php程序設(shè)計中中文編碼問題曾經(jīng)困擾很多人，導(dǎo)致這個問題的原因其實(shí)很簡單，每個國家(或區(qū)域)都規(guī)定了計算機(jī)信息交換用的字符編碼集，如美國的擴(kuò)展 ASCII 碼, 中國的 GB2312-80，日本的 JIS 等。作為該國家/區(qū)域內(nèi)信息處理的基礎(chǔ)，字符編碼集起著統(tǒng)一編碼的重要作用。字符編碼集按長度分為 SBCS(單字節(jié)字符集)，DBCS(雙字節(jié)字符集)兩大類。早期的軟件(尤其是操作系統(tǒng))，為了解決本地字符信息的計算機(jī)處理，出現(xiàn)了各種本地化版本(L10N)，為了區(qū)分，引進(jìn)了 LANG, Codepage 等概念。但是由于各個本地字符集代碼范圍重疊，相互間信息交換困難;軟件各個本地化版本獨(dú)立維護(hù)成本較高。因此有必要將本地化工作中的共性抽取出來，作一致處理，將特別的本地化處理內(nèi)容降低到最少。這也就是所謂的國際化(118N)。各種語言信息被進(jìn)一步規(guī)范為 Locale 信息。處理的底層字符集變成了幾乎包含了所有字形的 Unicode。

現(xiàn)在大部分具有國際化特征的軟件核心字符處理都是以 Unicode 為基礎(chǔ)的，在軟件運(yùn)行時根據(jù)當(dāng)時的ocale/Lang/Codepage 設(shè)置確定相應(yīng)的本地字符編碼設(shè)置，并依此處理本地字符。在處理過程中需要實(shí)現(xiàn) Unicode 和本地字符集的相互轉(zhuǎn)換，甚或以 Unicode 為中間的兩個不同本地字符集的相互轉(zhuǎn)換。這種方式在網(wǎng)絡(luò)環(huán)境下被進(jìn)一步延伸，任何網(wǎng)絡(luò)兩端的字符信息也需要根據(jù)字符集的設(shè)置轉(zhuǎn)換成可接受的內(nèi)容。

數(shù)據(jù)庫中的字符集編碼問題
流行的關(guān)系數(shù)據(jù)庫系統(tǒng)都支持?jǐn)?shù)據(jù)庫字符集編碼，也就是說在創(chuàng)建數(shù)據(jù)庫時可以指定它自己的字符集設(shè)置，數(shù)據(jù)庫的數(shù)據(jù)以指定的編碼形式存儲。當(dāng)應(yīng)用程序訪問數(shù)據(jù)時，在入口和出口處都會有字符集編碼的轉(zhuǎn)換。對于中文數(shù)據(jù)，數(shù)據(jù)庫字符編碼的設(shè)置應(yīng)當(dāng)保證數(shù)據(jù)的完整性。GB2312、GBK、UTF-8 等都是可選的數(shù)據(jù)庫字符集編碼;當(dāng)然我們也可以選擇 ISO8859-1 (8-bit)，只是我們得在應(yīng)

用程序?qū)憯?shù)據(jù)之前先將 16Bit 的一個漢字或 Unicode 拆分成兩個 8-bit 的字符，讀數(shù)據(jù)之后也需要將兩個字節(jié)合并起來，同時還要判別其中的 SBCS 字符，因此我們并不推薦采用 ISO8859-1 作為數(shù)據(jù)庫字符集編碼。這樣不但沒有充分利用數(shù)據(jù)庫自身的字符集編碼支持，而且同時也增加了編程的復(fù)雜度。編程時，可以先用數(shù)據(jù)庫管理系統(tǒng)提供的管理功能檢查其中的中文數(shù)據(jù)是否正確。

php 程序在查詢數(shù)據(jù)庫之前，首先執(zhí)行 mysql_query("SET NAMES xxxx"); 其中 xxxx 是你網(wǎng)頁的編碼(charset=xxxx)，如果網(wǎng)頁中 charset=utf8，則 xxxx=utf8，如果網(wǎng)頁中 charset=gb2312，則xxxx=gb2312，幾乎所有 WEB 程序，都有一段連接數(shù)據(jù)庫的公共代碼，放在一個文件里，在這文件里，加入 mysql_query("SET NAMES xxxx") 就可以了。

SET NAMES 顯示客戶端發(fā)送的 SQL 語句中使用什么字符集。因此，SET NAMES 'utf-8' 語句告訴服務(wù)器“將來從這個客戶端傳來的信息采用字符集 utf-8”。它還為服務(wù)器發(fā)送回客戶端的結(jié)果指定了字符集(例如，如果你使用一個 SELECT 語句，它表示列值使用了什么字符集)。

定位問題時常用的技巧
定位中文編碼問題通常采用最笨的也是最有效的辦法