【求助】如何讓apache支援utf-8編碼的檔案請求?

[mus000]

65664214842213
-> 根據ASCII只解讀的出A與B其餘則變成亂碼...這樣想對嗎?

你想太多了。ANSI一般不會做額外處理。雖然說中文是雙位元碼，但是，他們並沒有真的被編碼在一起。
資料還是原來的 41 42 A4 A4 A4 AE
雙位元碼的意思，是指 BIG5 在處理中文資料時，是使用兩個位元組來顯示一個中文字。它的原始資料並沒有改變。

在 ASCII 下，沒有對 A4 AE這些高位元碼做定義，會無法顯示。
所以你只會看到 AB 秀在畫面上，但是後面的資料依然存在。
但是，也因為 ASCII 沒有高位元碼應用的需求，有些英文軟體，在碰到高位元碼時，會直接將這些高位元碼刪除濾掉，最後你看到的資料就只剩下 41 42 這樣子被存下來了，這時就跟原始資料已經不同了。所以如果該編碼有對無效位元做處理時，就要小心資料的轉換是否會改變。

比如『大家好』三個字。
它的資料是 A4 6A AE 61 A6 6E
在 BIG5 編碼下，你會看到『大家好』。
在西歐字母編碼下你會看到『ja| n』。
在ASCII下會變成『 j a n』。
在ASCII-7下會被過濾成『jan』。此時儲存的話，資料就被破壞了。
但是它的資料都是同一個 A4 6A AE 61 A6 6E，並沒有改變。
如果是碰到有對 A4 AE A6 這些高位元碼定義成 ASCII 圖型的話，那你就會看到一些圖型出現，像上面的西歐字母編碼。

也正因為資料一直都存在，所以你用 emeditor 這類軟體在切換邊碼時，它們都會以該編碼處理資料顯示的方式去顯示它們的內容。

請問如果php網頁以utf-8存檔,但mysql database卻使用BIG5.
此前提下browser的畫面只要文字是由database調出來的且為中文時就會變亂碼,
但若非從database調出,而是原先就寫在php file的中文字就沒問題,這樣是否表示在PHP調資料時還要加上轉碼的函式,如此該怎麼作呢?

這個就是程式設計師要處理的事了。
首先，你要先確定你的資料當時是以什麼型態存在? UTF-8 ? 還是 ANSI?
如果是 ANSI，需不需要先轉成 UTF-8 再處理? 還是把 UTF-8 轉成 ANSI 來處理?
像你說 database 裡的資料是 BIG5，那個你在調用資料時，就必須以 BIG5 方式去調用出來，然後再去處理成你要的資料型態。
其中還牽扯到一些網頁資料的 UTF-8 被轉成BIG5 時所做的額外處理。
所以:
1. database 是什麼樣的資料型態?
2. php 抓出資料時，是什麼樣子?
3. php 抓出的資料是否該做一些處理?
4. php 要送出去給網頁的資料，是不是要再做一次處理?

以下網址則又有另一個問題,
http://study-note.blogdns.org:8080/blog/mt/
browser以utf-8顯示網頁都沒問題,但若點選檢視原始檔時,記事本就無法正確顯示中文字...
不知這又是何原因啊??

抱歉，該網頁我連不上，所以無法知道確實問題。
以下用猜的。
因為此時的記事本無法正確辨識出你要它顯示的網頁資料是屬於 utf-8。所以以系統預設值的 big5去開起該網頁暫存資料。(IE的網頁暫存資料是在IE的暫存目錄下)
所以，這時只能請改用 emeditor ，然後去調整編碼顯示即可。

最後就是關於您提到的:
"BOM主要用意，是要區分 Unicode 檔內容，是以哪種格式儲存的，比如 BE、LE、UTF-8、UTF-7 的區別。"

我有點混亂,因為我查到的資訊只說到BOM是WINDOWS系統用來分辨UNICODE文件屬於BE(U+FEFF)或者LE(U+FFFE)的,而UTF-8文件可能包含單位元組,雙位元組,三位元組.
也因為每個字元不見得剛好是 2 個 byte,所以不管是以 LE 或是 BE 為主的系統上，UTF-8 文檔大都採 BE 方式編碼.

