はじめに

Mac と Windows 間で zip ファイルをやり取りしたとき、日本語ファイル名が文字化けすることがあります。その理由について「Mac は Unicode 対応だが Windows はいつまでも古い Shift JIS を使い続けているから」と、Windows 側の問題であるかのように書いてあるページがありますが全く持って違います。Windows は 30 年以上前に Unicode へ完全移行しており、10 年以上前から zip ファイルの UTF-8 ファイル名対応を進めており、ユーザーが困らないようにほぼ完璧なタイミングで UTF-8 ファイル名対応を完了させました。世界では Shift JIS 以外にさまざま文字コードが使われてきました。Shift JIS は日本語専用の文字コードなので日本以外では使われていません。Windows は Shift JIS を使っているのではなく、ユーザーが Shift JIS も使えるようにしており、そして zip ファイルの中のファイル名が「UTF-8 でも世界中の以前の文字コードでも問題ない」ように両方に対応しました。今まで通りこれからもどちらでも使えます。常識で考えてください。世界中から「昔に作った zip ファイル」が消えるわけがないでしょう？ UTF-8 と Shift JIS は両対応できることなのに Shift JIS を切り捨てるわけないじゃないですか。互換性を重視している Windows はさすがです。

結論から言うと、文字化けの問題は Mac が悪いんですよ。特に Mac で作った zip ファイルが Windows で文字化けする問題は 100% Mac が原因です。文字化けの原因は Mac が「UTF-8 ファイル名の標準規格に準拠した zip ファイルを作らない」からです。zip ファイルの中には 30 年前に作成した古いファイルもあるはずですが、Mac はそのようなことを考慮しておらず UTF-8 のファイル名にしか対応していません。Mac 標準の zip 機能は Mac で使うことしか考慮しておらず、古い zip ファイルを切り捨てている上「ISO/IEC が定める zip ファイルの標準規格」にも準拠していません。Windows と zip ファイルのやり取りするときに Mac 標準の zip 機能を使うのはやめましょう。これは Mac の問題です。Windows 側の対応は完了したので、これ以上は Mac が修正されないかぎり文字化け問題は解決しません。Mac の問題が修正されるまで、Mac ユーザーは正しい知識を学んで、Windows ユーザーに迷惑をかけないように心がけてください。

Mac にはもう一つ濁点・半濁点が含まれるファイル名を変な文字に勝手に書き換えるという（zip ファイルに関連しているが）別の問題があります。これは UNIX の標準規格では認められていない動作で macOS が UNIX に準拠してない点の一つです。これは Mac そのものの問題なので、Mac だけを使っていても発生します。どう対応するのが正しいかはファイルを作った Mac ユーザーにしかわからないことなので完全な対応は Mac ユーザーにしかできません。しかしファイル名の書き換えは Mac が勝手にやってるので平均的な Mac ユーザーは問題箇所を見つけるのが困難で対応するのは難しいでしょう。注意深く作業する以外に解決方法はないのでどうしようもありません。諦めてファイル名に濁点や半濁点を使わないようにするほうが簡単です。文句は Mac に言ってください。全部標準規格に準拠していない Mac が悪いんです（はぁ）。

技術者の間では zip ファイルにある通称「UTF-8 フラグ」の存在は知られてきているようですが、普通の Windows ユーザーや Mac ユーザーの間ではそれほど知られていないようです。この記事では少なくとも UTF-8 フラグというものが存在することを知ってください。UTF-8 フラグに触れずに Windows や Shift JIS のせいにするようなページは読むだけ無駄です。UTF-8 フラグ = 文字化けを防ぐ機能、Shift JIS = 互換性のために必要な文字コード、macOS 標準の zip 機能は UTF-8 フラグを無視するから文字化けするが要点です。

関連記事

文字化けの原因はMacが正しいUTF-8のzipを作らないから（＋Shift JIS非対応）

文字化けする原因が Mac にあることを簡単にまとめます。予備知識として Windows が標準で使用している文字コードは Unicode であり、必要な場合に互換性のために「言語設定の文字コード」（古いアプリで使われていた文字コード、日本語設定では Shift JIS）にわざわざ変換しているということを知っておいてください。

Mac で作成した zip が Windows で文字化けする理由

macOS 15 で作成した zip（標準規格に準拠せずにファイル名に UTF-8 を使っている）
- 👉️ zip ファイルのファイル名の文字コードが判断できない
  - Win: 言語設定の文字コードと解釈するため文字化けする
  - Mac: たまたま一致してるので文字化けしない

