窄多之Blog

最近把一个基于PERL的系统迁移到另一台服务器，本来运作好好的系统，移过去却问题百出。总结下来，有如下问题需要特别注意：

1. 对字符串的处理
   处理之前一定要先确定字符串对象是否存在。注意对变量的判断。
2. DBI查询数据库语句结尾时分号的问题
   在用PHP习惯了给每一个SQL加上一个分号，旧服务器中没出现任何问题，可是新的服务器却提示无法辨认;前后的SQL语句，而无法执行的错误。最好在excute的同时加上die的选择，这样会避免出现恐怖的错误 – 曾经有这样的错误，excute出错，但是$sth->rows依然获取行数，不过不是一行，而是几百万行。
3. 尽量使用公共变量保存系统路径。
4. 还原数据库的时候注意Mysql语句在不同版本间的区别。
5. use strict和eval对调试很有帮助。

今天看到PHP Classes博客上提到的PHP上传GIF文件的安全溢出漏洞，觉得这是一个很严重的问题。就算我们验证了GIF文件的类型和通过getimagesize()验证了GIF文件大小，PHP代码仍有可能被嵌入GIF文件中，就像〈?php readfile(‘/etc/passwd’); ?〉，很有可能被黑客利用。

这是他们提供的解决办法：

1. 利用.htaccess或httpd.conf限制上传文件所在目录执行PHP的权限。

< FilesMatch "\.php$" >
deny from all
< /FilesMatch>

2. 避免直接调用上传的GIF文件。如：src=”image.php?uploaded.gif” mce_src=”image.php?uploaded.gif”。

3. 利用GD模块复制上传的GIF文件。

我的办法是可以设置 Apache，限定refer来自本站的才能调用GIF，就是常规的网站防盗链的办法[ Allow from env=local_ref ]。
总的感觉解决办法让上传GIF文件变得有些碍手碍脚。不知道还有什么其他解决办法。

最近数码相机出了问题，拍不了照片，出现了“FRAME NO. FULL”的错误，很多人并没有留意，看着像错误的提示实际上并不是内存卡出了什么问题，而是照片的编码号已经超过设置的最大值，只要进入设置菜单重新设置，RENEW FRAME NUMBER就可以了。奇怪的是为什么生产厂家不能做得更加人性化一些呢？只是简单的提示错误，对于用户的体验来说比较生硬，完全可以提供更多说明或者是可选择的操作。就像我们平时CODING一样，用户界面的考量越加重视用户的体验和人性化。就像GMAIL后面的男人Paul Buchheit提到的All actions should have ‘undo’，虽然做起来并不容易，但这绝对是用户界面发展的将来趋势。