这份教程是由WordPress啦!的小雯子编写，站长百科的大漠孤狼制作的，我参与了审核校对工作。
本文档是WordPress主题制作的入门指导，详细分析了WordPress主题的每个文件，并对常用的函数使用参数做了详细的介绍。只要您具有基本的html及css知识，通过学习本文档就可以掌握WordPress主题的制作了。
下载地址： http://doc.zzbaike.com/wordpress/book/wordpress-themes.pdf
这是金步国先生翻译的同名文档的PDF版，方便大家打印和阅读。
这个IP-国家查询库使用Webnet77整理的数据，包含了9万多个IP段，在免费数据中是最完整的了（原地址）。我把它转换成了MySQL数据表，同时加入了中文国家名。
使用时，先把SQL文件导入数据库。数据库有点大，完整大小8390KB，压缩后1.19MB，如果你无法一次性导入这么大的数据，可以考虑使用一些导入工具，比如Bigdump。
查询时，先用ip2long()函数把xxx.xxx.xxx.xxx形式的IP（标准地址）转换成int数据（IPv4地址），然后执行查询：
$query = “SELECT * FROM iptocountry WHERE lower_bound <= $ip AND upper_bound >= $ip”;
详细代码就不写了，大致就是上面的那个意思。
Zend_Filter_Input默认会给所有通过的数据添加一个HtmlEntities的过滤器。不幸的是，这个HtmlEntities使用的是ISO-8859-1编码，如果你使用的是GB2312或者UTF-8一类的编码，那中文字符就惨了，乱码无疑。
想要避开这个问题，就不能再用$input->field的方式访问数据了，要用$input->getUnescaped(‘field’)的方式，这样会忽略掉默认的HtmlEntities过滤器。如果你仍然喜欢用$input->field的方式，往下看：
一个简单的解决方法是直接去改Zend/Filter/HtmlEntities.php文件，把构造函数（public function __construct($quoteStyle = ENT_COMPAT, $charSet = ‘ISO-8859-1’)）里第二个参数的默认值改成你的网站使用的编码。
这个方法还有一个额外的好处，以后当你使用HtmlEntities时也无需再指定编码了。虽然通常不鼓励直接修改Zend Framework的源文件，但是这一点小小的改动不会有什么英系那个。唯一的弊端就是每次升级Zend Framework时必须再改一次。
另一个方法是用别的过滤器替换掉默认的HtmlEntities过滤器。你可以使用其他的标准过滤器，比如StringTrim；也可以模仿HtmlEntities写个你自己的html转移过滤器，用上你自己的网站编码；还可以创建一个空过滤器，不进行任何过滤。然后在实例化Zend_Filter_Input时这样写：
$myFilter);
$input = new Zend_Filter_Input($filters, $validators, $data, $options);
?>
或者：
setDefaultEscapeFilter($myFilter);
?>
大功告成！
在支付宝UED博客上看到了老鱼的“浅谈产品设计中的可用性和可访问性”。全文中心思想是“国内大部分Web产品在设计时往往忽略可用性和可访问性问题”，对于这点我基本上是认同的，但是对于文章里举的例子，一个“支付宝登录界面如果禁用JS就无法正常工作”的例子，也就是一个“预留退路”的例子，我有话要说。
“预留退路”这个概念我最早是从《网站重构》上看到的，简单来说，预留退路是指当访问者禁用CSS或JavaScript时，网页仍然能正常显示内容。当时对这个概念印象深刻，并且在之后一段时间内也一直以此为标杆。但随着对互联网、对web的理解越来越深，随着项目开发越做越多，我逐渐开始动摇。不可否认，“预留退路”在安全性方面是十分必须的，服务器端必须把好最后一道关，不能相信客户端、不能相信任何用户输入。但在用户体验方面，在可用行方面，我认为预留退路的重要性远不如许多UE设计师们声称的那么重要。
首先，目前的网站，已经不再是以前那种“网页文档”的集合了。以前的网页的主体是内容，单向性很强。JS等交互功能只是内容上的调料。而现在大量兴起的web应用，已经把网站推向了“软件”的境界。浏览器只是一个容器，网页只是一种呈现方式，交互才是真正的重头戏。虽然交互的目的仍然是内容，但这里的内容已不再是传统意义上的html代码，而是数据，交互是获得数据的必经手段，缺少交互，数据（内容）无从谈起。在这种情况下，预留退路显然不是一条不可打破的禁忌。
其次，预留退路的提出是在浏览器大战的年代。在那个时候，主流浏览器对JS的支持十分混乱，保证一个网站在所有浏览器上都做出正常的表现很难。开发者们在恶劣的开发环境下学会了自我约束，限制js的使用，预留退路作为下策，以防万一。而在现在，web标准日趋普及，浏览器们的支持标准也渐渐统一，跨浏览器平台的交互功能实现将越来越简单。虽然移动设备那边可能还不是很完善，但统一的标准必然是未来的趋势。
最后，尽管如老鱼所说，“很多交互设计师都会想当然的认为，类似这样的应用场景受重群体是很小的，也许真实的数据会让你大吃一惊！”，可我至今没有见过实际的统计数据。我身边有用Opera的，有用Linux的，可至今没有禁用JS上网的。倒是在豆瓣上见过一个，不过他是个Geek，关闭JS是有他自己的目的的，并且他也很清楚这样做的后果。相信那些不开JS上网的人，大部分都是像这个豆瓣用户那样的中高级用户，他们很清楚自己在做什么，以及这样做之后可能会遇到的情况。而预留退路真正需要照顾到的，那些无法使用JS自己却一无所知的无助的用户们，我绝不认为其总量会是个“让人大吃一惊”的数字。
综上，我认为“预留退路”不是个应该鼓吹的概念，更不是个不可打破的标准。中国没有408条例，所以更多的时候要根据实际需要来抉择，不要一味迷信传统。
最后，感谢土豆网的Dexter.YY，您的回信让我受益匪浅。
if (mb_strlen($string, $encoding) != strlen($string)) {} //字符串中包含汉字
请阅读手册，Multibyte String函数里还有更多惊喜。