問題都是一個,結(jié)論總是奇形怪狀.
狀況: ecshop 驗證碼不顯示

1) 原因1： 有客戶試圖用前臺英文后臺中文模式工作，他就仿照一些方法，覆蓋了語言文件
導(dǎo)致一些CFG 后臺設(shè)置的變量無法讀取，
解決方法，修改 captcha.php 文件，不包含 init.php, 然后手動傳入寬高變量
首先定義 ROOT_PATH
define(‘ROOT_PATH’, “絕對路徑”);
然后
$img = new captcha(ROOT_PATH . ‘data/captcha/’, $_CFG['captcha_width'], $_CFG['captcha_height']);
變?yōu)?br /> $img = new captcha(ROOT_PATH . ‘data/captcha/’, 100, 20);

2) 原因2，修改了某些utf-8文件，結(jié)果保存成 utf-8+ 也就是傳說中的 utf-8 with bom
解決方法，找到對應(yīng)文件，應(yīng) editplus 重新保存成 utf-8 無bom

如何將代碼保存為utf-8無bom格式的呢？

BOM（Byte Order Mark）是Unicode規(guī)范中推薦的標記字節(jié)順序的方法。

在UCS 編碼中有一個叫做”ZERO WIDTH NO-BREAK SPACE”的字符，它的編碼是FEFF。而FFFE在UCS中是不存在的字符，所以不應(yīng)該出現(xiàn)在實際傳輸中。UCS規(guī)范建議我們在傳輸字節(jié)流前，先傳輸 字符”ZERO WIDTH NO-BREAK SPACE”。

這樣如果接收者收到FEFF，就表明這個字節(jié)流是Big-Endian的；如果收到FFFE，就表明這個字節(jié)流是Little-Endian的。因此字符”ZERO WIDTH NO-BREAK SPACE”又被稱作BOM。

UTF-8不需要BOM來表明字節(jié)順序，但可以用BOM來表明編碼方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8編碼是EF BB BF（讀者可以用我們前面介紹的編碼方法驗證一下）。所以如果接收者收到以EF BB BF開頭的字節(jié)流，就知道這是UTF-8編碼了。

Windows就是使用BOM來標記文本文件的編碼方式的。

在使用UTF-8對字符進行編碼時，windows的記事本保存時會對其內(nèi)容自動加上BOM。該行為會導(dǎo)致一些問題，最常見的莫過一些莫名其妙的空 白行了。在PHP中使用include函數(shù)包含一個PHP文件時，空白行就有可能產(chǎn)生，然后就會對頁面的樣式產(chǎn)生影響，所以windows自帶的記事本并 不是一款值得依賴的文本編輯器。

Dreamweaver中除去BOM的方法：ctrl+J -> 標題/編碼 -> 取消”包括Unicode簽名(BOM)”選擇。