ZIP 안의 깨진 한글 파일명 복구

사용 방법

1. 전달받은 원본 ZIP을 선택하고 이름의 기존 인코딩을 고릅니다. 한국어 이름이라면 EUC-KR·CP949로 시작하고, 일본어 자료라면 Shift_JIS를 선택합니다.
2. 파일 이름 미리 보기를 눌러 원래 이름과 저장할 이름을 비교합니다. 상위 폴더만 보지 말고 하위 폴더, 숫자 뒤의 한글, 원본 바이트 유지로 표시된 항목까지 확인합니다.
3. 미리 본 이름이 맞으면 선택한 파일을 변환합니다. 복구 결과를 내려받아 별도의 빈 폴더에 풀고, 이름과 파일 내용이 맞는지 확인한 다음 전달용 사본으로 사용합니다.

포맷 설명

ZIP은 파일마다 붙는 로컬 헤더와 전체 항목을 모아 놓은 중앙 디렉터리에 이름을 저장합니다. 이름 바이트가 같아도 해석하는 문자 인코딩이 다르면 화면에 보이는 글자는 달라질 수 있습니다. UTF-8을 나타내는 bit 11이 있으면 그 표시를 먼저 따르고, 표시가 없어도 원본 이름의 CRC와 일치하는 Info-ZIP Unicode Path 필드가 있으면 그 안의 이름을 사용합니다. 둘 다 없고 이름에 영문 기본 문자 밖의 바이트가 있을 때만 사용자가 고른 EUC-KR 또는 Shift_JIS 해석을 적용합니다. 따라서 정상적인 UTF-8 이름을 한국어로 다시 읽는 방식과는 동작이 다릅니다. 한글이 들어 있다는 이유만으로 이름 전체를 무조건 바꾸지 않습니다.

자주 묻는 질문

깨진 이름이면 모두 원래 한글로 돌아오나요?

원래 이름을 표현한 바이트가 ZIP에 남아 있어야 복구할 수 있습니다. 다른 프로그램이 깨진 이름을 이미 물음표로 바꿔 저장했다면 이 도구가 원래 철자를 알아낼 수 없습니다. 한국어로 해석하는 데 성공해도 그것이 실제 파일의 제목이라는 보장은 없습니다. 예를 들어 서로 다른 언어의 바이트가 선택한 인코딩에서 우연히 읽힐 수 있으므로, 알고 있는 폴더명과 문서명 여러 개를 직접 대조해야 합니다.

복구한 ZIP과 원본 ZIP의 바이트가 다른데 내용도 바뀐 것인가요?

압축 파일 전체의 바이트는 달라집니다. 이름 길이가 바뀌면 뒤에 오는 항목의 위치도 달라져 헤더와 중앙 디렉터리를 다시 써야 하기 때문입니다. 오래된 Unicode 이름 필드를 정리하고 필요한 데이터 descriptor 정보도 헤더로 옮깁니다. 다만 처리에 성공한 각 파일의 압축 본문은 원본에서 그대로 가져옵니다. 전체 ZIP의 해시가 달라졌다는 사실만으로 안의 문서가 변했다고 판단하지 마세요. 항목 주석도 읽을 수 있을 때 같은 UTF-8 표시에 맞춰 인코딩을 옮깁니다.

일본어 이름이나 한글과 영어가 섞인 이름은 어떻게 하나요?

일본어 이름은 기존 인코딩에서 Shift_JIS를 고르면 됩니다. 언어 선택은 이름 정보가 부족한 항목에만 적용되고, UTF-8 표시가 있는 이름이나 검증된 Unicode 이름은 계속 우선합니다. 한글과 영문이 섞인 경로에서는 영문 부분만 정상으로 보이고 한글 부분만 깨질 수 있습니다. 옵션을 바꾸면 이전 미리 보기는 지워지므로 새 목록을 읽고 이름을 다시 확인하세요.

이름이 겹친다는 오류는 왜 나오나요?

