重定向管道流读取TXT文本第一次读取为""空字符串、type xxx.txt | go run . 报错、BOM头、[239,186,191] 字节数组

问题

package main

import (
	"bufio"
	"fmt"
	"os"
)

func main() {
	scan := bufio.NewScanner(os.Stdin)

	// ^ 默认是按行读取,所以手动指定按单词读取
	scan.Split(bufio.ScanWords)

	for scan.Scan() {
		fmt.Println([]byte(scan.Text()))
	}

}

本程序是给定一段文字按单词读取，读完为止。将每次读取的单词转化为字节切片（没学过go可以先理解成数组），先看看会出现什么问题。

当前目录下创建一个 test.txt

matt went to china
hello world

运行 cmd 执行

cat test.txt | go run .

[239 187 191 109 97 116 116]
[119 101 110 116]
[116 111]
[99 104 105 110 97]
[104 101 108 108 111]
[119 111 114 108 100]

第一行是不是出现了问题，matt 各个字符作为 ascii 码总共应该是 4 个字节却出现了 7 个字节。

我们把 test.txt 加一行空行，再次运行

matt went to china
hello world

[239 187 191]
[109 97 116 116]
[119 101 110 116]
[116 111]
[99 104 105 110 97]
[104 101 108 108 111]
[119 111 114 108 100]

你可以看到 matt 在第二行，而第一行出现了奇怪的东东。罪魁祸首就是 UTF-8 BOM 头

BOM是什么

　　Unicode的学名是"Universal Multiple-Octet Coded Character Set"，简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。在UCS 编码中有一个叫做 "Zero Width No-Break Space"，中文译名作“零宽无间断间隔”的字符，它的编码是 FEFF。而 FFFE 在 UCS 中是不存在的字符，所以不应该出现在实际传输中。UCS 规范建议我们在传输字节流前，先传输字符 "Zero Width No-Break Space"。这样如果接收者收到 FEFF，就表明这个字节流是 Big-Endian 的；如果收到FFFE，就表明这个字节流是 Little- Endian 的。因此字符 "Zero Width No-Break Space" （“零宽无间断间隔”）又被称作 BOM(即Byte Order Mark)。

UTF-8 BOM头又是什么

​ UTF-8 以字节为编码单元因此不需要 BOM 来表明字节顺序，但可以用 BOM 来表明 UTF-8 编码方式。字符 "Zero Width No-Break Space" 的 UTF-8 编码是 EF BB BF。所以如果接收者收到以 EF BB BF 开头的字节流，就知道这是 UTF-8 编码了。而 [EF BB BF] 转换成十进制就是 [239 187 191]

其他

这里看到一种编程语言的解决方法，其他编程语言同理。

      char c = line.charAt(0);
      if(c==65279) {    //65279是空字符
            line = line.substring(1);
      }