Windows 11 で作成した zip ファイルが Windows と Mac で文字化けしない理由

Windows 11 で作成した zip（💯 標準規格に準拠した UTF-8 ファイル名）
- 👉️ zip ファイルのファイル名の文字コードが UTF-8 だと判断できる❤️
  - Win: 以前のバージョンから標準規格に準拠してるので文字化けしない✌🏻
  - Mac: たまたま一致してるので文字化けしない

Windows 10 以前で作成した zip が Mac で文字化けする理由

Windows 10 以前で作成した zip（言語設定の文字コードにファイル名を変換）
- 👉️ zipファイルのファイル名の文字コードが判断できない
  - Win: 言語設定の文字コードと解釈するため文字化けしない（互換機能）
  - Mac: UTF-8 にしか対応してないので文字化けする
- 補足: Windows 10 1803 以降なら UTF-8 も利用可
  「ワールドワイド言語サポートでUnicode UTF-8を使用」の有効が必要

結論: Macが「💯 標準規格に準拠した UTF-8 ファイル名」を使っていれば、今頃は文字化けなんて起きなくなっていた！

4.4.4 (general purpose bit flag)

Bit 0, bits 4 to 10 and 12 to 15, shall not be set.

Bit 11 should be set. If the value of any byte in the file name or file comment is greater than 0x7F, bit 11 shall be set.

If bit 11 is set, the file names and comment fields for the document container file shall be Unicode strings encoded using the UTF-8 encoding scheme as specified in ISO/IEC 10646:2014, Annex D.

各OSのUTF-8ファイル名の対応状況

Windows と macOS の zip ファイル名の Unicode (UTF-8) 対応状況について簡単にまとめます。Windows は圧縮時と解凍時とで UTF-8 ファイル名への対応のタイミングが異なることに注意してください。対応のタイミングが違うのは文字化けが発生してユーザーが困ることがないようにするためです。UTF-8 フラグとは zip ファイル形式の仕様で、UTF-8 ファイル名が使われていることを示すフラグです。UTF-8 フラグに対応していないものは、UTF-8 ファイル名に完全対応しているとは言えません。

OS	圧縮 (UTF-8 flag)	解凍 (UTF-8 flag)	補足
Windows XP	非対応	非対応
Windows Vista	非対応	非対応
Windows 7	非対応	✅️ 完全対応 (yes)	2012年のパッチが必要
Windows 8/8.1	非対応	✅️ 完全対応 (yes)
Windows 10	⚠️ 準対応 (no)	✅️ 完全対応 (yes)	1803 以降、設定変更が必要
Windows 11	✅️ 完全対応 (yes)	✅️ 完全対応 (yes)	圧縮の対応は 24H2 以降？
macOS 15	⚠️ 準対応 (no)	⚠️ 準対応 (no)

ここからわかるように、Windows は 2012 年より解凍で UTF-8 ファイル名に対応し、（制限有りながら）Windows 10 1803 以降でファイル名に UTF-8 を使って圧縮できるようになり、Windows 11（こちらのコメントより 24H2 以降？）で標準規格に準拠した UTF-8 ファイル名に完全対応しました。

一方で macOS はファイル名に UTF-8 を使いながらも標準規格に準拠しておらず（UTF-8 フラグに非対応）、未だに不完全な zip ファイルしか作れません。だから Windows で文字化けします。

WindowsはmacOSより先にUnicode対応

zip ファイルではなく OS の話です。Windows の標準文字コードは Unicode です。ファイル名の文字コードにも Unicode を使っています。Windows が Shift JIS を使っていると勘違いしている人は、Windows のことを知らないか、25 年前（2000年）ぐらいで知識が止まっているのでしょう。 Windows は Unicode をメインで使っており、互換性のために古い文字コード（日本語設定では Shift JIS）も扱えますが、Shift JIS には依存していません。ちなみに昔は Windows だけではなく Mac も Shift JIS を使っていました。Mac が Shift JIS を独自に拡張して㈰㈪㈫㈬㈭㈮㈯㉀㈷㉂とかいう文字化けを問題を引き起こした MacJapanese とかいうやつのことです。2000 年より前からの古い Mac ユーザーならそのことをよく知っていることでしょう。

