【要約】ZIPの日本語ファイル名はなぜ化けるのか、仕様書を読んでPythonで再現してみた [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がWindows環境で作成したZIPファイルを他者に共有した際、ファイル名が記号の羅列になる問題がある。多くの解説は「文字コードの不一致」という抽象的な説明に留まっている。具体的には以下の課題が存在する。
- ・どの仕様書のどの項目が、文字化けのトリガーとなっているのか不明。
- ・ビットフラグの有無が、解釈プロセスにどう影響するのかがブラックボックス。
- ・不整合なデータが、エラーとして処理されるのか、文字化けとして処理されるのかが不明。
// Approach
筆者は、PKWAREの公式仕様書「APPNOTE.TXT」を読み解き、Pythonを用いて不整合なZIPファイルを意図的に生成する手法を採用した。検証は以下のステップで実施されている。
1.仕様書から、ビット11がUTF-8の使用を示すフラグであることを特定。
2.Pythonのzipfileによる標準的な書き込み挙動を確認。
3.structモジュールを用い、ビット11を0に設定したままCP932でエンコードしたZIPヘッダを手組み。
4.生成したZIPを読み込み、文字化けおよびデコードエラーの発生を実測。
// Result
検証の結果、文字化けのメカニズムが仕様レベルで解明された。ビット11が0の場合、読み手は仕様に従いCP437として解釈するため、CP932のバイト列は文字化けする。また、ビット11が1かつ中身がCP932の場合、UTF-8デコード失敗により例外が発生することも確認した。これにより、文字化けの本質は「データの破損」ではなく「解釈の約束事の不一致」であることが証明された。
Senior Engineer Insight
> 「文字コードの問題」という曖昧な事象を、仕様に基づいた「フラグとエンコーディングの不整合」として具体化した点は極めて優秀である。大規模システムにおいて、ファイル名やメタデータの扱いは、OSやライブラリの暗黙の挙動に依存しがちである。本記事のように、一次資料に立ち返り、境界条件をコードで検証する姿勢は、堅牢なシステム設計において不可欠である。トラブルシューティングの際、単なる推測ではなく、仕様に基づいたエビデンスを提示できる能力は、技術責任者として高く評価できる。