ToolVault

现象：转完 JSON，日期变成了一串数字

你用工具把 Excel 导出成 JSON，结果发现本该是 2023-01-01 的日期，变成了 44927；中文偶尔还乱码，空单元格直接消失。这不是工具坏了，是 Excel 的存储方式在作怪。

坑一：日期变成数字（Excel 序列号）

Excel 内部不存"日期"，只存一个数字——从基准日 1899-12-30 起算的天数。比如 44927 就代表从那天往后数 44927 天，即 2023-01-01 附近。

所以转 JSON 时如果不做特殊处理，你拿到的就是天数，而不是日期字符串。正确转换要把序列号还原：

// Excel 序列号 → JS Date（注意时区，用 UTC 避免偏移）
function excelDateToISO(serial) {
  const utc = Math.round((serial - 25569) * 86400 * 1000);
  return new Date(utc).toISOString().slice(0, 10);
}
console.log(excelDateToISO(44927)); // 2023-01-01

两个容易忽略的细节：

• 带时间的单元格是小数：44927.5 表示当天中午（0.5 天）。还原时把小数部分乘 86400 秒处理即可；
• 单元格格式决定一切：同一列里"日期显示为 2023-01-01"和"显示为 44927"可能底层存的都是序列号。别信显示格式，转换前统一按序列号解析最稳。

坑二：中文乱码（编码）

如果导出链路里某一环用了非 UTF-8 编码（比如 GBK 的 CSV 当 UTF-8 读），中文就乱码。统一用 UTF-8 导出和读取能根治。

实操判断方法：用文本编辑器打开导出的文件，若中文正常、用程序读出来乱码，问题在程序的解码假设（指定 encoding: 'utf-8'）；若编辑器里就已经乱码，问题在导出环节。Windows 下的 Excel 另存 CSV 默认是 ANSI/GBK，跨系统传输前务必转成 UTF-8（带 BOM 的 UTF-8 兼容性最好，Excel 双击打开不乱码）。

坑三：空单元格 / 表头

• 空单元格：很多工具会直接省略该字段，导致每行字段不一致；如需保留，明确"空值也输出 null"；
• 表头：第一行通常是列名，应作为 JSON 对象的 key；若文件无表头，要手动指定或按顺序编号；
• 重复/空表头：两列都叫"备注"时后者会覆盖前者，转换前先在 Excel 里把表头改唯一。

坑四：数字精度悄悄丢失

Excel 数值只有 15 位有效数字。身份证号、银行卡号、长订单号这类超过 15 位的纯数字，在 Excel 里打开的瞬间第 16 位起就变成了 0——这不是转换工具的问题，文件本身已经损坏。预防办法是在 Excel 里把这类列设为文本格式再录入；已经损坏的数据无法恢复，只能回源重导。

怎么用工具正确转换

打开 ToolVault 工具匣 的 Excel 转 JSON 工具：

1. 上传或拖入 .xlsx；
2. 工具自动把日期序列号还原成可读日期，中文按 UTF-8 处理不乱码；
3. 选择输出结构（数组对象 / 按列），空值策略可配置；
4. 一键复制 JSON，也可配合 CSV 转 JSON 处理纯文本表格。

转出来的 JSON 如果要继续入库或生成接口，用 JSON 格式化 校验语法，用 JSON 转 TypeScript 生成类型定义，让下游代码有类型可依。

FAQ

为什么我的 44927 算出来差一天？

Excel 有个著名的"1900 年闰年 bug"，它把 1900 年当成闰年多算了一天。上面的 25569 偏移已修正了这个偏差；用 UTC 计算也能避开本地时区把日期推前一天的问题。

只想导出某几列怎么办？

先在 Excel 里筛选好再导出，或转换后在前端/脚本里按 key 取需要的字段。

大文件会卡吗？

Excel 解析在浏览器本地进行，文件越大越吃内存；超大表建议先拆分，或只保留必要sheet。.xlsx 本质是 zip 包，几十万行的表解压后内存翻几十倍——超过 10 万行就值得先按业务拆 sheet。

转出的 JSON 里有隐藏字符怎么办？

从 Excel 复制的数据常混入不间断空格（\u00A0）和零宽字符，肉眼看不出来但会让匹配、去重全部失效。转换后跑一次 文本去重 或用正则 \s 全局清理一次再入库。

本文由 ToolVault 工具匣 提供。相关工具：Excel 转 JSON、CSV 转 JSON、JSON 格式化。访问 首页 查看更多开发者工具。