lain画集のBinHexエンコードされた画像を見る(4)
デコード
table: BinHexフォーマット
データ 説明(英語) 説明
Byte Length of FileName (1->63) ファイル名の長さ(1~63) (1バイト)
Bytes FileName ("Length" bytes) ファイル名("ファイル名の長さ"バイト)
Byte Version バージョン(1バイト)
Long Type ファイルの種類(4バイト)
Long Creator 作成者(4バイト)
Word Flags (And $F800) フラグ(2バイト)
Long Length of Data Fork データフォークの長さ(4バイト)
Long Length of Resource Fork リソースフォークの長さ(4バイト)
Word CRC 巡回冗長検査(CRC) (2バイト)
Bytes Data Fork ("Data Length" bytes) データフォーク("データフォークの長さ"バイト)
Word CRC 巡回冗長検査(CRC) (2バイト)
Bytes Resource Fork ("Rsrc Length" bytes) リソースフォーク("リソースフォークの長さ"バイト)
Word CRC 巡回冗長検査(CRC) (2バイト)
正直CRCがどの範囲に対して適用されているかよく分かっていない…が今回はどうせ(不明な箇所があるため)あまり意味がないので気にしないこととする。
データフォークに実際のデータが入っている。
リソースフォークは(以前の?)Macで使われていた、実際のデータ部分以外の付加情報を記録する部分らしい(→Wikipedia) 突き合わせたものはこちら↓ 数値として読むべきところとASCIIとして読むべきところがあるので注意
table: フォーマットと突き合わせたもの
データ名 バイト数 実際のデータ(16進) 説明
ファイル名の長さ 1 0C 12
ファイル名 12 69 6E 6E 6F 63 65 6E 74 2E 6A 70 67 innocent.jpg
バージョン 1 00 0
ファイルの種類 4 4A 50 45 47 JPEG
作成者 4 38 42 49 4D 8BIM (Photoshopのシグネチャ?JPEGのPhotoshop資源データセグメントにも出てくる)
フラグ 2 05 00 フラグ(よく分からない)
データフォークの長さ 4 00 00 0B EE 3054
リソースフォークの長さ 4 00 00 00 00 0
巡回冗長検査(CRC) 2 19 10 (6416)
データフォーク 3054 FF D8 ... FF D9 JPEGファイルのデータ
巡回冗長検査(CRC) 2 44 AC (17580)
リソースフォーク 0 (なし)
巡回冗長検査(CRC) 2 00 00 (0) (リソースフォークのみに適用されていると見て良いか?)
パディング 1 00 エンコード時に3の倍数バイトにするために付けられた00
というわけで元のファイルはinnocent.jpgという3054バイトのJPEGファイルであると分かった。
FF D8 ... FF D9の部分をバイナリエディタ等で(バイナリ形式で)保存すれば晴れて画像が見られるというわけである。
…まあ本当はその前にある程度1とlがどちらなのか確定させる作業があるわけだが…
そもそもファイルを開けない・明らかに画像に変な部分が出るというようなのは直しているのでそのまま見れるようになっているはず
あとはこのJPEGファイルがどんな構造になってるか見ていく感じで。次回、vs. JPEG。
修正を試みるのでなければ特に見る必要はないかも。