趁这两天闲来无事，把《IT技术博客大学习》网站弄成UTF-8了，了却了心中一大遗憾。

    网站地址：http://blogread.cn/it/，欢迎观赏。

    博客导航：http://blogread.cn/，这个网站之前做了一个可以提交网站的功能，昨天看了一下，尽然真有人提交了，好久不看，怠慢人家了。。。顺手做了一个一有人提交就给我发信的功能，相信以后不会怠慢了。对不起啊。。。。。。。

    另：此博令本站不再长草。。。。。。。。

     有一个传奇，一个网吧管理员做了一个极其简单的网站，由于迎合了初期网吧上网用户的需求，最终成为一个互联网的重要入口，并在2004年8月，被百度以1190万元和4万股股票收购，经济收入颇丰。这个网站就是李兴平做的hao123.com。即使现在看来，它也是如此的简陋，但这并不影响他的价值 -- 用户认可它。就这么一个网站把“更懂中文”的百度自己的导航网站：site.baidu.com 硬生生的压制了下去（注1）。

    在hao123.com之后，蔡文胜在03年建立的265.com 于08年5月被谷歌正式收购，而之前的一年它们绯闻不断:）（注2）。你可以看到谷歌首页左上角的网址导航地址daohang.google.cn早已被“265导航”取代，这让谷歌的技术大牛们情何以堪:）。

    传奇永远激励后人，这不近期就有传言史玉柱联手红杉欲购2345.com（注3）。甚至“123”这样的后缀都成了流行，如淘宝的tao123.com、采购行业的caigou123.com。

    本身是互联网入口的两个搜索引擎巨头耗巨资、舍弃自己产品收购另一个互联网入口 -- 网址导航网站，多少有点怪异，但无他，流量为王！虽然中国互联网的用户在不断增加，但低端网民的需求是很简单的，而鼠标远比键盘操作简单，网址导航网站比搜索网站门槛更低。

    我们可以通过艾瑞近五年的调研结果看看：

    1：2006-12-26。导航类网站的网民覆盖人数已经超过5700万，占中国全体网民人数的一半（注4）。

    2：2007-08-26。2007年7月，网站导航类网站月度覆盖人数为6141万人，占全体网民的一半左右，在所有网站类别中排名第九。而人均月度访问次数达24.5次，在所有网站类别中排名第三，仅次于综合门户和搜索引擎，人均月度访问天数也以9.1天紧随综合门户及搜索引擎，排在第三位，用户黏性明显高于其他类别网站（注5）。

    3：2010年9月。2010年8月中国互联网网民中，六成以上访问导航网站。数据显示，2010年8月，中国访问导航网站的互联网用户规模达到2.3亿元，占所有网站访问用户规模的62.5%。2010年4月，该比重最高达到66.4%（注6）。

    现在，这是一个用户达2.3亿的市场！事实上我们也看到，至今仍有大量的网址导航网站通过各种手段在努力占据着用户的首页，如114la.com、2345.com、9991.com、ai1234.com。

    在互联网上还一个词叫“内容为王”，在Web1.0门户时代这个词风靡一时，随后大量垂直门户出现，悄无声息的扩张，如pcpop.com，还有一些行业性的网站，闷声发大财，上网一搜“行业门户”即可知道。

    这些，让一些人看到了曙光，垂直类的网址导航网站出现了。

    从2005年开始，博客在中国风生水起，虽然博客服务提供商（如新浪、搜狐、blogbus）都提供了推荐博文、博客排行的功能。但是跨服务提供商的推荐和排行限于行业竞争一直是个空白，更重要的是，越来越多的优秀博主拥有自己的独立博客（即有自己的独立顶级域名）。这些的优秀博主进入我们的视野更多是凭借口碑、小圈子内的传播。

    于是，或者似乎，博客网址导航网站有了存在的价值。

    从目前yayu看到的，有博客导航性质的站点有以下几类：
    1：RSS订阅查看网站。如Google Reader、抓虾、鲜果等。坊间有讨论这种类型已经在没落了（注7）。
    2：博客digg网站。如垦一垦、糖果盒，这些都是模仿国外StumbleUpon这个猎奇服务网站的。
    3：纯粹的博客网址导航。

    本文主要说说第三类：博客网址导航 -- 博客导航。对这些网站我们可以通过在Google、baidu中搜索“博客导航”中找到，这方面的网站不多，目前还是小众领域。两个搜索引擎前两页的网站重合率还是挺高的，我们可以从中分析其中的特点。

    1：各大网址导航网站的下属博客分类。

    比如：114la.com和265.com均有这类服务。由于这类网站名气大，对个人博客直接忽略，列举出的都是各大博客服务提供商。

    2：专业博客导航垂直网站。这类是下面要重点说的。

    这个领域是小网站的战斗场，互联网巨头们都忽略这个领域，因为这里实在是太草根了。哪个大公司会为了这么一个小众领域而耗费精力去收集、甄别优秀个人博客呢？

    细看这下，专业博客导航网站对博客的分类主要有两类：

    1：地域分类。如：93blog.com等

    顾名思义，这类导航网站把博主分省市罗列，不得不佩服这类站长的毅力，从哪花功夫去获取这些偏隐私的信息呢？

    2：内容分类。如：oolog.org、blogread.cn等

    这个就是按照博主写的领域来分类了。如情感、技术、旅游、商业等等。

    为了获取用户，博客导航网站除了提供导航服务外，还有诸多附加服务：

    1：博客网址提交。由站长一个人或团队维护、甄别这么多的博客是个苦力活，所以基本上都会提供用户提交博客网址，然后站长后台审核的功能。这样如果站点流量大，用户活跃度高，可以帮助站长从内容收集的烦恼中脱离出来。对用户而言，也增加了亲切感。

    2：收藏夹。在网站上收藏你喜欢的博客。

    3：邮箱登陆。用户可以在博客导航网站直接登录你的邮箱，如网易、新浪等。

    4：天气显示。智能的显示你所在地区的天气。

    5：搜索功能。提供baidu、Google的搜索服务，省去打开一个新浏览器进入搜索网站的时间。

    6：实用工具。主要是站长使用的，独立博客站长使用得比较多。如SEO信息、网站alex排名查询、IP查询等等。基本上都是链接到其他专业网站上的。

    为什么会有以上额外的服务呢？根据艾瑞资源在2010年10月发布的《2010年8月中国六成以上互联网网民访问导航网站》我们可以看到（注6）：

    艾瑞咨询分析认为，超过六成的互联网网民使用导航网站，原因在于导航网站集合了搜索、邮箱、新闻、购物、游戏、视频等多方面的互联网应用，用户能够一站式、快速获取相关服务。同时，由于庞大的用户规模，导航网站也成为各垂直行业网站（尤其是行业内第二、三梯队网站）流量导入的重要途径。

    以上虽然指的是综合导航网站，但同样可用于垂直导航网站。归根结底，这些服务都是为了留住回头客，而上述艾瑞分析的最后一句话，最指出导航网站的价值 -- 各垂直行业网站流量的重要来源。而博客导航网站也有望给优秀的个人博客带来流量。从目前博客导航网站的现状看，要做到这一点，仍需努力。

    基本上，一个网站做得再好，如果运营、推广不力，只能自生自灭。而这正是目前博客导航网站的软肋之一，综合导航网站旗下的博客导航聚焦在博客服务提供商，对个人博客关注度为零。垂直博客导航网站基本都是个人或小团队在做，推广主要依赖搜索引擎，难以占领用户浏览器。

    软肋之二是页面简陋，甚至内容缺失。yayu发现有的网站一些站内主链接打开后看到的是一个模板页，内容几乎没有。难以想象这是怎么在搜索引擎中排列在前的？！更无语的是某花钱在搜索网站推广的博客导航网站，在导航中写的是博客导航，但其实却是综合分类导航，完全是下载了某模板，换汤不换药，真是良莠不齐！

    或许依赖知名博客的介绍可以促进推广。搜索“博客导航”，有一个网站依赖也一个简单的页面、一个单一的博文页也排列到了第一页。这就是知名博客主“和菜头”的“中文博客导航”，甚至有网友发帖说写博客能写到这种程度真令人嫉妒到死:）

    即使吸引不了知名博客的友链，从目前看还可以通过博友互链。一些博客导航网站所提供的博客收录准则就明确指明：博主自己先做链接，然后经过查看访问来源后就可以收录。门槛较低，但与公信力违背，也算是双刃剑吧。

    能持续观察到行业中一个领域的发展也是幸事，不知道博客导航这个领域是否能风生水起，期待之!

