重定向管道流读取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);
}