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特征字符均有的字符串。一般來說，英文字符無論怎麼轉換或處理，都不會失真(如果遇到了，可以嘗試著增加連續的英文字母長度)。
