기술 · 실용 가이드
jq 원본 출력은 정확한데 필터 뒤에서 ID가 바뀌나요? BigInt 전에 실제 경로를 검사하세요
그대로 출력하는 필터는 통과해도 산술 연산이 마지막 숫자를 바꿀 수 있습니다. 원시 출력을 짝지어 비교하고 하위 복원 콜백이 문제를 가리기 전에 손실 지점을 찾으세요.

ID의 마지막 숫자가 바뀌면 파서를 바꾸기 전에 각 단계의 원시 출력을 보관하세요. 원본 출력 테스트 통과만으로는 실제 산술 필터가 모든 숫자를 보존한다고 할 수 없습니다.
로컬 실험 8개로 원본 텍스트, jq 출력, Node 파싱의 경계를 구분하고 문자열 기대값으로 전체 숫자를 확인합니다.
1. 기대하는 ID를 Number에 저장하지 마세요
원본 JSON 텍스트 {"id":9007199254740993,"count":42}에서 시작하고 기대하는 ID를 문자열 "9007199254740993"으로 보관하세요. JavaScript 숫자 리터럴로 쓴 뒤 두 Number를 비교하면 기대값부터 반올림될 수 있습니다. 데이터를 바꾸기 전에 실제 jq 및 Node 실행 파일, 버전, 운영 필터를 기록하세요.
RFC8259는 구현이 범위와 정밀도를 제한할 수 있다고 하며 절댓값이 2^53−1 이하인 정수를 정확하게 상호 운용할 수 있는 범위로 제시합니다. 범위를 벗어나도 표현 가능한 정수가 있으므로 큰 값이 모두 바뀌지는 않습니다. 식별자에는 정확한 모든 숫자가 필요합니다. 파싱 성공이나 그럴듯한 로그만으로는 검증을 마칠 수 없습니다.
2. 원본 출력과 실제 필터를 짝지어 검사하세요
Linux 로컬 실험 8개는 jq1.7과 Nodev24.22.1을 사용했습니다. 위 입력에서 jq -c '.'은 원래 ...993 토큰을 출력했지만 .id += 0은 ...992를 출력했습니다. 1.7 설명서는 수정하지 않은 리터럴 보존과 배정밀도 산술을 구분합니다. 따라서 원본 출력 통과는 그 연산만 입증하며 모든 필터의 안전성을 보증하지 않습니다.
각 변환 직전과 직후에 출력되는 텍스트를 저장하세요. 이 실행 파일에서 .id |= tostring은 "9007199254740993"을, .id += 0 | .id |= tostring은 "9007199254740992"를 만들었습니다. 먼저 문자열로 바꾸는 경우와 나중에 바꾸는 경우는 서로 다른 대조군입니다. 실제 운영 필터와 빌드로 다시 검사하세요. 다른 jq 구현이나 릴리스를 보증하는 결과는 아닙니다.
3. 복원 콜백이 받은 입력을 입증하세요
일반 JSON.parse 뒤에 id.toString()을 호출하면 ...992가 나왔고, 이미 파싱한 값을 BigInt에 전달해도 ...992였습니다. 키를 지정하여 BigInt(context.source)를 읽는 복원 콜백은 원본 입력과 원본 출력 필터 결과에서 ...993를 얻었습니다. jq 산술 뒤에는 같은 콜백도 ...992를 얻었습니다. 입력 숫자 텍스트가 이미 바뀌었기 때문입니다.
구조를 아는 숫자 ID에 사용한 테스트 콜백은 (k,v,c)=>k==='id'&&typeof v==='number'?BigInt(c.source):v였습니다. 샘플용 콜백이며 범용 검증기는 아닙니다. 실제 런타임에서 context.source 지원 여부를 검사하고 필드 경로 및 정수 토큰 문법을 검증하세요. 소수나 지수 표기는 별도 계약이 필요합니다. 숫자처럼 보이는 모든 문자열을 변환하면 텍스트로 남겨야 할 필드도 바뀝니다.
4. 전체 왕복 검증을 마무리하세요
API를 관리한다면 이전 전에 수신 측과 문자열 ID를 합의하세요. 여덟 번째 실험은 복원한 BigInt를 id.toString()으로 명시적으로 직렬화한 뒤 문자열 계약에 따라 다시 파싱해 모든 원래 숫자를 얻었습니다. 이는 샘플의 왕복을 입증하며 바뀌지 않은 숫자 스키마와의 호환성을 입증하지는 않습니다. 수량, 소수 금액이나 무관한 필드를 조용히 바꾸지 마세요.
확보한 원본 숫자 텍스트, 의도한 각 전달 단계, 최종 스키마에 맞춘 문자열 비교가 모두 일치해야 수정이 완료됩니다. 원본 출력 대조군과 실제 필터 회귀 검사를 함께 보관하고 ...993과 ...992 및 처음 바뀐 경계를 기록하세요. 하위 복원 콜백은 상위 단계에서 잃은 정보를 복구할 수 없습니다. 이번 검사는 로컬 입력으로 수행했으며 실제 게이트웨이나 브라우저는 검사하지 않았습니다. 실제 생성 측과 소비 측의 각 경계에서 다시 실행하세요.
