JSON 문자열 이스케이프 / 해제

JSON 문자열 이스케이프란?#

JSON 문서 안에서 문자열은 큰따옴표 사이에 들어가야 하는데, 텍스트 자체에 따옴표나 줄바꿈, 백슬래시가 들어 있으면 문제가 생깁니다. 그대로 집어넣으면 파서가 너무 일찍 닫는 따옴표로 해석하거나, \를 이해할 수 없는 이스케이프의 시작으로 취급합니다. 이스케이프(Escaping) 는 이런 문자들을 JSON 사양이 정의한 짧은 백슬래시 시퀀스로 바꾸는 작업입니다. 따옴표는 \", 백슬래시는 \\, 줄바꿈은 \n, 탭은 \t 식이며 몇 가지가 더 있습니다. 이스케이프 해제(Unescaping) 는 그 반대로, 시퀀스를 원래 문자로 되돌리는 일입니다.

두 번째, 좀 더 가혹한 모드가 있습니다. 오래된 로그 전송기, 엄격한 데이터베이스, 순수 ASCII를 가정하는 전송 계층 같은 레거시 시스템은 127을 넘는 바이트에 걸립니다. 이런 환경을 위해 JSON은 임의의 비 ASCII 문자를 \uXXXX로 쓸 수 있게 해 줍니다(이모지 같은 성혜(BMP 바깥) 문자는 UTF-16 서로게이트 쌍으로). 텍스트는 여전히 올바른 JSON이며, 이스케이프 뒤에는 온전히 ASCII로만 이루어질 뿐입니다.

이 페이지는 양방향과 두 모드를 모두 지원합니다. 원시 문자열을 올바른 JSON 문자열 리터럴로 이스케이프하거나, 리터럴을 원래 텍스트로 이스케이프 해제합니다. 선택적으로 ASCII 전용 출력(\uXXXX) 스위치를 켜서 모든 비 ASCII 코드포인트를 \uXXXX 형태로 강제할 수 있습니다.

사용 방법#

1. 도구 모음 왼쪽 위의 인코딩 / 디코딩 토글로 방향을 고르세요. 인코딩은 원시 텍스트를 JSON 리터럴로 이스케이프하고, 디코딩은 리터럴을 다시 텍스트로 되돌립니다.
2. 왼쪽 입력 패널에 타이핑하거나 붙여넣으세요.
   • 인코딩 모드에서는 전체 텍스트가 하나의 JSON 문자열 리터럴(양끝 따옴표 포함)이 됩니다.
   • 디코딩 모드에서는 따옴표가 있는 리터럴("a\nb")이나 따옴표 없는 이스케이프 본문(a\nb)이나 모두 붙여넣을 수 있습니다. 도구가 따옴표를 감싸줍니다. 올바른 JSON 숫자, 불리언, 객체는 “문자열이 아님”으로 거부되며 자동 변환되지 않습니다.
3. 하위 소비자가 비 ASCII 바이트를 처리하지 못하면 ASCII 전용 출력(\uXXXX) (인코딩 모드)에 체크하세요. 이모지 같은 성혜 문자는 JSON.stringify와 똑같이 올바른 서로게이트 쌍으로 내보내집니다.
4. 결과는 출력 패널에 실시간으로 나타납니다. 복사 로 가져가세요.
5. 예제 는 다국어 데모 문자열을 채워주고, 지우기 는 양쪽 패널을 초기화합니다.

주요 기능#

