ZIPで日本語ファイル名が文字化けする理由

Windowsで作ったZIPファイルを渡したら、相手の環境でファイル名だけが「ﾃｽﾄ.txt」のような記号の羅列に化けていた——という経験がある人は少なくないはずです。この現象は偶然のバグではなく、ZIPの公式仕様PKWARE APPNOTE.TXTが定める汎用フラグのビット11(Language encoding flag/EFS)という1個のフラグの有無で説明できます。本記事は、原文の規定内容と、この環境のpythonでその因果関係を実際に再現した結果を並べ、7-Zip・RAR 5.0・MIMEのファイル名との違いも整理します。本サイトは特定のツールの文字化けの有無を判定するものではありません。

ZIPのファイル名エンコーディングを決める1ビット

出典はPKWARE APPNOTE.TXT Version 6.3.10(Revised Nov 01, 2022)の§4.4.4 general purpose bit flagとAPPENDIX Dです。汎用フラグのビット11(0x0800、Language encoding flag/EFSとも呼ばれます)が立っている場合、原文には次のようにあります。

MUST be encoded using UTF-8

一方、このビットが立っていない場合、APPENDIX Dは次のように定めています。

SHOULD conform to the original ZIP

ここで見落とせないのは、両者の義務の強さが非対称であることです。ビット11ありは「UTF-8でMUST(必須)エンコード」、ビット11なしは「従来のZIP文字エンコーディング(IBM Code Page 437)にSHOULD(努力目標であり必須ではない)準拠」とされています。つまりビット11が立っていないZIPのファイル名は、規格上は前提としてCP437として解釈される、という約束事になっています。

この環境のpythonで実機再現した4つの事実

規格の原文だけでなく、実際にファイルを作って読み戻す検証をこの環境のpython(3.13.3)で行いました。検証スクリプトと結果はサイト側で保存しています。

検証3では、「日本語ファイル名.txt」をCP932でエンコードしたバイト列を、ビット11を立てないままZIPヘッダに手作業で格納し、それをAPPNOTE.TXTの規定どおりCP437として解釈するリーダーで読み戻しました。結果は元の文字列とは一致しない記号の羅列になり、まさに「文字化け」と呼ばれる状態が再現されました。検証4は、ビット11を立てているのに中身がCP932のバイト列のままという、規格上ありえない組み合わせを試したものです。この場合はUTF-8として厳格にデコードしようとして失敗するため、文字化けよりもさらに手前の「読み取りエラー」で止まります。この2つの検証は、ビット11というたった1個のフラグと、実際のバイト列のエンコーディングが一致しているかどうかが、文字化けの有無を分ける核心であることを裏付けています。

他のアーカイブ形式・MIMEとの対比

ZIPのように「ビットの有無で解釈が変わる」仕組みは、すべてのファイル形式に共通するわけではありません。

7-Zipの開発者公式リポジトリが公開する仕様書7zFormat.txtには、次のように記載されています。

wchar_t Names[NameSize];

7-Zipには、ZIPのような「既定エンコーディングかUTF-8か」という二層の切替概念がそもそもありません。ファイル名は常にwchar_tの配列として格納されます。ただし、7-Zip自体の文字化けが起こる条件については、当サイトでは調査していません。

RARLAB公式のRAR 5.0技術文書には、ファイル名について次の記載があります。

in UTF-8 format without trailing zero

RAR 5.0もビットフラグによる切替を持たず、常にUTF-8で格納する方式を採用しています。こちらも、文字化けが起こる具体的な条件そのものは今回確認していません。

HTTPのContent-Dispositionヘッダーで使われるfilenameパラメータは、RFC 6266 §4.3の記述によれば、filename*との対比の中でISO-8859-1相当の文字集合に限られることが示されています。

characters not present in the ISO-8859-1

それ以外の文字を扱うためのfilename*パラメータは、次のようにRFC 5987のエンコーディング方式を使います。

uses the encoding defined in [RFC5987]

このfilename*の構文は、charset'language'valueという3分割の形式とパーセントエンコーディングを基盤としており、その構文自体はRFC 2231に遡ります。ただしRFC 2231自体は「filename」という語やContent-Dispositionへの直接の言及を持たない一次資料である点には注意が必要です。filename*を解釈できない古い実装は、ISO-8859-1相当のfilenameパラメータにフォールバックするため、原文には次のようにあります。

do not understand the

フォールバックが起きると、ISO-8859-1に無い文字(日本語を含む多くの非ラテン文字)を含むファイル名は、文字化けしたり失われたりしうるという帰結になります。「文字化けする」という直接的な表現がRFC自体にあるわけではなく、フォールバック時の非互換性から生じる結果として整理したものです。

よくある質問

出典・関連リンク

このページを引用する場合

本記事の情報を引用・紹介いただく場合は、記事名「ZIPで日本語ファイル名が文字化けする理由」と情報確認日「2026年7月26日」をあわせてお示しください。当ページへのリンクは任意です(リンクいただける場合は https://www.conbu.jp/tool/filename-limits/article-zip-mojibake.html をご利用ください)。