PHP编程中10个最常见的错误
Limit1:324952
Limit10000:32572912
更加糟糕的是,根据php的官方文档,mysql扩展存储查询数据使用的'内存是mysqlnd的两倍,因此原来的代码使用的内存是上面显示的两倍左右。
为了避免此类问题,可以考虑分几次完成查询,减小单次查询数据量:
$totalNumberToFetch=10000;
$portimock=100;
for($i=0;$i<=ceil($totalNumberToFetch/$portionSize);$i++){
$limitFrom=$portionSize*$i;
$res=$connection->query(
"SELECT `x`,`y` FROM `test` LIMIT $limitFrom, $portionSize");
}
联系上面提到的错误4可以看出,在实际的编码过程中,要做到一种平衡,才能既满足功能要求,又能保证性能。
错误6:忽略Unicode/UTF-8问题
php编程中,在处理非ascii字符时,会遇到一些问题,要很小心的去对待,要不然就会错误遍地。举个简单的例子,strlen($name),如果$name包含非ascii字符,那结果就有些出乎意料。在此给出一些建议,尽量避免此类问题:
如果你对unicode和utf-8不是很了解,那么你至少应该了解一些基础。推荐阅读这篇文章。
最好使用mb_*函数来处理字符串,避免使用老的字符串处理函数。这里要确保PHP的“multibyte”扩展已开启。
数据库和表最好使用unicode编码。
知道jason_code函数会转换非ascii字符,但serialize函数不会。
php代码源文件最好使用不含bom的utf-8格式。
在此推荐一篇文章,更详细的介绍了此类问题:UTF-8 Primer for PHP and MySQL
错误7:假定$_POST总是包含POST数据
PHP中的$_POST并非总是包含表单POST提交过来的数据。假设我们通过jQuery.ajax方法向服务器发送了POST请求:
// js
$.ajax({
url:'http://my.site/some/path',
method:'post',
data:JSON.stringify({a:'a',b:'b'}),
contentType:'application/json'
});
注意代码中的 contentType: ‘application/json’ ,我们是以json数据格式来发送的数据。在服务端,我们仅输出$_POST数组:
// php
var_dump($_POST);
你会很惊奇的发现,结果是下面所示:
array(0){}
为什么是这样的结果呢?我们的json数据 {a: ‘a’, b: ‘b’}哪去了呢?
答案就是PHP仅仅解析Content-Type为 application/x-www-form-urlencoded或 multipart/form-data的Http请求。之所以这样是因为历史原因,PHP最初实现$_POST时,最流行的就是上面两种类型。因此虽说现在有些类型(比如application/json)很流行,但PHP中还是没有去实现自动处理。
因为$_POST是全局变量,所以更改$_POST会全局有效。因此对于Content-Type为 application/json的请求,我们需要手工去解析json数据,然后修改$_POST变量。
// php
$_POST=json_decode(file_get_contents('php://input'),true);
此时,我们再去输出$_POST变量,则会得到我们期望的输出:
array(2){["a"]=>string(1)"a"["b"]=>string(1)"b"}
错误8:认为PHP支持字符数据类型
看看下面的代码,猜测下会输出什么:
for($c='a';$c<='z';$c++){
echo$c."\n";
}
如果你的回答是输出’a’到’z’,那么你会惊奇的发现你的回答是错误的。
不错,上面的代码的确会输出’a’到’z’,但除此之外,还会输出’aa’到’yz’。我们来分析下为什么会是这样的结果。
在PHP中不存在char数据类型,只有string类型。明白这点,那么对’z’进行递增操作,结果则为’aa’。对于字符串比较大小,学过C的应该都知道,’aa’是小于’z’的。这也就解释了为何会有上面的输出结果。
如果我们想输出’a’到’z’,下面的实现是一种不错的办法:
for($i=ord('a');$i<=ord('z');$i++){
echochr($i)."\n";
}
或者这样也是OK的:
$letters=range('a','z');
for($i=0;$i
echo$letters[$i]."\n";
}
虽说忽略编码标准不会导致错误或是bug,但遵循一定的编码标准还是很重要的。
没有统一的编码标准会使你的项目出现很多问题。最明显的就是你的项目代码不具有一致性。更坏的地方在于,你的代码将更加难以调试、扩展和维护。这也就意味着你的团队效率会降低,包括做一些很多无意义的劳动。
对于PHP开发者来说,是比较幸运的。因为有PHP编码标准推荐(PSR),由下面5个部分组成:
PSR-0:自动加载标准
PSR-1:基本编码标准
PSR-2:编码风格指南
PSR-3:日志接口标准
PSR-4:自动加载
PSR最初由PHP社区的几个大的团体所创建并遵循。Zend, Drupal, Symfony, Joomla及其它的平台都为此标准做过贡献并遵循这个标准。即使是PEAR,早些年也想让自己成为一个标准,但现在也加入了PSR阵营。
在
某些情况下,使用什么编码标准是无关紧要的,只要你使用一种编码风格并一直坚持使用即可。但是遵循PSR标准不失为一个好办法,除非你有什么特殊的原因要
自己弄一套。现在越来越多的项目都开始使用PSR,大部分的PHP开发者也在使用PSR,因此使用PSR会让新加入你团队的成员更快的熟悉项目,写代码时
也会更加舒适。
错误10:错误使用empty函数
一些PHP开发人员喜欢用empty函数去对变量或表达式做布尔判断,但在某些情况下会让人很困惑。
首先我们来看看PHP中的数组Array和数组对象ArrayObject。看上去好像没什么区别,都是一样的。真的这样吗?
// PHP 5.0 or later:
$array=;
var_dump(empty($array));// outputs bool(true)
$array=newArrayObject;
var_dump(empty($array));// outputs bool(false)