CN102801429B

CN102801429B - 适用于gb18030的url中文参数压缩方法

Info

Publication number: CN102801429B
Application number: CN201210291922.3A
Authority: CN
Inventors: 吴英杰; 傅仰耿; 钟思志; 林秋霞; 潘晓晓
Original assignee: Fuzhou University
Current assignee: Fuzhou University
Priority date: 2012-08-16
Filing date: 2012-08-16
Publication date: 2015-03-04
Anticipated expiration: 2032-08-16
Also published as: CN102801429A

Abstract

本发明涉及URL编码技术领域，特别是一种适用于GB18030的URL中文参数压缩方法，该方法针对URL中文参数的特点，结合Base64，设计并实现了一种改良的适用于GB18030-2000和GB18030-2005的URL中文参数压缩方法。该方法压缩效果好，适用范围广。该方法不仅减小了URL的中文参数的编码长度，在一定程度上避免了URL长度超过浏览器/服务器的限制，而且显著减少服务器不必要的流量，并缩短服务器的响应时间，提升在网络拥塞情况下用户的浏览体验。

Description

适用于GB18030的URL中文参数压缩方法

技术领域

本发明涉及URL编码技术领域，特别是一种适用于GB18030的URL中文参数压缩方法。

背景技术

URL参数是追加到URL 上的一个名称/值对，RFC1738、RFC3986等相关文档规定，需要对URL参数中的中文进行编码后再传送。URL编码是对不安全字符以百分号(%)用十六进制进行编码，只有US-ASCII字符集的一个子集的字符才能允许出现在URL中。

Web编程语言如JavaScript、PHP等提供了URL编码函数如escape、encodeURI、urlencode等，但这些函数对URL的中文参数编码后长度过长。浏览器和服务器对URL的长度有一定的限制，过长的URL不仅可能导致服务器产生拒绝请求服务的错误，在海量用户环境下还会影响请求的提交和服务器响应。

发明内容

本发明的目的在于提供一种适用于GB18030的URL中文参数压缩方法，该方法压缩效果好，有利于减小URL的中文参数的编码长度。

本发明采用的技术方案是：一种适用于GB18030的URL中文参数压缩方法，当Web页面采用GB18030-2000或GB18030-2005编码时，对于映射到Unicode的编码值在U+4E00-U+9FA5范围中的CJK统一字符以及编码值在U+3400-U+4DB5范围中的CJK扩展A字符，按如下步骤进行中文编码：

步骤1.1：将16位的二进制Unicode值左移两位成18位，然后表示成长度分别为6位、6位、6位的三块；

步骤1.2：当第二块的二进制值为111110或111111时，将第二块前五位的任意一位与第三块的末位交换；

步骤1.3：将经过步骤1.1、1.2处理的汉字二进制编码进行Base64编码，实现URL中文参数的压缩；

对于映射到Unicode的编码值在U+ F92C-U+ FA29范围中的CJK兼容字符，按如下步骤进行中文编码：

步骤2.1：将16位的汉字Unicode值左移两位成18位，然后表示成长度分别为6位、6位、6位的三块；

步骤2.2：将第一块的最后两位交换；

步骤2.3：将经过步骤2.1、2.2处理的汉字二进制编码进行Base64编码，实现URL中文参数的压缩；

对于映射到Unicode的编码值在U+20000-U+2A6D6范围中的CJK扩展B字符，按如下步骤进行中文编码：

步骤3.1：将20位的汉字Unicode值的最高两位忽略，然后表示成长度分别为6位、6位、6位的三块；

步骤3.2：定义当一个块的二进制值为111110或111111时就称该块特殊，并在二进制值为101000-111100范围中任取三个值X、Y、Z，分别用以表示第二块特殊、第三块特殊、第二块和第三块均特殊；

当第二块和第三块均不特殊时，将第一块的最高位置为0；

当第二块或第三块特殊时，将特殊块的后两位与二进制10作异或运算，并将第一块的后四位存储在特殊块的前四位，然后将对应的X或Y值填入第一块；

当第二块和第三块均特殊时，将两个特殊块的后两位分别与二进制10作异或运算，并将第一块的后四位存储在其中一个特殊块的前四位，然后将对应的Z值填入第一块；

