CSV 缺失的标准：RFC 4180 涵盖的内容以及未解决的内容

谁的 CSV 是正确的？ — 同一个表的两个导出，一个带分号，一个带逗号，都称为 CSV

ToolAcre 可以从 JSON 发出逗号、分号或制表符分隔的输出。它不会读取两个相互竞争的 CSV 导出或声明其中之一正确。 CSV 在这里是只写的，因此分隔符选择是一个显式的输出选项，而不是一个检测算法。

这种区别可以防止常见的事实失误。可以编写分号的接口尚未证明它可以识别未知文件中的分号、处理区域设置小数或解释标头。这些是故意排除的单独输入责任。

两个分隔符选择是输出选项，而不是该面板读取任一文件的证据

该存储库不包含早期电子表格或数据库历史的来源，因此本文没有发明年表。它从当前编写器及其测试开始：记录、字段、分隔符、CRLF 终止和引号转义。

历史背景可以稍后通过审查的来源添加。转换器的实现是产品今天所写内容的证据，而不是约定何时首次出现或供应商为何出现分歧的证据。

CSV RFC 4180 之前的历史记录是外部存储库证据

包含分隔符、双引号、回车符或换行符的字段用双引号括起来，并且每个嵌入的引号都是双引号。前导或尾随空格也被引用，以防止常见的电子表格修剪。记录以 CRLF 结尾，文件终止。

这些行为遵循在存储库中测试的 RFC 4180 样式规则。本文避免声称普遍合规，因为作者还支持替代分隔符，并在狭义语法之外添加了安全处理。

作者使用 RFC 4180 风格的引用和 CRLF，但未声明完全符合标准

CSV 单元不保留 JSON 类型。 Null 和空字符串都变成空单元格，而布尔值和数字则变成文本表示。 UTF-8 内容被传递，并且可以为需要它的消费者添加可选的 BOM 前缀。

未嵌入语言环境解释。分号分隔符可以与小数逗号共存，但编写器不会按区域设置重新格式化数字或对日期类型进行编码。接收应用程序仍然决定如何解释每个字段。

编码、类型和区域设置边界在本文中保持明确

实现的变体是逗号、分号和制表符，以及可选的 BOM。以 `=`、`+`、`-`、`@`、制表符或回车符开头的类似公式的文本默认以撇号为前缀，因此电子表格将其视为文本。用户可以禁用该保护并收到警告。

此编写器中没有 `sep=` 提示或反斜杠转义模式。将这些称为已发货选项是错误的。嵌入的引号使用加倍，正如测试断言的那样。

观察到的电子表格变化仅限于此处实施的选项和保护

该路线中的每个假设都从解析的 JSON 开始：哪个值提供行，嵌套如何展平为点列以及哪些键成为标题。不对传入的 CSV 方言做出任何假设，因为传入的 CSV 被拒绝。

此更正颠倒了工作簿请求的方向。 CSV 到 JSON 工作流程必须在另一个工具中选择分隔符、引号、标题和单元格类型。 ToolAcre 的错误解释了这种拒绝，而不是静静地猜测。

转换假设适用于 JSON 到 CSV 仅因为 CSV 输入被拒绝

修复格式错误的 CSV 超出了范围。断引号、混合编码和意外分隔符需要 CSV Cleaner 或其他具有显式诊断功能的解析器。语法转换器接收严格的 JSON，而不是损坏的 CSV 文本。

当嵌套树创建不明确的点列或超过 2,000 列时，输出仍然可能不适合目标。警告和上限会在下载前暴露这些表格形状的故障。

要点： CSV 是一种约定，而不是一种格式 - 以及语法转换器面板如何将格式良好的文件转换为 JSON 您可以检查

将 CSV 视为其选择必须可见的约定。 ToolAcre 记录其输出选择并拒绝未指定的反向操作。这比使用一个按钮完成两项完全不同的工作更可靠。

检查接收系统中的分隔符、引号、CRLF、BOM 和公式转义。如果需要输入解析，请使用询问的工具，而不是将编写者的约定转移到未知文件上。

实际验收检查会在目标使用者中打开生成的文件，并检查原始字节或文本。消费者视图捕获显示和导入问题；原始视图确认分隔符、双引号、CRLF 和可选的 BOM，无需重新解释电子表格。将类似公式的字符串测试为惰性文本，将负数测试为数字。这些配对检查验证了编写者的实际合同，而不声称每个程序都相同地实现 CSV 约定。