mac下CSV文件用FileReader、FileWriter读写乱码

 　　先说下windows的excel文件搬到mac下打开为什么会显示乱码。
    在win下，excel采用GBK编码，1个汉字是存为2个字节，而mac下各种软件广泛默认使用UTF-8编码方式，如在excel中，1个汉字存为3个字节，所以mac下用excel解码二进制时，也就是把二进制文件解码为汉字过程中，把原本相邻2个字节认为是一个汉字，现在拆解为把相邻3个字节才认为是一个汉字。你设想，假如源文件只有3个汉字是6个字节，来到mac下，6个字节才等于2个汉字大小，整个文件肯定都读不出原来语义了，细心的你还会发现乱码部分变少了。这每3个字节在UTF-8码表上对应什么码值就显示什么码值，如果没有对应码值，会以特殊字符代替，这些都叫“乱码”。简单来说，就是用GBK编码，打开浏览却用UTF-8解码导致的。

    在说测试代码前，我先普及下，mac下MyEclipse默认也是UTF-8，在preference--general--workspace里可以查看和更改。我们在用IO流的各种方法，比如测试代码里的String(byte[] bytes, int offset, int length) 和FileWriter.write()，查看他们的文档注释时，大都提到采用平台默认编码方式，就是指这里的编码方式。

    但不论你的MyEclipse是设置为GBK还是UTF-8，运行代码你会发现，1个相同点和1个不同点。

    相同点是生成的22.csv文件里都是乱码。当用GBK时，FileReader读的是对的，都把2个字节认为1个汉字。你取消注释，能打印出来中文就能验证我说的对。FileWriter写也是对的，也是把2个字节认为1个汉字。至于生成的22.csv显示乱码，是因为mac下excel用UTF-8解码的缘故。正因为FileReader、FileWriter都用GBK读写而excel用UTF-8解码，所以22.csv和11.csv乱码显示是一样的。

    不同点是，用UTF-8时，生成的22.csv显示的乱码跟GBK下显示的乱码不同，因为读写都按3个字节处理。原理同上。理解了，你也能知道，即使有把22.csv重新用UTF-8存储的功能，也找不回原来的文字，因为从最开始在windows我们给excel输入中文保存时，就默认选择了1个汉字按2个字节存储的GBK编码方式。（难怪我在mac的excel下没发现选择存储编码方式）

    如何避免呢，在win下就该存一份UTF-8格式的文件再拷贝到mac。因为只有在最开始写好中文保存的时候，就决定了汉字按2个字节存储还是3个字节存储。当然MAC也有相应的转换工具iconv，但我使用发现文件预览是正确汉字，打开还是乱码，但起码能看到汉字，说明iconv是没问题的，可能是excel版本兼容问题，我的是最新的mac版本office365。