步骤3.3：将经过步骤3.1、3.2处理的汉字二进制编码进行Base64编码，实现URL中文参数的压缩。

本发明的有益效果是针对URL中文参数的特点，结合Base64设计并实现了一种改良的适用于GB18030-2000和GB18030-2005的URL中文参数压缩方法。该方法压缩效果好，适用范围广。该方法不仅一定程度上避免了URL长度超过浏览器/服务器的限制，而且显著减少服务器不必要的流量，并缩短服务器的响应时间，提升在网络拥塞情况下用户的浏览体验。

附图说明

图1是本发明方法的工作流程图。

图2是Base64方法的编码过程图。

图3是本发明方法对CJK统一字符或CJK扩展A字符编码时，在Unicode值的第二块出现62或63时的编码过程图。

图4是CP936中映射到Unicode的编码值不在U+4E00~U+9FA5范围中的21个CJK兼容字符列表。

图5是本发明方法对CJK兼容字符编码时，在Unicode值的第一块出现62时的编码过程图。

图6是本发明方法对第一块的二进制值的分配表。

图7是本发明方法对CJK扩展B字符编码时，在第二块特殊时的编码过程图。

图8是本发明方法对CJK扩展B字符编码时，在第三块特殊时的编码过程图。

图9是本发明方法对CJK扩展B字符编码时，在第二块和第三块均特殊时的编码过程图。

具体实施方式

本发明适用于GB18030的URL中文参数压缩方法，当Web页面采用GB18030-2000或GB18030-2005编码时，对于映射到Unicode的编码值在U+4E00-U+9FA5范围中的CJK统一字符以及编码值在U+3400-U+4DB5范围中的CJK扩展A字符，按如下步骤进行中文编码：

步骤2.2：将第一块的最后两位交换；

步骤3.2：定义当一个块的二进制值为111110或111111时就称该块特殊，并在二进制值为101000-111100范围中任取三个值X、Y、Z，分别用以表示第二块特殊、第三块特殊、第二块和第三块均特殊；在本实施例中，分别用二进制值111000、110100、111100表示第二款特殊、第三块特殊、第二块和第三块均特殊；

当第二块和第三块均不特殊时，将第一块的最高位置为0；

当第二块特殊时，将第二块的后两位与二进制10作异或运算，并将第一块的后四位存储在第二块的前四位，然后将对应的二进制值111000填入第一块；

当第三块特殊时，将第三块的后两位与二进制10作异或运算，并将第一块的后四位存储在第三块的前四位，然后将对应的二进制值110100填入第一块；

当第二块和第三块均特殊时，将两个特殊块的后两位分别与二进制10作异或运算，并将第一块的后四位存储在其中一个特殊块的前四位，然后将对应的二进制值111100填入第一块；

下面结合具体实施例对本发明作进一步的详细说明。

1、方法基本思想-Base64方法

Base64是网络上最常见的用于传输8Bit字节代码的编码方式之一，其使用字符A-Z、a-z、0-9和两个特殊字符组成64个字符。MIME邮件中，最后两个字符分别为加号“+”和除号“/”，并用等号“=”来做后缀填补。Base64将每三个8bit的字节转换成四个6bit的字节，然后将6bit字节扩充到8bit查表，编码后的数据长度是原来的4/3。如“FZU”的编码过程如图2所示。

2、本发明对GBK字符集编码的改良

由于本发明方法的实现包括了对GBK的改良，因此，这里首先阐述针对GBK的改良方法。

一个GBK中文汉字经Base64编码之后需要用4个ASCII码字符来表示，虽然经过Base64编码后的URL参数和百分号编码相比短一些，但效果还不够明显。同时，标准的URL编码器会把+、/编码为%xx形式，这样不仅增加额外的长度，而且这些“%”号在存入数据库时还需要进行转换，因为ANSI SQL中已将“%”号用作通配符。

Base64编码表共有64个字符，除去+、/共有62个字符。由中文字符集的分析可知，GBK中共收录汉字21003个。若采用Base64编码表前62个字符，那么三个编码字符可以表示238328种字符，即理论上用三个字符即可表示GBK收录的所有汉字。本发明通过对Base64改良，使其用三个字符来表示一个汉字并不使用编码值为62和63的字符+、/。

