TSV を JSON に変換

TSV の見出し行がキーになり、それ以降の 1 行が 1 つのオブジェクトになります。多くの API やテストデータが前提にしている、いちばん扱いやすい形です。

TSV はタブを区切り文字として使う分、値の中にカンマが混じっていても崩れにくいという利点があります。ただし値の中にタブそのものが含まれる場合は、引用符で囲まれていれば正しく解釈されます。

型は推定されます。数値に見える値は JSON の数値になり、`true` と `false` は真偽値になります。数量や区分の列には、ほぼ確実にこれが望みどおりの結果です。

識別子には間違った答えです。`007` は `7` になり、郵便番号や品番、口座番号は先頭の 0 を黙って落とします。日本のデータではこれがよく当たります。`0600001` という郵便番号、`03` で始まる電話番号、13 桁の法人番号。最後のものは 0 が消えるどころか指数表示になることさえあります。数量ではなく符号を扱っているなら、頼る前に出力を見てください。

数値に見える値は数値になるので、符号の列を守る方法は、変換の前に「これは数値ではない」と分かる形にしておくことです。表計算ソフトで先頭に `'` を付ける、接頭辞を足す、書き出しの時点で引用符で囲む。どれでも文字として印が付きます。

一般則として、その列の 2 つの値を足すことが一生ないなら、それは識別子で、文字列のままでいたがっています。郵便番号、品番、電話番号、口座番号、法人番号は全部この足し算の試験に落ちます。

空の欄は空文字列ではなく null になります。見出しが `a\tb\tc` の行にデータが 2 つしかなければ、足りない列には null が入ります。JSON を受け取る側が文字列を要求する場合、null はスキーマの検証で弾かれることがあります。

TSV には「空だった欄」と「そもそも無かった欄」を区別する方法がなく、その違いに意味がある場合は、元の TSV の側で明示的に書いておく必要があります。

同じ見出しを持つ列が 2 つあると衝突します。オブジェクトのキーは一意だからです。後ろの列が勝ち、前の列は警告もなく消えます。直す場所は元の TSV の見出し行です。

見出しが日本語なら、JSON のキーも日本語になります。それ自体は正しい JSON ですが、受け取る側が ASCII のキーを前提にしていることもあります。書き出し元の文字コードが UTF-8 になっているかも、あわせて確認しておくと安心です。

全部ブラウザーの中で動くので、大きな書き出しでも機械が許す速さで変換され、この機械からは出ません。TSV はたいてい顧客名簿か注文履歴か、社外の相手に説明したくない基幹システムからの書き出しなので、この組み合わせがほかの変換より効いてきます。

開発者ツールのネットワークタブを開いたまま変換すれば、ファイルを運ぶリクエストが 1 つも出ていないことを確認できます。

解析は速く、限界はメモリーです。配列全体を組み立ててから書き出すためです。数十メガバイトは普通に通ります。数百メガバイトになると、ブラウザーのタブが苦しみはじめます。

その大きさの書き出しなら、正しい道具はブラウザーの変換機ではなく、逐次読み込みができるスクリプトの側です。