先说结论
「CSV 坏了」几乎总是三种互不相关的问题之一，各有各的修法：乱码是编码不匹配，整行挤进一列是分隔符不匹配，007 变 7是 Excel 把文本转成了数字。一个文件可能同时踩中多个——我们下面的测试文件故意埋了全部三类陷阱，外加引号内逗号、字段内换行，并生成了三种编码供下载。
| 症状 | 原因 | 修复 | 本文是否实测 |
|---|---|---|---|
| 品名 显示为 鍝佸悕（或 æŸ? 类乱码） | 文件字节与 Excel 猜的编码不符（双击按系统 ANSI 代码页解码，中文 Windows 是 GBK） | 重新导出为带 BOM 的 UTF-8，或在 Excel 导入时选 UTF-8 编码 | 已实测——真实 Excel 打开 + CSV 清洗工具导出 |
| 整行挤进一列（或在逗号处随机断开） | 分隔符不匹配：文件用分号，Excel 按逗号切（欧洲区域则相反） | 导入时选对分隔符，或让 CSV 清洗工具自动识别 | 已实测——真实 Excel + CSV 清洗工具 |
| 007 变 7，单号丢前导零 | Excel 打开时把看似数字的单元格转成数字——任何编码都会发生 | 改用导入并把该列格式设为文本；文件本身的数据没有丢 | 部分实测——丢失已在真实 Excel 验证；向导修复步骤来自微软官方文档（向导界面本机未实测） |
测试文件（以及 Excel 里真实发生了什么）
我们做了一张原创 4×4 演示表——中英文品名、引号内逗号（北京, 上海 仓发货）、成对引号转义（含"双层"包装）、字段内换行、单号 007 / 0210 / 00——保存为三种编码和一个分号变体，全部可下载。然后用真实桌面 Excel（Windows 11，中文区域，ANSI 代码页 936/GBK）以等同双击的方式打开每个文件，记录实际显示内容：
| 文件 | 品名 表头显示为 | 第一个单号显示为 | 解析行列 |
|---|---|---|---|
| utf8-nobom.csv | 鍝佸悕——乱码 | 7（零丢了） | 4 × 4（文字不可读） |
| utf8-bom.csv | 品名——正常 | 7（零丢了） | 4 × 4 |
| gbk.csv | 品名——正常（在 GBK 区域机器上） | 7（零丢了） | 4 × 4 |
| semicolons.csv | 表头挤进一个单元格 | 整行作为文本 | 5 × 2——解析错乱 |
这张表直接给出三条结论。一：同一个文件的好坏取决于编码猜测——GBK 文件在中文区域 Windows 上正常，在默认 UTF-8 的平台上会坏；不带 BOM 的 UTF-8 在这里正好相反地坏（UTF-8 字节按 GBK 读出来就是 鍝佸悕——品名的教科书式乱码）。二：BOM 只修编码，修不了别的——每个文件里 007 都变成了 7，因为 Excel 在解码之后还会做数字转换。三：分隔符不对不会报错，而是悄悄拆坏表格结构。
修复一：编码乱码——用 CSV 清洗工具实测验证
CSV 清洗工具在浏览器本地运行，文件不上传。它的读文件逻辑正是救回的关键：先按 UTF-8 解码，一旦出现替换字符（乱码标记），就用 GB18030 重新解码同一份字节。我们的 GBK 文件实测正是这样：粘贴预览直接得到干净中文（编号/品名…，无替换字符），而 Excel 需要文件本来就是 GBK 才行。注意工具没有宣称识别所有编码：文档写明支持 UTF-8（含/不含 BOM）与 GBK/GB18030，其他老编码请在源头转换。
- 添加乱码来源文件. 打开 CSV 清洗工具，把原始文件拖进去（务必保留原件，见下方警告）。GBK 或 UTF-8 文件会自动解码；也可以直接粘贴文本。
- 点应用并核对预览. 点应用。我们的 GBK 文件显示 4 行 × 4 列，每个值都可读——包括引号内逗号、成对引号、规格 单元格里的换行。预览只显示前 50 行；导出包含全部（上限 5 MB、10 万行）。
- 导出即得 BOM. 点导出 CSV。下载文件恒为带 BOM 的 UTF-8、CRLF 换行——正是中文 Windows 双击 Excel 想要的格式。我们的导出逐字节核对：247 字节、以 EF BB BF 开头，解析值与源表完全一致，前导零原样。
修复后的导出文件在真实 Excel 里打开即为正常中文——与上文 utf8-bom.csv 一行结果相同。微软官方给出的替代方案是 数据 > 获取数据 > 从文件 > 从文本/CSV，在导入时选择 65001（UTF-8）编码；该流程来自微软官方页面，但本次未对向导界面做实机测试。
修复二：整行一列——分隔符问题
分号文件保持工具默认的逗号分隔符时，解析成 4 行 × 2 列——表头挤进一个单元格，还有一行在北京, 上海 的逗号处被切断。把分隔符显式选为分号，或切换为自动识别，都得到正确的 4 行 × 4 列、值完整。Excel 的导入流程里有同样的选择（向导可设分隔符），所以这一步应在导入时做——双击没有给你说话的机会。
修复三：007 变 7——前导零
零不是在 CSV 文件里丢的。我们导出的文件逐字节仍含 007——往返之后已验证。丢失发生在 Excel 双击打开时：所有编码下 007 都被解析成数字 7。微软官方文档给的修法是：不要双击，改用导入并在向导里把该列的数据格式设为文本，文件里的零就能保住。这一步我们没有实机跑向导，请按官方文档对待；我们实测确认的是：数据在文件里完好，而双击必然丢零。
另一个坑：像公式的单元格
以 = + - @ 开头的单元格会被表格软件当作公式执行——这是 CSV 交换中的已知攻击面（例如 =HYPERLINK(...) 链接）。CSV 清洗工具默认开启安全导出：这些字符开头的单元格会加单引号前缀，Excel 显示为文本而不是执行（工具会提示加了多少个单元格；我们的样例是 0 个，因为下载样例在设计上就不含危险前缀，保持注入安全）。理解其含义后再关闭。本页不演示危险载荷本身。
限制与未实测项
- CSV 清洗工具限制：5 MB 文本、10 万行、预览前 50 行；编码支持 UTF-8（含/不含 BOM）与 GBK/GB18030——并非识别所有编码。
- Excel 实测环境：Windows 11、中文区域（ANSI 936）、桌面 Excel 自动化打开（等同双击）。其他区域使用不同 ANSI 代码页和列表分隔符——症状规律一致，具体乱码字符会不同。
- 未实机测试：macOS 版 Excel、Excel 导入向导界面、Numbers、Google Sheets、WPS。微软向导步骤因此按官方文档对待。
- 清洗工具的粘贴框无法修复粘贴前就已损坏的文本——救回必须从原始文件字节开始。
- 中文全角分号（；）是普通字符，不影响分隔符识别；单元格里的半角分号会影响自动识别的投票，所以显式选择分隔符才是可靠路径。
用我们的文件试一遍
下面全部是实测原始材料：同一张表的三种编码、分号变体、清洗工具的真实导出（逐字节核对）、以及供程序化核对的真值文件。所有样例设计上注入安全（无以 = + - @ 开头的单元格）。
- utf8-nobom.csv —— 双击乱码的那份（246 字节） — 下载样例 · 246 字节
- utf8-bom.csv —— 同表带 BOM；打开正常（249 字节） — 下载样例 · 249 字节
- gbk.csv —— 同表 GBK/ANSI 936（190 字节） — 下载样例 · 190 字节
- semicolons.csv —— 分号分隔变体（247 字节） — 下载样例 · 247 字节
- cleaned-export.csv —— 清洗工具从 gbk.csv 导出的真实文件（247 字节，UTF-8 BOM + CRLF） — 下载样例 · 247 字节
- expected-values.json —— 供程序化核对的真值 — 下载样例 · 491 字节
CSV 清洗工具的能力描述以其工具页与引擎源码为准（核查日期 2026-11-11）；导入步骤依据上方链接的微软官方页面。
来源与核查
- YYSI CSV cleaner — engine reads files as UTF-8 first and retries GB18030 when replacement characters appear; export is always UTF-8 with BOM and CRLF; safe-export guard defaults on (engine source + live page) — 来源核查日期 2026-11-11
- Microsoft Support: Import or export text (.txt or .csv) files — the official open-directly vs import distinction and the import wizard steps (encoding origin and per-column data format) — 来源核查日期 2026-11-11
- Microsoft Support: Import data from a CSV, HTML, or text file — Data > Get Data > From File > From Text/CSV with encoding and column-format choices — 来源核查日期 2026-11-11
来源核查日期 Encoding/delimiter/leading-zero behavior was verified by YYSI on 2026-11-11 in two ways: (1) real desktop Excel on Windows 11 (zh-CN locale, ANSI code page 936/GBK) opened each sample via automation equivalent to double-click and the displayed cell text was recorded; (2) the YYSI csv-cleaner ran in a local browser against the same files through its real file-decode path, with the exported bytes checked byte for byte. The Microsoft import-wizard steps are quoted from the official pages above but the wizard UI itself was NOT run on a real machine in this test (automation limitation) — this is marked again where the steps appear. Excel for macOS, Numbers and Google Sheets were not tested.
阅读编辑标准（EN），或发送纠错到 [email protected]。