用iconv批量转换需先探测编码、加-c跳过非法字节、不直接覆盖原文件；find+iconv易因空格、编码混用出错，推荐file探测后循环处理；-f/-t参数须用iconv --list中的标准名，注意utf8与utf-8兼容性。
如何用 iconv 批量转换单个目录下所有文件的编码
直接在目标目录执行循环 + iconv 是最常用也最可控的方式。关键不是“能不能”，而是“要不要覆盖原文件”和“如何避免乱码覆盖”。
常见错误现象：iconv: illegal input sequence at position —— 说明源编码猜错了，或文件混用了多种编码（比如部分 UTF-8、部分 GBK）；iconv 默认遇到非法字节就报错退出，不会跳过。
- 先用
file -i filename或enca -L zh filename粗略探测原始编码，别凭感觉硬写-f utf8 - 务必加
-c参数：跳过非法字节（iconv -f gbk -t utf8 -c file.txt > new.txt），否则一个乱码字节就中断整个批量流程 - 不要直接
> file.txt覆盖原文件——万一批量出错，所有文件全毁。先输出到临时名，验证无误再mv - 推荐用
for f in *.txt; do iconv -f gbk -t utf8 -c "$f" > "${f%.txt}_utf8.txt"; done，用${f%.txt}安全截后缀
处理子目录嵌套时，为什么 find + iconv 容易出错
find . -name "*.md" -exec iconv -f gbk -t utf8 {} \; 这种写法看着简洁，实际有三个坑：
-
{}不加引号，路径含空格时直接崩（find报错或只处理空格前半段） -
iconv输出默认到终端，没重定向就全刷屏，且不保存结果 - 无法区分不同文件的实际源编码——一个目录里可能同时存在 GBK、GB2312、UTF-8-BOM 文件，统一用
-f gbk会把 UTF-8 文件转成乱码
更稳妥的做法是配合 while read 和 file 探测：
find . -name "*.txt" -print0 | while IFS= read -r -d '' f; do
enc=$(file -bi "$f" | sed 's/.*charset=//')
[ "$enc" = "utf-8" ] && continue
iconv -f "$enc" -t utf8 -c "$f" > "${f}.utf8" && mv "${f}.utf8" "$f"
done
iconv 的 -f 和 -t 参数哪些值能用、哪些会静默失败
iconv --list 输出的编码名才是安全可用的，但列表里有些名字是别名、有些已废弃。实操中高频踩坑点：
-
-f utf8可以，但-f utf-8在某些老系统（如 CentOS 6）上不认，必须写utf8 -
-f gbk比-f cp936更通用，后者在部分 Alpine 镜像里缺失 -
-f latin1实际等价于-f iso-8859-1，但某些版本iconv对latin1支持不一致，优先用后者 - 遇到
iconv: conversion from UTF-8 to UTF-8 is not supported？那是你写了-f utf8 -t utf8—— 它真会拒绝这种“无效转换”，哪怕只是想清理 BOM
批量转换后内容异常：BOM、换行符、不可见控制字符怎么办
iconv 只管字节映射，不处理 BOM、行尾符或零宽空格这类元信息。转换后看起来“文字对了但格式乱了”，大概率是这些原因：
- 源文件带 UTF-8 BOM（
EF BB BF），iconv -f utf8 -t utf8不会删它；要用sed '1s/^\xEF\xBB\xBF//' -i后置清理 - Windows 换行符
\r\n转成 Linux 的\n需额外用dos2unix，iconv从不碰换行符 - GBK 编码里常见的全角空格（
0xA3A0）、中文顿号（0xA3AC）转 UTF-8 后可能被编辑器渲染异常，这不是iconv的问题，是字体或编辑器配置问题
真正难搞的是混合编码文件——比如 HTML 中 <meta charset="gbk"> 声明了 GBK，但正文里插了一段 UTF-8 编码的 JSON。这种得人工分段，iconv 无解。
