PHP程式設計中中文編碼問題曾經困擾很多人，導致這個問題的原因其實很簡單，每個國家(或區域)都規定了計算機信息交換用的字符編碼集，如美國的擴展ASCII 碼，中國的GB2312-80，日本的JIS 等。作為該國家/區域內資訊處理的基礎，字元編碼集起著統一編碼的重要作用。字元編碼集依長度分為 SBCS(單字元組)，DBCS(雙位元組字元集)兩大類。早期的軟體(尤其是作業系統)，為了解決本地字元資訊的電腦處理，出現了各種本地化版本(L10N)，為了區分，引進了 LANG, Codepage 等概念。但由於各個本地字符集代碼範圍重疊，相互間信息交換困難; 軟體各個本地化版本獨立維護成本較高。因此有必要將在地化工作中的共通性抽取出來，並作一致處理，將特別的在地化處理內容降到最少。這也就是所謂的國際化(118N)。各種語言訊息進一步規範為 Locale 訊息。處理的底層字元集變成了幾乎包含了所有字形的 Unicode。
現在大部分具有國際化特徵的軟體核心字元處理都是以 Unicode 為基礎的，在軟體運行時根據當時的ocale/Lang/Codepage 設定確定相應的本地字元編碼設置，並依此處理本地字元。在處理過程中需要實作 Unicode 和本機字元集的相互轉換，甚或以 Unicode 為中間的兩個不同本地字元集的相互轉換。這種方式在網路環境下進一步延伸，任何網路兩端的字元資訊也需要根據字元集的設定轉換成可接受的內容。
資料庫中的字元集編碼問題
流行的關係資料庫系統都支援資料庫字元集編碼，也就是說在建立資料庫時可以指定它自己的字元集設置，資料庫的資料以指定的編碼形式儲存。當應用程式存取資料時，在入口和出口處都會有字元集編碼的轉換。對於中文數據，資料庫字元編碼的設定應保證資料的完整性。 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特徵字元均有的字串。一般來說，英文字元無論怎麼轉換或處理，都不會失真(如果遇到了，可以嘗試著增加連續的英文字母長度)。
解決各種應用的亂碼問題
1) 使用標籤設定頁面編碼
這個標籤的作用是聲明客戶端的瀏覽器用什麼字元集編碼顯示該頁面，xxx 可以為GB2312、GBKUTF-D-8(KUTFUTF-8和MySQL 不同，MySQL 是UTF8)等等。因此，大部分頁面可以採用這種方式來告訴瀏覽器顯示這個頁面的時候採用什麼編碼，這樣才不會造成編碼錯誤而產生亂碼。但有的時候我們會發現有了這句還是不行，不管 xxx 是哪一種，瀏覽器採用的始終都是一種編碼，這個情況我後面會談到。
請注意， 是屬於 HTML 資訊的，只是一個聲明，僅表示伺服器已經把 HTML 資訊傳到了瀏覽器。
2) header("content-type:text/html; charset=xxx");
這個函數 header() 的作用是把括號裡面的資訊發到 http 標頭。如果括號裡面的內容為文中所說那樣，那作用和 標籤基本上相同，大家對照第一個看發現字符都差不多的。但不同的是如果有這段函數，瀏覽器就會永遠採用你所要求的 xxx 編碼，絕對不會不聽話，因此這個函數是很有用的。為什麼會這樣呢?那就得說說 http 標頭和 HTML資訊的差別了：
http 標頭是伺服器以 http 協定傳送 HTML 資訊到瀏覽器前所送出的字串。而 標籤是屬於 HTML 資訊的，所以 header() 傳送的內容先到達瀏覽器，通俗點就是 header() 的優先權高於 (不知道可不可以這樣講)。假如一個PHP頁面既有header("content-type:text/html; charset=xxx")，又有，瀏覽器就只認前者 http 標頭而不認 meta 了。當然這個函數只能在PHP頁面內使用。
同樣也留有一個問題，為什麼前者就絕對起作用，而後者有時候就不行呢?這就是接下來要談的Apache 的原因了。
3) AddDefaultCharset
Apache 根目錄的 conf 資料夾裡，有整個 Apache 的設定檔 httpd.conf。
用文字編輯器開啟 httpd.conf，第 708 行(不同版本可能不同)有 AddDefaultCharset xxx，xxx為編碼名稱。這行程式碼的意思：設定整個伺服器內的網頁檔案 http 標頭裡的字元集為你預設的 xxx字元集。有這行，就等於是為每個檔案加了一行 header("content-type:text/html; charset=xxx")。這就明白為什麼明明 設定了是 utf-8，可瀏覽器總是採用 gb2312 的原因。
如果網頁裡有 header("content-type:text/html; charset=xxx")，就把預設的字元集改為你設定的字元集，所以這個函數永遠有用。如果把 AddDefaultCharset xxx 前面加個"#"，註解掉這句，而且頁面裡不含 header("content-type…")，那這個時候就輪到 meta 標籤起作用了。
下面列出以上的優先順序：
.. header("content-type:text/html; charset=xxx")
.. AddDefaultCharset xxx")
.. AddDefaultCharset xxx🀜給你的每個頁面都加個header("content-type:text/html; charset=xxx")，這樣可以保證它在任何伺服器都能正確顯示，可移植性也比較強。
4)PHP.ini 中的 default_charset 配置：
php.ini 中的 default_charset = "gb2312" 定義了PHP的預設語言字元集。一般建議註解掉此行，讓瀏覽器根據網頁頭中的 charset 來自動選擇語言而非做一個強制性的規定，這樣就可以在同台伺服器上提供多種語言的網頁服務。
結束語
其實PHP開發中的中文編碼並沒有想像的那麼複雜，雖然定位和解決問題沒有定規，各種運行環境也各不盡然，但後面的原理是一樣的。了解字符集的知識是解決字符問題的基礎。不過，隨著中文字元集的變化，不只是PHP編程，中文資訊處理的問題還是會存在一段時間的。
