解决了一个utf8编码的问题，自己高兴一下。

从某个时候开始（应该是给servlet折磨之后），本人的php程序编码就只有utf-8的编码格式了，所以从不去考虑gb2312以及GBK，但是最近写一个程序的时候却遇到了很大的麻烦。该程序是一个数据导入程序，导入到文件格式很多，需要php自动分析，这个似乎难不倒我，但是问题在于这些文件的编码方式不一样，有的是gb2312，有的是utf-8，麻烦可大了。当然，或许有朋友要吧iconv或者mb_convert_encoding函数介绍给我，这些函数都一一尝试过，它们有一个严重的问题就是转换之后丢失文字。

最初的时候我以为导入文件都是GB2312的编码，所以我做了两次处理。首先将上传文件的表单提交给一个GB2312编码的php（do-gb2312.php）程序，这样从文件中读取的内容可以正常显示，然后通过ajax将php读出的结果返回到utf-8编码的一个表单中，再次用javascript提交该表单，问题解决了。然而问题并没有解决，因为用户还有另外的导入格式，而这些格式中居然又出现了UTF8的编码模式，刚才的程序好不容易把GB2312编码的文件处理好，但是UTF-8编码又出问题了。

想了很久，最后终于出绝招了。将do-gb2312.php原封不动的以utf-8编码的格式保存成另外一个文件do-utf8.php，在do-gb2312.php中加上编码判断。主界面的表单默认还是提交给do-gb2312.php，当do-gb2312.php中发现文本编码是UTF8格式的时候，通过js自动将主界面的表单提交域改成do-utf8.php，再次提交，大功告成，终于圆满的解决了此问题，毕竟中文除了GB2312和UTF8编码模式之外基本不会有其他的编码模式了。

下面是相关的函数，和一篇墙外相关的文章（虽然他没有解决我的问题，但是还是很有用的，所以我将它搬回到墙内） (read on …)

幸亏当初设计的时候用了PEAR的 Cache_lite做了多级的缓存。结果今天进入google统计一看，没有想到今天居然飙升到13000多IP，实在不可思议，估计又是撞上了新的热门关键词语，看来改版的时候得更加注意考虑缓存了，缓存设计至关重要，否则很容易被拖垮的。目前新的版本已经完成了50%，希望能在6月之前发布出来！

php因为其简单灵活安全（这个似乎和编程习惯相关）而著称，只要有c语言的知识、清晰了解b/s结构，你就可以在很短的时间内迅速上手。但是人总是喜欢偷懒的，写代码到一定的时候就开始想投机取巧了，所以很多人都会从最初的借用别人的代码到使用成熟的库然后到使用框架。对于我自己来说，也一直都在犹豫是使用框架还是用我自己的库+成熟的PEAR呢？

现在PHP的框架很多，传说中就有10个顶级的框架，他们是：Zend Framework、CakePHP、Symfony Project、Seagull Framework、WACT、Prado、PHP on TRAX、ZooP Framework、eZ Components、CodeIgniter，当然最著名的只有Zend Framework、CakePHP、Symfony这三个了。这么多框架，采用哪个好呢？其实学习一种语言就是为了解决问题，使用框架是为了缩短开发周期，但是对于我来说，一直都不知道采用什么框架来开发自己的php程序，有哪位把php开发当作工作的朋友，能给我一点建议么？

目前我一直都是采用自己的库+PEAR lib来完成自己的开发的，框架太多，所以让我无从下手。

几个月前帮一兄弟做网上商店,这兄弟特别喜欢shopex,所以我便负责做shopex的模板。这是我第一次接触shopex，也是我第一次做商业模板，以前接触的比较多的倒是zen-cart（国外的一个商店程序）。当时大致看了看shopex的架构和模板的机制，基本认为这是一个纯的体力劳动了，所以就很快的答应下来了，虽然后来是一直在这个朋友的极度怀疑中进行工作，最终还是我的实力让他的疑虑渐渐的消失了（自己开始臭美了，估计这个朋友也会在这篇文章下面留言的）。不过通过这两个（成功的只有一个）模板的制作，基本了解了shopex的模板机制，总体来说就是：简单+量大。 (read on …)

收到epile的留言，顺着留下的链接找到了花儿开了这篇文章，写的是一个关于如果防止spam的新思路，感觉还挺有道理，但是经过思考之后比较怀疑这样的方式是否可行，可能仅仅是一个治标不治本的方法，并且用了庞大的jquery会拖慢整个站点的速度。所以我这里也写了一个反spam的新思路，供大家参考。其实是一个简单的思路，基本思想就是将你的留言处理方式特殊化。

我没有写过真正的spam程序，但是在大学的时候曾经用简单的方法绕过chinaren校友录的javascript验证，成功的进行“多彩”留言（现在不行了）。从这点看来，想绕过客户端的限制是一件比较容易的事情，所以ajax防止spam的方式仅仅只能针对人工spam。不能防止程序自动spam，除非我们假设这个spam程序会这样做：1.打开你的页面；2.找到填写留言和名字的表单域（ajax防止spam的方式就是想在这里将spam卡住）；3.填写好用户和广告评论；4.模拟用户提交评论表单。如果spam程序真是这样，那么恭喜你，在客户端可以很容易的控制住spam。但是大部分spam不可能会这样做。因为对于主流的程序，如wordpress、drupal，或者主流的bsp，spam程序早已清楚留言的表单有多少域，这些域的含义代表什么，并且也知道对于表单域赋予不同的值便能对不同的文章进行评论。所以spam程序不需要打开你的页面，它完全可以自行制造一个表单（因为你有什么域它都一清二楚了），然后伪造http头信息，假装是从web发送数据，直接将数据post到处理评论的程序，所以前面客户端用ajax做的一切努力都白费了。

因此，目前最有效能防止机器spam的还是图形验证码，当然那些可以通过路径都能看出来的验证码是没有用的。 (read on …)

业余接触php已经有6年多了，中间也遇到过很客户的BT需求，配合刚才发布的文章，所以特此介绍一下我想出来的变态解决方案，说不定你哪天也会用得上呢，用不上就当做看看玩吧。

用php生成word文档。

说到word，可能熟悉asp或者vb的朋友马上就要跳出来了，不就是VBA的问题么？可是别忘了php是在*nix机器下运行，没有可爱的VBA呀，所以这里就得采用变态的方法来解决这个问题了。 (read on …)