はじめに
2025年現在でのおすすめの zip ファイル形式の圧縮・展開（解凍）ソフトについてまとめました。本記事はファイル名を文字化けせずにやり取りできるかを重視しており、使い勝手や対応形式の多さや機能については評価の対象にしていません（が後半におまけで書いています）。一部を除きフリー（無料）で使えます。Lhaplus のような未だに Shift JIS にしか対応していない古いソフトウェアは非推奨としています。今どき Shift JIS を使う必要はありませんし、Shift JIS では一部の漢字や絵文字などを扱えず、Windows と macOS で対応している Shift JIS の種類に違いがあるため文字化けを避けることができないからです。
🚩 おすすめ圧縮展開ソフト だけを知りたいという方はコチラ
現在では
▶ zip ファイルの中のファイル名の文字コードは Unicode (UTF-8) で構いません
なぜなら OS 標準の zip 機能は（Windows 7 以降の）
▷ Windows も macOS も両方とも UTF-8 ファイル名の展開に対応している
からです。
ただし（一部注意が必要な文字がありますが）
▶ zip ファイルの中のファイル名の文字コードに Shift JIS を使っても構いません
なぜなら OS 標準の zip 機能は
▷ Windows も macOS も両方とも Shift JIS ファイル名の展開に対応している
からです。
注意点として、Windows 10 以前と macOS の標準の zip 機能は、以下で示すように UTF-8 対応が不十分なので、Windows と macOS 間でやりとりするときに OS 標準の zip 機能を使用するのはおすすめしません。
- Windows 10 以前: ファイル名を Shift JIS で格納する（UTF-8 は展開のみ対応）
- Windows 11: ファイル名を UTF-8 で格納し UTF-8 フラグを立てる（完璧！ 👍️）
- macOS 15: ファイル名を UTF-8 で格納するが UTF-8 フラグに非対応（ダメ 👎️）
OS 標準の zip 機能が使えない場合に、どのソフトウェアを使うべきかをまとめたのがこの記事です。とはいうものの、文字化けの仕組みを理解しなければどのソフトウェアを使うべきか判断できないので、文字化けの理屈をきっちりと解説しています。この記事は、巷にあふれる適当な解説記事の間違いを正し、文字化けが発生するメカニズムを解説し、Windows ⇔ macOS 間の文字化け問題のトライ＆エラーをなくすことを目的にしています。なぜか文字化けする、文字化けの原因も直し方もわからない、いろんなソフトを試してみてやっとうまく行った･･･のか？という時代からはおさらばしましょう。
長い本文を読みたくない人向けに結論を書いておくと、文字化け問題は Mac ユーザーが Keka を使えばおそらく全て解決します。なんで Windows ユーザーのために手間を掛けなければいけないんだと思うかもしれませんが、原因のほとんどは macOS 側にあるので kMac ユーザーが手間を掛けるのが筋です。文句は Apple に言ってください。Windows ユーザーが CubeICE を使えば Windows 側で回避できると思いますが、そもそも macOS 標準機能で作る zip ファイルが標準規格に準拠してない（UTF-8 フラグを設定しない）のが問題で、macOS がちゃんと対応していれば文字化け問題は 10 年前には解決していたはずです。Keka は AppStore からだと有料ですが公式サイトからダウンロードすれば無料で使えるようです。CubeICE も無料で使えます。
圧縮・展開ソフトの数が多く検証も面倒なので間違いが含まれている可能性があります。もし間違いを見つけたら教えていただけると助かります。zip ファイルの内部構造の調査には zipdetails コマンドを使うと便利です。macOS では標準インストールされていますが、最新の 4 系だとファイル名のエンコーディングを指定できたりと機能が強化されています。
- 2025-06-29: Lhaplus からの移行のおすすめを 7-Zip から CubeICE に変更しました
- 2025-06-30: Zone ID の伝搬に対応しているソフトウェアの情報を追記しました
-
2025-07-05: 不要ファイル（
_MACOSXなど）の無視機能について追記しました
前提知識
zip ファイルの文字化けの話で頻繁に出てくる Unicode と Shift JIS について簡単に解説します。
Unicode (UTF-8, UTF-16) とは
Unicode とは世界中の文字を扱える文字コードで、最新の Unicode 16.0.0 ではおよそ 15万5千種類の文字を扱えます。UTF-8 や UTF-16 は Unicode をどのような形式で表現するかの違いです。UTF-8（1バイトから4バイトで表現）と UTF-16（2バイトまたは4バイトで表現）で扱える文字に違いはなく、UTF-8 と UTF-16 の表現形式は決まった計算式で相互に変換できます。
Windows と macOS の標準の文字コードは両方とも Unicode です。Windows は 30 年以上前から Unicode です。一般ユーザーに限ったとしても 20 年以上前の XP はすでに Unicode です。macOS の誕生は XP と同じ頃なので Mac ユーザーと同じ頃から Windows ユーザーは Unicode を使っています。もちろん Windows でファイル名に使用している文字コードも Unicode です。Windows がファイル名に Shift JIS を使っているわけないでしょう？ その証拠に Shift JIS では扱えない絵文字を含むファイル名を付けられます。ファイルシステムへの記録は、Windows の NTFS（や USB メモリなどで使う exFAT）は UTF-16 で、macOS の APFS は UTF-8（少し前の HFS+ では UTF-16）と違いがありますが、本記事の内容としては重要な違いではありません。いずれにしろ zip ファイルの中に格納するファイルの文字コードは Unicode の場合は UTF-8 を使うと決まっているからです。
Shift JIS (CP932, MacJapanese) とは
本記事ではわかりやすく Shift JIS と書いていますが、Shift JIS は日本専用の文字コードで、日本以外では使われていません。Shift JIS（またはその国独自の文字コード）は古い文字コードという扱いで、Windows はすでに Unicode に完全移行しています。Shift JIS を使っているユーザーのために Shift JIS にも対応していますが、Windows 自体は Shift JIS に依存しておらず、Shift JIS を使っているのは Windows ではなくユーザーです。
Shift JIS はなにも Windows だけのものではありません。かつての日本語版 Windows 9x 系が Shift JIS を使っていた頃、同じ時代の昔の「Mac OS」は Shift JIS を使っていましたし、現在の macOS も Shift JIS に対応しています。例えば macOS 標準アプリの「テキストエディット」は Shift JIS のファイルを開けます（「オプションを表示」をクリック）。しかも Windows 向け (CP932) と Mac OS 向け (MacJapanese) とどちらでもない（最低限の？）Shift JIS に対応しています。
■ macOS のテキストエディットは Shift JIS 対応
（Mac OS = MacJapanese、Windows, DOS = CP932）
zip ファイルに関しても、macOS は Shift JIS に対応しています。ただし Windows 拡張版の CP932 ではなく、Mac OS 拡張版の MacJapaneseです。つまり古い Mac OS で作成した zip ファイルを展開できるようになっています。zip ファイルの中のファイル名の文字コードは国によって様々な文字コードが使われてきました。様々な文字コードが使われる状況では文字化けしやすいのは当然です。現在では Windows も macOS も Unicode を使っているわけで、あなたに Shift JIS を使う理由がないのであれば、zip ファイルの中のファイル名にも Unicode (UTF-8) を使いましょう。
「Windows は Shift JIS を使うから文字化けする」はウソ
zip ファイルのファイル名が文字化けする原因として、使用している文字コードの違いであり macOS は UTF-8 で、Windows は Shift JIS だからという説が流れていますが、これは Windows や文字コードなどに詳しくない人のよくある間違いです。Windows 自体は Unicode (UTF-16) を使っており、Shift JIS を使う可能性があるのは zip ファイルですが、Windows の話と zip ファイルの話は、別の話です。
zip ファイルの中のファイル名が 適切な UTF-8 ファイル名 の場合、Windows と macOS は両方とも文字化けせずに展開できます。なぜなら Windows と macOS は両方とも UTF-8 ファイル名に対応しているからです。
zip ファイルの中のファイル名が Shift JIS ファイル名の場合、Windows と macOS は、ほとんどの文字を文字化けせずに展開できます。なぜなら（日本語設定の）Windows と macOS は両方とも Shift JIS ファイル名に対応しているからです。
Windows と macOS は両方とも UTF-8 と Shift JIS の両方に対応しています。昔に作成した zip ファイルを展開することを考えれば、片方にしか対応しないよりも両方に対応できるほうが良いですよね？ それなのになぜ文字化けが発生するのでしょうか？ 文字化けが発生する本当の原因は次の 2 点です。
- macOS 標準の zip 機能が 適切な UTF-8 ファイル名で作成しないから（macOS の問題）
- Windows と macOS で対応している Shift JIS の種類が異なり一部の文字が違うから
つまり、Windows は Shift JIS を使うのではなく、macOS で作成した zip ファイルは、文字コードに UTF-8 を使っていると明記されていないから、Windows は OS の設定に従って Shift JIS と判断するしかないということです。UTF-8 を使っていると明記されていれば、ちゃんと UTF-8 を使います。
例えば日本でいきなり「なんで国際共通語（英語？）を使わないんだ！」と言われたら、たとえ10ヵ国語を話せる人でも困りますよね？ 日本で日本語を使うのは日本ではそれが一番通用するからです。マルチリンガルな人 (Windows) に国際共通語 (Unicode) を使って欲しいなら、まず国際共通語で話をしようと事前に言いましょうという話です。最近はもうみんな Unicode を使うようになったと言っても、昔の zip ファイルは Shift JIS を使っているわけで、文字コードを指定しない場合のデフォルトを動作を今すぐ変更するわけにはいきません。Windows がデフォルトを変更できるのは Shift JIS を使うユーザーがいなくなった後です。だからこの記事では Shift JIS にしか対応していない古いソフトウェアを非推奨にして使うのをやめましょうと書いているわけです。もっとも世界中で使われている Windows が、日本だけの状況でデフォルトを変更することはないでしょうし、近い未来に世界のほとんどの地域から古い文字コードが使われなくなるとは到底思えませんが。
文字化けからサヨナラするための基礎知識
zip ファイルのファイル名の文字化けを避けるには、圧縮展開ツールが次の機能に対応しているかを知る必要があります。
- A. Unicode ファイル名に対応しているか？
- B. Unicode ファイル名の正規化機能を持っているか？
- C. Shift JIS に対応しているか？
Unicode ファイル名に対応しているか？
Shift JIS では文字化けを完全に避けることは不可能なので Unicode を使う必要があります。Unicode ファイル名への対応には、次の 3 つの考慮事項があります。
- UTF-8 ファイル名で格納しているか？
- UTF-8 フラグに対応しているか？
- Unicode パス拡張フィールドに対応しているか？
1 は中途半端な対応で、zip ファイルに格納するファイル名の文字コードに UTF-8 を使用しますが、UTF-8 を使用しているという情報を記録しません。ファイル名自体は（たまたま）UTF-8 で格納されているというだけで、どの文字コードを使用しているかという情報がなく、文字コードを推測するしかないため文字化けを起こす可能性があります。この方法は現在の macOS（執筆時点の最新版は macOS 15）が使用しており、macOS で作成した zip ファイルが Windows で文字化けする原因となっています。
2 はファイル名を UTF-8 で格納したうえで、UTF-8 フラグ（general purpose bit flag の 11 ビット目）を設定する方法で、つまり 1 に加え UTF-8 フラグを設定するということです。これは ISO/IEC の zip の標準規格 (ISO/IEC 21320–1:2015) で標準化されている推奨される方法です。UTF-8 フラグが設定されていればファイル名の文字コードは UTF-8 です。UTF-8 フラグへは Windows 7（パッチが必要）以降で対応しているため展開時に文字化けしません。macOS は UTF-8 フラグに対応していないようですが、zip ファイルのファイル名の文字コードを UTF-8 と判断できる限り文字化けしません。
3 は Unicode ファイル名に対応するもう一つの方法で、Unicode パス拡張フィールド (Info-ZIP Unicode Path Extra Field) に Unicode パスを格納する方法です。つまり通常の Shift JIS のパスに加えて Unicode のパスを格納します。展開側が Shift JIS にしか対応していない場合でも、Unicode にしか対応していない場合でも、どちらでも文字化けしないというメリットがありますが、文字化けを避けるには Shift JIS で扱える範囲の文字しか使えません（通常は Shift JIS と Unicode で同じファイル名にするため）。互換性は高い反面、完全な Unicode 対応ができない方法です。ちなみに Info-ZIP は Linux や macOS で使われているオープンソース版 zip コマンドの開発元なので、Unicode パス拡張フィールドは Info-ZIP による拡張機能ということなのでしょう。
まとめると、zip ファイルに記録するファイル名の文字コードを Unicode にする方法は次の 2 つです。通常は前者の方法を使います。後者では全ての Unicode 文字に対応できません。
- ファイル名を UTF-8 で記録し、UTF-8 フラグを設定する（通常の方法)
- ファイル名を Shift JIS で記録し、追加で Unicode パスを持たせる（互換向け）
参考: UTF-8 フラグと Unicode パス拡張フィールド の情報
- 本家 PKWARE の zip 形式の仕様 (APPNOTE) 一覧
- UTF-8 フラグ: APPNOTE 6.3.0 (2006-09-26) 以降に記載
- Unicode パス拡張フィールド: APPNOTE 6.3.2 (2007-09-28) 以降に記載
- ISO/IEC 21320–1:2015: APPNOTE 6.3.3 (2012-09-01) ベース
- 米国議会図書館による zip 形式についての仕様のまとめ
Unicode ファイル名の正規化機能を持っているか？
これは見た目には文字化けしているように見えないので厳密には文字化けの話ではありません。文字化けしていない（ようにみえる）のに何故かファイルを参照できないという問題の話です。
Unicode では、例えば「ガ」を 1 文字で表現するか、「カ」と「゛」の 2 文字で表現するか、2 つの表現方法があります。（フォントによりますが）「ガ」と「カ゛」の 2 つは見た目に違いがわかりません。一部のソフトウェアは zip ファイルに圧縮または展開するときに、「ガ」に統一するか「カ゛」に統一するかの機能を持っていることがあります。 前者を NFC 正規化といい、後者を NFD 正規化と言います。
Windows や Linux や その他の多くの OS では正規化を行わないので、入力したままの文字（一般的には「ガ」）が使われます。しかし困ったことに macOS では一般的にファイル名は NFD に正規化され、標準の zip 機能も NFD で正規されたファイル名で格納します。macOS ではファイル名が正規化されていてもされていなくても同じように参照できるようになっているので困らないのですが、そのような OS は他にはなく、ファイルの参照で問題が発生する場合があります。
これはファイル名の食い違いの問題で、文字としては NFC と NFD のどちらが正しいというわけではないのですが、macOS の問題は入力した時の文字とは違う文字にファイル名を変更することです。どちらも文字としては正しいので正規化を行わないソフトが一般的ですが、macOS の特殊な仕様に対応しているソフトでは、NFC に正規化する機能を持っています。もし圧縮ソフト自体に対応していない場合、別のソフトウェアを使って変換できます。詳細はこの記事の「ファイル名の NFC ⇔ NFD 変換ツール」を参照してください
Shift JIS ファイル名に対応しているか？
新しく作成する zip ファイルに Shift JIS を使う理由はありませんが、古い zip ファイルで Shift JIS が使われている場合があります。また相手が Windows 10 以前で圧縮したり、Unicode に対応していない古い圧縮ソフトを使っている場合もあるでしょう。そういう場合に Shift JIS にも対応していることは文字化けを起こさないために重要です。
Shift JIS は Windows と macOS で違いがあります。Windows の Shift JIS は正式には CP932 という名前で、macOS の Shift JIS は MacJapanese という名前です。Windows と macOS はどちらも標準の zip 機能は Shift JIS のファイル名に対応しているのですが、対応している Shift JIS の種類に違いがあるため、Windows で作成した zip ファイルの中のファイル名の ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ という文字が、macOS で展開すると ㈰ ㈪ ㈫ ㈬ ㈭ ㈮ ㈯ ㉀ ㈷ ㉂ ㈹ に文字化けすることがあります。そういう問題があるため Unicode を使いましょうということになるわけです。
おすすめ圧縮展開ソフト
「ファイル名」の列にある [OSS] は、オープンソースという意味です。「UTF-8 圧縮」と「UTF-8 展開」の列はそれぞれ Unicode ファイル名に対応しているかを示しています。
- ✅️ ･･･ UTF-8 ファイル名で格納（UTF-8 フラグ 対応）
- ☑️ ･･･ Shift JIS で表現できないものだけ UTF-8 ファイル名で格納（UTF-8 フラグ 対応）
- ⚠️ ･･･ UTF-8 ファイル名で格納（UTF-8 フラグ 非対応）
「Shift JISファイル名」の列は、Windows (CP932) に対応している場合は 🅆️、macOS (MacJapanese) に対応している場合は 🄼 と書いています。両方に対している場合は、展開時にどちらで解釈するかを選択できます。取り消し線のソフトウェアは非推奨です（私の主観）。Unicode (UTF-8) に対応していないものは非推奨として扱います。
macOS 用
注意: Unicode 正規化は圧縮時の話です。
| ソフト名 | UTF-8 圧縮 |
UTF-8 展開 |
Unicode パス 拡張フィールド |
Unicode 正規化 圧縮 |
Shift JIS ファイル名 |
|---|---|---|---|---|---|
| macOS 15 | ⚠️ | ⚠️ | 参照のみ | NFD 固定 | 展開のみ 🄼 |
| Keka 1.2.54 [OSS?] | ✅️ | ✅️ | 参照のみ | NFC 固定 | 展開のみ 🅆️ 🄼 |
| The Unarchiver 4.3.9 | - | ✅️ | 参照のみ | - | 展開のみ 🅆️ 🄼 |
| PeaZip 10.5.0 [OSS] | ✅️ | ✅️ | 参照のみ | なし | 非対応 |
| ソフト名（以下は非推奨） | UTF-8 圧縮 |
UTF-8 展開 |
Unicode パス 拡張フィールド |
Unicode 正規化 圧縮 |
Shift JIS ファイル名 |
| ❌️ | - | 非対応 | - | 対応 🅆️ | |
| ❌️ | ❓️ | 非対応 | - | 対応 🅆️ | |
| ❌️ | ❌️ | 非対応 | - | 対応 🅆️ |
補足
- The Unarchiver はその名の通り展開専用で圧縮機能を持たない
- PeaZip は文字コードの指定ができるが、macOS 版は機能しない？
- MacWinZipper (WinArchiver) は無料版での検証。展開機能は有料版のみなので未検証
- ZIPANG は AppStore 版は削除。FULL 版は「プライバシーとセキュリティ」から実行許可が必要
macOS 用まとめ
macOS 標準機能は UTF-8 フラグに対応していない、必ず NFD 正規化が行われる、Shift JIS の展開は MacJapanese にしか対応していない、という点から Windows とのやり取りに適していません。Windows とのやり取りには Keka が適しています。展開のみが必要であれば The Unarchiver でも良いでしょう。
もしどうしてもファイル名の文字コードに Shift JIS を使った zip ファイルを作成したい場合は、DTP Zipper、MacWinZipper、ZIPANG を使うことになりますが、Windows 側はすでに UTF-8 ファイル名に対応しているため通常は必要にならないはずです。相手（Windows 側）が Shift JIS にしか対応していない Lhaplus などを使っており、変更してもらえない場合の最終手段です。ちなみに Shift JIS には正規化という概念がなく、ファイル名に Shift JIS を使った場合は NFC 正規化に近い変換が行われますが、ZIPANG では一旦 NFKD 正規化が行われているのか、例えば「㍉」が「ミリ」に変換されます。DTP Zipper ではどういう基準なのかわかりませんが「㍉」は扱えない文字の可能性があるとしてエラーになります。したがって MacWinZipper を使うのが良さそうなのですが、なんか zip のヘッダがおかしいようなんですよね......
$ zipdetails archive.zip
︙
WARNING!
Zip local header not found.
Skipping 0x0 bytes to Central Directory...
︙
WARNINGS
* Expected Zip header not found at offset 0xAE, skipped 0x0 bytes
Done
Windows 用
注意: Unicode 正規化は展開時の話です。追加の「macOS 標準 zip」は macOS 標準の zip 機能で作成したファイルを文字化けせずに展開できるかです。
| ソフト名 | UTF-8 圧縮 |
UTF-8 展開 |
Unicode パス 拡張フィールド |
Unicode 正規化 展開 |
Shift JIS ファイル名 |
macOS 標準 zip |
|---|---|---|---|---|---|---|
| Windows 7 + パッチ | ❌️ | ✅️ | 参照のみ | なし | 対応 🅆️ | ❌️ |
| Windows 8 / 8.1 | ❌️ | ✅️ | 参照のみ | なし | 対応 🅆️ | ❌️ |
| Windows 10 22H2 | ⚠️ | ✅️ | 参照のみ | なし | 対応 🅆️ | ❌️ |
| Windows 11 24H2 | ✅️ | ✅️ | 参照のみ | なし | 展開 🅆️ | ❌️ |
| 7-Zip 24.09 [OSS] | ✅️ | ✅️ | 格納 参照 | なし | 対応 🅆️ | ✅️ |
| PeaZip 10.5.0 [OSS] | ✅️ | ✅️ | 格納 参照 | なし | 対応 🅆️ | ✅️ |
| CubeICE 3.5.1 [OSS] | ✅️ | ✅️ | 格納 参照 | NFC 固定 | 対応 🅆️ | ✅️ |
| WinRar 7.11 [有料] | ✅️ | ✅️ | 格納 参照 | NFC 固定 | 対応 🅆️ | ✅️ |
| WinZip 76.9 [有料] | ✅️ | ✅️ | 格納 参照 | なし | 対応 🅆️ | ✅️ |
| Bandizip 7.38 | ✅️ | ✅️ | 格納 参照 | なし | 対応 🅆️ | ✅️ |
| Explzh 9.78 [商用有料] | ✅️ | ✅️ | 格納 参照 | NFC 対応 | 対応 🅆️ | ✅️ |
| LhaForge 2.0.0 [OSS] | ✅️ | ✅️ | 非対応 | なし | 展開 🅆️ | ❌️ |
| lhaz 2.6.1 [有料] | ☑️ | ✅️ | 非対応 | なし | 対応 🅆️ | ❌️ |
| lhaz+ 3.6.1 [有料] | ☑️ | ✅️ | 非対応 | なし | 対応 🅆️ | ❌️ |
| ソフト名（以下は非推奨） | UTF-8 圧縮 |
UTF-8 展開 |
Unicode パス 拡張フィールド |
Unicode 正規化 展開 |
Shift JIS ファイル名 |
macOS 標準 zip |
| ❌️ | ❌️ | 非対応 | - | 対応 🅆️ | ❌️ | |
| ❌️ | ❌️ | 非対応 | - | 対応 🅆️ | ❌️ | |
| - | ❌️ | 非対応 | - | 展開 🅆️ | ❌️ | |
| - | ❌️ | 非対応 | - | 展開 🅆️ | ❌️ |
補足: 圧縮時にファイル名の文字コードを UTF-8 にする場合
- Windows 10: 「ワールドワイド言語サポートでUnicode UTF-8を使用」をチェック
- Shift JIS を使う古いアプリなどの動作に影響が出る場合があるので注意
- 7zip: 「パラメーター」に
cu=onを指定する - CubeICE: 「ファイル名を UTF-8 に変換する」をチェック
- Explzh: 「2バイト文字ファイル名を UTF-8 にエンコーディングする」をチェック
補足: Windows 7 のパッチとは KB2704299 のことです。
Windows 用 まとめ
Windows 標準の zip 機能は、正しい UTF-8 ファイル名（UTF-8 フラグが設定、または Unicode パス拡張フィールドの設定）であれば問題なく展開できたのですが、macOS 標準機能で作成した zip ファイルは、正しい UTF-8 ファイル名ではないので文字化けしてしまいます。他のソフトで文字化けしないのは、おそらく別の情報を参照しており、zip ファイルの情報に作成 OS が「Unix」と記録されていれば UTF-8 だろうと推測しているようです。現在の macOS や Linux を含む Unix 系 OS の多くは UTF-8 を使用していますが、以前は日本では EUC-JP をよく使用していました。macOS で作成した zip ファイルは確かに文字化けしませんが、文字化けを起こさない完璧な方法というわけではありません。
Windows 11 では zip ファイルの中のファイル名に UTF-8 を使うようになったことに注意してください。Shift JIS ファイル名は格納されないので、Shift JIS ファイル名にしか対応していない古いソフトウェアは、今後文字化けするようになるでしょう。なぜ Windows は 長らく UTF-8 ファイル名での圧縮に対応していなかったかと言うと、おそらく互換性が理由です。UTF-8 ファイル名での展開ができない Windows XP、Vista、パッチなしの 7 が使われている状態で UTF-8 ファイル名を格納してしまったら古い Windows で文字化けしてしまいます。さすがに今は非対応の古い Windows はほとんど使われていない（Windows 7 のサポート終了は 2020年1月14日、ESU は 2023 年）はずなので、Windows 11 でようやく解禁できたと言ったところでしょう。
展開時にファイル名の Unicode 正規化をして欲しい場合には、CubeICE、Explzh、WinRar が選択肢になります。無料で商用利用したい場合には CubeICE が良いでしょう。macOS で Keka を使って圧縮している場合には圧縮時点で NFC 正規化が行われるため、展開時の正規化機能は必須というわけではありません。またファイル名の正規化は別のツールで行うこともできます。このようなツールを使うと、少し手間ですが、圧縮ソフトに依存せず zip ファイル以外の圧縮形式にも対応できるので、選択肢と応用範囲が広がります。
Bandizip には macOS 版もありますが有料で試用もできないため、評価していません。WinZip と WinRar は有料なので、最低限の機能で十分なら選ぶ理由はないでしょう。
Lhaplus、+Lhaca、MacWinZipper、ZIPANG などが非推奨の理由
これらのソフトが非推奨の理由を改めて明記すると、Shift JIS にしか対応していないからです。Shift JIS を使っている人がいる限り文字化け問題はなくなりません。また後述しますがパスワードや Zone ID の伝搬に関しても脆弱です。これらのソフトが将来バージョンアップして Unicode 対応に作り変えられたとしたら話は別ですが、メンテナンスもほとんどされていないようで、2025 年現在では使ってはなりません。
古い記事の焼き直しなのか何なのか知りませんが、いつまでも Lhaplus を定番ソフトだとか言ってオススメにあげているのはどうかしています。特に Lhaplus は非推奨であると念を押しておきます。Lhaplus は現在最新の 1.74 でさえ脆弱性があり危険であることが知られていますが、脆弱性があることよりも 2017 年から放置されているという事実のほうが問題です。メンテナンスされていないようなものを人に薦めてはいけません。実際の利用に関しても Lhaplus は文字化けを起こすという問題があります。Lhaplus（Shift JIS にしか対応してないソフト）を使っている人だけが文字化けし、その人のためだけに対応しなければならないとしたら、周りの人にとっても迷惑です。
Lhaplus からの乗り換えでは CubeICE をオススメします。使い方がシンプルで Lhaplus でできることはほぼ全てできます。エクスプローラ型が好みの人は 7-Zip が良いでしょう。ライセンスやその他の様々な考慮事項の問題もありません。
ファイル名の NFC ⇔ NFD 変換ツール
展開した後でファイル名を正規化したい場合には次のようなツールを使用します。一般的には NFC に正規化（例: 「ガ」）するとよいですが、macOS では NFD に正規化（例: 「カ゛」）されたファイル名を使うのが一般的です。特にファイルシステムに APFS ではなく古い HFS+ を使用している場合、ファイルシステムの機能ですべて NFD に正規化されます。macOS ではファイル名が NFC に正規化されていても NFD に正規化されていても同じように扱えるような仕組みがありますが、Windows や Linux など他の OS にはそのような仕組みはありません。
GUI 用
GUI から NFC ⇔ NFD 変換を行いたい場合、次の BandiNamer が利用できます。Windows 版と macOS 版の両方が提供されています。使い方は直感的なので迷うことはないでしょう。
CLI 用
CLI コマンドに慣れている人は convmv コマンドを使うとよいでしょう。標準的なパッケージ管理システムからインストールできるはずです。カレントディレクトリ以下のすべてのファイルを NFC に正規化する場合は次のようにします。
$ convmv -r -f utf8 -t utf8 --nfc .
$ convmv -r -f utf8 -t utf8 --nfc --notest .
本来はファイル名の文字コードを変換するためのツールであるためか、NFC ⇔ NFD だけを行う場合でも utf-8 を 2 回指定しなければならないのが面倒なところです。詳細はドキュメントを参照してください。
おまけ: zip ファイルに関するセキュリティ
本記事のテーマは文字化けですが、より安全な zip ファイルの使い方を広めるためにおまけで、zip ファイルに関するセキュリティ機能について解説します。
パスワードについて
zip ファイルのパスワードには、使用する暗号化方式として「古くて脆弱で使ってはならない ZipCrypto 方式」と「AES 方式」の 2 つがあります。ZipCrypto は使ってはならないものなので使ってはいけませんが、古いソフトウェアは ZipCrypto にしか対応していない場合があります。そのようなソフトウェアではパスワード機能を使ってはいけません。AES にはビットが違うものがいくつかあり大きいほうがより安全ですが、AES-256bit が一般的です。
- ZipCrypto（別名: Zip 2.0 互換、Legacy encryption、ZIP レガシー暗号化 など）
- AES (128bit / 192bi / 256bit)
macOS の標準機能でパスワードを設定する方法として zipcloak コマンドや zip コマンドの -e オプションが紹介されることがありますが、zipcloak も zip -e も ZipCrypto 方式なので使ってはいけません。なお古い macOS は ZipCrypto にしか対応しておらず、Windows も ZipCrypto の展開にしか対応していません。したがってパスワード付き zip ファイルを扱う場合には AES に対応したソフトウェアを使う必要があるでしょう。
補足ですが、ISO/IEC 21320–1:2015 では zip ファイルのパスワード（暗号化機能）は禁止 (prohibited) されています。もしかしたらこれが、Windows や macOS の標準機能でパスワードの設定が実装されていない理由かもしれません。
Zone ID の伝搬について
Zone ID は zip ファイルそのもののセキュリティ機能ではなく Windows の機能です。zip ファイルに限りませんが、インターネットからダウンロードしたファイルというのはセキュリティ上のリスク（マルウェアなど）があります。Windows はファイルの入手元がインターネットからなのか手元で作ったのかなどを区別する機能 (MOTW: Mark of the Web) を持っており、どこから入手したかを Zone ID としてファイルの代替データストリーム（いわゆる拡張属性）に記録します。代替データストリームは NTFS の機能なので、USB メモリなどで使われる exFAT では機能しません。また Zone ID は Windows XP SP2 以降で実装されました。
インターネットから（ブラウザで）ダウンロードした zip ファイルには Zone ID が付加されますが、zip ファイルの中のファイルには関係ありません。セキュリティという点から言えば、zip ファイルを展開して得られたファイルも同じようにインターネットから入手したものとして扱われるべきです。つまり zip ファイルに付加された Zone ID を展開したファイルにコピーする機能が「Zone ID の伝搬」です。Zone ID 自体は XP SP2 で実装されましたが、Zone ID の伝搬が行われるようになったのは Vista からです。
Zone ID の伝搬は展開時に行う処理なので、（OS 標準の zip 機能ではなく）別のソフトウェアで展開した場合は、そのソフトウェアが Zone ID の伝搬機能を搭載している必要があります。次の対応セキュリティ機能の比較では Zone ID の伝搬機能を持っているかも記載しています。なおファイルの Zone ID の確認は次のようにします。ファイルのプロパティからも確認でき、（Zone ID によるセキュリティ機能が逆に困るという場合に）Zone ID の削除もそこからできます。
C:\temp> dir /r file.zip
︙
2025/06/30 20:08 1,759,193 file.zip
168 file.zip:Zone.Identifier:$DATA
︙
C:\temp> more < file.zip:Zone.Identifier
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://www.post.japanpost.jp/zipcode/dl/roman-zip.html
HostUrl=https://www.post.japanpost.jp/zipcode/dl/roman/KEN_ALL_ROME.zip
補足: ZoneId の意味
- 0：ローカルマシン
- 1：イントラネット
- 2：信頼済みサイト
- 3：インターネット
- 4：制限付きサイト
上記の出力では ZoneId の他に ReferrerUrl と HostUrl が記録されており、見てわかるようにどこから何をダウンロードしたのかバレバレです。これはトラブルシューティングの助けとなる可能性がある一方で、プライバシー上のリスクにもつながるため、ソフトによってはおそらく意図的に ZoneId 以外を伝搬していない場合があります。
対応セキュリティ機能の比較
パスワードに対応している各ソフトが、どの暗号方式に対応しているかの比較です。知らないうちに脆弱なパスワードが使われてはいけないという意味で、ここでは 安全なパスワード設定ができない（AES非対応の） OS 以外のソフトウェアを非推奨にしています。また Windows 用のソフトウェアは Zone ID の伝搬機能を持っているかも記載しています。
- ✅️ ･･･ 圧縮と展開に両対応
- ☑️ ･･･ 展開のみ対応
- ❌️ ･･･ 非対応
MacOS 用
| ソフト名 | ZipCrypto･脆弱 | AES（○: 展開のみ ◉: 圧縮･展開） |
|---|---|---|
| macOS 15 | ☑️ | ☑️ ○128bit ○192bit ○256bit |
| Keka | ✅️ | ✅️ ○128bit ○192bit ◉256bit |
| The Unarchiver | ✅️ | ✅️ ○128bit ○192bit ◉256bit |
| PeaZip | ✅️ | ✅️ ○128bit ○192bit ◉256bit |
| ソフト名（以下は非推奨） | ZipCrypto･脆弱 | AES（○: 展開のみ、◉: 圧縮･展開） |
| ✅️ | ❌️ 128bit 192bit 256bit | |
| ✅️ | ❌️ 128bit 192bit 256bit |
Windows 用
- ZoneIDの伝搬: ✅️ ･･･ 対応（ソフトによっては有効に設定する必要あり）
| ソフト名 | ZipCrypto･脆弱 | AES（○: 展開のみ ◉: 圧縮･展開） | ZoneIDの伝搬 |
|---|---|---|---|
| Windows XP（参考） | ✅️ | ❌️ 128bit 192bit 256bit | ❌️ |
| Windows 11（Vista以降） | ☑️ | ❌️ 128bit 192bit 256bit | ✅️ |
| 7-Zip | ✅️ | ✅️ ○128bit ○192bit ◉256bit | ✅️ |
| PeaZip | ✅️ | ✅️ ○128bit ○192bit ◉256bit | ✅️ |
| CubeICE | ✅️ | ✅️ ◉128bit ◉192bit ◉256bit | ✅️ |
| WinRar | ✅️ | ✅️ ○128bit ○192bit ◉256bit | ✅️ |
| WinZip | ✅️ | ✅️ ◉128bit ○192bit ◉256bit | ✅️ |
| Bandizip | ✅️ | ✅️ ○128bit ○192bit ◉256bit | ✅️ |
| Explzh | ✅️ | ✅️ ◉128bit ○192bit ◉256bit | ✅️ |
| LhaForge | ☑️ | ✅️ ○128bit ○192bit ◉256bit | ❌️ |
| ソフト名（以下は非推奨） | ZipCrypto･脆弱 | AES（○: 展開のみ ◉: 圧縮･展開） | ZoneIDの伝搬 |
| ✅️ | ☑️ ○128bit ○192bit ○256bit | ✅️ | |
| ✅️ | ☑️ ○128bit ○192bit ○256bit | ❌️ | |
| ✅️ | ❌️ 128bit 192bit 256bit | ❌️ | |
| ☑️ | ❌️ 128bit 192bit 256bit | ❌️ | |
| ☑️ | ❌️ 128bit 192bit 256bit | ❌️ |
補足
- 7-Zip: ZoneID の伝搬はデフォルトでは無効です
- CubeICE: ZoneID の伝搬時に ReferrerUrl と HostUrl を伝搬しない
- WinZIP: ZoneID の伝搬時に ReferrerUrl がローカルになり、HostUrl を伝搬しない
- Bandizip: セキュリティ上のリスクがある特定のファイルのみ伝搬する（参照）
- Explzh: ZoneID の伝搬時に ReferrerUrl と HostUrl を伝搬しない
安全なパスワードの長さは15桁以上？
補足として安全なパスワードの長さですが、脆弱な ZipCrypto ではどれだけパスワードを長くしても安全ではありません。AES を使っていれば、十分な長さがあれば（今のところは）安全だと思いますが、4 桁のパスワードなど言語道断でパスワードを設定していないのと同じです。8文字以下は危険と考えたほうが良いでしょう。
内閣サイバーセキュリティセンター (NISC) では以前は 15 桁以上を推奨していた（参考）ようですが、最新版では推奨の桁数が削除されているようです。おそらくコンピュータ性能の向上や効率的な攻撃手段の発見などで 15 桁なら安全と保証できなくなったのでしょう。
何文字以上なら安全と断言することはできませんが、NISC が（以前に）言っていたということを理由に、AES で数字や記号を織り交ぜて 15 桁以上にするのが良いのではないでしょうか？ ファミコン版ドラゴンクエスト2 のパスワード（ふっかつのじゅもん）の最大が 52 文字なので大した長さではありませんね？
パスワードのかかった zip の中身を不正に見る方法
zip ファイルのパスワードを解析するツールはいくつもあります。有名なのは John the Ripper と Hashcat でしょうか。どちらも無料で使えます。コマンドラインから使うので使い方は少々難しいですが、GPGPU による並列処理を行うことで、高速にパスワードを見つけ出すことができます。
有料を含めると初心者でも簡単にパスワードを解析できるツールはいくつもあります。Google で検索すると簡単に見つけられます。
これらを使えば、6 文字程度のパスワードは数時間程度以内で見つけ出せます。4 文字なんて一瞬です。数年後にはさらに短い時間で見つけられるようになるでしょう。zip ファイルのパスワードを見つけるのは、専門家じゃなくても誰でも簡単にできます。みんなじゃんじゃんトライして遊んでみましょう！（不正を推奨しているわけではなく、不正は簡単にできるという話を広めるのが目的です）
おまけ: 不要ファイルの無視機能
Windows では zip ファイルの中に desktop.ini や Thumbs.db、macOS では .DS_Store や _MACOSX を格納することがあります。これらはそれぞれ次のような役目を持っています。
- Windows
-
desktop.ini: フォルダのアイコンや表示設定を保存するファイル -
Thumbs.db: 画像や動画のサムネイル（縮小画像）をキャッシュするファイル
-
- macOS
-
.DS_Store: Finderでの表示位置や並び順などの設定を保存するファイル -
._*: 拡張属性に対応していないファイルシステムで拡張属性の保存に使うファイル -
_MACOSX: 拡張属性を保存するフォルダ（zip ファイル内のみ）
-
通常これらは、現在のコンピュータ上で意味があるもので、他のコンピュータでは役に立ちません。基本的に無視して構わないものですが、zip ファイルの中に含まれているとウザく感じるものです。一部の圧縮・展開ソフトウェアの中には、圧縮時にこれらのファイルを含めずに圧縮したり、また展開時にこれらのファイルを無視して展開する機能を持っています。各ソフトウェアが何に対応しているかは今回の調査に含めませんでしたが、いくつか簡単に書いておきます。
予備知識として macOS の _MACOSX ですが、これは拡張属性を保存する zip ファイルの中に作成されるディレクトリです。拡張属性は APFS（や古い HFS+）ファイルシステムが持っている機能で本来はファイルの属性として記録されています。拡張属性の例はテキストファイルのエンコーディング情報 (com.apple.TextEncoding) です。しかし zip ファイルでは拡張属性をそのまま記録できないため、_MACOSX ディレクトリの中に AppleDouble 形式（._* ファイルと同じ形式）でファイルに保存します。拡張属性は macOS 上では意味があるため不用意に削除すると困る可能性がありますが、Windows など他の OS では意味がないため、単に無視（削除）して構いません。
macOS での Keka は「Macのリソースフォークを含めない」というチェックを有効にすることで .DS_Store や _MACOSX を zip ファイルの中に保存しないようになります。このリソースフォークというのは少々誤解を招く言葉で、元々のリソースフォークは macOS 以前の Classic Mac OS で使われていた機能です。macOS ではリソースフォークは原則として使用されず、互換性などの目的で必要な場合は拡張属性の一つ (com.apple.ResourceFork) として扱われます。.DS_Store は Desktop Services Store の略でリソースフォークではありません。ですが、Keka は _MACOSX ディレクトリや .DS_Store ファイルを含めないという機能を（現在の所）「Macのリソースフォークを含めない」という風に表現しています。なおここでは別の表現に変更するべきと提案されており、また正確には .localized, ._*, .FBC*, .Spotlight-V100, .Trash, .Trashes, .background, .TemporaryItems, .fseventsd, .com.apple.timemachine.*, .VolumeIcon.icns を無視するようです。
Windows での CubeICE は指定したファイルを無視するフィルタリング機能を持っており、カスタマイズ可能ですがデフォルトで desktop.ini、Thumbs.db、.DS_Store、_MACOSX が無視されるように設定されています。
さいごに
zip ファイルは Unicode (UTF-8) が誕生する前から使われており、ファイル名に使用する文字コードにはさまざまなものが使われていたため、文字化け問題は避けられないものでした。現在では Unicode (UTF-8) に統一することで、文字化け問題を避けられるようになっていますが、OS 標準の zip 機能で Unicode (UTF-8) に十分対応できていると言えるのは今のところ Windows 11 だけです。それでも正しい UTF-8 ファイル名でなければ展開できませんし、macOS の NFD 問題に注意が必要です。
この記事では zip ファイルのみに焦点をあてていましたが、Windows と macOS の両方でその他の圧縮形式にも対応してきているので、zip ファイルにこだわる必要はないかもしれません。例えば 7-Zip などが対応している 7z 形式は最初から Unicode を使う仕様となっています。文字化け問題は少なくなるとは思いますが、それでも macOS の NFD 問題が残っています。
macOS の NFD 問題は本当に厄介で、これを楽に解決しようとすると、macOS で zip ファイルを作成するときには、macOS 標準の zip 機能は使わずに Keka を使いましょうというのが、現時点で最も良い方法に思えます。macOS 側で Keka を使っていれば Windows 側は何を使っても構いません。もちろん非推奨の Shift JIS にしか対応していないものは除きます。
一つこれから起こるであろうことを予言しておくと、未だに Lhaplus、+Lhaca、Lhasa などの Windows 用の古いソフトを使っている人は、Windows 11 の普及と共に文字化けするようになるでしょう。皆が望んだ Shift JIS 切り捨ての始まりです（ヒント: 本記事でおすすめしているソフトの多くは lzh ファイルの圧縮展開に対応しています）。というか、いい加減 Shift JIS 使うのやめましょうよ。皆が Shift JIS を使い続けるからいつまでも Shift JIS が無くならないんですよ。Windows は 30 年前に Unicode に移行したというのに･･･