JSON 정규화 (RFC 8785 JCS)

규격이 그렇게 정했고, 이유는 실용적입니다. UTF-16은 ECMAScript·자바·.NET에서 문자열이 표현되는 방식이고, JSON 이스케이프 시퀀스 자체가 UTF-16 코드 단위입니다. 두 순서는 BMP 밖 문자에서만 갈리는데, 그 문자는 U+D800~U+DBFF로 시작하는 서로게이트 쌍으로 정렬되므로 이모지가 U+FFFF 뒤가 아니라 U+E000 앞에 옵니다. 코드 포인트로 정렬하는 구현도 결정적이긴 하지만 JCS가 아니고, 그 서명은 JCS 구현에서 검증되지 않습니다.

키 정렬은 읽기 좋은 diff를 주고, 정규화는 서명할 바이트를 줍니다. JCS는 공백을 모두 제거하고, 모든 숫자를 ECMAScript 표기로 다시 쓰고, 모든 문자열의 이스케이프를 고치고, UTF-8로 인코딩하고, 잘못된 입력을 거부합니다. 커밋할 깔끔한 문서만 원한다면 키 정렬기가 더 간단하고 숫자를 다시 쓰지도 않습니다.

여기서 JSON 숫자는 double이고 정규 형식은 텍스트가 아니라 그 double이기 때문입니다. 1.0과 1e0은 모두 1이 되고, 1E30은 1e+30이 되며, 0.002는 그대로지만 2e-3도 0.002가 됩니다. double이 담는 정밀도를 넘는 리터럴은 들어올 때 반올림되므로 9007199254740993은 9007199254740992로 나옵니다. 이 툴은 표기가 바뀌는 리터럴을 모두 표시합니다.

규격이 요구합니다. 짝 없는 서로게이트는 유효한 유니코드가 아니라서 구현마다 다르게 다룹니다 — 이스케이프하기도, 치환하기도, 예외를 던지기도 합니다 — 그리고 그 불일치는 같은 문서가 다른 바이트를 내고 한쪽에서는 검증되고 다른 쪽에서는 실패하는 서명을 뜻합니다. 멈추는 것이 유일하게 상호운용되는 답입니다.

서명에서는 그렇습니다. JSON.parse는 같은 이름 둘 중 마지막 것을 남기고 앞의 것을 말없이 버리므로, 문서가 검증자는 보지 못하는 값을 담고 있으면서 겉보기에 올바른 해시를 낼 수 있습니다. RFC 8785는 중복을 아예 금지하는 I-JSON 입력을 요구해 이를 피해 가므로, 중복은 파싱 전에 텍스트에서 잡아야 합니다.