本文目錄一覽:
- 1、PHP字元串長度計算 – strlen()函數使用介紹
- 2、php各種編碼集詳解和在什麼情況下進行使用
- 3、如何用 PHP 搞定中文字元編碼問題
- 4、什麼是PHP編碼?
- 5、PHP如何獲取中文字元串長度 utf8
PHP字元串長度計算 – strlen()函數使用介紹
strlen()函數和mb_strlen()函數
在PHP中,函數strlen()返回字元串的長度。函數原型如下:
複製代碼
代碼如下:
int
strlen(string
string_input);
參數string_input為要處理的字元串。
strlen()函數返回字元串所佔的位元組長度,一個英文字母、數字、各種符號均佔一個位元組,它們的長度均為1。一個中午字元佔兩個位元組,所以一個中午字元的長度是2。例如
複製代碼
代碼如下:
?php
echo
strlen(“”);
echo
strlen(“三知開發網”);
?
「echo
strlen(“”);」的運行結果:15
「echo
strlen(“三知開發網”);」的運行結果:15
這裡有一個疑問,一個中文字元不是佔2個位元組嗎?「三知開發網」,明明是五個漢字,運行的結果怎麼會是15?
原因出在這裡:strlen()計算時,對於一個UTF-8的中文字元,會把它當做長度為3來處理。當出現中英文混排的情況下,怎麼準確的計算字元串的長度呢?這裡,得引入另外一個函數mb_strlen()。mb_strlen()函數的用法與strlen()幾乎一摸一樣,只是多了一個指定字符集編碼的參數。函數原型為:
複製代碼
代碼如下:
int
mb_strlen(string
string_input,
string
encode);
PHP內置的字元串長度函數strlen無法正確處理中文字元串,它得到的只是字元串所佔的位元組數。對於GB2312的中文編碼,strlen得到的值是漢字個數的2倍,而對於UTF-8編碼的中文,就是3倍的差異了(在UTF-8編碼下,一個漢字佔3個位元組)。
因此,下面的代碼能準確計算出中文字元串的長度:
複製代碼
代碼如下:
?php
$str
=
“三知sunchis開發網”;
echo
strlen($str).”br”;
//結果:22
echo
mb_strlen($str,”UTF8″).”br”;
//結果:12
$strlen
=
(strlen($str)+mb_strlen($str,”UTF8″))/2;
echo
$strlen;
//結果:17
?
原理分析:
strlen()計算時,對待UTF-8的中文字元長度是3,所以「三知sunchis開發網」的長度為5×3+7×1=22
在mb_strlen計算時,選定內碼為UTF8,則會將一個中文字元當作長度1來計算,所以「三知sunchis開發網」長度為5×1+7×1=12
剩下的就是純數學問題了,在此就不啰嗦了……
注意:對於mb_strlen($str,’UTF-8′),如果省略第二個參數,則會使用PHP的內部編碼。內部編碼可以通過mb_internal_encoding()函數得到。需要注意的是,mb_strlen並不是PHP核心函數,使用前需要確保在php.ini中載入了php_mbstring.dll,即確保「extension=php_mbstring.dll」這一行存在並且沒有被注釋掉,否則會出現未定義函數的問題。
php各種編碼集詳解和在什麼情況下進行使用
utf-8 一般是通用的並且是國際的編碼標準, gbk gb2312 是中國標準,我覺得主要看的你的產品在什麼實用範圍,建議實用UTF-8
如何用 PHP 搞定中文字元編碼問題
1、要麼頁面原始漢字和從資料庫里取出的漢字全是亂碼;
2、要麼原始漢字和資料庫漢字,一個顯示正常了,另一個就變成亂碼了。
問題需要一步一步的解決。在實際操作以下方法之前,需要配置 Web 伺服器,使其與 PHP 集成,最終可以調試 PHP 程序。我們以常見的 GB2312 和 UTF-8 字符集為例來測試和說明。瀏覽器是 IE7.0。
1、頁面原始漢字亂碼的解決
解決這個問題就需要使用 UltraEdit 的這個功能。
1.1 打開中文 Windows,用 UltraEdit 創建一個文本文件,手工輸入一個 PHP 頁面文件,文件內容如下。保存為 test1.php 文件,注意保存時「格式」下拉框選擇「默認」- 特別注意這裡。
什麼是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如何獲取中文字元串長度 utf8
PHP對中文字元串的處理一直困擾於剛剛接觸PHP開發的新手程序員。下面簡要的剖析一下PHP對中文字元串長度的處理:
PHP自帶的函數如strlen()、mb_strlen()都是通過計算字元串所佔位元組數來統計字元串長度的,一個英文字元佔1位元組。例:
$enStr = 『Hello,China!』;
echo strlen($enStr); // 輸出:12
而中文則不然,做中文網站一般會選擇兩種編碼:gbk/gb2312或是utf-8。utf-8能兼容更多的字元,所以受到很多站長的喜愛。gbk與utf-8對中文的編碼不同,導致中文在gbk與utf-8編碼下所佔位元組也有差異。
gbk編碼下每個中文字元所佔位元組為2,例:
$zhStr = 『您好,中國!』;
echo strlen($zhStr); // 輸出:12
utf-8編碼下每個中文字元所佔位元組為3,例:
$zhStr = 『您好,中國!』;
echo strlen($zhStr); // 輸出:18
那麼如何計算這組中文字元串的長度呢?有人可能會說gbk下獲取中文字元串長度除以2,utf-8編碼下除以3不就行了嗎?但是您要考慮字元串並不老實,99%的情況會以中英混合的情況出現。
這是WordPress中的一段代碼,主要思想就是先用正則將字元串分解為個體單元,然後再計算單元的個數即字元串的長度,代碼如下(只能處理utf-8編碼下的字元串):
$zhStr = 『您好,中國!』;
$str = 『Hello,中國!』;
// 計算中文字元串長度
function utf8_strlen($string = null) {
// 將字元串分解為單元
preg_match_all(「/./us」, $string, $match);
// 返回單元個數
return count($match[0]);
}
echo utf8_strlen($zhStr); // 輸出:6
echo utf8_strlen($str); // 輸出:9
原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-tw/n/155067.html