- 浏览: 1657882 次
- 性别:
文章分类
- 全部博客 (2929)
- 非技术 (18)
- Eclipse (11)
- JAVA (31)
- 正则表达式 (0)
- J2EE (4)
- DOS命令 (2)
- WEB前端 (52)
- JavaScript (69)
- 数据库 (8)
- 设计模式 (0)
- JFreechart (1)
- 操作系统 (1)
- 互联网 (10)
- EasyMock (1)
- jQuery (5)
- Struts2 (12)
- Spring (24)
- 浏览器 (16)
- OGNL (1)
- WebService (12)
- OSGi (14)
- 软件 (10)
- Tomcat (2)
- Ext (3)
- SiteMesh (2)
- 开源软件 (2)
- Hibernate (2)
- Quartz (6)
- iBatis (2)
最新评论
中文化和国际化问题权威解析之一:字符编码发展历程 收藏
<script type="text/javascript"> document.body.oncopy = function() { if (window.clipboardData) { setTimeout(function() { var text = clipboardData.getData("text"); if (text && text.length>300) { text = text + "/r/n/n本文来自CSDN博客,转载请标明出处:" + location.href; clipboardData.setData("text", text); } }, 100); } } </script><script class="blogstory">function StorePage(){d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://www.365key.com/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'keyit','scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes'));keyit.focus();}</script>
前几天看文初的《精武门之Web安全研讨会首日感受 》,说到利用字符集攻击时提到以前宝宝写的一篇有关国际化的文章,趁机再次拜读了宝宝的这篇大作,不得不感慨宝宝的写作功底,无敌!这么好的文章不分享出来实在是太可惜了,在此将宝宝的大作转帖于此;
作者序
在我开发 Java 程序的几年中,遇到得最多,也是别人向我提问最多的问题,就是各种各样看似稀奇古怪的中文乱码问题了。网上也有许多解释和解决 Java 中文问题的文章,但水平参差不齐,有一些文章甚至是错误的。
此外,我们公司自己的 Java 程序从一开始就采用了错误的方式处理中文问题,虽能解一时之急,却引出了越来越多的深远的问题。每当我听到有的同事还在讨论如何特殊处理双字节的中文 GB 码,就感慨他们思路的狭隘。试问,今天我们可以用特殊的方式处理我们所熟悉的中文编码,可是今后我们怎样才能应付日文版、韩文版、或世界其它国家语言的产品开发呢?
在我看来,与其说这些问题是 “ 中文化问题 ” ,不如说是 “ 国际化问题 ” 。所谓的 “ 汉化 ” 这 种说法已经随时代远去了。想想看,这个词带有明显的小农经济的色彩:自家汉化自家用,哪管世界变化多。经过汉化的软件,常常意味着:版本落后、不兼容、不 稳定。为什么会这样呢?根本原因是,从软件的设计阶段,就没有考虑国际用户的需要,没有采用国际通用的标准。事后要弥补自然难上加难。
所以让我们把眼光放开,想一想 “ 国际化 ” 。当然国际化的目的还是生产出 “ 汉化 ” 的软件,但我们可以用同样的方法 “ 韩化 ” 、 “ 日化 ” 、 “ 阿拉伯化 ” ,统称为 “ 本地化 ” —— 这就是 “ 国际化 ” 的目的。国际化和本地化有两个很体面的英文缩写: I18n ( Internationalization )和 L10n ( Localization )。
想要开发出国际化的软件产品,首先要了解国际标准,而不是使用东拼西凑的权宜之计。本文首先从相关国际标准的讨论切入,相信正确地理解和应用这些标准,所有的 “ 中文化问题 ” 或 “ 国际化问题 ” 都会迎刃而解。
字符编码简介
ASCII 码
从学计算机的那天开始,老师就告诉我们在计算机里面,所有的英文字母都对应到一个数字编码,这就是 ASCII 码( American Standard Code for Information Interchange )。 ASCII 码是很久很久以前( 1968 年)制定的。它只使用了一个 8 位字节中的低 7 位,总共是 127 个编码位。这样的方案很快就不够使用了。
单字节编码的发展
在 80 年代早期,一些现在流行的标准(如 ISO 8859 和 Unicode )还未出现。那时为了支持多种地区的语言,各大组织机构或 IT 厂商开始发明它们自己的编码方案,以便弥补 ASCII 编码的不足。一时间,各种互不相容的字符编码方案成百花齐放之势。
为了避免混乱, ISO 组织在 1998 年之后,陆续发表了一系列代号为 8859 的标准,作为 ASCII 编码的标准扩展,终于统一了单字节的西方字符的编码。 ISO 是设在瑞士的国际标准化组织的简称( International Organization for Standardization )。
ISO-8859-1 ( Latin1 - 西欧字符)
ISO-8859-1 覆盖了大多数西欧语言,包括:法国、西班牙、葡萄牙、意大利、荷兰、德国、丹麦、瑞典、挪威、芬兰、冰岛、爱尔兰、苏格兰、英格兰等,因而也涉及到了整个美洲大陆、澳大利亚和非洲很多国家的语言。
此外, ISO-8859-1 后来被采纳为 ISO-10646 标准(后面会讲到)的首页,换句话说, Unicode 的最开头 256 个字符编码和 ISO-8859-1 是一一对应的。正是由于这个特殊性,使很多人产生了对 ISO-8859-1 编码的误用。
ISO-8859 标准还包括:
- ISO-8859-2 ( Latin2 - 中、东欧字符)
- ISO-8859-3 ( Latin3 - 南欧字符)
- ISO-8859-4 ( Latin4 - 北欧字符)
- ISO-8859-5 ( Cyrillic - 斯拉夫语)
- ISO-8859-6 ( Arabic - 阿拉伯语)
- ISO-8859-7 ( Greek - 希腊语)
- ISO-8859-8 ( Hebrew - 希伯来语)
- ISO-8859-9 ( Latin5 )
- ISO-8859-10 ( Latin6 )
- ISO-8859-11 ( Thai - 泰国语)
- ISO-8859-12 (保留)
- ISO-8859-13 ( Latin7 )
- ISO-8859-14 ( Latin8 )
- ISO-8859-15 ( Latin9 )
但是 ISO 8859 系列标准的字符编码,还是互不相容,不可能同时使用的。毕竟它们只是单字节的编码方案。而且,它们和多字节的编码方案如中文编码 GB2312 和 BIG5 也是不相容的。那些欧洲字符(最高位为 1 的字符),在 GB2312 和 BIG5 中被认为是双字节汉字编码的首字节。
多字节编码的发展
单字节编码只有 256 个码位( 28 =256 ),而中文字符何止千千万,单字节编码不可能满足中文编码的需要。于是为了适应东方文字信息处理的需要, ISO 又制定了 ISO 2022 标准( Character code structure and extension techniques ),提供了七位与八位编码字符集的扩充方法的标准。我国根据 ISO 2022 制定了国家标准 GB2311 —— 《信息交换用七位编码字符集的扩充方法》,并根据该标准制定了国家标准 GB2312-80 编码。其他东方国家和地区也制定了各自的字符编码标准,如日本的 JIS0208 ,韩国的 KSC5601 ,台湾地区的 CNS11643 等。
BIG5
BIG5 是从 CNS11643 的早期版本发展而来的,虽然没有包括 CNS11643 的全部内容,但却是目前台湾、香港地区普遍使用的一种繁体汉字的市场标准,包括 440 个符号,一级汉字 5401 个、二级汉字 7652 个,共计 13060 个汉字。
GB2312-80
全称是《信息交换用汉字编码字符集 基本集》, 1980 年发布,是中文信息处理的国家标准,在大陆及海外使用简体中文的地区(如新加坡等)是强制使用的唯一中文编码。
· 双字节编码
· A1-A9 :符号区,包含 682 个符号
· B0-F7 :汉字区,包含 6763 个汉字
GB2312 码共收录 6763 个简体汉字、 682 个符号,其中汉字部分:一级字 3755 ,以拼音排序,二级字 3008 ,以偏旁排序。该标准的制定和应用为规范、推动中文信息化进程起了很大作用。
GBK
汉字内码扩展规范( GBK )是国家技术监督局 1995 年为中文 Windows 95 所制定的新的汉字内码规范。
· 双字节编码, GB2312-80 的扩充,在码位上和 GB2312-80 兼容。
· 范围: 8140 ~ FEFE (剔除 xx7F )共 23940 个码位。
· 包含 21003 个汉字,包含了 ISO 10646 中的全部中日韩汉字,简、繁体字融于一库。
严格说, GBK 不能算是国家标准,最多算是一个商业标准。而 GB18030 才是真正的国家标准。
GB18030-2000
全称是《信息交换用汉字编码字符集》,是我国的强制标准,所有不支持 GB18030 标准的软件将不能作为产品出售。
· 单字节、双字节、四字节编码。
· 向下与 GB2312 编码兼容。
· 支持 GB 13000.1-1993 中的全部中、日、韩( CJK )统一汉字字符和全部 CJK 统一汉字扩展 A 的字符。
虽然 GB18030 标准非常强大,但它是一个中国大陆的标准。在编码上,除了和 GB2312 以外,还是不能和世界上其它任何一种字符编码统一。
终极标准 —— Unicode 和 ISO 10646
前面所讲的一切字符编码方案,都是针对局部地区或少数语言文字的,没有办法同时表达所有的语言文字,或在多种语言平台上交换。这对今天极其频繁的国际信息交流是不相称的。
为了提高计算机的信息处理和交换功能,使得世界各国的文字都能在计算机中处理,从 1984 年起, ISO 组织就开始研究制定一个全新的标准:通用多八位编码字符集( Universal Multiple-Octet Coded Character Set ),简称 UCS 。标准的编号为: ISO 10646 。这一标准为世界各种主要语言的字符 ( 包括简体及繁体的中文字 ) 及附加符号,编制统一的内码。
统一码( Unicode )是 Universal Code 的缩写,是由另一个叫 “Unicode 学术学会 ” ( The Unicode Consortium )的机构制定的字符编码系统。 Unicode 与 ISO 10646 国际编码标准从内容上来说是同步一致的。
Unicode 是 Java 语言和 XML 的基础,所以我们要稍微详细地介绍一下 Unicode 以及 ISO 10646 标准。
注意: 不够耐心的读者可以跳过本章的余下部分。但显然了解本章所描述的 Unicode 及相关编码的技术细节,有利于你更好地理解和应用 Unicode 。
Unicode 和 ISO 10646 的关系
在 1991 年, Unicode 学术学会与 ISO 国际标准化组织决定共同制订一套适用于多种语言文本的通用编码标准。 Unicode 与 ISO 10646 国际编码标准于 1992 年 1 月正式合作发展一套通用编码标准。自此,两个组织便一直紧密合作,同步发展 Unicode 及 ISO 10646 国际编码标准。
ISO 10646 ( UCS ) |
Unicode |
1993 年, ISO 组织发表 ISO 10646 国际编码标准的第一个版本,全名是 ISO/IEC 10646-1:1993 。它收录了 20902 个表意字符( ideograph ,中日韩文均属表意字符)。 |
同年, Unicode 学术学会根据 ISO/IEC 10646-1:1993 修订了 Unicode 1.0 ,发布 Unicode 1.1 。 |
不断改善和修订 ISO 10646 标准。 |
1996 年发表 Unicode 2.0 , 1998 年发表 Unicode 2.1 ,根据 ISO 10646 做了一些改善和修订,新增了欧元符号。 |
2000 年 10 月发表了 ISO 10646 第二版的第一部分: ISO/IEC 10646-1:2000 ,新增收了 6,582 个表意字符于扩展区 A 中( CJK Unified Ideographs Extension A )。 |
2000 年 2 月,发表 Unicode 3.0 ,也包含了同样的 CJK Ext A 。 |
2001 年,发表了 ISO/IEC 10646 的第二部分,增收了 42711 个表意字符于扩展区 B 里。 |
2001 年, Unicode 发表 3.1 版,将 CJK Ext B 纳入新版 Unicode 中。 |
虽然两个组织保持如此密切的合作关系,但 Unicode 和 ISO 10646 还是有区别的。 ISO 10646 着重定义字符编码,而 Unicode 则在此基础上,为这些字符及编码数据提出应用的方法以及对语义数据作补充。
UCS 的结构
UCS 的结构是一个四维的编码空间,每一维由一个字节(八位二进制位)组成,范围是 00 到 FF 。总体上分为 128 个群组 (Group 00-7F) ,每一群组由 256 个平面 (Plane 00-FF) 组成,每一平面有 256 行 (Row 00-FF) ,每一行 256 个编码位 (Cell 00-FF) 。所以,每一平面包括 65,536 个字符位 (Character Position 0000-FFFF) 。
整个编码字符集的每个字符都由 4 个字节,按 “ 组 - 面 - 行 - 列 ” 的顺序表示。所以 UCS 的可编码空间为: 128 × 256 × 256 × 256 = 231 。
UCS 将其第一个平面 (00 群组中的 00 平面 ) 称作基本多语种平面( Basic Multilingual Plane , BMP )。
在 UCS 中,目前只有 00 组是重要的, Unicode 学术学会断言,在可以预见的将来,甚至不可能用完 00 组中的前 17 个平面( 00 平面到 10 平面)。因此, Unicode 只定义了 ISO 10646 的第 00 组的前 17 个平面。事实上,目前绝大多数字符,都分配在第 00 平面 BMP 中。
下表中列出了 BMP 中的字符分配情况:
区间 |
描述 |
( 0000-1FFF )基本拼音字符区 |
包括所有拼读文字的字母拼音和音标。它的字符集一般较小,如:拉丁文、西里尔文、希腊文、希伯来文、阿拉伯文、泰文、天成文书(梵文)等。 |
( 2000-28FF )符号区 |
包括许多种用于标点、数学、化学、科技及其它特殊用途上的 “ 符号 ” 和 “ 丁贝符 ” (示意图形符号)。 |
( 2E80-33FF )中日韩语音及符号区 |
包括用于中国、日本、韩国语言中的标点、符号、字根(笔画)及发音等字符。 |
( 3400-9FA5 )中日韩汉字字符区 |
由 27,484 个中日韩(越)的统一汉字组成。 |
( A000-A4C6 )彝族字符区 |
由 1,165 个中国南方彝族音节和 50 个其字根组成。 |
( AC00-D7A3 )韩字符拼音区 |
由 11,172 个预先组合的韩字符拼音音节组成。 |
( D800-DFFF )代理区 |
这个区被平分为 1024 个 “ 高半代理区 ” ( D800-DBFF )码位和 1024 个 “ 低半代理区 ” ( DC00-DFFF )码位,用来形成代理对,可以得到超过一百万个扩充编码位。 |
( E000-F8FF )私人专用区 |
包含 6,400 个编码位,用于用户或开发商自行定义的字符编码。 |
( F900-FA2D )兼容字符区 |
包括一些被许多行业协会和国家标准广泛使用的字符,但在 Unicode 编码中有不同的表现形式。包含一些专用字符。 |
UCS 的表现形式
UCS 有两种方式来表示一个字符编码:四字节正规形式( UCS-4 , Four-octet canonical form )和双字节基本平面形式( UCS-2 , Two-octet BMP form )。
UCS-4 —— 四字节正规形式
UCS-4 用 4 个字节来表示一个字符。第一个字节表示组( Group ),第二表示平面( Plane ),第三表示行( Row ),第四表示单元号或列( Cell )。
UCS-2 —— 双字节基本平面形式
当系统只使用 BMP 的字符码时,可以省略群组和平面中的八位,将字符码由 32 个位缩短为 16 个位( 2 个字节)。标记为 UCS-2 。
Unicode 和 UCS-2 同样采用 16 位编码。所以一般 可以把 Unicode 和 UCS-2 看作是同一样东西 。
代理对( Surrogate Pair )
UCS-4 定义了 4 个字节表示一个字符,用来应付将来的扩展是绰绰有余。可是 Unicode 和 UCS-2 只定义了 2 个字节,却很容易用尽。代理对( Surrogate Pair )的设计在这种背景下应运而生。
UCS-2 在 BMP 中开辟了一个特殊的区间( D800 - DFFF ) -- 代理区,并平分成两个区,分别称为高半代理区( High-half Zone , D800 - DBFF ),和低半代理区( Low-half Zone , DC00 - DFFF ),各有 1024 个码位。使用时,从高低两个代理区中各取一个编码组成一个四字节的代理,来表示一个在 BMP 以外平面上的编码字符位。这样一来,总共可以多表示 1024×1024 个字符,映射到 00 群组中的 01 到 10 平面(共 16 个平面)。
代理对提供了用 BMP 的 2 字节编码来表示在基本多文种平面( BMP )之外的 16 个平面编码的机制。一些不常用的字符可以用代理对表示。目前,只有 ISO/IEC 10646-2:2001 和 Unicode 3.1 才使用到代理对。
高半代理区和低半代理区的划分,使编码位相互区分开。非代理区字符一定不会在这个区里。因为高半代理区和低半代理区不相交,所以很容易决定字符值的边界。一个完好的文本中,高半代理码和低半代理码总是按先后成对出现。
如果在实现上没有删除代理码或在代理码对中插入字符,数据的完整性就可得到保证。即使数据有残损,也只是局部的。一个残缺的码只影响一个字符。因为高半代理区和低半代理区不相交,且成对出现,错码不会传到文本的其它部分。
具体来说,一个代理对( H , L )由码值为 D800-DBFF 的高半代理码 H 和码值为 DC00-DFFF 低半代理码 L 组成。将一个字符映射到 UCS-4 码位中。假设 N 是 UCS-4 码值,则有:(以下所有数字均为 16 进制)
N = (H - D800) × 400 + (L - DC00) + 10000
于是得到 N 的码值为 10000 到 10FFFF 。
注意
Unicode 3.0 没有用到代理对,直到 3.1 才增加了 CJK Ext B ,用到了 02 平面,需要使用代理对才能访问。但 99.99% 的情况下,根本用不到那些字。此外, JDK1.4 只支持到 Unicode 3.0 ,所以目前 Java 还不能应用代理对。
UTF 编码
UTF 为 UCS Transformation Format 的缩写,意为 “UCS 转换格式 ” 。 UCS 只是一个字形和内码上的标准,并没有定义实际在计算机上存取的方法,而 UTF 便定义了一整套的计算机存取 UCS 编码的转换格式,并考虑了与其它编码方式兼容。常用的格式有 UTF-8 和 UTF-16 。有时也用到 UTF-7 来进行 7 位数据传输。
UTF-16
UTF-16 是用定长 16 位( 2 字节)来表示的 UCS-2 或 Unicode 转换格式。它将 Unicode 的编码值变成 2 字节的 Big-endian (高位字节在前,低位字节在后)或 Little-endian (低位字节在前,高位字节在后)编码。 UTF-16 利用代理对来访问 BMP 之外的字符编码。
Java 使用 Big-endian 系统,而 Intel 系列处理器内部使用 Little-endian 系统(学汇编语言和 C 语言的人都知道)。
例如: “ 中国 ” 两字, Unicode 是 4E2D 56FD ,在 Windows 上用 UTF-16 编码,结果为四个字节: 2D 4E FD 56 ;如果使用 Java 输出,结果为: 4E 2D 56 FD 。
使用 UTF-16 有什么缺点呢?很显然,
1. 所有原本 1 个字节就可以表示的西方字符,现在要用 2 个字节来表示,体积大了一倍。
2. 学过 C 的人都知道, 0x00 代表 C 字符串的结尾。但是用 UTF-16 来表示单字节字符( ISO-8859-1 )时,高位字节为 0x00 。这样就会使 C 语言库函数发生误判。用 UTF-16 表示文件名、网址等,全引出无数的问题。
3. 字符的边界不好找。程序处理时必须从字符串的头部开始扫描,才可能正确地找出一个字符的边界,效率较低。此外,万一坏掉一个字节,这个字节之后的字符都会错位,坏掉一片。
所有的这些问题,在 UTF-8 中都不存在。
但是, UTF-16 也有其天然的优点:它直接表现了字符编码的整数值。所以 UTF-16 是最直接的 Unicode 表示法。此外,它是定长的,这大大简化了字符串的操作。 Java 语言就是用 UTF-16 格式将字符存储在内存中的。正是这样,才使 Java 的 Unicode 字符串的操作格外简单高效。
UTF-8
UTF-8 使用了变长技术,在每一个编码区域有不同的字码长度:
1. 对 UCS-2 ,由 1 字节至 3 字节构成;
2. 如果 UCS-2 使用了代理对,则 UTF-8 最长可到 4 字节;
3. 对 UCS-4 ,由 1 字节至 6 字节构成。
因为以字节( 8 位)为组成单元,故称为 “UTF-8 ” 。对于英文文本, UTF-8 的文件大小比其它转换格式都小。
在 UTF-8 内,字符由 1 个至 6 个字节为组合。下表列举出了不同范围的 UCS 码转换成 UTF-8 的规则。英文字母 “x” 代表可以用来记录 Unicode 码值的区域。
UCS-4 区域(十六进制) |
UTF-8 字节组合(二进制) |
0000 0000 —— 0000 007F |
0xxxxxxx |
0000 0080 —— 0000 07FF |
110xxxxx 10xxxxxx |
0000 0800 —— 0000 FFFF |
1110xxxx 10xxxxxx 10xxxxxx |
0001 0000 —— 001F FFFF |
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
0020 0000 —— 03FF FFFF |
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx |
0400 0000 —— 7FFF FFFF |
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx |
在 UTF-8 内,
1. 如果一个字节,最高位(第 8 位)为 0 ,表示这是一个 ASCII 字符( 00 - 7F )。可见,所有 ASCII 编码已经是 UTF-8 了。
2. 如果一个字节,以 11 开头,连续的 1 的个数暗示这个字符的字节数,例如: 110xxxxx 代表它是双字节 UTF-8 字符的首字节。
3. 如果一个字节,以 10 开始,表示它不是首字节,需要向前查找才能得到当前字符的首字节。
可见 UTF-8 可以有效地保证数据的完整性,避免出现编码的错位。即使偶然出现 “ 坏字 ” ,也不会影响到后续的文本。
那么 UTF-8 有什么缺点呢?显然,对于在 BMP 中的中文字来说,需要用 3 个字节才能表示,比使用 UTF-16 或直接使用双字节的 GB2312 编码大了 0.5 倍。
上文说了一大通,总结一下,其实很简单:
- 字符编码是抽象字符在计算机中的数字表示。
- 字符编码集( character set ,简称字符集)是一批字符编码的集合。世界上存在大量互不兼容的字符集,给国际交流带来了困难。
- ASCII 码是最古老的字符编码,它总共只定义了 7 位共 128 个字母、数字和符号。但它是其它所有字符编码的基础。
- Unicode 用 16 位整数编码,将世界上所有主要文字的字符统一起来了。如果利用代理对( surrogate pair )最多可以表示从 0 到 1FFFF 的字符。然而绝大多数情况下,只需要用到 0 到 FFFF 之间的字符就足够了。
- Unicode 常用 UTF-8 和 UTF-16 来表示。 7 位的 ASCII 码不用作任何变化,就已经是 UTF-8 了。但 UTF-8 需要用 3 个字节来表示一个汉字。
- ISO 8859 系列字符集,定义了单字节字符编码的标准。其中最特殊的是 ISO-8859-1 编码,它的编码和 Unicode 中最开始的 256 个字符编码完全相同。
- GB18030 编码是中国大陆的国家标准,在字汇上等同于 Unicode ,在编码上和 GB2312 编码以及 GBK 编码兼容。
发表评论
-
中文化和国际化问题权威解析之二:Java国际化基础
2009-08-11 20:07 720我们知道 Unicode 为国际化( I18n ... -
中文化和国际化问题权威解析之三:Java中文问题分析
2009-08-11 20:08 693本章从实际的中文问题中,分析问题的根本原因,以及解决之道。 ... -
中文化和国际化问题权威解析之五:URL编码/Misc
2009-08-11 20:09 618通过前面中文化、国际化问题解决的系列1-4,相信大家对字符集、 ... -
中文化和国际化问题权威解析之四:Java中文化和国际化攻略
2009-08-11 20:09 677一般攻略 既然在 Java 内部是直接使用 U ... -
中文化和国际化问题权威解析之七:JS中的escape、encodeURI、encodeURIComponent解惑
2009-08-11 20:10 641面一篇文档《中文化和国际化问题权威解析之五:URL编码/Mis ... -
中文化和国际化问题权威解析之六:MIME编码/字符传输编码
2009-08-11 20:10 627MIME(Multipurpose Internet Ma ... -
通过IP地址和子网掩码与运算计算相关地址
2010-03-12 14:41 509通过IP地址和子网掩码 ... -
子网掩码和IP地址计算网络地址和广播地址的换算
2010-03-12 14:50 1142子网掩码和IP地址计算 ... -
更改google桌面搜索的索引文件位置
2010-11-15 09:14 679Google Desktop Search默认的索引文件是保存 ...
相关推荐
在互联网技术的发展历程中,字符编码一直是影响多语言支持的关键因素之一。对于中文等双字节字符集(DBCS)而言,正确的编码处理尤为重要。《JSP_Servlet 中的汉字编码问题》一文针对这一主题进行了深入探讨,特别是...
总之,《MYSQL字符集与乱码问题分析》不仅回顾了字符集的发展历程,还详细解析了MySQL环境下字符集的配置与优化方法,对于预防和解决乱码问题具有重要的实践指导意义。通过对字符集的深入了解,开发者能够更好地应对...
字符编码技术的发展历程反映了信息技术与人类语言文化的融合过程。从早期的ASCII编码到今天的UNICODE和UTF-8,每一次进步都使得计算机能更好地理解和支持全球各地的语言文字。掌握字符编码的基本原理及其转换方法,...
### GB2312字符集解析与应用 #### GB2312-80简介 GB2312-80是一种广泛应用于中国大陆的汉字编码标准,由中华人民共和国...对于了解中文编码发展历程以及相关技术背景的人来说,GB2312仍然是一个值得研究的重要课题。
这些标准的发展历程反映了汉字编码技术的进步和对多种语言文字的支持。 #### 六、总结 通过对Unicode编码及相关的UCS、UTF、BMP、BOM等概念的详细介绍,我们可以更加深入地理解这些编码方式的工作原理及其在实际...
在IT行业中,正则表达式(Regular Expression)是一种强大的文本处理工具,用于匹配、查找、替换和解析字符串。在C++编程环境下,虽然标准库没有内置的正则表达式支持,但开发人员经常通过第三方库来实现这一功能。...
根据提供的信息,《编码的奥秘》这本书以一种有趣的方式介绍了计算机科学中的编码概念和技术细节,同时探讨了计算机系统的构成和发展历程。以下是对该书中部分章节所涉及知识点的详细解析: ### 第1章:电筒密谈 这...
- **Unicode编码**:一种国际字符集标准,支持世界上几乎所有语言的文字。 - **GB2312、GBK编码**:中文字符编码标准。 #### 绘图仪类型 - **知识点解析**:绘图仪是一种用于绘制图形的硬件设备,主要分为平台式...
本文将详细解析字符编码的历史发展,以及Unicode、UTF-8和GBK等编码方式的差异。 ASCII编码,全称美国信息交换标准代码,是最基础的字符编码,使用7位二进制数(一个字节的前7位)表示128个字符,包括大写和小写...
#### 发展历程:从GB2312到Unicode 汉字编码的发展经历了从GB2312到Unicode的过程,反映了信息技术进步和全球化趋势。 - **GB2312**:作为早期的汉字编码标准,虽然解决了汉字在计算机上的存储问题,但由于收录...
从早期仅能通过字符编码与计算机进行交互,到现今使用语音识别、手写输入等多种方式,中文输入法的演进历程映射着人机交互技术的变革。 一、中文输入法的技术演进 中文输入法的诞生源于人类与计算机交流的需要。...
在20多年的发展历程中,中文信息处理技术经历了多个阶段,从最初的字符编码标准化,如GB2312、GBK到Unicode,再到词典和模式匹配技术的进步,以及近年来基于深度学习的自然语言处理模型的广泛应用。这些进展极大地...
5. `re_history.txt`:这可能是库的历史版本记录或更新日志,记录了库的发展历程和改动,对于理解和跟踪库的改进有帮助。 这个支持中文的正则表达式库可能采用了Unicode编码,如UTF-8或GBK,以确保能够正确处理中文...
- **国际化和本地化**: - **字符编码**:支持更多的字符集和编码方式,如UTF-8。 - **本地化支持**:增强了日期时间、数字格式化等功能。 #### 3. Java 1.6 的安装与配置 - **安装步骤**: - 下载官方提供的...
1. Python语言基础:介绍Python的发展历程、特性、版本以及运行方式,教授如何使用Python开发环境如控制台、IDLE和IDE。 2. Python基本语法:讲解基本语法元素、输入输出、变量和对象,通过编写简单的程序进行实践。...
在那个年代,计算机硬件资源有限,如何高效地实现中文字符编码、显示和处理,是对开发者的一大挑战。袖珍龙系统通过动态中文化技术,成功地在有限的内存和存储空间内实现了对汉字的支持,这在当时是一个技术创新。 ...
- **选项配置**:ctex宏包提供了丰富的选项,包括仅适用于文档类的选项、仅适用于文档类和ctexcap.sty的选项,以及针对中文编码、字库、引擎、排版风格和宏包兼容性的选项,满足个性化需求。 - **缺省选项**:为了...