최근 업데이트
불러오는 중...

Unicode Escape ↔ Text 변환기

Unicode Escape ↔ Text 변환기 \uXXXX, \xXX, \u{…} 형식을 한 화면에서 양방향 변환하고 strict/lenient 정책별 오류 위치를 함께 점검할 수 있는 개발용 변환기입니다. 변환 방향 Escape → Text Text → Escape 디코드 정책 Strict (오류 강조) Lenient (리터럴 유지) Escape 출력 포맷 \uXXXX (BMP)/surrogate pair \u{…} code point \xXX (ASCII) + \uXXXX HEX 대문자 사용 […]

최종 업데이트: 2026/03/04

Unicode Escape ↔ Text 변환기

\uXXXX, \xXX, \u{…} 형식을 한 화면에서 양방향 변환하고 strict/lenient 정책별 오류 위치를 함께 점검할 수 있는 개발용 변환기입니다.

변환 중입니다. 토큰을 분석하고 결과를 생성하고 있습니다.
입력 단위
0
변환 성공
0
오류/경고
0
출력 길이
0

텍스트 결과

오류 목록 (위치/건수)

# 구분 위치 입력 토큰 메시지
아직 오류가 없습니다. 변환을 실행하면 strict/lenient 정책에 따른 이슈가 표시됩니다.

코드포인트 분석

# 문자 U+코드포인트 UTF-16 단위 위치
변환 후 코드포인트 목록이 표시됩니다.

상세 변환 표

# 유형 입력 출력 코드 위치 상태 메모
변환을 실행하면 토크나이저 기준의 상세 행이 출력됩니다.

변환 로직은 브라우저 내부에서만 실행되며 입력 텍스트는 서버로 전송되지 않습니다.

Unicode Escape ↔ Text 변환기란?

Unicode Escape ↔ Text 변환기는 개발 중 자주 만나는 이스케이프 문자열을 사람이 읽을 수 있는 텍스트로 복원하거나, 일반 텍스트를 이스케이프 시퀀스로 안전하게 변환하는 도구입니다. 특히 로그 분석, API 페이로드 확인, 코드 리뷰에서 눈으로 확인하기 어려운 문자열을 빠르게 해석하는 데 초점을 맞췄습니다.

이 도구는 단순 치환이 아니라 토크나이저 기반 해석을 사용해 \uXXXX, \xXX, \u{…}를 구분하고, 잘못된 토큰의 위치와 원인을 함께 보여줍니다. 따라서 결과 문자열만 보는 흐름이 아니라, 어떤 구간에서 문제가 생겼는지까지 한 번에 점검할 수 있습니다.

이런 상황에서 활용해 보세요

문자열 디버깅은 결과 값만 바뀌는 문제가 아니라, 인코딩 규칙과 입력 품질이 동시에 영향을 줍니다. 아래 사례처럼 정책과 위치 기반 점검이 필요한 순간에 가장 효과적입니다.

  • 서버 로그의 \uXXXX 값이 실제 어떤 문자로 표시되는지 즉시 확인해야 할 때
  • 프론트엔드에서 전송하는 텍스트를 API 계약에 맞는 escape 포맷으로 변환해야 할 때
  • 복수 백슬래시(\\)가 섞인 문자열에서 리터럴과 실제 escape를 구분해야 할 때
  • surrogate pair가 깨져 이모지/보조평면 문자가 손상되는 원인을 찾아야 할 때
  • 오류 위치를 QA 티켓에 정확히 남기고 재현 가능한 증적을 공유해야 할 때

주요 기능

변환 정확성과 리뷰 가독성을 동시에 확보할 수 있도록, 결과 요약과 진단 정보를 한 화면에서 단계적으로 확인할 수 있게 구성했습니다.

  • 양방향 변환: Escape → Text, Text → Escape를 즉시 전환합니다.
  • 다중 escape 지원: \uXXXX, \xXX, \u{...} 형식을 동일 입력에서 함께 처리합니다.
  • strict/lenient 정책: invalid escape를 오류로 강조하거나 리터럴 유지 경고로 처리합니다.
  • 오류 위치/건수 표시: line:column, index, 원본 토큰, 메시지를 표로 제공합니다.
  • 요약 카드 + 결과 탭: 입력 단위·변환 성공·이슈 수·출력 길이를 한눈에 보여줍니다.
  • 상세 변환 표: 토큰 단위 입력/출력/코드/상태를 행 단위로 추적할 수 있습니다.
  • 다운로드 버튼: 결과 텍스트, 오류 CSV, 코드포인트 CSV를 즉시 저장할 수 있습니다.