列個表給您參考:

Bytes 　　　　　　Encoding Form
00 00 FE FF 　　　UTF-32, big-endian
FF FE 00 00 　　　UTF-32, little-endian
FE FF 　　　　　　UTF-16, big-endian
FF FE 　　　　　　UTF-16, little-endian
EF BB BF　　　　　UTF-8

相關網址請參考：　http://www.unicode.org/faq/utf_bom.html

BOM 不是 windows 特有的東西。這是在Unicode中就有的定義。

[b90220208]

很感謝您的回應.

您的意思是說記事本在開啟文件時,是以系統語系為依歸.
例如中文xp下,NOTEPAD就會自動以BIG5去解讀文件嗎?

這樣不是有些奇怪嗎? (為何文書程式不能聰明點...)
因我原本一直以為任何文書程式在開啟文件時,都會先判斷該文件所用內碼為何 (這也是OS讓USER在存檔時選擇編碼的目的之一不是嗎..?),接著再以正確的編碼去解讀.
而若是程式本身無支援該編碼時,只好以預設的--例如中文XP時的BIG5去解讀,所以才會出現亂碼的樣貌....原來不是這樣喔?



======================================================================================

抱歉，該網頁我連不上，所以無法知道確實問題。
以下用猜的。
因為此時的記事本無法正確辨識出你要它顯示的網頁資料是屬於 utf-8。所以以系統預設值的 big5去開起該網頁暫存資料。(IE的網頁暫存資料是在IE的暫存目錄下)
所以，這時只能請改用 emeditor ，然後去調整編碼顯示即可。

如果中文xp下,NOTEPAD真的是自動以BIG5去解讀文件這個觀念成立的話,
那麼我也就了解為何我會遇到這個問題:
當我選檢視原始檔時,會以NOTEPAD開啟網頁暫存目錄下的檔案.又因為我的網頁是以UTF-8存檔的,所以中文XP下預設會自動以BIG5解讀文件的NOTEPAD自然就會出錯了.

只是我不懂為何僅中文字會變亂碼而因文數字則能正確顯示??

那麼例如我由XOOPS,MT BLOG等網站抓下來的網頁檔案,我想其原本若非以UTF-8就是以ANSI(英文)為編碼的吧.
既如此,為何當我以記事本開啟這些文件時都能正常顯示呢?



======================================================================================
關於PHP的編碼轉換函式iconv():

