はぅーーー．．．っと仕事してたら夜になる生活なり． 今日は山崎氏が上京(ぉ　してるとのことで，早めに終えて食事でも行こうかと思っていたのだ． 早めに終えるためにいろいろな制御をしてバッファを作ったのだけど．．． なんか不具合対処とかで空いたバッファは即座に埋められることになるわけさ． 理由は「そこにバッファがあるから」ですカ？

　で，その不具合ってのがまた， 某外注のバカが作った汚いソースから暗号化としか思えないロジックをほどいてバグを探す作業だよ． ソースは相変わらずの暗号化．テーブル列の定義をわざわざ CSV にして別ファイルに定義してあって， その別ファイルのファイル名は前の form から hidden で受け取る値をそのまま使用なので， コンテキストを解釈しないと動作が判らない． ていうか form の値をそのままファイル名にって，なんかすげー穴が開いてそうっていうか絶対開いてる．

　で，その CSV には，ただ人が見るときに便利なだけだと思われる「通番」がついているのだな． 最初の行は見出しになってて，次の行から，1 から始まる連番がついている． これを Excel で見ると 2行目が 1 となってちょっと変なんだけど， コンピュータは普通 0 から数え始めるので，見出し行が 0 とするとデータ開始行は 1． まぁフツーの発想だーね．

　かと思ったら，ご丁寧に見出し行はきちんと読み飛ばした上で， きちんと 0 origin の配列に放り込んでるよう！ 　ってことは，配列の 0番目は CSV データの 1番目で Excel でいう 2行目だ！ 　相変わらずキチガってるぜ！！

　で，他にも難しいロジック（高度な，という意味ではない）をくぐり抜けて， やっと見つけたバグの原因は，全然違った項目をデータに入れてるせいでしたとさ． テーブル列の定義が配列にあるのと同様に，読んできたデータも配列に入るんだけど， これへのアクセスは全て配列の添え字（つまりただの数字）で行なってる． で，「$var = $CSVDATA[26][2]; //設備」って文， わざわざコメントに「設備」って書いてあるけど， 「設備」は $CSVDATA[40][2] であって，$CSVDATA[26][2] は「会社名」なんだよゴルァ！！

　はぁはぁ．こいつの作ったソースを見るたびにアタマが悪くなっていく気がする．．．