アカウント名:
パスワード:
CSVファイルを開いたら電話番号の頭の0が消えているというお問い合わせに対応するのは嫌です
CSVのパーサーをCで自前で作ろうとして意外と苦労しました。結局「"」まわりは中途半端な実装になってしまった。（仕様上問題はないんですが、罪滅ぼしとしてID）ググると先人の方たちの苦労が垣間見れます。http://f4.aaacafe.ne.jp/~pointc/log1227.html [aaacafe.ne.jp]
私はむしろデータは全て文字列で、それを数値として再解釈するかどうかは実装依存、ダブルクォーテーションで囲むのが通常で、囲まないのは例外的な省略記法、くらいに割り切って解釈してます。
#データにカンマ改行ダブルクォーテーションが含まれる場合にダブルクォーテーション記法にしろ？そんな分岐やってられねーよ。ハナから全部囲ったらぁ！
そんな独自解釈するよりも、RFC読めば良いのに。
Excelに食わせる前提だとあり得る解釈RFCに従ったところでソフトごとに方言多すぎ
ソフトごとに方言が多すぎたのでRFCで統一を図ったけど、そもそもRFCを読んでくれない。「RFCっていんたあねっとの決まりでしょ？CSV関係ないじゃん」
なるほど。一理以上のものを感じます。アプリ側から見れば確かにそうですね。
プログラマなので内部処理的に理解できなくは無いけど、「(小数表記ではない)0で始まる数字の列を整数とみなす」「数値の書式を変更したら日付の欄も数値に変換する」あたりは「数値と数字の区別がついてないアプリ」の方が悪いと思う
桁位置縛りの固定長CSVというのもありますよ。区切り文字意味ねえw
RFC4180もそう言った謎仕様に対して止めてくれの意味込めて作ったみたいだけど、そういうのやらかすとこは唯我独尊だから無駄だったと。。。
COBOLでファイルを作ると可変長CSVを作るのが非常に困難なのですよ >桁位置縛りの固定長CSV表計算ソフトでの固定長ファイルの読ませ方を説明するのは非常に面倒くさいので、簡単に読ませるために区切り文字だけ付けてCSVにするという…
異システム間での情報交換のためのものなのに「自分が」面倒だから規則無視して相手にトラブル押し付けるの？
その辺りも覚悟のうえでCOBOL選んだんだから自己責任で解決してください。
tcp/ipプロトコル仕様無視する輩と同じ事言ってますよ。
どの辺が規則無視してるの？
CSVは列をカンマで区切る、行を改行で区切る程度しか仕様が決まってないからね。文字列にカンマや改行が含まれていた時にどうするか方言があるけども。だから固定長だからってカンマと改行で区切ってさえいれば規則には合ってるんだよね。なんで規則を無視したと思い込んだんだろうねえ。
確かに気持ちは悪いがCSVを空白でパディングしてはならないなんて聞いたことがない
> COBOLでファイルを作ると可変長CSVを作るのが非常に困難なのですよ
う～ん、、、これもCOBOLを知らない人のCOBOL叩きだな。
#2942535のACです
>う～ん、、、これもCOBOLを知らない人のCOBOL叩きだな。
え? 不可能とはいわないまでも、困難というか、そこまで手をかけても得るものが少ないくらいには非常に面倒くさいでしょ?というか、面倒くさすぎて実際に固定長CSV作ってましたし
オブジェクト指向COBOL化以降だと違うかもしれませんが追いかけてない
IBMによると、JSONに変換する関数はあるみたい（Googleで検索しただけ）なので、それでJSONにしてから、Pythonかなにかで並ばせ直せばいいんじゃないでしょうか。
> そこまで手をかけても得るものが少ないくらいには非常に面倒くさいでしょ?
ほんと、何も知らないのだな。
どうすればいいのか説明できないなら無理にコメントしなくてもいいんですよ＾＾
知っているがお前の態度が気に食わない。
#馬鹿なのになんで教えてもらえると思っているのだろう?
COBOLなんて別に知りたくもないんですけどね。無理しなくてもいいですよ＾＾
やっと無知を自白しましたね。
私の方は適切かつ十分な反論が終わっているので無理とか言われてもなにがなんだか。。。
例えば、ドイツ語圏では小数点がカンマなので、円周率は3,14159....ですが、2の平方根と円周率とオイラー数を列挙した場合、
1,4142, 3,14159, 2,71828
となり、これをCSVとして再解釈すると、
1, 1442, 3, 14159, 2, 71828
となって、フィールド数が倍になってしまいます。そこで、それを避けるために一続きのフィールドを二重引用符でくくるわけです。
"1,4142", "3,14159", "2,71828"
文字列は""でくくるっていうのは、勝手な思い込みなので、そういう独自仕様を声高に叫ぶ人がいる限り、世界は平和にはならんでしょうな。
Excelだと、ロケールがドイツの場合、CSVの区切り文字はセミコロンになります。あれはたぶん地域の設定の「区切り記号」を使っているのかな。
Cemicolon Separate Value
# 苦しい
今は、 Character Separated Value の略らしいですよ。なので、タブ区切りも CSV なんだとか。
そもそも、""で囲まれていても文頭の0は削除されるのが問題なのですが……
表計算ソフト？桁可変の10進数の数値扱うのが主体のソフトだから、文字は”一応”使用可能なだけ。あくまでイレギュラーな値。
先頭ゼロは数値として扱えたとしても10進変換が間に挟まることになってたかと。
表計算ソフトは「表」が大事なんだから文字もちゃんと扱えないとダメだよ。せめてダブルクォートで囲んだ「"01-01"」くらいちゃんと「01-01」として解釈しないと。
それに表計算ソフトなら表計算ソフトで「0.010」と「0.01」の違いは理解してほしいものだ。
> でも、世間様では「項目を,で分ける」でCSVなんですよね。そもそもCSVが何の略かを考えれば自明のような...カンマで区切られていればCSV、タブで区切られていればTSV、スペースで区切られていればSSV、でしょうに。
生物学やっている人間なら、遺伝子名が日付に替わるというのは定番中の定番。遺伝子名がずらっと並んでいるカラムに、突然「10月4日」とか入っているExcelを1ヶ月に1～2回は見る。
今こそSylk形式ファイルの復権を
.txt にリネームして、Excelで開く時に当該フィールドを文字列扱いにする。じゃダメですか？
これ、ちゃんと取りこむ方法あるのに、1人も例示できなくてﾜﾛﾀ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
もう (スコア:0)
CSVファイルを開いたら電話番号の頭の0が消えているというお問い合わせに対応するのは嫌です
それはMSのせいでは無いよなぁ (スコア:2)
でも、世間様では「項目を,で分ける」でCSVなんですよね。
桁数に意味があるのに、"でくくらないなんていうのは当たり前。以前、情報処理センターから提供を受けた「CSVファイル」では行毎に含まれている項目が違う、かつ、項目がレコード毎に可変というすさまじいものも・・・（どうも汎用機の非RDBMSのデータをそのまま出力したみたい）。
他にも政府系からは親レコードと子レコードを一致させるための項目が無いデータ（それぞれの順番だけでマッチさせる前提らしい）が来るとか、すごい世界ですよ。
で、頭の０が消えて、という人は「数値と数字の区別がついてない」人ですねぇ。見てると、理系・文系は関係ないし、ITが本職の人の中にも区別がついてない人がいることがあります。
Re:それはMSのせいでは無いよなぁ (スコア:1)
CSVのパーサーをCで自前で作ろうとして意外と苦労しました。
結局「"」まわりは中途半端な実装になってしまった。
（仕様上問題はないんですが、罪滅ぼしとしてID）
ググると先人の方たちの苦労が垣間見れます。
http://f4.aaacafe.ne.jp/~pointc/log1227.html [aaacafe.ne.jp]
Re:それはMSのせいでは無いよなぁ (スコア:1)
私はむしろ
データは全て文字列で、それを数値として再解釈するかどうかは実装依存、
ダブルクォーテーションで囲むのが通常で、囲まないのは例外的な省略記法、
くらいに割り切って解釈してます。
#データにカンマ改行ダブルクォーテーションが含まれる場合にダブルクォーテーション記法にしろ？そんな分岐やってられねーよ。ハナから全部囲ったらぁ！
Re: (スコア:0)
そんな独自解釈するよりも、RFC読めば良いのに。
Re: (スコア:0)
Excelに食わせる前提だとあり得る解釈
RFCに従ったところでソフトごとに方言多すぎ
Re:それはMSのせいでは無いよなぁ (スコア:1)
ソフトごとに方言が多すぎたのでRFCで統一を図ったけど、そもそもRFCを読んでくれない。
「RFCっていんたあねっとの決まりでしょ？CSV関係ないじゃん」
Re: (スコア:0)
なるほど。
一理以上のものを感じます。
アプリ側から見れば確かにそうですね。
Re:それはMSのせいでは無いよなぁ (スコア:1)
プログラマなので内部処理的に理解できなくは無いけど、「(小数表記ではない)0で始まる数字の列を整数とみなす」「数値の書式を変更したら日付の欄も数値に変換する」あたりは「数値と数字の区別がついてないアプリ」の方が悪いと思う
うじゃうじゃ
Re: (スコア:0)
桁位置縛りの固定長CSVというのもありますよ。区切り文字意味ねえw
RFC4180もそう言った謎仕様に対して止めてくれの意味込めて作ったみたいだけど、そういうのやらかすとこは唯我独尊だから無駄だったと。。。
Re: (スコア:0)
COBOLでファイルを作ると可変長CSVを作るのが非常に困難なのですよ >桁位置縛りの固定長CSV
表計算ソフトでの固定長ファイルの読ませ方を説明するのは非常に面倒くさいので、簡単に読ませるために区切り文字だけ付けてCSVにするという…
Re: (スコア:0)
異システム間での情報交換のためのものなのに「自分が」面倒だから規則無視して相手にトラブル押し付けるの？
その辺りも覚悟のうえでCOBOL選んだんだから自己責任で解決してください。
tcp/ipプロトコル仕様無視する輩と同じ事言ってますよ。
Re: (スコア:0)
どの辺が規則無視してるの？
Re: (スコア:0)
CSVは列をカンマで区切る、行を改行で区切る程度しか仕様が決まってないからね。
文字列にカンマや改行が含まれていた時にどうするか方言があるけども。
だから固定長だからってカンマと改行で区切ってさえいれば規則には合ってるんだよね。
なんで規則を無視したと思い込んだんだろうねえ。
Re: (スコア:0)
確かに気持ちは悪いがCSVを空白でパディングしてはならないなんて聞いたことがない
Re: (スコア:0)
> COBOLでファイルを作ると可変長CSVを作るのが非常に困難なのですよ
う～ん、、、これもCOBOLを知らない人のCOBOL叩きだな。
Re: (スコア:0)
#2942535のACです
>う～ん、、、これもCOBOLを知らない人のCOBOL叩きだな。
え? 不可能とはいわないまでも、困難というか、そこまで手をかけても得るものが少ないくらいには非常に面倒くさいでしょ?
というか、面倒くさすぎて実際に固定長CSV作ってましたし
オブジェクト指向COBOL化以降だと違うかもしれませんが追いかけてない
Re:それはMSのせいでは無いよなぁ (スコア:1)
IBMによると、JSONに変換する関数はあるみたい（Googleで検索しただけ）なので、それでJSONにしてから、Pythonかなにかで並ばせ直せばいいんじゃないでしょうか。
Re: (スコア:0)
> そこまで手をかけても得るものが少ないくらいには非常に面倒くさいでしょ?
ほんと、何も知らないのだな。
Re: (スコア:0)
どうすればいいのか説明できないなら無理にコメントしなくてもいいんですよ＾＾
Re: (スコア:0)
知っているがお前の態度が気に食わない。
#馬鹿なのになんで教えてもらえると思っているのだろう?
Re: (スコア:0)
COBOLなんて別に知りたくもないんですけどね。無理しなくてもいいですよ＾＾
Re: (スコア:0)
やっと無知を自白しましたね。
私の方は適切かつ十分な反論が終わっているので無理とか言われてもなにがなんだか。。。
Re: (スコア:0)
例えば、ドイツ語圏では小数点がカンマなので、円周率は3,14159....ですが、2の平方根と円周率とオイラー数を列挙した場合、
1,4142, 3,14159, 2,71828
となり、これをCSVとして再解釈すると、
1, 1442, 3, 14159, 2, 71828
となって、フィールド数が倍になってしまいます。そこで、それを避けるために一続きのフィールドを二重引用符でくくるわけです。
"1,4142", "3,14159", "2,71828"
文字列は""でくくるっていうのは、勝手な思い込みなので、そういう独自仕様を声高に叫ぶ人がいる限り、世界は平和にはならんでしょうな。
Re:それはMSのせいでは無いよなぁ (スコア:1)
いわれて検索してみると、現在のCSVは制御文字を含むときのみ囲むようですね。
私は桐のあたりでCSVを覚えたので、文字列は囲むと覚えてました（BASICでCSVを作るときの方法とか）。
Re: (スコア:0)
Excelだと、ロケールがドイツの場合、CSVの区切り文字はセミコロンになります。
あれはたぶん地域の設定の「区切り記号」を使っているのかな。
Re: (スコア:0)
Cemicolon Separate Value
# 苦しい
Re: (スコア:0)
今は、 Character Separated Value の略らしいですよ。なので、タブ区切りも CSV なんだとか。
Re: (スコア:0)
そもそも、""で囲まれていても文頭の0は削除されるのが問題なのですが……
Re: (スコア:0)
表計算ソフト？
桁可変の10進数の数値扱うのが主体のソフトだから、文字は”一応”使用可能なだけ。
あくまでイレギュラーな値。
先頭ゼロは数値として扱えたとしても10進変換が間に挟まることになってたかと。
Re: (スコア:0)
表計算ソフトは「表」が大事なんだから文字もちゃんと扱えないとダメだよ。
せめてダブルクォートで囲んだ「"01-01"」くらいちゃんと「01-01」として解釈しないと。
それに表計算ソフトなら表計算ソフトで「0.010」と「0.01」の違いは理解してほしいものだ。
Re: (スコア:0)
> でも、世間様では「項目を,で分ける」でCSVなんですよね。
そもそもCSVが何の略かを考えれば自明のような...
カンマで区切られていればCSV、タブで区切られていればTSV、スペースで区切られていればSSV、でしょうに。
Re:もう (スコア:2, 興味深い)
生物学やっている人間なら、遺伝子名が日付に替わるというのは定番中の定番。
遺伝子名がずらっと並んでいるカラムに、突然「10月4日」とか入っているExcelを1ヶ月に1～2回は見る。
Re: (スコア:0)
今こそSylk形式ファイルの復権を
Re: (スコア:0)
.txt にリネームして、Excelで開く時に当該フィールドを文字列扱いにする。
じゃダメですか？
Re: (スコア:0)
これ、ちゃんと取りこむ方法あるのに、1人も例示できなくてﾜﾛﾀ