十进制62、63的二进制表示分别为111110和111111。若一个六位二进制的前5位均为1，那么十进制值为62或63，反之肯定不为62或63。Unicode 1.0中CJK统一文字（CJK Unified Ideographs）的编码范围是U+4E00~U+9FA5。把汉字Unicode值的二进制表示划分成长度为6、6、4三块，易知只有第二块6位二进制值可能为62或63。在对中文进行编码时，先对Unicode值左移（<<）两位，那么Unicode值的二进制表示可分成长度为6、6、6三块。为了保证每块均不出现62（111110）或者63（111111），当第二块值为62或63时，将第二块前五位的任意一位和第三块末位交换，在这里将第二块第三位和第三块末位交换。如中文“篷”Unicode编码十六进制表示为0x7BF7，那么可经如图3所示方法转换。

再经过如图2所示的Base64编码，“篷”最终被编码为“e3d”。本发明对Base64的改良可用PHP实现如下：

if (($unicodeValue & 0x00F80) == 0x00F80) {

$unicodeValue = ($unicodeValue & 0xFFDFF) | 0x00001;

}

$encodeStr = Base64Encode($unicodeValue);

解码是编码的逆过程，不再赘述。

综上所述，中文经过本发明方法编码，得到的编码结果仅包含数字[0-9]、字母[A-Z]、[a-z]的字符串，长度是MIME中Base64编码后长度的3/4。

分析中文编码GB2312易知，GB2312收录的所有汉字的Unicode值范围是U+4E00~U+9FA0，即在Unicode 1.0的CJK统一字符范围之内。即当Web页面编码设置为GB2312时，本发明方法能适用于URL中文参数的压缩。

分析BIG5字符编码易知，BIG5微软衍生的版本CP950中除了“兀”（U+FA0C）外，其它收录汉字的Unicode也在U+4E00~U+9FA5范围中，即本发明方法适用于绝大多数的CP950中的繁体汉字。

GBK共收录21003个汉字，不仅兼容GB2312，还收录了CP950中的全部汉字。在微软的CP936中，共有21个CJK兼容汉字映射到Unicode的编码值不在U+4E00-U+9FA5范围中，其中包括CP950（BIG5）收录的“兀”（U+FA0C）。这21个CJK兼容汉字如图4所示。

分析这21个汉字Unicode编码可知，当将其分成6、6、4三块时，第一块都是62（111110），而后面两块均不出现62或63。因此，将第一块的最后两位交换，即由62(111110)转化为61(111101)。如“兀”（U+FA0C）的改良如图5所示。

综上所述，在对GBK收录的汉字进行编码时，若它的Unicode值的第二块出现62或者63时，即对于CJK统一字符，用图3所示的方法对它的Unicode编码进行处理。若第一块出现62时，即对于CJK兼容字符，用图5所示的方法对它的Unicode编码进行处理，具体用PHP实现如下：

if (($ch2 & 3) == 3 && $ch3 >= 14) {

$encodeIndex2 = ($encodeIndex2 & 0x37); // 11011x

$encodeIndex3 = ($encodeIndex3 | 0x1); // xxxx01

} else if ($ch1 == 0xf && $ch2 >= 0x8) {

$encodeIndex1 = $encodeIndex1 ^0x3;

}

3、本发明对GB18030字符集编码的改良

GB18030-2000相对于GBK新增的汉字，即CJK扩展A字符的Unicode范围是U+3400-U+4DB5，易知这些新增汉字可用上述改良方法进行编码，即上述针对GBK字符集的Base64改良方法同样适用于GB18030-2000。GB18030-2005相对于GB18030-2000新增汉字的Unicode范围是U+20000-U+2A6D6。

这些新增汉字的UTF-8编码占用4个字节，Unicode编码十六进制为5个字符，其二进制最高四位固定为0010。由于最高两位固定为00，依据上面对GBK字符集编码改良的思想，在编码时忽略其二进制的最高两位，解码时再还原回来。这样就可以将这些字符的二进制表示划分成6bit、6bit、6bit的三块，易知第二块和第三块的值可能为62或者63。