Windows が Unicode を使うようになったのは 1993 年、現在の Windows へと続く NT 系が誕生したときからです。もっとも NT 系は当初はビジネス向けで、一般ユーザーの多くが NT 系を使い出したのは 2001 年の Windows XP からです。Apple 独自の Mac OS の開発継続を断念し、Unix ベースの macOS に置き換えたのと同じ時期です。一般ユーザーだけに限ったとしても、Mac も Windows も同じぐらいから Unicode を標準的に使っています。ファイル名に Unicode を使えるのかを確認するのは簡単です。Unicode でしか使えないような絵文字をファイル名に使えるか調べればいいのです。（♡などの一部を除いて）ファイル名に絵文字が使えれば、それは Unicode ということです。

Mac の古参の熱狂的なファンなら、Mac が Macintosh と呼ばれており OS が Unix ベースになる前の Apple 独自の MacOS のときから使っていたことでしょう。その頃の Mac はとても不安定で一日に何度も爆弾マーク（システムエラー）が表示されて強制リセットしなければならなかったことを覚えているはずです。その頃の Windows も一般ユーザーの多くは Windows 95、いわゆる 9x 系が使われており Mac ほどではありませんが不安定でした。しかし Windows 9x 系は MS-DOS から起動する必要がなくなり、完全なプリエンプティブマルチタスク OS で仮想メモリ対応も完璧な 32ビット OS だったので、当時の Mac の OS よりも優れていました。MS-DOS の時代から 9x 系で使われていたのが Shift JIS です。Windows のファイル名が Shift JIS というのは、そういうインターネット老人会に片足を2本突っ込んでいるような人が話す、遠い昔の話です。今も Windows のファイル名が Shift JIS とか言っているのであれば、それは単に知らないだけです。2000 年頃から知識がアップデートされていないということです。

じゃあなんで最近も Shift JIS がどうとか言われてるのかというと、あのさぁ、OS のファイルの文字コードと、zip ファイルの中に格納されているファイルの文字コードの区別ぐらいつけましょうよ。べーつ、それは別の話ですから。zip ファイルの中に文字コードを Unicode から Shift JIS に変換して格納したからって、Windows が今も Shift JIS を使っていることにはならないでしょうが。Windows はわざわざ Unicode から変換してるの。ユーザーが困らないように互換性のために。

古い zip はいつまで対応するべきか？

Mac は互換性を切り捨てる

有名な話だと思いますが macOS は、すぐに古い Mac を切り捨てます。macOS は直近の 3 バージョンぐらいまでしかサポート（セキュリティ問題の修正など）をしないので、2025 年現在、2021年の macOS 12 Monterey はもうサポート終了しています。macOS はアップデートし続けなければいけませんが、アップデートするたびに古い Mac を切り捨てます。切り捨てられた Mac は macOS をアップデートできないので、安全に使うには Mac を書い直さなければならなくなります。

Windows はパソコンに付属しており、さらに無償でバージョンアップできます。私は未だに自作 PC を使っているので Windows は買いましたが、でも一体いつ買ったんだろう？ Windows 7 ぐらいからな気がするので 15 年ぐらいお金を払わずに Windows を使い続けている気がします。Mac の買い替えに比べればほとんど無料みたいなものですね。これから無料でアップデートできないときなんて来るんでしょうかね？これからもずっと Windows を無料で使える気がします。

さて Mac が互換性をすぐに切り捨てるのとは反対に、Windows は互換性を非常に大事にします。あなたが人生で一番最初に zip ファイルを作ったのはいつでしょうか？ なんでこんな質問をしたのかと言うと、zip ファイルは最近作ったものだけが解凍できればいいってもんじゃないってことです。30 年前（1995年）に作った zip ファイルを解凍するかもしれないじゃないですか？古い zip なんて不要、ゴミだから捨ててしまえっていうのが、互換性を大事にしない考え方です。

だーれも、ずっと Shift JIS を使い続けろなんて話はしてませんよ？ Windows は素晴らしいです。Unicode に完全移行したのに、Shift JIS を使いたい人は Shift JIS を使えるからです。OS も Unicode と Shift JIS の両対応ですし、zip ファイルも Unicode と Shift JIS の両対応を実現しました。でも Shift JIS を使い続けないでください。Windows はユーザーのことを思って Shift JIS に対応し続けていますが、みなさんは Unicode に移行しましょう。Windows は Unicode に完全対応です。