복구 뒤 서로 다른 항목이 같은 경로가 되면 한 파일이 다른 파일을 덮거나 압축 프로그램이 하나를 생략할 수 있습니다. HanOpen은 대소문자만 다른 이름, Unicode 정규화로 같아지는 이름, 파일 이름과 하위 폴더 경로의 충돌도 막습니다. 오류가 난 원본은 압축 프로그램에서 겹치는 항목에 서로 다른 이름을 붙여 다시 저장해야 합니다. 이름을 임의로 선택해 하나를 버리는 복구는 하지 않습니다.

암호 ZIP과 ZIP64도 읽을 수 있나요?

이 버전은 암호화된 항목과 ZIP64를 지원하지 않습니다. 여러 디스크로 나뉜 ZIP도 처리 대상이 아닙니다. Store 또는 Deflate로 압축한 일반 ZIP 가운데 항목 10,000개, 중앙 디렉터리 16 MB, 압축 해제 크기의 합 256 MB 이하를 받습니다. 이 조건을 만족해도 파일 선택 영역에 보이는 기기별 입력 크기 한도를 넘으면 작업을 시작할 수 없습니다.

복구했는데 문서 안의 한글도 깨져 보입니다

압축 안의 파일 이름과 파일 본문의 인코딩은 별개의 정보입니다. 이름을 고쳐도 텍스트 파일 안에 저장된 바이트를 다른 인코딩으로 바꾸지는 않습니다. 문서 제목은 정상인데 본문만 깨지면 원본을 만든 프로그램의 저장 형식이나 해당 파일을 여는 프로그램의 문자 설정을 살펴보세요. SMI 자막의 본문을 UTF-8 SRT로 바꾸려는 목적이라면 별도의 자막 변환 도구에서 파일 내용과 언어 트랙을 확인할 수 있습니다.

원본 압축을 먼저 보관하세요

수신한 ZIP은 이름이 이상하게 보이더라도 바로 덮어쓰지 말고 그대로 남겨 두세요. 파일 이름이 깨진 화면을 보고 이름을 수동으로 고친 뒤 다시 압축하면 원래 인코딩을 추적하는 데 필요한 바이트가 사라질 수 있습니다. 복구 결과는 다른 이름으로 내려받으므로 원본과 나란히 보관할 수 있습니다. 결과가 기대와 다르면 원본을 다시 선택해 다른 인코딩으로 확인할 여지가 남습니다. 이미 여러 번 재압축한 사본만 있다면 최초 발신자가 가진 ZIP이나 압축 전 폴더를 요청하는 것이 더 정확한 출발점입니다. 이 과정에서 문서 내용을 공개할 필요는 없습니다. 발신자에게 파일과 폴더의 의도한 이름만 확인받아 미리 보기와 대조해도 판별에 도움이 됩니다.

미리 보기에서 살펴볼 네 가지

첫째, 프로젝트명이나 기관명처럼 정확한 철자를 알고 있는 이름을 고릅니다. 둘째, 한글과 숫자가 함께 들어 있는 날짜별 파일을 확인합니다. 셋째, 가장 안쪽 하위 폴더의 이름도 읽어 봅니다. 넷째, 복구 방식이 원본 바이트 유지로 표시된 항목이 있는지 살펴봅니다. 한 항목이 맞았다는 이유로 전체 목록이 맞는다고 단정할 수는 없습니다. 한 ZIP 안에도 서로 다른 시기에 추가된 파일이나 다른 문자 규칙으로 저장된 항목이 섞일 수 있기 때문입니다. 목록이 길면 이름 100개 더 보기로 표시 범위를 늘려 확인할 수 있습니다. 작은 화면에서는 표 안을 스크롤해 긴 경로의 뒷부분까지 보세요.

원본 바이트 유지 표시의 의미

