제 텍스트에 \"가 사방에 있는 이유는 무엇인가요?

한 번보다 많이 이스케이프됐습니다. 매 회차가 앞 회차의 백슬래시를 이스케이프하므로, 원래 따옴표 하나가 여러 백슬래시에 앞서게 됩니다. 반복해서 디코딩하세요 — 매 회차가 정확히 한 겹을 벗깁니다 — 텍스트가 보통으로 읽힐 때까지.

감싸는 따옴표를 켜야 하나요?

완전한 JSON 값을 그대로 붙여넣고 싶을 때, 예를 들어 키의 오른쪽 전체로 붙여넣을 때만입니다. 코드에 이미 있는 문자열에 붙여넣는다면 끄세요 — 아니면 따옴표 안의 따옴표가 됩니다.

한국어, 아랍어, 중국어, 이모지는 이스케이프가 필요한가요?

아니요. JSON 문자열은 유니코드라서 그 문자들은 그대로 유효하고 기본으로 읽을 수 있게 남습니다. \uXXXX 옵션은 하류 시스템이 맨 ASCII를 고집할 때만 켜세요. 그러면 이모지는 필수인 두 개의 서로게이트 이스케이프로 쓰입니다.

"잘못된 이스케이프 나열"은 무슨 뜻인가요?

입력에 백슬래시에 이어 JSON이 정의하지 않은 것, 예를 들어 \q나 뒤에 16진수 네 자리가 없는 \u가 있습니다. 위치가 보고되므로 그 지점을 볼 수 있습니다: 대개 텍스트가 애초에 JSON 이스케이프되지 않았거나 중간에 잘린 것입니다.

제 텍스트가 어딘가로 전송되나요?

아니요. 이스케이프도 디코딩도 전적으로 브라우저 안에서 도므로, 토큰, 페이로드, 로그 줄이 기기 밖으로 나가지 않습니다.

JSON 문자열 이스케이프

텍스트를 JSON 문자열로 유효하도록 이스케이프하고, 이스케이프된 문자열을 원래 내용으로 되돌립니다. 오류 위치도 표시.

감싸는 따옴표 포함비ASCII 문자 이스케이프

텍스트

이스케이프 결과

결과가 여기에 표시됩니다

이 도구가 하는 일

JSON 문자열은 맨 큰따옴표, 맨 백슬래시, 맨 줄바꿈을 담을 수 없습니다 — 형식이 문자열의 시작과 끝을 표시하는 데 그 문자들을 필요로 하기 때문입니다. 그래서 그것들은 대신 이스케이프 나열로 쓰이고, 이 도구는 두 형태를 서로 변환합니다. 보통 텍스트를 붙여넣어 JSON에 넣을 준비가 된 이스케이프본을 얻거나, 방향을 바꿔 이스케이프된 텍스트를 다시 읽을 수 있게 만듭니다.

두 번째 방향이 사람이 보통 찾아오는 이유입니다: 백슬래시의 벽처럼 되돌아온 로그 줄, 오류 메시지, curl 응답입니다. 모두 브라우저 안에서 돌며, 읽으려는 페이로드가 운영 응답일 때 그것이 중요합니다.

이스케이프 나열

JSON은 짧은 이스케이프 목록을 정의하고, 이 도구는 정확히 그 목록을 씁니다 — 그보다 별난 것은 없습니다. 그 밖은 무엇이든 유효한 JSON이 아니기 때문입니다.

\" — 큰따옴표. 아니면 문자열을 끝냅니다.
\\ — 단일 백슬래시. Windows 경로와 정규식 패턴이 두 겹이 되는 이유입니다.
\n과 \r — 줄바꿈과 캐리지 리턴.
\t — 탭. 백스페이스와 폼 피드를 위한 \b와 \f도 있습니다.
\/ — 앞 슬래시의 선택적 이스케이프. 유효하지만 결코 필수가 아닙니다. 이 도구는 받아들이고 결코 내지 않습니다.
\uXXXX — 16진수 코드로 된 임의의 문자로, 제어 문자와 ASCII 밖의 것을 쓸 수 있는 방법입니다.

제어 문자 — 코드 32 미만의 모든 것 — 는 JSON 문자열 안에 문자 그대로의 형태가 아예 없으므로, ASCII 출력을 청하지 않았어도 늘 \uXXXX 이스케이프로 나옵니다.

백슬래시가 늘어나는 이유

이런 도구에 손을 뻗는 가장 흔한 이유는 한 번보다 많이 이스케이프된 텍스트입니다. 인코딩할 때마다 앞선 것이 들여온 백슬래시를 이스케이프하므로, 따옴표 하나가 점점 긴 꼬리를 기릅니다:

original    He said "hi"
escaped     He said \"hi\"
escaped x2  He said \\\"hi\\\"

