php字元集
㈠ php 輸出簡單的中文 亂碼問題
解決php中中文亂碼問題方法
php文件本身的編碼與網頁的編碼應匹配
a. 如果欲使用gb2312編碼，那麼php要輸出頭：header(「Content-Type: text/html; charset=gb2312")，靜態頁面添加<metahttp-equiv="Content-Type" content="text/html; charset=gb2312">，所有文件的編碼格式為ANSI，可用記事本打開，另存為選擇編碼為ANSI，覆蓋源文件。
b. 如果欲使用utf-8編碼，那麼php要輸出頭：header(「Content-Type: text/html; charset=utf-8")，靜態頁面添加<metahttp-equiv="Content-Type" content="text/html; charset=utf-8">，所有文件的編碼格式為utf-8。保存為utf-8可能會有點麻煩，一般utf-8文件開頭會有BOM，如果使用session就會出問題，可用editplus來保存，在editplus中，工具->參數選擇->文件->UTF-8簽名，選擇總是刪除，再保存就可以去掉BOM信息了。php本身不是Unicode的，所有substr之類的函數得改成mb_substr（需要裝mbstring擴展）；或者用iconv轉碼。
如果你的HTML文件文件出現了亂碼問題，那麼你可以在head標簽裡面加入UTF8編碼(國際化編碼)：UTF-8是沒有國家的編碼，也就是獨立於任何一種語言，任何語言都可以使用的。
(1)php字元集擴展閱讀：
解決PHP 輸出簡單的中文 亂碼問題的其他方法：
在php的echo前面加入header("Content-Type:text/html;charset=gb2312")
把<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />中的UTF-8改成gb2312
㈡ PHP的字元編碼17符號代替問題，怎麼解決
近日，公司的論壇管理員發了一個帖子鏈接給我，說標題修改以後和實際的顯示不一樣。我打開之後發現，原始標題為：「手賤洗包漿，洗洗更健康」，但在title顯示成了 「手賤洗包漿，洗洗更降」。
於是乎，在本地測試環境下進行了編輯測試未發現異常，伺服器上對其它帖子也進行了編輯保存也為發現問題。
看來需要跟蹤一下源代碼了，發現上面的標題在執行了一下代碼之後發生了變化：
1 $thread['subject'] = str_replace("【",'',$thread['subject']);
2 $thread['subject'] = str_replace("】",'',$thread['subject']);
至此，可以肯定問題出在了這里，然而到底是什麼問題導致的呢，初步考慮是
1，伺服器環境有問題
2，編碼處理不一致
經過多個伺服器環境測試後，發現問題依舊，可以排除伺服器因素
。
之後測試編碼處理，先將要替換的字元和查詢的字元串轉成UTF-8編碼，之後進行替換測試發現問題不存在了。
於是修正上面的代碼為：
1 $rep1 = iconv('GBK', 'UTF-8', "【");
2 $rep2 = iconv('GBK', 'UTF-8', "】");
3 $thread['subject'] = iconv('GBK', 'UTF-8', $thread['subject']);
4 $thread['subject'] = str_replace(array($rep1, $rep2),array('',''), $thread['subject']);
5 $thread['subject'] = iconv('UTF-8', 'GBK', $thread['subject']);
解決問題。
終極問題分析：
由於計算機是基於二進制代碼運行的，因此php在執行替換的時候也是將非ASCII字元轉成了ASCII編碼之後進行查找替換，使用十六進制工具查看這些字元的二進制情況，結果如下：
【 的十六進制為 A1 BE
】
的十六進制為 A1 BF
健康的十六進制為 BD A1 BF B5
降的十六進制為 BD B5
通過以上的十六進制數據不難發現，健康的ASCII碼裡面正好存在】的ASCII碼，於是被替換，留下了降的ASCII碼。
由此可知，在字元串查找替換的時候，如果是非ASCII編碼字元串很容易出現這種問題，通過轉碼到UTF8或者Unicode編碼能否徹底的解決此問題還有待考證！
㈢ PHP字元集顯示問題!!!高手來
一看你導出來的sql文件是什麼格式的
二就是你建立的數據字元集是什麼
三就是導入的時候用的什麼字元集，
只要這三塊要注意
㈣ php字元集修改成GBK在php.ini文件里怎麼改啊
文本編輯打開文件、修改保存即可。
如果是WINDOWS伺服器，可以使用記事本修改。如果是UNIX伺服器，可以使用vi修改。
查看PHP.INI文件位置，可以使用phpinfo()函數
㈤ php創建mysql數據表，怎麼選擇UTF8字元集
一、轉碼失敗
在數據寫入到表的過程中轉碼失敗，資料庫端也沒有進行恰當的處理，導致存放在表裡的數據亂碼。
針對這種情況，前幾篇文章介紹過客戶端發送請求到服務端。
其中任意一個編碼不一致，都會導致表裡的數據存入不正確的編碼而產生亂碼。
比如下面簡單一條語句：
set @a = "文本字元串";
insert into t1 values(@a);
變數 @a 的字元編碼是由參數 CHARACTER_SET_CLIENT 決定的，假設此時編碼為 A，也就是變數 @a 的編碼。
2. 寫入語句在發送到 MySQL 服務端之前的編碼由 CHARACTER_SET_CONNECTION 決定，假設此時編碼為 B。
3. 經過 MySQL 一系列詞法，語法解析等處理後，寫入到表 t1，表 t1 的編碼為 C。
那這里編碼 A、編碼 B、編碼 C 如果不兼容，寫入的數據就直接亂碼。
二、客戶端亂碼
表數據正常，但是客戶端展示後出現亂碼。
這一類場景，指的是從 MySQL 表裡拿數據出來返回到客戶端，MySQL 里的數據本身沒有問題。客戶端發送請求到 MySQL，表的編碼為 D，從 MySQL 拿到記錄結果傳輸到客戶端，此時記錄編碼為 E（CHARACTER_SET_RESULTS）。
那以上編碼 E 和 D 如果不兼容，檢索出來的數據就看起來亂碼了。但是由於數據本身沒有被破壞，所以換個兼容的編碼就可以獲取正確的結果。
這一類又分為以下三個不同的小類：
1)欄位編碼和表一致，客戶端是不同的編碼
比如下面例子， 表數據的編碼是 utf8mb4，而 SESSION 1 發起的連接編碼為 gbk。那由於編碼不兼容，檢索出來的數據肯定為亂碼。
2）表編碼和客戶端的編碼一致，但是記錄之間編碼存在不一致的情形
比如表編碼是 utf8mb4，應用端編碼也是 utf8mb4，但是表裡的數據可能一半編碼是 utf8mb4，另外一半是 gbk。那麼此時表的數據也是正常的，不過此時採用哪種編碼都讀不到所有完整的數據。這樣數據產生的原因很多，比如其中一種可能性就是表編碼多次變更而且每次變更不徹底導致（變更不徹底，我之前的篇章里有介紹）。舉個例子，表 t3 的編碼之前是 utf8mb4，現在是 gbk，而且兩次編碼期間都被寫入了正常的數據。
3）每個欄位的編碼不一致，導致亂碼和第二點一樣的場景。不同的是：非記錄間的編碼不統一，而是每個欄位編碼不統一。舉個例子，表 c1 欄位 a1,a2。a1 編碼 gbk，a2 編碼是 utf8mb4。那每個欄位單獨讀出來數據是完整的，但是所有欄位一起讀出來，數據總會有一部分亂碼。
三、LATIN1
還有一種情形就是以 LATIN1 的編碼存儲數據
估計大家都知道字元集 LATIN1，LATIN1 對所有字元都是單位元組流處理，遇到不能處理的位元組流，保持原樣，那麼在以上兩種存入和檢索的過程中都能保證數據一致，所以 MySQL 長期以來默認的編碼都是 LATIN1。這種情形，看起來也沒啥不對的點，數據也沒亂碼，那為什麼還有選用其他的編碼呢？原因就是對字元存儲的位元組數不一樣，比如 emoji 字元 "❤"，如果用 utf8mb4 存儲，佔用 3 個位元組，那 varchar(12) 就能存放 12 個字元，但是換成 LATIN1，只能存 4 個字元。
㈥ php怎麼設置編碼
header("Content-type: text/html; charset=utf-8");
另外你的編輯器編碼也要對應哦
a. 如果欲使用gb2312編碼，那麼php要輸出頭：header(「Content-Type: text/html; charset=gb2312")，靜態頁面添加<meta http-equiv="Content-Type" content="text/html; charset=gb2312">，所有文件的編碼格式為ANSI，可用記事本打開，另存為選擇編碼為ANSI，覆蓋源文件。
b. 如果欲使用utf-8編碼，那麼php要輸出頭 ：header(「Content-Type: text/html; charset=utf-8")，靜態頁面添加<meta http-equiv="Content-Type" content="text/html; charset=utf-8">，所有文件的編碼格式為utf-8。
最近需要用到iconv函數把抓取來過的utf-8編碼的頁面轉成gb2312， 發現只有用iconv函數把抓取過來的數據一轉碼數據就會無緣無故的少一些。 讓我郁悶了好一會兒，去網上一查資料才知道這是iconv函數的一個bug。iconv在轉換字元"—"到gb2312時會出錯。解決方法很簡單，就是在 需要轉成的編碼後加 "//IGNORE" 也就是iconv函數第二個參數後，如下：
iconv("UTF-8","GB2312//IGNORE",$data)
ignore的意思是忽略轉換時的錯誤，如果沒有ignore參數，所有該字元後面的字元串都無法被保存。
㈦ [php教程]php中如何設置字元集
利用PHP函數設置頁面的頭文件編碼，即可：
header("Content-Type:text/html;charset=utf-8");
㈧ php創建mysql資料庫時候如何設置字元集
我來給你做一個綜合解釋吧。
在正常情況下。
PHP腳本 HTML 已經瀏覽器 然後就是資料庫。
都有自己的字元集。何謂字元集。我想你如果是一個真正想熱衷於學PHP
那麼你應該花一定的時間去了解一下字元集的問題。
因為無論你以後做什麼項目開發什麼網站都是要牽涉到字元集。
就好比我做第一個項目。因為字元集搞的死去活來。
好進入正題。怎麼解決問題呢？
1.PHP的字元集。一般PHP網頁的是嵌套在html頁面以內。那麼如果在沒有沖突的情況下可以使用
header方面設置。比如<?php header ... ?>
2.HTML的字元集，一般是網頁的優先字元集，這個問題是牽涉到你的網站是什麼定位，比如：你的網站僅僅適合國內的客戶。那麼用gbk 或者gb2312.如果想老外也開湊湊熱鬧的話，就用utf-8.至於怎麼設置這個字元集，你可以在<meta>這個標記中看到。
3.資料庫的問題。mysql_query("set names gbk"); 這句話意思就是說，在操作資料庫的時候已這個字元集去讀寫。當然這個字元集要對應你的頁面的字元集哦。
4.瀏覽器。瀏覽器的問題是最萬惡的，因為每個瀏覽器默認的是gb2312.當然不同的瀏覽器是不同的。所以要想成為一名優秀的程序員，寫出優質的代碼。你還得去了解每個瀏覽器的差別。當然目前是不需要的，當然這個問題你慢慢學習。寫代碼的過程中會慢慢了解到的。
你要做的就是將所有使用字元集確保一致性
問題就這些吧，如果有什麼問題可以繼續問哦。凡是對PHP有熱情的人。我都會盡全力幫一下。哈哈。因為這個加物以類聚。還有這個內容絕對不是復制粘貼的。
㈨ php 怎麼增加字元集ZHS16GBK
默認編碼不一致造成問題
1、資料庫創建編碼選用一個如gb2312。
2、資料庫字元集校對選用一個gb2312，以上兩者必須一致。
3、不同編譯器或者工具如notepad、vim、editplus，它們默認文件的編碼不一致，保存的時候選擇相應的字元集保存。
4、頁面的環境不一樣造成，html中的head中meta中的charset=gb2312即可。
5、瀏覽器的設置默認編碼不一致，有的自動選擇，有的默認gb2312，許多頁面默認是utf8，造成亂碼，php文件採用header('Content-Type: text/html; charset=gb2312');告訴瀏覽器文本類型是html和字元集是gb2312.，header前面不能有任何輸出包括空格，此時可以不使用方法4.
綜上所述，亂碼的大部分原因。
㈩ php獲取字元編碼的問題
啊=>'0x3021'
這是區位碼,還是國標碼,要是的還真沒辦法.
在PHP中,可以取漢字的內碼
echo bin2hex('啊');
我也只能做到這一步,你再找接下去方法.
echo str_decode('啊');
function str_decode($strval){
$a=bin2hex($strval);
$a1=substr($a,0,2);
$a2=substr($a,2,2);
$a1=strval(decbin(hexdec($a1)));
$a2=strval(decbin(hexdec($a2)));
$c='0';
$b1=substr_replace($a1,$c,0,1);
$b2=substr_replace($a2,$c,0,1);
$b=dechex(bindec($b1)).dechex(bindec($b2));
return "ox".$b;
}
不夠簡練,你在完整下.
注意文件必須以GBK形式保存,才能取得國標碼.
思路是,先取得漢字的內碼,再根據內碼和國標碼的關系,先把內碼分成兩部分,再轉換成二進制,用替換函數把最高位換成'0',這樣就得到國標碼的二進制了,下面的過程就相反.