编码与字符集
指定字符编码重新读取乱码 CSV
使用工具
.csv 扩展名不能决定字符编码。生成与打开应用采用不同编码时，相同字节会显示成不同文字。直接保存乱码可能覆盖证据，应先保留原文件。
字符编码工具按明确选择的编码把文字转字节或反向转换，不会自动鉴定原编码。先用 あ 一字理解机制，再应用于实际文件。
あ 的字节随编码而变
UTF-8 e38182
UTF-16LE 4230
UTF-16BE 3042
Windows-31J 82a0输入 あ 并切换编码可得到这四种结果。字符未变，字节值与长度不同。十六进制表示存储传输字节，不是变成了不可读字符。复制时应附编码。
用对应编码解回去
e38182 按 UTF-8、82a0 按 Windows-31J 解码可恢复 あ。UTF-16 的字节顺序也是规则的一部分，4230 在 LE 与 BE 中含义不同，不能互换。
往返成功只确认该例，不唯一证明整个文件的原编码。纯 ASCII 可能在多种编码下都正常。还应检查代表性非 ASCII、符号、换行，并结合生成方导出设置或规范。
解码报错也能保护证据
不合法字节会报错，不会默默替成替代字符。例如 e381 是 e38182 的截断 UTF-8。错误可能来自选错编码，也可能是输入缺字节，两种都要查。
没有错误也不证明读法正确，另一编码也可能接受这些字节。需核对预期词语、符号、记录数和生成方声明，重点是保留预期内容，不是只要能显示。
已替成 ? 或 � 的字可能无法恢复
若只是显示时误解码，原字节可能还能按正确方式重读。但保存替代 ? 或 � 后，不同原字可能已变成同一替代符，仅凭保存文本无法唯一恢复。
此时应找原导出或备份，而非反复转换损坏文本。复制乱码显示不同于提供原字节。求助时说明证据类型，用副本操作，不覆盖来源。
仅凭 Shift_JIS 名称不能保证兼容
当前支持 UTF-8、UTF-16LE、UTF-16BE 和 WHATWG shift_jis 对应的 Windows-31J 映射，不表示与旧 JIS 或所有同名产品实现完全一致。应在接收应用测试实际出问题的符号或扩展字。
Windows-31J 无法表示的字符如 😀 会编码失败，不默默替成 ?。接收方只能用该编码时，需要约定字符规则、修改接口或明确替代表示，这些涉及语义，不应由工具暗自决定。
编码正确，仍要另查 CSV 结构
文字恢复后，再用 CSV 编辑器检查行列。分隔符、引号内换行、前导零和空字符串是另一些问题。表格软件即使修好显示，也可能把 ID 转数字，应核对代表性记录。
为防复发，应在交换规范写明编码、BOM、换行和 CSV 分隔符。工具编码结果是十六进制文字，保存屏幕内容不自动成为可导入业务文件。最终文件形式和导入步骤需按接收方要求核对。
文字恢复可读，不代表文件交接已完成
CSV 乱码时，先保留未经表格软件另存的原始字节。错误解码后保存可能将字符换成问号或删前导零，问题就不只编码。每种候选都从同一原本测试，不要反复覆盖；分清换解码方式重读与用其他编码保存，才能追踪信息在哪步变化。
纯英数字一行显示正确并非强证据，因为多种编码对这些字节相同。应检查文件实际包含的非 ASCII 文字与符号，但几字可读也不证明整份正确。有导出设置或提供方规格时优先确认，推测的编码应注明推测。
可读之后还要查行列数、引号内换行和空字段含义。解码成功不保证 CSV 数据相同，应一起交代编码、分隔符、换行和列类型。本工具某些操作输出十六进制字节文本，不能直接把那段文字当业务 CSV 保存。