인코딩·문자셋
Unicode 이스케이프와 HTML 엔티티를 문자로 복원하기
사용할 도구
읽을 글이 역슬래시·&로 시작하면 손상이 아니라 다른 형식의 표기일 수 있습니다. 다만 Unicode 이스케이프·HTML 문자 참조·URL % 인코딩은 규칙이 달라 같은 디코더로 처리하지 않습니다.
あ·이모지·짧은 HTML 같은 문장으로 복원 범위를 봅니다. 결과는 텍스트로 보고 HTML·JavaScript로 실행하지 않습니다. 코드처럼 보여도 실행할 필요 없이 출처 형식을 확인하세요.
\u3042를 한 글자로 복원
\u3042디코딩하면 あ이고 인코딩 방식에 따라 \u3042·\u{3042}가 됩니다. 둘 다 문자를 가리켜도 수신 형식이 둘 다 받지는 않습니다. JSON 문자열과 JavaScript 코드 포인트 표기를 구분하세요.
로그의 \u3042는 あ를 이스케이프해 보여 준 것일 수 있습니다. 실제 여섯 문자 값인지 로거가 한 글자를 그렇게 표시한 것인지 출력 방식을 확인하세요. 표기만으로 저장 손상을 단정하지 마세요.
이모지 하나에 \u 두 묶음이 필요한 경우
\u{1F600}
\uD83D\uDE00첫 줄은 코드 포인트 하나, 둘째는 UTF-16 서로게이트 쌍입니다. 각각 디코딩하면 😀이며 두 묶음이 이모지 두 개는 아닙니다. 보이는 문자·UTF-16 단위 차이가 이스케이프에도 나타납니다.
\uD83D만 남기면 짝 없는 서로게이트로 오류입니다. 짧게 보이게 하거나 길이 제한에 맞추려 반쪽을 지우지 마세요. 표현 단위를 자르면 잘못된 데이터가 되므로 자르는 단위를 명확히 정해야 합니다.
&는 &를 나타내는 문자 참조
Tom & Jerry
<b>hello</b>결과는 Tom & Jerry와 <b>hello</b>라는 텍스트입니다. 태그를 실행해 굵게 렌더링하는 곳이 아닙니다. 복원 문자를 검사하는 것과 DOM에 HTML로 넣는 것은 다르며 성공이 안전 삽입 허가는 아닙니다.
이름 참조는 현재 amp·lt·gt·quot·apos·nbsp와 숫자 참조를 지원하며 전체 HTML 이름 목록은 아닙니다. 미지원 이름은 남습니다. 참조처럼 남아도 손상보다 지원 범위를 먼저 확인하세요.
&lt;를 한 번 풀어도 <는 아닙니다
&lt; → < → <첫 번은 &를 &로 만들어 <가 남고 다시 풀면 <입니다. 하지만 원문이 < 표기 자체를 설명했다면 두 번째는 잘못입니다. 이스케이프가 없어질 때까지가 아니라 직렬화 계층을 확인하세요.
JSON 안 HTML처럼 형식이 겹칠 수 있습니다. 바깥 JSON을 파싱해 문자열을 얻는 단계와 HTML 참조 복원을 나누세요. 광범위한 치환은 따옴표·구분자를 바꿀 수 있으니 단계별 기대값을 정하세요.
%E3%81%82와 あ도 다른 디코더 필요
Unicode: \u3042
HTML: あ / あ
URL UTF-8: %E3%81%82HTML 숫자 참조는 코드 포인트를 10·16진수로, URL %는 UTF-8 바이트로 나타냅니다. 숫자가 다르다고 문자가 다른 것은 아닙니다. 출처 형식으로 도구를 고르고 불명확하면 생성 측을 확인하세요.
현재 Unicode 디코딩은 \uXXXX·\u{X}·\xXX이며 \n·\t 등 모든 문자열 이스케이프 파서는 아닙니다. 전체 JSON은 JSON 검증을 쓰고 미지원 문법을 억지로 바꿔 성공처럼 만들지 마세요.
복원 뒤에도 출력 위치의 규칙은 남습니다
디코딩은 조사 진전이지만 결과를 HTML 본문·속성·JavaScript·URL에 넣을 때는 각 문맥 처리가 필요합니다. 한 번 이스케이프하면 어디서나 안전한 것이 아닙니다. 위치가 바뀔 때 해석 규칙을 확인하세요.
원래 표기·디코더·횟수·결과를 보고하세요. 'HTML 참조 한 계층을 풀어 &가 됨'이 '깨짐 수정'보다 구체적입니다. 보기 맞을 때까지 반복 변환보다 여분 계층이 생긴 경계를 고치는 것이 재발을 막습니다.
보이는 역슬래시는 데이터일까요, 표현 방식일까요?
로그에 \u3042가 보여도 원래 값은 あ이고 표시만 이스케이프한 경우가 있고, 사용자가 여섯 문자를 그대로 입력한 경우도 있습니다. 어느 계층을 복사했는지에 따라 디코딩 필요 여부가 다릅니다. JSON을 읽는다면 파싱된 값부터 확인하고, 치환을 추가하기 전에 파서가 이미 이스케이프를 해석했는지 보세요.
HTML 문자 참조도 같습니다. <라는 예를 그대로 보여 주려면 원문에 &lt;가 필요할 수 있습니다. 두 번 디코딩해 <로 만들면 보여 주려던 예가 달라집니다. 읽힐 때까지 반복하지 말고 알려진 표현 계층 수에 맞춰 복원하세요. 도구는 처리 이력을 추측하지 않으므로 읽힌다는 이유만으로 올바른 단계라고 판단할 수 없습니다.