おはようございます。じぇいかわさきです。
最近の出来事で、痛切に自分の思い込みは良くないなって感じたことがあります。
近頃、ラズパイでIoTに挑戦だなんて粋がっていたんです。年甲斐もなくね。そんな中での出来事です、
CSVファイルって知ってます？
あなたはCSVファイルって知っています？正確に言うならば、CSV形式ファイルということになると思いますが。
[ads]
ウィキペディアでは以下のように言っております。
comma-separated values（略称：CSV）は、いくつかのフィールド（項目）を区切り文字であるカンマ「
,」で区切ったテキストデータおよびテキストファイル。拡張子は.csv、MIMEタイプはtext/csv。「comma-separated variables」とも言う。広く普及した訳語はないが、「カンマ区切り」などとも呼ばれる。Microsoft Excelでは「CSV (カンマ区切り)」としている。
データ交換用のデファクトスタンダードとして、古くから多くの表計算ソフトやデータベースソフトで使われているが、細部の実装はソフトによって異なる。それらを追認する形で、2005年10月、RFC 4180 で Informational（IESGの外部で決定された有用な情報の提供）として仕様が成文化された。
類似したフォーマットとして、タブで区切られた tab-separated values (TSV)や、欧文間隔 (いわゆる半角スペース) で区切られた space-separated values (SSV) などがあり、これらをまとめて character-separated values (CSV)、delimiter-separated values (DSV) とも呼ばれることも多い。
引用：CSV形式
ご存知の通り、CSVファイルは、日本語で翻訳すると「カンマ区切り」のファイル形式です。1行の文字列を半角カンマ文字「,」で複数のデータ項目に分割します。
また、区切り文字として、タブ文字や半角スペース、半角パイプ「|」などを使用した形式もCSV(character-separated values)ファイルと言う場合もありますので、相手に伝える時は「カンマ区切りのCSVファイル」と言った方が誤解はないと思います。
一般的に、表計算ソフトやデータベースへのデータ書込み用ファイルとして用いられていますよね。
自分も、よくデータベースの内容を書き出し、Excelなどで読み込む時に使用しているファイルの形式です。
普段なにげなしに使っていたんですが、これが、今回のIoTチャレンジの中で、本当に最後の最後に引っかかったんですね。
焦りまくりでしたよ。
何に引っかかったか
実はですね、Pythonで書いたプログラムで、温度湿度を測定して、データをMariaDBに記録したんです。
まあ、ここまでは良いですよね。
記録したデータをmacで使いたかったので、SQL文を使いCSVファイルで書き出したのです。
ここで、例のCSVファイルが出てくるんですよ。
SQL文で取り出したデータファイルは、指定した通り、拡張子がCSVでできていました。
今度は、このデータをmac側のMariaDBへインポートしたんです。
SQL文が間違っているようで、何回かエラーは出たのですが、そのエラーを修復していちようインポートが完了したんです。
このインポートも、無事問題もなくできたのですが、チョットだけ気になるところは、レコードは262問題なく読み込まれたのですが、ワーニングがなんと786も出ているじゃないですか。
[ads]
心配になり、selectを使ってデータを確認すると、なんと表計算シートではちゃんと見えている温湿度の値が、全て0になっているんです。
全てが0なんです。もう見事としか言いようがない。
ワーニングが786、読み込みレコードは262。これから分かることは、3カラム全部の値がおかしいと言うことですね。
何に引っかかったのか？
散々考えた挙げ句、分かったのはインポートしたときのSQL文の間違いだったのです。
インポートに使用したSQL分は
load data local infile “/User/thorie/test_sample.csv” into table test_sample fields terminated by “,” ;
ここに落とし穴が有ったんです。
一般的にデータベースからエクスポートしたファイルは、カンマ区切りのファイルとなっています。だからCSVと言う拡張子が付いているんです。
そう自分は信じていました。
恐ろしいのは、この習慣でカンマ区切りになっているからCSVファイル何だという思い込みですね。
ウィキペディアに書かれているように
類似したフォーマットとして、タブで区切られた tab-separated values (TSV)や、欧文間隔 (いわゆる半角スペース) で区切られた space-separated values (SSV) などがあり、これらをまとめて character-separated values (CSV)、delimiter-separated values (DSV) とも呼ばれることも多い。
もCSVファイルと言うということ。
つまり、CSVと言う拡張子が付いていても、必ずしもカンマ区切りではないと言うことを忘れてはいけないんです。
調べていったら、MariaDBでエクスポートすると、標準の書式はカンマ区切りではなく、タブ区切りのようなんです。
ちゃんとマニュアルを読んでいなかった事が、最大の落ち度であるということ。つまり、自分の常識は、世の中では非常識だったということですね。
思い込みは、ホント恐ろしいですね。
結局どうして改善したか
何回もテーブルを作り直し、何回もインポートしなおしても全然改善されなかったのは、このCSVファイルはカンマ区切りのファイルではなかったからです。
そのため、最初のカラムに全データが入ってしまい、残りの2つのカラムには0が入ってしまったのです。
しょうがない、もう一度テーブルを削除して再度作り直し、以下のSQL分で再びインポートしました。
load data local infile “/User/thorie/test_sample.csv” into table test_sample fields terminated by “\t” ;
変化点は、最後のterminated byの文字を”,”から”\t”に変えたのです。
結果は見事、ワーニングが0になりました。当たり前といえば、当たり前。
そして、selectでデータを読み出してみると、全てのカラムにデータがきちんと格納されていました。
これでやっと、macでの次の開発準備が整いました。
まとめ
人の思い込みは本当に恐ろしい。これは、ブログを書いているときの誤字と同じですね。
書いている人は、字が間違っていても自分で書いているので、書いた通りに読めてしまう。
これが第三者に読んでもらうと、間違いが一発で分る。つまり、思い込みっていうやつですね。
今回、本当に最後の最後でハマりました。何度確認してもデータは間違いなく記録されている。エクスポートされたデータも表計算アプリで見ると、ちゃんとデータは入っている。
でも何故インポートするとダメなのか？
CSV形式は必ずしもカンマ区切りではない。総認識したのは、ウィキペディアを読んで初めて気が付きました。
勝手な思い込みでは、本当に無駄な時間を過ごしてしまいますね。
ブログの収益化と同じで、自分でかってに思っていること自体が、実は本当に無駄なことで、もっと他のことに注力すべきことがあるのだと、改めて感じました。
なんで？ そう思うことは非常に大事ですが、その時に自分の固定概念も一緒に捨てて考えなければ、全く意味が無いってことですね。
ホント、今回はためになりました。
喉元過ぎて、今回痛い目にあった事を忘れないようにしたいと思います。
誰かの役に、きっとたつと信じて。
[twt]
