java 认识字符集.pdfVIP

j ava 认识字符集 认识字符集 j ava编码中的中⽂问题是⼀个⽼⽣常谈的问题了，每次遇到中⽂乱码LZ要么是按照以 前的经验修改，要么 是baidu .com来解决问题。阅读许多关于中⽂乱码的解决办法的 博⽂后，发现对于该问题我们都 （更加包括我⾃⼰）没有⼀个清晰明了的认识，于是 LZ想通过这系列博⽂ （估计只有⼏篇）来彻底分析、解决j ava 中⽂乱码问题，如有错 误之处望各位同仁指出 ！当然，此系列博⽂并⾮LZ完全原创，都是在前辈基础上总 结，归纳，如果雷同纯属借鉴…… 问题起源 对于计算机⽽⾔，它仅认识两个0和1，不管是在内存中还是外部存储设备上，我们所 看到的⽂字、图⽚、视频等等“数据”在计算机中都是已⼆进制形式存在的。不同字符 对应⼆进制数的规 ，就是字符的编码。字符编码的集合称为字符集。 在早期的计算机系统中，使⽤的字符是⾮常少的，他们只包括26个英⽂字母、数字符 号和⼀些常⽤符号，对于这些字符进⾏编码，⽤1个字节就⾜够了，但是随着计算机 的不断发展，为了适应全世界其他各国民族的语⾔，这些少得可怜的字符编码肯定是 不够的。于是⼈们提出了UNICODE编码，它采⽤双字节编码，兼容英⽂字符和其他 国家民族的双字节字符编码。 每个国家为了统⼀编码都会规定该国家/地区计算机信息交换⽤的字符集编码，为了解 决本地字符信息的计算机处理，于是出现了各种本地化版本，引进LANG , Codepage 等概念。现在⼤部分具有国际化特征的软件核⼼字符处理都是以Unicode 为基础的， 在软件运⾏时根据当时的Locale/Lang/Codepage 设置确定相应的本地字符编码设置， 并依此处理本地字符。在处理过程中需要实现Unicode 和本地字符集的相互转换。 同然，j ava 内部采⽤的就是Unicode编码，所以在j ava运⾏的过程中就必然存在从 Unicode编码与相应的计算机操作系统或者浏览器⽀持的编码格式相互转化的过程， 这个转换的过程有⼀系列的步骤，如果某个步骤出现错误， 输出的⽂字就会是乱 码。 所以产⽣j ava乱码的问题就在于JVM与对应的操作系统/浏览器进⾏编码格式转换时出 现了错误。 其实要解决j ava乱码问题的⽅法还是⽐较简单的，但是要究其原因，理解背后的原理 还是需要了解 其实解决JAVA 程序中的汉字编码问题的⽅法往往很简单，但理解其背后的原因，定 位问题，还需要了解现有的汉字编码和编码转换。 常见字符编码 计算机要准确的处理各种字符集⽂字，需要进⾏字符编码，以便计算机能够识别和存 储各种⽂字。常见的字符编码主要包括：ASCII编码、GB**编码、Unicode 。下⾯LZ 就简单地介绍下 ！（为什么是简单介绍？因为LZ在⽹上查找资料想去了解字符编码 时，发现这个问题⽐我想象的复杂太多了，所以LZ需要另起⼀篇详细介绍，所以各位 看客就简单看看吧 ！！） 1.ASCII编码 ASCII ，American Standard Code for Information Interchange ，是基于拉丁字母的⼀套电 脑编码系统，主要⽤于显⽰现代英语和其他西欧语⾔。它是现今最通⽤的单字节编码 系统。 ASCII码使⽤指定的7位或者8为⼆进制数字组合表⽰128或者256种可能的字符。标准 的ASCII编码使⽤的是7 （2^7 = 128 ）位⼆进制数来表⽰所有的⼤⼩写字母、数字和标 点符号已经⼀些特殊的控制字符，最前⾯的⼀位统⼀规定为0 。其中0 ～31及127(共33 个)是控制字符或通信专⽤字符，32 ～126(共95个)是字符(32是空格），其中48 ～57为0 到9⼗个阿拉伯数字，65 ～90为26个⼤写英⽂字母，97 ～122号为26个⼩写英⽂字母， 其余为⼀些标点符号、运算符号等。 2.GBK***编码 ASCII最⼤的缺点就是显⽰字符有限，他虽然解决了部分西欧语⾔的显⽰问题，但是 对更多的其他语⾔他实在是⽆能为了。随着计算机技术的发展，使⽤范围越来越⼴泛 了，ASCII的缺陷越来越明显了，其他国家和地区需要使⽤计算机，必须要设计⼀套 符合本国/本地区的编码规 。例如为了显⽰中⽂，我们就必须要设计⼀套编码规 ⽤ 于将汉字转换为计算机可以接受的数字系统的数。 GB2312 ，⽤于汉字处理、汉字通信等系统之间的信息交换，通⾏于中国⼤陆。它的 编码规 是：⼩于127的字符的意义与原来相同，但两个⼤于127的字符连在⼀起时， 就表⽰⼀个汉字，前⾯的⼀个字节 （他称之为⾼字节）从0xA 1⽤到0xF7 ，后⾯⼀个 字