Getの動作

Excel(2013) VBAで「Get」について次のような記述がある(赤線はこちらで付けた)。
この記述は別に目新しいものではなく、10年以上も前から存在している杜撰で何の参考にもならないインチキ記述である(詳細はvba_6007を参照)。


これによれば「10」は、「ファイルから10バイトを読み込む」、ということになっている。昔もそう記述されていた。


動作の確認

1
上の記述の確認である。
ここで読み込みの対象とする sjis_std.txt ファイルの内容である。


文字コードはShift_JISである(この画像は既出)

2
上の記述にならって、「10」を指定した場合の結果である。
これで表示されている(読み込まれている)のはファイルの先頭部分の「これはShift_J」で、これは「10文字」である。


Shift_JISなら、これは「13バイト」に相当する。
Unicodeなら、これは「20バイト」に相当する。
どちらにしても、上で書かれているような「10バイト」ではない

となると、上の記述の信憑性はかなり怪しくなってくる。
BASICなどはどうせエクセルバカが相手の子供だましのオモチャだから、Microsoftもいい加減なことを書き放題である。もう10年以上も前からこんな手抜き記述のままなのである。


ファイル全部を読み込む

次に、このファイル全部を読み込んでみよう。
このsjis_std.txtは107バイトのテキストファイルである(Shift_JIS)。これを次のようにして読み込んでみよう。

プログラミング VarString = String(107," ") Get #1, ,VarString

1
読み込む対象ファイルのサイズは107バイトである(FileLen関数の値である)。


2
これを上と同様に次のようにして読み込む。
このときのVarStringの値である(Len関数の値である)。


3
このときのVarStringの値である(LenB関数の値である)。


4
読み込んだデータの表示を表示させてみる。
全部正常に読み込まれている。
しかし、仔細に検討すればこれが想定したものとは異なっていることが判明するが、少なくとも「見かけ」だけは正常である。これがさまざまな間違いの元になる。


5
この場合、「篠崎愛」にあたるデータは124バイト目から129バイト目にある。
文字コードはUnicodeになっていることも、そのバイトデータからわかる。


総括
最初に設定した「107バイト」をはるかに超えたところにもデータがある。
VBAの「Get」の説明にならっていえば、あの「107バイト(を読み込む)」という「ありがたい説明」は一体どうなってしまったのだろうか

ここでおぼろげながら次のようなことがわかってくる。
  1. Getで使うバッファとして確保されているのは214バイトである。
  2. 107という数値は、エクセルで内部的にUnicodeが使われていること、107と214との関係に注目すれば、これはUnicodeでの文字数である。

「見かけ」だけは正常とは

ところで、sjis_std.txt ファイルを、内容はまったく同じままで、これをUnicodeとして保存すると、そのファイルサイズは148バイトになる。すなわち、このテキストを全部Unicodeにしても148バイトにしかならない。

これはバッファとして確保した214バイト(LenB関数の値である)よりはるかに小さい。
となると、214バイト-148バイト=66バイトである。この66バイトは一体どうなったのであろうか。これが実際は大問題なのである。

1
配列として何らかのデータ(この場合は0x00)が確保されている。


2
214を超えた部分、たとえば215バイト目から220バイト目までを表示しようとするとエラーになる。
この部分は配列としての領域は確保されていないということである。


ということは、この読み込み方では149バイト以降は無意味かつ無駄な領域を確保していることになる。ただ、そのデータが「0x00」であるから表示されていても画面では見えなかっただけだということになる。BASICではC言語などのように文字列の終端がヌルになるということはない。

この弊害は、今読み込んだデータをそのままファイルに書き出したときに顕現する(実質的にコピーするだけ)。上のテキストの末尾にスペース(空白)が66バイト分出てくることになる。もちろん、これは元のファイルにはないものである。これでは、テキストファイルなら大した実害は無いが、こんな杜撰のことではバイト単位的に処理するバイナリファイルの操作には使えないのである。

なお、上のような方法はBASIC小僧が書いた低レベルなインチキ入門書をはじめとするパソコン系ゴミ本などによく出てくる。いや全部がそういうインチキ・デタラメであるといってもよい。ドシロウトを簡単にだませるからである。しかし、ちょっと複雑なことをしようと思えば到底使い物にならない方法である。たとえば、エクセルバカを相手にした「VBAがわかる500の技」(技術評論社)173pにも、こういう「見かけだけは正常」な笑えるインチキで杜撰なサンプルが出ていて自画自賛している。バカか、こいつ(この筆者)。無知とは平和なことである(笑)。

この程度のBASIC小僧にはその弊害などには当然気がついていない。こういうことをトコトンまで突き詰めて検討していないということで、実際は大したプログラミングはしていないということである。カネ儲けのためにバカがバカ相手に適当なことを書いているだけである。エクセルはバカがバカを相手に商売ができるありがたい世界だからである。詳細は「パソコン系ゴミ本の検討(Source Library:pbk_0068)」を参照。

この弊害を避けて過不足なくこのデータを処理する方法については「過不足なく書き込む(Source Library:vba_0206)」の項を参照。

上のようなインチキ入門書に書いてあるような杜撰な方法では、たとえば「UTF-8の行単位的処理」などを見てもわかるように、1バイトでも過不足があれば処理できないような世界では到底通用しないのである。そんなものには何の価値もない。しかし、そんなことはエクセルバカにはわからない。それでこんなデタラメばかり書いて商売しているようなチンピラBASIC小僧でも生き延びられるのである。げにバカ相手の商売は楽である(笑)。

- 2014/04/20 -







バイナリモード(Binary)についての杜撰な記述(vba_6007)
この問題の解決法/過不足なく正確にデータを書き込む(vba_0206)



エクセルバカの世界はこんな世界であるということの好例である。
LOG
116.80.207.193 [06/Jan/2015:10:47:40] VarString エクセル
もう目の向いている方向が全然ちがうのである。バカは度し難い。


タコの殿堂
エクセル屋の世界はバカがバカを相手に商売できる気楽なところだからデタラメだらけなのよね。

Unicode,UTF-8,UTF-16,Big,Little,Endian,LE,BE,Shift_JIS,SJIS,CR,LF,CRLF,byte,bit,word,CSV,BOM,Encode,Decode,ANSI, Binary,Open,Byte,Get,Put,InputB,AscB,Hex,Mod,LOF,Loc,FreeFile,ReDim,Encoding, バイナリ,テキスト,文字列,文字コード,16進コード,16進文字列,変換,ビッグ,リトル,エンディアン,ユニコード,改行,サンプル, バイト,ビット,ヘキサ,2進数,16進数,読み込み,書き込み,エンコード,デコード,解析,変換,判定,判別,バイナリエディタ, 全角,半角,カタカナ,ひらがな,漢字,