それにしても互換性を重視している Windows 11 のほうが、zip ファイルの UTF-8ファイル名対応が優れてるってすごいことすよね。過去を切り捨てて Unicode に１本化したはずの macOS はまだ標準規格に準拠できていません。まあ zip ファイルに関して言えば 2000 年よりも前の Mac の世界ではほとんど使われていなかったようなので、切り捨てる過去はなかったかもしれませんが。でも昔の Mac は Shift JIS (MacJapanese) を使っていたわけで古い macOS は Shift JIS にも対応していた？みたいな情報もあるのですが、切り捨てたんでしょうかね。Mac の世界には古い zip ファイルが存在しないから対応するのは UTF-8 だけでいいやと思っているのでしょうが、Mac の外の世界には古い zip ファイルが存在するんですよ。

適切に事を進めれば互換性と進化は両立できます。現に Unix という古い OS は、互換性と進化を両立させてきました。互換性を切り捨てなければ進化できないという考えは甘えです。ねぇ、なんで互換性を保つ必要がないのに Mac は、いつまでも標準規格に準拠できてないの？ UTF-8フラグ立てるだけだよ？ 10 年ぐらい前にはできてたはずだよね？

Windowsは互換性を大事にする

Windowsは互換性を大事にする OS です。最先端 OS の一つとして Unicode に完全対応しながらも、過去のプログラムを実行できたり過去の zip ファイルを問題なく扱えるように、世界中で以前に使われていた過去の文字コード（日本語設定では Shift JIS）にも両対応しています。全てではありませんが、30 年前の Windows 95 用アプリも動くはずです。日本語用の Windows 95 用アプリは Shift JIS を使うので Shift JIS への対応機能が必要です。さて 1995 年頃の Mac 用アプリは今動くのでしょうか？ macOS になる前で CPU は PowerPC でしたね。そういや Intel Mac 用のアプリ、いつ動かなくなるんでしたっけ？

データに関してはもっと長い寿命が必要です。アプリケーションは新しいバージョンや別のものに乗り換えればよいですが、自分が作成した zip ファイルに代わりは無いからです。おそらくまだ何十年もファイル名が Shift JIS で記録されている zip ファイルを扱える必要があるでしょう。Windows 10 までは OS の標準機能も、ファイル名を Shift JIS で記録していました。なぜなら UTF-8ファイル名に対応している Windows のサポート期間が終わっていなかったからです。Windows 11 に乗り換えていない人は、今もファイル名が Shift JIS の zip ファイルを作っています。

OS	リリース	サポート終了（延長サポート）	解凍機能
Windows XP	2001-10-25	2009-04-14 (2014-04-08)	UTF-8 非対応
Windows Vista	2007-01-30	2012-04-10 (2017-04-11)	UTF-8 非対応
Windows 7	2009-10-22	2015-01-13 (2020-01-14)	✅️ UTF-8 対応
Windows 8	2012-10-26	2016-01-09 (2016-01-12)	✅️ UTF-8 対応
Windows 8.1	2013-10-17	2018-01-09 (2023-01-10)	✅️ UTF-8 対応
Windows 10	2015-07-29	2020-10-13 (2025-10-14)	✅️ UTF-8 対応
Windows 11	2021-10-05		✅️ UTF-8 対応

上記の一覧を見るとわかるように、zip ファイルの解凍機能が zip ファイルのUTF-8ファイル名に対応したのは Windows 7（2012年の修正パッチが必要）からです。しかし修正パッチを当てていない人がいるかも知しないので、Windows 7 は zipファイルの中のUTF-8ファイル名を扱えない可能性があります。延長サポートを含めれば Windows 7 は 2020年1月14日までの長いサポートがあったわけで、Windows の標準機能としては Windows 7 のサポート期間が終了するまでは、UTF-8ファイル名を zip ファイルの中に格納するわけにはいかなかったのでしょう。

そして古い Windows のサポートがようやく終了して、サポート切れの古い Windows を使っているような人もいなくなったであろうこのタイミング（Windows 11 24H2？）でやっと UTF-8ファイル名を使う zip ファイルの作成機能を皆に提供したわけです。UTF-8ファイル名を使っていれば、パッチありの Windows 7 以降で文字化けしませんし、未だに UTF-8ファイル名の標準規格に対応していない Mac でも文字化けしなくなります。さあみなさん、Windows 11 にアップデートするのです！

なんで Windows XP のときから UTF-8 ファイル名に対応しなかったの？と思うかもしれませんが、UTF-8 ファイル名の仕様が登場したのが 2006 年だからです。総合的に考えると 2008 年まで UTF-8 ファイル名の仕様が固まっていなかった可能性があり、ISO/IEC で標準規格になったのは 2015 年です。それを考えると 2012 年に対応した Windows は十分に早いということになります。Mac は 2025 年時点でまだ対応してませんから。

