mus000
2005-04-16, 11:20 AM
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中就有的定義。
-> 根據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中就有的定義。