사용 방법

  1. 변환 방향을 먼저 선택합니다. Escape 해석이 목적이면 Escape → Text, 이스케이프 생성이 목적이면 Text → Escape를 사용합니다.
  2. Escape 해석 시에는 strict/lenient 정책을 정하고, Text 인코딩 시에는 출력 포맷(\uXXXX, \u{...}, \xXX 혼합)을 선택합니다.
  3. 입력 텍스트를 붙여넣고 Convert를 클릭하면 결과 영역으로 자동 스크롤되며 요약 카드와 탭이 업데이트됩니다.
  4. 오류 목록 탭에서 위치·건수를 먼저 확인한 뒤, 코드포인트 탭상세 표로 원인을 좁혀 검토합니다.
  5. 검토를 마치면 다운로드 버튼으로 증적 파일을 내보내거나, 현재 탭 복사 기능으로 이슈 리포트에 바로 붙여넣습니다.

리셋 버튼은 입력·옵션·결과를 모두 초기 상태로 되돌리므로, 서로 다른 케이스를 연속 검증할 때 오염 없이 반복 테스트를 수행할 수 있습니다.

토크나이저 기준과 해석 규칙

디코드 과정은 문자열을 문자 단위가 아니라 토큰 단위로 스캔합니다. 백슬래시 연속(\\)은 리터럴 백슬래시로 처리하고, \uXXXX/\xXX/\u{...} 패턴은 각각 독립 검증한 뒤 변환합니다. 이 구조 덕분에 부분 손상 입력에서도 문제 구간을 정확히 분리해 표시할 수 있습니다.

surrogate pair는 고/저 대리쌍이 연속으로 등장할 때만 결합합니다. high surrogate 단독, low surrogate 단독, 범위를 벗어난 code point는 strict에서는 오류로, lenient에서는 원문 보존 경고로 기록해 디버깅과 복구 두 시나리오를 모두 지원합니다.

기준 확인일: 2026-03-04
참고 문서: ECMAScript String Literals, MDN Character escape, Unicode FAQ (UTF / surrogate).

자주 묻는 질문

strict와 lenient는 실제로 무엇이 다른가요?

strict는 규격 위반 토큰을 오류로 강조해 원인을 빠르게 찾는 데 초점을 두고, lenient는 같은 토큰을 원문 리터럴로 남겨 데이터 흐름을 끊지 않으면서 경고로 추적하도록 설계되어 있습니다. 즉, strict는 품질 게이트용, lenient는 복구·운영 대응용에 가깝습니다.

\\uD83D\\uDE80 같은 surrogate pair는 어떻게 처리하나요?

토크나이저가 high surrogate와 low surrogate의 연속 여부를 확인해 정상 쌍이면 하나의 코드포인트로 결합합니다. 쌍이 깨진 경우에는 위치와 토큰을 함께 표시해 어떤 escape가 손상되었는지 즉시 확인할 수 있습니다.

Text → Escape에서 왜 포맷 선택이 필요한가요?

대상 시스템마다 허용 문법이 다르기 때문입니다. 일부 런타임은 \u{...}를 지원하지만 레거시 파서는 \uXXXX만 허용하며, 바이너리 로그처럼 ASCII 우선 환경에서는 \xXX 혼합 포맷이 더 실용적일 수 있습니다.

오류 CSV와 코드포인트 CSV는 어떤 차이가 있나요?

오류 CSV는 이슈 triage용으로, 구분·위치·원본 토큰·메시지를 중심으로 구성됩니다. 코드포인트 CSV는 문자열 검증용으로, 문자별 U+값과 UTF-16 단위를 기록해 인코딩 호환성 점검이나 회귀 비교에 유리합니다.

백슬래시가 여러 개 연속된 입력도 신뢰할 수 있나요?

네. 연속 백슬래시는 독립 토큰으로 처리되어 실제 escape와 리터럴 구간이 분리됩니다. 따라서 \\u0041처럼 사람이 보기 헷갈리는 입력에서도 어떤 부분이 해석되고 어떤 부분이 그대로 유지되는지 표로 확인할 수 있습니다.

민감한 문자열을 넣어도 괜찮나요?

변환 자체는 브라우저에서만 동작하지만, 운영 보안 관점에서는 실데이터 대신 마스킹된 샘플로 테스트하는 습관이 안전합니다. 특히 인증 토큰이나 개인정보가 포함된 로그는 검증 전에 반드시 비식별화하는 것을 권장합니다.