必须先用对应解码器（如simplifiedchinese.GBK.NewDecoder()）将原始字节转为合法UTF-8字符串，再执行strings.Contains等搜索操作；顺序不可颠倒，否则因非法UTF-8导致匹配失败。
os.ReadFile 读出来就乱码，还怎么搜？
直接用 os.ReadFile 读取 GBK/Shift-JIS 等非 UTF-8 文件后调 strings.Contains，结果永远是 false——因为字节没解码，中文被当成了非法 UTF-8 序列，转成 string 后全是 或空格。这不是搜索逻辑错，是输入根本没还原成真实文本。
必须先完成编码转换，再做字符串匹配。顺序不能颠倒：
- 先用对应解码器（如
simplifiedchinese.GBK.NewDecoder()）把原始[]byte转成合法 UTF-8 字符串 - 再对这个字符串执行
strings.Contains、regexp.MatchString等操作 - 别试图在乱码字符串上“修复”：
strings.ToValidUTF8只替换非法码点，不恢复原始汉字
GBK 文件里搜“配置”，该怎么写代码？
核心是把文件字节流塞进 transform.NewReader 管道，让解码器在读取时实时转换。不是先读再转，而是边读边解。
示例片段（省略 error 处理）：
立即学习“go语言免费学习笔记（深入）”；
data, _ := os.ReadFile("config.txt")
reader := transform.NewReader(bytes.NewReader(data), simplifiedchinese.GBK.NewDecoder())
content, _ := io.ReadAll(reader)
if strings.Contains(string(content), "配置") {
fmt.Println("找到了")
}
注意点：
-
transform.NewReader接收io.Reader，所以要用bytes.NewReader(data)包一层 - 别用
gbk.NewDecoder().String(string(data))—— 这会先错转一次成乱码 string，再解，双重失真 - 如果文件很大，改用
os.Open+transform.NewReader(file, ...)流式处理，避免内存爆炸
编码不确定时，能边猜边搜吗？
不能跳过探测直接搜。自动探测必须作用于原始字节，且只对前几百~1024 字节有效；全文探测既慢又不准。
推荐流程：
- 用
enry.DetectEncoding(data[:min(len(data), 1024)])获取编码名和confidence - 若
confidence < 0.7，放弃自动识别， fallback 到常见编码列表（如["GBK", "UTF-8", "EUC-JP"]）逐个试 - 每个候选编码都走一遍解码 + 搜索，只要有一个命中就返回结果
- 别用
chardet：它对短文本（
UTF-16 文件里搜“Hello”，为什么 ReadLine 失败？
bufio.Scanner.ReadLine() 和 ReadString('\n') 都假设输入是字节流，但 UTF-16 是双字节编码——换行符 0x0A 在 UTF-16LE 中变成 0x0A 0x00，Scanner 根本认不出。
正确做法是用 unicode.UTF16 解码器预处理整个流：
f, _ := os.Open("hello.txt")
defer f.Close()
decoder := unicode.UTF16(unicode.LittleEndian, unicode.UseBOM).NewDecoder()
reader := transform.NewReader(f, decoder)
scanner := bufio.NewScanner(reader)
for scanner.Scan() {
if strings.Contains(scanner.Text(), "Hello") {
fmt.Println("行内匹配")
}
}
关键细节：
-
unicode.UTF16构造时必须指定字节序（LittleEndian/BigEndian）和是否用 BOM（UseBOM） - 如果文件带 BOM，
UseBOM会自动识别并忽略；不带 BOM 就必须人工指定，否则解码失败 - UTF-16BE 的换行符是
0x00 0x0A，Scanner 默认按单字节找0x0A，必然漏行
编码探测和转换不是可选步骤，是搜索的前提。哪怕只是临时脚本，也要先确认 file -i filename 输出的真实编码，再决定走哪条解码路径——靠猜和重试成本远高于一次查清。
