問題都是一個(gè),結(jié)論總是奇形怪狀.
狀況: ecshop 驗(yàn)證碼不顯示
1) 原因1： 有客戶試圖用前臺(tái)英文后臺(tái)中文模式工作，他就仿照一些方法，覆蓋了語言文件
導(dǎo)致一些CFG 后臺(tái)設(shè)置的變量無法讀取，
解決方法，修改 captcha.php 文件，不包含 init.php, 然后手動(dòng)傳入寬高變量
首先定義 ROOT_PATH
define(‘ROOT_PATH’, “絕對(duì)路徑”);
然后
$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
解決方法，找到對(duì)應(yīng)文件，應(yīng) editplus 重新保存成 utf-8 無bom
如何將代碼保存為utf-8無bom格式的呢？
BOM（Byte Order Mark）是Unicode規(guī)范中推薦的標(biāo)記字節(jié)順序的方法。
在UCS 編碼中有一個(gè)叫做”ZERO WIDTH NO-BREAK SPACE”的字符，它的編碼是FEFF。而FFFE在UCS中是不存在的字符，所以不應(yīng)該出現(xiàn)在實(shí)際傳輸中。UCS規(guī)范建議我們?cè)趥鬏斪止?jié)流前，先傳輸 字符”ZERO WIDTH NO-BREAK SPACE”。
這樣如果接收者收到FEFF，就表明這個(gè)字節(jié)流是Big-Endian的；如果收到FFFE，就表明這個(gè)字節(jié)流是Little-Endian的。因此字符”ZERO WIDTH NO-BREAK SPACE”又被稱作BOM。
UTF-8不需要BOM來表明字節(jié)順序，但可以用BOM來表明編碼方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8編碼是EF BB BF（讀者可以用我們前面介紹的編碼方法驗(yàn)證一下）。所以如果接收者收到以EF BB BF開頭的字節(jié)流，就知道這是UTF-8編碼了。
Windows就是使用BOM來標(biāo)記文本文件的編碼方式的。
在使用UTF-8對(duì)字符進(jìn)行編碼時(shí)，windows的記事本保存時(shí)會(huì)對(duì)其內(nèi)容自動(dòng)加上BOM。該行為會(huì)導(dǎo)致一些問題，最常見的莫過一些莫名其妙的空 白行了。在PHP中使用include函數(shù)包含一個(gè)PHP文件時(shí)，空白行就有可能產(chǎn)生，然后就會(huì)對(duì)頁面的樣式產(chǎn)生影響，所以windows自帶的記事本并 不是一款值得依賴的文本編輯器。
Dreamweaver中除去BOM的方法：ctrl+J -> 標(biāo)題/編碼 -> 取消”包括Unicode簽名(BOM)”選擇。
