Macで圧縮したzipが解凍できない・文字化けするときに、最初に切り分ける3つ

Macで圧縮したzipが相手のWindowsで解凍できない、または開けても日本語のファイル名が「縺後℃」のような記号の列に化ける。この相談の大半は、zipの中に書かれたファイル名に「UTF-8で書いた」という印が付いていないことが原因です。印の無い名前を、日本語版のWindowsは昔ながらのShift_JIS(CP932)として読むため、文字が化けます。名前を英数字だけにして圧縮し直すか、受け取る側でUTF-8として読める道具で開けば、中身はそのまま取り出せます。

一方、Mac自身で開けないときは別の原因です。書庫が最後まで届いていない、.cpgz が増えて堂々巡りになる、展開先の空きが足りない、のどれかに収まります。この記事では、どこで開けないのかを3つに分け、それぞれを2026年10月9日にmacOS 27.0.1で実際に試した結果をもとに説明します。

まず「どこで」開けないのかを3つに分ける

同じ「解凍できない」でも、起きている場所によって原因がまったく違います。最初にどれに当たるかを決めると、試すことが一気に減ります。

  • Windowsで開くと、ファイル名だけが化ける、またはエラーで止まる
  • Macで開くと、.cpgz という別のファイルができて、開くとまたzipに戻る
  • Macで開くと、番号付きのエラーが出るか、何も起きない

1つ目は、書庫は壊れていません。ファイル名の読み方が送る側と受ける側で食い違っているだけです。2つ目と3つ目は、書庫そのものか、展開する側の環境に問題があります。

見分ける手がかりは、送り主と受け取り手のOSです。Macで作ってWindowsへ送ったなら1つ目を疑い、受け取ったファイルをMacで開けないなら2つ目と3つ目を疑います。ファイルの中身(請求書のPDFや写真)が開けないのではなく、zipから取り出す段階で止まっている、という点も確かめておきます。取り出せたファイルが開けないのは、zipではなくアプリの側の話です。

Macで作ったzipの中身を実際に調べた

macOSのFinderで右クリックから「圧縮」を選ぶと、Appleの説明どおり、元の名前に .zip が付いた書庫ができます。

1つの項目を圧縮すると、圧縮ファイルには元の項目の名前に拡張子「.zip」が付いた名前が付けられます。複数の項目を同時に圧縮すると、圧縮ファイルには「アーカイブ.zip」という名前が付けられます。 出典: support.apple.com

この書庫の中身を、Finderの圧縮と同じ形式で書き出す ditto コマンドで作って調べると、次の2点が分かります。対象は「資料」というフォルダに「がぎぐ見積書.txt」を1つ入れたものです。

1点目は、ファイル名の符号化の印です。zipの仕様書(PKWAREのAPPNOTE)では、各ファイルの見出しにある11番目のビットが立っていれば、名前はUTF-8で書かれているものとして読む決まりになっています。

Bit 11: Language encoding flag (EFS). If this bit is set, the filename and comment fields for this file MUST be encoded using UTF-8. 出典: pkware.cachefly.net

実測では、名前のバイト列そのものはUTF-8でしたが、このビットは立っていませんでした。macOSに入っている zip コマンド(Info-ZIP 3.0のApple改変版)で作った書庫も同じで、ビットは立ちません。印が無いので、受け取る側は自分の判断で文字コードを決めます。同じバイト列をCP932として読ませると「資料」は「雉�譁�」に、「がぎぐ見積書」は「縺後℃縺占ヲ狗ゥ肴嶌」になりました。Windowsで見かける化け方そのものです。

2点目は、隠しフォルダです。Finderと同じ形式の書庫には、中身とは別に __MACOSX というフォルダが入り、その中に ._がぎぐ見積書.txt という215バイトのファイルができていました。これはMacがファイルに付けている追加の情報(ダウンロード元の記録など)を、Mac以外でも壊さず運ぶための入れ物です。Macで展開すると元に戻されて見えなくなりますが、Windowsではそのままフォルダとして見えるため、「知らないフォルダが入っている」「中身の数が合わない」という問い合わせにつながります。

