[開發故事]4項技巧使你不再為PHP中文編碼苦惱

發表於2019-05-11
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、GBK、UTF-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
  ..
  如果你是 web 程式設計師,建議給你的每個頁面都加個header("content-type:text/html; charset=xxx"),這樣就可以保證它在任何伺服器都能正確顯示,可移植性也比較強。
  4)PHP.ini 中的 default_charset 配置:
  php.ini 中的 default_charset = "gb2312" 定義了PHP的預設語言字符集。一般推薦註釋掉此行,讓瀏覽器根據網頁頭中的 charset 來自動選擇語言而非做一個強制性的規定,這樣就可以在同臺伺服器上提供多種語言的網頁服務。
  結束語
  其實PHP開發中的中文編碼並沒有想像的那麼複雜,雖然定位和解決問題沒有定規,各種執行環境也各不盡然,但後面的原理是一樣的。瞭解字符集的知識是解決字元問題的基礎。不過,隨著中文字符集的變化,不僅僅是PHP程式設計,中文資訊處理中的問題還是會存在一段時間的。
回覆

相關文章