一张商品表在预览里看起来整齐，交给同事以后，SKU却从000123变成123，订单号末尾也发生变化。问题可能出在打开表格的软件自动识别了类型，而不只是转换工具。使用XunL JSON与CSV转换时，最好把数据转换和电子表格导入看成两个需要分别验收的环节。
先用一行有代表性的数据检查转换规则
可以从下面的教学输入开始，而不是一开始导入整个商品库：
[{"sku":"000123","order_id":"9007199254740993","name":"长,款","qty":2}]SKU与订单号在这里明确写为字符串，数量则是数字。名称故意包含逗号，用来检查字段边界。转成逗号分隔文本时，名称不应被拆成两列；涉及逗号、双引号或字段内换行的内容需要正确引用。CSV的通用格式与双引号处理方式可查阅RFC 4180格式说明。
工具会保留JSON数字原文，也不会擅自把CSV字符串全部转换为数字。不过，数据离开工具后，接收系统仍可能采用自己的类型推断。把商品编号、电话号码与条码明确设计成文本字段，比依赖“看起来像数字”更容易保持业务含义。
转换方向、分隔符和嵌套方式要一起确认
- 选择JSON到分隔文本，粘贴对象数组，先核对字段名是否对应预期的表头。
- 选择逗号或任务要求的其他分隔符，不要仅因文件名叫CSV就忽略接收系统的约定。
- 遇到嵌套对象时，决定保留为一个JSON字符串单元格，还是展开为多个路径字段。
- 在结果表格核对行数、列数与上述特殊样本，下载后再用接收软件打开检查。
嵌套展开会改变表格结构。若不同商品具有不同层级，先约定缺少字段的处理方式；数组也不应为了凑成一张平面表就随意合并。严格JSON输入遇到重复对象键会被拒绝，应回到原始资料确认哪个字段值才是需要保留的版本。
原始数据和电子表格文本保护服务于不同交付
以等号等符号开头的文本，可能在电子表格中被当作公式。文本保护模式会对这些危险开头增加单引号等保护前缀，方便按文本阅读；但加了前缀的单元格已经不再与原始字符串逐字相同。如果这份CSV要回灌业务系统，应确认系统是否需要原值，不能将保护模式的导出文件直接当作无损备份。
例如产品备注确实以等号开头，给同事查看与交给接口导入是两种任务。前者关注打开后的文本行为，后者关注机器接收到的字段内容。选择前先问清交付对象，再保留原始JSON和导出版本；不要为了消除一个显示问题就覆盖唯一的源数据。
Excel导入时还应明确文件编码，并把SKU、订单号等列设为文本。双击打开后显示正常，不足以证明长数字没有被改写。可以比较末尾几位、前导零与含换行的备注，再挑几行反向转换检查。反向操作能发现部分差异，却不能恢复已经被其他软件舍弃的数字。
还应专门挑一行检查空字符串、缺少字段与零值。它们在表格里可能都显得空白或不起眼，但传回业务系统后含义不同。先约定接收格式如何表示这些状态，再进行批量转换，能减少后续用人工填空修复数据的工作。
商品表格转换的常见问题
为什么中文名称乱码，英文却正常？
常见原因是文件编码与打开方式不一致。先通过电子表格的文本导入入口选择UTF-8，再观察中文；不要在乱码状态下重新保存覆盖原件，否则后续更难区分编码问题与内容已经损坏。
表格看起来少了几行，是否就是工具漏转？
先检查字段内部是否本来包含换行，以及预览和接收软件怎样解释引号。一个业务记录可以在纯文本文件中占据多行。应比较解析后的记录数和关键编号，而不只是用文本编辑器的行数判断。
个人微信：ssevening
