アカウント名:
パスワード:
神 Excelと違って、楽勝だね。
"❶","12,000㌕","32.1㌫"Ⅱ,1万kg,46
全部にダブルクォート付きくらいなら、除去するだけだから楽勝だが。下手にデータの方にもダブルクォートがある場合ってどうなるんだろ。
ダブルクォートの出力方法がそもそも複数ある。ダブルクォートが2個並ぶ形式(普通はこの形式)でエスケープ。バックスラッシュ(円記号)の後ろにダブルクォートでエスケープ。ダブルクォートを単なる通常文字として扱う(この場合フィールド内に区切り文字や改行文字は入力不能)。もしかすると、ダブルクォートで括った上で区切り文字に隣接しない場合はダブルクォート一文字、区切り文字に隣接する場合はダブルクォートを一文字増やすって実装もあり得るだろうか?
二重ダブルクォートだけサポートしとけば大概は大丈夫だろうけど、もし方言含めてパースするなら当該形式で矛盾が起きない形式のうち最も一般的な方式であると推定が行えてから読み込みだねぇ……区切り文字が破壊されればフィールド数の不揃いで検知できるが、全部不揃いなパターンや破壊が起きないパターンだと確定困難。
> ダブルクォートの出力方法がそもそも複数ある
他の方も言及されてますがRFC 4180 というデファクトスタンダードがあります。それによればエスケープ方法は二重引用符を重ねる形式:
> "aaa","b""bb","ccc"
の1パターンのみ許容されるということになりますね。つまり「RFC 準拠のCSVでお願いします!」と言っとけばOKってことです。
http://www.kasai.fm/wiki/rfc4180jp [kasai.fm]
RFCになってるのにデファクトスタンダードとはこれいかに。
僕の考えた最強のデファクトスタンダードの定義は今はいいです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
CSVなら任せて安心 (スコア:0)
神 Excelと違って、楽勝だね。
"❶","12,000㌕","32.1㌫"
Ⅱ,1万kg,46
全部にダブルクォート付きくらいなら、除去するだけだから楽勝だが。
下手にデータの方にもダブルクォートがある場合ってどうなるんだろ。
Re: (スコア:0)
ダブルクォートの出力方法がそもそも複数ある。
ダブルクォートが2個並ぶ形式(普通はこの形式)でエスケープ。
バックスラッシュ(円記号)の後ろにダブルクォートでエスケープ。
ダブルクォートを単なる通常文字として扱う(この場合フィールド内に区切り文字や改行文字は入力不能)。
もしかすると、ダブルクォートで括った上で区切り文字に隣接しない場合はダブルクォート一文字、
区切り文字に隣接する場合はダブルクォートを一文字増やすって実装もあり得るだろうか?
二重ダブルクォートだけサポートしとけば大概は大丈夫だろうけど、
もし方言含めてパースするなら当該形式で矛盾が起きない形式のうち
最も一般的な方式であると推定が行えてから読み込みだねぇ……
区切り文字が破壊されればフィールド数の不揃いで検知できるが、
全部不揃いなパターンや破壊が起きないパターンだと確定困難。
Re: (スコア:3)
> ダブルクォートの出力方法がそもそも複数ある
他の方も言及されてますが
RFC 4180 というデファクトスタンダードがあります。
それによればエスケープ方法は二重引用符を重ねる形式:
> "aaa","b""bb","ccc"
の1パターンのみ許容されるということになりますね。
つまり「RFC 準拠のCSVでお願いします!」と言っとけばOKってことです。
http://www.kasai.fm/wiki/rfc4180jp [kasai.fm]
Re:CSVなら任せて安心 (スコア:0)
RFCになってるのにデファクトスタンダードとはこれいかに。
Re:CSVなら任せて安心 (スコア:1)
// デファクトにも達していない可能性大
Re: (スコア:0)
僕の考えた最強のデファクトスタンダードの定義は今はいいです。