文字化けを防ぐためのソフト

Mac → Windows のための神ソフト Keka

macOS の標準の zip 機能は使い物になりません。そこで Mac から Windows へ zip ファイルを渡すときによく使われている神ソフトが Keka です。Apple Store からインストールするときは有料ですが、自分でダウンロードしてインストールすれば無料で使えます。無料で使えますが便利だと思ったらチップを贈って開発者を助けてあげましょう。

Keka を使って作成した zip ファイルは Windows で文字化けしないんです。不思議に思いませんか？ Keka はファイル名に UTF-8 を使用しているのに Widows で文字化けしないんですよ？

はい、ここで「Windows は Shift JIS だよ」派は途端に苦しくなってしまいました。Windows が Shift JIS というのなら、なぜファイル名に UTF-8 を使用している Keka で作成した zip ファイルは文字化けしないんでしょうか？

ここまでちゃんと読んでいる人はおわかりですね。zip ファイルの標準規格に準拠した正しい UTF-8 ファイル名（UTF-8 フラグ）なら Windows で文字化けしないんです。Windows は Unicode を使う OS で、Windows はバッチリと zip ファイルの UTF-8 ファイル名に対応しているんだから文字化けしません。

Shift JIS って何の話ですか？いい加減、適当な話をするのはやめてください。

Keka は他にも不要なファイル _MACOSX や .DS_Store を入れない機能もあるので便利です。まあこのファイルは Windows にとってはゴミファイルなので無視すればいいだけなんですが、macOS のためにこんなことを知らなきゃいけないわけです。

Windows → Mac のための The Unarchiver

Windows 10 以前の Windows では zip ファイルのファイル名に（日本語設定の場合は）Shift JISを使っていました。これは仕方ないんですよ。みんなが新しい Windows に乗り換えないからです。Windows 7（パッチなし）は UTF-8 ファイル名を使う zip ファイルを正しく解凍できないので、Shift JIS を使うしかありません。Windows 7 などの古い Windows が使われなくなるまで、UTF-8ファイル名の zip を作成するのは延期しなければなりませんでした。

素晴らしいことに Windows では zip ファイルは Shift JIS と UTF-8 の両対応です。UTF-8 フラグが設定されていなければ、Shift JIS として扱い、UTF-8 フラグが設定されていれば UTF-8 として扱います。完璧ですね。しかし macOS は UTF-8 フラグが設定されていてもいなくても UTF-8 として扱います。なんのための UTF-8 フラグだと思っているのでしょうか？

macOS の標準の zip 機能が使い物にならないので、Windows から貰った zip ファイルを解凍するときに使うのが、The Unarchiver です。解凍専用ですが解凍するときに UTF-8 以外の文字コードを考慮してくれますし、文字コードを指定できるので問題なく解凍できるようになります。

なお、Windows 11（24H2以降？）で作成した zip ファイルであれば The Unarchiver は不要です。Windows 11 では標準規格に準拠した UTF-8 ファイル名（UTF-8フラグ）を使う正しい zip ファイルを作成するので、macOS 側が UTF-8 フラグを無視していてもファイル名自体は UTF-8 なので一応問題なく解凍できます。Windows 10 のサポート終了は2025年10月14日もうすぐです。無料で Windows 11 に乗り換えましょう。

Windows 側で対処する場合の 7-Zip

本来は Mac ユーザーが、標準規格に準拠した zip ファイルを作らなければいけません。しかし、Mac ユーザーが詳しい人とは限らず、macOS 標準機能で作った zip ファイルを送ってくるかもしれません。macOS 標準機能で作った zip ファイルには UTF-8 フラグがありません。だからどの文字コードを使っているのか知るすべがありません。UTF-8 フラグが付いていないものは、互換性を大切にしている Windows では Shift JIS として扱います。さあどうするか。

