개발자 도구 · JSON 포맷터 및 유효성 검사기
JSON 문자열 이스케이프 설명: \n, \uXXXX 및 제어 문자
· 작동 방식
JSON 개발자 워크플로 검증
JSON 문자열 내부의 원시 개행 문자는 유효하지 않으며 탭도 유효하지 않습니다. 이 게시물에서는 8개의 이스케이프 시퀀스, \u 이스케이프 및 서로게이트 쌍의 작동 방식, 붙여넣은 단락이 전체 파일을 무효화할 수 있는 이유를 다룹니다.
페이로드를 중단한 단락
페이로드를 분리한 단락 — 인용된 설명에 눈에 보이는 줄 바꿈을 붙여넣으면 제어 문자가 JSON 문자열에 직접 삽입됩니다. 첫 번째 줄은 완전한 것처럼 보이지만 여는 따옴표에는 여전히 문자열 내용이나 닫는 따옴표가 필요합니다. 파서가 원시 줄 바꿈에 도달하면 JSON 문자열이 물리적 줄을 그런 식으로 확장할 수 없기 때문에 거기서 중지됩니다. 텍스트에는 디코딩된 값에 줄 바꿈이 필요할 때마다 두 문자 이스케이프 `\n`가 포함되어야 합니다.
문서나 스프레드시트에서 복사된 탭은 편집자가 이를 무해한 공백으로 렌더링하더라도 동일한 종류의 오류를 유발합니다. 리터럴 탭을 `\t`로, 캐리지 리턴을 `\r`로, 기타 금지된 컨트롤을 명명된 또는 유니코드 이스케이프로 바꾸세요.
8가지 이스케이프 JSON이 허용하는
8개의 이스케이프 JSON에서 허용합니다. 백슬래시 뒤에 짧은 형식은 `"`, `\\`, `\/`, `\b`, `\f`, `\n`, `\r` 및 `\t`. 이는 따옴표, 백슬래시, 슬래시, 백스페이스, 폼 피드, 줄 바꿈, 캐리지 리턴 및 가로 탭을 나타냅니다. 슬래시는 이스케이프되지 않은 것처럼 보일 수도 있습니다. `\/`는 주로 종료 스크립트 시퀀스를 특별히 처리했던 컨텍스트와의 호환성을 위해 존재합니다.
JSON 백슬래시 뒤에는 다른 문자가 올 수 없습니다. `\v`, `\0`, `\x41` 또는 백슬래시 뒤에 물리적 개행 문자가 오는 등 프로그래밍 언어에 익숙한 시퀀스는 여기서 유효하지 않습니다. 짧은 이스케이프가 없는 경우 `\u` 뒤에 정확히 4개의 16진수 숫자가 오는 것을 사용하세요. 이 작은 고정 어휘는 JSON 문자열을 이식 가능하게 유지합니다. 소비자는 유효한 텍스트로 표시되는 문자를 결정하기 위해 JavaScript, Python 또는 셸별 이스케이프 규칙이 필요하지 않습니다.
리터럴 탭은 유효하지 않지만 리터럴 é는 괜찮은 이유
리터럴 탭은 유효하지 않지만 리터럴 é는 괜찮은 이유 — JSON는 문자열 내부의 U+0000부터 U+001F까지 이스케이프되지 않은 코드 포인트를 금지합니다. 해당 범위에는 보이지 않는 효과로 인해 프레이밍이나 표시가 중단될 수 있는 탭, 줄 바꿈 및 기타 컨트롤이 포함되어 있습니다. 문자 `é`는 U+00E9이며 제어 범위를 훨씬 벗어납니다. 따라서 UTF-8 JSON는 이를 따옴표 사이에 직접 포함할 수 있습니다. 대부분의 스크립트, 기호, 이모티콘도 마찬가지입니다.
따라서 일반 유니코드 이스케이프는 선택 사항이며 정리 요구 사항은 아닙니다. `"café"` 및 `"caf\u00e9"`은 동일한 문자 시퀀스로 디코딩됩니다. 직접 텍스트는 일반적으로 사람들이 읽기 쉬운 반면, 이스케이프는 ASCII 전용 전송에 도움이 되거나 특정 코드 단위를 표시할 수 있습니다. 제어 문자는 다릅니다. 이스케이프는 필수입니다.
\uXXXX 이스케이프 작동 방식
`\uXXXX` 이스케이프 작동 방식 — `u` 뒤에는 정확히 4개의 16진수 숫자가 와야 하며 두 경우 모두 0–9 또는 A–F를 사용합니다. `\u00E9`는 `é`에 대한 UTF-16 코드 단위를 나타내고 `\u000A`은 줄 바꿈을 나타냅니다. 다른 프로그래밍 언어에서 해당 표기법을 허용하더라도 숫자 수가 적거나 `\u{1F600}`과 같은 중괄호 또는 16진수가 아닌 문자로 인해 JSON이 유효하지 않게 됩니다.
U+FFFF 위의 문자는 이 이스케이프 형식에서 서로게이트 쌍으로 표시됩니다. 이모티콘 😀은 `\uD83D\uDE00`로 작성할 수 있습니다. 하나의 유니코드 스칼라 값으로 구문 분석한 후 상위 및 하위 대체가 결합됩니다. JSON 문법은 짝이 없는 서로게이트 이스케이프를 전달할 수 있지만 다운스트림 인코더와 애플리케이션은 완전한 유니코드 문자를 식별하지 못하기 때문에 이를 거부하거나 대체할 수 있습니다.
작업된 예: Windows 경로 및 HTML 조각 이스케이프
작업 예: Windows 경로 및 HTML 조각 이스케이프 - 의도한 경로 `C:\Temp\report.txt`에는 JSON 소스: `"C:\\Temp\\report.txt"`에서 각 백슬래시를 두 배로 늘려야 합니다. 두 배로 늘리지 않으면 `\T`은 잘못된 이스케이프이며 `\r` 또는 `\t`와 같은 시퀀스는 경로 구분 기호 대신 자동으로 제어 문자가 될 수 있습니다. 표시된 슬래시가 이미 외부 언어에 속해 있는지 추측하지 않고 의도한 값에서 JSON을 빌드합니다.
`<a title="Report">Open</a>`와 같은 HTML 조각은 꺾쇠 괄호와 슬래시를 문자 그대로 유지할 수 있지만 속성 인용은 JSON 문자열 내에서 `\"`이 되어야 합니다. 줄 바꿈이 두 개의 태그를 구분하는 경우 이를 `\n`로 인코딩합니다. 결과 JSON 멤버는 유효성을 검사하고 원래 HTML 텍스트로 다시 구문 분석할 수 있습니다.
이스케이프가 두 배로 늘어나는 곳
이스케이프가 두 배로 증가하는 경우 - 모든 둘러싸는 텍스트 문법은 백슬래시를 해석할 수 있는 고유한 기회를 갖습니다. 디코딩된 문자열 `line1\nline2`을 포함하는 JSON 문서는 해당 백슬래시를 이스케이프하여 `"line1\\nline2"`를 생성해야 합니다. 해당 JSON 텍스트 자체가 JSON 문자열로 저장된 경우 해당 따옴표와 두 백슬래시에는 또 다른 이스케이프 레이어가 필요합니다. 명백한 혼란은 JSON의 특별한 확장 형식이 아닌 여러 표현을 기록합니다.
셸 및 프로그래밍 언어 리터럴은 JSON 구문 분석기가 인수를 보기 전에 자체 인용 규칙을 추가합니다. 내부부터 진단합니다. 먼저 정확한 디코딩된 값을 작성하고 이를 JSON로 한 번 인코딩한 다음 주변 셸 또는 소스 언어에 대해 전체 JSON 텍스트를 인코딩합니다. 각 경계에서 다음 파서가 실제로 수신하는 바이트 또는 문자를 검사합니다.
여기서 다루지 않는 내용
여기서 다루지 않는 내용 — `"`과 같은 HTML 엔터티와 `%20`과 같은 URL 백분율 인코딩은 별도의 구문 컨텍스트에 대한 별도의 변환입니다. JSON 파서는 두 형식 모두 디코딩하지 않습니다. 문자열 `"""`에는 구문 분석 후 따옴표가 아닌 6개의 리터럴 문자가 포함되어 있으며, `"%20"`에는 공백이 아닌 백분율 기호와 두 자리 숫자가 포함되어 있습니다. 데이터가 HTML 또는 URL 구성 요소와 교차하는 경우에만 해당 인코딩을 적용하십시오.
이 토론은 또한 출력 인코딩을 대체하지 않습니다. 신뢰할 수 없는 소스로부터 수신된 유효한 JSON에는 여전히 HTML, 스크립트와 같은 텍스트 또는 터미널 제어 시퀀스가 일반 문자열 데이터로 포함될 수 있습니다. 나중에 명령을 렌더링하거나 실행하는 애플리케이션은 해당 대상을 안전하게 처리해야 합니다. JSON 이스케이프 처리는 JSON 구조를 보호합니다. 보편적인 위생처리는 아닙니다.
요점: 문법이 금지하는 것을 피하세요. 그 이상은 아닙니다.
요점: 문법이 금지하는 것을 피하세요. 그 이상은 없습니다. U+0020 아래의 큰따옴표, 백슬래시 및 코드 포인트는 JSON 문자열 내에서 주의가 필요합니다. 일반 유니코드는 계속해서 읽을 수 있는 반면, `\uXXXX`는 정확한 4자리 대체 코드를 제공하고 서로게이트 쌍은 U+FFFF 이상의 문자를 나타냅니다. 명백히 비어 있는 위치에 대한 진단은 문자 그대로의 개행, 탭 또는 텍스트 이스케이프로 대체되어야 하는 기타 제어 문자를 식별하는 경우가 많습니다.
슬래시를 눈으로 계산하는 대신 인코딩 레이어를 계산합니다. 애플리케이션이 수신해야 하는 값부터 시작하여 JSON에 대해 한 번 인코딩한 다음 외부 셸, 소스 파일 또는 두 번째 JSON 문자열에 대한 결과 문서를 인용합니다. JSON 구문 분석기에 표시된 텍스트의 유효성을 검사하고 정확성이 중요한 경우 나중에 디코딩된 문자열을 검사합니다.