zip 한글 깨짐 복구

사용법

1. 파일명이 깨지는 zip을 위 영역에 끌어다 놓거나 파일 선택으로 올립니다.
2. 진단 표에서 각 파일명의 상태(자소분리·인코딩 깨짐·정상)와 복구 후 이름을 확인합니다.
3. 복구된 zip 다운로드 버튼을 누르면 정상 파일명으로 다시 압축된 zip이 저장됩니다.
4. 받은 zip을 윈도우·맥 어디서든 풀어 파일명이 올바르게 보이는지 확인합니다.

어떤 경우에 필요할까요

• 맥으로 압축해 제출한 과제 zip을 받은 교수님이나 조원이 윈도우에서 열었더니 파일명이 ㅎㅏㄴㄱㅡㄹ처럼 낱자로 분리되어 보인다는 연락을 받았을 때
• 거래처나 관공서처럼 윈도우 환경이 확실한 곳에 맥에서 만든 압축파일을 보내기 전에 파일명이 깨지지 않는지 미리 점검하고 싶을 때
• 반대로 회사 윈도우 PC에서 압축해 보낸 zip을 맥이나 아이폰에서 열었더니 한글 파일명이 전부 외계어로 표시될 때
• 받은 zip을 풀었더니 __MACOSX 폴더와 ._로 시작하는 정체불명의 파일이 함께 쏟아져 나와 정리가 번거로울 때
• 압축을 다시 하려 해도 원본 파일을 보낸 사람에게 재요청하기 애매해서 깨진 zip 자체를 받은 쪽에서 바로 고치고 싶을 때

한글 파일명이 왜 깨지는지, 어떻게 예방하는지는 zip 한글 깨짐의 원인과 해결 가이드에서 더 자세히 다룹니다.

엑셀에서 CSV 한글이 깨진다면 CSV 한글 깨짐 해결 도구를, 압축 전 이미지 용량을 줄이려면 이미지 용량 줄이기 도구를 이용해 보세요.

'한' 한 글자가 3바이트에서 9바이트가 되는 순간

자소분리와 인코딩 깨짐은 화면에서만 다르게 보이는 게 아니라, 파일 안에 적히는 바이트 자체가 다릅니다. 파이썬 3.14.5(MacBook Pro M1 Pro, macOS 26.5.2)로 같은 글자를 세 방식으로 인코딩해 꺼내 봤습니다.

'한' 한 글자
  UTF-8 (정상, NFC)  : ED 95 9C                       3바이트
  UTF-8 (자소분리)    : E1 84 92 E1 85 A1 E1 86 AB     9바이트  ← ㅎ + ㅏ + ㄴ
  CP949 (윈도우)      : C7 D1                          2바이트

자소분리는 '한'을 초성 ㅎ, 중성 ㅏ, 종성 ㄴ 세 글자로 쪼개 각각 3바이트씩 적습니다. 눈으로는 붙어 보여도 파일 안에서는 이미 세 글자입니다. 파일명 전체로 늘리면 이렇습니다.

이 도구가 하는 일은 이 바이트 열을 첫 번째 열의 모양으로 되돌리는 것입니다. 압축을 풀었다 다시 압축하는 게 아니라 이름 부분만 고쳐 다시 담기 때문에, 안에 든 파일 내용은 손대지 않습니다.

압축 프로그램들이 실제로 남긴 헤더를 열어봤습니다

zip 규격에는 "이 파일명은 UTF-8입니다"라고 알리는 표시(범용 플래그 11번 비트, 0x800)가 있습니다. 이 표시가 제대로 붙어 있으면 이름이 깨질 일이 없습니다. 같은 이름의 파일을 세 가지 방법으로 압축한 뒤, 만들어진 zip의 중앙 디렉터리를 직접 파싱해 표시가 붙었는지 확인했습니다.

맥 쪽 두 방법 다 이름은 멀쩡한 UTF-8인데 "이건 UTF-8이다"라는 표시를 붙이지 않았습니다. 표시가 없으면 규격상 옛 방식(윈도우에서는 CP949)으로 읽는 게 맞으므로, 받은 쪽 프로그램이 규격대로 처리하면 정상 이름을 깨진 이름으로 만들어 버립니다. 맥에서 압축한 게 윈도우에서 깨지는 사연의 절반이 여기에 있습니다. 이 도구는 표시를 믿지 않고 실제 바이트를 UTF-8로 먼저 읽어 보기 때문에 이 경우를 정상으로 통과시킵니다.

나머지 절반은 자소분리입니다. 위 실험에서는 자소분리가 나오지 않았습니다. 요즘 맥 파일 시스템은 이름을 준 대로 저장하기 때문입니다. 자소분리는 예전 파일 시스템에서 만들어져 오래 굴러다닌 파일이나, 이름을 낱자로 분해해 저장하는 앱을 거친 파일에서 나옵니다. 그 경우도 이 도구가 잡아냅니다.

맥 기본 압축의 파일 수도 눈에 띕니다. 파일 하나를 넣었는데 zip 안에는 항목이 다섯 개가 들어갔고, 그중 셋이 __MACOSX 계열입니다. 용량도 195바이트짜리가 835바이트가 됐습니다. 도구 화면의 "맥 메타 파일 제거"를 체크하면 이 항목들이 빠집니다.

두 해석 중 하나를 직접 고르는 345글자

이 도구는 이름 바이트를 먼저 UTF-8로 읽어 보고, 실패하면 CP949로 해석합니다. 대부분의 한글 CP949 바이트는 UTF-8로 읽으면 반드시 실패하기 때문에 이 방법이 통합니다. 그런데 예외가 있습니다. 완성형 한글 11,172자를 전부 CP949로 인코딩해 UTF-8로도 읽히는지 확인해 봤더니 345자가 걸렸습니다.

완성형 한글 11172자 중 CP949 바이트가 UTF-8로도 유효한 글자: 345자
  예: 징 짖 짙 짚 짜 짝 짠 짢 짤 짧 …

'징' CP949 = C2 A1  → UTF-8로 읽으면 '¡'
'짜' CP949 = C2 A5  → UTF-8로 읽으면 '¥'

실제로 "징짜.txt"라는 이름을 CP949로 넣은 zip을 만들어 수정한 페이지에 올려 봤습니다. 화면에는 "¡¥.txt / 확실하지 않음"과 함께 "UTF-8 유지: ¡¥.txt", "EUC-KR 복구: 징짜.txt"가 나란히 표시됐고, 선택 전에는 다운로드할 수 없었습니다. EUC-KR 쪽을 고른 뒤 받은 zip의 실제 파일명은 "징짜.txt"였고, UTF-8 쪽을 고르면 "¡¥.txt"로 저장됐습니다. 두 글자 조합 124,813,584개를 전부 확인했을 때 119,025개가 같은 함정에 해당하므로 짧은 이름에서는 이 확인 단계가 필요합니다.

UTF-8 표시가 없는 이름이 두 방식으로 모두 읽히고, UTF-8 해석에는 제어 문자·라틴 확장 문자나 기호가, CP949 해석에는 완성형 한글이 나올 때만 "확실하지 않음"으로 멈춥니다. 어느 쪽이 원래 이름인지 도구가 추측하지 않고 목록에서 사용자가 직접 선택하게 합니다.

위 표시와 판정은 전부 실제 Chrome으로 이 페이지를 열어 파일을 올린 결과입니다. 다만 윈도우 압축 프로그램들이 만든 zip을 직접 구해 검증하지는 못했고, CP949 zip은 규격에 맞게 직접 만들어 썼습니다.