バイナリデータとテキストデータ

このところ受託開発の仕事のプログラミングの納期間近ということで、私も手伝って慌ただしくプログラミングをしているのですが、そのシステムでは通信データの形式にバイナリ形式を使っています。バイナリ形式とテキスト形式の違いをあらためてプログラマー視点で書いてみましょう。

バイナリ形式とはCPUがそのまま値として扱える状態のことで、例えば数値データとして一般的に使われている32ビット整数や、64ビット浮動小数点などがあります。C言語では、char,short,long,float,doubleなどの型が使われます。32ビットコンパイラならintはlongと同等ですね。

一方、テキスト形式は、人間がそのまま読める形式で、一般的にはアスキー形式とも呼ばれますが、ASCII文字を使用し、数値も「1.234」という感じに文字列で表現します。

昔はフロッピーディスクなどの記憶媒体の容量が少なかったため、少ない容量で多くのデータを保持できるバイナリ形式が多用されました。プログラマー視点で考えると、そもそもメモリー使用可能容量がさらに少なかったので、読み書きしやすいバイナリー形式が好まれたとも言えます。

しかし、容量の問題はすでにほとんど気にされなくなり、それより、ネットワークの発達に伴い、データの互換性が要求されるようになってきました。バイナリ形式はCPUが扱う形式そのままですので、CPUによって形式が異なる場合があるのです。モトローラー系とインテル系のバイトオーダーが逆、という致命的な問題のため、バイナリ形式では1バイトより大きな単位で数値を表現する際にバイトの並び順が異なるという問題が発生し、ファイルデータの互換性はもちろん、ネットワークでデータを通信する際にも問題となりました。イーサーネットではモトローラー系のバイトオーダーを標準として、プログラミングする際には、htons(),htonl(),ntohs(),ntohl()などのバイトオーダー変換関数を必ず使用するという決まりになりました。

その後、XMLをはじめとして、データを様々な環境で使うことを前提としたフォーマットはほとんどテキスト形式が採用され、バイナリ形式はサイズ、速度などが要求される限定的な用途で使われるようになってきています。

プログラマーとしてはテキスト形式は解釈に手間がかかり、多少面倒なのですが、デバッグのしやすさや、メンテナンス性の高さから好まれています。XMLなど汎用的な形式では汎用のパーサーと呼ばれる解釈ライブラリも用意され、プログラマーの手間を減らしてくれています。一方、バイナリデータは自分で作って読み書きするだけなら良いのですが、他のシステムとやりとりする場合、意外とバグが出やすいのです。バイトオーダーの問題もありますし、連続したデータの途中のサイズを間違えただけでそれ以降のデータがとんでもない値になってしまいます。受託開発で何よりも困るのが、データフォーマットの仕様書が間違えていると致命的という点です。バイナリ形式はデータの位置が命です。テキスト形式ですと区切り文字などがあるので、意外とエラー処理も含めてきちんとできるのですが、バイナリ形式は仕様書通りに扱うしかできず、正しいかどうかの判断は値を見てもなかなかできないのです。デバッグもテキスト形式であればエディタで編集してテストできますが、バイナリ形式ですと自分でテストデータを作るプログラムを準備してテストすることになり、それがそもそも勘違いしていると最後まで間違いに気がつかないと言うことになってしまいます。

個人的な趣味もありますが、基本的に複数のシステム・プログラム・環境でやりとりするデータはテキスト形式が安全です。実はテキスト形式にも改行がLFかCRLFかの違いがあったりしますが、それを吸収するのは簡単です。バイナリ形式はプログラムがローカルに作業用に使う場合などに限る方が、最終的には楽に結合ができるものだと思います。

まあ、昔は何でもバイナリ、さらにビット単位でフラグをちりばめたりして、仕様書なしではとても扱えないデータが多かったものです。今でもMPEGファイルなどのように効率優先のフォーマットはそういう感じですが。今ではOFFICE系のドキュメントデータまでXMLになってきました。時代は変わったものです。

ちなみに、テキスト形式で、何でもXMLとは思いません。構造的あるいは階層的なデータで、拡張性が必要な場合などはXMLのメリットも感じますが、一般的なデータはXMLにしても扱いにくくなるだけの場合が多いものです。個人的には普通の「名前=値」形式が一番好きです。これでほとんどのデータが書き表せると思います。目的に応じて使い分けるのがポイントです。