개발자 도구 · JSON 포맷터 및 유효성 검사기
JSON을 깨는 보이지 않는 문자: BOM, 둥근 따옴표 및 NBSP
· 작동 방식
JSON 개발자 워크플로 검증
유효성 검사기가 첫 번째 문자에서 오류를 보고하고 파일이 완벽해 보이는 경우 일반적으로 보이지 않는 문자가 원인입니다. 이 게시물에서는 바이트 순서 표시, 인쇄상의 인용부호 및 줄바꿈 방지 공백과 각 항목이 보고되는 방법에 대해 설명합니다.
라인 1, 열 1, 볼 수 있는 문제는 없습니다.
라인 1, 열 1, 보기에 잘못된 것은 없습니다. JSON 문서는 실제 위치를 차지하는 문자로 시작할 수 있지만 눈에 보이는 글리프 없이 렌더링됩니다. 여는 중괄호는 바이트 순서 표시나 너비가 0인 문자가 앞에 있더라도 첫 번째로 나타납니다. 엄격한 파서는 `{`에 도달하기 전에 숨겨진 코드 포인트를 발견하므로 첫 번째 열 보고는 모호하지 않고 정확합니다. 디스플레이와 문자 순서는 단순히 다른 이야기를 전달합니다.
단지 캐럿이 옆에 나타난다고 해서 올바르게 보이는 중괄호를 삭제하지 마십시오. 보고된 오프셋에서 코드 포인트를 검사하고 공백 표시를 활성화하거나 16진수 보기로 전환하세요. ToolAcre는 구문 분석 전에 선행 BOM을 자동으로 제거하지 않으며 스캐너는 첫 번째 예상치 못한 문자를 보고합니다.
UTF-8 바이트 순서 표시
UTF-8 바이트 순서 표시 — 바이트 시퀀스 EF BB BF는 파일 시작 부분에서 U+FEFF로 디코딩됩니다. UTF-8에서는 바이트 순서가 모호하지 않으므로 표시가 필요하지 않지만 일부 편집자 및 내보내기 도구에서는 여전히 이를 인코딩 서명으로 추가합니다. RFC 8259에 따르면 JSON 생성기는 네트워크로 연결된 JSON에 BOM을 추가해서는 안 됩니다. 단, 파서는 상호 운용성을 위해 BOM을 무시하도록 선택할 수 있습니다. 이러한 허용 오차는 도구 전체에서 가정할 수 없습니다.
JavaScript 문자열에서 UTF-8 표현이 3바이트를 사용하더라도 BOM은 1문자입니다. ToolAcre는 위치를 문자열 문자로 보고하므로 선행 표시가 1 행, 1 열에 나타납니다. 파일을 배포하기 전에 BOM 없이 UTF-8을 저장하거나 U+FEFF를 제거하도록 편집기를 구성하십시오.
워드 프로세서의 스마트 따옴표
워드 프로세서의 둥근 따옴표 — 활자체 열기 및 닫기 표시는 산문에서는 세련되게 보이지만 JSON에서는 ASCII 따옴표 U+0022만 문자열 구분 기호로 인식합니다. U+201C 및 U+201D는 일반 유니코드 문자입니다. 문자열 외부에서는 속성 이름이나 값을 시작할 수 없으므로 유효성 검사기는 둥근 따옴표 자체를 보고합니다. 채팅, 이메일 또는 문서 편집기의 자동 수정으로 인해 JSON가 원래 유효했던 이후에 변경 사항이 발생하는 경우가 많습니다.
구분 기호를 곧은 큰따옴표로 바꾼 다음 값에 속하는 아포스트로피와 따옴표를 검사합니다. 둥근 따옴표는 올바르게 구분된 JSON 문자열(예: `"She said “go”"`) 내의 콘텐츠로서 완전히 합법적입니다. 구분 기호의 문법 작업을 수행하라는 요청을 받은 경우에만 실패합니다.
줄바꿈하지 않는 공백 및 너비가 0인 문자
줄바꿈 없는 공백 및 너비가 0인 문자 — JSON 공백은 의도적으로 짧은 목록입니다: 일반 공백 U+0020, 탭 U+0009, 줄 바꿈 U+000A 및 캐리지 리턴 U+000D. 잘림 방지 공백 U+00A0은 콜론과 값 사이의 일반 공백과 동일해 보일 수 있지만 해당 목록에는 없습니다. 너비가 0인 공백 U+200B는 아무것도 표시하지 않지만 인용된 문자열 외부에는 예상치 못한 문자로 남아 있습니다.
웹 페이지는 단어를 함께 유지하기 위해 줄 바꿈 방지 공백을 사용하며 메시징 시스템은 줄 바꿈 또는 스크립트 처리를 위해 너비가 0인 문자를 삽입할 수 있습니다. 서식이 지정된 조각을 복사하면 해당 조각을 구성으로 가져올 수 있습니다. 구조적 NBSP 문자를 일반 공백으로 바꾸고, 보고된 오프셋에 따라 의도하지 않은 너비가 0인 문자를 제거합니다.
작업 예시: 채팅 메시지에서 복사된 구성
작업된 예: 채팅 메시지에서 복사된 구성 — 표시되는 텍스트가 `{"mode": "safe"}`와 유사하지만 시작 시 유효성 검사가 실패한다고 가정합니다. 16진수 보기에서는 버팀대 앞에 EF BB BF가 표시됩니다. 해당 BOM을 제거하면 다음 보고서가 실제로 U+201C인 `mode` 이전 견적으로 진행됩니다. 두 스마트 구분 기호를 모두 U+0022로 바꾸면 콜론과 값 사이에 U+00A0이 노출됩니다.
구조적 잘림 방지 공간을 U+0020로 변경하고 다시 한 번 유효성을 검사합니다. 이제 승인된 결과를 정상적으로 형식화할 수 있습니다. 이 순서는 화면에 표시된 것만 수정하는 것이 신뢰할 수 없는 이유를 보여줍니다. 여러 개의 보이지 않거나 유사한 문자가 서로 다른 문법 위치를 차지할 수 있습니다. 각 줄과 열을 따라 실제 코드 포인트를 식별하고 의도적으로 교체한 후 유효성 검사를 다시 실행하세요.
보이지 않는 것을 보는 방법
보이지 않는 것을 보는 방법 - 편집기의 공백 렌더링 옵션을 활성화하여 탭과 공백을 구별하고 비정상적인 간격을 드러낸 다음 여전히 동일하게 보이는 문자에 대해 유니코드 검사기 또는 16진수 보기를 사용합니다. UTF-8 BOM은 EF BB BF로 표시되고, 잘림 방지 공백은 C2 A0으로, 너비가 0인 공백은 E2 80 8B로 표시됩니다. 스마트 열기 및 닫기 따옴표는 E2 80 9C 및 E2 80 9D로 표시됩니다.
계산하기 전에 진단의 좌표계를 일치시킵니다. ToolAcre는 JavaScript 문자열을 스캔하므로 해당 열은 UTF-8 바이트가 아닌 UTF-16 코드 단위를 계산합니다. 따라서 바이트 지향 16진수 편집기는 ASCII가 아닌 문자 뒤에 더 큰 숫자 오프셋을 표시할 수 있습니다. 보고된 라인을 사용하여 검색 범위를 좁히고 인접한 코드 포인트를 검사하고 필요한 경우에만 변환합니다.
여기서 다루지 않는 내용
여기서 다루지 않는 내용 — `café`과 같은 mojibake는 완전히 유효한 JSON일 수 있습니다. 파서는 문자열 문자의 일반적인 시퀀스를 확인하며 UTF-8 바이트가 이전에 다른 인코딩으로 디코딩되었다는 증거가 없습니다. 마찬가지로, 인용된 값 안에 있는 줄바꿈 없는 공백이나 너비가 0인 문자는 구문상 유효합니다. 유효성 검사는 JSON 문법을 위반하는 문자를 포착합니다. 유효한 유니코드 콘텐츠가 작성자의 의도와 일치하는지 여부를 결정할 수 없습니다.
원래 인코딩과 잘못된 인코딩에 대한 지식을 사용하여 바이트가 텍스트가 되는 경계에서 인코딩 손상을 복구합니다. 더 좋아 보일 때까지 JSON 문자열을 반복적으로 인코딩하고 디코딩하지 마세요. 그렇게 하면 이미 올바른 문자가 손상될 수 있습니다. 애플리케이션 수준 정규화도 별도의 결정입니다. 즉, 시각적으로 동일한 유니코드 시퀀스는 유효한 상태를 유지하면서 다르게 비교할 수 있습니다.
요점: 선이 깨끗해 보이더라도 보고된 열을 신뢰하십시오.
요점: 행이 깨끗해 보이더라도 보고된 열을 신뢰하십시오. 보이지 않는 문자와 유사한 구두점은 여전히 소스에서 정확한 위치를 차지합니다. 선행 BOM, 둥근 구분 기호, 잘림 방지 공백 또는 너비가 0인 표시로 인해 파서가 올바르게 나타나는 중괄호나 인용문에 도달하지 못할 수 있습니다. 근처에 보이는 JSON을 무작위로 편집하는 대신 공백을 표시하고 코드 포인트나 바이트를 검사하고 신원이 문법적 역할과 충돌하는 문자를 대체합니다.
16진수 도구가 인코딩된 바이트를 계산하는 동안 위치는 문자를 계산할 수 있으므로 모든 오프셋 숫자가 일치할 것이라고 기대하는 대신 주변 텍스트를 비교하십시오. 문서 경계에서만 BOM을 제거하고, 스마트 구분 기호를 U+0022로 변환하고, 문자열 내부의 합법적인 유니코드를 지우지 않고 유효하지 않은 구조적 공백을 대체합니다.