文件能打开，数据就正确吗？转换时如何保留含义

分别检查解码、结构与含义

文件可以打开，不代表其中的信息正确。解码负责把字节映射成字符；结构决定字段和行是否符合规则；含义说明一个值在业务中代表什么。JSON 解析器可以检查前两层的部分问题，却无法替数据所有者决定某个数字是不是标识符。

这里使用不含个人信息的两条虚构库存记录：编号 00127，名称 Çay，数量 0；编号 00128，名称 Kahve，数量为空。先明确这两行必须保留什么，比在几百行输出中凭感觉寻找错误更容易检查与复现。

00127 可能是编号，而不是数值

把 00127 转成数字会得到 127。数学值看似没有改变，但前导零可能属于另一系统匹配记录时需要的编号。在 JSON 中应把它保留为字符串 "00127"。RFC 8259 不允许数字带多余的前导零，因此 00127 不能直接作为合法的 JSON 数值。

合适的示例输出是 {"code":"00127","name":"Çay","quantity":0}。编号为文本，数量为数字。应先写字段字典：编号用于匹配，数量用于算术。全部自动转为数字或全部变成字符串，都不能替代这一含义判断。

零、空字符串、null 与缺少字段不同

本例约定数量 0 表示“已经盘点，库存为零”，空 CSV 单元格表示“尚未盘点”。把空单元格转成 0，就捏造了一次完成的盘点。即使两行合计仍为 0，数值总和相同也无法发现这一含义损失。

JSON 中的 ""、null 与完全省略字段是不同表示。若接收系统约定 null 表示未盘点，第二条记录可以写成 {"code":"00128","name":"Kahve","quantity":null}。CSV 本身无法决定这个规则。来源没有说明时，应保留空值并暂停库存结论。

文本显示和日期格式也包含解释

Çay 显示乱码属于另一类问题。W3C 说明字符编码决定字节与字符之间的映射。用错误编码读取 UTF-8，可能让原本正确的字节显示为错误文字。重新保存乱码前，应保留原始文件并记录使用的解码设置，以免覆盖还可恢复的来源。

03/04/2026 按日/月顺序是 4 月 3 日，按月/日顺序则是 3 月 4 日。格式化工具无法脱离来源定义解决歧义。如果字段规则明确为日/月/年，可写为 2026-04-03。给一个不带时区的日历日期自动添加 UTC 零点，又会引入额外假设。

先建立一个小型验收表

转换前写下预期：保留两条记录；编号仍为 00127 和 00128；Çay 字符不变；零与未知数量保持区别。转换后逐项检查。只看“JSON 有效”的消息或文件大小，无法确认这些语义条件。

往返转换也是辅助检查：将 JSON 转回 CSV，比较选定字段是否保留相同含义。但如果两个方向采用同一种错误假设，往返也可能成功。原始来源和字段字典才是依据；有用的转换并不总要求字节完全一致。

• 记录数为 2，没有丢行或新增行。
• 编号为字符串，保留前导零。
• 0 与 null 不混同；未知数量在合计之外明确标记。
• 名称 Çay 与原始字符一致。

遇到歧义先停止，把问题问具体

覆盖源文件前，先在副本上操作。缺少字段定义时可以问：“数量为空表示未盘点还是零？00127 的前导零是否必须保留？”这比“文件坏了”更容易得到可以验证的回答。

在社区讨论时，分享这两条合成数据、预期 JSON 和实际差异即可，不必上传真实库存。转换器和差异工具可以辅助操作，关键仍是了解哪些字段含义必须保留。如果规则尚未明确，应把结果标为不确定，而不是把整齐的格式当作正确的证据。