一つは、Windows 10 (1803) で追加された「ワールドワイド言語サポートでUnicode UTF-8を使用」を有効にすることです。有効にすると互換性のための過去の古い文字コード（日本語設定では Shift JIS）の代わりに UTF-8 を標準で使うようになります。つまり Windows は Unicode (UTF-16) を標準の文字コードとして使い、Unicode (UTF-8) を同時に使う OS に変化するということです。もちろんその代わり Shift JIS 対応機能が失われて古いアプリなどが動きづらくなります。互換能力が下がることになりますが、もしあなたが Shift JIS なんてもういらねーと、Windows に Shift JIS の対応をやめて欲しいと思うのであれば、今すぐ UTF-8 を使用するように設定し、周りの人にも設定変更を依頼するとよいでしょう。今や Windows が Shift JISを使うかどうかは、あなたや周りの人が決めることなのです。

世の中から古い文字コードを使っている zip ファイルなどが消えて無くならない限り、「ワールドワイド言語サポートでUnicode UTF-8を使用」にメリットはほとんどありません。UTF-8 対応アプリは別にこの設定を有効にしなくても作れるからです。例えば エクセルの CSV ファイルやメモ帳なんか UTF-8 に対応しているでしょう？運が良ければ Shift JIS 専用アプリを Unicode 対応アプリとして使えるようになるかもしれませんが、まずないでしょう。他の国のあまり複雑ではない別の文字コードを使うアプリケーションが使えるようになる可能性はあるかもしれませんが。

ということで、Mac ユーザーが文字化けする zip ファイルを送ってきたりしたら、7-Zip を使いましょう。7-Zip は UTF-8フラグが付いていない場合に、もし zip ファイルが Unix 系 OS で作成されたものなら（zip ファイルにはどの OS で作成されたかが記録されています）、文字コードは UTF-8 だろうと解釈する機能を持っています。Unix 系 OS だからといって必ずしも UTF-8 を使っているとは限らず、昔の日本は EUC-JP が使われていたのですが、今なら UTF-8 と解釈しても問題ないと判断したのでしょう。

7-Zip は zip ファイルを作成するときにも使えます。macOS は互換性を考慮してないので古い zip ファイルは扱えません。UTF-8 ファイル名にしか対応していませんが、7-Zip を使えば Windows 10 以前でも、標準規格に準拠した UTF-8 ファイル名の zip ファイルを作れます（パラメータの設定に cu=on と書く必要がある）。ですが Windows 10 のサポート終了は2025年10月14日もうすぐです。無料で Windows 11 に乗り換えましょう。

しかし、7-Zip では、macOS のもう一つの大きな問題「濁点・半濁点が含まれるファイル名を変な文字に勝手に書き換える」には対応できません。これは zip ファイルを作成する側、macOS 側の問題なので対応できないのです。

大迷惑‼️ Macは濁点を勝手に書き換える⁉️

ここまで文字化け問題の解決策を説明しましたが、それでは完全に解決できない問題があります。macOS は「ガ」みたいな濁点や半濁点を、見た目には気づかれないように「カ」と「゛」の2文字に勝手に置き換えるんです。実は 2 文字なんですが、1 文字に見えるように表示するので、見た目には気づきません。この問題については、「誤解の多い「NFD問題とUTF-8-MAC問題」を解説する - macOSの濁点を含むファイル名の扱い」で詳しく解説しています。

この問題は zip ファイルでも発生しますが、macOS の OS 機能なので、zip ファイル以外でも発生します。根本的な解決方法はありません。macOS は Unix ベースなどと言われますが、本来の Unix はこんな事しません。なんでこんな仕様なのかと言うと、元々 Unix ベースになる前の 2000 年以前の MacOS の設計を引き継いだものだからです。Unix の仕様にはない Mac オリジナルの独自仕様で UNIX の標準規格にも準拠していません。ダメダメなニオイがプンプンしてきますよね。

どういうときに文字化けするのかというと、Finderからファイル名をコピーしたときです。Finder に表示されているファイル名は全て「カ゛」みたいになっているからです。また Windows から送られてきた zip ファイルを解凍すると、元のファイル名が「ガ」でも全部「カ゛」みたいに勝手に変換されます。

macOS でもテキストファイルなんかに書いている文字は「ガ」なんですよ。ファイル名に使うと勝手に書き換えるんですよ。そのファイル名をコピーして使うと「カ゛」に変わるんですよ。そうするとテキストファイルの中に「ガ」と「カ゛」がいりじまっってしまうわけですよ。

macOS ではファイル名が「ガ」でも「カ゛」でも同じファイルとみなすので、ファイル名が食い違っていても一応動きますが、Windows だけじゃなくて Linux や他の Unix 系 OS なんかでは別の文字なので別のファイルと見なされます。ほんと、macOS の仕様で大迷惑です。

