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のスタートボタンを取った！などがある。（便利なものは真っ先に抹消される法則