非UTF-8编码文件中使用bash与awk提取特定位置字符串的跨机器兼容问题排查及通用方案咨询

你的问题本质是不同awk版本对字符编码的处理逻辑不一致——有的awk默认按「字符数」计算substr的位置（尤其是系统locale为UTF-8时），而ISO-8859-1是单字节编码，你需要的是按「字节位置」提取内容，这就导致了跨机器的结果差异。下面给你两个通用的解决办法，以及问题根源的分析：

一、直接用按字节处理的工具（推荐用cut） #

cut命令默认支持按字节提取，完全不受locale或工具版本影响，正好匹配你的需求：

cat foo.dat | cut -b 10-14 | iconv -f ISO-8859-1 -t UTF-8 > results.utf8

这里-b 10-14表示提取第10到第14个字节（共5个字节），完全对应你要的「从第10位开始长度为5的字符串」——因为ISO-8859-1每个字符就是1字节，提取的字节内容可以直接用iconv转成UTF-8。

二、强制awk按单字节模式处理 #

如果你坚持要用awk，可以通过设置LC_ALL=C强制awk把每个字节当成一个独立字符，这样substr就会按字节位置计算，而非字符数：

cat foo.dat | LC_ALL=C awk '{print substr($0, 10,5)}' | iconv -f ISO-8859-1 -t UTF-8 > results.utf8

LC_ALL=C会让awk切换到C locale，在这个模式下所有字符都是单字节，不管原文件里的字节是不是有效的UTF-8，都会被当作独立的单位处理，完美解决跨机器的差异问题。

三、为什么原来的两个命令会有差异？ #

咱们来拆解一下问题根源：

• 命令1（先转码再awk）：当你把ISO-8859-1转成UTF-8时，部分原单字节字符会变成多字节（比如ISO-8859-1的0xE1（á）转UTF-8是0xC3 0xA1）。如果机器上的awk默认按「字符数」处理substr，提取的位置就和原文件的字节位置不匹配了——机器2的awk应该就是这种情况，所以结果异常。
• 命令2（先awk再转码）：如果机器1的awk默认按UTF-8处理输入，遇到原文件中无效的UTF-8序列（比如你提到的(a▒c)里的乱码字节），它会把这些无效字节合并成一个「伪字符」，导致substr的位置计算错误；而机器2的awk可能默认用了C locale（或类似单字节模式），所以能正确按字节提取。

这两种命令的结果都依赖于awk的默认配置，所以跨机器必然会出问题。

内容的提问来源于stack exchange，提问作者Alg_D