EUC-KR 또는 Shift_JIS로 이름을 읽는 과정에서 잘못된 바이트 조합이 나오면 알아서 비슷한 글자로 바꾸지 않습니다. 해당 항목의 이름 바이트와 UTF-8이 아니라는 상태를 보존하고 목록에 판별 실패를 표시합니다. 이 항목은 복구 ZIP에서도 프로그램에 따라 이상하게 보일 수 있습니다. 원본 바이트를 남겼다는 말은 원래 한국어 이름을 찾아냈다는 뜻이 아닙니다. 다른 항목은 정상으로 복구되었더라도 이 항목만은 별도의 확인 대상으로 남깁니다. 발신자가 알려 준 철자와 원본 압축의 정보를 대조한 뒤 적절한 압축 편집 도구에서 이름을 직접 정리할 수 있습니다. 내용 확인을 마치기 전에는 판별 실패 항목을 삭제하지 마세요.

CRC 검사는 무엇을 확인하나요

ZIP에는 압축을 푼 데이터의 CRC와 크기가 기록되어 있습니다. 변환할 때 Store 항목은 그 바이트를 읽고, Deflate 항목은 작은 덩어리로 풀어 기록된 값과 비교합니다. 값이 맞지 않거나 데이터가 중간에 끊겼다면 복구 다운로드를 만들지 않고 손상을 안내합니다. 이 검사는 전송 중 손상이나 일부 잘린 데이터를 발견하는 데 쓰입니다. 문서의 문장이 사실인지, 사진이 필요한 사진인지, 파일을 열어도 되는지까지 판단하는 검사는 아닙니다. 원본 ZIP이 다른 경로로 다시 전달될 수 있다면 손상이 난 사본을 반복 처리하기보다 새 사본을 받아 비교하는 편이 낫습니다. 이름 문제와 내용 손상을 구분해 대응하세요.

큰 ZIP에서 전체 본문을 먼저 읽지 않습니다

압축을 선택하면 파일 끝의 EOCD와 중앙 디렉터리를 먼저 읽어 이름과 항목 정보를 구합니다. 변환할 때에는 압축 본문을 스트림으로 검사하고, 결과 ZIP은 원본 파일의 압축 구간을 연결해 만듭니다. 전체 압축을 한 번에 풀어 거대한 배열로 보관한 뒤 다시 압축하는 경로를 사용하지 않습니다. 로컬 자동 검증에서는 101 MB 합성 ZIP을 처리하면서 원본 전체를 ArrayBuffer로 읽는 호출이 없었고 한 번에 읽은 버퍼의 최대 크기는 65,577바이트였습니다. 이 수치는 해당 검증 경로를 설명하는 자료이며 휴대전화의 처리 시간이나 최대 메모리를 보장하는 수치가 아닙니다. 사용 중인 기기의 한도와 입력 파일의 구조에 따라 결과는 달라집니다.

안전하지 않은 경로를 바꾸지 않고 멈추는 이유

ZIP의 항목 이름은 단순한 표시 제목이 아니라 압축을 풀 때 사용할 경로이기도 합니다. 상위 폴더로 이동하는 경로, 절대 경로, 드라이브를 지정한 이름, 운영체제의 예약 이름은 의도하지 않은 위치에 파일을 만들거나 다른 파일과 충돌할 수 있습니다. 심볼릭 링크 같은 특수 항목도 일반 문서로 가장해 새 압축에 넣지 않습니다. 이런 경우에는 이름을 자동으로 잘라 내거나 적당한 폴더로 옮기지 않고 원본 수정을 안내합니다. 경로를 바꾸면 문서 안의 상대 경로나 함께 배포된 자료의 연결이 끊길 수도 있기 때문입니다. 압축을 만든 쪽에서 어떤 구조가 의도된 것인지 확인하고 필요한 항목을 일반 파일과 정상 경로로 다시 묶어 주세요.

여러 ZIP을 한 번에 처리할 때

