<svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path> </svg> <p>原文地址：https://blog.csdn.net/h12kjgj/article/details/</p> 讯享网
如果源码文件是GBK编码, 操作系统（windows）默认的环境编码为GBK，那么编译时, JVM将 按照GBK编码将字节数组解析成字符，然后将字符转换为unicode格式的字节数组，作为内部存储。
当打印这个字符串时，JVM 根据操作系统本地的语言环境，将unicode转换为GBK，然后操作系统将GBK格式的内容显示出来。
当源码文件是UTF-8, 我们需要通知编译器源码的格式，javac -encoding utf-8 … , 编译时，JVM按照utf-8 解析成字符，然后转换为unicode格式的字节数组， 那么不论源码文件是什么格式，同样的字符串，最后得到的unicode字节数组是完全一致的，显示的时候，也是转成GBK来显示（跟OS环境有关）
本质上都是由于字符串原本的编码格式 与 读取时解析用的编码格式 不一致导致的。
例如：
讯享网
输出：
其中 getBytes() 是将unicode 转换为操作系统默认的格式的字节数组，即"你好哦"的 GBK格式。
new String (bytes, Charset) 中的charset 是指定读取 bytes 的方式，这里指定为UTF-8,即把bytes的内容当做UTF-8 格式对待。
如下两种方式都会有正确的结果，因为他们的源内容编码和解析用的编码是一致的。
讯享网
但是为什么在tomcat 下，使用 new String(s.getBytes(“iso-8859-1”) ,“GBK”) 却可以用呢？
答案是：
tomcat 默认使用iso-8859-1编码， 也就是说，如果原本字符串是GBK的，tomcat传输过程中，将GBK转成iso-8859-1了。默认情况下，使用iso-8859-1读取中文肯定是有问题的，那么我们需要将iso-8859-1 再转成GBK， 而iso-8859-1 是单字节编码的，即他认为一个字节是一个字符， 那么这种转换不会对原来的字节数组做任何改变，因为字节数组本来就是由单个字节组成的。如果之前用GBK编码，那么转成iso-8859-1后编码内容完全没变， 则 s.getBytes(“iso-8859-1”) 实际上还是原来GBK的编码内容。
则 new String(s.getBytes(“iso-8859-1”) ,“GBK”) 就可以正确解码了。 所以说这是一种巧合。
简化后就是:
讯享网
Encodes this String into a sequence of bytes using the named charset, storing the result into a new byte array.
另外对于读写文件，
OutputStreamWriter w1 = new OutputStreamWriter(new FileOutputStream(“D:file1.txt”),“UTF-8”);
InputStreamReader( stream, charset)
可以帮助我们轻松的按照指定编码读写文件。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/162579.html