Word .docx ファイルの最初の部分を 16 進数で示します。
50 4b 03 04 14 00 06 00 08 00 00 00 21 00 e1 0f
8e bf 8d 01 00 00 29 06 00 00 13 00 08 02 5b 43
6f 6e 74 65 6e 74 5f 54 79 70 65 73 5d 2e 78 6d
6c 20 a2 04 02 28 a0 00 02 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
上記の 2 桁の値はそれぞれ1文字であることに注意してください。最初の 2 つの値 -- 50 と 4b -- は、ASCII 文字の P と K です (Google の「ASCII テーブル」を参照すると、私の意味がわかります)。
表示できるすべての文字データは次のとおりです。
PK[Content_Types].xml
16 進値を見ると、値が 0x7F を超えるものは有効な ASCII/UTF8 文字ではありません。このようなデータが特定のプロトコルを介してインターネット経由で送信される場合、何らかの方法で ASCII にエンコードされていない限り、データが文字化けする傾向があります (プロトコルは ASCII 文字を想定しているため)。これが「Base-64」の目的です。
Base-64 は上記のデータを次のようにエンコードします。
UEsDBBQABgAIAAAAIQDhD46/jQEAACkGAAATAAgCW0NvbnRlbn
RfVHlwZXNdLnhtbCCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
すべての値は通常の ASCII 文字 (数値は 0x7f 未満) であるため、これは安全に送信できます。
Base-64 をデコードすると、おそらく最初と同じデータが返されるため、そのデータをファイルに書き込むと、元の .docx ファイルが「再構成」されます。
一方、デコードされたデータ (またはエンコードされていないデータ) をバイトから文字列へのコンバーター ( newStringUtf8
. ただし、「バイナリ」データ (.doc または .docx ファイルのヘッダー データなど) は単なる数字であり、文字データではありません。これらのバイナリ値を UTF 文字に変換しても意味はありません。さらに、一部の値は変換に耐えられず、正しく変換されません。
このファイルを処理する方法は、.doc ファイルを Base-64 形式から「バイナリ」に「再構成」し、そのデータを「バイナリ」ファイルとして書き込むことです。次に、そのヘッダーを読み取り、賢明に分解する方法を理解するソフトウェアを使用します。これは、Word 自体か、Word ファイルの内部にアクセスするために特別に作成された API のいずれかです。