咖啡戒斷症候群

最近嘗試使用Adobe的Dreamweaver Developer Toolbox來開發資料庫網頁, 該工具只有英文版, 為了修改為中文訊息, 加上初次使用php來撰寫資料庫網頁, 又加上Dreamweaver CS3內定使用utf-8的網頁編碼, 結果處理過程繞了個大圈子, 簡直就是個大災難!

其實起因還是因為阿被的背景, 因為阿被的低階程式偵錯員背景, 讓阿被習慣了用補漏洞的方式處理這個問題, 加上php根基尚未紮實, 著實吃了些苦頭!

不過過程仍有許多值得紀錄, 但是既然是大災難, 就不是三言兩語可以道盡, 還是慢慢挖出回憶再記錄下來好了!

過程大概是:

1.ADDT無法顯示中文, 所以找出了存放英文訊息的檔案把訊息改成了中文。

2.改中文訊息後, 錯誤訊息變成了亂碼。

3.變成亂碼應是判斷訊息文字編碼的問題, 因此直覺的以Notepad把訊息檔讀入, 轉存為utf8編碼的unicode檔案

4.中文訊息變成正常, 但是ADDT部份功能的頁面轉換卻出現header無法修改的錯誤而無法轉換頁面。

5.為解決轉換頁面的問題, 找到了ADDT轉換頁面的部份, 把改寫轉換頁面的方式, 雖然在中文訊息正常的情況下可以轉換頁面, 但轉換頁面的速度較原本慢

6.又把訊息檔改回原本的ANSI格式(big5編碼), 並找到了輸出訊息的函數部份, 把輸出錯誤訊息的函數的輸出結果字串, 從big5編碼改成urf8編碼, 中文訊息顯示正常, 經過修改的轉換頁面函數也同時可以還原為原本寫法。

7.改訊息輸出函數之後, 內定訊息雖然可以正常顯示, 但是自訂訊息部份(可以輸入中文), 卻反而變成了亂碼

8.過程中出現了utf8編碼的網頁, 會呈現整頁空白的情形。為了解決utf8編碼變成空白的情形, 把utf8編碼的網頁加上了BOM, 加上BOM標記後, urf8編碼的網頁果然不再發生IE識別編碼的錯誤

9.加上BOM標記就可以讓utf8編碼的網頁正常, 因部份utf8頁面仍會用到ADDT會轉換頁面的功能,因此仍會導致無法修改header而轉換頁面錯誤, 因此又把轉換頁面函數改成較慢的替代方式。

10.既然為了讓IＥ顯示畫面正常而把utf8網頁加上BOM標記, 於是就把ADDT的訊息檔也改為加上BOM的utf8編碼, 如此讀入該訊息檔時, 就不會發生big5中文被解為utf8而變成亂碼, 所以輸出錯誤訊息的函數就可以還原為原本的函數樣貌, 不必使用big5轉換為utf8編碼的方式, 至此內定錯誤訊息跟自訂錯誤訊息都可以正常顯示, 但ADDT轉換頁面的功能函數仍為較慢的方式

11.發現了PHP的output_buffering=0n的設定方式, 設定後, 網頁仍可為加上bom的utf8編碼, ADDT訊息檔也可改為加上BOM的utf8編碼, 但ADDT的訊息輸出函數、與頁面轉換相關的函數都可以還原為原來版本並維持中文訊息正常。

12.網站接近完工, 要移植到客戶的虛擬主機, 發現主機為PHP4, 且output_buffering=0n並未開啟, 業者也不願做此設定, 看來彷彿得重新努力!

13.因此utf8編碼網頁如果為了正常顯示而加上BOM, 則ADDT與轉換頁面相關的函數又得改成較慢的方式, 但不知是否心理作用, 這種方式在PHP4上比PHP5上又更慢了

14.發現IE將utf8網頁解讀錯誤主要仍在php網頁, 即使php網頁有做了正確的html編碼方式設定仍可能被IE忽略

15.改用php在頁面一開始就送出utf8編碼的HTML設定, 未加上BOM的utf8網頁在IE終於正常

16.既然未加上BOM的utf8編碼頁面可以正常顯示了, ADDT的訊息檔案應該也盡可能把BOM移除, 才能讓ADDT的轉換頁面方式採用原本較快的方式, 因此嘗試把ADDT頁面改為沒有BOM的utf8編碼(UltraEdit無法正常轉碼, Notepad則是會自動加上BOM, 兩者都不能使用), 至此終於中文訊息可以正常顯示, 也可以使用原本ADDT的轉換頁面方式了!

結論:

不論在PHP4, PHP5上使用utf8網頁編碼, 並使用ADDT作為開發工具, 同時又想讓ADDT顯示中文訊息, 其實只需要:

1.使用沒有BOM的utf8編碼檔案, 但得在每個php檔案一開始就以PHP送出utf8編碼方式。

2.ADDT只需將儲存英文訊息的php檔案改為不帶BOM的urf8編碼檔案即可正常顯示, 其他ADDT函數均無須更動。

3.PHP無須設定output_buffering=on, ADDT亦可以正常轉換頁面。