変奏現実

javascriptでsplit(“,”)とすると、
“A,B,C,D” も”,,,”も４つの要素を持つ配列になる。
しかし、昔(VB5～)からMSのBASICのSplitが空要素を削除するのが習わしになっているので、”,,,”は要素０個の空配列になってしまう。
なぜそうなったのかは、容易に想像が付く。
A   B        　　C    　　D   E
A   BCG      CODE    D   E
A   BASIC   C    　　　D   E
の様にデータの要素のカラム位置を綺麗にそろえると空白が並ぶ、
これを普通のSplit(” “)で処理すると、予想外の空データが挟まってしまう（しかも大量に）ので、
安易（便利なつもり）にMSのSplitが空データを挟まなくなったのは間違いないだろう。
勿論、このような特殊なケースだけは、非常に便利だが・・・
※なぜ特殊なケースだけかと云えば・・・
A   “BCG      CODE”    D   E
とか
A   “”””  C    D   E
が期待されるような結果が出るとはとても思えないからだ。
CSVでは、よく見かける

A, B, C, , , w, , ,Z

と云う様によく見かける『簡単なデータを簡単に処理できない』のがMSのAPIの特徴である。
中にはStrConvの実装が当初、「ｱ⇒ア」はバッファが１バイトしか用意していないため””（空文字列）を出力するので、「ｱｱ⇒ア」としないいけない欠陥が長く続いたが、MS内部でも不都合杉だったようで、こっそり手直しされた例もある。
※Windows７にVisual -Studio 2008+SP1+SQL Server Express 2007だけをインストすると発生するが、例えば、古いAcrobat Readerの様に、扱いやすく手直し（Bugfix）されたランタイムをWindowsに上書きしてくれる便利なものをインストすると、StrConvが便利になり、アンスコしても元には戻らないところがとてもいい。
※もっとも今では巨大企業のORACLEのODBCドライバーもWindows95全盛期は、SELECT * FROM A WHERE ID<100 程度を想定していたらしく、EXCELからINSERTの様な長いSQL文を送信するためには語彙（WORD）が256バイトの境界を股がない様に調整しなければならなかった。後に１パケット（４KB）境界と緩和された代わりにMAX64KBのスタックの大半を使い切る悪魔で、32ビット版WindowsまでTCP/IP版はその道のプロでも使いたくないシロモノだったりとか、LANカードごとにTCP-IPドライバーが別もので、同じ会社でも別商品なら２枚差し不可とか、そのドライバーの中にC:\{メーカー名}と直書きされていてPC98シリーズ品なのに使うにはドライバーをMS-DOSのデバッガでA:\と書き換えなければいけないとか、16ビットWindowsの頃はどの会社もトンデモ品ばかりで、そんな苦労に明け暮れる日々だった。（合掌
※更に付け加えるなら、.Net、SilverRight、XAML、WPF、Windows8.xなど中途半端な実装に踊らされている現在も同様に進行中ということだ。後何年かするとバカバカしい苦労でしかなくなるのだ。（メデタシメデタシ
しかし当時のMS-BASICには普通のSplitと同じ仕様のREAD文があり、特に支障は無かったのだが・・・・・・・・・・・・・・・・・・・・・・・・・・
現在はDATA文などと一緒に抹消されている。（便利なものは真っ先に抹消される法則
これらはVB6から.Net-BASICへのソースの移植が困難を極めた要因の１つであり、一字（ちょっとした仕様変更）が万字（沢山のソースコード）を駆逐（ゴミ）にするMS悪仕様の原点と云えよう。
言い換えれば、継ぎはぎだらけのAPIで成り立っていたVB６を.Netにコンバートなんて、まっとうなモノができる訳がなかったのだ。
実際、VB6から.Net-BASICへのソースのコンバートはMS自身が真っ先に投げ出しており、MSコンバータをアテにしてコンバートを請け負った会社がどれだけ酷い目にあったかは想像もしたくない。
現在でも、JScriptのSplitは、そのよう（MS流）になっている。（大笑
最近の類例では、Windowsのスタートボタンを取った！などがある。（便利なものは真っ先に抹消される法則

UsedRangeで大雑把なデータの範囲が得られる。

//エクセルファイルを開く
var book = EXCEL.Workbooks.Open("abc.xls");
//最初のシートを選ぶ
var sheet = book.Worksheets(1)
try {
  echo(sheet.name);
  //使用した行範囲を得る
  var rows = sheet.UsedRange.Rows;
  echo("rows:"+rows.count);
  //使用した最小行を得る
  var rowmin = rows(1).row;
  echo("rows(min):"+rowmin);
  //使用した最大行を得る
  var rowmax = rows(rows.count).row;
  echo("rows(max):"+rows(rows.count).row);
  //使用した列範囲を得る
  var cols = sheet.UsedRange.columns;
  echo("cols:"+cols.count);
  //使用した最小列を得る
  var colmin = cols(1).column;
  echo("cols(min):"+colmin);
  //使用した最大列を得る
  var colmax = cols(rows.count).column;
  echo("cols(max):"+cols(cols.count).column);

実行してみると、チャンとデータのある範囲を表示する。

rows:7
rows(min):2
rows(max):8
cols:3
cols(min):2
cols(max):4

ではJScriptでEXCELにシートのデータをクリップボードで送らせてみよう。

  sheet.Range(sheet.Cells(rowmin,colmin), sheet.Cells(rowmax, colmax)).Copy();
} catch(e){
  var i, ary = [];
  for (i in e) { ary.push(i + ":" + e[i]); }
  echo("例外処理：" + ary.join(", "));
} finally {
  if (book != null){
    book.Close(false);
  }
}

なぜかWindows 8.x 64bit版＋MS Office 365 Solo では、クリップボードにコピーしてくれないから・・・

  //sheet.Range(sheet.Cells(rowmin,colmin), sheet.Cells(rowmax, colmax)).Copy();
  var text="";
  for(var row=rowmin; row<=rowmax;row++) {
    var colText=[];
    for(var col=colmin; col<=colmax;col++) {
      colText.push(sheet.Cells(row,col).Text);
    }
    text += colText.join("\t") + "\r\n";
  }
} catch(e){
  var i, ary = [];
  for (i in e) { ary.push(i + ":" + e[i]); }
  echo("例外処理：" + ary.join(", "));
} finally {
  if (book != null){
    book.Close(false);
  }
}

自力でクリップボードもどきのデータを作らないといけないらしい。
ちなみに、例外処理を入れてあるのは、

book.Close(false);

しないとEXCELプロセスが起動する度に残ってしまうから・・・
例外処理が起きた場合は・・・

例外処理：name:TypeError, message:'aaa' は宣言されていません。, number:-2146823279, description:'aaa' は宣言されていません。

の様な感じで出る。
try catch で括ってしまうと、拡張機能のlinenumberが無いから、
文法エラーの場所が判らなくなってしまうので本末転倒な作りになっている。
非常に面倒。
aaa ならまだマシ、
インテリセンスなエディタは　変数Stと変数rtを宣言したソースの Start を　’St’ + space + ‘a’ + space + ‘rt’ に変化（へんげ）させてしまうことがママあるが・・・
そんな時は・・・
　　 ‘a’ は宣言されていません。
と表示するハズ。
インテリセンスなエディタの半角スペースは幅が狭く（１ドットぐらい）　目視で見つけることはまず無理。
やはりMSは人の邪魔しかしない。