브라우저에서만 처리
깨짐 예시 넣기:
복구 후보 (한글다움 점수 순)
아직 입력이 없습니다.
깨짐 모양으로 원인 알아보기
| 이렇게 보이면 | 무슨 일이 있었나 | 복구 |
|---|---|---|
| 안녕하세요 | UTF-8 데이터를 Latin-1/CP1252 로 읽음 | 가능 |
| ¾È³çÇϼ¼¿ä | EUC-KR 데이터를 Latin-1/CP1252 로 읽음 | 가능 |
| 안녕 | 위 실수가 두 번 겹침(이중 인코딩) | 대부분 가능 |
| 占쏙옙, � | 디코딩 실패로 바이트가 이미 버려짐 | 불가 |
| 뷁, 궭 (희귀 음절) | EUC-KR을 UTF-8로 읽는 등 우연히 유효했던 조합 | 부분적 |
자주 묻는 것
왜 복구가 안 되는 경우가 있나요?
깨짐에는 두 종류가 있습니다. 바이트는 그대로인데 잘못 보여준 경우(Latin-1로 읽은 UTF-8 등)는 해석만 되돌리면 되므로 완전 복구가 됩니다. 반면 디코딩 단계에서 해석 불가 바이트가 �(U+FFFD)로 대체된 경우는 정보 자체가 사라진 뒤라 수학적으로 복구가 불가능합니다. UTF-8을 EUC-KR로 읽은 경우가 대표적으로, 일부 바이트 조합만 우연히 살아남아 부분 복구만 됩니다.
CP949와 EUC-KR은 다른가요?
CP949(UHC)는 EUC-KR의 확장으로, EUC-KR에 없는 8,822자(옛 완성형 밖의 음절)를 더 담습니다.
브라우저의 TextDecoder('euc-kr')는 WHATWG 표준에 따라 실제로는 CP949(windows-949)로
동작하므로, 이 도구의 EUC-KR 경로는 CP949 데이터도 처리합니다.
입력한 값이 서버로 전송되나요?
전송되지 않습니다. 변환은 전부 브라우저의 자바스크립트가 하며 네트워크 요청이 발생하지 않습니다. 개발자 도구의 네트워크 탭으로 확인해 보셔도 됩니다.
관련 도구: 한글 초성 정규식 생성기 · URL 인코더/디코더 · 해시 생성기