数据和电子表格 · CSV 清理器
RFC 4180 解释：最接近 CSV 的官方标准
· 背景
csv rfc-4180 数据格式
CSV 在有人把它写下来之前已经存在了几十年。这篇文章介绍了 RFC 4180，它实际上说明了有关分隔符、引用、行结尾和标题的内容，以及为什么现实世界的文件仍然忽略它。
两个“有效”的 CSV 文件，没有一个解析器能够正确读取——为什么这种格式在没有标准的情况下发展了几十年
两个文件都可以带有 .csv 扩展名，其中一个文件使用分号，另一个文件使用制表符，并且每个文件应用不同的引号。在标点符号成为结构之前，解析器必须了解一种方言。 ToolAcre 从四个候选者开始，并对解析的样本形状进行评分，而不是信任扩展。
这种灵活性解释了为什么“有效的 CSV”通常是不完整的描述。清洁器可以接受常见的偏差，然后序列化一致的结果。它的行为是由配置和测试定义的，这比假设每个生产者都完美地遵循一份备忘录提供了更有用的合同。
RFC 4180 是什么 — 来自 2005 的信息备忘录，记录了常见做法，而不是具有约束力的标准
存储库重复将 RFC 4180 命名为输出约定，但它不是有关备忘录日期或法律状态的历史声明的来源。因此，本文重点关注实现所体现的规则：记录结尾、引用、标头宽度和分隔符处理。
当外部标准历史很重要时，请单独引用主要出版物。对于使用 ToolAcre，相关证据是本地的：代码默认为 CRLF、引用结构字符、双引号并报告宽度与标题不同的行。
存储库证据使用 RFC 4180 作为目标约定；发布历史记录位于源集之外
配置的目标描述逗号分隔的输出、CRLF 行结尾、可选的标头概念和矩形行。在发货路线上，第一行在实践中不是可选的：它始终被用作标题。无标头文件将失去该角色的第一个记录。
参差不齐的输入不会导致拒绝。短行用空单元格填充；长行保留额外内容，并且都收到行编号的警告。序列化器写入每个保留的行，因此“干净的输出”并不意味着程序猜测如何修复结构分歧。
根据备忘录引用 — 何时必须引用字段以及如何将文字双引号加倍
当字段包含所选分隔符、引号或记录结束字符时，必须用引号引起来。 ToolAcre 还额外引用前导空格或尾随空格，因此另一个解析器不会默默地修剪它们。在带引号的字段内，每个文字双引号变成两个双引号。
Quote 每个字段开关要求统一的样式；否则输出最少被引用。冗余的源引号可能会消失，而解析的值保持相等。这种标准化是预期的，这也是测试比较恢复的表以及所选示例的精确输出的原因。
文本 /csv 媒体类型 — 可选的标头和字符集参数，以及为什么它们很少与磁盘上的文件一起传输
磁盘上的文件很少会附加媒体类型参数。 ToolAcre 不会从所选文件中读取 `header` 或 `charset` 参数。它依赖于其路由契约：UTF-8 文本、第一行标题和支持的分隔符检测或手动选择。
可选的 BOM 导出开关在第一个标头之前写入 U+FEFF。这可能有助于电子表格识别 UTF-8，但配置警告它可能会破坏严格的脚本或数据库导入，因为标记在未剥离时会连接名字。除非消费者需要，否则将其保留。
世界的分歧之处——分号、LF行结尾、参差不齐的行和未标记的编码，以及为什么备忘录不能容忍这些
实际输入可以使用分号、制表符或竖线、LF 或单独的 CR、不均匀的行和前导 UTF-8 BOM。解析器有意接受所有这些行结尾和分隔符候选。它不会默默地“容忍”参差不齐的行；它保留数据并附加警告。
未关闭的报价是另一个已接受但报告的条件。起始引号之后的所有内容都成为一个字段，因为不存在明确的结束边界。在信任导出之前更正该来源。许可解析是一种保存策略，而不是证明输入符合要求。
ToolAcre 接受一些现实世界的偏差，同时报告参差不齐的行而不是拒绝它们
这里没有规则给出单元格数字、布尔或空类型。解析器返回字符串，JSON 转换器将它们保留为字符串。语义约定必须由发送者和接收者达成一致，包括是否缺少空白文本以及数字序列是否是标识符。
公式注入安全性是位于 CSV 语法之上的导出策略。启用后，除了普通数字形式之外，有风险的前导字符都会收到撇号。为了电子表格的安全故意改变数值；它不是引号转义或通用类型系统的一部分。
即使输入忽略 RFC 风格的输出 - ToolAcre CSV Cleaner 如何修复文件以实现一致的定界和引用
即使源方言发生变化，也要争取可预测的输出。解析并解决警告后，ToolAcre 会发出 CRLF 记录和标准双引号转义。如果检测到的分隔符仍然是分号或制表符，则下载会保留该分隔符而不是始终强制使用逗号。
当接收合同需要逗号分隔输出时，手动选择逗号，并检查控件，因为它显示实际使用的分隔符。一致性来自显式选择加上经过审查的行形状，而不是仅来自 CSV 扩展。