抱怨你的工具，并不会让你的事情做得更好。

我前一篇的「PHP 开发迷思 （叁） – PHP 很蹩脚？」，有网友写了一篇「 PHP 很烂」来回应。

我想说的是：对他来说， PHP 的确很糟，所以真的不适合他；由于他援用了别人停留在三四年前的 PHP 的观念来证明他对 PHP 的看法。还有，他看到的都是烂 PHP 程序。

不可否认， PHP 的确在先天上有所不足，只由于它诞生的太早，很多包袱无法轻易摆脱。即便 PHP 6 将会摆脱这些束缚，但时间点似乎太晚？

所以呢？难道研讨 PHP 的人都是傻瓜吗？

当然不是。

我不想为 PHP 平反什么，我也不认为我能改变多少人对 PHP 的看法。这裡我只想把这些人认为 PHP 烂的地方做个说明，剩下的就交给大家自行评断。

版本问题

从 PHP 诞生以来有十五年了，真正被大家注重而开始运用的第 4 版则有十年了。

然而随着 PHP 5 的诞生，以及 2008 年 PHP 4 不再被官方维护，大部份的主机商也曾经部署了 PHP 5 作为次要执行环境；虽然现阶段 PHP 5 还是会让 PHP 4 的程序能够执行，但是开发者的观念如果没有一同随着更新，那才是灾难的开始。

言语的设计本来就没办法一开始考虑周详， Java 如此， Python 也是如此，它们在严重改版时，部份语法及相关的核心组件上本来就会有所改变。而开发者如果没有适时去了解在新版本上的使用差异，那么跟抱怨一把生锈的斧头很难砍倒一棵大树有什么差别？

Unicode

Unicode 在最近这几年才开始被台湾的开发者所注重，在那之前 BIG5 大概是他们的恶梦吧。

先不管 PHP ，我们来看一下别的言语怎样处理 Unicode 。

Ruby： 就我粗浅的了解， Ruby 本身也不完整援助处理 Unicode ，但还是可以处理。

Python： 在 2.x 版也是透过 unicode 类别来处理，在 3.0 核心有直接援助。

那么 PHP 呢？

的确 PHP 本身没有很方便的方法来处理 Unicode ，但是不表示它不能用其他方法来处理：

mbstring： 多位元组的字串处理

iconv： 转换编码

PHP 6 当前则是直接把 unicode 放到核心函式裡。

当然 PHP 先天的限制，会让它在处理 Unicode 字串上无法像 Ruby 和 Python 那么直觉；但不表示我们不能透过其他方法将它封装起来，方便后续的开发。

在材料库上的 Unicode 问题也是如此， PHP 本身不处理这些，它只是透过 client 来取得材料库回传的材料，这在每个言语对材料库的实作都是一样的。

Magic Quotes

一开始 PHP 有 magic_quotes 只是为了方便处理要塞入材料库的字串，由于当时 PHP 开发者对于程序与材料库之沟通非常不熟悉。

然而，这只是材料分层处理的观念。

理想上我们基本不该对接收下来的材料做假设，如果输入的材料是「许功盖 （BIG5） 」，就让它保持「许功盖 （BIG5） 」；等到要存入材料库时，再让真正的材料操作函数 （或物件） 去处理它 （像是 PDO：：quote ） ，而不是再用 addslashes（） 或 stripslashes（） 这种别扭的方式来存取材料库。

而从材料库取得材料时也是一样，由于我们用正确的方法塞入，所以它也会回传我们正确的材料，这在所有言语都是一样的！

所当前来的 PHP 5.3 版本就将 magic_quotes 废弃， PHP 6 则直接不援助。

而在这之前的版本所开发出来的程序，也都是该以 magic_quotes 保持关闭的形状来开发；遇到不确定 magic_quotes 能否开启时，可以参考官方手册的建议来取消它对程序的影响。

SQL Injection

某网友说：「填‘; shutdown — 就能打挂一票网站…，九成可能都是 PHP 写的」，又说「我知道 SQL （Injection） 是跨言语的问题，但是 PHP 就是偏偏特别容易写出有洞的程序 像这样 “SELECT * FROM User WHERE id = $user_id” 然后就毁了。」

我团体倒认为，有九成以上会有 SQL Injection 问题的，可能是传统的 ASP 网站。 （这边 ASP 只是举例，不表示真的九成以上都是这样；理想上没有援用一个正确的统计数字，这都只是嘴炮而已，请塬谅我用这么粗俗的字眼）