导出文件时必须显式指定目标编码（如'gbk'），open()不可省略encoding参数；pandas.to_csv()需禁用utf-8-sig BOM；Linux下优先用iconv转码；Java应使用OutputStreamWriter而非FileWriter。
导出文件时指定 GBK 或 BIG5 编码，Python 的 open() 必须显式传 encoding
默认用 utf-8 写文件，直接写中文到旧系统会乱码。关键不是“怎么转”，而是“写入时就用目标编码”。open() 的 encoding 参数不能省，且值必须是系统支持的编码名（如 'gbk'，不是 'gbk' —— python 对大小写不敏感但惯例小写）。
常见错误现象：UnicodeEncodeError: 'gbk' codec can't encode character '\uXXXX'，说明数据里有 GBK 不支持的字符（比如 emoji、生僻汉字）。这时候不能硬写，得提前处理。
- 先确认目标系统实际需要哪个编码：
gbk（简体 Windows 常见）、big5（繁体台湾/香港）、gb2312（更老的简体子集，兼容性略差） - 写入前检查内容：
text.encode('gbk', errors='ignore')可快速过滤掉不兼容字符；若需保留，改用errors='replace'替换为? - 避免用
str.encode().decode()多余转换：直接open(..., encoding='gbk')写字符串最安全
pandas.to_csv() 导出 GBK/BIG5 文件，必须关掉 utf-8-sig BOM 干扰
用 pandas 导出 CSV 给旧系统时，encoding='gbk' 是基础，但容易被 utf-8-sig 残留坑到——即使你指定了 gbk，如果 DataFrame 里混了 UTF-8 字节串或之前用过 utf-8-sig 读取，可能写出来开头多出乱码（BOM 被错当成 GBK 字符）。
- 务必显式指定
encoding='gbk'（或'big5'），不要依赖默认 - 禁用自动 BOM：确保没设
encoding='utf-8-sig'，也别在文件头手动加\ufeff - 如果列名含中文，旧 Excel 打开仍乱码，大概率是 Excel 自动按 ANSI 解析——此时需用
encoding='gb18030'（GBK 超集，Windows 兼容更好）
Linux/macOS 下用命令行转码，iconv 是唯一靠谱选择
服务器上批量处理文本时，别用 Python 脚本绕路。旧业务系统常跑在 Windows，但日志/配置文件生成在 Linux，这时必须用 iconv 做无损转换。
常见错误现象：iconv: illegal input sequence at position XXX，通常是源文件本身编码猜错了，或含混合编码。
- 先用
file -i filename.txt看原始编码（注意charset=iso-8859-1很可能是 UTF-8 误判） - 转 GBK：
iconv -f utf-8 -t gbk input.txt > output.txt；转 BIG5：-t big5 - 遇到非法字节，加
-c跳过，或--unicode-subst='?'替换（iconv2.35+ 支持） - 别用
recode或nkf：前者已废弃，后者对 BIG5 支持弱，且默认行为不一致
Java 写文件用 OutputStreamWriter，别碰 FileWriter
FileWriter 是陷阱——它内部硬编码用平台默认编码（Linux 是 UTF-8，Windows 是 GBK），看似能写中文，一换环境就崩。真正可控的是 OutputStreamWriter 配 FileOutputStream。
- 写 GBK：
new OutputStreamWriter(new FileOutputStream("out.txt"), "GBK") - 写 BIG5：
"Big5"（注意 Java 里是Big5，不是BIG5或big5） - 捕获
UnsupportedEncodingException：JDK 8+ 默认支持 GBK/BIG5，但某些精简版 JRE 可能删了，需提前验证 - 别用
PrintWriter包一层再设编码——它只继承Writer的编码，不接管底层流，易丢字节
最麻烦的其实是混合场景：比如 Python 生成的 JSON 里嵌了 GBK 编码的 base64 字符串，下游 Java 服务又得解码。这种链路里，任何一环漏了编码声明，问题就藏得深。盯住每个 IO 边界，而不是只看最终文件。
