アカウント名:
パスワード:
Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes.
前述の「フィールドセパレータとしてのカンマとフィールド内のデータとしてのカンマの扱い」だけでなく、各フィールドのデータをシングルorダブルクォートで囲んで出力するヤツもいたりした。極論すれば「1レコード内の各フィールドをカンマで区切る」という制約以外は無いに等しい状況だったわけで。
すべてのCSVを扱うソフトがRFCに準拠してくれればともかく、現状では、機械的処理を前提とすると、CSVほどタチの悪いフォーマットは無いと思う。それでも多くの場面でCSVが汎用データ交換形式として役に立ってた理由は、人間が可読可能なテキストデータだったから、最悪引っかかったとこだけエディタで修正するとか、スクリプト言語で前処理を行うとか、要は人力で問題を回避する方法が取れたからだと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
text (csv) さえ扱えれば (スコア:0)
と、Officeを清書ツールとしてしか使っていないemacs使いのチラシの裏
Re: (スコア:1)
Re: (スコア:1)
それができないのなら、ダブルクォートで囲むようにするようにすれば良いのでは?
RFC4180 [ietf.org]より引用。
I'm out of my mind, but feel free to leave a comment.
そんな新しいRFCを論拠にされてもなぁ (スコア:0)
前述の「フィールドセパレータとしてのカンマとフィールド内のデータとしてのカンマの扱い」だけでなく、各フィールドのデータをシングルorダブルクォートで囲んで出力するヤツもいたりした。極論すれば「1レコード内の各フィールドをカンマで区切る」という制約以外は無いに等しい状況だったわけで。
すべてのCSVを扱うソフトがRFCに準拠してくれればともかく、現状では、機械的処理を前提とすると、CSVほどタチの悪いフォーマットは無いと思う。それでも多くの場面でCSVが汎用データ交換形式として役に立ってた理由は、人間が可読可能なテキストデータだったから、最悪引っかかったとこだけエディタで修正するとか、スクリプト言語で前処理を行うとか、要は人力で問題を回避する方法が取れたからだと思う。