Word 文書（docx）ファイル形式
Office Open XML 形式の Microsoft Word 文書。
- MIME タイプ
- application/vnd.openxmlformats-officedocument.wordprocessingml.document
- 拡張子
- .docx
- カテゴリ
- ドキュメント
マジックナンバー（ファイル署名）
| 0x00000000 | 504B0304 | PK·· | 'PK' — it is a ZIP |
ZIP 内に '[Content_Types].xml' と 'word/' ディレクトリがあります。
Word 文書（docx）形式について
.docx は Open Packaging Conventions のパッケージ、つまり XML パーツと埋め込みメディアをエントリに持ち、リレーションシップファイルで互いを結んだ普通の ZIP アーカイブです。.zip にリネームして開けば文書の全体が見えます。word/document.xml に本文と段落構造、word/styles.xml に書式、word/media/ に画像。ファイルの先頭 30 バイトには 'Word' を示すものは何もなく、形式の判別は完全に ZIP のディレクトリに並ぶ名前だけで行われます。
ヘッダーの構造（バイト単位）
| オフセット | 長さ | フィールド | 意味 |
|---|---|---|---|
| 0 | 4 | Local file header signature | 50 4B 03 04。.docx は ZIP であり、これはその最初のローカルファイルヘッダで、素のアーカイブや .apk、.epub の先頭にあるものとまったく同じです。このファイルを Word 文書たらしめている要素はもっと奥にあります。 |
| 4 | 2 | Version needed to extract | 必要な読み取り側の最小バージョンを 10 倍した値。ZIP のあらゆる整数と同じくリトルエンディアンです。Word が書くのは deflate を示す 20 で、無圧縮のエントリには 10 が現れます。 |
| 6 | 2 | General purpose bit flag | ここで一番効くのはビット 3 です。これが立っていると下にある CRC とサイズ 2 つがゼロになり、実際の値は圧縮データの後ろに続きます。Word はストリーミングで書いたかどうかによって、どちらの形でもパッケージを作ります。 |
| 8 | 2 | Compression method | .docx のパーツはほぼすべて 8（deflate）です。XML は極めてよく縮み、1 ページ分のテキストは数 KB の XML が数百バイトになります。すでに圧縮済みのメディアは方式 0 のまま格納されることがあります。 |
| 10 | 2 | Last modified time | MS-DOS のパック形式の時刻で、時 5 ビット、分 6 ビット、2 秒刻みの秒 5 ビット。Word は自分が生成したパーツのタイムスタンプを正規化するので、ここから実際の編集日時が分かることはまずありません。本物の日付は docProps/core.xml にあります。 |
| 12 | 2 | Last modified date | MS-DOS のパック形式の日付で、1980 年起点の年 7 ビット、月 4 ビット、日 5 ビット。1980 年より前は表現できず、タイムゾーンもありません。 |
| 14 | 4 | CRC-32 | このパーツの非圧縮バイト列に対するチェックサム。1 エントリしかカバーしないので、最初のパーツの CRC は完璧なのに 3 つ先のパーツが壊れている .docx もあり得ます。 |
| 18 | 4 | Compressed size | ヘッダと可変長フィールドの後ろに続く deflate データのバイト数。FF FF FF FF なら読み手は ZIP64 の extra field を見に行きますが、.docx でそれが必要になることは実質ありません。 |
| 22 | 4 | Uncompressed size | パーツの元の長さ。[Content_Types].xml なら数百〜数千バイトで、圧縮後との比はたいてい 5 対 1 より良くなります。 |
| 26 | 2 | File name length | 最初のエントリが [Content_Types].xml のときは 13 00（19 バイト）です。Word をはじめ OOXML の書き手はこれを必ず先頭に置きます。ファイル全体を通して、手にしているものの正体を示唆する最初のフィールドがここです。 |
| 28 | 2 | Extra field length | Word が書いたパッケージではたいていゼロです。非ゼロなら ZIP64 のサイズ、Unix のパーミッション、高精度タイムスタンプなどで、Word ではなく再パックしたツールが足したものです。 |
| 30 | 19 | First entry name | ASCII バイトで [Content_Types].xml。このパーツはパッケージの地図で、アーカイブ内のすべての拡張子とすべての override に対してコンテンツタイプを列挙します。OPC はこれをパッケージのルートに置くことを要求しています。オフセット 30 にこれがあることが、種類を問わず OOXML であることを示す一番安上がりな肯定的テストです。 |
| variable | variable | word/document.xml | このパッケージをブックでもスライドでもなく Word 文書にしているパーツです。固定オフセットにはないのでファイル末尾のセントラルディレクトリ経由で探しますが、そこに名前が現れることが決定的な判定になります。画像やスタイルへ結び付ける word/_rels/document.xml.rels も同様です。 |
| -22 | 4 | End of central directory signature | 50 4B 05 06。アーカイブコメントが無ければ末尾から 22 バイトの位置にあります。読み手はここから始めて、指されたセントラルディレクトリをたどり、そこで初めてパッケージにどのパーツが入っているかを知ります。だから最初のヘッダが健全でも末尾を失った .docx はそもそも開きません。 |
| -6 | 4 | Offset of the central directory | ディレクトリが始まる絶対バイト位置で、コメントが空という同じ条件が付きます。ファイルの前に何かを足すとこの数値の基準がずれます。ダウンロードした文書で「Word がこのファイルを開けません」となる原因のほとんどはこれです。 |
似た形式との見分け方
| 紛らわしい形式 | 見分け方 |
|---|---|
| Excel ブック（xlsx） | ローカルファイルヘッダの全フィールドが同一で、たいていは最初のエントリ名も同一です。どちらもオフセット 30 が [Content_Types].xml だからです。確実に分けられるのはファイル末尾のディレクトリだけで、ブックなら xl/workbook.xml と xl/ ツリー、文書なら word/document.xml と word/ ツリーが並びます。コンテンツタイプのパーツ自体も、ContentType が wordprocessingml.document で終わる Override で種類を宣言しています。 |
| ZIP | .docx は ZIP です。問題は ZIP かどうかではなく、どの ZIP かです。素のアーカイブには必須のエントリ名が一切ないので、判定は否定形ではなく肯定形にします。ルートに [Content_Types].xml があり、かつ _rels/.rels パーツがあること。両方そろっていなければ、たまたま XML が入っているだけの ZIP です。 |
| OLE2 / CFB | .docx が置き換えた側の形式です。Word 97-2003 の .doc は D0 CF 11 E0 A1 B1 1A E1 で始まる Compound File Binary コンテナで、中に文字どおり 'WordDocument' という名前のストリームがあります。.docx は 50 4B 03 04 で始まります。どちらも同じ Word で開きますし、Word は拡張子ではなくバイトを読んで判断します。名前を間違えたファイルが開いてしまい、名前が正しい壊れたファイルが開かないのはそのためです。 |
| EPUB | どちらもマークアップを詰めた ZIP パッケージで、'PK' で判定を止める素朴な検出器はどちらも取り違えます。EPUB は最初のエントリを完全に固定していて、'mimetype' を無圧縮・extra field なしで置き、オフセット 38 に application/epub+zip が来ます。対する OOXML はバイトレベルで何も固定せず、エントリ名で判別します。オフセット 30 が 'mimetype' なら、それは .docx ではありません。 |
| docm | マクロ有効の Word 文書で、hex エディタで見る範囲ではどこも .docx と同一です。違いは中に word/vbaProject.bin パーツがあることと、[Content_Types].xml の ContentType が異なることだけ。出所が信用できないファイルではこの組み合わせを確認する価値があります。目に見える違いは拡張子だけで、それはリネームひとつで消えるからです。 |
よくある壊れ方
- 末尾が欠けている。ローカルヘッダも圧縮済みパーツも全部無傷なのにファイルが開かない、ということが起こります。ZIP の読み手は end-of-central-directory レコードから始めるのに、それが無いからです。復旧は 50 4B 03 04 を前方に探してローカルヘッダからディレクトリを組み直す作業で、.docx なら本文はたいてい完全に取り戻せます。
- 先頭にバイトが付いた。HTML のエラーページや PHP の警告が .docx という名前で保存されると全体がずれ、セントラルディレクトリの絶対オフセットが見当違いの場所を指します。文書は丸ごと残っているのに Word は破損と報告します。50 4B 03 04 より前を削れば直ります。
- テキストモード転送。deflate ストリーム内の改行変換はヘッダのフィールドもエントリ名も無傷のまま残すので、パッケージの一覧は完璧に出て、その後 Word が word/document.xml を展開するところで CRC 不一致になります。Word のバグに見えて、そうではない障害です。
- 手で編集して再パックを誤った。パーツはただの XML なので編集は簡単で、間違えるのは zip し直すところです。フォルダ自体のディレクトリエントリを足す、エントリ名の大小文字を変える、XML 宣言の前に BOM を入れる。どれをやっても、あらゆる ZIP ツールが健全と言うパッケージを Word が拒否します。
- word/media のパーツが途中で切れている。画像は普通の ZIP エントリなので、書き掛けの PNG が入っていても本文はまったく無傷で読めて、その画像だけが壊れたプレースホルダとして表示されます。CRC が合わないのはそのエントリだけです。
この形式の現在地
.docx はどこでも既定のワープロ形式であり、Microsoft の形式としては珍しく本物の公開標準です（ECMA-376 と ISO/IEC 29500）。Google ドキュメントも LibreOffice も Apple Pages も過不足なく読み書きできるのはそのおかげです。バイナリの .doc から移ったことで、Microsoft の外にも効く利点が 2 つ手に入りました。1 つは復旧しやすさで、本文がただの XML なのでパッケージが壊れても中身は生き残ります。もう 1 つはサイズで、圧縮された XML は同じ内容の compound file より劇的に小さくなります。解決しなかったのは実装間の再現性です。標準は巨大で、パーツ同士は深く絡み合っており、Microsoft 以外のエディタを一度通した文書は行間や段落番号やリストの字下げが微妙に変わって戻ってくることがよくあります。だから .docx は、共同で編集したり変更履歴付きでレビューしたりするものには第一候補で、どの端末でも見た目が同一でなければならないものには不向きです。そちらは PDF の役目です。実務上の弱点は、XML 詰めの ZIP が配送手段として都合が良すぎることでしょう。マクロ有効の兄弟 .docm はバイト単位でほぼ見分けが付かないので、メールフィルタは拡張子を信じずに毎回パッケージの中を開けざるを得ません。
Word 文書（docx）ファイルをこのサイトで開く
どれもブラウザ内で動きます。ファイルが端末から出ることはありません。
関連する形式
Word 文書（docx）と混同しやすい形式です。先頭バイトを見比べてください。
| 形式 | 先頭バイト | 拡張子 |
|---|---|---|
| Excel ブック（xlsx） | 50 4B 03 04 | .xlsx |
| PowerPoint プレゼン（pptx） | 50 4B 03 04 | .pptx |
| ZIP | 50 4B 03 04 | .zip |
| OLE2 / CFB | D0 CF 11 E0 A1 B1 | .doc |
| EPUB | 50 4B 03 04 | .epub |