データ解析ソフトRでのファイル入力read.csvがエラーになります

データ解析ソフトRでのファイル入力read.csvでの問題です。

以下のファイルはヘッダーなしのcsvファイルdata1.csvです。
1,60.4,60.1,60.3
2,60.1,59.5,60.5
これを、data<-read.csv("data1.csv", header=F)
全く問題なく読めます。

以下のファイルはヘッダーなしのcsvファイルdata2.csvです。
1,60.4,60.1,60.3
2,60.1,59.5,60.5
これを、data<-read.csv("data2.csv", header=F)
とすると、
---
type.convert.default(data[[i]], as.is = as.is[i], dec = dec, でエラー:
'<ef>ｻ<bf>1' に不正なマルチバイト文字があります
---
となりエラーとなります。一見全く同じ内容です。

この２つのファイルは同じ内容ですが、作成方法が違います。
うまくいく方（上）は本に付属のサンプルファイルであり、
うまくいかない方（下）はエクセルファイルからcsvファイルとして出力したものです。

このトラブルの原因を教えて頂きたいのですが。両ファイルともUTF-8となっています（エディタで確認）。
よろしくお願いします。
※自分が作成したcsvファイルでRのread.csvがちゃんと処理できたためしがないのですが。
csvファイルって見えないところにヘッダーがあったりするのでしょうか。

No.7 回答者： rinkun 回答日時： 2022/04/02 21:38

BOMってByte Order MarkなのでもともとUnicode(基本的には16ビットコード(UTF-16))の上位バイトが先に来るのか下位バイトが先に来るのかを示すためのものなのです。

それでUTF-8はエンコード仕様としてバイト順まで決まっているのでBOMは必要ないはずなのですが、何故かBOM付きUTF-8なんてものがあるのがそもそもの間違いなのです。
ただ実際にはBOM付きUTF-8はちょくちょく見かけますね。Windowsのメモ帳も一時期はUTF-8にするとBOM付きでした。今はデフォルトはBOMのないUTF-8になっていますがBOM付きUTF-8でも保存できます。
ExcelがBOM付きUTF-8のCSVを出しているならテキストエディタ(メモ帳でも可)で一度開いてUTF-8(BOMなしのもの)で保存し直せばRで問題なく読めるようになると思います。
なお日本語文字を含む場合はWindows上のRだとUTF-8が化ける恐れがあるので化ける場合はSJISにして下さい。

この回答へのお礼

回答ありがとうございます。秀丸エディタでもBOMのオン・オフを指定できます。またSJISでも動作することを確認しました。なんでBOMなんてものがあるんだと思いました。

お礼日時：2022/04/05 00:25

No.6 回答者： rinkun 回答日時： 2022/03/31 22:29

動作確認したので回答します。

数字だけのExcelデータをCSVで保存した場合、Excel2013で保存した場合はテキストエディタで開くとSJIS扱いになりました。ASCIIしか含まないUTF-8テキストはSJISと区別できないので妥当です。一方でMicrosoft365のExcel(バージョン2202)だと同じデータがBOM付きUTF-8テキストになります。
# ちなみに日本語文字が入っていると最新版もSJISテキストのCSVになる
# バージョン2202のバグかも

一方でR(これは最近入れたのでバージョン4.1.3だったかと)ではSJIS扱いのCSVは普通に読めますが、BOM付きUTF-8のCSVは不正なマルチバイト文字のエラーになります。
以上からNo.1-4の方の回答が正しいようです。

この回答へのお礼

回答ありがとうございます。文字コードに関してあまり理解していないのですが、トラブルが生じたらUTF-8にすればいいんだ、ということだけ覚えていました。ところが、BOMが出てきてそれではダメということになりました。一応BOMをコントーロールする方法（それを付けたり、削除したりする方法）も覚えたのですが、何とめんどくさいことしてくれたんだろうと思います。覚えることが減ったと思ったのに忘れてはならないことができてしまいました。

お礼日時：2022/04/01 19:44

No.5 回答者： ssaw 回答日時： 2022/03/30 04:56

No.4

>0.001を１０００回足せば、１になるはずですが、計算結果は１ピッタリにはなりません。

そんなに多くしなくても、たとえば、0.1を10個足しても1ピッタリにはなりません。
Rで0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1を計算すると答は1と表示されますが
0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1==1だとFALSEになります。
実際には1と少し違うのに1と表示しています。
Pythonだと0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1は0.9999999999999999に
なります。

No.4 回答者： tatsumaru77 回答日時： 2022/03/28 11:33

No2です。

結局、うまくいかない方（下）は、どうなったのでしょうか？
BOMがついていて、BOMをはずしたたら、うまく読み込めたと解釈して良いのでしょうか。こちらの回答が正しかったのかどうか、気になり念のため確認した次第です。


>これだけ知っておけばコンピュータリテラシはOKというような範疇があるのでしょうか。
そのような、範疇があるかどうかはわかりませんが、
あなたが、プログラマーもしくはSEの立場でしたら、
CPUのエンディアン及び浮動小数点数
については、理解しておく必要があるかと思います。

エンディアンについて
https://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%B3 …

浮動小数点について
https://ja.wikipedia.org/wiki/%E6%B5%AE%E5%8B%95 …

エンディアンについては、バイナリーデータを扱うとき、
ビッグエンディアンなのかリトルエンディアンなのかを押さえておく必要があります。
（通信プロトコル上はビッグエンディアンを使用することが決められていますが、INTEL系のCPU（AMDも含む）はリトルエンディアンです）

浮動小数点数については、例えば、
0.001を１０００回足せば、１になるはずですが、計算結果は１ピッタリにはなりません。必ず誤差が出ます。
小数点を含む計算が、電卓でたたいたような結果を期待するには無理がある
ということを理解しておく必要があります。また、誤差を極力出ないようにするための工夫も必要になります。

上記以外については、いまのところ思い当たりません。

この回答へのお礼

経過の回答が遅れてすみません。この問題は”BOMあり”が原因であり、それを外せば予定通り動作することを確認しました。

お礼日時：2022/04/05 00:22

No.3 回答者： tatsumaru77 回答日時： 2022/03/28 09:31

No2です。

添付図を忘れました。ちょっと、みにくいかもしれませんが、こちらになります。

No.2 回答者： tatsumaru77 回答日時： 2022/03/28 09:28

No1です。

＞エディタで保存するときにBOMの有無を指定できるのでしょうか。
うまくいかない方（下）は、添付図のように、BOMにチェックがいれてあるはずです。このチェックをはずしてください。そして上書き保存してください。そうするとBOMが外れます。


＞逆にBOMの効用というか、どう言う場合に役に立つのかということです
が。
一般ユーザーからすると、百害あって一利なしのような気がします。
もともとは、漢字とかの文字を表現するために、いろいろな文字コードが乱立している状態でした。（日本ならシフトJISとかEUCとかです。）
これを世界中の文字コード１つに統一する試みが行われました。
これをユニコードと言ってますが、（マイクロソフトは内部コードはユニコードにしてあります）、ユニコードでもマシンのメーカー（コンピュータのメーカー：INTEL等）により、内部の持ち方に違いが発生してしましました。この違いを明確にするために、ファイルの先頭にBOMをつけて管理することになりました。
詳しくは、
https://ja.wikipedia.org/wiki/%E3%83%90%E3%82%A4 …
を参照ください。

我々一般ユーザーの立場としては、
通常は、ユニコードはUTF-8しか使いません。そしてUTF-8はBOMがないことを前提にしているアプリケーションが大部分です。
従って、
１．動作がおかしかったら、BOMの有無を疑う。
２．そのソフトが明示的にBOMが有ることを前提にしていなければ、BOMを外してから、動作させる。
ということを踏まえていれば、それでよいかと思います。

この回答へのお礼

詳細な回答を頂き有難うございます。
今回、はじめてBOMという仕様に出会いました。もし、このようなものを知らず、ここへの質問もしなかったらこのトラブルを回避する方法を発見できなかったはずです。今回の件でUTF8のファイル読み込みで何か不具合があったらBOMを疑うということは憶えました。
また、BOMを知らない状態でファイルの読み書きをプログラムで実行していたとしたら、うまく読んだような顔をして全くこちらの意図がプログラムに通じてない、間違ったデータの読み込みで結果を誘導していないかという疑義が生じます。またBOMはよしとして、それ以外にBOM風の仕様があってそれを知らないとトラブルが解決できないというようなものがありそうな気がしてきました。これだけ知っておけばコンピュータリテラシはOKというような範疇があるのでしょうか。

お礼日時：2022/03/28 10:48

No.1 回答者： tatsumaru77 回答日時： 2022/03/28 04:59

エディターは何を使用されていますか。

うまくいかない方（下）のファイルにはBOMがついていませんでしょうか。
BOMについては、下記URLを参照ください。
https://uxmilk.jp/48923

https://ja.wikipedia.org/wiki/%E3%83%90%E3%82%A4 …

両ファイルについて、BOMの有無を確認してください。

この回答へのお礼

回答ありがとうございます。エディタは秀丸です。両ファイルともUTF-8です。BOMという概念はこれまで全くノーマークでした。BOMの有無に関しては無しにしないと動作しないということでしょうか。BOMをコントロールする方法が不明なのですが。エディタで保存するときにBOMの有無を指定できるのでしょうか。逆にBOMの効用というか、どう言う場合に役に立つのかということですが。

お礼日時：2022/03/28 08:29