PHP程式設計中中文編碼問題曾經困擾很多人，導致這個問題的原因其實很簡單，每個國家(或地區)都規定了電腦資訊交換用的字元編碼集，如美國的擴充 ASCII 碼, 中國的 GB2312-80，日本的 JIS 等。作為該國家/地區內資訊處理的基礎，字元編碼集起著統一編碼的重要作用。字元編碼集按長度分為 SBCS(單一位元組字元集)，DBCS(雙位元組字元集)兩大類。早期的軟體(尤其是作業系統)，為瞭解決本地字元資訊的電腦處理，出現了各種語言版本(L10N)，為了區分，引進了 LANG, Codepage 等概念。但是由於各個本地字元集代碼範圍重疊，相互間資訊交換困難; 軟體各個語言版本獨立維護成本較高。因此有必要將本地化工作中的共性抽取出來，作一致處理，將特別的本地化處理內容降低到最少。這也就是所謂的國際化(118N)。各種語言資訊被進一步規範為 Locale 資訊。處理的底層字元集變成了幾乎包含了所有字形的 Unicode。
現在大部分具有國際化特徵的軟體核心字元處理都是以 Unicode 為基礎的，在軟體運行時根據當時的ocale/Lang/Codepage 設定確定相應的本地字元編碼設定，並依此處理本地字元。在處理過程中需要實現 Unicode 和本地字元集的相互轉換，甚或以 Unicode 為中間的兩個不同本地字元集的相互轉換。這種方式在網路環境下被進一步延伸，任何網路兩端的字元資訊也需要根據字元集的設定轉換成可接受的內容。 Ip.
資料庫中的字元集編碼問題
流行的關聯式資料庫系統都支援資料庫字元集編碼，也就是說在建立資料庫時可以指定它自己的字元集設定，資料庫的資料以指定的編碼形式儲存。當應用程式訪問資料時，在入口和出口處都會有字元集編碼的轉換。對於中文資料，資料庫字元編碼的設定應當保證資料的完整性。GB2312、GBK、UTF-8 等都是可選的資料庫字元集編碼; 當然我們也可以選擇 ISO8859-1 (8-bit)，只是我們得在應
用程式寫資料之前先將 16Bit 的一個漢字或 Unicode 拆分成兩個 8-bit 的字元，讀資料之後也需要將兩個位元組合并起來，同時還要判別其中的 SBCS 字元，因此我們並不推薦採用 ISO8859-1 作為資料庫字元集編碼。這樣不但沒有充分利用資料庫自身的字元集編碼支援，而且同時也增加了編程的複雜度。編程時，可以先用資料庫管理系統提供的管理功能檢查其中的中文資料是否正確。
PHP 程式在查詢資料庫之前，首先執行 mysql_query("SET NAMES xxxx"); 其中 xxxx 是你網頁的編碼(charset=xxxx)，如果網頁中 charset=utf8，則 xxxx=utf8，如果網頁中 charset=gb2312，則xxxx=gb2312，幾乎所有 WEB 程式，都有一段串連資料庫的公用代碼，放在一個檔案裡，在這檔案裡，加入 mysql_query("SET NAMES xxxx") 就可以了。
SET NAMES 顯示用戶端發送的 SQL 陳述式中使用什麼字元集。因此，SET NAMES 'utf-8' 語句告訴伺服器“將來從這個用戶端傳來的資訊採用字元集 utf-8”。它還為伺服器發送回用戶端的結果指定了字元集(例如，如果你使用一個 SELECT 語句，它表示列值使用了什麼字元集)。
定位問題時常用的技巧 :
定位中文編碼問題通常採用最笨的也是最有效辦法―在你認為有嫌疑的程式處理後列印字串的內碼。通過列印字串的內碼，你可以發現什麼時候中文字元被轉換成 Unicode，什麼時候Unicode 被轉回中文內碼，什麼時候一個中文字成了兩個 Unicode 字元，什麼時候中文字串被轉成了一串問號，什麼時候中文字串的高位被截掉了……
取用合適的樣本字串也有助於區分問題的類型。如："aa啊 aa?@aa" 等中英相間，GB、GBK特徵字元均有的字串。一般來說，英文字元無論怎麼轉換或處理，都不會失真(如果遇到了，可以嘗試著增加連續的英文字母長度)。
http://www.bkjia.com/PHPjc/364006.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/364006.htmlTechArticlePHP程式設計中中文編碼問題曾經困擾很多人，導致這個問題的原因其實很簡單，每個國家(或地區)都規定了電腦資訊交換用的字元編碼集，...
