유니코드 정규화 (NFC·NFD)
한글 자소가 흩어진 문자열을 NFC로 되돌리고 NFD·NFKC·NFKD 네 형식을 서로 비교합니다. 코드포인트 단위로 뜯어보며 왜 겉보기가 같은데 다른 문자열인지 확인합니다.
입력한 내용은 서버로 전송되지 않습니다.
NFD 로 저장된 한글입니다. 겉보기는 같지만 코드포인트가 자모 단위로 흩어져 있습니다.
이 문자열은 NFD (분해형) 입니다
15자 · 37바이트
조합·분해에 따라 문자열이 달라지는 글자가 들어 있습니다. 비교하기 전에 정규화가 필요합니다.
형식이 하는 일
코드포인트로 뜯어보기
파란 칸은 앞 글자에 붙는 결합 문자입니다. 한글이 NFD 로 저장되면 중성·종성이 여기에 해당합니다.
사용 방법
- 1자소가 흩어진 파일명이나 문자열을 붙여 넣습니다.
- 2NFC 결과를 복사해 쓰면 대부분의 한글 깨짐이 해결됩니다.
- 3코드포인트 목록에서 결합 문자가 어디에 붙어 있는지 확인할 수 있습니다.
자주 묻는 질문
애플 파일시스템이 한글을 자모 단위(NFD)로 저장하고 윈도우·리눅스는 완성된 글자(NFC)로 저장하는데, zip 파일에 어느 쪽인지 적는 자리가 없어 그대로 전달되기 때문입니다. 파일명이 “ㅎㅏㄴ”처럼 보이면 NFD로 저장된 것이고, NFC로 바꾸면 되돌아옵니다.
NFC는 합칠 수 있는 것을 합치고 NFD는 쪼갤 수 있는 것을 쪼갭니다. “한”은 NFC에서 코드포인트 하나(U+D55C)지만 NFD에서는 초성·중성·종성 셋으로 나뉩니다. 화면에는 똑같이 보이지만 문자열로 비교하면 다릅니다.
검색어를 맞추거나 표기를 통일할 때 씁니다. K가 붙으면 호환 문자까지 표준형으로 갈아치워 ①이 1이 되고 ㈜가 (주)가 되며 전각 Ａ가 반각 A가 됩니다. 다만 원문이 달라지므로 저장하거나 표시할 값에는 쓰지 마세요.
그럴 가능성이 큽니다. 데이터베이스에 NFC로 저장된 값을 NFD 문자열로 찾으면 일치하지 않습니다. 저장할 때와 찾을 때 모두 같은 형식으로 정규화하는 것이 해결책이며, 보통 NFC를 씁니다.
늘어납니다. UTF-8 기준으로 완성형 한글 한 글자는 3바이트지만, 받침이 있으면 자모 셋으로 나뉘어 9바이트, 받침이 없으면 둘로 나뉘어 6바이트가 됩니다. 파일명 길이 제한에 걸리는 일도 이 때문에 생깁니다.
알아두면 좋은 점
- 브라우저에 내장된 String.prototype.normalize를 그대로 씁니다. 입력값이 서버로 전송되지 않습니다.
- zip 파일 안의 이름을 직접 고치지는 못합니다. 풀어낸 파일명을 여기서 바꾼 뒤 이름을 다시 지정하세요.
함께 보면 좋은 도구
마지막 검증: 2026년 8월 30일 · 결과는 참고용 추정치입니다.