「Windows API/図形の描画」の版間の差分

ナビゲーションに移動 検索に移動
s/機械語/バイナリーデーター/ See 機械語
({{Nav}},s/命令/関数/)
(s/機械語/バイナリーデーター/ See 機械語)
タグ: 2017年版ソースエディター
 
== 画像ファイルのバイナリ ==
{{-}}
[[File:Bitmap structure on hex edit japanese.svg|thumb|900px|バイナリエディタで見た場合のビットマップの機械語バイナリーデーターの配置<br>バージョンによって少々異なる場合もあるが、おおむね、こういう感じである。]]
{{-}}
 
たとえばビットマップ画像を作りたい場合、
 
機械語バイナリーデーターで、いわゆる「ビットマップ構造体」の仕様で決められた様式で、機械語バイナリーデーターをファイルに書き込む。
 
すると、たいていのデスクトップ用OS(ウィンドウズも含む)では、ビットマップ形式の機械語バイナリーデーターをサポートしているので、その機械語バイナリーデーターを画像ファイルとして認識してくれるので、クリックなどをするとOSが画像表示などをしてくれる。
 
なお、ネットや専門書の解説では画像フォーマットの仕様を説明するためによくC言語の「構造体」の書式が説明されるが、しかし、その構造体を入力しても、画像は生成されない。
この「42 4D」という冒頭の数字を識別子とすることで、ファイルの種類を認識している。
 
誤解しないでほしいが、けっして「BM」と機械語バイナリーデーターで書かれているのでなく(そもそも十六進数に「M」は無い)、書かれているのは あくまで「42 4D」である。
 
ネット検索で調べる場合は「42 4D」というキーワードを付け加えて「ビットマップ 42 4D」などで調べれば、ビットマップ画像のバイナリでの扱いに関する有益な情報が入手しやすいだろう。
</pre>
 
stiring に限らず一般にバイナリエディタの画面の構成は、上記のようになっている。(なお、「ファイル」→「ダンプイメージの保存」などの操作で、上記のような機械語バイナリーデーターのイメージをテキストエディタ(Windowsの場合は『ワードパッド』など)で見られる形式に変換して出力できる。)
 
機械語バイナリーデーターはそのままでは、テキスト表示できない。なので、それをテキスト化したり、見やすくするために書式を整えたりして、機械語バイナリーデーターの内容を出力したものをダンプ イメージという。
 
また、そのようなダンプイメージを出力することを、俗に(ぞくに)「ダンプする」などとIT業界では言う。
 
 
さて、このダンプイメージのうち、機械語バイナリーデーターの本体は、真ん中のブロックである、下記の
<pre>
42 4D 82 00 00 00 00 00 00 00 76 00 00 00 28 00
 
</pre>
は、ファイル内容の機械語バイナリーデーターをアスキーコードに変換して表示している。
 
このアスキーは、機械語バイナリーデーターのファイル内容ではなく、バイナリエディタ側がユーザーが内容を探しやすくする目的などのために表示している。
 
 
</pre>
 
は、単に何バイト目かをあらわしているだけである。これは、機械語バイナリーデーターのファイル内容ではなく、バイナリエディタ側がユーザーが見やすくするために表示している。
 
 
;各ヘッダの名称
{{-}}
[[File:Bitmap structure on hex edit japanese.svg|thumb|900px|バイナリエディタで見た場合のビットマップの機械語バイナリーデーターの配置<br>バージョンによって少々異なる場合もあるが、おおむね、こういう感じである。]]
{{-}}
 
 
ビットマップ情報ヘッダの長さは40バイトで固定である。
機械語バイナリーデーター本体の右上にあるビットマップ情報ヘッダの「28 00」と次の段の「00 00」は、ヘッダサイズに相当するが、28は十進数に直すと40である(16×2+8=40)。 リトルエンディアンなので、あとの00の3回くりかえしは無視していい。
 
 
さて、ビットマップ構造体の図を、ダンプイメージと照らし合わせてみよう。
{{-}}
[[File:Bitmap structure on hex edit japanese.svg|thumb|900px|(再掲)バイナリエディタで見た場合のビットマップの機械語バイナリーデーターの配置]]
{{-}}
 
1段目アドレスのABCDの部分にある「 76 00 00 00」は、まず意味は10進数で118である。7×16+6=118 より。
 
で、「機械語バイナリーデーターの118バイト目から、画像データが始まります」と宣言している(ファイル先頭から画像デーマまでの「オフセット」という)。1バイトは256で、16×16=256なので16進数では2ケタぶんです。画像データの先頭のバイトが118バイト目であると、を指し示している。
 
なお、数え方は左上の「42 4D」ですでに2バイトである。 この調子で118バイト目を探すと
 
 
それを横5×縦3ピクセルにしたファイルの機械語バイナリーデーターダンプは、次のようになります。
 
<pre>
 
 
なお、画像データの読み方は、機械語バイナリーデーターの情報が、画像では左下から右下に対応します。
 
なので、2色以上を使った画像で、調べてみましょう。
 
 
さて、幅30×高さ10 の画像は、画像で見ると、青い帯は下側にあります。しかし機械語バイナリーデーターでは、青い帯は、最初に書かれています。
 
このように、上下が反転しています。そういう仕様だからです。
 
;Linux のxxdコマンド
Linux だと、この機械語バイナリーデーターのテキスト形式のダンプ内容を、機械語バイナリーデーターのビットマップ画像形式に変換できるコマンドがある。
 
<code>xxd</code> というコマンドを使えばいい。Fedora 31 では標準では、この <code>xxd</code> がついていない。なのでFedoraにこのコマンドをインストールするために vim-common をインストールする必要がある。Fedora ではvim-common に <code>xxd</code> が含まれている。
 
xxdはもともと、機械語バイナリーデーターを16進ダンプするためのコマンドであるが、このソフトウェアには、さらに16進ダンプされた内容のテキストを機械語バイナリーデーターに戻す機能もある。
 
 
引数に -r をつける事により、16進ダンプを機械語バイナリーデーターに戻せる。
 
たとえば、なんらかのテキストエディタ(Fedora標準の gedit でもよい)に、下記のテキスト(これはstirringで出力したテキストから、上2行の見出しを除去しただけの物である)をそのままコピーペーストしてテキストエディタに貼り付けし、普通に「test」などの名前で保存しよう。この段階では、ファイル「test」は、まだ単なるテキストファイルである。
が必要である。
 
だが、これを使わなくても、C言語で直接に書いてしまう方法もある。C言語で書き込みの際、書き込みモードに「wb」のようにbをつけるだけで機械語バイナリーデーターを書き込みできるので、ソレを使って、プログラムを自力で書く方法もある。
 
なお、文字列「1」はアスキーコードでは16進数「31」なので、一対一対応しないので、C言語で書く場合には注意しよう。
3,375

回編集

案内メニュー