이것은 값이 JSON으로 직렬화되고, 그 JSON이 다른 JSON 문서 안의 문자열로 저장되고, 그 결과가 로그에 기록될 때 일어납니다. 한 번 디코딩하면 한 겹을 벗깁니다. 텍스트가 보통으로 읽힐 때까지 결과에 대해 다시 돌리세요. 디코딩했는데 출력에 아직 떠도는 백슬래시가 있으면, 그것은 진짜 여분의 겹이지 변환의 버그가 아닙니다.

따옴표: 값이냐 조각이냐

완전한 JSON 문자열 값은 감싸는 큰따옴표를 포함합니다. 하지만 대개는 코드나 설정에 이미 있는 문자열 안에 붙여넣는 것이라, 거기서 그 따옴표는 틀립니다. 그래서 이스케이프는 기본으로 맨 이스케이프된 내용을 내고, "감싸는 따옴표 포함" 옵션은 통째로 붙여넣을 값을 원할 때 그것을 더합니다.

디코딩에는 그런 선택이 필요 없습니다 — 두 형태를 다 받습니다. 조각을 붙여넣든 JSON 문서에서 완전한 따옴표 붙은 값을 그대로 붙여넣든, 감싸는 따옴표가 인식되어 벗겨집니다.

유니코드, 그리고 그것을 언제 이스케이프하나

JSON은 유니코드 형식입니다. "안녕하세요"와 "😀"는 쓰인 그대로 흠 없이 유효한 JSON 문자열이고, 읽을 수 있게 두는 것이 여기의 기본값입니다. \uXXXX 옵션은 아직 따라오지 못한 시스템을 위한 것입니다: ASCII를 가정하고 그 밖을 망가뜨리는 오래된 로그 파이프라인, 터미널, 파서입니다.

그 옵션이 켜졌을 때 세부 하나가 중요합니다. 기본 범위 밖의 문자 — 대부분의 이모지 — 는 내부적으로 서로게이트 쌍이라 불리는 두 단위로 저장되고, 형식은 두 반쪽을 별개의 이스케이프로 쓰기를 요구합니다. 그래서 이모지는 하나의 긴 것이 아니라 두 개의 \u 이스케이프가 됩니다. 이것을 틀리는 도구는 어느 파서도 받지 않는 이스케이프를 내며, 이것이 한 시스템을 살아남고 다음에서 깨지는 이모지의 흔한 설명입니다.

디코딩이 실패할 때

모든 백슬래시 나열이 유효한 이스케이프는 아닙니다. \q는 JSON에서 아무 뜻이 없고, \u12는 자릿수의 반이 빠진 \u 이스케이프입니다. 그것들을 그대로 통과시켜 괜찮아 보이지만 데이터가 말한 것이 아닌 출력을 돌려주는 대신, 이 도구는 멈춰 잘못된 나열이 시작되는 정확한 줄과 열을 보고합니다.

실무에서 그 오류는 유익합니다: 떠도는 \q는 대개 텍스트가 애초에 JSON 이스케이프되지 않았음을, 잘린 \u는 대개 입력이 짧게 잘렸음을 뜻합니다 — 길이 제한에서 잘린 로그 줄이나 나열 중간에 멈춘 복사입니다.

자주 묻는 질문

제 텍스트에 \"가 사방에 있는 이유는 무엇인가요?: 한 번보다 많이 이스케이프됐습니다. 매 회차가 앞 회차의 백슬래시를 이스케이프하므로, 원래 따옴표 하나가 여러 백슬래시에 앞서게 됩니다. 반복해서 디코딩하세요 — 매 회차가 정확히 한 겹을 벗깁니다 — 텍스트가 보통으로 읽힐 때까지.
감싸는 따옴표를 켜야 하나요?: 완전한 JSON 값을 그대로 붙여넣고 싶을 때, 예를 들어 키의 오른쪽 전체로 붙여넣을 때만입니다. 코드에 이미 있는 문자열에 붙여넣는다면 끄세요 — 아니면 따옴표 안의 따옴표가 됩니다.
한국어, 아랍어, 중국어, 이모지는 이스케이프가 필요한가요?: 아니요. JSON 문자열은 유니코드라서 그 문자들은 그대로 유효하고 기본으로 읽을 수 있게 남습니다. \uXXXX 옵션은 하류 시스템이 맨 ASCII를 고집할 때만 켜세요. 그러면 이모지는 필수인 두 개의 서로게이트 이스케이프로 쓰입니다.
"잘못된 이스케이프 나열"은 무슨 뜻인가요?: 입력에 백슬래시에 이어 JSON이 정의하지 않은 것, 예를 들어 \q나 뒤에 16진수 네 자리가 없는 \u가 있습니다. 위치가 보고되므로 그 지점을 볼 수 있습니다: 대개 텍스트가 애초에 JSON 이스케이프되지 않았거나 중간에 잘린 것입니다.
제 텍스트가 어딘가로 전송되나요?: 아니요. 이스케이프도 디코딩도 전적으로 브라우저 안에서 도므로, 토큰, 페이로드, 로그 줄이 기기 밖으로 나가지 않습니다.