精 字符,字节和编码 下
本资料由豆丁若莲文档搜集
更多文档请点击
(精)字符,字节和编码(下)2010-06-03 20:392.字符与编码在程序中的实现
2.1程序中的字符与字节
在C++和Java中,用来代表"字符"和"字节"的数据类型,以及进行编码的
:
类型或操作C++Java
字符wchar_tchar
字节charbyte ANSI字符串charbyte UNICODE字符串wchar_tString
字节串?字符串mbstowcs(),MultiByteToWideChar()string=new
String(bytes,"encoding")
字符串?字节串
wcstombs(),WideCharToMultiByte()bytes=string.getBytes("encoding")
以上需要注意几点:
Java中的char代表一个"UNICODE字符(宽字节字符)",而C++中的char代表一个字节。MultiByteToWideChar()和WideCharToMultiByte()是Windows API函数。
2.2 C++中相关实现方法
声明一段字符串常量:
//ANSI字符串,内容长度7字节char sz[20]="中文123";//UNICODE字符串,内容长度5个wchar_t(10字节)wchar_t
wsz[20]=L"\x4E2D\x6587\x0031\x0032\x0033";
UNICODE字符串的I/O操作,字符与字节的转换操作:
//运行时设定当前ANSI编码,VC格式setlocale(LC_ALL,".936");//GCC中格式setlocale(LC_ALL,"zh_CN.GBK");//Visual C++中使用小写%s,按照setlocale指定编码输出到文件//GCC中使用大写%S
fwprintf(fp,L"%s\n",wsz);//把UNICODE字符串按照setlocale指定的编码转换成字节wcstombs(sz,wsz,20);//把字节串按照setlocale指定的编码转换成UNICODE字符串mbstowcs(wsz,sz,20);
UNICODE字符串常量有更简单的表示方法。如果源程序在Visual C++中,
的编码与当前默认ANSI编码不符,则需要使用#pragma setlocale,告诉编译器源程序使用的编码:
//如果源程序的编码与当前默认ANSI编码不一致,//则需要此行,编译时用来指明当前源程序使用的编码#pragma setlocale(".936")//UNICODE字符串常量,内容长度10字节wchar_t wsz[20]=L"中文123";
以上需要注意#pragma setlocale与setlocale(LC_ALL,"")的作用是不同的,#pragma setlocale在编译时起作用,setlocale()在运行时起作用。
2.3 Java中相关实现方法
字符串类String中的内容是UNICODE字符串:
//Java代码,直接写中文Stringstring="中文123";//得到长度为5,因为是5个字符System.out.println(string.length());
字符串I/O操作,字符与字节转换操作。在Java包java.io.*中,以"Stream"结尾的类一般是用来操作"字节串"的类,以"Reader","Writer"结尾的类一般是用来操作"字符串"的类。
//字符串与字节串间相互转化//按照GB2312得到字节(得到多字节字符串)byte bytes=string.getBytes("GB2312");//从字节按照GB2312得到UNICODE字符串string=new String(bytes,"GB2312");//要将String按照某种编码写入文本文件,有两种方法://第一种办法:用Stream类写入已经按照指定编码转化好的字节串OutputStream os=new FileOutputStream("1.txt");os.write(bytes);os.close();//第二种办法:构造指定编码的Writer来写入字符串Writer ow=new OutputStreamWriter(new FileOutputStream("2.txt"),"GB2312");ow.write(string);ow.close();/*最后得到的1.txt和2.txt都是7个字节*/
如果java的源程序编码与当前默认ANSI编码不符,则在编译的时候,需要指明一下源程序的编码。比如:
E:\javac-encoding BIG5 Hello.java
以上需要注意区分源程序的编码与I/O操作的编码,前者是在编译时起作用,后者是在运行时起作用。
3.几种误解,以及乱码产生的原因和解决办法
3.1容易产生的误解
对编码的误解
误解一在将"字节串"转化成"UNICODE字符串"时,比如在读取文本文件时,或者通过网络传输文本时,容易将"字节串"简单地作为单字节字符串,采用每"一个字节"就是"一个字符"的方法进行转化。而实际上,在非英文的环境中,应该将"字节串"作为ANSI字符串,采用适当的编码来得到UNICODE字符串,有可能"多个字节"才能得到"一个字符"。通常,一直在英文环境下做开发的程序员们,容易有这种误解。
误解二在DOS,Windows 98等非UNICODE环境下,字符串都是以ANSI编码的字节形式存在的。这种以字节形式存在的字符串,必须知道是哪种编码才能被正确地使用。这使我们形成了一个惯性思维:"字符串的编码"。当UNICODE被支持后,Java中的String是以字符的"序号"来存储的,不是以"某种编码的
字节"来存储的,因此已经不存在"字符串的编码"这个概念了。只有在"字符串"与"字节串"转化时,或者,将一个"字节串"当成一个ANSI字符串时,才有编码的概念。不少的人都有这个误解。
第一种误解,往往是导致乱码产生的原因。第二种误解,往往导致本来容易纠正的乱码问题变得更复杂。
在这里,我们可以看到,其中所讲的"误解一",即采用每"一个字节"就是"
的转化方法,实际上也就等同于采用iso-8859-1进行转化。因此,一个字符"
我们常常使用bytes=string.getBytes("iso-8859-1")来进行逆向操作,得到原始的"字节串"。然后再使用正确的ANSI编码,比如string=new String(bytes,"GB2312"),来得到正确的"UNICODE字符串"。
3.2非UNICODE程序在不同语言环境间移植时的乱码
非UNICODE程序中的字符串,都是以某种ANSI编码形式存在的。如果程序运行时的语言环境与开发时的语言环境不同,将会导致ANSI字符串的显示失败。
比如,在日文环境下开发的非UNICODE的日文程序界面,拿到中文环境下运行时,界面上将显示乱码。如果这个日文程序界面改为采用UNICODE来
字符串,那么当在中文环境下运行时,界面上将可以显示正常的日文。
由于客观原因,有时候我们必须在中文操作系统下运行非UNICODE的日文软件,这时我们可以采用一些工具,比如,南极星,AppLocale等,暂时的模拟不同的语言环境。
3.3网页提交字符串
当页面中的表单提交字符串时,首先把字符串按照当前页面的编码,转化成字节串。然后再将每个字节转化成"%XX"的格式提交到Web服务器。比如,一个编码为GB2312的页面,提交"中"这个字符串时,提交给服务器的内容为"%D6%D0"。
在服务器端,Web服务器把收到的"%D6%D0"转化成[0xD6,0xD0]两个字节,然后再根据GB2312编码规则得到"中"字。
在Tomcat服务器中,request.getParameter()得到乱码时,常常是因为前面提到的"误解一"造成的。默认情况下,当提交"%D6%D0"给Tomcat服务器时,request.getParameter()将返回[0x00D6,0x00D0]两个UNICODE字符,而不是返回一个"中"字符。因此,我们需要使用bytes=string.getBytes("iso-8859-1")
得到原始的字节串,再用string=new String(bytes,"GB2312")重新得到正确的字符串"中"。
3.4从数据库读取字符串
通过数据库客户端(比如ODBC或JDBC)从数据库服务器中读取字符串时,客户端需要从服务器获知所使用的ANSI编码。当数据库服务器发送字节流给客户端时,客户端负责将字节流按照正确的编码转化成UNICODE字符串。
如果从数据库读取字符串时得到乱码,而数据库中存放的数据又是正确的,那么往往还是因为前面提到的"误解一"造成的。解决的办法还是通过
8859-1"),"GB2312")的方法,重新string=new String(string.getBytes("iso-得到原始的字节串,再重新使用正确的编码转化成字符串。
3.5电子邮件中的字符串
当一段Text或者HTML通过电子邮件传送时,发送的内容首先通过一种指定的字符编码转化成"字节串",然后再把"字节串"通过一种指定的传输编码(Content-Transfer-Encoding)进行转化得到另一串"字节串"。比如,打开一封电子邮件源代码,可以看到类似的内容:
Content-Type:text/plain;charset="gb2312"Content-Transfer-
Encoding:base64
sbG+qcrQuqO17cf4yee74bGjz9W7+b3wudzA7dbQ0MQNCg0KvPKzxqO6uqO17cnnsaPW0
NDEDQoNCg==
最常用的Content-Transfer-Encoding有Base64和Quoted-Printable两种。在对二进制文件或者中文文本进行转化时,Base64得到的"字节串"比Quoted-Printable更短。在对英文文本进行转化时,Quoted-Printable得到的"字节串"比Base64更短。
邮件的标题,用了一种更简短的格式来标注"字符编码"和"传输编码"。比如,标题内容为"中",则在邮件源代码中表示为:
//正确的标题格式Subject:=?GB2312?B?1tA=?=
其中,
第一个"=?"与"?"中间的部分指定了字符编码,在这个例子中指定的是GB2312。"?"与"?"中间的"B"代表Base64。如果是"Q"则代表Quoted-Printable。最后"?"与"?="之间的部分,就是经过GB2312转化成字节串,再经过Base64转化后的标题内容。如果"传输编码"改为Quoted-Printable,同样,如果标题内容为"中":
//正确的标题格式Subject:=?GB2312?Q?=D6=D0?=
如果阅读邮件时出现乱码,一般是因为"字符编码"或"传输编码"指定有误,或者是没有指定。比如,有的发邮件组件在发送邮件时,标题"中":
//错误的标题格式Subject:=?ISO-8859-1?Q?=D6=D0?=
这样的表示,实际上是明确指明了标题为[0x00D6,0x00D0],即"",而不是"中"。
4.几种错误理解的纠正
误解:"ISO-8859-1是国际编码?"
非也。iso-8859-1只是单字节字符集中最简单的一种,也就是"字节编号"与"UNICODE字符编号"一致的那种编码规则。当我们要把一个"字节串"转化成"字符串",而又不知道它是哪一种ANSI编码时,先暂时地把"每一个字节"作为"一个字符"进行转化,不会造成信息丢失。然后再使用
bytes=string.getBytes("iso-8859-1")的方法可恢复到原始的字节串。
误解:"Java中,怎样知道某个字符串的内码?"
Java中,字符串类java.lang.String处理的是UNICODE字符串,不是ANSI字符串。我们只需要把字符串作为"抽象的符号的串"来看待。因此不存在字符串的内码的问题。
特别声明:
1:资料来源于互联网,版权归属原作者
2:资料内容属于网络意见,与本账号立场无关
3:如有侵权,请告知,立即删除。
本资料由豆丁若莲文档搜集
更多文档请点击