CMS中文编码问题分析及解决方案 - XOOPS 专栏 - CSDNBlog
来源:百度文库 编辑:神马文学网 时间:2024/07/05 10:55:36
CMS中文编码问题分析及解决方案
CMS中文编码问题分析及解决方案
开题注: 有意见认为采用UTF-8编码将解决一切语言编码问题。我不同意这种意见: 其一对于中文用户,简体和繁体用户不习惯江两种编码字混排阅读;其二,目前大量网站采用GB/BIG5编码,而MB/ICONV对GB/BIG5 – UTF-8转换的支持并不理想。
CMS 的开发中必须要面对语言问题,主要是指多字节处理,包括encoding charset转换、字长计算等。一般来说,普通的多字节问题可以借助MB/ICONV等模块解决,但是对于中文来说,PHP自带的这两个模块支持不完善.XOOPS 中文版采用了xconv模块 – iconv forXOOPS。该模块使用了查找替换方法,效率低,但也是没有办法的办法。[XOOPS 可以自由选择编码方式,如果你选择UTF-8编码,以下内容权作茶资]
本文将尝试作如下分析[按现有资料是否齐备计序,不考虑逻辑和时间顺序]: big5冲码问题简介、分析及解决方案; xconv模块介绍及使用; 多字节问题介绍及处理方案.
一 BIG5冲码问题分析及解决方案
在处理big5编码时,有个著名的问题”許蓋功”—-BIG5冲码是必须要面对的,下边将摘录部分来自台湾的资料。
淺談許蓋功
許蓋功何許人也?
許蓋功這號人物,只要曾經用過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=’1234′
假設我有一個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裡面是被拿來當跳脫字元,也就是說當變數裡面的文字帶有 、單引號或雙引號時,為了要可以正確顯示這些特殊字元,通常需要多加一個 \,常見的例子如:
echo ””;
CMS中文编码问题分析及解决方案
开题注: 有意见认为采用UTF-8编码将解决一切语言编码问题。我不同意这种意见: 其一对于中文用户,简体和繁体用户不习惯江两种编码字混排阅读;其二,目前大量网站采用GB/BIG5编码,而MB/ICONV对GB/BIG5 – UTF-8转换的支持并不理想。
CMS 的开发中必须要面对语言问题,主要是指多字节处理,包括encoding charset转换、字长计算等。一般来说,普通的多字节问题可以借助MB/ICONV等模块解决,但是对于中文来说,PHP自带的这两个模块支持不完善.XOOPS 中文版采用了xconv模块 – iconv forXOOPS。该模块使用了查找替换方法,效率低,但也是没有办法的办法。[XOOPS 可以自由选择编码方式,如果你选择UTF-8编码,以下内容权作茶资]
本文将尝试作如下分析[按现有资料是否齐备计序,不考虑逻辑和时间顺序]: big5冲码问题简介、分析及解决方案; xconv模块介绍及使用; 多字节问题介绍及处理方案.
一 BIG5冲码问题分析及解决方案
在处理big5编码时,有个著名的问题”許蓋功”—-BIG5冲码是必须要面对的,下边将摘录部分来自台湾的资料。
淺談許蓋功
許蓋功何許人也?
許蓋功這號人物,只要曾經用過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=’1234′
假設我有一個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裡面是被拿來當跳脫字元,也就是說當變數裡面的文字帶有 、單引號或雙引號時,為了要可以正確顯示這些特殊字元,通常需要多加一個 \,常見的例子如:
echo ”