Shift_JISのCSV、
見た目は普通なのに処理できなかった。

FIRST QUESTION

ファイルはある。
中身も見える。なのに、なぜ？

最初に見るのは、 ファイルそのものです。

ファイル名は合っているか。

拡張子はCSVになっているか。

必要な項目が入っているか。

データの並びは合っているか。

ぱっと見では、 特に問題がないように見えることもありました。

でも、 プログラムから読み込むと 想定どおりに処理できない。

そこで初めて、 「このCSV、何の文字コードなんだ？」 というところを見ることになりました。

ENCODING

CSVの見た目が同じでも、
中の文字コードは違う。

CSVは、 カンマで区切られた テキストファイルです。

ただ、 テキストとして どの文字コードで保存されているかは ファイルによって違います。

自分が扱っていた連携では、 Shift_JISのCSVを扱う場面がありました。

一方で、 プログラム側では UTF-8を前提に扱っていることもあります。

ここが合っていないと、 同じCSVでも 正しく読み込めないことがあります。

見た目

商品コード,商品名,数量
A001,サンプル部品,10


実際には

Shift_JIS で保存されているCSV

UTF-8 で保存されているCSV

では、同じ文字でも
ファイル内部の表現が違う。

人がExcelやエディタで開いたときに 普通に見えるからといって、 プログラムからも同じように 読めるとは限りませんでした。

SYMPTOMS

文字化けだけが、
問題じゃなかった。

文字コードが違うと聞くと、 最初に思い浮かぶのは 文字化けでした。

もちろん、 日本語が正しく表示されないこともあります。

でも外部連携では、 それだけではありません。

読み込んだ値が 想定した文字列にならない。

その値を使った検索で レコードが見つからない。

CSVの項目を 正しく扱えない。

そのまま後続処理へ進んで、 別の場所でエラーになる。

つまり、 文字コードの問題が 後続処理の不具合として見える こともありました。

だから、 エラーが出た場所だけを見るのではなく、 そもそも元のファイルを 正しく読み込めているかを見る必要があります。

SPECIFICATION

自分たちが使いたい形式より、
連携先が何を求めているかを見る。

外部連携では、 「UTF-8の方が扱いやすいから」 だけで決めることはできません。

連携先のシステムが Shift_JISを前提にしているなら、 その仕様へ合わせる必要があります。

逆に、 NetSuite側で受け取ったあとに どう扱うのかも考える必要があります。

文字コードだけではなく、 ファイル連携では いくつかの仕様がセットになっています。

• ファイル名
• 文字コード
• 改行コード
• 区切り文字
• 項目数
• 項目の並び
• 日付や数値の形式

CSVというだけでは、 連携仕様としては足りません。

ファイルの形式そのものも、 システム間のインターフェース仕様。

そう考えるようになりました。

TROUBLESHOOTING

コードを見る前に、
実際のファイルを見る。

CSV連携でうまくいかないと、 つい読み込み処理や SuiteScript側のコードを 先に見たくなります。

でも、 元のファイルそのものが 想定と違っていれば、 コードを追い続けても 原因にはたどり着けません。

そこで、 実際のCSVを取得して 中身を確認しました。

ファイル名は正しいか。

必要な行や列は入っているか。

日本語は正しく見えるか。

どの文字コードになっているか。

それを確認した上で、 NetSuite側の読み込み処理や 後続処理を見ていきます。

SFTP連携でも同じでしたが、 データが実際にどうなっているかを 先に確認する だけで、 切り分けがかなりしやすくなりました。

SFTP連携を外から確認しながら切り分けた話 →

CONVERSION

必要なら、
読む側・出す側で変換する。

連携元と連携先で 使う文字コードが違う場合は、 どこかで変換する必要があります。

受け取ったShift_JISのデータを 内部で扱いやすい形へ変換する。

逆に、 外部システムへ渡す前に 相手側が求める形式へ変換する。

重要なのは、 とりあえず変換することではなく、

「どこから来たデータで、 次にどこへ渡すのか」 を見て、 変換する場所を決めることでした。

文字コードも、 そのデータの流れの一部として 見るようになりました。