- 浏览: 1222273 次
- 性别:
- 来自: 荆州
文章分类
- 全部博客 (396)
- Android 基础 (72)
- Java 基础 (42)
- Android(动画效果) (26)
- Android(自定义组件) (13)
- Android(手机服务) (38)
- Android(网络相关) (27)
- Android(多媒体) (12)
- Android(小技巧) (30)
- Android(用户界面) (39)
- 基础概念 (24)
- Android组件学习 (21)
- Android数据库相关 (11)
- 生活杂谈 (10)
- 调试技巧部分 (8)
- Sql Server相关 (1)
- Android(xml相关) (2)
- Android 开发 (12)
- 韩语学习 (4)
- Mac添加环境变量的三种方法 (1)
- iPhone开发 (1)
- Android Studio (1)
最新评论
-
ppfbsar:
下载网络文件到SD卡上 -
851228082:
好文!彻底理解单类型导入与按需导入的区别了。还有一点可以通过 ...
谈java的导入(import) -
麦田的设计者:
老乡啊
sqlite 数据库保存图片 -
sf_dream:
我要是读写list、map之类的集合呢
ObjectOutputStream和ObjectInputStream类的学习 -
xfyunyun:
博主,请问webview加载html字符串时怎么进行缓存处理呢 ...
WebView使用总结2(加载HTML内容形式的String)
下面这段文字是从panny1982处转过来的,给大家分享一下:
很久很久以前,有一群人,他们决定用8个可以开合的晶体管来组合成不同的状态,以表示世界上的万物。他们看到8个开关状态是好的,于是他们把这称为"字节"。
再后来,他们又做了一些可以处理这些字节的机器,机器开动了,可以用字节来组合出很多状态,状态开始变来变去。他们看到这样是好的,于是它们就这机器称为"计算机"。
开始计算机只在美国用。八位的字节一共可以组合出256(2的8次方)种不同的状态。 他们把其中的编号从0开始的32种状态分别规定了特殊的用途,一但终端、打印机遇上约定好的这些字节被传过来时,就要做一些约定的动作。遇上0x10, 终端就换行,遇上0x07, 终端就向人们嘟嘟叫,例好遇上0x1b, 打印机就打印反白的字,或者终端就用彩色显示字母。他们看到这样很好,于是就把这些0x20以下的字节状态称为"控制码"。
他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示,一直编到了第127号,这样计算机就可以用不同字节来存储英语的文字了。大家看到这样,都感觉很好,于是大家都把这个方案叫做 ANSI 的"Ascii"编码(American Standard Code for Information Interchange,美国信息互换标准代码)。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。
后来,就像建造巴比伦塔一样,世界各地的都开始使用计算机,但是很多国家用的不是英文,他们的字母里有许多是ASCII里没有的,为了可以在计算机保存他们的文字,他们决定采用127号之后的空位来表示这些新的字母、符号,还加入了很多画表格时需要用下到的横线、竖线、交叉等形状,一直把序号编到了最后一个状态255。从128到255这一页的字符集被称"扩展字符集"。从此之后,贪婪的人类再没有新的状态可以用了,美帝国主义可能没有想到还有第三世界国家的人们也希望可以用到计算机吧!
等中国人们得到计算机时,已经没有可以利用的字节状态来表示汉字,况且有6000多个常用汉字需要保存呢。但是这难不倒智慧的中国人民,我们不客气地把那些127号之后的奇异符号们直接取消掉, 规定:一个小于127的字符的意义与原来相同,但两个大于127的字符连在一起时,就表示一个汉字,前面的一个字节(他称之为高字节)从0xA1用到0xF7,后面一个字节(低字节)从0xA1到0xFE,这样我们就可以组合出大约7000多个简体汉字了。在这些编码里,我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了,连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码,这就是常说的"全角"字符,而原来在127号以下的那些就叫"半角"字符了。
中国人民看到这样很不错,于是就把这种汉字方案叫做 "GB2312"。GB2312 是对 ASCII 的中文扩展。 但是中国的汉字太多了,我们很快就就发现有许多人的人名没有办法在这里打出来,特别是某些很会麻烦别人的国家领导人。于是我们不得不继续把 GB2312 没有用到的码位找出来老实不客气地用上。
后来还是不够用,于是干脆不再要求低字节一定是127号之后的内码,只要第一个字节是大于127就固定表示这是一个汉字的开始,不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准,GBK 包括了 GB2312 的所有内容,同时又增加了近20000个新的汉字(包括繁体字)和符号。
后来少数民族也要用电脑了,于是我们再扩展,又加了几千个新的少数民族的字,GBK 扩成了 GB18030。从此之后,中华民族的文化就可以在计算机时代中传承了。
中国的程序员们看到这一系列汉字编码的标准是好的,于是通称他们叫做 "DBCS"(Double Byte Charecter Set 双字节字符集)。在DBCS系列标准里,最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里,因此他们写的程序为了支持中文处理,必须要注意字串里的每一个字节的值,如果这个值是大于127的,那么就认为一个双字节字符集里的字符出现了。那时候凡是受过加持,会编程的计算机僧侣们都要每天念下面这个咒语数百遍:"一个汉字算两个英文字符!一个汉字算两个英文字符......"
因为当时各个国家都像中国这样搞出一套自己的编码标准,结果互相之间谁也不懂谁的编码,谁也不支持别人的编码,连大陆和台湾这样只相隔了150海里,使用着同一种语言的兄弟地区,也分别采用了不同的 DBCS 编码方案。当时的中国人想让电脑显示汉字,就必须装上一个"汉字系统",专门用来处理汉字的显示、输入的问题,但是那个台湾的愚昧封建人士写的算命程序就必须加装另一套支持 BIG5 编码的什么"倚天汉字系统"才可以用,装错了字符系统,显示就会乱了套!这怎么办?而且世界民族之林中还有那些一时用不上电脑的穷苦人民,他们的文字又怎么办? 真是计算机的巴比伦塔命题啊!
正在这时,大天使加百列及时出现了:一个叫 ISO (国际标谁化组织)的国际组织决定着手解决这个问题。他们采用的方法很简单:废了所有的地区性编码方案,重新搞一个包括了地球上所有文化、所有字母和符号的编码!他们打算叫它"Universal Multiple-Octet Coded Character Set",简称 UCS, 俗称 "UNICODE"。
UNICODE 开始制订时,计算机的存储器容量极大地发展了,空间再也不成为问题了。于是 ISO 就直接规定必须用两个字节,也就是16位来统一表示所有的字符,对于ascii里的那些"半角"字符,UNICODE 保持其原编码不变,只是将其长度由原来的8位扩展为16位,而其他文化和语言的字符则全部重新统一编码。由于"半角"英文符号只需要用到低8位,所以其高8位永远是0,因此这种大气的方案在保存英文文本时会多浪费一倍的空间。
这时候,从旧社会里走过来的程序员开始发现一个奇怪的现象:他们的strlen函数靠不住了,一个汉字不再是相当于两个字符了,而是一个!是的,从 UNICODE 开始,无论是半角的英文字母,还是全角的汉字,它们都是统一的"一个字符"!同时,也都是统一的"两个字节",请注意"字符"和"字节"两个术语的不同,"字节"是一个8位的物理存贮单元,而"字符"则是一个文化相关的符号。在UNICODE 中,一个字符就是两个字节。一个汉字算两个英文字符的时代已经快过去了。
从前多种字符集存在时,那些做多语言软件的公司遇上过很大麻烦,他们为了在不同的国家销售同一套软件,就不得不在区域化软件时也加持那个双字节字符集咒语,不仅要处处小心不要搞错,还要把软件中的文字在不同的字符集中转来转去。UNICODE 对于他们来说是一个很好的一揽子解决方案,于是从 Windows NT 开始,MS 趁机把它们的操作系统改了一遍,把所有的核心代码都改成了用 UNICODE 方式工作的版本,从这时开始,WINDOWS 系统终于无需要加装各种本土语言系统,就可以显示全世界上所有文化的字符了。
但是,UNICODE 在制订时没有考虑与任何一种现有的编码方案保持兼容,这使得 GBK 与UNICODE 在汉字的内码编排上完全是不一样的,没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换,这种转换必须通过查表来进行。
如前所述,UNICODE 是用两个字节来表示为一个字符,他总共可以组合出65535不同的字符,这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系,ISO已经准备了UCS-4方案,说简单了就是四个字节来表示一个字符,这样我们就可以组合出21亿个不同的字符出来(最高位有其他用途),这大概可以用到银河联邦成立那一天吧!
UNICODE 来到时,一起到来的还有计算机网络的兴起,UNICODE 如何在网络上传输也是一个必须考虑的问题,于是面向传输的众多 UTF(UCS Transfer Format)标准出现了,顾名思义,UTF8就是每次8个位传输数据,而UTF16就是每次16个位,只不过为了传输时的可靠性,从UNICODE到UTF时并不是直接的对应,而是要过一些算法和规则来转换。
受到过网络编程加持的计算机僧侣们都知道,在网络里传递信息时有一个很重要的问题,就是对于数据高低位的解读方式,一些计算机是采用低位先发送的方法,例如我们PC机采用的 INTEL 架构,而另一些是采用高位先发送的方式,在网络中交换数据时,为了核对双方对于高低位的认识是否是一致的,采用了一种很简便的方法,就是在文本流的开始时向对方发送一个标志符。如果之后的文本是高位在位,那就发送"FEFF",反之,则发送"FFFE"。不信你可以用二进制方式打开一个UTF-X格式的文件,看看开头两个字节是不是这两个字节?
讲到这里,我们再顺便说说一个很著名的奇怪现象:当你在 windows 的记事本里新建一个文件,输入"联通"两个字之后,保存,关闭,然后再次打开,你会发现这两个字已经消失了,代之的是几个乱码!呵呵,有人说这就是联通之所以拼不过移动的原因。其实这是因为GB2312编码与UTF8编码产生了编码冲撞的原因。
从网上引来一段从UNICODE到UTF8的转换规则:
例如"汉"字的Unicode编码是6C49。6C49在0800-FFFF之间,所以要用3字节模板:1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是:0110 1100 0100 1001,将这个比特流按三字节模板的分段方法分为0110 110001 001001,依次代替模板中的x,得到:1110-0110 10-110001 10-001001,即E6 B1 89,这就是其UTF8的编码。
而当你新建一个文本文件时,记事本的编码默认是ANSI, 如果你在ANSI的编码输入汉字,那么他实际就是GB系列的编码方式,在这种编码下,"联通"的内码是:
注意到了吗?第一二个字节、第三四个字节的起始部分的都是"110"和"10",正好与UTF8规则里的两字节模板是一致的,于是再次打开记事本时,记事本就误认为这是一个UTF8编码的文件,让我们把第一个字节的110和第二个字节的10去掉,我们就得到了"00001 101010",再把各位对齐,补上前导的0,就得到了"0000 0000 0110 1010",不好意思,这是UNICODE的006A,也就是小写的字母"j",而之后的两字节用UTF8解码之后是0368,这个字符什么也不是。这就是只有"联通"两个字的文件没有办法在记事本里正常显示的原因。
而如果你在"联通"之后多输入几个字,其他的字的编码不见得又恰好是110和10开始的字节,这样再次打开时,记事本就不会坚持这是一个utf8编码的文件,而会用ANSI的方式解读之,这时乱码又不出现了
下面是对编码的一个总结:也是参考了部分网上内容,各位不要tor我:学习而已
1、在中国,大陆最常用的就是GBK18030编码,除此之外还有GBK,GB2312,这几个编码的关系是这样的。
最早制定的汉字编码是GB2312,包括6763个汉字和682个其它符号;95年重新修订了编码,命名GBK1.0,共收录了21886个符号。之后又推出了GBK18030编码,共收录了27484个汉字,同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字,现在WINDOWS平台必需要支持GBK18030编码。按照GBK18030、GBK、GB2312的顺序,3种编码是向下兼容,同一个汉字在三个编码方案中是相同的编码。
2、台湾,香港等地使用的是BIG5编码
3、日本:SJIS编码
如果把各种文字编码形容为各地的方言,那么Unicode就是世界各国合作开发的一种语言。
在这种语言环境下,不会再有语言的编码冲突,在同屏下,可以显示任何语言的内容,这就是Unicode的最大好处。那么Unicode是如何编码的呢?其实非常简单。就是将世界上所有的文字用2个字节统一进行编码。可能你会问,2个字节最多能够表示65536个编码,够用吗?韩国和日本的大部分汉字都是从中国传播过去的,字型是完全一样的。比如:“文”字,GBK和SJIS中都是同一个汉字,只是编码不同而已。那样,像这样统一编码,2个字节就已经足够容纳世界上所有的语言的大部分文字了。
Unicode的学名是"Universal Multiple-Octet Coded Character Set",简称为UCS。
现在用的是UCS-2,即2个字节编码,而UCS-4是为了防止将来2个字节不够用才开发的。UCS-2也称为基本多文种平面,转换到UCS-4只是简单的在前面加2个字节0。UCS-4则主要用于保存辅助平面,例如Unicode 4.0中的第二辅助平面
总共增加了16个辅助平面,由原先的65536个编码扩展至将近100万编码。那么既然统一了编码,如何兼容原先各国的文字编码呢?这个时候就需要codepage了。
什么是codepage?codepage就是各国的文字编码和Unicode之间的映射表。
比如简体中文和Unicode的映射表就是CP936,点这里查看官方的映射表;以下是几个常用的codepage,相应的修改上面的地址的数字即可。
最后一个65001,据个人理解,应该只是一个虚拟的映射表,实际只是一个算法而已。
从936中随意取一行,例如:
0x9993 0x6ABD #CJK UNIFIED IDEOGRAPH
前面的编码是GBK的编码,后面的是Unicode。通过查这张表,就能简单的实现GBK和Unicode之间的转换。
现在明白了Unicode,那么UTF-8又是什么呢?又为什么会出现UTF-8呢?
ASCII转换成UCS-2,只是在编码前插入一个0x0。用这些编码,会包括一些控制符,比如 或 /,这在UNIX和一些C函数中,将会产生严重错误。因此可以肯定,UCS-2不适合作为Unicode的外部编码。因此,才诞生了UTF-8。那么UTF-8是如何编码的?又是如何解决UCS-2的问题呢?
按照UTF-8的编码规则,分解如下:xxxx0100 xx111101 xx100000,把除了x之外的数字拼接在一起,就变成“你”的Unicode编码了。注意UTF-8的最前面3个1,表示整个UTF-8串是由3个字节构成的。经过UTF-8编码之后,再也不会出现敏感字符了,因为最高位始终为1。
以下是Unicode和UTF-8之间的转换关系表:
Unicode编码转换到UTF-8,简单的把Unicode字节流套到x中就变成UTF-8了
很久很久以前,有一群人,他们决定用8个可以开合的晶体管来组合成不同的状态,以表示世界上的万物。他们看到8个开关状态是好的,于是他们把这称为"字节"。
再后来,他们又做了一些可以处理这些字节的机器,机器开动了,可以用字节来组合出很多状态,状态开始变来变去。他们看到这样是好的,于是它们就这机器称为"计算机"。
开始计算机只在美国用。八位的字节一共可以组合出256(2的8次方)种不同的状态。 他们把其中的编号从0开始的32种状态分别规定了特殊的用途,一但终端、打印机遇上约定好的这些字节被传过来时,就要做一些约定的动作。遇上0x10, 终端就换行,遇上0x07, 终端就向人们嘟嘟叫,例好遇上0x1b, 打印机就打印反白的字,或者终端就用彩色显示字母。他们看到这样很好,于是就把这些0x20以下的字节状态称为"控制码"。
他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示,一直编到了第127号,这样计算机就可以用不同字节来存储英语的文字了。大家看到这样,都感觉很好,于是大家都把这个方案叫做 ANSI 的"Ascii"编码(American Standard Code for Information Interchange,美国信息互换标准代码)。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。
后来,就像建造巴比伦塔一样,世界各地的都开始使用计算机,但是很多国家用的不是英文,他们的字母里有许多是ASCII里没有的,为了可以在计算机保存他们的文字,他们决定采用127号之后的空位来表示这些新的字母、符号,还加入了很多画表格时需要用下到的横线、竖线、交叉等形状,一直把序号编到了最后一个状态255。从128到255这一页的字符集被称"扩展字符集"。从此之后,贪婪的人类再没有新的状态可以用了,美帝国主义可能没有想到还有第三世界国家的人们也希望可以用到计算机吧!
等中国人们得到计算机时,已经没有可以利用的字节状态来表示汉字,况且有6000多个常用汉字需要保存呢。但是这难不倒智慧的中国人民,我们不客气地把那些127号之后的奇异符号们直接取消掉, 规定:一个小于127的字符的意义与原来相同,但两个大于127的字符连在一起时,就表示一个汉字,前面的一个字节(他称之为高字节)从0xA1用到0xF7,后面一个字节(低字节)从0xA1到0xFE,这样我们就可以组合出大约7000多个简体汉字了。在这些编码里,我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了,连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码,这就是常说的"全角"字符,而原来在127号以下的那些就叫"半角"字符了。
中国人民看到这样很不错,于是就把这种汉字方案叫做 "GB2312"。GB2312 是对 ASCII 的中文扩展。 但是中国的汉字太多了,我们很快就就发现有许多人的人名没有办法在这里打出来,特别是某些很会麻烦别人的国家领导人。于是我们不得不继续把 GB2312 没有用到的码位找出来老实不客气地用上。
后来还是不够用,于是干脆不再要求低字节一定是127号之后的内码,只要第一个字节是大于127就固定表示这是一个汉字的开始,不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准,GBK 包括了 GB2312 的所有内容,同时又增加了近20000个新的汉字(包括繁体字)和符号。
后来少数民族也要用电脑了,于是我们再扩展,又加了几千个新的少数民族的字,GBK 扩成了 GB18030。从此之后,中华民族的文化就可以在计算机时代中传承了。
中国的程序员们看到这一系列汉字编码的标准是好的,于是通称他们叫做 "DBCS"(Double Byte Charecter Set 双字节字符集)。在DBCS系列标准里,最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里,因此他们写的程序为了支持中文处理,必须要注意字串里的每一个字节的值,如果这个值是大于127的,那么就认为一个双字节字符集里的字符出现了。那时候凡是受过加持,会编程的计算机僧侣们都要每天念下面这个咒语数百遍:"一个汉字算两个英文字符!一个汉字算两个英文字符......"
因为当时各个国家都像中国这样搞出一套自己的编码标准,结果互相之间谁也不懂谁的编码,谁也不支持别人的编码,连大陆和台湾这样只相隔了150海里,使用着同一种语言的兄弟地区,也分别采用了不同的 DBCS 编码方案。当时的中国人想让电脑显示汉字,就必须装上一个"汉字系统",专门用来处理汉字的显示、输入的问题,但是那个台湾的愚昧封建人士写的算命程序就必须加装另一套支持 BIG5 编码的什么"倚天汉字系统"才可以用,装错了字符系统,显示就会乱了套!这怎么办?而且世界民族之林中还有那些一时用不上电脑的穷苦人民,他们的文字又怎么办? 真是计算机的巴比伦塔命题啊!
正在这时,大天使加百列及时出现了:一个叫 ISO (国际标谁化组织)的国际组织决定着手解决这个问题。他们采用的方法很简单:废了所有的地区性编码方案,重新搞一个包括了地球上所有文化、所有字母和符号的编码!他们打算叫它"Universal Multiple-Octet Coded Character Set",简称 UCS, 俗称 "UNICODE"。
UNICODE 开始制订时,计算机的存储器容量极大地发展了,空间再也不成为问题了。于是 ISO 就直接规定必须用两个字节,也就是16位来统一表示所有的字符,对于ascii里的那些"半角"字符,UNICODE 保持其原编码不变,只是将其长度由原来的8位扩展为16位,而其他文化和语言的字符则全部重新统一编码。由于"半角"英文符号只需要用到低8位,所以其高8位永远是0,因此这种大气的方案在保存英文文本时会多浪费一倍的空间。
这时候,从旧社会里走过来的程序员开始发现一个奇怪的现象:他们的strlen函数靠不住了,一个汉字不再是相当于两个字符了,而是一个!是的,从 UNICODE 开始,无论是半角的英文字母,还是全角的汉字,它们都是统一的"一个字符"!同时,也都是统一的"两个字节",请注意"字符"和"字节"两个术语的不同,"字节"是一个8位的物理存贮单元,而"字符"则是一个文化相关的符号。在UNICODE 中,一个字符就是两个字节。一个汉字算两个英文字符的时代已经快过去了。
从前多种字符集存在时,那些做多语言软件的公司遇上过很大麻烦,他们为了在不同的国家销售同一套软件,就不得不在区域化软件时也加持那个双字节字符集咒语,不仅要处处小心不要搞错,还要把软件中的文字在不同的字符集中转来转去。UNICODE 对于他们来说是一个很好的一揽子解决方案,于是从 Windows NT 开始,MS 趁机把它们的操作系统改了一遍,把所有的核心代码都改成了用 UNICODE 方式工作的版本,从这时开始,WINDOWS 系统终于无需要加装各种本土语言系统,就可以显示全世界上所有文化的字符了。
但是,UNICODE 在制订时没有考虑与任何一种现有的编码方案保持兼容,这使得 GBK 与UNICODE 在汉字的内码编排上完全是不一样的,没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换,这种转换必须通过查表来进行。
如前所述,UNICODE 是用两个字节来表示为一个字符,他总共可以组合出65535不同的字符,这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系,ISO已经准备了UCS-4方案,说简单了就是四个字节来表示一个字符,这样我们就可以组合出21亿个不同的字符出来(最高位有其他用途),这大概可以用到银河联邦成立那一天吧!
UNICODE 来到时,一起到来的还有计算机网络的兴起,UNICODE 如何在网络上传输也是一个必须考虑的问题,于是面向传输的众多 UTF(UCS Transfer Format)标准出现了,顾名思义,UTF8就是每次8个位传输数据,而UTF16就是每次16个位,只不过为了传输时的可靠性,从UNICODE到UTF时并不是直接的对应,而是要过一些算法和规则来转换。
受到过网络编程加持的计算机僧侣们都知道,在网络里传递信息时有一个很重要的问题,就是对于数据高低位的解读方式,一些计算机是采用低位先发送的方法,例如我们PC机采用的 INTEL 架构,而另一些是采用高位先发送的方式,在网络中交换数据时,为了核对双方对于高低位的认识是否是一致的,采用了一种很简便的方法,就是在文本流的开始时向对方发送一个标志符。如果之后的文本是高位在位,那就发送"FEFF",反之,则发送"FFFE"。不信你可以用二进制方式打开一个UTF-X格式的文件,看看开头两个字节是不是这两个字节?
讲到这里,我们再顺便说说一个很著名的奇怪现象:当你在 windows 的记事本里新建一个文件,输入"联通"两个字之后,保存,关闭,然后再次打开,你会发现这两个字已经消失了,代之的是几个乱码!呵呵,有人说这就是联通之所以拼不过移动的原因。其实这是因为GB2312编码与UTF8编码产生了编码冲撞的原因。
从网上引来一段从UNICODE到UTF8的转换规则:
Unicode UTF-8 0000 - 007F 0xxxxxxx 0080 - 07FF 110xxxxx 10xxxxxx 0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx
例如"汉"字的Unicode编码是6C49。6C49在0800-FFFF之间,所以要用3字节模板:1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是:0110 1100 0100 1001,将这个比特流按三字节模板的分段方法分为0110 110001 001001,依次代替模板中的x,得到:1110-0110 10-110001 10-001001,即E6 B1 89,这就是其UTF8的编码。
而当你新建一个文本文件时,记事本的编码默认是ANSI, 如果你在ANSI的编码输入汉字,那么他实际就是GB系列的编码方式,在这种编码下,"联通"的内码是:
c1 1100 0001 aa 1010 1010 cd 1100 1101 a8 1010 1000
注意到了吗?第一二个字节、第三四个字节的起始部分的都是"110"和"10",正好与UTF8规则里的两字节模板是一致的,于是再次打开记事本时,记事本就误认为这是一个UTF8编码的文件,让我们把第一个字节的110和第二个字节的10去掉,我们就得到了"00001 101010",再把各位对齐,补上前导的0,就得到了"0000 0000 0110 1010",不好意思,这是UNICODE的006A,也就是小写的字母"j",而之后的两字节用UTF8解码之后是0368,这个字符什么也不是。这就是只有"联通"两个字的文件没有办法在记事本里正常显示的原因。
而如果你在"联通"之后多输入几个字,其他的字的编码不见得又恰好是110和10开始的字节,这样再次打开时,记事本就不会坚持这是一个utf8编码的文件,而会用ANSI的方式解读之,这时乱码又不出现了
下面是对编码的一个总结:也是参考了部分网上内容,各位不要tor我:学习而已
1、在中国,大陆最常用的就是GBK18030编码,除此之外还有GBK,GB2312,这几个编码的关系是这样的。
最早制定的汉字编码是GB2312,包括6763个汉字和682个其它符号;95年重新修订了编码,命名GBK1.0,共收录了21886个符号。之后又推出了GBK18030编码,共收录了27484个汉字,同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字,现在WINDOWS平台必需要支持GBK18030编码。按照GBK18030、GBK、GB2312的顺序,3种编码是向下兼容,同一个汉字在三个编码方案中是相同的编码。
2、台湾,香港等地使用的是BIG5编码
3、日本:SJIS编码
如果把各种文字编码形容为各地的方言,那么Unicode就是世界各国合作开发的一种语言。
在这种语言环境下,不会再有语言的编码冲突,在同屏下,可以显示任何语言的内容,这就是Unicode的最大好处。那么Unicode是如何编码的呢?其实非常简单。就是将世界上所有的文字用2个字节统一进行编码。可能你会问,2个字节最多能够表示65536个编码,够用吗?韩国和日本的大部分汉字都是从中国传播过去的,字型是完全一样的。比如:“文”字,GBK和SJIS中都是同一个汉字,只是编码不同而已。那样,像这样统一编码,2个字节就已经足够容纳世界上所有的语言的大部分文字了。
Unicode的学名是"Universal Multiple-Octet Coded Character Set",简称为UCS。
现在用的是UCS-2,即2个字节编码,而UCS-4是为了防止将来2个字节不够用才开发的。UCS-2也称为基本多文种平面,转换到UCS-4只是简单的在前面加2个字节0。UCS-4则主要用于保存辅助平面,例如Unicode 4.0中的第二辅助平面
20000-20FFF - 21000-21FFF - 22000-22FFF - 23000-23FFF - 24000-24FFF - 25000-25FFF - 26000-26FFF - 27000-27FFF - 28000-28FFF - 29000-29FFF - 2A000-2AFFF - 2F000-2FFFF
总共增加了16个辅助平面,由原先的65536个编码扩展至将近100万编码。那么既然统一了编码,如何兼容原先各国的文字编码呢?这个时候就需要codepage了。
什么是codepage?codepage就是各国的文字编码和Unicode之间的映射表。
比如简体中文和Unicode的映射表就是CP936,点这里查看官方的映射表;以下是几个常用的codepage,相应的修改上面的地址的数字即可。
codepage=936 简体中文GBK codepage=950 繁体中文BIG5 codepage=437 美国/加拿大英语 codepage=932 日文 codepage=949 韩文 codepage=866 俄文 codepage=65001 unicode UFT-8
最后一个65001,据个人理解,应该只是一个虚拟的映射表,实际只是一个算法而已。
从936中随意取一行,例如:
0x9993 0x6ABD #CJK UNIFIED IDEOGRAPH
前面的编码是GBK的编码,后面的是Unicode。通过查这张表,就能简单的实现GBK和Unicode之间的转换。
现在明白了Unicode,那么UTF-8又是什么呢?又为什么会出现UTF-8呢?
ASCII转换成UCS-2,只是在编码前插入一个0x0。用这些编码,会包括一些控制符,比如 或 /,这在UNIX和一些C函数中,将会产生严重错误。因此可以肯定,UCS-2不适合作为Unicode的外部编码。因此,才诞生了UTF-8。那么UTF-8是如何编码的?又是如何解决UCS-2的问题呢?
例: E4 BD A0 11100100 10111101 10100000 这是“你”字的UTF-8编码 4F 60 01001111 01100000 这是“你”的Unicode编码
按照UTF-8的编码规则,分解如下:xxxx0100 xx111101 xx100000,把除了x之外的数字拼接在一起,就变成“你”的Unicode编码了。注意UTF-8的最前面3个1,表示整个UTF-8串是由3个字节构成的。经过UTF-8编码之后,再也不会出现敏感字符了,因为最高位始终为1。
以下是Unicode和UTF-8之间的转换关系表:
U-00000000 - U-0000007F: 0xxxxxxx U-00000080 - U-000007FF: 110xxxxx 10xxxxxx U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
Unicode编码转换到UTF-8,简单的把Unicode字节流套到x中就变成UTF-8了
发表评论
-
ArrayList添加add方法效率
2013-05-09 19:24 1578public static void main(Strin ... -
Java设计模式之组合模式(Composite)
2012-11-16 11:08 13859Composite模式定义: 将对象以树形结构 ... -
HashMap用法熟悉
2012-11-11 23:43 1438HashMap排列没有按一定规则示例代码: public ... -
谈java的导入(import)
2012-06-10 16:53 1751单类型导入(single-type-import),例如imp ... -
TCP和UDP协议理解
2011-12-04 21:32 1460我们学习过什么是 ... -
华为的一道面试题
2011-11-01 10:26 1626代码如下: package com.ex; publ ... -
Java中静态变量的初始化问题
2011-10-24 11:04 10767/** * java中的内存有一块地址叫"静态代 ... -
Java引用了解
2011-10-16 16:29 1209正常来说,传统的JAVA引用,如 public ... -
Java中的抽象类和接口的区别
2011-08-21 08:47 1171Java语言中, abstract class 和in ... -
谈谈final, finally, finalize的区别
2011-08-20 10:37 1283final—修饰符(关键字)如果一个类被声明为fi ... -
Java中重载和重写的区别
2011-08-20 10:17 1141这个问题已经研究了好多遍了,总是忘记,就整理下来加深印象: ... -
Hashtable和HashMap
2011-08-20 09:55 11092者概念: Hashtable继承自Dictionary类 ... -
Java中HashCode()理解
2011-08-20 09:42 1109先从一个java基础面试的问题开始引入吧: 问题: 两个对象值 ... -
java继承复习
2011-07-24 14:30 867package com.edison; public ... -
Java多态机制中的绑定规则
2011-07-23 10:25 1533package com.example; publi ... -
java接口进一步理解(二)
2011-07-23 09:54 1116抽象类与接口比较: 1.抽象类与接口都位于继承树的上层 相 ... -
java接口进一步理解(一)
2011-07-23 09:47 1294今天来整理篇关于java接口知识的文章: 首先我们知道 ... -
SimpleDateFormat的常用方法
2011-07-22 10:17 1122/** parse()可以 把String型的字符串转换成 ... -
内部类使用总结(参考白度文献上的文章)
2011-07-21 22:00 1131我是一个java基础不太好 ... -
线程和Runnable接口的理解
2011-06-21 11:59 1194通过卖票来进行解释: 1.ThreadTicket.java: ...
相关推荐
#### 三、Java编码转换的详细过程 Java程序从开发到运行的过程中,涉及到多个环节的编码转换,主要包括: 1. **源文件编码**:Java源文件(`.java`)在保存时通常采用操作系统默认的编码格式。例如,在中文Windows...
在Java编程中,中文乱码问题是一个常见的困扰,尤其是在处理文件读写、网络传输或数据库操作时。本文将深入探讨几种解决Java中中文乱码问题的方法,并以MyEclipse为开发环境,结合实际示例进行讲解。 1. 文件读写中...
JAVA 中文乱码问题是开发过程中常见的问题之一,解决这个问题需要了解乱码产生的原因,然后对症下药。下面我们对容易产生乱码问题的场景进行分析,并提出解决方案。 1. 以 POST 方法提交的表单数据中有中文字符 在...
在Java编程语言中,编码和转换是至关重要的概念,特别是在处理...正确理解和使用各种编码方法,以及在适当的地方设置合适的字符集,是避免乱码问题的关键。理解这些概念和操作,对于开发跨平台、多语言的应用至关重要。
在Java编程中,中文编码问题是一个常见的挑战,尤其是在处理文本输入、输出以及网络通信时。本文将深入探讨Java中的中文编码问题,以及如何有效地解决这些问题。 首先,我们要了解字符编码的基本概念。字符编码是...
总之,解决Java中的URL中文乱码问题需要理解URL编码的原理,并在客户端和服务器端采取相应的措施,确保编码和解码的一致性。无论是通过JavaScript编码、Java服务器端解码,还是调整服务器配置,关键在于确保字符集的...
Java 中文乱码问题是一个老生常谈的问题,特别是在 Web 应用中。今天,我们将从编码角度分析 Java 编译后在控制台和 Web 等终端显示乱码问题。 一、 Java 处理字符的原理 Java 使用 UNICODE 来存储字符数据,处理...
"Java中文乱码问题解决" ...解决Java中文乱码问题需要了解编码的基本原理和各种编码格式的区别,并了解Java中常见的编码格式和应用场景。只有这样,才能更好地避免乱码问题,提高Java开发的效率和质量。
Java 解决中文乱码问题 Java 中文乱码问题是中国程序员无法避免的话题。乱码的出现是由于中文和英文的编码格式不同,解码也是不一样...解决 Java 中文乱码问题的关键是选择合适的编码方式和正确地配置 Tomcat 和 JSP。
Java编程语言在处理中文字符时可能会遇到乱码问题,这主要源于Java的源代码编码、JVM处理class文件以及不同操作系统、数据库系统之间的编码不一致。本文深入剖析了Java中文问题的根源,并提供了相应的解决方案。 一...
在Java开发过程中,中文乱码...理解字符编码的工作原理,以及如何在Java中操作字符编码,对于避免和解决乱码问题至关重要。在实际项目开发中,养成良好的编码习惯,如始终使用UTF-8编码,可以显著减少乱码问题的出现。
在Java编程中,中文乱码问题是一个常见的困扰开发者的问题,特别是在处理输入输出或者网络通信时。这个问题涉及到字符编码的理解和正确使用。以下是对这个主题的详细解析: 首先,我们需要了解字符编码的基础知识。...
在Java开发过程中,中文乱码问题是一个常见的困扰。这主要涉及到字符编码的处理,包括客户端浏览器、服务器端、以及在不同传输方式(如GET、POST)下的数据编码和解码。以下将详细讨论这些知识点: 1. **客户端与...
### 深入分析Java中的中文编码问题 #### 一、引言 在软件开发过程中,尤其是涉及到国际化和多语言支持的应用中,编码问题一直是令开发者头疼的问题之一。尤其是在使用Java这种跨平台语言进行开发时,不同的操作...
java aspose word 上传到服务器 导出的word 中文字体乱码 的问题 java aspose java aspose word 上传到服务器 导出的word 中文字体乱码 的问题 java aspose java aspose word 上传到服务器 导出的word 中文字体乱码 ...
网上很多描述java解压中文乱码的问题,很多描述不全.由于工作需要整理出一个完整版.简单实用.下载后请从ZipUtil.java的main方法开始,一目了然. public static void main(String args[]) { new ZipUtil().unZip("E:\\...
总结来说,处理Java中ZIP文件的中文乱码问题,关键在于明确指定字符集,通常是UTF-8,无论是使用Java内置的API还是第三方库。同时,理解文件系统的编码和压缩/解压过程中的字符编码转换也非常重要。通过这种方式,...
总的来说,处理Java中CSV文件的中文乱码问题主要涉及正确设置字符编码,而给定的.NET DLL文件与此问题的解决没有直接关联。如果你在.NET环境中遇到类似问题,可以参考.NET的编码处理方式,或者寻找适合的.NET库来...
### Java编程中乱码问题解决 在Java编程中,乱码问题是开发者经常遇到的一个难题,尤其是在处理中文或者其他非英文字符时。本文将详细介绍如何解决Java编程中常见的乱码问题,并提供具体的实例帮助读者理解。 ####...