本文目錄一覽:
php搜索時的編碼問題,謝謝
應該不是有關utf8的問題,傳過來的內容被改成類似於%20這樣的東西了吧,用urldecode($_GET[‘key’])解碼。
PHP中文編碼問題?
如果說Editplus 快,所以用它的話,不如用記事本,更快。EclipsePHP就是Eclipse加個php插件,對於開發php來說,比Editplus強多了。樓主說的不能正常的輸出中文,其實就是新手常見的編碼問題,與用什麼編輯器無關的。如果頁面是utf8,你的php文檔用的是gbk,那麼輸出的中文就會亂碼了,Eclipse可以對文檔、項目、全局設定編碼。我用的是ZendStudio ,菜單上windows-preferences,general-workspace,找到Text file encoding,這是全局編碼設定。項目設定:右擊項目-preferences,resource,找到Text file encoding。項目里的單文件設定,跟項目的設定差不多,右擊文件。項目外的單文件,設定全局編碼後,重新打開文件就可以了。
如何解決PHP在utf-8編碼下中文顯示亂碼問題?
如果php文件已經在頭部設置編碼格式為utf-8,在運行的時候還出現亂碼問題,可能是由於文件編碼格式不匹配或者頭部有bom信息輸出導致亂碼。解決辦法:
設置保存文件編碼格式為utf-8;
去掉文件頭部bom信息;
什麼是PHP編碼?
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(“SETNAMESxxxx”);其中xxxx是你網頁的編碼(charset=xxxx),如果網頁中 charset=utf8,則xxxx=utf8,如果網頁中charset=gb2312,則xxxx=gb2312,幾乎所有WEB程序,都有一段連接數據庫的公共代碼,放在一個文件里,在這文件里,加入mysql_query(“SETNAMESxxxx”)就可以了。
SETNAMES 顯示客戶端發送的SQL語句中使用什麼字符集。因此,SETNAMES’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行(不同版本可能不同)有AddDefaultCharsetxxx,xxx為編碼名稱。這行代碼的意思:設置整個服務器內的網頁文件http標頭裡的字符集為你默認的xxx字符集。有這行,就相當於給每個文件都加了一行header(“content- type:text/html;charset=xxx”)。這下就明白為什麼明明設置了是utf-8,可瀏覽器始終採用gb2312的原因。
如果網頁里有header(“content-type:text/html;charset=xxx”),就把默認的字符集改為你設置的字符集,所以這個函數永遠有用。如果把AddDefaultCharsetxxx前面加個”#”,注釋掉這句,而且頁面里不含header(“content- type…”),那這個時候就輪到meta標籤起作用了。
下面列出以上的優先順序:
..header(“content-type:text/html;charset=xxx”)
..AddDefaultCharsetxxx
..
如果你是web程序員,建議給你的每個頁面都加個header(“content-type:text/html;charset=xxx”),這樣就可以保證它在任何服務器都能正確顯示,可移植性也比較強。
4)php.ini中的default_charset配置:
php.ini中的default_charset=”gb2312″定義了php的默認語言字符集。一般推薦注釋掉此行,讓瀏覽器根據網頁頭中的charset來自動選擇語言而非做一個強制性的規定,這樣就可以在同台服務器上提供多種語言的網頁服務。
結束語 參考:
其實php開發中的中文編碼並沒有想像的那麼複雜,雖然定位和解決問題沒有定規,各種運行環境也各不盡然,但後面的原理是一樣的。了解字符集的知識是解決字符問題的基礎。不過,隨着中文字符集的變化,不僅僅是php編程,中文信息處理中的問題還是會存在一段時間的。
php編碼的問題。
原因只有一個。你的網頁編碼和服務器輸出編碼不同。。
解決方案比較簡單。。你當前網頁使用什麼編碼。。就在 php 最開頭的地方加一行 header 改變 服務器的輸出編碼即可。。
header(‘Content-Type: text/html; charset=UTF-8’);
原創文章,作者:OYTC,如若轉載,請註明出處:https://www.506064.com/zh-hant/n/148717.html