编码与 BOM 问题

最后更新： 2026年5月16日

乱码和代码页错误几乎都源于同一个原因：文件丢失了 UTF-8 字节顺序标记 (BOM)。 Daxlate 始终以 UTF-8 (带 BOM) 写入 CSV，这正是 Windows 版 Excel 双击打开时所 期望的格式。因此往返流程出问题，通常意味着中途有其他工具重新保存过该文件。 下面每个症状都列出了对应的原因和解决办法。

症状：在 Excel 中打开 CSV 出现乱码 #

原因： 该文件被某个工具打开或重新保存过，而这个工具去掉了 UTF-8 的 BOM， 或者把它转换成了旧式代码页（例如 Windows-1252）。

解决： 用应用中的文件 → 导出翻译…重新导出。Daxlate 的 CSV 写出器始终 输出带 BOM 的 UTF-8，这正是 Windows 上的 Excel 双击打开时所期待的格式。如果你 处理的是别处来的文件，请先在 Notepad++ 或 VS Code 中另存为带 BOM 的 UTF-8 再导入。

症状：导入失败，提示“代码页不匹配”或解析错误 #

原因： 文件没有以 UTF-8 编码保存，非 ASCII 字符在到达解析器之前就已经损坏。

解决： 用能显示编码的编辑器打开文件（Notepad++、VS Code、Sublime），另存为 带 BOM 的 UTF-8，然后重试导入。

症状：表情符号或生僻的 CJK 字符在往返后丢失 #

原因： 电子表格是在对基本多文种平面之外的 Unicode 支持不完整的编辑器中打开 的，或者在某些非 Excel 工具中用“另存为 CSV”存成了旧式 CSV。

解决： 对于包含增补平面字符的内容（表情符号、生僻 CJK 字符、历史文字），请 优先使用 XLSX 而不是 CSV。XLSX 的存储没有歧义；CSV 取决于生成方选择的编码。

症状：导入预览显示“已忽略未知列：…” #

原因： 文件中有不符合 Daxlate 表头格式的列（Object ID、Type、Parent、 Name、Caption ({culture})、Description ({culture})）。译者有时会加备注列， 导入器会给出警告并丢弃这些列，而不是让整次导入失败。

解决： 如果这条警告在预期之内，忽略即可。如果某个你预期的区域性没有被识别， 请检查列标题。它必须正好是 Caption (xx-XX) 或 Description (xx-XX)，带圆括号 并使用有效的 .NET 区域性代码。