데이터 형식·구조화 데이터

큰 JSON ID의 끝자리가 바뀐 이유는?

사용할 도구

계산 없이 주문번호를 복사했는데 다른 화면에서 끝자리가 바뀔 수 있습니다. 숫자로 읽는 순간에도 정밀도를 잃을 수 있으므로 원래 JSON의 자릿수와 파싱된 숫자를 구별하세요. 가상의 인접한 ID 두 개로 시작합니다.

구분을 유지할 두 숫자

{"first":9007199254740992,"second":9007199254740993}

JSON 정리에 그대로 붙여 넣으면 정밀도 보존 파서가 끝자리 2와 3을 유지합니다. 오류가 없는지만 보지 말고 축약 라벨이 아닌 출력의 전체 값 두 개가 다른지 확인하세요.

다른 프로그램을 거친 second도 2로 끝나면 그 경로에서 정보가 사라진 것입니다. 이 도구의 성공이 다른 앱의 정밀도를 보장하지는 않습니다. 원문 응답, 파싱 직후, 표시, 저장 후 재로딩을 각각 비교해 최초 변경 지점을 찾으세요.

ID를 문자열로 전달하는 예

{"first":"9007199254740992","second":"9007199254740993","code":"00123"}

긴 ID와 00123이 모두 문자열이라 식별자의 자릿수와 앞자리 0을 보존하기 좋습니다. 그러나 송신 측만 바꾸면 숫자만 받는 계약을 위반할 수 있습니다. API와 저장 형식을 맞추고 형식 정리와 자료형 변경을 따로 설명하세요.

JSON 숫자로 00123을 쓰는 것은 앞자리 0을 보존하는 올바른 방법이 아닙니다. 123으로 바뀐 뒤에는 원래 자릿수를 추정할 수 없습니다. 고정 폭은 규격 일부이므로 수량인지 정확히 일치시킬 코드인지 먼저 정하세요.

양쪽에 하나씩 넣을 객체

{"id":9007199254740993}
{"id":9007199254740992}

JSON 비교의 양쪽에 객체 하나씩 넣고 ID 변경을 확인한 뒤 한쪽을 따옴표 ID로 바꿔 자료형 차이도 봅니다. 정밀도 보존 내부 표현 때문에 value 같은 보조 경로가 보일 수 있지만 원래 API 필드와 혼동하지 마세요.

1과 1.0은 수학적 값이 같아도 표기가 다릅니다. 구조 비교 결과는 비교 규칙에 달렸습니다. ID 원문이 요구사항이라면 숫자 동등성만 보지 말고 고정 예상 문자열과 JSON 자료형을 함께 확인하세요.

CSV에 올바른 숫자가 남아도 스프레드시트가 부정확한 숫자로 읽을 수 있습니다. 다른 형식 변환의 지원 범위도 JSON 정리와 다릅니다. 한 도구의 보장을 전체 흐름으로 확대하지 말고 가상 경계값으로 단계마다 확인하세요.

이미 반올림된 일반 숫자를 BigInt로 바꿔도 잃은 자릿수는 돌아오지 않습니다. 원래 두 값이 하나가 된 뒤에는 출력만으로 원본을 알 수 없습니다. 반올림 전 원본을 확보하고 표시값을 손으로 고치기보다 입력 경계를 수정하세요.

123뿐 아니라 인접 큰 숫자, 문자열 큰 ID, 앞자리 0 코드도 시험하세요. 숫자 필드의 상한과 거부 범위를 정합니다. 계산할 수량까지 전부 문자열로 바꾸면 다른 형식 오류가 생기므로 필드 의미에 따라 선택하세요.

원본 JSON, 작업, 결과값, 예상 자료형을 함께 전달하세요. 정밀도 손실이라는 말만으로는 축약 표시와 저장값 변경을 구분할 수 없습니다. 라벨만 짧다면 표시 계층을 확인해야 하며 구체적 관찰이 올바른 수정 위치를 알려줍니다.