|
■No98917 (WebSurfer さん) に返信
> エラーメッセージは、
> ValueError: could not convert string to float:
> だそうですが、後出ししないで一番最初の質問で書きましょう。それから、float: の
> 後に変換しようとした文字列があるのではないですか？
あるいは、本来は数値を出力しなければならない場所に、
実際には何も出力されていない(空文字列)とか…ですかね。
■98913 (ゆい さん) に返信
> 未知に近いUTF-8(BOM無し)に、てっきり起因があるのでは？ とも思ってもしまったのです。
それは BOM あり BOM なし 2 種類のファイルを使って検証すれば、すぐに分かる話ではないでしょうか?
BOM の有無を調整する方法は、先に紹介した URL に書いてあります。
仮に「BOM 無しを前提としている処理系」に BOM 有ファイルを渡した場合、
(a) BOM を文字として読み取り、先頭に U+FEFF すなわち「幅ゼロの無改行空白文字」として読み込む。
(b) BOM を自動的に切り取って処理してくれる。(BOM 有無を自動判定するタイプ)
のいずれかになると思います。
a の場合は、最初の行の最初の列に、不可視文字が一文字混入するという事です。
> 先日教えてもいただいた「WriteLine → Write」での、
> そのままでは改行がされないがため、安直にも「sr.WriteLine()」が為にも関わらず。
その処理系では期待されている改行は LF ですか? CRLF ですか? あるいは CR ですか?
現状は、CSV ということと、それが UTF-8(BOMなし) という点しか分からないので、
仕様を出している担当者に、もっと突っ込んで確認した方が良いかも知れませんね。
(1)ファイルの先頭にヘッダー行が含まれるの否か。
常にヘッダーがあるパターン、常に無いパターン、あっても無くても良いパターン。
(2)各レコードは可変長なのか固定長なのか。
固定長 CSV の場合、文字数固定なのかバイト数固定なのかも重要です。
(3)すべての行で列数が同一なのかどうか。また、その列数は幾つと定義されているのか。
処理系によっては、行によって列数が異なる CSV なんてものもあります。
(4)レコード区切りは LF 改行なのか CRLF 改行なのか CR 改行なのか。
固定長 CSV の場合、稀に改行を一切含まないという特殊な CSV がありえます。
(5)レコード区切りの改行がある場合、それは「レコードの末尾」に付与されるのか
それとも「レコードとレコードの間」に付与されるのか。
もしもレコード間改行という仕様だった場合、ファイル終端には改行が含まれません。
(6)それぞれのデータを引用部(")で囲むのか否か。
すべて引用符で囲む CSV もあれば、すべてのデータを囲まない CSV もあります。
文字列は囲むが、数値は囲まない CSV なんてもあります。日付を # で囲む処理系もあり。
(7)引用符で囲む CSV の場合、データ中に「カンマ」や「改行」が許可されるか否か。
これらの特殊文字をデータに含む CSV は、ファイルの作成はさほど難しく無いものの
ファイルの読み込み処理が複雑化する傾向にあります。
Excel で生成した CSV の場合、データ内改行は LF 固定、レコード区切は CRLF だったりしますね。
(8)引用符で囲む CSV の場合、データ中に「引用符」が許可されるか否か。
半角「"」だけでなく、全角「“」や「”」も含めて禁止という CSV もあれば、
データ内の引用符を許可する CSV もありますが。
引用符が許可される場合、それはどのように出力されるのかも重要です。
(9)データを含まないセルの出力仕様が決まっているか。
たとえば、携帯電話番号を含む住所録な CSV データがあって、たとえば
"田中A","07092895448","東京都"
と出力されるような処理系において、携帯電話番号が無い場合の出力パターンとしては
"田中B","","東京都"
"田中C",,"東京都"
"田中D",null,"東京都"
"田中E",undefined,"東京都"
などのパターンが考えられます。
処理系によっては、田中B のパターンは「空文字列」として扱う（携帯電話が無い）ものとし、、
田中C のパターンを「null」として扱う（携帯番号を持っているかどうか不明）ことで、
両者を区別して使い分けていることがありました。
(田中D や田中E のパターンは、話として聞いたことがあるだけで、実際に見たことは無いです)
|