さっきまで読み込めていたファイルが読み込めない

TRNSYSのType9はCSVなどテキスト形式のデータファイルを読み込むコンポーネントです。計算用のデータの読み込みなどでよく使われます。

いつものようにType9でファイルを読み込もうしたら、いきなりエラー発生。既存のCSVのデータを変更しただけなんだが、はて？

エラーメッセージは以下のような内容。

*** Fatal Error at time   :         0.000000
    Generated by Unit     :     4
    Generated by Type     :     9
    Message               : Unable to correctly read from the supplied data file. Please check the file and re-run the simulation. The most likely cause of this problem is an empty or non-existent file.
提供されたデータファイルから正しく読み取れませんでした。ファイルを確認し、シミュレーションを再実行してください。この問題の最も可能性の高い原因は、空のファイルまたは存在しないファイルです。

CSVファイルの一部の値を変更しただけなので、空のファイルでもなければ存在しないファイルでもない。念のためメモ帳で開くと、データはちゃんと存在している。

と、しばらく考えてて気がついた。Excelで元データを編集して、保存する方法を間違えていた。

ExcelからCSV形式で保存する場合、2つ形式があります。

• CSV UTF-8(コマン区切り)
• CSV (コマン区切り)

後者が正解なんですが、うっかり前者で保存していたらしい。「CSV (コマン区切り)」で保存し直したら無事に読み込めました。

エラーの原因は？

以下、ファイルフォーマットの話なので、興味のある方向けの情報です。

Type9はANSI形式（ASCII形式）のテキストファイルを読み込みます。ExcelでCSVを保存する場合「CSV (コマン区切り)」を選ぶとANSI形式のファイルで保存されます。

「CSV UTF-8(コマン区切り)」を選ぶと、UTF-8形式で保存されます。Type9では対応していない形式なので上記のエラーが発生することになります。

余談ですが、UTF-8はANSI形式と英数字のデータは互換性があります。数値だけのデータであればANSI、UTF-8でも基本的に同じデータになります。実際、まったく同じデータなのでプログラム的には区別が付かない、というか区別しようがありません。

ところがExcelではUTF-8形式でファイルを保存すると、「BOM付きUTF-8」と呼ばれる形式で書き出します。BOMはbyte order mark（バイト順マーク）の意味で、ファイル形式の識別に使われます。前述の話と矛盾しているように聞こえますが、ANSI, UTF-8ファイルとして区別が付かないなら付くようにデータの先頭に識別用のデータを挿入します。識別データでファイルの種類の区別がつくので、これはこれでファイルに日本語のデータを含む場合は便利な仕組みです。

が、数値を扱うプログラムからすれば予想外のデータが追加されたファイルのため、却ってジャマになってしまう訳です。

動作環境

以下の環境で動作を確認しています。
Windows10 Pro(64bit, 20H2)
TRNSYS18.02.0002(64bit)
Microsoft® Excel® for Microsoft 365 MSO (16.0.13929.20222) 64 ビット

Tweet

Pocket