FfFilenameFixer
← すべての記事

Macのzip文字化け・濁点分離を防いでWindowsに送る方法

Macで作ったzipがWindowsで文字化けする、具体的には「請求書_ガイド.xlsx」の「ガ」が「カ゛」のように濁点が分離して見える、韓国語の「한글」が「ㅎㅏㄴㄱㅡㄹ」にばらける、あるいは見た目は正しいのにExcelが「ファイルが見つかりません」と言う。こうした場合、zipファイル自体は壊れていません。原因はMac側の2つの癖です。macOSはアクセント付き文字や日本語・韓国語のファイル名を、Windowsが想定していない分解形式のUnicode（NFD）で保存することが多いこと。そしてFinderの「圧縮」コマンドが、隠しフォルダ __MACOSX と各ファイルの ._ コピーを勝手に追加することです。送る側での対処は、圧縮する前にファイル名を合成形式（NFC）に揃え、そのうえでMacのメタデータを含めないツールでzipを作る、という順番です。この記事ではその手順と、すでに送ってしまった後の直し方をまとめます。

Macで作ったzipがWindowsで文字化けする原因

実は別々の3つの現象が混ざっています。自分がどれに当たっているかを先に見分けると早いです。

分解された文字（NFD）。 macOSは昔からファイル名をNFDで書く傾向があります。NFDでは「ガ」は「カ」と結合文字の「゛」の2文字として、「é」は「e」と結合アクセントとして、韓国語の1音節は個々の字母（ジャモ）として保存されます。一方、WindowsやほとんどのWebサーバー、Windows用アプリは合成形式（NFC）、つまり「ガ」が1文字として表現される形を前提にしています。Windowsのエクスプローラーはたいてい見た目を正しく描画しますが、名前の中身は入力したものと技術的に別物です。だから相手の画面には 請求書_ガイド.xlsx と表示されているのに、マクロやスクリプト、SharePointのリンクがNFC表記で探すと「見つからない」という事態が起きます。日本語の濁点・半濁点や韓国語の場合はもっと目に見える形で崩れ、「パ」が「ハ゜」のように分離します。

__MACOSX フォルダと ._ ファイル。 Finderで右クリックして「圧縮」を選ぶと、macOSはリソースフォークやFinderのメタデータを __MACOSX フォルダ内の ._ファイル名 として一緒に詰め込みます。Windowsにとっては無用なものです。害はありませんが、ファイル数が倍になり、「._ 付きの壊れたファイルが入っている」と誤解されたり、一部のアップロードフォームで弾かれたりします。

正規化ではなく文字コードの問題。 名前が José のようになったり、「?????」や意味不明な記号の羅列になったりする場合は別の問題です。Windows側の解凍ソフトが名前を違う文字コードで読んでいます。最近のWindowsエクスプローラーや7-Zipは、現行macOSが書き出すUTF-8のzip名を正しく扱えるので、これは主にかなり古い解凍ソフトで起きます。この記事はこちらは扱いません。NFDと余計なフォルダの話です。

Windows向けにMacでzipを作る手順

必ずこの順番で進めてください。圧縮した後に名前を直すとzipを作り直すことになるので、正規化が先です。

1. ファイル名が本当にNFDかを確認する

FinderではNFDかどうかは見えません。手早い確認方法は2つです。

  • ターミナルを開き、cd で対象フォルダに移動して次を実行します。 ls | python3 -c "import sys,unicodedata; [print(repr(n)) for n in sys.stdin.read().splitlines() if unicodedata.normalize('NFC', n) != n]" 何か名前が表示されたら、それがNFDです。
  • または、Finderの「情報を見る」からファイル名をコピーし、FilenameFixerのWebアプリのテキスト変換に貼り付けます。変換後のテキストが貼り付けたものと違っていれば、その名前は分解形式です。

半角英数字だけの名前（report_2026.pdf）は影響を受けません。関係するのは濁点・半濁点付きのかな、アクセント付きのラテン文字、ハングルなどだけです。

2. ファイル名をNFCに正規化する

APFSのドライブ（macOS 10.13以降の内蔵ディスクはすべてAPFS）では、リネームした名前はその形のまま保持されます。方法は次のとおりです。

  • ブラウザで一括リネーム。 FilenameFixerのWebアプリにファイルをドラッグ＆ドロップし、変換前後の一覧を確認して、リネーム済みのファイルをダウンロードします。処理はブラウザ内で完結し、ファイルがサーバーにアップロードされることはありません。日本語や韓国語の名前が混ざった資料フォルダをまとめて直すには、これが一番手間がかかりません。
  • ターミナルで1行。 対象フォルダ内で次を実行します。 python3 -c "import os,unicodedata; [os.rename(n, unicodedata.normalize('NFC', n)) for n in os.listdir('.') if unicodedata.normalize('NFC', n) != n]" これは現在のフォルダ直下だけをリネームします。サブフォルダがある場合は各フォルダで繰り返すか、慣れていれば os.walk を使う形に書き換えてください。
  • Homebrewを使っている人は convmv を入れて、フォルダ上で convmv -f utf8 -t utf8 --nfc -r --notest . を実行できます。

