首先，由于我们缺乏对javascript的熟练编写，导致一个应用很多时候都是借助服务器端完成（以下都以PHP为例），也就是说用户的浏览器只是在GET和POST数据，然后渲染HTML，很少用客户端来进行计算和交互，最多只是用来检测下表单的合法性。记得四年前开发一个CMS的时候，用javascript写了大量的代码，至今想起来犹如梦魇。那时对javascript很不了解，用PHP的思维去使用它，造成代码冗长，难以维护，加上自己调试能力不好，每次做bug修复的时候都想告别这个行业。08年初，在使用Drupal这个CMS的时候，意外看到了jQuery这个框架，是内置在Drupal中的，默认自动加载。为了编写好很多ajax应用，啃了几天jquery cookbook，算是入门了，后来也闲置了。最多就是写一些简单的ajax应用和前台效果。前几天看了一本书《jQuery with PHP》，09年10月份出版的，面向的主要读者就是做服务端开发，对前端知识比较少了解的人。200多页比较精简，语言通俗易懂，看完后收获颇多，从书中摘取一些比较有意思的东西分享给大家。（附上个人翻译，有误的地方欢迎拍转）我想这本书是对一个PHP工程师来说，平衡前后端能力，提高产品的用户体验，节省网络带宽，提高应用性能的重要一课。

It would be silly if a 3D screen was generated on the server and was sent to the client 24 times per second. And it would be awkward if you tried to do something like walk through a wall, and had to wait for the server to decide if it was allowed or not.

（这里用网游来比喻前端和后端的关系，很多程序员都玩网游吧！）

如果3D效果的显示数据是在服务端生成后以每秒24次的频率发送给客户端，可想这种设计有多傻。同样，如果你试着做一些很常见的操作，比如准备穿越一道墙，如果这个时候还要等待服务器来判断是否允许的话同样很傻，客户端做这个事情是最合适的。

However, in a pure PHP environment, that’s exactly what has been happening—the server generates absolutely everything that the client displays. If an element needs to be removed from a table, for example, then the server needs to be told, so that it can give the client the new view. If you try to do something illegal, such as submit a blank form where an email address is required, then pure PHP applications will let you do that, wasting time and server resources.

然而，在单独的PHP环境中，服务端产生几乎所有客户端要显示的东西。比如要从一个HTML表格中删除一个元素，必须通知服务器，这样服务端才能生成新的页面发送给客户端。如果你做了一些非法操作，比如没有填写重要的邮件地址就提交了一个空的表单，只有提交后PHP才能知道，这样大大浪费了时间和宝贵的服务器资源。

However, using JavaScript, and especially using Ajax, the client side is no longer a ”dumb terminal” for the server. We can write applications fully on the client side, if we wish, using the server purely as a database. This book will demonstrate ways to work towards that.

花了三天时间看完了《CakePHP Application Development》这本PDF文档，感叹作者的耐心，何奇的淡定。且不说我这个用了PHP做应用5年的人，就算是一个PHP不怎么了解的人估计都能看懂。这本书从头到尾都在案例之后进行分析，我觉得好处在于对初学者来说在cakephp这个框架能打好基础，对cakephp的个方面了解比较透彻。虽然从头到尾300多页感觉如果精简的话可能只有100多页，但是我不认为多余的是废话。只有对技术比较刨根问底的人才能把一门技术写的请清楚楚，让看客们也请清楚楚，明明白白。比起其他一些作者，写出来的东西都是一律而过来得更为实在。

cakephp是基于MVC这个模式来组织代码的，所以此书最重要的三章应该就是分别介绍controller，model和view的三章。早就听说cakephp是ror的php版本，虽然说法有些夸张，但是在cake里面还是能看到很多ror的思想和影子。很多人也说cake的Model实现方式过为复杂，我想只是使用群体不一样，具体的项目具体对待。

