TSV を CSV に変換

タブ区切りのファイルを書き出すシステムは多く、それを受け付けるシステムはほとんどありません。分析コンソール、広告プラットフォーム、研究機器、データベースクライアントはどれもタブを使います。データがカンマだらけだからです。受け取る側の CRM やメール配信ツール、会計ソフトには「CSV をアップロード」という欄があり、それは文字どおりの意味です。

ファイルのリネームを試す価値はあります。30 秒で済み、少数派のインポートツールは拡張子ではなく実際の区切り文字を判定するからです。Excel もその 1 つです。ただし多数派はそうしません。各行をカンマで分割し、12 列を期待していたのに 1 列しか見つからず、役に立たないメッセージでファイルを拒否するか、すべての行を最初のフィールドへ取り込みます。後者のほうが厄介です。うまくいったように見えるからです。

この変換はタブをカンマに置き換える単純な検索置換ではなく、そうであってはいけません。「Berlin, Germany」というフィールドは、これから区切り文字になろうとしている文字をすでに含んでいるので、書き出す際にダブルクォートで囲まれ、そのフィールドの中のダブルクォートは二重にされます。

これは正しく、普遍的な処理ですが、結果を初めてテキストエディターで開いた人を驚かせます。必要なフィールドだけが引用符付きになり、残りは素のまま書かれます。住所や説明の列だけが引用符付きで、それ以外はそうではないファイルこそ、正しく整った CSV の姿です。アップロードする価値のあるインポートツールなら、この慣習を読めます。読めないなら、引用符を取り除くのではなく、別のインポート経路を探すべきだというサインです。

タブ区切りファイルの唯一の弱点は、タブがときどき値の中に紛れ込んでしまうことです。貼り付けや誤入力、別システムからの引き継ぎなどで発生し、この形式にはそれを表現する自然な方法がありません。タブの数を数える下流のツールは、その行以降で 1 列多く見えてしまいます。

CSV に変換すればこの問題は完全になくなります。タブはもう区切り文字ではないからです。引用符も必要とせずあいまいさも生まず、フィールドの中にそのまま書かれます。あるツールでタブ区切りの書き出しが行のずれを起こしていたなら、この変換は回避策ではなく正当な修正です。壊れていたのはデータではなく区切り文字の選択だったと知っておく価値があります。

数値に見える値は、その過程で数値として読まれます。数量や価格には正しく、コードには間違っています。00123 という会員番号は CSV の中で 123 として届き、スペースなしの電話番号は大きな整数になり、1e5 と書かれた参照番号は 100000 になります。

判定基準は、その列の 2 つの値を足し算することに意味があるかどうかです。郵便番号、品番、電話番号、口座参照番号はどれもこの試験に落ち、文字列として扱われるべきです。書き出しを自分で設定できるなら、接頭辞を足すか列を引用符付きで書き出せばそのまま保てます。できないなら、アップロードする前に変換されたファイルのその列を確認してください。インポート画面は、本来 00123 を受け取るべきところで 123 を何も言わずに受け入れ、間違ったレコードと突き合わせてしまいます。

出力はバイトオーダーマークのない UTF-8 です。これはスクリプトやインポートツール、バージョン管理にとっては正しい選択で、Windows でダブルクリックする用途には不向きです。ファイルの先頭に印がないので、Excel はシステムのコードページにフォールバックし、Müller のような名前が Müller として表示されます。

直すには、開くのではなくインポートしてください。「データ」から「データの取得」、「テキストまたは CSV から」を選び、取得元を 65001: Unicode (UTF-8) に指定します。これで Excel は正しく読み込み、同時に列の型も設定でき、識別子の列をテキストとして指定する好機にもなります。行き先が本当にインポート画面ではなく表計算ソフトなら、TSV を直接 XLSX に変換すればこの問題全体を回避できます。ワークブックはエンコーディングと型を内部に持っているからです。

ここで作られる CSV はカンマを使います。これが国際的な慣習で、ほとんどのインポートツールが「CSV」という言葉で意味しているものです。カンマが小数点の区切りであるロケール——ドイツ、フランス、スペイン、ブラジル、その他多くのヨーロッパや南米の国——にインストールされた Excel は、セミコロンを探しているため、ダブルクリックでは分割してくれません。

これはファイルの欠陥ではなく、1 つのプログラムの表示上の問題です。同じ「データの取得」によるインポート経路で、区切り文字を自分で指定すれば解決します。ファイルの行き先がシステムではなく、そうした Excel を使う同僚なら、TSV を直接 XLSX に変換するほうがやはり近道です。区切り文字もエンコーディングも小数点の区切りも、一度に回避できます。

列名は、スペースや単位、記号を含め、TSV が書いたとおりに引き継がれます。インポート画面はたいていそれよりずっと神経質で、正確な名前で照合するか、固定の順序を求めるか、次のページで列を 1 つずつ手作業で対応付けさせます。

見出しの編集は、引用符が付いて行が読みにくくなる変換後よりも、変換前のほうが簡単です。インポートツールが対話的に列を対応付けるタイプでも、良い見出しは時間を節約します。対応付けの画面には名前とサンプル値しか表示されないからです。どちらも「date」という名前の 2 つの列は、そこでは見分けが付きません。

すべての行は同じ数のフィールドを保つので、空の値は消えるのではなく空のフィールドとして残り、ファイルは矩形のままです。それが、インポートツールが列を揃えるために必要とするものです。

空欄が何を意味するかはファイルではなくインポートツールの判断で、これが連絡先のアップロードで問題になりがちな部分です。多くのシステムは、更新の際の空のフィールドを「これを空にする」という意味で扱い、書き出しに含まれていなかっただけの電話番号を消してしまいます。ファイルが新規作成ではなく既存レコードの更新なら、アップロードする前に空欄に対するそのツールの規則を確認し、変更するつもりのない列は削除してください。

どちらの形式も平文で、読み込みも書き出しも普通の JavaScript で行われ、変換はこのページの中で完結します。ファイルを運ぶリクエストは発生しないので、連絡先の一覧や顧客の書き出しが、本当に選んだ相手に届く前に、第三者へコピーされることはありません。

行数の確認もアカウントも不要です。上限は 100 MB のファイル、1 回のドロップにつき 100 ファイルです。数十メガバイトの表は問題なく変換され、100 MB に達するようなファイルは、たいていインポート画面にとっても大きすぎ、どのみち分割が必要になります。

行き先がシェルのパイプラインや R のスクリプト、引用符を解析せず単に文字で分割するものなら、タブ区切りの元データのほうが優れており、この変換はむしろ後退です。引用符処理こそ、そうしたツールが扱えない複雑さそのものだからです。

書き出しが正式な記録である場合は、CSV に加えて TSV も残しておいてください。この変換は数値に見える値を数値として読むので、CSV は元データの可逆なコピーではありません。手を加えていない書き出しに戻れるようにしておくコストはかからず、それが何度も午後の作業を救ってきました。