복구할 압축 여러 개를 목록에 추가할 수 있습니다. 각 ZIP은 자기 중앙 디렉터리와 이름 목록을 따로 검사하므로 어느 입력에서 오류가 났는지 파일별로 볼 수 있습니다. 성공한 결과가 둘 이상이면 각각의 복구 ZIP을 바깥 ZIP 하나에 담아 내려받습니다. 따라서 바깥 압축을 풀면 복구된 압축 파일들이 나오고, 그 안에 각 원본의 폴더와 문서가 들어 있습니다. 서로 같은 다운로드 이름이 생길 때에는 뒤에 번호를 붙여 결과를 모두 남깁니다. 바깥 ZIP은 Store 방식으로 묶기 때문에 이미 압축된 결과를 다시 압축해 크기를 줄이려는 용도가 아닙니다. 업무별로 전달 대상을 나눠야 한다면 목록을 나누어 변환하는 편이 결과를 구분하기 쉽습니다.

전달 전에 결과를 검토하는 방법

복구본은 원본을 풀었던 폴더 위에 바로 덮어 풀지 말고 새 빈 폴더에 추출하세요. 미리 보기의 항목 수와 압축 프로그램에 나타나는 항목 수를 비교하고, 최상위 폴더와 몇 단계 아래 폴더의 이름을 각각 확인합니다. 같은 번호로 이어지는 문서나 이름이 비슷한 이미지가 있다면 빠진 항목이 없는지도 살펴보세요. 대표 문서 몇 개를 열어 내용이 읽히는지 확인하면 이름과 본문의 문제를 구분할 수 있습니다. 공유할 때에는 복구한 사본임을 알리고 원본을 별도로 보관합니다. 상대방이 사용하는 환경에서도 이름을 확인한 뒤 원본 삭제 여부를 결정하세요. 변환 완료 표시는 모든 이름의 뜻을 사람이 검토했다는 의미가 아닙니다.

옵션을 바꿔도 같은 이름이 나오는 경우

한글과 일본어 옵션을 바꿨는데 일부 항목의 이름이 그대로인 것은 오류가 아닐 수 있습니다. 해당 항목에 UTF-8 표시가 있거나 유효한 Unicode 이름 필드가 있으면 그 정보가 사용자의 대체 인코딩 선택보다 우선하기 때문입니다. 영문 기본 문자만으로 된 이름도 두 옵션에서 같게 보입니다. 목록의 복구 방식 열을 보면 어떤 규칙이 쓰였는지 구분할 수 있습니다. 반대로 기존에 잘못 해석된 이름이 UTF-8로 다시 저장되어 있다면 그 이름은 형식상 정상 UTF-8이므로 이 도구가 임의로 되돌리지 않습니다. 원래 글자를 찾으려면 이전 단계의 압축이나 발신자가 보관한 폴더 이름이 필요합니다. 결과를 설명할 때에는 한국어 옵션을 골랐다는 사실만 기록하기보다, 어떤 항목이 어느 규칙으로 읽혔는지를 함께 확인하는 것이 좋습니다. 같은 문서를 다시 받을 때 이 정보가 있어야 문제를 재현하기 쉽습니다. 옵션을 비교하는 동안은 원본 ZIP 하나를 기준으로 삼고 새로 내려받은 복구본을 다시 입력하지 마세요.

다른 방법과 출력 선택

원본을 만든 사람이 다시 저장할 수 있다면 Unicode 이름을 명시한 ZIP 사본을 요청하는 방법도 있습니다. 파일을 여러 번 풀었다가 다시 묶기보다, 올바른 이름이 남아 있는 원래 폴더에서 새 압축을 만드는 편이 확인하기 쉽습니다. 전달할 때에는 이름을 확인한 항목 몇 개와 전체 파일 개수를 함께 알려 주면 받는 사람이 다른 환경에서 결과를 대조할 수 있습니다. 특정 압축 프로그램의 모든 버전이나 운영체제에서 같은 결과가 난다고 가정하지 마세요.