这次是因为一个中型项目而让我对cakephp产生要了解的想法。因为虽然php的framework很多，但是不像java阵营那样，php相关的框架大都是毁誉参半的，而且个别流行的框架也没有强大的社区支持。从众多的php框架中我选择了国产的thinkphp，相当于官方的zend framework以及轻量级的codeigiter，最后就是本文主要介绍的cakephp。选择的过程是个纠结的过程，因为框架的选择角度太多了，但从代码风格上来说，我更趋向于cake的代码。仔细研究了下，发现cake做的很人性化，这里人性化的意思是作者很像是个做产品的人，因为从很多地方都体现出了cake的方便和人性化。比如scaffold这个基本功能，在codeigiter里面也有，cake里面只需要在controller里面声明一个scaffold属性就行了，相当简单。

大家都知道，较高的便利性下面都隐藏着大量的命名约定。因为你只有遵守了框架作者的约定和设计思想，你才会得到很大的便利。因为作者在设计的时候，如果考虑使用者各种各样的习惯，设计出来的东西谁都用着不舒服了，只有使用者遵循一定的规则，框架就能带来强大的生产力，这也就是cake的脚本可以跑起来的前提条件。cake拥有一个小型的“shell”，叫做bake，ROR和Djangle都有类似的支持。只要我们在controller，model和views以及数据库设计的时候遵循了cake的命名约定，那么这一些都可以用bake来帮你处理。

我用cakephp建立了一个简单的定餐应用，发现确实像口号中所说那样：rapid development。大概一个下午，就做出了一个成熟的定餐系统应该有的所有功能。这样我就不用羡慕很多java开发者可以使用成熟的框架了，没办法自己对java也挺了解的，为什么就没法在实际应用中应用呢？总觉得太重。

搜索cakephp的时候，在网上看到一些中文资料，但质量都不是很好，强烈建议对cakephp有兴趣的朋友看看这本书，从头到尾没有一个晦涩的单词，通俗易懂。而且后面几章作者通过一个实例小应用配合cake的一些特性进行了说明，这写特性有分页，ajax，认证机制，cookie，session，rss订阅。在这写应用中，cake都显得极为方便。正如那句话：a piece of cake。

本书是面向cakephp新手的书，看完后我觉得还需要对官方文档详细阅读后才能达到用cakephp来开发复杂应用的程度。因为用户群不同，这本书只是介绍了cake的一些基础理论，而了解了这写，使用者可以在官方文档中自助式查询需要的东西。

1, 选择高性能 OS
首先，不难理解，任何一个server最底层的支撑还是OS，而OS的选择，主要包括 Unix, Windows server, Linux, BSD等等。
其中，开源的OS，有Linux, BSD及部分unix。从目前使用情况来看，linux还是网站首选OS之一。

但是，Linux由于其自由的特点，也给选择产生了一些不便 – 发行版太多。
现有的主流版本包括 red hat(RHEL), ubuntu, 红旗, opensuse, debian等。

其中，每一个发行版都有自己的特色，比如RHEL的稳定，ubuntu的易用，红旗的中文支持很棒等。

但要以性能为主，又兼顾稳定，易用性，以上都不是最佳选择。
这里推荐一个发行版，它是一个极限性能，加高度可定制，优化的 Linux – gentoo。

