Windowsだけで処理をしている場合はほとんど問題ないが、それ以外のＯＳが絡む場合、文字コード体系は Shift-JIS/ASCII に変換して貰って受理しても、改行コードが LF のファイルを受け取ることがある。
さて、CR や LF と言われて分からない方もいらっしゃるだろう。
例えば、テキストエディタ上で改行をすると、ちゃんと改行する。次に開いたときもそこで改行している状態が保持される。これは、改行する、という記号が埋め込まれているからだ。制御コードとか制御文字とか言われるが、その記号が、WindowsではCR＋LFと呼ばれる。CRはキャッジリターンで、行の先頭に戻る、という意味で、内部コードは16進数で0x13 である。LFはラインフィードで、行を１行送る、という意味で、内部コードは16進数で 0x10である。（16進数表記の時は、それだと分かるように先に0xをつける事が多い。実際は 13 と 10 という、１バイトのコードである。）
UNIX系はLFが改行コードとなるため、しばしば CR がないものが渡されることがあるのだ。（Macは・・すいません。知りません。）
話を戻す。LFだけでCRのないcsvファイルを VBA の Line Input で読みこむと、一気に全内容を読み込んでしまう。Line Input では行の区切りを認識するのに少なくとも CR が必要だからである。
対策としては、受理する時点でCR＋LFでファイルにしてもらうこと。さもなくば、いったんシートにcsvを読み込むようにすればよい。csvをシートに読み込む分にLFだけでも認識してくれるのだ。VBAでいったんシートに読むようにすると手作業は減るだろう。ちなみに、CR、LF、CR+LFはVBAで定数として持っている。
例えばDebug.Print Asc(vbLf)
の結果は 10 が返るし、
Debug.Print Asc(vbCr)
の結果は 13 が返る。
なお、たまにコード内で CR を意味するコードとして、Chr(13)などと書いているコードがあるが、可読性に欠けるので、vbCrなど、定数を使った方がいいだろう。
ただ、うろ覚えなのだが、vb.netのマニュアルにこの書き方があまりよくないような書き方があったような記憶もある。その辺はまた確認したい。
ブログトップへブログ内検索キーワード
改行
csv