ZIPの文字コードと文字化けの条件

既定の文字コード

追加の指定が無い場合に、名前の格納に使われる既定の文字コード

IBM Code Page 437(汎用フラグのビット11が立っていない場合。義務の強さはSHOULDでありMUSTではない)

SHOULD conform to the original ZIP

D.1で『従来のZIP文字エンコーディング』がIBM Code Page 437であると定義された上で、D.2がSHOULD(努力目標であり必須ではない)と規定している

出典: PKWARE APPNOTE.TXT APPENDIX D (Language Encoding)

確認日: 2026年10月11日

Unicode対応の仕組み

UTF-8等のUnicodeファイル名であることを区別・記録する仕組みがあるか

汎用フラグ ビット11(Language encoding flag/EFS)を立てると、ファイル名とコメントはUTF-8でMUST(必須)エンコード

MUST be encoded using UTF-8

ビット11なし→SHOULD(CP437)、ビット11あり→MUST(UTF-8)という義務の強さの非対称性が原文の細部

出典: PKWARE APPNOTE.TXT §4.4.4 general purpose bit flag

確認日: 2026年10月11日

文字化けが起こる条件

どのような条件で日本語などのファイル名が文字化けするか

汎用フラグのビット11が立っていないZIPは、規格上 CP437 として解釈される。ファイル名が CP932 で書かれているとこの解釈で文字化けする

APPNOTE.TXT 自体は、Windows 標準の ZIP 機能がファイル名をどう書き込むかには触れていない。当サイトでは Python(3.13.3)で、ファイル名を CP932 で書きビット11を立てない ZIP ヘッダを作り、規格どおりに読むと文字化けすることを再現した。Windows 標準の ZIP 機能がこの状態のファイルを生成すると指摘されることは多いが、本表は Windows の現行実装そのものを検証したものではない

出典: PKWARE APPNOTE.TXT APPENDIX D(規定)+ 当サイトでの Python による再現

確認日: 2026年10月11日

パス長の上限

格納できるパス全体の上限

パス専用の上限は定められていない。ファイル名の欄(相対パスを含められる)の長さは2バイトの欄で表し、ディレクトリのレコードとファイル名・拡張フィールド・コメントの欄を合わせた長さは、通常65,535バイトを超えないものとする(SHOULD NOT) (単位: バイト)

SHOULD NOT generally exceed 65,535 bytes

§4.4.10〜4.4.12 はファイル名・拡張フィールド・コメントの長さをそれぞれ2バイトの欄とし、合計の長さを SHOULD NOT(避けるべき)で定めている。MUST NOT(禁止)ではない。ファイル名の欄に相対パスを含められることは §4.4.17.1 にある。展開先の OS のパス長の上限は、表の各 OS の行を参照

出典: PKWARE APPNOTE.TXT §4.4.10〜4.4.12・§4.4.17

確認日: 2026年10月11日