我發現該函數的"字碼集網站"上(http://www.gnu.org/software/libiconv/)的chinese區塊中CP950與BIG5都有定義到,這樣是否表示此兩有什麼不同之處?

會這樣問是因我的MYSQL預設使用BIG5來存資料,若我要將調出來的資料轉換成UTF-8時,
以下兩寫法何者才是??
$newstr = iconv( "CP950" , "UTF-8" , $oldstr);
$newstr = iconv( "BIG5" , "UTF-8" , $oldstr);

[mus000]

不是。XP的記事本在開啟文件時，應該是優先以 Unicode方式去判斷的。
(2K以後的作業系統是以Unicode為主，ANSI為輔。)
如果有 BOM，那就是 Unicode 檔。
沒有 BOM，那就從內容的文字特徵上去找特徵，如果判斷具有Unicode特徵，應該還是會由Unicode方式開啟。會不會有誤判? 可能會。

當判斷不是Unicode時，那就是 ANSI檔，以當時XP系統預設的ANSI big5 編碼下去開啟。但如果那文件其實並不是 big5 檔的話，此時開啟的文件，就可能會是亂碼了。
==========
為何文書程式不能聰明點?

為何不行? 因為沒有判斷唯一條件的依據。
1. 有些編碼存在一些無效位元，可從這些無效位元存在否來惕除。
2. 有些編碼有高位元(東方語系)，高位元範圍有差異。這也是可以判斷的地方。

但是以上方式，都不足以形成唯一的判斷方式，那麼就不會有百分之百正確的結果顯示給你看了。所以最後都是要靠人去決定哪個才是正確的。
所以沒有文書軟體是夠聰明的，頂多是有些稍為聰明一點，還是會有誤判的。

有些軟體很聰明，比如南極星，在多國語言分辨及顯示上有很強的功能，但是，即使如此，還是難保不會有誤判現象發生。

所以才會有 Unicode 的發展，要來解決文字顯示處理大一統的問題。

[mus000]

如果中文xp下,NOTEPAD真的是自動以BIG5去解讀文件這個觀念成立的話,
那麼我也就了解為何我會遇到這個問題:
當我選檢視原始檔時,會以NOTEPAD開啟網頁暫存目錄下的檔案.又因為我的網頁是以UTF-8存檔的,所以中文XP下預設會自動以BIG5解讀文件的NOTEPAD自然就會出錯了.

只是我不懂為何僅中文字會變亂碼而因文數字則能正確顯示??

那麼例如我由XOOPS,MT BLOG等網站抓下來的網頁檔案,我想其原本若非以UTF-8就是以ANSI(英文)為編碼的吧.
既如此,為何當我以記事本開啟這些文件時都能正常顯示呢?

看來你對 ANSI 還有誤解。
英文字，在每個ANSI編碼中的定義，是幾乎都相同的，包括數字及常用符號。所以，不管你用哪種ANSI編碼去開啟一個純英數文件時，通常都是顯示正常的。ANSI的各種編碼，並沒有對原始資料做特別編碼處理。A就是A，B就是B。從 big5 gb jis euc ..... 都是 A 與 B。
你可以自行試試，把一個只有英數的文件，用 emeditor在各種編碼之間切換，看看是否都一樣。

另外記事本為什麼不能正常顯示問題，請參考上一則回答。

關於PHP的編碼轉換函式iconv():

我發現該函數的"字碼集網站"上(http://www.gnu.org/software/libiconv/)的chinese區塊中CP950與BIG5都有定義到,這樣是否表示此兩有什麼不同之處?

會這樣問是因我的MYSQL預設使用BIG5來存資料,若我要將調出來的資料轉換成UTF-8時,
以下兩寫法何者才是??
$newstr = iconv( "CP950" , "UTF-8" , $oldstr);
$newstr = iconv( "BIG5" , "UTF-8" , $oldstr);

CP950 跟 BIG5 其實是類似的東西。只不過，BIG5是台灣業界通用，而 CP950是微軟制定給台灣地區用的中文，兩者有一些差異。CP950少了一些東西。
建議你還是用 BIG5。

[b90220208]

我剛作了一個測試結論是xp下的utf-8文件若以emeditor強行刪去BOM的話,
會導致記事本無法判斷是否為UTF-8而以ANSI(BIG5)去解讀該文件,所以這也就是為什麼我的UTF-8網頁以BROWSER點選檢視原始檔時所有中文都變亂碼了.至於為何英文數字可正常顯示,那是因為,例如"A"這個字母,不管以何內碼來看,其machine code看起來都會有一串"01000001"
若翻成UNICODE則等於U+0041,
若翻成UTF-8就變成了0x41
若翻成ASCII code則為: 65
對照各自的table,結果都是"A".

而從UNICODE轉換為UTF-8的規則之一來看:
U+0000 - U+007F：0xxxxxxx
也可看出utf-8對於ASCII code定義的128個字元符號都是相容的用意.....It's great! 我終於真的懂了.....Thanks a lot again !!


---------------------------------------
以下code是判斷字元是否為中文字,我試過許多都無問題,唯讀"鑫"這一字就是無法正確判斷.....不知問題出在哪,是code有瑕疵嗎?

[PHP]<?PHP
define("BIG5_HB_MIN" , 0x81); // 高位元組最小值
define("BIG5_HB_MAX" , 0xfe); // 高位元組最大值
define("BIG5_LB1_MIN" , 0x40); // 低位元組最小值
define("BIG5_LB1_MAX" , 0x7e); // 低位元組最大值
define("BIG5_LB2_MIN" , 0xa1); // 低位元組最小值
define("BIG5_LB2_MAX" , 0xfe); // 低位元組最大值


function big5_isHB($c) {
$asc = Ord($c);
if($asc>=BIG5_HB_MIN && $asc<=BIG5_HB_MAX) return true;
return false;
}

function big5_isLB($c) {
$asc = Ord($c);
// php在處理數值變數,例如:比較大小或者純輸出時,不論是十或其他如十六進位數值,都會被轉成十進制數值喔!
if(($asc>=BIG5_LB1_MIN && $asc<=BIG5_LB1_MAX) || ($asc>=BIG5_LB2_MIN && $asc<=BIG5_LB2_MAX))
return true;
return false;
}



$c = '鑫';

// php自動將字串資料(包括單一字元)之變數視作一陣列
if ( big5_isHB($c[0]) && big5_isLB($c[1]) ) { echo $c.' is a chinese word!'; }
else { echo $c.' is not a chinese word!'; }
?>[/PHP]

[mus000]

你要不要試試把『鑫』的資料印出來比對看看是不是在你的定義範圍之外?
在 utf-8 存檔中，看到的『鑫』編碼是 E9 91 AB。
91 不在你的條件判斷式中。
所以問題可能是在這裡。

[b90220208]

真抱歉,函式的判斷是針對BIG5字集,
但此卻是個UTF-8文件,主要是我將檢測的字元:"鑫"寫在文件上,
若是由BIG5的DATABASE調出"鑫"字再呼叫這兒的函式檢測就沒問題了.
--- 有無可以檢查資料編碼種類的函式可用?

對了您是如何看的到原始編碼的呢?(可以教一下嗎)
還有關於MySQL如何支援UTF-8呢?
(因我在安裝APPSERV v2.5.1時發現它雖支援相當多的編碼,但就是找不到有utf-8可選)

[mus000]

沒有檢查函式可用。
只有轉換用的函式。
程式建議參考網路上其它前輩的概念跟寫法。
這種問題找不到一個完美的解決法，只看你適不適合用跟夠不夠用而已。
目前來看統一使用UTF-8也許是完美的方案一種。但是缺點就是儲存容量會膨脹，處理資料量相對上變多。


怎麼看文字編碼的值? 就找個可以看 HEX 的文書軟體就行了。
比如 ultraedit，或是 winHEX 之類的。

MySQL 怎麼設定 UTF-8?
找到 my.ini 檔，設定以下資料應該就行了。(mysql 版本可能有差別)
[mysqld]
default-character-set = utf-8
[client]
default-character-set = utf-8

[b90220208]

抱歉讓我再小問一下就好:
php4,5版本的"字串相關函式"例如有切割,擷取字數,置換字元...等
其原理是都是將一個byte當作一個字元嗎?
若是,換句話說,也僅限於處理ASCII或者是BIG5,UTF-8等的英文數字類的字元了嗎?
至於碰到多位元字元時要嘛不是誤切就是誤判...對嗎?
....到現階段為止,是否都還未有能夠處理UNICODE之類的"字串函式"支援嗎?
若是,那MySQL改成UTF-8還是個好的決定嗎?
這樣往後遇有要切割字串時,豈不是還要再作轉碼成BIG5,然後再以特定能處理BIG5的函式去處理...如此頗為麻煩的...還是有更好的解決方案呢?

[mus000]

php 的部份，可能得問問這方面的高手才行了。
剛剛找了一下發現，原來在 php4 >= 4.0.6 以後版本裡，就有檢查資料編碼的函數。
mb_detect_encoding

在此修正一下之前的錯誤。 =.=

在php中，有一個功能函數組是 Multi-Byte String Functions，
應該就是跟多位元編碼有關的功能支援。(有版本差異，舊版可能無)
配合這些函數功能，應該就能做到你想到的東西。