ＰＩＣＢＡＳＩＣコンパイラ
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
まるでインタプリタ。でもコンパイラです。超カンタン超シンプルです。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

［第１２３回］



●ＳＤカードＩＦ（４３）ＳＤカードをＷｉｎｄｏｗｓ７に接続（１６）ＣＳＶファイル（１４）ＥＸＣＥＬのゼロサプレス問題

［第１２１回］でＥｘｃｅｌでＢＩＴ表現のデータファイルを開いたところ左側のビットが０のときにはその０が表示されないこと（ゼロサプレス）に気がつきました。
たとえば００００００００は０、０００００１０１は１０１というように表示されてしまいます。
このことはそれ以前の回での１６進数データをＥｘｃｅｌで開いた場合でも同じだったのですがそのときはまだそのこと（左側の０が表示されないこと）には気がついていませんでした。
１６進数の場合には００〜０９が０〜９になってしまいます。

Ｅｘｃｅｌではそういう表示になってしまうのがルールなのでどうしようもないと一旦はそのように思ったのですが、何か方法があるのではないかと思い直して少し考えてみることにしました。
Ｅｘｃｅｌでは数値に対してはゼロサプレスが利いてしまうのはどうやら仕方がないようです。
しかし文字列ならば？
常識的に考えれば文字列に対してゼロサプレスが働くなどということはありえないはずです。
なんとなれば、数値としての「０１２３」と「１２３」は同値なのですが、文字列としての「０１２３」と「１２３」は異なっているはずだからです。
もっとも数値といい文字列といってもどちらも人間が都合のよいように扱う符牒のようなものですから目的や用途によっていかようにも変化します。
それじゃあとらえどころがないことになってしまいますから、特にコンピュータの世界ではそこに何らかの情報を付加して「数値」であるか「文字列」であるかを区別します。
たとえばＢＡＳＩＣなどでは文字列の両端を”（引用符）で挟むことでそれが文字列であることを示します。
”ＡＢＣ”、”１２３４５”という表し方です。
おお。
それだ。
それならＥｘｃｅｌ様にもご納得いただけるのでは。

ということでとりあえず１６進数データの両端を”で挟む形のデータを出力するプログラムを作りました。
作成したプログラムはＢＩＮＨＥＸＥ．ＥＸＥです。
ＢＩＮＨＥＸＥ．ＥＸＥを実行しました。

今までと同じようにＴＥＳＴ３１．ＢＩＮを読み込んでＴＥＳＴ３１．ＣＳＶを出力しました。
その内容を確認するためＤＥＢＵＧコマンドを実行しました。
１６進数データの両端が「”」（ＡＳＣＩＩコードは２２）で挟まれていることが確認できます。

これでどうじゃ。
そのように作成されたＴＥＳＴ３１．ＣＳＶをＥｘｃｅｌで開きました。

ぬあんと。
あかん。
駄目でありました。
「お前はばかか？」
”　”で「文字列」であることを示したにもかかわらずわざわざその中身を確認して「だんなさま。調べたら数値でしたのでそのように扱いました。ぼくって賢いでしょ」って、全然賢くない！！
Ｅｘｃｅｌに限らず総じてＷｉｎｄｏｗｓの眷属にはこういうどうしようもないところがあって、もう腹が立ってパイを投げつけてやりたくなることがあります。

余りに見事なので、ひょっとしてこちらが間違えたかと思ってしまいます。
念のために確認いたしました。

うむむむむ。
間違いなどではありません。
同じＴＥＳＴ３１．ＣＳＶを同じ画面上でＥｘｃｅｌとＴｅｒａＰａｄの両方で開いてみました。
間違いなく１６進数データは”　”で挟まれています。
こうなると。
Ｅｘｃｅｌは確信犯であります。

さて。
どうする？

ＰＩＣＢＡＳＩＣコンパイラ［第１２３回］
２０２４．１．２ｕｐｌｏａｄ

前へ
次へ
ホームページトップへ戻る