khabaネタ
(7)
- (2010.06.27b)
- データ・フォーマット混載型(G02)
- 混載型とはいっても、中に入れない？
- タイプフィールド
- シンプル(1):あるタイプがファイル終端まで繰り返す。
- 0はNOP・・・いやNOPはいらない。自由長だから。
- タイプ33は、LFでの改行を義務付ける。TABは4文字分。BSなどは含んでもいいが、処理できない可能性はある。制御コードとして処理されても文句を言ってはいけない。それはオプションで制御される？・・・デフォルトは、一般文字として扱う。00も抜かない。
- となると、標準テキストはこんな感じかな？（47 40 はjunkヘッダ。最終的には47 02を予定）
- 一般ビットストリーム
- 最初が74になっている場合、エンディアン誤認の可能性。
- bigエンディアンで 47 02 14 だと、リトルではどうなるの？ 4702 は 02 47 と書き込まれる。これは、bigエンディアンのファイルを、16bit単位で読んで、リトルに書き出してしまった場合。
- リトルエンディアンでは、47を分割して、74とかかせるのはどうだろう？だって下位から埋めるべきだろう？'t'
- 74で始まったら、リトルエンディアンgh4を採用していることが分かる。47で始まったら、bigエンディアンgh4。
- リトルエンディアンgh4では、制御ビットが下位に表れる。だってそっちが「先」だから。
- とにかく4bitを読め。そしてさらに4bitを読め。この順序では必ず 4 7 が出るはず。しかし7はよくない数字だ。変更しよう。じゃあ、43で。43なら逆にしても34だし。41-14だとあまりよくないから。いや、下位1bitも0のほうがいい。リトル版gh4を考えたら。
- ということで、エンディアンを守って4bitずつ読んで、 4 2 0 2 が出たら認識成功。
- 2 4 2 0 ならbigをリトルで読んだ病気になっている可能性が高い。
- 4 2 0 2 でも中がおかしくなっている可能性は？2bitや1bitもテストするべきなのか？
- それはできなくてもいいと思う。
- gh4ルーチンで読んでもいいけど、できればそれはしないほうがいい。
- ちがう、とにかく8bitを読め、だ。42が見えたらエンディアン一致。24が見えたらエンディアン不一致。出力では、4bitずつ、4 2 0 2 を送るのだから。
- 42_02はやめよう。2の部分はgh4で。いややっぱり有効。これは02という一つの数字ではなくて、0と2なんだ。そうなんだ。
- 33のテキストファイルなどのエンディアンがどっちでもいいケースは、42を使うほうが推奨される。
![[K Wiki]](k.jpg "[K Wiki]")