注意点が1つ。HFS+ のボリューム（古いMac、または「Mac OS 拡張」でフォーマットした外付けドライブ）では、ファイルシステムが再びNFDに戻してしまうため、リネームしても何も変わらないように見えます。その場合は後述の「完成したzipを直す」方法に進んでください。

3. __MACOSX フォルダを付けずに圧縮する

Finderの「圧縮」は必ずメタデータのフォルダを追加します。代わりに次のいずれかを使います。

  • ターミナルの zip： zip -r -X archive.zip フォルダ名。-X オプションで拡張属性を省きます。.DS_Store も除外したい場合は zip -r -X archive.zip フォルダ名 -x "*.DS_Store" とします。
  • ターミナルの ditto： ditto -c -k --norsrc --noextattr フォルダ名 archive.zip。Apple純正のコマンドで、Windowsで扱いやすい余計なもののないzipができます。
  • Keka（無料のサードパーティ製アーカイバ）には、環境設定にMacのリソースフォークを除外するオプションがあります。圧縮前にオンにしてください。

zip も ditto もUTF-8のファイル名を正しいフラグ付きで書き出すので、現行のWindowsエクスプローラーや7-Zipで正しく読めます。

4. 送る前に中身を確認する

ターミナルで unzip -l archive.zip を実行します。自分のファイルとフォルダだけが並び、__MACOSX の行も ._ の項目もなければ成功です。NFDについても念入りに確かめたいなら、この一覧を手順1のPythonチェックにパイプで渡してください。

すでにzipを送ってしまった、またはドライブがHFS+の場合

もう相手に送ってしまった後だったり、HFS+ボリューム上でリネームが効かなかったりすることもあります。どちらの場合も、元のファイルには触らず、完成したzipの中の名前を直す方法があります。

zipファイル名復元ツールは、200 MBまでのzipを受け取り、中のNFDの項目名をすべてNFCに書き換え、修正済みのzipをダウンロードできるようにします。ファイルの中身はそのままで、処理はブラウザ内で行われます。修正したzipを差し替えとして送り直すか、受け取った相手に同じページで元のzipを通してもらってください。ただし __MACOSX フォルダは削除されないので、それも気になる場合は、名前を正規化したうえで前述の ditto または zip -X でzipを作り直してください。

ツールを一切使いたくないなら、Windows側の相手が解凍後に該当ファイルの名前を手で付け直すという手もあります。数個のファイルならそれが一番早いです。日本語名の書類が200個あるフォルダでは現実的ではありません。

Windows側の相手に伝えておくこと

短い一言を添えるだけで、やり取りの往復がかなり減ります。たとえば次のような内容です。

  1. 解凍はエクスプローラー標準の「すべて展開」か7-Zipで。どちらもMacで作ったzipを正しく読めます。
  2. __MACOSX フォルダがあれば削除して構いません。中の ._ ファイルは壊れたコピーではなく、Macのメタデータです。
  3. 名前は正しく見えるのにアプリで開けないファイルがあれば、名前が分解形式になっています。手でリネームするか、解凍したファイルをFilenameFixerのWebアプリに放り込んで一括リネームしてください。

受け取る側が開発者なら、PowerShellで原因を確認できます。[Text.Encoding]::UTF8.GetByteCount("ガ") はNFC表記なら3、NFDなら6を返します。Node、Python、.NETのいずれにも normalize("NFC") があるので、両方の形式を受け付ける必要があるスクリプトではそれを通してください。

限界と、似ているけれど別の問題

  • 長いパス。 Windowsは長いパスのサポートを有効にしない限り、フルパスを260文字までに制限しています。深い階層に長い名前のフォルダを重ねたMacのフォルダは、正規化とは無関係に展開に失敗することがあります。圧縮前に最上位フォルダの名前を短くしてください。
  • 4 GBを超えるzipにはZIP64が必要です。現行macOSの zip と ditto は対応していますが、古いWindows用ツールには対応していないものがあります。
  • zip -e で作ったパスワード付きzipは旧式の暗号化を使うため、7-Zipでは開けてもWindowsエクスプローラーでは開けません。ファイル名の問題ではありませんが、「Windowsで開けない」という同じ種類の連絡が来ます。
  • 使えない文字。 :、?、*、|、<、>、" を含む名前はmacOSでは有効ですがWindowsでは使えず、エクスプローラーは展開時に拒否するか別名に変えます。NFC正規化ではこれらは変わらないので、自分で置き換える必要があります。
  • 往復のやり取り。 Windows側の人がファイルを編集してzipで送り返してきても、何も壊れません。NFCの名前はAPFS上でそのまま保持されます。問題が起きるのはMacからWindowsへの方向だけです。

まず正規化し、ditto か zip -X で圧縮し、一覧を確認する。この順番を守れば「名前がおかしい」という返事は来なくなります。すでに相手の受信箱に届いてしまったzipなら、中の名前を書き換えたものを送り直すのが一番早い差し替えです。