关于编码的碎碎念.md

最新推荐文章于 2024-08-11 08:34:55 发布

酒中仙1225

最新推荐文章于 2024-08-11 08:34:55 发布

阅读量938

点赞数

分类专栏：闲谈胡侃文章标签：编码 Java 字符集 Unicode 转码

本文链接：https://blog.csdn.net/xinjianwuhen1991/article/details/50804563

版权

闲谈胡侃专栏收录该内容

14 篇文章 0 订阅

订阅专栏

一、编码的前世今生

先有字符集，后有编码。字符集指的是英文、其他欧系字符、日语、中文等字符集。如果只考虑英文，asc||码就行了，但是其他语言如果需要在计算机中的表示，就需要兼容asc码，由此出现许多语言的编码。
但是随着国际化产生，我们需要一个统一编码，Unicode就此产生。

二、关于Unicode编码

Unicode并不是编码集，其实他只是对所有字符集定义一个二个字节的数字，假设“中”112，至于这个112怎么存储，属于编码的实现方案。

之所有不用Unicode本省二个字节作为存储方案，是因为网络上70%网页都是英文的。如果用两个字节非常浪费。
我们需要一种变长编码。uft-8编码。utf-16编码。utf-8编码中英文一个字节，中文三个字节。utf-16一般是二个或四个字节，常见的是二个字节，因此会误认为是定长编码。

其实这里还有个不明白的地方，utf-16编码和Unicode本身的两个字节编码是否相同，好多网友都说是不一样的。

三、Java和编码

Java开发者必须牢记：在Java中字符仅以一种形式存在，那就是Unicode（不选择任何特定的编码，直接使用他们在字符集中的编号，这是统一的唯一方法）。由于java采用unicode编码，char 在java中占2个字节。2个字节（16位）来表示一个字符。
这里的Java中是指在JVM中、在内存中、在代码里声明的每一个char、String类型的变量中。
JVM的折中约定使得一个字符分为两部分：JVM内部和OS的文件系统。在JVM内部，统一使用Unicode表示，当这个字符被从JVM内部移到外部（即保存为文件系统中的一个文件的内容时），就进行了编码转换，使用了具体的编码方案。因此可以说所有的编码转换只发生在边界的地方，JVM和OS的交界处，也就是各种输入/输出流（或者Reader，Writer类）起作用的地方。
* Jvm中只能是以Unicode存在，不以任何编码实现方案存在否则就引起混乱，详情阅读极客公园的原则*
仔细阅读
http://wiki.jikexueyuan.com/project/java-chinese-garbled-solution/java-code-conversion-process.html

四、常见问题

new String(text.getBytes(“ISO-8859-1”),”GBK”)这句代码，是因为一个GBK的字节流被错误地以ISO-8859- 1的方式转换为String（unicode）了！发生这种情况最普遍的地方是一个GBK编码的网页向后台提交数据的时候，就有可能会看到这句代码的出现。GBK的流被错误的当成ISO8859-1的流，所以便得到了一个错误的String。由于ISO8859-1是单字节编码，所以每个字节被按照原样转换为String，也就是说，虽然这是一个错误的转换，但编码没有改变，所以我们仍然有机会把编码转换回来！所以那句经典的new String(text.getBytes(“ISO-8859-1”),”GBK”)便出现了。
作为web框架解析参数时，他不关心，前台传过来的字节流是什么编码，我统一解析成ISO-8859- 1放到String类型的text中，程序员写代码的时候，可以直接在此从将内存中的内容text（此时是Unicode）text.getBytes(“ISO-8859-1”)以8859逆向解码成字节流。Unicode-》ISO8859。
然后这时就和前端发送过来的字节流是完全一样的，后端程序员就可以按照前后端约定的编码解码。new String(text.getBytes(“ISO-8859-1”),”GBK”)。
和框架解耦，框架不关注前端和后端的解码。