问题都是一个,结论总是奇形怪状.
状况: ecshop 验证码不显示

1) 原因1： 有客户试图用前台英文后台中文模式工作，他就仿照一些方法，覆盖了语言文件
导致一些CFG 后台设置的变量无法读取，
解决方法，修改 captcha.php 文件，不包含 init.php, 然后手动传入宽高变量
首先定义 ROOT_PATH
define(‘ROOT_PATH’, “绝对路径”);
然后
$img = new captcha(ROOT_PATH . ‘data/captcha/’, $_CFG['captcha_width'], $_CFG['captcha_height']);
变为
$img = new captcha(ROOT_PATH . ‘data/captcha/’, 100, 20);

2) 原因2，修改了某些utf-8文件，结果保存成 utf-8+ 也就是传说中的 utf-8 with bom
解决方法，找到对应文件，应 editplus 重新保存成 utf-8 无bom

如何将代码保存为utf-8无bom格式的呢？

BOM（Byte Order Mark）是Unicode规范中推荐的标记字节顺序的方法。

在UCS 编码中有一个叫做”ZERO WIDTH NO-BREAK SPACE”的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输 字符”ZERO WIDTH NO-BREAK SPACE”。

这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符”ZERO WIDTH NO-BREAK SPACE”又被称作BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8编码是EF BB BF（读者可以用我们前面介绍的编码方法验证一下）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

在使用UTF-8对字符进行编码时，windows的记事本保存时会对其内容自动加上BOM。该行为会导致一些问题，最常见的莫过一些莫名其妙的空 白行了。在PHP中使用include函数包含一个PHP文件时，空白行就有可能产生，然后就会对页面的样式产生影响，所以windows自带的记事本并 不是一款值得依赖的文本编辑器。

Dreamweaver中除去BOM的方法：ctrl+J -> 标题/编码 -> 取消”包括Unicode签名(BOM)”选择。