CSVをテキストに変換する：表の構文を外して値だけ残す
CSVをきれいな表に整えることが、もう役に立たなくなる地点があります。9万行の取引ログに列の桁揃えは要りません。 必要なのは、どこかに収まること、チャンクに分かれること、ベクトル化されること、次の処理に流し込まれることです。 その規模になると表の足場は純粋なオーバーヘッドです。パイプ、詰め物の空白、区切り行が、ファイルの行数だけ 掛け算されていきます。
このページは.csvファイルを平たい可読テキストに変換します。引用符は解決され、エスケープは
ほどかれ、文字エンコーディングは正規化され、返ってくるのは実際の値だけです。1レコード1行、装飾はゼロ。
無料、登録不要、上限50MB、ファイルは保持しません。桁の揃った表のほうがほしければ、
CSVをMarkdownにが上の形式切り替え
からワンクリックです。ファイルも持ち越されるので、アップロードし直す必要はありません。
実際に何が変わるのか——引用符、区切り文字、文字化け
「CSVからプレーンテキストへ」と聞くと何もしないのと同じに思えます。CSVはもともとテキストなのですから。 ですが実際は違います。生のCSVファイルは、パーサーがフィールドの境界を見つけるためだけに存在する仕掛けで 埋まっているからです。
- 囲みの引用符が消えます。
"山田, 太郎"は山田, 太郎になります。引用符は元からデータの一部ではなく、中のカンマが区切りとして 読まれないように置かれていただけです。 - 二重化された引用符が戻ります。
"彼は""いいえ""と答えた"は彼は"いいえ"と答えたになります。値としては最初からこうでした。 - フィールド内の改行が畳まれます。自由記述のコメント欄は、引用符の内側に改行を含んでいても 仕様上正当です。つまり1レコードがファイル上では5行にまたがります。そのままにしておくと、後段の 行単位の処理がすべて壊れます。畳んでおけば1レコードが1行に収まります。
- 区切り文字が解決されます。元がカンマでもセミコロンでもタブでもパイプでも、出力は 一定です。区切り文字の選択がばらばらな複数のソースからファイルを集めて処理しているときに効いてきます。
- エンコーディングはUTF-8に正規化されます。Shift_JISで書き出されたCSVを取り違えて
読んだときに出る
譁�蟄怜喧縺�のような文字化けが出なくなります。
ヘッダー行は先頭にそのまま残るので、文脈としての列名は手元にあります。ただ、それが各値に繰り返し付いたり、 見た目で結び付けられたりはしないというだけです。
トークンの計算
表形式のデータでMarkdownよりテキストが選ばれる主な理由がこれで、しかも暗算できる程度の話です。
Markdownの表はセルごとに固定費を払います。パイプ1つ、前の空白、後ろの空白。それに区切り行が加わります。 10列の表なら、データが1文字も入る前に1行あたり30数文字の上乗せです。1万行あれば、モデルにとって何の情報も 運ばない構文が数十万文字積み上がる計算になります。値は同じ、占有量だけが目に見えて増えます。
それが問題になるかどうかは、完全にファイル次第です。誠実な確かめ方は、両方の形式に変換して出力の下の トークンカウンターを読むことです。すぐそこにありますし、形式切り替えで2クリックですし、推測よりずっと確実です。 小さな分析用データなら、桁揃えが本当にモデルの助けになるので表の勝ちです。長いものなら、収まるという 一点でテキストの勝ちです。
埋め込み、インデックス、レコード単位のチャンク
CSVの行き先がチャット窓ではなくベクトルデータベースや検索インデックスなら、ほしい形式は平たいテキストです。
検索用のパイプラインは文書をチャンクに割りますが、表形式データにとって自然なチャンクの単位はレコードです。 1レコード1行という形はそこにきれいに対応します。改行で分割し、各行を埋め込む。それで終わりです。 Markdownの表も技術的には各行が独立した行にはなりますが、その場合どのチャンクにもパイプ記号が付いてきて、 意味を足さないままベクトルをずらします。しかもヘッダーの文脈は、数千行離れた自分だけのチャンクに 取り残されます。
全文検索でも理屈は同じです。インデクサーは単語境界と記号でトークンに割るので、表の構文を食わせれば、
インデックスを汚すか、本来不要だったはずの除去処理を書くかの二択になります。平たいテキストならそのまま
入ります。古典的なテキスト処理——grep、wc -l、sort、
uniq、ちょっとしたPythonのループ——にとっても正しい形で、変換済みファイルは
「まずパースしなければならないもの」ではなく、ただの入力の1つになります。
引き換えに手放すもの
トレードオフについて正直に言えば、桁の揃ったグリッドがなくなる分、値と列名の結び付きは弱くなります。 平たいテキストの4,000行目を読むモデルは、7番目の値が地域コードだったことを覚えていなければなりません。 たいていは何とかします。列が少なく、日付や通貨や明らかなカテゴリのように値そのものに特徴があるファイルなら、 楽にこなします。素の整数ばかりが横に長く並ぶファイルでは、そのうち当て推量を始めます。
ですから目安はこうなります。手に負える規模のデータセットに対する分析的な問い——「どの商品ラインが 振るわなかったか」「重複エントリを見つけて」「四半期別にまとめて」——には、 CSVをMarkdownにとパイプ表が 向いています。一括処理、検索、インデックス作成、コーパス構築、スクリプト処理にはプレーンテキストです。 横にも縦にも大きいファイルなら、変換前に本当に必要な列まで削ることを検討してください。6列のエクスポートは、 形式が何であれ60列のものより的確に質問に答えます。
大きなファイルと、分割すべき見極め
ここでのアップロード上限は50MBで、CSVとしてはかなりの量です。普通のエクスポートなら数十万行は余裕で入ります。 変換自体は問題なく通ります。ですが結果をモデルに貼り付けるのは無理ですし、現在売られているどの コンテキストウィンドウも受け止めません。
無理を通そうとするより、うまくいくやり方をいくつか挙げます。
- 意図をもってサンプリングする。代表的な数百行あれば、データの形、値の分布、 端のケースについてモデルが知るべきことはひととおり伝わります。サンプルに対して質問し、 出てきたロジックを自分の手で全件に流してください。
- 変換前に絞り込む。誰も聞いていない列は落とす。エクスポートが横に長いのは、 全部が重要だからではなく、誰かが全項目を選択したからというのが大半です。
- 自然なキーで分割する。月、地域、顧客——そうすればチャンクが恣意的な切れ端ではなく、 意味のまとまりになります。
- 先に集計する。問いが「傾向はどうか」なら、集計済みの数字を読むモデルのほうが、 生の100万行を読むモデルより良い答えを出しますし、安く済みます。
つまずきやすい細かいところ
- 行末のカンマ。エクスポーターによっては全行を区切り文字で終わらせるので、各レコードの 末尾に幽霊のような空列が生まれます。無害ではありますが、出力で目立ちますし、スクリプトの フィールド数カウントを狂わせることがあります。
- 欠損値の書き方は統一されていません。空文字列、
NULL、N/A、-、\N——どれも「値なし」を意味しますが、どれが使われるかは書き出した システム次第です。変換はこれらをそのまま通すので、統計的な処理をするなら自分で正規化してください。 - 改行コード。WindowsのCRLFとUnixのLFの違いは画面上では見えませんが、スクリプトには ときどきはっきり見えます。出力側では正規化されます。
- 桁区切りの入った数値。引用符の中に
1,234と書かれているものは混乱の 定番です。このカンマは構造ではなく書式であり、値の一部として本当に存在するので、テキストにも そのまま残ります。 - 元のスプレッドシートが残っているなら。Excelをテキストに ならXLSXを直接読み、複数シートも扱え、ExcelのCSV書き出しが道中で持ち込む問題の一群を そもそも回避できます。
よくある質問
CSVをtxtファイルに変換するには？
上の変換ツールに.csvをドロップして、結果を.txtとしてダウンロードしてください。無料、登録不要、1ファイル50MBまで。はっきり言っておくと、CSVはもともとプレーンテキストです。ここでやっているのは区切り文字の構造を取り除き、値を読みやすい行の形で返すことです。
CSVはすでにテキストなのに、なぜ変換するのですか？
次にそれを読む相手にとって、「プレーンテキスト」と「カンマ区切り」は別物だからです。埋め込みモデル、分類器、全文検索インデックスは、カンマや引用符の1文字1文字を「意味を運ばないのに位置を占めるトークン」として扱います。区切り文字を外せば、そのノイズが消えます。逆に、渡す先がCSVをパースするのであれば変換しないでください。相手が必要としている構造を捨てることになります。
カンマを含むフィールドでCSVが崩れるのはなぜ？
CSVの古典的な失敗で、これはどの変換ツールよりも上流で起きています。山田, 太郎のようなフィールドは元ファイルで引用符に囲まれていなければなりません。書き出した側が正しく引用しなかった場合、その行はディスク上の時点ですでに曖昧で、どんなリーダーも意図された区切りを復元できません。出力を疑う前に、生のファイルを開いて引用符を確認してください。
セミコロン区切りやタブ区切りのファイルも扱えますか？
セミコロン区切りの書き出し——ヨーロッパの多くの地域では既定です——は十分ありふれているので、おおむね正しくパースされます。厄介なのはタブ区切りのデータが.csv拡張子で保存されている場合です。拡張子が約束している中身と、実際のバイト列が食い違っているからです。出力が途切れのない1本の長い列に見えるなら、原因はこの食い違いです。
CSVはテキストとMarkdownのどちらにすべき？
行が実質的にただのリスト——URLの1列、商品名、エラーコード——で、区切り文字が邪魔なだけならテキストです。ファイルが本当に表であり、人間かモデルにどの値がどの列のものかを見せる必要があるならMarkdownです。
ツールキットのほかの場所
File2Txtは対応形式なら何でも 1回のアップロードで受け付けます。近いところでは、APIのダンプやログの書き出しには JSONをテキストに、 フィードや旧来の交換フォーマットにはXMLをテキストに、 保存済みのページにはHTMLをテキストに、 文書にはPDFをテキストにがあります。
データがコードの隣に置かれているなら、 GitHubをテキストに変換するツール、 GitLab変換、 ローカルディレクトリ変換で プロジェクトを平たくして、両方まとめてモデルに渡してください。Web上のソースなら、 Web2Txtが公開中のURLを取得します。 背景をもう少し知りたければ、 LLM向けにファイルを整える方法のガイド があります。
Repo2Txtを開発・運営しているのは v12hero、 プライバシー最優先のネイティブアプリとWebアプリを作る独立系デベロッパーです。