由上可知，划分后第二块第三块的值是否为62或者63共四种状态，需要用两位来表示，这里约定某块十进制值为62或者63时就称这块特殊。截取后的十八位二进制最高两位固定为10，若用这两位来表示这四种状态，则会在解码时候发生冲突。如用00表示后两块均不特殊，用01表示第三块特殊，用10表示第二块特殊，用11表示两块均特殊，那么当第二块特殊时，那么这个二进制前缀（第一块）范围是100000-101010，它和CJK统一汉字（U+4E00-U+9FA5）扩展到18位二进制前缀（第一块）范围010011-100111有重合。当前缀位于在他们重合的区间时，我们在解码时无法判断它是CJK统一字符还是CJK统一字符扩展B。同理，第三块特殊即最高两位为01时也会发生冲突，因此需要对上面GBK改良做进一步延伸。

出现上面问题的主要原因是第一块无法在不丢失信息的情况下表示这四种状态。三个Base64编码表中的字符共可表示238328种字符，远远大于GB18030-2005收录的汉字，即理论上可以找到一种编码方法，用三个字符表示GB18030-2005中的所有汉字而不会发生冲突。

若某块特殊，那么它的二进制前5为均为1，我们可以充分利用这块来存储第一块的信息，让第一块腾出足够多的空闲位来表示这四种状态。结合前面已经占用的空间，对第一块的具体分配如图6所示。

由图6可知，这样分配之后他们前缀不会发生冲突，即他们在解码的过程中可以顺利判断属于哪一类汉字。当某块特殊时，所剩的工作就是利用这个特殊块来存储第一块后四位信息，然后用第一块来表示这种状态。如第二块特殊时，将第二块前4为存储第一块后四位信息，具体如图7所示。

同理第三块特殊时，将第三块前四位存储第一块后四位的信息，具体如图8所示。

当第二块和第三块均特殊时，可以将第一块信息存储在第二块或者第三块，这里我们将它存储在第二块，具体如图9所示。

用ch1-ch5表示CJK统一扩展B汉字Unicode编码的5位十六进制，index1-index3表示所要获取的索引值，那么用PHP实现上述改良如下：

if ($index2 < 62 && $index2 < 62) $index1 = $ch2;

else if ($index2 < 62) {

$index3 = ($ch2 << 2) | (($ch5 & 0x3) ^0x2);

$index1 = 0xd << 2;

} else if ($index3 < 62) {

$index2 = ($ch2 << 2) | (($ch4 >> 2) ^0x2);

$index1 = 0xe << 2;

} else {

$index2 = ($ch2 << 2) | (($ch4 >> 2) ^0x2);

$index3 = $index3 ^0x2;

$index1 = 0xf << 2;

}

在解码的过程中根据第一块来获取哪块特殊，再还原第一块和特殊块的信息。上面的改良适用于CJK统一汉字扩展B收录的所有汉字，编码之后长度变为3个字符，在解码时不会发生冲突，结合对GBK的改良，能顺利处理GB18030-2005的所有汉字。

以上是本发明的较佳实施例，凡依本发明技术方案所作的改变，所产生的功能作用未超出本发明技术方案的范围时，均属于本发明的保护范围。

Claims

1.一种适用于GB18030的URL中文参数压缩方法，其特征在于：当Web页面采用GB18030-2000或GB18030-2005编码时，对于映射到Unicode的编码值在U+4E00~U+9FA5范围中的CJK统一字符以及编码值在U+3400~U+4DB5范围中的CJK扩展A字符，按如下步骤进行中文编码：

步骤1.1：将上述字符的16位的二进制Unicode值左移两位成18位，然后表示成长度分别为6位、6位、6位的三块；

对于映射到Unicode的编码值在U+F92C~U+FA29范围中的CJK兼容字符，按如下步骤进行中文编码：

步骤2.2：将第一块的最后两位交换；

对于映射到Unicode的编码值在U+20000~U+2A6D6范围中的CJK扩展B字符，按如下步骤进行中文编码：

步骤3.2：定义当一个块的二进制值为111110或111111时就称该块特殊，并在二进制值为101000~111100范围中任取三个值X、Y、Z，分别用以表示第二块特殊、第三块特殊、第二块和第三块均特殊；

当第二块和第三块均不特殊时，将第一块的最高位置为0；

2.根据权利要求1所述的适用于GB18030的URL中文参数压缩方法，其特征在于：在步骤3.2中，分别用二进制值111000、110100、111100表示第二块特殊、第三块特殊、第二块和第三块均特殊。