Windowsで化けるときに、送る側ができること

いちばん確実なのは、送る前にファイル名とフォルダ名を半角英数字にしておくことです。英数字はUTF-8でもCP932でも同じバイト列なので、ビットの有無に関係なく正しく読まれます。「見積書_10月.pdf」を「mitsumori_2026-10.pdf」にする程度で足ります。

日本語の名前を残したい場合は、__MACOSX を外すだけでも受け手の混乱は減ります。ターミナルで次のように打つと、既にできた書庫から取り除けます。

zip -d 書庫.zip "__MACOSX/*"

実測では __MACOSX/ とその下の ._ ファイルの3件が消え、中身のファイルだけが残りました。最初から入れたくないときは、フォルダの1つ上の階層に移動してから zip -r 書庫.zip フォルダ名 -x ".*" -x "__MACOSX" で作ります。こちらは隠しファイルも除いた書庫になります。

ただし、この2つは隠しフォルダを消すだけで、名前の符号化の印は付きません。日本語名の文字化けまで確実に避けたいなら、英数字の名前にするか、受け取る側の道具に任せるかのどちらかです。送り先が社外で相手の環境が分からないときは、英数字の名前にしておくのが手戻りの少ない選び方です。慶應義塾大学の学生団体のブログでも、同じ現象が具体的に説明されています。

Macで作成したzipファイルは、Windowsでは高確率で文字化けして読めなくなります。 出典: lyncs.hateblo.jp

受け取る側のWindowsでの圧縮と展開の基本操作は、Microsoftのファイルを圧縮および展開するの案内にまとまっています。文字コードを選んで開ける展開ソフトを使っている相手なら、UTF-8を指定して開いてもらう方法もあります。

Macで開けないとき:届いていないのか、壊れているのか

Mac側で開けない場合は、ターミナルの3つのコマンドで順に確かめます。追加のインストールは要りません。

unzip -l 書庫.zip
unzip -t 書庫.zip
ditto -x -k 書庫.zip 展開先フォルダ

1つ目は中身の一覧を出すだけです。約3MBの書庫を半分で切ったものに試すと、末尾の目録が見つからないという趣旨の「End-of-central-directory signature not found」が出ました。これは中身が壊れているのではなく、ファイルが最後まで届いていない目印です。ダウンロードをやり直すか、送り主に元のファイルサイズを聞いて、ls -l のバイト数と比べます。

2つ目は中身まで検査します。正常な書庫では最後に「No errors detected in compressed data」と出ます。特定のファイルだけが失敗するなら、届いてはいるが一部が傷んでいます。

3つ目は、Finderの圧縮と同じ形式を扱う ditto で実際に展開します。同じ切れた書庫では「Couldn't read pkzip signature.」と出て止まりました。一覧が通るのにここだけ失敗する場合は、書庫の外、つまり展開先の空きや権限を疑います。Appleも、開けないときはまず空き容量を確認するよう案内しています。展開中は書庫と展開後のファイルの両方がディスクに載るので、書庫の大きさの数倍の空きを見込んでおきます。

もう1つ、Windowsで作られたzipは ditto のほうが扱いやすい場面があります。CP932で名前を書いた書庫を作って試すと、unzip -l の一覧では名前が「?」の列になりましたが、ditto -x -k で展開したファイルは「請求書.txt」と正しい名前で出てきました。macOSの unzip には文字コードを指定する -O が無いため、名前が化ける書庫は ditto で開くのが近道です。

.cpgz が増えるのは、書庫として読めなかった合図

