php字元編碼
A. 怎樣設置php的編碼格式為utf-8
在 PHP 編寫過程中，一般需要注意的是三種編碼：
1、網頁字元編碼
2、文件字元編碼
3、資料庫字元編碼
只有上面3種編碼的格式都一致的情況下，才會盡可能的避免亂碼的出現。
二、如何使用Notepad++軟體設置UTF-8編碼：
用 Notepad++ 軟體打開指定的 php 文檔後，在「格式」菜單下找到「以UTF-8格式編碼"
以xxx編碼的意思是不強制轉換文件的編碼，僅僅以某種編碼來查看，不會對文件進行修改，這對打開某個文件發現都是亂碼時非常實用。
轉為xxx編碼的意思就是將文件內容強制轉換為某種編碼，這對於本來看到的就不是亂碼但需要調整右下角的文件編碼時非常好用。
B. PHP中哪個函數可以強制統一設置所有字元編碼為指定編碼
一般都是utf-8和gbk，gbk的一般沒有什麼問題。
utf-8最好在apache服務端就設定為utf-8。然後其他的地方，資料庫、文件都設置為UTF-8，就不會有錯了。
在php函數庫有一個函數：iconv()，iconv函數庫能夠完成各種字元集間的轉換，是php編程中不可缺少的基礎函數庫。
最近在做一個小偷程序，需要用到iconv函數把抓取來過的utf-8編碼的頁面轉成gb2312， 發現只有用iconv函數把抓取過來的數據一轉碼數據就會無緣無故的少一些。 讓我郁悶了好一會兒，去網上一查資料才知道這是iconv函數的一個bug。iconv在轉換字元"—"到gb2312時會出錯。
php編程技術：
PHP是一種易於學習和使用的伺服器端腳本語言。只需要很少的編程知識你就能使用PHP建立一個真正交互的WEB站點。 PHP是能讓你生成動態網頁的工具之一。PHP網頁文件被當作一般HTML網頁文件來處理並且在編輯時你可以用編輯HTML的常規方法編寫PHP。
C. php 字元編碼問題
做php最好是編碼統一， 頁面utf8， 資料庫gb2312， 這樣做，除了難為你自己還有別的好處嗎？
如果你非要這么做， 那你必須將$name11="張三" 轉成gb2312編碼， 然後讀取出來顯示到頁面的時候， 必須轉成utf8， 不累的慌？
D. PHP中如何把一個字元串轉換為utf-8編碼的 如題 謝謝了
1、把 GBK 編碼字串轉換成 UTF-8 編碼字串 view plain to clipboardprint? <?php header("content-Type: text/html; charset=Utf-8"); echo mb_convert_encoding("你是我的好朋友","UTF-8","GBK"); ?> 2、把 UTF-8 編碼字串轉換成 GB2312 編碼字串 view plain to clipboardprint? // 注意將此文件存檔成 utf-8 編碼格式文件再測試 <?php header("content-Type:text/html;charset=gb2312"); echo mb_convert_encoding("你是我的好朋友","gb2312","utf-8"); ?> // 注意將此文件存檔成 utf-8 編碼格式文件再測試 <?php header("content-Type: text/html; charset=gb2312"); echo mb_convert_encoding("你是我的好朋友","gb312","utf-8"); ?> 3、對整個頁面進行轉換 該方法適用所有編碼環境。這樣把前128個字元以外（顯示字元）的字元集都用 NCR（Numeric character reference，如「漢字」將轉換成「汉字」這種形式）來表示，這樣的編碼在任意編碼環境下頁面都能正常顯示。 在php文件的頭部加上下面三行代碼： view plain to clipboardprint? mb_internal_encoding(」gb2312″); // 這里的gb2312是你網站原來的編碼 mb_http_output(」HTML-ENTITIES」); ob_start(』mb_output_handler』); mb_internal_encoding(」gb2312″); // 這里的gb2312是你網站原來的編碼 mb_http_output(」HTML-ENTITIES」); ob_start(』mb_output_handler』); 使用mb_convert_encoding 函數需啟用PHP 的mbstring （multi-byte string）擴展
E. php 一般設默認編碼是什麼
也可以給每個文件設置默認編碼，但是比較麻煩，不建議這樣做。建議直接找到配置文件，然後將編碼格式設置成自己需要的類型即可。
F. PHP的字元轉成ANSI編碼。。。求助。。。
用notepad++吧
選擇「格式」->"專為ANSI編碼"
ok
G. PHP中文編碼~~
一、頁面編碼
1. 使用 <META http-equiv="content-type" content="text/html; charset=xxx"> 標簽設置頁面編碼
這個標簽的作用是聲明客戶端的瀏覽器用什麼字元集編碼顯示該頁面，xxx可以為GB2312，GBK，UTF-8（和Mysql不同，MySQL是 UTF8）等等。因此，大部分頁面可以採用這種方式來告訴瀏覽器顯示這個頁面的時候採用什麼編碼，這樣才不會造成編碼錯誤而產生亂碼。但是有的時候我們會發現有了這句還是不行，不管xxx是哪一種，瀏覽器採用的始終都是一種編碼，這個情況我後面會談到。
請注意，<meta>是屬於html信息的，僅僅是一個聲明，它起作用表明伺服器已經把HTML信息傳到了瀏覽器。
2. header("content-type:text/html; charset=xxx");
這個函數header()的作用是把括弧裡面的信息發到http標頭。
如果括弧裡面的內容為文中所說那樣，那作用和<META>標簽基本相同，大家對照第一個看發現字元都差不多的。但是不同的是如果有這段函數，瀏覽器就會永遠採用你所要求的xxx編碼，絕對不會不聽話，因此這個函數是很有用的。為什麼會這樣呢？那就得說說HTTPS標頭和HTML信息的差別了：
https標頭是伺服器以HTTP協議傳送HTML信息到瀏覽器前所送出的字串。
因為meta標簽是屬於html信息的，所以header()發送的內容先到達瀏覽器，通俗點就是header()的優先順序高於meta（不知道可不可以這樣講）。加入一個php頁面既有header("content-type:text/html; charset=xxx")，又有<META http-equiv="content-type" content="text/html; charset=xxx">，瀏覽器就只認前者http標頭而不認meta了。當然這個函數只能在php頁面內使用。
同樣也留有一個問題，為什麼前者就絕對起作用，而後者有時候就不行呢？這就是接下來要談的Apache的原因了。
3. AddDefaultCharset
Apache 根目錄的 conf 文件夾里，有整個Apache的配置文檔httpd.conf。
用文本編輯器打開httpd.conf，第708行（不同版本可能不同）有AddDefaultCharset xxx，xxx為編碼名稱。這行代碼的意思：設置整個伺服器內的網頁文件https標頭里的字元集為你默認的xxx字元集。有這行，就相當於給每個文件都加了一行header("content-type:text/html; charset=xxx")。這下就明白為什麼明明meta設置了是utf-8，可瀏覽器始終採用gb2312的原因。
如果網頁里有header("content-type:text/html; charset=xxx")，就把默認的字元集改為你設置的字元集，所以這個函數永遠有用。如果把AddDefaultCharset xxx前面加個「#」，注釋掉這句，而且頁面里不含header("content-type…")，那這個時候就輪到meta標簽起作用了。
4. default_charset
在 php.ini 文件中可以定義 php 的默認語言： default_charset = "xxx"，xxx為編碼名稱。這行代碼的意思是設置所有 php 的輸出頁面編碼為 xxx。
總結：
以上 4 種編碼設置方法的優先順序如下：
header("content-type:text/html; charset=xxx")
default_charset xxx
AddDefaultCharset xxx
<META http-equiv="content-type" content="text/html; charset=xxx">
如果你是web程序員，給你的每個頁面都加個header("content-type:text/html; charset=xxx")，保證它在任何伺服器都能正確顯示，可移植性強。
至於那句AddDefaultCharset xxx，要不要注釋就仁者見仁了。反正我是注釋掉了，不過我寫頁子也要寫header()，便於放到伺服器上能正常顯示。
二、資料庫編碼
PHP 程序在查詢資料庫之前，首先執行 mysql_query(「SET NAMES xxxx」);其中 xxxx 是你網頁的編碼(charset=xxxx)，如果網頁中 charset=utf8，則 xxxx=utf8，如果網頁中 charset=gb2312，則xxxx=gb2312，幾乎所有WEB程序，都有一段連接資料庫的公共代碼，放在一個文件里，在這文件里，加入mysql_query(「set names」)就可以了。
SET NAMES 顯示客戶端發送的 SQL 語句中使用什麼字元集。因此，SET NAMES 'utf-8'語句告訴伺服器「將來從這個客戶端傳來的信息採用字元集utf-8」。它還為伺服器發送回客戶端的結果指定了字元集。（例如，如果你使用一個SELECT語句，它表示列值使用了什麼字元集。）
三、中文文件名
默認情況下，文件名為中文時不能訪問。要使中文文件名能正常訪問，需進行如下設置：
在ie中選擇 工具 -> internet選項 -> 高級 -> 取消「總是以UTF-8發送URL」。
H. php怎樣判斷字元串是什麼編碼
php判斷字元編碼的二個方法：
一個是用php自帶的函數mb_detect_encoding，一個是個人寫函數來處理。
方法1，使用mb_detect_encoding函數。
?
1
2
3
4
<?php
$str=」<a href="http://www..com/" target="_blank" class="infotextkey">腳本</a>」;
echo mb_detect_encoding($str);
?>
方法2，自定義函數。
?
1
2
3
4
5
6
7
8
9
10
11
<?php
function chkbm($string){
$bm = array(『ASCII』, 『GBK』, 『UTF-8′);
foreach($bm as $c){
if( $string === <a href="http://www..com/" target="_blank" class="infotextkey">iconv</a>(『UTF-8′, $c, iconv($c, 『UTF-8′, $string))){//轉換編碼後是不是相等
return $c;
}
}
return null;
}
?>
I. php 怎樣判斷字元串是哪種編碼
php中有個函數可以用來檢查當前字元串的編碼類型
mb_detect_encoding($str,array('ASSCII',''GB2312','UTF-8));
PHP用MBString庫的函數
$e=mb_detect_encoding($text, array('UTF-8', 'GBK'));
switch($e){
case 'UTF-8' : //如果是utf8編碼
break;
case 『GBK』: //如果是gbk編碼
break
}
J. 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編碼能否徹底的解決此問題還有待考證！