Fix broken Korean filenames in a ZIP

How to use it

1. Add the ZIP archive and choose Korean EUC-KR / CP949 or Japanese Shift_JIS as the fallback encoding.
2. Select Preview filenames and compare the original and proposed names, including the folders and any entries kept as raw bytes.
3. Convert the reviewed archive, then download the repaired ZIP and inspect its contents before passing the copy to someone else.

About the formats

A ZIP contains a local header near each file and a central directory describing all entries. Filename bytes appear in both places. General-purpose bit 11 identifies UTF-8; an Info-ZIP Unicode Path field can supply a Unicode name when its checksum matches the original name bytes. Archives without either signal do not identify their legacy code page reliably. Choosing EUC-KR or Shift_JIS supplies that missing interpretation for names which contain non-ASCII bytes. A valid UTF-8 flag takes priority, so an already correct name such as café.txt is never run through Korean fallback decoding. An invalid Unicode path checksum is ignored instead of being trusted.

Frequently asked questions

Can every garbled filename be recovered?

Recovery depends on the bytes still stored in the archive. If another application already replaced the name with question marks or saved incorrectly decoded text, the original spelling may no longer be present. A successful decoding is also not proof that you chose the right language; inspect the proposed names before converting.

Does repairing names change file contents?

The repair process retains the compressed payload of each accepted entry. It rewrites filename metadata and offsets, removes stale Unicode name fields and normalizes data descriptors into headers where needed. The resulting archive therefore has different bytes as a whole even though the stored file payloads are preserved. Per-entry comments are also re-encoded with the filename flag when readable.

How do Japanese filenames work?

Select Japanese Shift_JIS before reading the archive. Existing UTF-8 and verified Unicode path names still take priority; only names needing fallback decoding use Shift_JIS. Changing this setting clears the old preview so that you can review the new interpretation.

What happens when two names would become identical?

The archive is rejected rather than silently losing an entry. The check includes case differences, Unicode normalization and conflicts between a file and a folder path. Rename the conflicting source entries in an archive application, then select the revised local ZIP here.

Are password-protected archives or ZIP64 supported?

Encrypted entries and ZIP64 are explicitly rejected. This version accepts ordinary single-volume ZIP archives using Store or Deflate, with up to 10,000 entries, a 16 MB central directory and 256 MB of expanded contents. Device-specific input size limits also apply.

Will this fix text inside a document or subtitle?

This utility changes archive names, not text encoding inside an extracted file. A correctly named document can still contain unreadable text for a separate reason. Open a representative extracted file to distinguish a filename problem from a content problem.

Start with the original archive

Keep the ZIP you received and repair a separate copy. Repeatedly extracting and recompressing a damaged-looking archive can replace useful filename bytes with the wrong visible spelling. Select the original ZIP directly, review its list, and compare several names whose spelling you know. Check nested folders as well as the first few files; a readable top-level folder alone does not establish the encoding of every entry.

Understand names kept as raw bytes

When fallback decoding fails, HanOpen keeps the original filename bytes and leaves that entry unmarked as UTF-8. The preview explicitly labels this condition. Other entries can still have recoverable names, but the undecodable ones may continue to look different across archive applications. Keep the source available and ask the sender for the intended spelling instead of treating the raw-byte label as a completed repair.

Large archives and validation

The reader starts with the archive tail and central directory using file slices. During conversion, it streams compressed entries through a CRC and size check and assembles the result from the original compressed slices. It does not allocate one expanded buffer for the whole archive. A synthetic 101 MB archive completed this path in local automated verification with no full-file ArrayBuffer read; that observation is not a speed or memory guarantee for your device.

Check the downloaded result

Extract the repaired copy into a new empty folder. Compare the item count with the preview, inspect names at multiple folder depths and open a few representative documents or images. CRC checks detect damaged payloads; they do not verify that filenames are linguistically correct or that a document’s content is accurate. For several input archives, the download button packages their separate repaired results into an outer ZIP, retaining duplicate result names by adding a number.

Other options

If the program that created the archive is available, another practical route is to make a new ZIP with explicit Unicode filenames there. Ask the sender to retain meaningful folder names and check the new archive before sharing it. HanOpen’s recovery view is useful when the legacy filename bytes remain intact and you need to produce a portable local copy.