zipを開いたら .cpgz ができ、それを開くとzipに戻る。この繰り返しの理由は、macOSの「アーカイブユーティリティ」の動きを見ると分かります。アーカイブユーティリティにフォルダを直接渡すと、zipではなく .cpgz ができました。中を file コマンドで調べると「gzip compressed data」で、これがアーカイブユーティリティ単体での既定の書き出し形式です。

つまり .cpgz が出てきたのは、渡されたzipを書庫として読めず、代わりに「圧縮する」ほうの仕事をした結果です。.cpgz を開く方法を探すのではなく、元のzipがなぜ読めなかったかを前の節の3つのコマンドで調べます。多くは途中で切れたダウンロードです。

拡張子が .zip でも中身が別の形式という場合もあります。

拡張子が「.zip」でも実際はRAR形式や、独自の圧縮方式が使われていることがあり、Mac標準では対応できません。 出典: next-sfa.jp

file 書庫.zip と打つと、名前ではなく先頭のバイト列から種類を判定します。「Zip archive data」以外が返ったら、名前と中身が食い違っています。ダウンロードの失敗でエラーページが .zip という名前で保存された場合は「HTML document」と出るので、すぐに分かります。

フォルダとターミナルを同じ窓で扱うと切り分けが速い

ここまでの手順は、Finderで書庫の場所を確かめ、ターミナルを開いて cd で同じ場所へ移り、コマンドを打つ、という往復の繰り返しです。書庫の場所をパスで打ち間違えると、それだけで「ファイルが見つからない」と出て、原因の切り分けが一段遠回りになります。

この往復を減らす方法の1つが、フォルダごとにターミナルが付いているファイル管理アプリを使うことです。開いているフォルダでそのままコマンドを打てるので、unzip -t や zip -d を書庫の隣で実行できます。そうした道具の中には、zipの作成と取り出しを内蔵していて、Mac単体で使う分には料金がかからないものもあります。どの機能が入っているかはできることに、無料の範囲と有料で増える内容は料金にまとまっています。Finderや他の道具との違いは他のファイル管理との比較で確かめられます。

どの道具を使う場合でも、順番は変わりません。開けない場所を3つに分け、Windows側の文字化けなら名前と __MACOSX を、Mac側なら届いているか、壊れているか、展開先かを順に確かめます。導入前の疑問はよくある質問で先に確認できます。

よくある質問

Macで圧縮したzipをWindowsで開くと、なぜファイル名だけ文字化けするのですか?

zipの中のファイル名には「UTF-8で書いた」という印を付ける決まりがありますが、macOSのFinderの圧縮と標準の zip コマンドで作った書庫では、2026年10月の実測で印が付いていませんでした。印が無いと日本語版のWindowsはShift_JISとして読むため、日本語の名前が記号の列になります。中身のデータは壊れていません。

送る相手がWindowsのとき、いちばん確実な対策は何ですか?

圧縮する前に、ファイル名とフォルダ名を半角英数字にしておくことです。英数字は文字コードの違いの影響を受けないため、相手の環境に関係なく正しく表示されます。あわせて zip -d 書庫.zip "__MACOSX/*" で隠しフォルダを外しておくと、知らないフォルダが入っているという問い合わせも防げます。

zipを開くとcpgzができて、また開くとzipに戻ります。どうすればよいですか?

cpgzはアーカイブユーティリティが書庫として読めなかったときに、代わりに圧縮を行った結果です。cpgzを開くのではなく、元のzipを unzip -l で確かめます。末尾の目録が見つからないという表示が出たら、ダウンロードが途中で切れています。ダウンロードをやり直すか、送り主に再送を頼みます。

Windowsで作られたzipをMacで開くと、名前が化けることはありますか?

あります。ただし2026年10月に試した範囲では、Shift_JISで名前を書いたzipを ditto -x -k で展開すると正しい日本語の名前で出てきました。macOSの unzip コマンドには文字コードを指定する方法が無いため、名前が化けるときは ditto で展開するのが近道です。

記事一覧へ戻る