なお Keka は「カ゛」のようなものを「ガ」に修正してくれるので、だから Mac ユーザーは Mac 標準の zip 機能を使わないで Kake を使いましょう。どうしても Windows 側で対応しなければならないのであれば、WSL から convmv コマンドで修正する法がありますが、ここでは使い方は割愛します。検索すれば見つかります。

ただし一律で「カ゛」を「ガ」に置き換えて問題ないかという話は別です。ファイル名は「ガ」になりますが、テキストファイルなどに書かれた文字はそのままだからです。もし某デザインソフトの中の画像ファイルへのリンク先が「カ゛.png」になっていたとして、ファイル名の方を「ガ.png」に書き換えて、はたして問題ないのでしょうか？だからこの問題は勝手にファイル名を変更する Mac が悪くて、勝手にファイル名を変換する Mac の問題をどうにかしないと根本的な問題解決にはならないのです。Keka がやっている一律に変換する機能は、「まあ、だいじょうぶだろ？」というもので問題が発生する可能性はゼロではありません。

技術者向け: UTF-8フラグと調査方法

はい、ではここからはもう少し真面目に詳細に、技術者向けに追加情報を解説することにします。

まずこの記事で雑に UTF-8 フラグと言っていたのは、正確には「General Purpose Flag」の Bit 11 の「Language encoding flag (EFS)」のことです。zip のファイル形式の仕様は zip のオリジナルの開発社である PKWARE が公開しています。Language encoding flag の初出は 6.3.0（2006年9月）で、2006 年に定義されたと書かれていることが多いのですが、6.3.2（2007年9月）以降から現在の最新の 6.3.10（2022年11月）までのドキュメントでは、6.3.2 で公開されたことに改められています。

https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.0.TXT (2006-09)
https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.2.TXT (2007-09)
https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT (2012-09)
https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.10.TXT (2022-11)

謎の略語 EFS は Early Feature Specification らしいので、最新の 6.3.10 に至るまで、仕様は完全に定義されているわけではないと考えるべきなのかもしれません。私は詳しく読んでいませんが読めばなにかわかるかもしれません。

If the version of this file is marked as a NOTIFICATION OF CHANGE,
the content defines an Early Feature Specification (EFS) change
to the .ZIP file format that may be subject to modification prior
to publication of the Final Feature Specification (FFS). This
document may also contain information on Planned Feature
Specifications (PFS) defining recognized future extensions.

このドキュメントは zip ファイル形式のドキュメントであり PKWARE がリリースするソフトウェアのバージョンと対応しているとは限らないようです。Linux や macOS などで私達が使用している zip コマンドは PKWARE のものではなく、Info-ZIP と呼ばれるオープンソース実装版で、2008年7月にリリースされた 3.0 で Unicode (UTF-8) filename がサポートされています。

Windows のリリース日と突き合わせると、Windows Vista (2007-01) と Windows 7 (2009-10-22) の間ということになります。Vista のシェアが少なかったことを考えると、2012年5月に Windows 7 向けの KB2704299 で展開機能のみ対応させたのは、Windows 8 のリリース日 2012年10月を考慮するとタイミング的には概ね適切であると判断できると思います。

zip の標準規格というのは 2015年4月に ISO/IEC で策定された ISO/IEC 21320-1 "Document Container File — Part 1: Core" のことです。価格は 0 と書いてあるのでおそらく登録するだけで入手できると思いますが、米国議会図書館のサイトの Document Container File: Core (based on ZIP 6.3.3) より標準規格は https://standards.iso.org/ittf/PubliclyAvailableStandards/c060101_ISO_IEC_21320-1_2015.zip からダウンロードできると書かれているので、これが同じものなんだと思います。ここから 6.3.3 (2012-09) が標準規格のベースとなっていることがわかったわけですが、ますます Windows が UTF-8フラグに対応したタイミングは非常に適切であるとわかります。

UTF-8 フラグが設定されているかどうか調べるには zipdetails コマンドを使うのが一番手っ取り早いでしょう。Ubuntu （Windows の WSL 含む）でも Homebrew からでもインストールできました。UTF-8 フラグはファイル毎などで設定されているので、以下のようなものが複数見つかると思います。

0006 General Purpose Flag  0800
     [Bit 11]              1 'Language Encoding'

