sed按字节流处理UTF-8文本，易因截断多字节字符导致解码失败；应先验证并清除BOM，设置LC_ALL=C.UTF-8，避免cut -b等字节操作，必要时改用perl或jq等Unicode感知工具。
sed 本身不理解多字节字符边界，它按字节流处理文本。在 UTF-8 中，一个中文字符占 3 字节，若 sed 在中间截断字节序列（比如用 cut 或正则匹配位置不当），就会产生非法 UTF-8 序列，终端或后续程序读取时显示为 或直接丢弃——这不是“显示乱码”，而是解码失败。
确保输入文件是合法 UTF-8 且无 BOM
先验证并清理源头：
- 用
file -i filename或iconv -f utf-8 -t utf-8//strict filename > /dev/null && echo ok检查是否为纯净 UTF-8 - 若含 BOM（
\xef\xbb\xbf），BOM 占前 3 字节，会使^锚点错位，导致正则匹配失效；可用sed '1s/^\xef\xbb\xbf//' -i filename或更稳妥地用tail -c +4 filename > newfile去除 - 避免混用编码：同一文件中不要同时存在 GBK 字节和 UTF-8 字节，否则 sed 无法可靠识别中文起始位置
避免使用依赖字节偏移的操作
sed 的 s///、d、p 等命令本身不破坏编码，但以下操作极易引发截断：
- 不用
cut -c或cut -b提取“第 N 个字符”——-c在 GNU 版本中虽声称按字符，但实际行为受 locale 影响，不可靠；-b明确按字节，必然出错 - 慎用
sed -n '1,10p'截取前 10 行没问题，但若配合head -c N截字节流，则可能切在中文字符中间 - 正则中的
.默认匹配单字节，在LC_ALL=C下无法跨字节匹配完整汉字；应设LC_ALL=en_US.UTF-8或LC_ALL=C.UTF-8（如系统支持）再使用sed -E '/^[0-9\u4e00-\u9fff]/d'
用 UTF-8 感知工具替代关键环节
对需“按字符”逻辑的场景，sed 不是最佳选择：
- 提取某字段中的中文子串？改用
awk '{print $2}' | iconv -f utf-8 -t utf-8后接grep -oP '\p{Han}+'（需 pcregrep） - 替换行首中文？先用
perl -CSD -pe 's/^[\x{4e00}-\x{9fff}]+//'，Perl 原生支持 Unicode 字符类 - 批量修改含中文的 HTML？优先用
xmlstar或jq（对 JSON）这类结构化工具，避开纯文本解析风险
设置环境与验证输出
运行前固定行为边界：
- 显式设置 locale：
export LC_ALL=C.UTF-8（推荐）或en_US.UTF-8，避免依赖系统默认值 - 重定向输出后立即校验：
sed 's/旧/新/g' in.txt > out.txt && file -i out.txt确保仍是 UTF-8 - 终端显示异常时，先运行
locale看LC_CTYPE是否为 UTF-8 类值，不是则export LC_CTYPE=en_US.UTF-8
