Garbled Filenames Inside a ZIP
You extract an archive and the files come out named ¿ù°£º¸°í¼.xlsx or レãƒãƒ¼ãƒˆ.pdf. If the file contents are fine and only the names are wrong, this is recoverable.
Why only the names break
The ZIP format has a flag that records how filenames were written — bit 11 of the general purpose field. When it is set, the names are UTF-8 and any tool anywhere reads them correctly.
The trouble is that older compression tools leave that flag blank. The names then get written using whatever code page the machine happened to use — CP949 on a Korean Windows, CP932 on a Japanese one, CP1252 in Western Europe. On the machine that created the archive everything looks fine, because it reads back with the same code page.
Open that same archive on macOS, Linux, or a Windows set to another region and a different table gets used. So the names only break for the person receiving the file. Nothing was created wrongly — a marker was simply never written, which is why this shows up constantly in files shared by email or chat.
The contents are untouched
The important thing is that names and contents are stored separately. The compressed data itself has nothing to do with text encoding. However mangled the names look, the files inside open perfectly.
You could rename everything by hand, but that stops being realistic past a few dozen files — and you have no way of knowing what the original names actually were.
Fixing it with this tool
Upload the zip itself on the File tab of Mojibake Recovery. There is no need to extract it first.
The names inside are identified and shown as an old name → new name list. If it looks right, download the rebuilt archive. Entries that were already proper UTF-8 are dimmed so you can tell them apart.
The compressed data is never touched. The tool copies each data block verbatim and only rewrites the name in the header. Nothing is decompressed and recompressed, so there is no way for file contents to be damaged, and the whole thing finishes instantly.
Your archive is never uploaded anywhere. Everything runs inside your browser, so internal documents are safe to use here.
One name alone is not enough to go on
The tool joins all the filenames together and identifies them as one block of text. A single name is too short for the statistics to mean anything. An archive containing just a.txt may not be identifiable, but real archives usually hold several files, so this rarely matters in practice.
What cannot be fixed
These three are detected and refused with the reason shown rather than silently producing something wrong.
Encrypted archives — access to the name records is restricted too.
ZIP64 archives — the extended format used for archives above 4GB.
Split archives — anything divided into .z01, .part1 and so on.
RAR and 7z are not supported, only zip. For those formats you can extract and repack as zip, but be aware that already-garbled names get baked in during that step. Where possible, ask whoever created the archive to repack it with UTF-8 names instead.
Creating archives that will not break
Most compression tools have a "store filenames as UTF-8" option. Turn it on for anything you are sending to other people. Modern Windows Explorer and macOS both write UTF-8 by default now, but older tools and older versions do not.
The safest option of all is to keep filenames to plain letters and digits. A–Z carry the same numbers in every encoding table, so they cannot break in the first place. Why that is true is explained in UTF-8 vs the old encodings.