gentoo的性能优化是从kernel源码编译就开始入手了，通过选择不同的源码包，可以适应于不同的应用场景。
(不同内核介绍: http://imkenwu.javaeye.com/blog/168906 )
举个经典的例子：国内，douban.com 在定制优化过的 gentoo 上跑的web服务器最高一天支撑了 2500 万pv。
http://www.dbanotes.net/arch/douban_web_server.html

这种流量，哪怕是提供纯静态的内容，也是很恐怖的。
而支持这种大流量的，除了server本身，最关键的就是高度精简的OS了。
所以，综上所述，高性能网站推荐使用可优化，定制的 gentoo 作为载体。

2, 选择高性能 web server
Apache是 LAMP 架构最核心的 web server， 开源，模块丰富，功能强大，稳定是它的绝对优势。
在美国前100个网站中，有49%的使用apache。可见其影响力。

但是，有利有弊，apache的致命缺陷，就是多于臃肿，强大的功能，一定会带来性能上的损耗。
面对这种情形，在市场上，有一支异军突起，那就是更轻量级的 web server – lighty(lighttpd)。
官方为它定义的口号是 fly light。

它具有非常低的内存开销，cpu占用率低，效能好，以及丰富的模块支持等特点。
这让他在短时间内占据了14%以上的市场份额。并且有越来越多的人开始选择使用lighty作为前端 web server。

到这里为之，其实高性能 web server 非 lighty 莫属。但更棒的是，依靠 gentoo 的高度定制化，我们还可以
进一步提升 lighty 的性能潜力-那就是定制 lighty。

3，选择高性能 database

数据库是任何网站走动态化内容展现及业务数据存储的保障。
市面上的开源数据库主要有 mysql , postgresql , berkeley db, sqlite 等。
其中，对比一下，

mysql ： 多线程，多处理器，高性能，5.0以上支持事务，丰富数据类型和sql语法，跨平台。
postgresql ： 面向对象，集成web，支持事务，使用进程，速度略慢于mysql.
berkeley db ： 嵌入式，数据操作通过接口完成，跨语言。
sqlite ： 与php集成，支持ACID特性，支持大并发量，库锁。

从上面的对比中，不难看出，mysql 应该是性能，稳定性与功能性的综合之选。

4，选择高性能 script language
能与 lighty 结合的脚本语言，主要有 ruby, php, python, perl。方式主要是通过 fast-cgi 来访问。
只从性能角度对比几种语言:

不难看出，python 是此次测试中，性能最好的脚本语言。
动态处理方面有绝对优势。对比 php ， 前者，可以更快的渲染输出内容，并由经lighty， 高速flush缓存到浏览器。
值得一提的是， douban.com 也是使用 python 作为应用服务器。

总结一下，什么是 LLMP？
LLMP 是 Linux Lighty Mysql Python 的组合，作为一种高性能的网站架构设计存在。

什么是高性能的LLMP？
LLMP并不意味着高性能，只是比其他架构，更有性能的提升潜力。高性能的LLMP，需要从系统，程序，硬件各个层面上协同进行的。

推荐给想用eclipse做php开发的朋友，熟练后就不必使用收费的zend studio了。

SQL注入是另一种常见的漏洞（针对XSS来说），是由于对输入数据过滤不严导致的。它不像XSS是直接针对站点的用户，而是直接破坏站点本身，特别是数据库。SQL注入的目的是插入任意数据，常常是插入一条被数据库执行的SQL语句。这些潜伏的被插入语句常常执行很多操作，从获取数据到更改或删除数据库信息。

// supposed input
$name = “ilia’; DELETE FROM users;”;
mysql_query(“SELECT * FROM users WHERE name=’{$name}’”);
这段功能本来是想从user表中获取匹配name字段的数据，一般情况下，name变量是一些字母数字和空白字符的组合，比如字符串“ilia”，但如果我们附加了查询语句，这条注入的查询语句将会删除users表中的所有记录。（幸运的是，mysql的mysql_query函数不允许堆查询，在一次调用中不允许执行多次查询，但是SQLite和postgresql扩展是可以的。

PHP的自动转义机制GPC提供了一些基本保护，如果启用了magic_quotes_gpc，将会对单引，双引等一些字符进行转义（在前面加反斜线）。但是magic quotes不包括所有需要转义的字符，并且这个特性不总是开启的。所以你需要自己用代码来阻止SQL注入。

php的很多数据库扩展有自己专门的转义机制，例如Mysql扩展的mysql_real_escape_string()函数。

if (get_magic_quotes_gpc()) {
  $name = stripslashes($name);
}
$name = mysql_real_escape_string($name);
mysql_query(“SELECT * FROM users WHERE name=’{$name}’”);
在调用数据库扩展的转义机制之前，首先要对magic quotes的状态进行检查，如果magic guotes启用了，则要去掉它可能添加的反斜线，以免输入数据被转义2次。

待续。。。有点累了。

首先，python的性能一直比较争议，而php本身的速度是比java的东西慢，但和db操作起来，肯定是比java的东西快很多了，这算是一个php的优势。并且php的成本较低（LAMP）应该算是很便宜的东东了，而现在支持python的服务器还不是很普遍，对机器要求也较高。下面简单看看语法。

php这种类C的语法是以大括号划分代码块来确定程序逻辑的，而python则是以代码缩进的形式。优缺点都有，缩进自然简化了输入繁琐，有人描述写python程序跟写英文作文一样，虽然这个描述有点夸张，但确实反应了python的优雅语法。唯一比较麻烦的事情就是用惯了类C语法的人对缩进不是很适应，比如我刚用python的时候，程序报错30%是缩进相关的问题，慢慢习惯就好了。下面说说引号，php中有单引和双引，加上dochere语法。单引不解析其内的变量或者转义字符，但是速度较快，所以如果是纯字符串，推荐用单引。而双引会将里面的变量或者转义字符解析后输出。php的dochere语法可以输入较长的字符串，而不用顾及单引和双引的交叉问题，但dochere语法要求较为“严格”，比如必须顶头写，开始标记和结束标记必须相同。而python的三引号语法使用起来很简单，单引和双引则没有区别（这点跟php和java等语言不一样）。

下面看数据类型。别的区别不大，主要是php数组这块，php如果分的比较详细，就是一个数组和关联数组，数组相当于python的列表(list)，关联数组相当于python的字典(dictionary, perl中叫哈希hash)，另外python还有一个tuple（元组），其中的内容和字符串一样是不可变化的。下面看数据处理，php的大部分数据处理都是数组操作，有一大堆以array_开头的函数可提供功能，数组没有负索引，而python的序列相关操作比较方便，功能更强大。php在一些特殊操作平台用-a参数可以使用交互模式，而python也支持交互模式，一些简单计算可以直接使用。

web方面：php的开发框架比较成熟，大都是mysql数据库驱动的。而python目前比较成熟的开发框架不是很多，流行的有zope，django和豆瓣用的Quixote。也不知道豆瓣当时为什么选择后者，可能当时ror和django这些东西还没有吧。

最后说下OO，现在大部分php的产品还是面向过程的，除了使用一些第三方的开源库。php5引入了很多的面向对象特性，对之前的版本来说，面向对象特性就是个鸡肋。而python的模块，OO机制很不错，也是学习的一个重点。

总之，python的特性有很多，学习它一定不会失望。由于本人水平有限的可怜，这个小文章就当是给想接触python的phper们一点动力吧。

Assumption is the enemy of security and making assumptions about user input is a sure way to allow an attacker to subvert your code. 又一次强调开发者的假设所带来的后果。对开发者来说，普遍假设selection box和check box以及radio button和hidden字段值是不用验证的，这就完全错了，
因为恶意用户可以拷贝html表单代码并且修改后来进行恶意提交任意数据。比起黑名单的概念，我们最好还是选择白名单，也就是说我们给出合法的值，然后验证是否合法；而不是给出不合法的值，验证值是否非法。显然后者不如前者来得安全。这里作者给出一个例子，说明了这个问题：
$months = array(“January”, “February”, /* … */);
if (empty($_POST[‘month’]) || !in_array($_POST[‘month’], $months)) {
   exit(“Quit hacking, you’re not a lumberjack!”);
}

关于文件上传：如果你的应用程序不会使用到文件上传的特性，你可以编辑php.ini文件来禁止文件上传。
file_uploads=off
upload_max_filesize指令可以控制上传的单个文件最大值，以字节为单位。默认值为2M
post_max_size指令限制了当表单以POST方式提交的数据大小。通常情况下，这个值我们应该设置地比上面那个file_uploads稍微大一点点。如果你可能用到多文件上传，根据需要自行调整。默认值为8M。

(待补充。。。)

前言和介绍就略过不翻译了，作者描述了一下PHP安全的重要性，以及为何变得如此重要。我想目前线上的很多php站点遭到攻击和破坏足以说明这点了，我们直接来看第一章Input Validation。今天先写前半章吧。（一章内容太多，本人英文比较菜，看完需要差不多3个小时）

该次翻译的内容列表：

1. The Trouble with Input. （输入的问题）
2. The Constant Solution （常量解决方案）
3. The $_QEGUEST Trojan Horse （$_REQUEST木马）
4. Validating Input （输入验证）
5. Validating Numeric Data （数字验证）
6. Locale Troubles （Locale问题）
7. String Validation （字符串验证）
8. Content Size Validation （内容长度验证）

这章简介中作者用斜体标注出了这么一句话：It is absolutely imperative to validate all user input to ensure it matches the expected form.
为了确保数据是我们期望的，必须验证所有的用户输入，即那句话：“永远不要信任外部数据”。

紧接着作者讲解了magic quotes gpc出现的历史，跟早起的版本相比较，是简化了开发者的工作，也增加了安全性。因为对外部来的数据不再对来源污染了，我们可以很清楚的知道数据的来源。这里作者给出一个例子：

if (is_authorized_user())
define(‘auth’, TRUE);
if (auth) // will always be true, either Boolean(TRUE) or String(“auth”)
/* display content intended only for authorized users */
为了“安全”，该程序将auth这个值设置为常量，避免数据污染和没有初始化带来的数据覆盖。但是，PHP中对于一个字符串，如果没有用引号包含起来，会当作常量处理，如果没有这个常量，将作为字符串处理。所以这里的auth放在if语句中就算没有define，也是成立的，因为他是一个字符串。这时只会给出一个notice的错误，不影响程序的执行，并且一般上线的站点，都会把display_errors关掉，根本不会提示。这里作者顺带提及了一个变量覆盖的问题，gpc_order指令可以设置优先级。并给出一个原则：尽量对所有变量进行初始化。

接下来，Validating Numeric Data这个小节说明对数字进行验证和处理最好的办法就是用int或float进行强制转换，比如：

$_GET[‘product_id’] = (int) $_GET[‘product_id’];
$_GET[‘price’] = (float) $_GET[‘price’];

这里注意一点，如果我们用is_numeric函数对8进制数字进行判断时，不一定返回的就是我们需要的结果。is_numeric(“0955”);返回的是true，但显然这不是一个有效的8进制数值。

接着作者说明了local对验证的影响，这里不再详述，只要使用setlocale语法就可以了。

关于字符串的验证，一般使用的是ctype类函数，不过这些函数局限性也很大，比如认为－，空格等字符是非法的，再加上ctype是一个独立的扩展，有可能服务器上并没有安装该扩展或者被屏蔽，而且只能用在单字节字符集，所以最好的替代方案就是使用正则表达式（比如ereg函数）。Alas, regular expressions aren’t exceptionally fast and validating large strings of data may take noticeable amount of time. But, safety must come first. 正则表达式不是特别快，当对比较长的字符串数据进行验证的时候，会占用很明显不少的时间。但是，安全第一。

这篇文章最后，说下内容长度验证的问题：

表单中，只有text和password类型的控件可以使用maxlength属性设置最大长度，如果我们想在textarea中限制长度，可以使用下面这小段js做到。

<form onSubmit=”if (this.biography.value.length > 255) {
alert(‘Keep it short, eh?’)
return false;
}”>
<textarea name=”biography”></textarea><input type=”submit”>
</form>
提交表单时候，用javascript判断这个textarea的长度是否大于255。不过任何form中的限制和js做的限制都不是一劳永逸的，If JavaScript and HTML can be circumvented, server-side PHP provides the real stopgap.

$form_fields = array(“Fname”=>50, “Lname”=>100, “Address”=>255, /* . . . */);
foreach ($form_fields as $k => $v)
if (!empty($_POST[$k]) && strlen($_POST[$k]) > $v)
exit(“{$k} is longer then the allowed {$v} byte length.”);
必须用服务器端脚本进行验证，比如上述php代码则可以完成。

此外，如果你是一个对效率要求很苛刻的人，strlen会觉得影响速度，没关系，可以试试下面这个方法：

$form_fields = array(“Fname”=>50, “Lname”=>100, “Address”=>255, /* . . . */);
foreach ($form_fields as $k => $v) {
if (!empty($_POST[$k]) && isset($_POST[$k]{$v + 1})) {
exit(“{$k} is longer then the allowed {$v} byte length.”);
}
}
在PHP4.3.10后，可以对字符串使用isset控制，Because isset() is a language construct, it’s converted to a single instruction by Zend’s PHP parser and takes virtually no time to execute. 因为isset是一个语言结构，这样会加快执行的速度。似乎有点吹毛求疵，不过这正是我们狼族小四此等人的目的:-）

今天先写到这里吧，可能翻译整理得比较笼统，剩下的东西大都是解释型的句子，我想大部分人都很了解了吧。

昨天抓取一个页面的时候，发现了一个有点bt的页面。里面的标点符号都替换成了图片，就是为了防止批量复制粘贴，因为这样粘贴进来的文章没有标点符号可想而知有多痛苦了。不过难不倒我们。

虽然每个文章的标点符号是用程序随即生成图片名称的，也就是说每个图片的名字都不一样，但我们可以肯定同样的标点符号（比如逗号）图片的md5值肯定是一样的，可以测试下：
<?php
copy(‘http://www.target.com/article1/comma54321.gif’, ‘pic1.gif ‘);
copy(‘http://www.target.com/article2/comma12345.gif’, ‘pic2.gif’);
echo md5_file(‘pic1.gif’), ‘<br />’, md5_file(‘pic2.gif’);
?>

可以看出不同文章里面的相同标点符号图片md5值是一样的，这样我们就可以在抓取程序中定义一个数组，用来做替换。
<?php
$replace_into = array(
  ‘md5_1′ => ‘，’,
  ‘md5_2′ => ‘。’,
  ‘md5_3′ => ‘、’,
);
if (array_key_exists(md5_file(‘url’), $replace_into)) {
  // do replacing str…
}
?>

这样抓取出来的东西则把图片替换为了我们想要的中文标点符号。问题解决。

此外，碰到一些有规则的图片，我们可以利用seq和shell知识做出一个下载器，下载下来进行分析。
#!/bin/bash
for  i in `seq -w 1 100` do  
wget -c "http://www.target.com/images/file_$i.gif"
done

1. 安装 memcached。

2. 在 php.ini 中设置：

session.save_handler = memcache
session.save_path = "tcp://127.0.0.1:11211"

或者某个目录下的 .htaccess ：

php_value session.save_handler "memcache"
php_value session.save_path  "tcp://127.0.0.1:11211"

再或者在某个一个应用中：

ini_set("session.save_handler", "memcache");
ini_set("session.save_path", "tcp://127.0.0.1:11211");

使用多个 memcached server 时用逗号”,”隔开，并且和 Memcache::addServer() 文档中说明的一样，可以带额外的参数”persistent”、”weight”、”timeout”、”retry_interval” 等等，类似这样的：”tcp://host1:port1?persistent=1&weight=2,tcp://host2:port2″ 。

3. 启动 memcached：

memcached -d -l 127.0.0.1 -p 11212 -m 128

4. 在程序中使用 memcache 来作 session 存储，用例子测试一下：

<?php
session_start();
if (!isset($_SESSION['TEST'])) {
    $_SESSION['TEST'] = time();
}

$_SESSION['TEST3'] = time();

print $_SESSION['TEST'];
print "<br><br>";
print $_SESSION['TEST3'];
print "<br><br>";
print session_id();
?>

5. 用 sessionid 去 memcached 里查询一下：

<?php
$memcache = memcache_connect('localhost', 11211);
var_dump($memcache->get('19216821213c65cedec65b0883238c278eeb573e077'));
?>

会有看到

string(37) "TEST|i:1177556731;TEST3|i:1177556881;"

这样的输出，证明 session 正常工作。

用 memcache 来存储 session 在读写速度上会比 files 时快很多，而且在多个服务器需要共用 session 时会比较方便，将这些服务器都配置成使用同一组 memcached 服务器就可以，减少了额外的工作量。缺点是 session 数据都保存在 memory 中，持久化方面有所欠缺，但对 session 数据来说也不是很大的问题。

另外，WS Memcached Session Handler for PHP 提供一种用 session_set_save_handler 来利用 memcached 的方法。