许盖功何许人也？
许盖功这号人物，只要曾经用过php+mysql架站的人，无人不知无人不晓，且绝对是这些架站人心中永远的痛....
(摘自osCommerce购物网站架设实战)
仔细探究原因，你会发现，错的人其实不该是许盖功，而是通称大五码的BIG5码，关于大五码的历史传说众说纷纭，无一定论。我们并不评论当初编码的对错与是非，对这历史有兴趣的读者不妨到google搜寻"BIG5"，相信可以找到一堆资料，或是到图书馆翻翻下列两本书：
书名：中文字码：万码奔腾，一码当先
作者：黄大一
出版单位：永麒科技
书名：国字整理小组十年
作者：谢清俊、黄克东
出版单位：资讯应用国字整理小组
既然大五码听来似乎有些问题，为何目前几乎所有的繁体中文却又都采用此一编码呢？在西元1983-1984年间，个人电脑正在台湾逐渐推广，电脑上的套装软体也开始盛行，为了解决电脑处理中文的问题，因而制定一套中文内码，也就是我们通称的"BIG5码"，又称大五码。而经历过这段时间的人，一定不会忘记当初倚天中文的行销手法，在国外软体厂商开始引进原版软体观念的当时，倚天中文却反其道而行，允许校园甚至一般使用者无条件且免费复制其中文系统，因此，让倚天中文在当时几乎成为中文的标准，也由于倚天中文正是采用BIG5编码，严格说来，也就是BIG5码为何一直沿用到现今的主要原因了。
大五码错在哪里？
错在编码时没有把美国标准资讯交换码ASCII(American Standard Code for Information Interchange)的控制码排除在外，凡是念过计算机概论的人都知道ASCII是以byte为单位，又1 byte=8 bits，所以ASCII最多可以编2^8=256个字元，对于只有26个字母的英文语系国家来说已绰绰有余，但对于有几万字的中文绝对不够，因此必须用两个byte来代表一个中文字，如"中"字的编码即是"A4A4"。然而，BIG5码设计时为了避免与ASCII冲突，每个中文字的第一个byte仅使用ASCII里的高字元(129-255)，但在第二个byte却用到了部分低字元(1-128)，这正是BIG5码在日后应用上造成极大不便的最大帮凶了。
为何BIG5码专找php+mysql麻烦？
原因有三：
一、sql隐码问题：
我们知道，如果要在mysql资料库中撷取得资料时的语法为：
select * from administrator where id='ABC' and passwd='
假设我有一个login.php的网页，内容是用来输入id和passwd值的表单(from)，若有人直接于网址列输入：
login.php?id=ABC&passwd='%20or%201=1%20or%201='
由于%20会被浏览器解译为空白，因此最后丢到mysql的sql语法是：
select * from administrator where id='ABC' and passwd='' or 1=1 or 1=''
这是一个恒为真的式子，骗过了验证而取得administrator的权限。
因此，单引号变成了头号隐形杀手。
二：php 的跳脱字元
5C在php里面是被拿来当跳脱字元，也就是说当变数里面的文字带有 、单引号或双引号时，为了要可以正确显示这些特殊字元，通常需要多加一个 ＼，常见的例子如:
<?php
echo "<table border=＼"0＼">";
?>
如果没加，立刻会出现错误讯息：
Parse error: parse error, unexpected T_LNUMBER, expecting ',' or '' in c:appservwwwcode.php on line 2
这样，问题就来了，当我们要插入一笔资料到资料库如：
INSERT INTO mytable VALUES ('许盖功\');
由于功的第二个byte是 5C ，加上后面接的是单引号，因此经过解译之后，最后面的单引号却认定为文字，因而导致sql语法少了最后那个单引号，当然就写不进资料库而发生错误了。
三、addslashes与stripslashes函数：
为了解决单引号可能被用来当成攻击资料库的工具，一般在写php程式时会利用addslashes函数将变数里的单引号前加入一个跳脱字元，如上述原本在passwd输入：
' or 1=1 or 1='
可以骗过验证，在经过addslashes函数处理后变成：
＼' or 1=1 or 1=＼'
这样便可以避免单引号被用来当成攻击资料库的工具了。但是，如此一来，跳脱字元会被当成输入文字直接写入资料库内，因此，当我们写入资料库时若用了addslashes函数，从资料库取出该笔资料时就必须使用stripslashes将删去，否则显示出来的资料就会多一个的跳脱字元了。
BIG5不只找php麻烦，连unix都幸免于难
7C 是 ASCII 里的 pipe '|' 用过 unix 的应该知道它是作什么的，举一个简单的例子，如果你用 ftp 上传一个 "四.doc" 的档名到 unix ，传完后立刻变成 "北.doc'，我想太多人有过这种经验，原因无他，中文字 "四" 的 BIG5 码是"A57C"，当 unix 看到 7C 时会觉得莫名其妙，上传一个 "|" 给我做什么？于是就自己处理掉了...
因此，你可以想像只要是中文字第二个byte是 "7C" 的，保证也都难逃BIG5的魔掌。
许盖功的解决之道
一、去除程式里出现问题那段程式码里的stripslashes函数，如此，除了显示"许盖功\"时可能变成"许盖功\"之外，似乎没有太大的问题，但是，mysql server的隐码及跳脱字元问题还是存在的。
二、使用big5_func字串处理函数集
如果你曾经仔细研究笔者在OSC里处理许盖功的方法，你应该就会发现[webroot]/catalog/includes/languages/tchinese 目录下有一个叫big5_func的资料夹，其实就是网路上的高人为了解决BIG5的问题而写的函数集，我们称之为"big5 字串处理函数集"。
为了尊重原作者版权，特别将相关讯息摘录于后：
/*
程式 : big5 字串处理函数集
档名 : big5_func.inc
作者 : Pigo Chu<
pigo@ms5.url.com.tw>
说明 :
这些函数是以 PHP4 来处理 big5 字元
任何人都可以自由散布本程式
写这些程式是看见 LinuxFab 上讨论区上很多人有中文问题才写的
我不能保证会发生什么问题 , 若有 bug 请来信讨论不要谩骂
时间 : 2002/4/21
版本 : 0.10
版本介绍 :
0.01 版(2001/5/27) 提供的函数
string big5_addslashes(string str) : 与 PHP addslashes 一样的功能 , 可以处理中文
string big5_stripslashes(string str) : 与 stripslashes 一样
int big5_strlen(string str) : 与 strlen 功能相同
string big5_substr(string str,int start , int length) : 与 substr 一样
string big5_strtolower(string str) : 与 strtolower 一样
string big5_strtoupper(string str) : 与 strtoupper 一样
0.02 版(2001/5/28) 提供的函数
string big5_chunk_split(string $str, [int $chunklen=76] , [string $end=" "]) : 与 chunk_split 相同
0.03 版(2001/6/16) 提供的函数
string big5_strpos(string haystack ,string needle , int [offset]) : 传回第一个找到 $str 的位置
0.04 版(2001/11/12) 修改 bug
把一些定义与判断式的写错修正 , 感谢网友小蓝 ...
0.05 版(2002/2/13) 修正 big5_stripslashes()
此函数会把所有 "" 去掉的问题 , 谢谢网友Neil指正
0.06 版(2002/2/22) 新增 big5_str_replace()
此函数用法与 str_replace() 一样
0.07 版(2002/4/12) 新增 int big5_stroke($string)
此函数可计算单一中文字的笔划 , 若输入的不是中文则return false
0.08 版(2002/4/19) 新增 big5_unicode($string) , big5_utf8_encode(),big5_utf8_decode(), 修改 big5_stroke($string)
big5_unicode() 可以将中文转成多国语言给网页用的码
big5_utf8_encode() 可以将中文转成 UTF8 码
big5_utf8_decode() 可以将 UTF8 转成 BIG5 码
big5_stroke() 改成开档方式 , 这样不用到此函数时比较省记忆体
0.09 呕心版 (2002/4/20) 修正许多函数写法 , 提升效能
据测试 : big5 转 utf 与 big5 转 unicode 提升效能 0.08 版效能 10 倍以上
测试 1 万 个中文字转 utf8 大约需要 2.2 秒 , 比前一版(居然超过2分钟快上非常多)
虽然还不是挺满意 , 不过已经可以接受
另外 big5_substr , big5_strlen 改了一些写法所有快了一点点 ...
0.10 版 (2002/4/21) 提升 bi5 转 utf8 , unicode , 效能再提升加快 2 倍
据我自己的电脑测试 , 测试 1 万中文字转 utf8 已经可以低于 1 秒了 ...
big5_substr() 重写也加快了一点点速度
*/
这就是目前笔者使用于OSC处理中文字串的函数集，有兴趣的读者不妨自行参考big5_func.inc一档。事实上如果要处理许盖功等\"5C"的问题，在big5_func里只用到两个函数，也就是big5_addslashes和big5_stripslashes，而这两个函数的功能除了拥有原来addslashes跟stripslashes的功能之外，最重要的就是可以分辨出哪些是中文字，哪些才是真正的跳脱字元。举例来说：
使用php时的程式码：
echo addslashes('许盖功\');
echo stripslashes('许盖功\');
?>
结果是：
许＼盖＼功＼
顶?
使用big5_func字串函数集的程式码：
echo big5_addslashes('许盖功\');
echo big5_stripslashes('许盖功\');
?>
结果是：
许盖功
许盖功
这样的确可以解决php处理盖功等相关中文字的问题，但是，同样的当你写入mysql资料库时仍然无法解决跳脱字元的问题而出现稍早提过的错误，因为" 许盖功\"内还是含有"5C"的字元。因此，当你决定使用big5_func来处理时，就必须将mysql的charset也一并改为BIG5且不可让许盖功等字放在要插入资料字串的最后面。请参考上述php的跳脱字元一节。此时，还有一个比较严重的问题是，变更charset是必须重新编译mysql的，也就是说如果你是已经运作正常的主机，必须重新安装mysql server并加入charset=big5的参数，若如果你是租用的网页主机，那问题就会变得更为复杂，因为主机供应商通常不会特别因为你要使用big5_func的函数而重新编译他的mysql server。
因此，笔者于光碟附的繁体中文OSC版本，仅针对mysql server的charset为latin1做修正，所以，如果你的mysql server的charset设定为big5，则参考本章所提的观念，应该可以很轻松修正许盖功的问题了。
笔者于目前OSC版本的修改方式为(mysql server charset=latin1)
1.开启 [webroot]/catalog/includes/functions/database.php
找到
function tep_db_input($string) {
return addslashes($string);
}
function tep_db_prepare_input($string) {
if (is_string($string)) {
return trim(tep_sanitize_string(stripslashes($string)));
改为
function tep_db_input($string) {
return addslashes(big5_stripslashes(($string)));
}
function tep_db_prepare_input($string) {
if (is_string($string)) {
return trim(tep_sanitize_string(big5_stripslashes(big5_addslashes($string))));
2.开启[webroot]/catalog/admin/includes/functions/database.php
找到
function tep_db_input($string) {
return addslashes($string);
}
function tep_db_prepare_input($string) {
if (is_string($string)) {
return trim(stripslashes($string));
改成
function tep_db_input($string) {
return addslashes($string);
}
function tep_db_prepare_input($string) {
if (is_string($string)) {
return trim(big5_stripslashes($string));
这样就可以解决大部分因许盖功造成的问题。
OSC前台无法搜寻许盖功等产品问题
这个问题还是跳脱字元"5C"搞的鬼，当我们在前台想要搜寻跟"许盖功\"有关的商品时，所产生的sql语法会像：
select * from tablename where products_name like '%许盖功\%'
这样的sql语法放到mysql里面，因为功的第二个byte就是"5C"跳脱字元，实际却被误判成：
select * from tablename where products_name like '%许盖?＼%'
因此，就造成了，明明资料库里有许盖功相关的商品，就是怎样也搜寻不到相关的产品资料。
那么，要如何才可以修正这个错误呢？答案就是想办法让你的sql语法变成这样：
select * from tablename where products_name like '%许盖功＼＼＼%'
所以你会看到笔者的做法：
开启[webroot]/catalog/advanced_search_result.php
约在256行：
找到
default:
$keyword = tep_db_prepare_input($search_keywords[$i]);
$where_str .= "(pd.products_name like '%" . tep_db_input($keyword) . "%' or p.products_model like '%" . tep_db_input($keyword) . "%' or m.manufacturers_name like '%" . tep_db_input($keyword) . "%'";
if (isset($HTTP_GET_VARS['search_in_deion']) && ($HTTP_GET_VARS['search_in_deion'] == Ƈ')) $where_str .= " or pd.products_deion like '%" . tep_db_input($keyword) . "%'";
$where_str .= ')'
break;
改成
default:
$keyword = big5_addslashes(stripslashes(big5_addslashes(tep_db_prepare_input($search_keywords[$i]))));
$keyword1 = big5_addslashes($search_keywords[$i]); //output -> 功＼＼
$keyword = str_replace( chr(92).chr(92) ,chr(92).chr(92).chr(92),$keyword1); // 将 功＼＼ 换成 功＼＼＼
$where_str .= "(pd.products_name like '%" . $keyword . "%' or p.products_model like '%" . $keyword . "%' or m.manufacturers_name like '%" . $keyword . "%'";
if (isset($HTTP_GET_VARS['search_in_deion']) && ($HTTP_GET_VARS['search_in_deion'] == Ƈ')) $where_str .= " or pd.products_deion like '%" . $keyword . "%'";
$where_str .= ')'
break;
后记
由于BIG5所造成的问题几乎无所不在，笔者认为除非BIG5有一个完整的补救计划，否则许盖功将会一直困扰着所有架站人。在此，笔者也试图透过这样的说明，让每一位想架站却又遭受此一问题困扰的人自己找到解决的办法。最后在此也特别声明，BIG5的问题可能不只这些，也可能相当棘手，甚至超出笔者所能解决的范围，但，如果你有任何问题，也欢迎你到 网路甘仔店 社群提出，相信我们有许多热心的人可以一同来解决BIG5的问题。
