ZIPの文字コードと文字化けの条件
本サイトは「このファイル名やパスが使えるか」を判定しません。掲載しているのは、公式資料に何が書かれているかの要約です。利用前に必ず原典をご確認ください。
区分: アーカイブ
4項目ごとの状況
既定の文字コード
追加の指定が無い場合に、名前の格納に使われる既定の文字コード
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年7月26日
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年7月26日
文字化けが起こる条件
どのような条件で日本語などのファイル名が文字化けするか
汎用フラグのビット11が立っていないZIPは、規格上 CP437 として解釈される。ファイル名が CP932 で書かれているとこの解釈で文字化けする
APPNOTE.TXT 自体は特定OSの実装に言及していない。この環境の python(3.13.3)で、ファイル名を CP932・ビット11を立てない状態のZIPヘッダを手作業で構築し、規格どおりに読むと実際に文字化けすることを再現した。Windows標準のZIP機能がこの状態のファイルを生成すると指摘されることは多いが、本表は Windows の現行実装そのものを検証したものではない
出典: PKWARE APPNOTE.TXT(規定)+ この環境での python 実機再現
確認日: 2026年7月26日
パス長の上限
格納できるパス全体の上限
未確認
APPNOTE.TXTのパス長上限について今回確認していない
確認日: 2026年7月26日
出典一覧
このページを引用する場合
本ページの情報を引用・紹介いただく場合は、ページ名「ZIPの文字コードと文字化けの条件」と情報確認日「2026年7月26日」をあわせてお示しください。当ページへのリンクは任意です(リンクいただける場合は https://www.conbu.jp/tool/filename-limits/zip.html をご利用ください)。
免責事項: 本ページはZIPを提供・管理する組織の公式サイトではなく、「このファイル名やパスを使ってよいか」を判定するものでもありません。掲載している内容は調査時点で公式資料から確認できた要約です。仕様は改定されうるため、最新の内容は必ず出典元の原典でご確認ください。詳細は免責事項をご確認ください。