理解に非常に苦しむことは、macOS に標準インストールされている zip コマンドや unzip コマンドは、どうやら UTF-8 対応を含む文字コード変換機能が削除されているようだということです。--unicode (-UN) オプションとか使えません。バージョン番号は同じなんですけどねぇ。GUI はともかくコマンドライン版から削除する意味って何よ？ macOS 標準の zip 機能は、CLI コマンドですら使い物にならないので、Homebrew でまともな zip / unzip コマンドをインストールしてください。

Homebrew の zip コマンドと unzip コマンド

$ zip --help
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
Zip 3.0 (July 5th 2008). Usage:
  ︙  省略

$ unzip --help
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Usage: unzip [-Z] [-opts[modifiers]] file[.zip] [list] [-x xlist] [-d exdir]
  Default action is to extract files in list, except those in xlist, to exdir;
  file[.zip] may be a wildcard.  -Z => ZipInfo mode ("unzip -Z" for usage).

  -p  extract files to pipe, no messages     -l  list files (short format)
  -f  freshen existing files, create none    -t  test compressed archive data
  -u  update files, create if necessary      -z  display archive comment only
  -v  list verbosely/show version info       -T  timestamp archive to latest
  -x  exclude files that follow (in xlist)   -d  extract files into exdir
modifiers:
  -n  never overwrite existing files         -q  quiet mode (-qq => quieter)
  -o  overwrite files WITHOUT prompting      -a  auto-convert any text files
  -j  junk paths (do not make directories)   -aa treat ALL files as text
  -U  use escapes for all non-ASCII Unicode  -UU ignore any Unicode fields
  -C  match filenames case-insensitively     -L  make (some) names lowercase
  -X  restore UID/GID info                   -V  retain VMS version numbers
  -K  keep setuid/setgid/tacky permissions   -M  pipe through "more" pager
  -O CHARSET  specify a character encoding for DOS, Windows and OS/2 archives 👈️標準版には
  -I CHARSET  specify a character encoding for UNIX and other archives        👈️これがない

See "unzip -hh" or unzip.txt for more help.  Examples:
  unzip data1 -x joe   => extract all files except joe from zipfile data1.zip
  unzip -p foo | more  => send contents of foo.zip via pipe into program more
  unzip -fo foo ReadMe => quietly replace existing ReadMe if archive file newer

つまり、macOS 標準の zip コマンドを使って作成した zip ファイルは UTF-8 フラグがつかない ということです。それもあってか、macOS で作成した zip ファイルは、macOS標準の unzip コマンドの -l オプションでこんな感じで文字化けします。もうアホかと。だから macOS の zip 機能はちゃんと作られてないんですよ。

macOS 標準機能で作った zip は mac標準の unzip で文字化けする

$ unzip -l テスト.zip
Archive:  テスト.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  06-14-2025 19:21   �??�?��??/
        0  06-14-2025 19:21   �??�?��??/�??�?��??.txt
---------                     -------
        0                     2 files

まあ表示上文字化けしているだけで、ファイル名の文字コードはしてるので、展開に問題はなさそうではありますが、まあダサいですよね。

さいごに

Windows は標準の文字コードとして Unicode (UTF-16) を採用しています。Shift JIS には依存しておらず、Shift JIS への対応は必要なユーザーのために互換機能です。

Windows の zip ファイルのファイル名の対応は正しいものです。ユーザーが困ることのないように段階的に UTF-8 ファイル名への対応が進められました。zip ファイルの標準規格にも準拠しています。以前の文字コード（日本語設定では Shift JIS）を使うのは古い Windows を使っている人が困ることのないようにするためで、昔に作成した zip ファイルを扱うことを考えれば、以前の文字コードへの対応は互換性のためにこれからも必要です。

Mac は昔に作った zip ファイルを扱うことを想定していません。Mac の zip ファイルは標準規格に準拠していないので Windows で文字化けします。

zip ファイルの UTF-8 ファイル名が完璧になった Windows 11 で作成した zip ファイルは macOS で文字化けしません。その反対に Mac で作成する zip ファイルは標準規格に準拠してないので Windows で文字化けします。Mac がこの問題を修正しない限り、Mac は周りに迷惑をかけ続けます。Mac ユーザーは、zip ファイルを別の人に渡すなら必ず Keka を使いましょう。受け取った zip ファイルが文字化けするなら The Unarchiver を使いましょう。Windows ユーザーは 7-Zip でだいたい対応できますが、濁点問題には完全な解決方法はありません。

macOS 26 Tahoe、大幅に変わるようですが、この問題、修正されるんでしょうかね。また古い Mac が切り捨てられるようですが。