难道研究PHP的人都是傻瓜吗？
抱怨你的工具，并不会让你的事情做得更好。 我前一篇的「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 只是举例，不表示真的九成以上都是这样；事实上没有引用一个正确的统计数字，这都只是嘴炮而已，请塬谅我用这么粗俗的字眼） |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
