CSV 转 JSON：保留开头的零和长 ID
账户 ID 不用来做计算。换格式时，别丢了开头的零或末尾的数字。
如果 001 是账户 ID，把它变成 1 就是一次错误的转换。很长的帖子 ID 如果连最后一位都变了，同样是转换出错。
CSV 不会告诉转换器哪些列是标识符。稳妥的做法是先把单元格内容保留为字符串，只有确实需要计算或判断真假的值，才转成数字或布尔值。
先用示例文件试试
我们的示例包含前导零、两个 19 位 ID、带引号字段内的逗号，以及名字 Zoë。这些行都不包含真实账户数据。
account_id,post_id,name,note,active
001,1234567890123456789,Alex,"Design, then share",true
002,9876543210987654321,Zoë,"Keep leading zeros",false
{
"account_id": "001",
"post_id": "1234567890123456789",
"name": "Alex",
"note": "Design, then share",
"active": "true"
}使用 CozyToolkit 的默认设置，001 保持为 "001"，长 ID 保持带引号，"Design, then share" 保持为一个值。甚至 true 也保持为字符串 "true"。这是默认行为：没有开启类型检测，转换器就不会自行猜测。
转换时保留原始 ID
- 下载上面的示例 CSV，或使用 尝试此 CSV 在 数据转换器 中打开它。
- 选择 CSV 作为源，JSON 作为目标。自动检测也能识别此示例。
- 在选项中将 第一行包含表头 保持开启，检测 CSV 中的数字和布尔值 保持关闭。
- 检查 JSON 输出。
account_id和post_id的值应该带有引号。 - 下载 JSON 并在后续要用的应用中检查。即使导出正确，后续的导入程序也可能更改它。
表格预览有助于检查列和行。检查类型时使用 JSON 视图：带引号的字符串和数字在表格中可能看起来相同。
什么时候该开启类型检测
如果 CSV 包含像 12 的数量和像 true 这样的真假值，检测 CSV 中的数字和布尔值 可以将它们转换为 JSON 数字和布尔值。在我们的转换器中，即使启用了检测，001 这样的值仍保持为字符串。
长整数则不同。启用检测后，我们的转换器使用无损数字解析器在导出的 JSON 中保留其数字。但它现在是一个不带引号的数字。读取该文件的程序也必须精确处理它。
JavaScript 的最大安全整数是 9,007,199,254,740,991。普通的 JSON.parse 将 JSON 数字转换为 JavaScript 数字，超出该安全范围的值可能会被四舍五入。MDN 解释了安全整数限制。
例如，在 JavaScript 中：
JSON.parse('{"id":1234567890123456789}').id
// 1234567890123456800
JSON.parse('{"id":"1234567890123456789"}').id
// "1234567890123456789"
如果你不需要拿 ID 做加减或求平均，将其保留为字符串可以避免此问题。当前转换器的类型检测开关适用于整个文件，而不是单个列。如果同一个文件里既有 ID 又有数量，先关闭类型检测，再到接收数据的系统里单独转换数量字段。
如果 CSV 已经损坏
转换器无法恢复早期电子表格导出时四舍五入掉的数字。它也无法推断 1 最初是 001 还是 0001。
在转换前以文本形式打开原始 CSV。如果数字已经丢失，请回到最初的数据源重新导出。事后添加零或虚构最后几位数字不是修复。
我们检查了什么
2026 年 9 月 28 日，我们使用 CozyToolkit 的转换功能，在类型检测关闭和开启的情况下运行了可下载文件。我们检查了输出中的两个长 ID、前导零、带引号的逗号和 Unicode。测量文件 包含两种输出以供比较。文件在你的浏览器中处理；此测试未使用 AI 模型。