• 사양에 정확한 단축형. RFC 8259가 요구하는 시퀀스(\", \\, \b, \f, \n, \r, \t)를 정확히 사용하고, 0x20 아래의 나머지에는 \uXXXX를 써서 JSON.stringify와 바이트 단위로 일치합니다.
• 진짜 ASCII 전용 모드. 비 ASCII 문자를 조용히 버리거나 깨지 않고, 각각을 \uXXXX로 내보냅니다. U+FFFF 위의 성혜 문자는 깨진 단일 코드 유닛이 아니라 올바른 UTF-16 서로게이트 쌍이 되며, 디코더가 거부하지 않습니다.
• 관대한 이스케이프 해제. 따옴표가 있는 리터럴과 따옴표 없는 본문을 모두 받아들이므로, 로그 한 줄에서 반쪽만 붙여넣은 조각도 예외를 던지지 않고 디코딩됩니다.
• 추측하지 않습니다. 디코딩 입력이 올바른 JSON이지만 문자열이 아니면(예: 숫자나 배열), 도구는 뒤에서 몰래 문자열화하지 않고 알려줍니다.

실전 예시#

인코딩 모드에서 예제 를 불러오면 입력은 따옴표, 백슬래시 경로, 줄바꿈, 저작권 기호, 이모지, 중국어를 의도적으로 섞은 문자열입니다.

He said "hi"
\path\ © 🌍 你好

ASCII 전용 을 끄면 이스케이프된 리터럴은 읽을 수 있는 문자를 그대로 유지하고 꼭 따옴표로 감싸야 하는 것만 감쌉니다.

"He said \"hi\"\n\\path\\ © 🌍 你好"

이제 ASCII 전용 출력(\uXXXX) 에 체크하면 같은 입력이 순수 ASCII가 됩니다. 저작권 기호는 네 글자 형태 \u00a9로, 지구 이모지는 서로게이트 쌍 \ud83c\udf0d로, 각 중국어 문자는 자신의 코드포인트(\u4f60, \u597d)로 바뀝니다.

"He said \"hi\"\n\\path\\ \u00a9 \ud83c\udf0d \u4f60\u597d"

디코딩 으로 전환해 두 리터럴 중 하나를 다시 붙여넣으면 이모지와 중국어를 포함한 원래 텍스트가 정확히 복원됩니다.

FAQ#

왜 이모지가 하나가 아니라 두 개의 \u 코드로 바뀌나요?#

U+FFFF 위의 문자(이모지, 희귀한 CJK 확장, 일부 수학 기호)는 16비트 코드 유닛 하나에 들어가지 않아서 UTF-16은 이를 서로게이트 쌍 — 상위 서로게이트와 하위 서로게이트 — 으로 표현합니다. 지구 이모지 🌍(U+1F30D)은 \ud83c\udf0d가 됩니다. \u 하나만 내보내면 엄격한 디코더가 거부하는 잘못된 JSON이 됩니다. 이 도구는 JSON.stringify처럼 쌍으로 내보내므로 출력이 왕복됩니다.

디코딩이 “입력이 JSON 문자열이 아닙니다.”라고 합니다. 무엇을 붙여넣었나요?#

올바른 JSON이지만 문자열이 아닌 것을 붙여넣었을 가능성이 큽니다. 보통은 숫자(42), 불리언(true), 객체/배열입니다. 도구는 이를 문자열화하지 않는데, 진짜 실수(문서 전체가 아니라 문자열 값 을 붙여넣으려 했을 것이므로)를 숨기기 때문입니다. 텍스트를 따옴표로 감싸고 다시 시도하세요.

리터럴 탭이나 벨 같은 제어 문자도 처리되나요?#

네. 입력의 리터럴 탭은 \t, 백스페이스는 \b, 폼피드는 \f, 캐리지 리턴은 \r이 됩니다. U+0020 아래의 다른 제어 코드(벨 0x07 포함)는 \u0007 형태의 코드가 됩니다. 이는 중요한데, JSON 문자열 안의 원시 제어 문자는 허용되지 않으며 일부 파서는 이를 아예 거부하기 때문입니다.

ASCII 전용 출력이 더 “안전”한가요?#

특정한 종류의 안전, 즉 비 ASCII 바이트를 망가뜨리거나 거부하는 전송 계층을 버텨내는 데에만 해당합니다. 보안 조치는 아닙니다 — 데이터는 여전히 쉽게 역순 가능하며, 더 제한적인 알파벳으로 표현되었을 뿐입니다. 소비자가 ASCII를 요구할 때만 켜두고, 그렇지 않으면 읽기 쉬운 형태가 디버깅에 훨씬 좋으므로 꺼두세요.