注1：百度百科 - hao123。http://baike.baidu.com/view/8424.htm#4
注2：百度百科 - 265。http://baike.baidu.com/view/292091.htm
注3：史玉柱联手红杉欲购2345网址导航。http://www.yicai.com/news/2010/10/582241.html
注4：导航网站价值新说――贴近新网民服务老用户。http://www.iresearch.com.cn/Report/View.aspx?Newsid=58790
注5：网址导航网站用户具有高黏性。http://www.iresearch.com.cn/Report/View.aspx?Newsid=69267
注6：2010年8月中国六成以上互联网网民访问导航网站。http://www.iresearch.com.cn/Report/View.aspx?Newsid=125684
注7：《RSS阅读时代的没落 》http://www.xjp.cc/2010-log/10/disgraced-rss-reader.html

    验证码，一个对用户毫无价值，但对网站却是一个自我保护的屏障。

    通常，验证码出现在提交表单的情况下，用于网站判断数据提交方是正常用户还是机器人。

    比如：

        1：在新用户的注册流程。可以用来遏制恶意注册。
        2：用户密码取回流程。可以用来防止用户密码被恶意夺取。
        3：用户登录。一般出现在多次密码输入错误，可以用来防刷密码。
        4：文章评论。可以防止广告等信息的传播。
        ......

    从产品上看，以上流程，对用户体验而言，让用户输入验证码，无疑是在骚扰用户。毕竟，恶意行为在独立用户、独立ip中是少数。这样的产品设计是让99个用户为1个用户的恶意行为买单。

    但是从技术上看，以上流程让验证码的存在却是有价值的。尤其是用户行为分析机制尚未建立时，因为我们无法预知对用户的行为。

    不要相信任何用户提交的数据。这一准则深深影响着程序员，我们对用户的提交的数据进行各种校验：是否符合产品上在页面规定的内容？是否符合数据库存储字段的属性？数据输入时是否会含有SQL注入的风险？数据输出时是否会影响页面的正常显示？数据中是否含有敏感词让某些人不高兴？

    这一切对正常用户而言，均不是问题。但是对于少部分用户，比如好奇心强的技术性用户，甚至想从中得取不正当利益的利益团体。真正有威胁的是后者。而验证码就是双方攻防的重要阵地，所谓刀光剑影尽在于此。

    基于以上讨论，我们是迫不得已在我们认为需要阻止恶意行为的地方加入验证码。这主要是一个技术问题，产品上是一个被迫的选择。

    但现在，似乎，在有表单提交的地方，验证码就成了标配。从以上的分析中，其实并不是每个地方都有必要出现验证码。只有在那种技术上、产品上难以控制恶意行为的地方才需要。

    一个比较典型的是：公司内网的登录为什么需要验证码？输入一次错误密码就是显示验证码的理由？尤其是那种半个小时不操作就要登录的系统，真是恶心的不行。半个小时不操作就让输入密码，本已很恶心，更恶心的是，这么频繁的操作偶尔输错一次密码还让输入验证码，真是恶心之极。

    言归正传，我们谈谈其它避免出现验证码的场景。

    一个登录后的用户，在进行操作时是否需要显示验证码？一个用户能登录，说明他通过了两个流程：注册、登录。以上我们谈到，这两个流程我们都是有必要用验证码来遏制恶意行为的。用户能正常登录，在很大程度上说明他不是一个恶意行为者。当然，不排除有恶意行为的可能，毕竟道高一尺，魔高一丈。这个时候就有必要考虑，是否为1个用户而为难99个用户了。

    我认为是没有必要的。如果一定要考虑，我们可以变通的实现，以缓解用户对验证码的厌恶，毕竟验证码对用户是毫无具体意义的。

    我们分场景讨论一下。我们把用户提交的信息分为两类：

        1：影响用户自己。
        2：影响其他用户。

    对于影响用户自己的操作，如修改密码、用户信息。这些信息有的只是用户的一条数据而已，如昵称、生日等；有的是需要网站付出资源的，比如绑定一个由网站方提供的邮箱、需要费劲心思保护的商务信息（某某币等）、用户敏感信息（密码、密保信息）等等。对于前者，用户任意改，其实无所谓，对于后者，就需要我们注意对用户进行保护了，比如用户被恶意侵入怎么办?这个时候验证码是否该出现呢？不应该！这个时候应该让用户输入自己的密码。这样既避免用户对验证码的厌恶感，又提高了安全性，夸大一点说：提高网站的品牌形象，用户一看：哇，这网站在保护我的信息。

    对于会影响其他用户的信息，如论坛的主题贴和回帖，博客、新闻的评论。如果这些地方显示验证码，从产品上让用户感觉不易用。但之前所说，道高一尺魔高一丈，如何遏制潜在的恶意行为？对这些产品而言，可使用的产品手段则比较多了。对于新注册的用户，很多网站都会禁言一段时间，但是这样也使正常用户感觉不爽，不利于网站推广。此时我认为可以采取产品手段：用户的注册时间、之前的活动量都是一个是否显示验证码的依据。对于可信赖的用户是无需使用验证码的！比如有些论坛就是积分大于某一值时就可以不显示验证码，当然对于这些用户的恶意行为的惩罚就是另一回事了。

    总而言之，验证码是技术人员无奈的选择，产品上能不用就不用，敬而远之！

    与xargs命令最初相识是在发现一个磁盘满了，具体是在/var/spool/clientmqueue，主要原因是系统中有用户开启了crontab，而crontab中执行的程序有输出内容，输出内容会以邮件形式发给cron的用户，而sendmail没有启动所以就产生了这些文件。关于更详细的原理，可以参考我之前的文章：crontab命令的使用介绍及我的体会。

    仅仅解决出现多文件的方法比较简单，在命令后加上“> /dev/null 2>&1”即可，表示程序员输出和运行错误都放到黑洞里面去，这样就不会产生文件了。

    如果是要解决删除多文件的问题，则进入这个文件夹，执行“ls | xargs rm -f ”即可。xargs可以从管道中循环读取文件，一次一次的把信息输送给后面的“rm -f”。

    请注意以上措辞：“一次一次的”，那么这个一次一次，是指“一个一个”还是“一批一批”呢？

    很杯具，当时不求甚解，未能深入学习xargs，误解为“一个一个”。

    最近在写一个程序时，需要处理一个文件中的行数据。平时都是使用php的fopen再fgets解决问题，但这次懒得套用这一套了，于是想使用管道把数据传送给php脚本。

    而php脚本也利用$argv这个数组来获取命令行输入的参数，那么很简单的，获取$argv[1]，就可以了。如“php a.php b”，$argv[0]为文件名a.php，$argv[1]就是后面的参数b了。于是想当然的：cat uid.txt | xargs php a.php 。

    最终发现，uid.txt中有近4千行的数据，但是只处理了4行。那么，既然出现问题就边解决边学习吧！

    使用：cat uid.txt | xargs echo > file.out

    发现 file.out文件果然就是四行，但是每行都很长。。。。。

    如下，uid.txt内容为：（“......”表示很多行）

    那么file.out的结果为：

    所以，程序处理每一行的第一个了，剩下的全部被忽略。而我期望的结果是xargs每次给我一行。

    那么寻求man的帮助吧：

    首先看-s参数，它提示说每次的输出不能超过131072 bytes，从结果上看上去它每次都往最大的值释放数据。再看-n参数，提示我们可以使用这个参数指定每次从源文件中取几行数据，那么OK，搞定了！如下：cat uid.txt | xargs -n 1 php a.php。问题解决。

    更进一步的：

    1：其实每个系统对于参数列表的大小都有限制。比如ARG_MAX一般至少定义为4096 bytes。如果超过了ARG_MAX，将产生shell错误：Argument list too lang，这个问题可以用上面说的xargs命令解决问题。

    2：xargs的-s参数，根据实战的结果，貌似会在指定的值和真实数据中取得平衡，不会只依据-s指定的大小活生生的把源数据的一行撕裂成两行。

    之前做RSS输出的程序时，用"<![CDATA[内容]]>"解决了description节点文章内容的老断点的问题。当时不甚其解，也没花时间弄明白它的原理。

    今天继续学习了一下XML的基础格式，豁然开朗。

    每种数据格式，如果要被广泛推广，被多种解析器能理解，必需要有其特定的格式，就如语法一般。

    虽然XML 和 HTML 为不同的目的而设计：

    但在语法上，两者有相似之处，HTML的标签都是放在“<”和“>”之间，XML也是如此。如在 XML 文档中放置了一个类似 "<" 字符，那么这个文档会产生一个错误，这是因为解析器会把它解释为新元素的开始。

    而一般文章的内容可能包含意想不到的特殊字符，尤其是技术博客。那么为了避免此类错误，XML要求我们把字符 "<" 替换为实体引用，如：

    而不是

    那什么是实体引用呢，如下：

    注释：严格地讲，在 XML 中仅有字符 "<"和"&" 是非法的。省略号、引号和大于号是合法的，但是把它们替换为实体引用是个好的习惯。

    所以在文章内容输出的时候，做一次htmlspecialchars处理是很有必要的。

    除了使用htmlspecialchars处理以外，XML还为我们提供了一个特殊的标签：CDATA 区段（CDATA section）中的文本会被解析器忽略。所谓被解析器忽略并不是舍弃内容，而是忽略中间的内容，不然中间的内容影响XML的格式。

    CDATA 区段开始于 "<![CDATA["，结束于 "]]>"：

    在上面的例子中，在 CDATA 区段中的所有东西都会被解析器忽略。

    特别注意：

    1：CDATA 区段不能包含字符串 "]]>"，所以，CDATA 区段的嵌套是不被允许的。
    2：同时也需要确保在 "]]>" 字符串中没有空格或折行。

    请参考：http://www.w3school.com.cn/xml/xml_cdata.asp

    首先看代码：

    杯具了，这句话有语法错误：

    那么，这是为什么呢？

    查看手中的手册，没发现有解释，查看官方文档：http://www.php.net/manual/en/language.oop5.properties.php，如下：

    如红色字体，翻译如下:

    呃，翻译的有点拗口。简而言之，就是说类里面变量的初始化不能是一个表达式，否则编译期间就编译不过去，产生不了Opcodes。

    手册中给出错误和正确的初始化的例子：

    关于Opcodes和编译的过程，可以参考以下资料：

    说句题外话:

    据说，现在PHP官网没有提供中文文档入口，是因为中文文档没人维护的原因，杯具！：http://opensource.solidot.org/article.pl?sid=08/04/22/2359251

    不过随便进入文档任意语言页面，切换语言中选 "Other"，还是可以进入中文文档的。

    find命令很强大，但没有遇到大量文件时，没想到它是如此的高效，真有一种想干掉ls命令的感觉：

    里面大约有16288个文件。

    看来ls只能是作为一个日常的工具使用，只是find命令是基于什么样的原理才能怎么快呢？上网只找到一个不错的使用解说：《Linux Find 命令精通指南》。共享一下！

    在数据库设计和程序中需要考虑数字的范围，否则可能导致一些问题。主要是考虑溢出的问题，比如如果数据库中有一个整型的数字字段，里面的数据可能随着业务的增长而膨胀，而这个数字有可能会超出列属性的范围，也就是溢出，与此同时，程序中也需要处理这个日益庞大的数字，如果其中有运算、数字类型的逻辑比较等等，也可能导致某天就出现了异常。而这种错误又是难以发现的。

    以下试以整型（int）抛砖引玉：

    一：MySQL5

    以MySQL5版本为例，大多数管理员可能把自增数字、或者其它应用数字字段的列属性设置为int类型，int占用4个字节，而int又分为无符号型和有符号性。对于无符号型的范围是0 到 4294967295；有符号型的范围是-2147483648 到 2147483647。参考资料可见mysql手册：11.2. 数值类型.

    当要在一个数值列内保存一个超出该列允许范围的值时，MySQL的操作取决于此时有效的SQL模式。如果模式未设置，MySQL将值裁剪到范围的相应端点，并保存裁减好的值。但是，如果模式设置为traditional(“严格模式”)，超出范围的值将被拒绝并提示错误，并且根据SQL标准插入会失败。请参见mysql手册5.3.2节：“SQL服务器模式”。

    如果INT列是UNSIGNED，列范围的大小相同，但其端点会变为到0和4294967295。如果你试图保存-9999999999和9999999999，以非严格模式保存到列中的值是0和4294967296。

    如果在浮点或定点列中分配的值超过指定(或默认)精度和标度规定的范围，MySQL以非严格模式保存表示范围相应端点的值。

    当MySQL没有工作在严格模式时，对于ALTER TABLE、LOAD DATA INFILE、UPDATE和多行INSERT语句，由于裁剪发生的转换将报告为警告。当MySQL工作在严格模式时，这些语句将失败，并且部分或全部值不会插入或更改，取决于是否表为事务表和其它因素。详情参见mysql手册5.3.2节：“SQL服务器模式”。

    二：php5：
 
    1：整型数的字长和平台有关，PHP 不支持无符号整数。
    2：如果给定的一个数超出了 integer 的范围，将会被解释为 float。同样如果执行的运算结果超出了 integer 范围，也会返回 float。如果在程序中有对数字类型做比较，可能会产生问题。
    3：可以查看PHP_INT_SIZE、PHP_INT_MAX，以确定整数的范围。
 
    以下列子可供参考：
 
    在32位服务器下：

    在64位服务器下：
 

    三：C/C++
 
    对C/C++也存在有符号和无符号类型的问题。
 
    对于32位系统，如果使用有符号int、long来定义变量保存唯一号就可能出现溢出，并出现上述问题。

    对于64位系统，如果使用int来定义变量保存唯一号就可能出现溢出，并出现上述问题。
 
    可参考 http://www.ibm.com/developerworks/cn/linux/l-port64.html

    这是这个连锁反应：发现apache的log没有分日期、分正误记录 --> 改为分日期、分正误记录log --> 观察错误log，发现有大量404错误 --> 需要修正程序，发现文件路径错误 --> 本机使用Dreamweaver替换路径，提交SVN --> 部署到服务器上时发现文件太多、且分散在子目录中

    怎么办？一个一个找一个一个上传？傻子才干！既然是在FreeBSD下，那就是用强大的命令行工具吧！实践中发现这个方法真的很实用，记录下来！

    需求：把本目录下，包括子目录下的文件，把所有含有“/adm/images/c.gif”的地方替换为“/Admin/Images/c.gif”。

    步骤：找出文件，找到地方，替换。

    寻找命令：找到文件（find，ls），找到地方（grep），替换（sed）。

    现在需要做的，就是组合起来。

    查找资料，有前辈告诫：“find 命令是所有 Linux 命令中最有用的一个，同时也是最混乱的一个”，顿时奔溃。

    还好，发现find命令有个叫“-exec”的，很是强大：find命令对匹配的文件执行该参数所给出的shell命令。相应命令的形式为'command' {} \;，注意{}和\;之间的空格。

    个人理解：-exec参数中的“{}”是该参数前命令产生的结果的一个变量。感觉类似管道的作用了。

    而且还可以有多个-exec参数，很是强大。基本上grep和sed都可以作为子命令在其中运行了。

    如此一来，可以使用以下命令列出需要替换的字符串所在的行了：

    然后再使用一个-exec参数吧sed包含进来吧。

    sed 的工作方式：

    注意后面提到的源文件不会修改，不过sed提供了-i参数，可以做到控制是否可以修改源文件。-i参数的描述，Linux和FreeBSD下不太一样，后来也发现Linux在命令的使用方便上的确是要强于FreeBSD的。分述如下：

    FreeBSD下说如果-i参数后面的后缀如果为0，则不产生备份文件，结果我试了好几次都没有搞定，不得已，使用了一个备份文件来存储源文件，然后修改源文件：

    比如下面的就不行，老提示错误，望知情者指教：

    Linux下，可以不产生备份文件直接修改了：

    当然，需要强调的是：备份还是很重要的！切记切记！

    本文环境如下：

    另：
    1：FreeBSD下如何查看sed的版本呢？
    2：网上看见资料说，类似下面的语句应该是可以达到目的，当我在FreeBSD和Linux下都没有运行成功

    参考资料：