失败的两类原因与四种策略
转码失败要分清是输入侧还是输出侧：输入侧是字节序列在源编码下非法（例如把某个 GBK 字节序列按 UTF-8 解），输出侧是字符本身合法但目标编码表示不了（例如把 emoji 转成 GBK）。iconv 的默认策略是中止并报出位置，这是最安全的选择。若必须继续，可选丢弃非法字符（-c）、丢弃无法表示的字符或音译替换（目标编码加后缀，如 //TRANSLIT、//IGNORE，属 GNU 扩展），两者的共同代价都是内容被改写。
基本信息
| 输入侧错误 | 字节序列在源编码下非法，常见于源编码判断错误 |
|---|---|
| 输出侧错误 | 字符在目标编码中无对应码位，如 emoji 转 GBK |
| 默认策略 | 报错并中止，退出码非零，已输出的部分保留在 stdout |
| 丢弃策略 | -c 或目标编码加 //IGNORE（GNU 扩展），内容有损 |
| 音译策略 | 目标编码加 //TRANSLIT，用相近字符替代（如重音字母降级） |
| 推荐做法 | 先严格模式定位问题范围，再决定逐条修复还是接受损失 |
典型使用场景
- 批量转码时的策略选择：能否接受个别字符丢失，决定用严格还是宽松模式
- 面向旧系统的输出：目标只支持 GBK/ASCII 时，需要明确替换规则而不是随机丢字
- 数据清洗审计：统计有多少条记录会被替换，评估影响面
- 接口兼容：把用户输入的 emoji 降级处理，避免写入后端直接失败
- 故障定位：通过报错位置定位到具体字节偏移，回溯是哪条记录引出的问题
策略对比示例
策略对比示例
# 严格模式：不放过任何问题，退出码非零即表示有非法字节或不可表示字符
iconv -f UTF-8 -t GBK emoji.txt -o out.txt; echo "exit=$?"
# 丢弃非法输入字符（有损），适合「先跑通再复盘」的临时场景
iconv -f UTF-8 -t UTF-8 -c dirty.txt -o clean.txt
# 音译降级：把无法表示的重音字符转成近似 ASCII（GNU 扩展语法）
iconv -f UTF-8 -t ASCII//TRANSLIT accent.txt -o ascii.txt
# 丢弃无法表示的字符并继续（GNU 扩展）
iconv -f UTF-8 -t GBK//IGNORE emoji.txt -o gbk.txt
# 事后核对损失量：统计替换符与长度变化
grep -c '?' gbk.txt; wc -c emoji.txt gbk.txt策略与代价对照
| 策略 | 写法 | 代价 |
|---|---|---|
| 中止（默认） | 不带额外选项 | 任务失败，但能拿到出错位置，便于定位 |
| 丢弃非法输入 | -c | 静默丢字节，可能破坏多字节字符边界 |
| 丢弃不可表示字符 | 目标编码加 //IGNORE | 静默丢字符，长度变化难以核对 |
| 音译替换 | 目标编码加 //TRANSLIT | 字符被替换成近似形式，语义可能改变 |
| 预检后分流 | 严格模式先跑一遍并按记录拆分 | 需要额外脚本，但可控性最好 |
宽松模式掩盖问题：转码「成功」并不代表数据完好，只代表错误被替换掉了。若在数据管道中开启丢弃策略，必须在监控里统计替换或丢弃的条数，否则劣化会被长期埋没。
退出码与输出必须一起看：报错时 stdout 上可能有部分已转换的内容，重定向后就是一个半成品文件。脚本应写入临时文件、检查退出码、校验行数与内容后再原子替换。
音译与忽略是工具扩展语法而非所有实现都支持：GNU 版本可用 //TRANSLIT、//IGNORE 这类后缀，其他平台可能直接把它当作编码名解析而报错。跨平台脚本需要先做能力探测，具体语法以对应实现的文档为准。