Linux与Windows解压乱码UTF8BOM读取问题

linux 与 Windows 文件乱码问题
这几天需要在linux下用CNN跑数据，但是把数据和数据列表list上传到linux下时却出现了不少乱码的问题。将这两天碰到的编码问题简单的总结一下。

1.解压乱码问题
如果直接把windows下压缩的压缩包通过ftp，这里我用的是xftp传输到linux服务器的目录下，我这里用的是zip包压缩，在Linux环境中用unzip直接解压，会发现乱码，这里就是我们通常会碰到的解压乱码问题。主要原因是我们在压缩的时候里面的文件以及文件夹的名字都是根据当前环境大部分都是windows 中文 默认采用的GBK编码。因此如果在linux下直接解压，Linux下一般系统默认都是utf8编码，因此解压的时候也是会根据utf8的编码方式来decode，所以会出现乱码。

解决的方法是 加上CP936选项

unzip -O CP936 xxx.zip

这里的CP936,有些人可能不明白，其实最早的GBK编码，就是IBM定制的MBCS字符集，汉子编码正好在整个字符集中的936页，因此好多地方其实都是用CP936来代表GBK

2.文件读取BOM问题乱码

后来碰到的问题比较坑爹，就是我的txt文件是一个图片列表，列表中有中文路径，并且涉及到众多的文件夹，不可能把他修改成英文，因此在linux下GBK编码的txt文件放到Linux上是会出现乱码的。这里我们以尽量统一utf8格式的为好，为了处理方便。因此我在windows下用记事本，将ANSI编码的txt文件另存为utf-8格式。

但是！！！我还是碰到了最晕的问题

这里引入BOM的概念，一个文件在编码后打上特定的标记，当打开文件时读取这个标记来以相应的编码方式解码文件，这样就可以解决不少问题。但是很多编辑器并不统一，给我们带来了不少麻烦。这里常见的如UTF8,UTF16，会打上这样的mark标记

BOM_UTF8 '/xef/xbb/xbf' BOM_UTF16_LE '/xff/xfe' BOM_UTF16_BE '/xfe/xff'

这里我当时是需要把txt文件传到linux下默认是UTF8格式，因此直接用的windows记事本，后来读取的时候就报错了。可以看到在之后的unicode码流中最先出现的是/xef/xbb/xbf，可能是linux默认没有读取BOM头的问题，因此如果有文件需要传输的话，最好不要带BOM头到Linux中。这里用Notepad++，选择用UTF8-无BOM格式编码就OK。
再在linux中读取中文就不会乱码了。