旧 CSV 中文乱码，怎样核对源编码再转 UTF-8

操作步骤

1. 打开“文本文件转 UTF-8”，先点击“载入 GB18030 示例”。源编码会切到 GB18030 / GBK，原始文件为 sample-gb18030.csv，21 字节。这个内置样例不会访问你的文件，适合先确认操作流程。
2. 核对只读预览：第一行为“编号,名称”，第二行为“A01,中文”，末尾还有换行。结果应显示输出 27 字节，CRLF 2、LF 0、CR 0。源编码回答的是原始字节怎样读成文字，UTF-8 则是新副本怎样保存，二者可以不同。
3. 暂时把源编码改成 UTF-8，确认出现严格解码错误，旧预览和下载入口消失；再改回 GB18030 / GBK，中文恢复。错误只是这些字节不符合所选编码，不代表能自动判断真正编码。
4. 默认不勾选“输出添加 UTF-8 BOM”。勾选后示例输出从 27 变为 30 字节，CRLF 数量不变；只有接收软件明确要求时才添加。每次变更源编码或 BOM，都需要重新确认预览。
5. 勾选“我已对照预览，确认源编码与内容正确”，点击“下载 UTF-8 副本”。下载名固定为 jijie-utf8.txt；本例内容仍是 CSV，可在自己的文件管理器中改名为 sample-utf8.csv，再用支持选择 UTF-8 的文本编辑器打开核对。原文件不被覆盖。
6. 处理实际文件前保留原件，从导出软件或文件提供方确认源编码，再选择不超过 2 MiB 的原始文件。对照中文名称、标点、编号和行尾，确认没有问号或错误汉字后才下载；长文本只预览前约 12,000 个 UTF-16 单元，全文应在下载副本中另行核对。

跟着示例试一次

内置文件按 GB18030 解码得到下方两行，采用 CRLF，最后一行也有 CRLF。浏览器实测输入 21 字节、输出 UTF-8 无 BOM 为 27 字节；真实下载文件已与独立生成的 UTF-8 字节逐一比较，两个 CRLF 均保留。添加 BOM 时前面额外增加 EF BB BF 三字节，不改变逗号、编号或换行。

编号,名称
A01,中文

怎样确认结果正确

示例的“中文”应完整显示，不是问号或乱码；下载副本按 UTF-8 打开仍是两行，编号 A01 不变。含 UTF-8 BOM 的原文件若错选 GB18030，会明确提示 BOM 冲突；无 BOM 文件不自动识别。严格解码通过仅说明字节可以按该编码读取，Windows-1252 等编码也可能把其他文件读成看似合法的错误文字，必须核对已知内容。技术依据为浏览器 TextDecoder 的 fatal 解码行为：https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder/decode 。

常见问题与边界

这不是 Unicode 字符串转义或简繁转换，也不解析 CSV 列类型、不修复已被保存为问号的内容。只支持界面列出的 UTF-8、GB18030、Big5、Shift_JIS、Windows-1252、UTF-16 LE/BE；UTF-32、BOM 冲突、非法字节及解码后含 NUL 会被拒绝。输入起始 BOM 作为标记移除，正文中的 U+FEFF 保留；输出 BOM 选项会另添一个标记。空文件合法，无 BOM 时输出零字节，勾选后为三字节。浏览器旧编码映射不等于特定标准版本的合规认证。所有文件在当前页面内存中处理，不上传、不写入站点存储，刷新即清除；不能据此推断下载副本没有敏感信息。