建站
咨詢
售后
建站咨詢
新聞中心
php創(chuàng)建mysql數(shù)據(jù)庫時候如何設(shè)置字符集？
我來給你做一個綜合解釋吧。
成都創(chuàng)新互聯(lián)公司專注于堯都網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供堯都營銷型網(wǎng)站建設(shè)，堯都網(wǎng)站制作、堯都網(wǎng)頁設(shè)計、堯都網(wǎng)站官網(wǎng)定制、微信平臺小程序開發(fā)服務(wù)，打造堯都網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供堯都網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
在正常情況下。
PHP腳本 HTML 已經(jīng)瀏覽器 然后就是數(shù)據(jù)庫。
都有自己的字符集。何謂字符集。我想你如果是一個真正想熱衷于學(xué)PHP
那么你應(yīng)該花一定的時間去了解一下字符集的問題。
因為無論你以后做什么項目開發(fā)什么網(wǎng)站都是要牽涉到字符集。
就好比我做第一個項目。因為字符集搞的死去活來。
好進(jìn)入正題。怎么解決問題呢？
1.PHP的字符集。一般PHP網(wǎng)頁的是嵌套在html頁面以內(nèi)。那么如果在沒有沖突的情況下可以使用
header方面設(shè)置。比如?php header ... ?
2.HTML的字符集，一般是網(wǎng)頁的優(yōu)先字符集，這個問題是牽涉到你的網(wǎng)站是什么定位，比如：你的網(wǎng)站僅僅適合國內(nèi)的客戶。那么用gbk 或者gb2312.如果想老外也開湊湊熱鬧的話，就用utf-8.至于怎么設(shè)置這個字符集，你可以在meta這個標(biāo)記中看到。
3.數(shù)據(jù)庫的問題。mysql_query("set names gbk"); 這句話意思就是說，在操作數(shù)據(jù)庫的時候已這個字符集去讀寫。當(dāng)然這個字符集要對應(yīng)你的頁面的字符集哦。
4.瀏覽器。瀏覽器的問題是最萬惡的，因為每個瀏覽器默認(rèn)的是gb2312.當(dāng)然不同的瀏覽器是不同的。所以要想成為一名優(yōu)秀的程序員，寫出優(yōu)質(zhì)的代碼。你還得去了解每個瀏覽器的差別。當(dāng)然目前是不需要的，當(dāng)然這個問題你慢慢學(xué)習(xí)。寫代碼的過程中會慢慢了解到的。
你要做的就是將所有使用字符集確保一致性
問題就這些吧，如果有什么問題可以繼續(xù)問哦。凡是對PHP有熱情的人。我都會盡全力幫一下。哈哈。因為這個加物以類聚。還有這個內(nèi)容絕對不是復(fù)制粘貼的。
php數(shù)據(jù)庫編碼問題
所有在頁面在編碼都要統(tǒng)一，并不是在頁面加入utf-8的header就行了，我的就是遇到過這樣的，要把網(wǎng)頁重新保存為utf-8的編碼
php創(chuàng)建mysql數(shù)據(jù)表，怎么選擇UTF8字符集
一、轉(zhuǎn)碼失敗
在數(shù)據(jù)寫入到表的過程中轉(zhuǎn)碼失敗，數(shù)據(jù)庫端也沒有進(jìn)行恰當(dāng)?shù)奶幚恚瑢?dǎo)致存放在表里的數(shù)據(jù)亂碼。
針對這種情況，前幾篇文章介紹過客戶端發(fā)送請求到服務(wù)端。
其中任意一個編碼不一致，都會導(dǎo)致表里的數(shù)據(jù)存入不正確的編碼而產(chǎn)生亂碼。
比如下面簡單一條語句：
set @a = "文本字符串";
insert into t1 values(@a);
變量 @a 的字符編碼是由參數(shù) CHARACTER_SET_CLIENT 決定的，假設(shè)此時編碼為 A，也就是變量 @a 的編碼。
2. 寫入語句在發(fā)送到 MySQL 服務(wù)端之前的編碼由 CHARACTER_SET_CONNECTION 決定，假設(shè)此時編碼為 B。
3. 經(jīng)過 MySQL 一系列詞法，語法解析等處理后，寫入到表 t1，表 t1 的編碼為 C。
那這里編碼 A、編碼 B、編碼 C 如果不兼容，寫入的數(shù)據(jù)就直接亂碼。
二、客戶端亂碼
表數(shù)據(jù)正常，但是客戶端展示后出現(xiàn)亂碼。
這一類場景，指的是從 MySQL 表里拿數(shù)據(jù)出來返回到客戶端，MySQL 里的數(shù)據(jù)本身沒有問題。客戶端發(fā)送請求到 MySQL，表的編碼為 D，從 MySQL 拿到記錄結(jié)果傳輸?shù)娇蛻舳?，此時記錄編碼為 E（CHARACTER_SET_RESULTS）。
那以上編碼 E 和 D 如果不兼容，檢索出來的數(shù)據(jù)就看起來亂碼了。但是由于數(shù)據(jù)本身沒有被破壞，所以換個兼容的編碼就可以獲取正確的結(jié)果。
這一類又分為以下三個不同的小類：
1)字段編碼和表一致，客戶端是不同的編碼
比如下面例子， 表數(shù)據(jù)的編碼是 utf8mb4，而 SESSION 1 發(fā)起的連接編碼為 gbk。那由于編碼不兼容，檢索出來的數(shù)據(jù)肯定為亂碼。
2）表編碼和客戶端的編碼一致，但是記錄之間編碼存在不一致的情形
比如表編碼是 utf8mb4，應(yīng)用端編碼也是 utf8mb4，但是表里的數(shù)據(jù)可能一半編碼是 utf8mb4，另外一半是 gbk。那么此時表的數(shù)據(jù)也是正常的，不過此時采用哪種編碼都讀不到所有完整的數(shù)據(jù)。這樣數(shù)據(jù)產(chǎn)生的原因很多，比如其中一種可能性就是表編碼多次變更而且每次變更不徹底導(dǎo)致（變更不徹底，我之前的篇章里有介紹）。舉個例子，表 t3 的編碼之前是 utf8mb4，現(xiàn)在是 gbk，而且兩次編碼期間都被寫入了正常的數(shù)據(jù)。
3）每個字段的編碼不一致，導(dǎo)致亂碼和第二點一樣的場景。不同的是：非記錄間的編碼不統(tǒng)一，而是每個字段編碼不統(tǒng)一。舉個例子，表 c1 字段 a1,a2。a1 編碼 gbk，a2 編碼是 utf8mb4。那每個字段單獨讀出來數(shù)據(jù)是完整的，但是所有字段一起讀出來，數(shù)據(jù)總會有一部分亂碼。
三、LATIN1
還有一種情形就是以 LATIN1 的編碼存儲數(shù)據(jù)
估計大家都知道字符集 LATIN1，LATIN1 對所有字符都是單字節(jié)流處理，遇到不能處理的字節(jié)流，保持原樣，那么在以上兩種存入和檢索的過程中都能保證數(shù)據(jù)一致，所以 MySQL 長期以來默認(rèn)的編碼都是 LATIN1。這種情形，看起來也沒啥不對的點，數(shù)據(jù)也沒亂碼，那為什么還有選用其他的編碼呢？原因就是對字符存儲的字節(jié)數(shù)不一樣，比如 emoji 字符 "?"，如果用 utf8mb4 存儲，占用 3 個字節(jié)，那 varchar(12) 就能存放 12 個字符，但是換成 LATIN1，只能存 4 個字符。
php怎么設(shè)置編碼
header("Content-type: text/html; charset=utf-8");
另外你的編輯器編碼也要對應(yīng)哦
a. 如果欲使用gb2312編碼，那么php要輸出頭：header(“Content-Type: text/html; charset=gb2312")，靜態(tài)頁面添加meta http-equiv="Content-Type" content="text/html; charset=gb2312"，所有文件的編碼格式為ANSI，可用記事本打開，另存為選擇編碼為ANSI，覆蓋源文件。
b. 如果欲使用utf-8編碼，那么php要輸出頭 ：header(“Content-Type: text/html; charset=utf-8")，靜態(tài)頁面添加meta http-equiv="Content-Type" content="text/html; charset=utf-8"，所有文件的編碼格式為utf-8。
最近需要用到iconv函數(shù)把抓取來過的utf-8編碼的頁面轉(zhuǎn)成gb2312， 發(fā)現(xiàn)只有用iconv函數(shù)把抓取過來的數(shù)據(jù)一轉(zhuǎn)碼數(shù)據(jù)就會無緣無故的少一些。 讓我郁悶了好一會兒，去網(wǎng)上一查資料才知道這是iconv函數(shù)的一個bug。iconv在轉(zhuǎn)換字符"—"到gb2312時會出錯。解決方法很簡單，就是在 需要轉(zhuǎn)成的編碼后加 "http://IGNORE" 也就是iconv函數(shù)第二個參數(shù)后，如下：
iconv("UTF-8","GB2312//IGNORE",$data)
ignore的意思是忽略轉(zhuǎn)換時的錯誤，如果沒有ignore參數(shù)，所有該字符后面的字符串都無法被保存。
什么是PHP編碼？
PHP程序設(shè)計中中文編碼問題曾經(jīng)困擾很多人，導(dǎo)致這個問題的原因其實很簡單，每個國家(或區(qū)域)都規(guī)定了計算機信息交換用的字符編碼集，如美國的擴展ASCII碼,中國的GB2312-80，日本的JIS等。作為該國家/區(qū)域內(nèi)信息處理的基礎(chǔ)，字符編碼集起著統(tǒng)一編碼的重要作用。字符編碼集按長度分為SBCS(單字節(jié)字符集)，DBCS(雙字節(jié)字符集)兩大類。早期的軟件(尤其是操作系統(tǒng))，為了解決本地字符信息的計算機處理，出現(xiàn)了各種本地化版本(L10N)，為了區(qū)分，引進(jìn)了LANG,Codepage等概念。但是由于各個本地字符集代碼范圍重疊，相互間信息交換困難;軟件各個本地化版本獨立維護(hù)成本較高。因此有必要將本地化工作中的共性抽取出來，作一致處理，將特別的本地化處理內(nèi)容降低到最少。這也就是所謂的國際化(118N)。各種語言信息被進(jìn)一步規(guī)范為Locale信息。處理的底層字符集變成了幾乎包含了所有字形的 Unicode。
現(xiàn)在大部分具有國際化特征的軟件核心字符處理都是以Unicode為基礎(chǔ)的，在軟件運行時根據(jù)當(dāng)時的ocale/Lang /Codepage設(shè)置確定相應(yīng)的本地字符編碼設(shè)置，并依此處理本地字符。在處理過程中需要實現(xiàn)Unicode和本地字符集的相互轉(zhuǎn)換，甚或以 Unicode為中間的兩個不同本地字符集的相互轉(zhuǎn)換。這種方式在網(wǎng)絡(luò)環(huán)境下被進(jìn)一步延伸，任何網(wǎng)絡(luò)兩端的字符信息也需要根據(jù)字符集的設(shè)置轉(zhuǎn)換成可接受的內(nèi)容。
數(shù)據(jù)庫中的字符集編碼問題
流行的關(guān)系數(shù)據(jù)庫系統(tǒng)都支持?jǐn)?shù)據(jù)庫字符集編碼，也就是說在創(chuàng)建數(shù)據(jù)庫時可以指定它自己的字符集設(shè)置，數(shù)據(jù)庫的數(shù)據(jù)以指定的編碼形式存儲。當(dāng)應(yīng)用程序訪問數(shù)據(jù)時，在入口和出口處都會有字符集編碼的轉(zhuǎn)換。對于中文數(shù)據(jù)，數(shù)據(jù)庫字符編碼的設(shè)置應(yīng)當(dāng)保證數(shù)據(jù)的完整性。GB2312、GBK、UTF-8等都是可選的數(shù)據(jù)庫字符集編碼;當(dāng)然我們也可以選擇ISO8859-1(8-bit)，只是我們得在應(yīng)
用程序?qū)憯?shù)據(jù)之前先將16Bit的一個漢字或Unicode拆分成兩個8-bit的字符，讀數(shù)據(jù)之后也需要將兩個字節(jié)合并起來，同時還要判別其中的SBCS 字符，因此我們并不推薦采用ISO8859-1作為數(shù)據(jù)庫字符集編碼。這樣不但沒有充分利用數(shù)據(jù)庫自身的字符集編碼支持，而且同時也增加了編程的復(fù)雜度。編程時，可以先用數(shù)據(jù)庫管理系統(tǒng)提供的管理功能檢查其中的中文數(shù)據(jù)是否正確。
PHP程序在查詢數(shù)據(jù)庫之前，首先執(zhí)行 mysql_query("SETNAMESxxxx");其中xxxx是你網(wǎng)頁的編碼(charset=xxxx)，如果網(wǎng)頁中 charset=utf8，則xxxx=utf8，如果網(wǎng)頁中charset=gb2312，則xxxx=gb2312，幾乎所有WEB程序，都有一段連接數(shù)據(jù)庫的公共代碼，放在一個文件里，在這文件里，加入mysql_query("SETNAMESxxxx")就可以了。
SETNAMES 顯示客戶端發(fā)送的SQL語句中使用什么字符集。因此，SETNAMES'utf-8'語句告訴服務(wù)器“將來從這個客戶端傳來的信息采用字符集utf- 8”。它還為服務(wù)器發(fā)送回客戶端的結(jié)果指定了字符集(例如，如果你使用一個SELECT語句，它表示列值使用了什么字符集)。
定位問題時常用的技巧
定位中文編碼問題通常采用最笨的也是最有效的辦法―在你認(rèn)為有嫌疑的程序處理后打印字符串的內(nèi)碼。通過打印字符串的內(nèi)碼，你可以發(fā)現(xiàn)什么時候中文字符被轉(zhuǎn)換成Unicode，什么時候Unicode被轉(zhuǎn)回中文內(nèi)碼，什么時候一個中文字成了兩個Unicode字符，什么時候中文字符串被轉(zhuǎn)成了一串問號，什么時候中文字符串的高位被截掉了……
取用合適的樣本字符串也有助于區(qū)分問題的類型。如："aa啊aa?@aa"等中英相間，GB、GBK特征字符均有的字符串。一般來說，英文字符無論怎么轉(zhuǎn)換或處理，都不會失真(如果遇到了，可以嘗試著增加連續(xù)的英文字母長度)。
解決各種應(yīng)用的亂碼問題
1)使用標(biāo)簽設(shè)置頁面編碼
這個標(biāo)簽的作用是聲明客戶端的瀏覽器用什么字符集編碼顯示該頁面，xxx可以為GB2312、GBK、UTF-8(和MySQL不同，MySQL是 UTF8)等等。因此，大部分頁面可以采用這種方式來告訴瀏覽器顯示這個頁面的時候采用什么編碼，這樣才不會造成編碼錯誤而產(chǎn)生亂碼。但是有的時候我們會發(fā)現(xiàn)有了這句還是不行，不管xxx是哪一種，瀏覽器采用的始終都是一種編碼，這個情況我后面會談到。
請注意，是屬于HTML信息的，僅僅是一個聲明，僅表明服務(wù)器已經(jīng)把HTML信息傳到了瀏覽器。
2)header("content-type:text/html;charset=xxx");
這個函數(shù)header()的作用是把括號里面的信息發(fā)到http標(biāo)頭。如果括號里面的內(nèi)容為文中所說那樣，那作用和標(biāo)簽基本相同，大家對照第一個看發(fā)現(xiàn)字符都差不多的。但是不同的是如果有這段函數(shù)，瀏覽器就會永遠(yuǎn)采用你所要求的xxx編碼，絕對不會不聽話，因此這個函數(shù)是很有用的。為什么會這樣呢?那就得說說http標(biāo)頭和HTML信息的差別了：
http標(biāo)頭是服務(wù)器以http協(xié)議傳送HTML信息到瀏覽器前所送出的字串。而標(biāo)簽是屬于 HTML信息的，所以header()發(fā)送的內(nèi)容先到達(dá)瀏覽器，通俗點就是header()的優(yōu)先級高于(不知道可不可以這樣講)。假如一個php頁面既有header("content-type:text/html;charset=xxx")，又有，瀏覽器就只認(rèn)前者h(yuǎn)ttp標(biāo)頭而不認(rèn)meta了。當(dāng)然這個函數(shù)只能在php頁面內(nèi)使用。
同樣也留有一個問題，為什么前者就絕對起作用，而后者有時候就不行呢?這就是接下來要談的Apache的原因了。
3)AddDefaultCharset
Apache根目錄的conf文件夾里，有整個Apache的配置文檔httpd.conf。
用文本編輯器打開httpd.conf，第708行(不同版本可能不同)有AddDefaultCharsetxxx，xxx為編碼名稱。這行代碼的意思：設(shè)置整個服務(wù)器內(nèi)的網(wǎng)頁文件http標(biāo)頭里的字符集為你默認(rèn)的xxx字符集。有這行，就相當(dāng)于給每個文件都加了一行header("content- type:text/html;charset=xxx")。這下就明白為什么明明設(shè)置了是utf-8，可瀏覽器始終采用gb2312的原因。
如果網(wǎng)頁里有header("content-type:text/html;charset=xxx")，就把默認(rèn)的字符集改為你設(shè)置的字符集，所以這個函數(shù)永遠(yuǎn)有用。如果把AddDefaultCharsetxxx前面加個"#"，注釋掉這句，而且頁面里不含header("content- type…")，那這個時候就輪到meta標(biāo)簽起作用了。
下面列出以上的優(yōu)先順序：
..header("content-type:text/html;charset=xxx")
..AddDefaultCharsetxxx
..
如果你是web程序員，建議給你的每個頁面都加個header("content-type:text/html;charset=xxx")，這樣就可以保證它在任何服務(wù)器都能正確顯示，可移植性也比較強。
4)php.ini中的default_charset配置：
php.ini中的default_charset="gb2312"定義了php的默認(rèn)語言字符集。一般推薦注釋掉此行，讓瀏覽器根據(jù)網(wǎng)頁頭中的charset來自動選擇語言而非做一個強制性的規(guī)定，這樣就可以在同臺服務(wù)器上提供多種語言的網(wǎng)頁服務(wù)。
結(jié)束語 參考：
其實php開發(fā)中的中文編碼并沒有想像的那么復(fù)雜，雖然定位和解決問題沒有定規(guī)，各種運行環(huán)境也各不盡然，但后面的原理是一樣的。了解字符集的知識是解決字符問題的基礎(chǔ)。不過，隨著中文字符集的變化，不僅僅是php編程，中文信息處理中的問題還是會存在一段時間的。
PHP 數(shù)據(jù)庫類里面如何加入編碼？
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource
警告：mysql_fetch_array():支持的參數(shù)不是一個有效的 MySQL 結(jié)果資源。
從錯誤提示信息來看，應(yīng)該是
$this-result = mysql_query($sql, $this-conn); // 執(zhí)行查詢語句
這一句執(zhí)行的結(jié)果不正確導(dǎo)致的。
建議：
1. 查看下sql語句是不是正確。
2. 查看 數(shù)據(jù)庫編碼 與 html文件 、 html 顯示編碼三者是否一致。
名稱欄目：php新增數(shù)據(jù)編碼設(shè)計,php設(shè)置mysql編碼
文章位置：http://fisionsoft.com.cn/article/hcjehe.html
