这是在欧阳的新贴子后的评论，转贴回来放到自己的blog里。小容在这次的评论里提出了“软信息”、“硬信息”、“浅交际”和“深交际”这四个新的生造词。造这四个新词，其实没有多大意义，仅仅是针对欧阳的那篇贴子。

建议先阅读原始贴子之后，再回来这里看小容的评论。

原始贴子：

阳志平眼中的web3.0：呼唤虚拟机器人时代的到来

引用：

即使对信息过滤得再巧妙、再充分，也始终还是停留在对信息的过滤层面，仅仅是Web1.0时代的自然进化而已，并没有深刻理解互联网与传统现实社会的异 同。

对于互联网上不存在的信息，也很难表达的信息，比如，信任、心理健康、调情、温暖、趣味、人情、内疚，这些内容，对于前一类网站来说，存在先天的局限性，几乎不可能表达出来。

“软信息”和“硬信息”这两个生造词可以参考上面这段引文。下面是原始的评论，中间涉及到虚拟人和机器人的说法，虚拟人的说法请先阅读程乐华老师的文章：长尾虚拟人：聚合人类时间和精力的长尾
—————————————

1、关于机器算法和人肉过滤

关于信息和信任两个维度的推演，很不错。用SNS业者的语言来说就是社会性计算。对于信息过滤的处理，机器算法和人肉过滤一直业界争议的话题，国外来说，就拿Google和Facebook相比，显然两者各有千秋，虽然Facebook提供了一些“软信息”，但是这不表明“硬信息”就过时了。而国内，豆瓣新近的改版也是在原来的机器算法的基础上加入了现在的人肉过滤算法。

2、关于虚拟人和机器人

小容觉得“虚拟机器人”这个提法有些模糊，程乐华对于虚拟人的分析，重点是虚拟人的角色是有它的自我存在，它的自我不是为了帮助他人过滤信息而存在。换句话说，张小盒是虚拟人，而哪吒的机器人则不是虚拟人。同样，小容也不认为小i机器人是虚拟人。

如同Imac所提到的Agent一样，信息处理领域一直就有信息中介存在，过滤器也是一样的。哪杂的机器人，小i机器人都可以算是这类信息中介的一种形态，我们可以叫它们过滤器、信息中介或者机器人都可以，但是，显然，他们和虚拟人有很大的差别。

当然，也排除有机器自动化操作的虚拟人，不过，小容很难想象那种会建立自我的机器人。。。。这个部分需要举例子来展开讨论。

3、关于软信息和硬信息

对于互联网上不存在的信息，也很难表达的信息，比如，信任、心理健康、调情、温暖、趣味、人情、内疚，这些内容。

小容想把这里说的这类信息称为软信息，而与此不同的则归类为硬信息。

然而，这样的定义是没有意义的。软信息这一类的内容，本身是人们在线交际的附属物。在社交活动中，人们不是为了信息而信息，人们是为了交际而表达。

在现实生活中，每一次单一交际活动结束后，因为表达出来的内容没有保存，而只能在人们的大脑中回响，而在网络世界中，每一次交际活动结束后，表达出来的内容保存下来。存档后的内容，甚至可以被网站利用来由此衍生和刺激下一轮的交际活动（例如facebook中的friend activities）。但是，即使这样，也不该就此认为交际所衍生的信息比交际本身更重要。换句话说，但人们获得了交际之后的心理体验之后，那些交际过程中所诞生出来的内容是没有价值的。

从这样的角度来看，小容认为Facebook不应该归类为信息过滤价值，而应该归类为社交价值。信息过滤价值只是Facebook的社交价值带来的附加价值，并不是主体。

4、人们分享硬信息的行为：浅交际

当然，Facebook上也同样存在着分享硬信息的行为存在，这一类行为的确可以归类为人肉过滤那一快。

同样，小容也用一个新词来描述这种行为：浅交际。这类行为比起相反的深交际来说，只是满足人们普通意义上的信息需求，而不会满足人们的社交需求/情感需求。

人们的社会交往的确包含有信息和信任两个维度，不过，放在互联网的语境中，社会交往里的“信息”和网络浏览里的“信息”的确是有差别的。或许可以把这两个维度变成一个四象限：

软信息，硬信息，浅交际，深交际。

5、未来

小容依然认为即使在未来，人们在web上，对于硬信息的需求还是占主导地位，因为道理很简单，整个web上，硬信息是海量的，只有对整个web的硬信息进行处理的公司，才会占据产业中心的位置。

而处理人们的情感行为方面的公司，它能处理的范围只会局限在自己的网站里面（人们的情感行为需要一个安全、固定和可信赖的环境，例如facebook和secondlife），这样它的地位终究是有限的，因为它没有把整个web当成自己表演的舞台。

当然，人们会探索如何在人们的交互过程中挖掘出有效的信息路径，这也是现在生活流如火如荼的原因。

原图

想起了以前在试验报告里杜撰数据-,-有机化学分析化学大学物理…

确实还是杜撰的好用呀，哈哈

原图

前些日子一篇N久之前的老文忽然成了被阅读的热点，检查之后才发现自己使用那段代码来做pr查询的页面已经不能正常得到URL的Page Rank值了，取而代之的是一大段“In your email, please send us the entire code displayed below”之类的Google terms_of_service错误提示信息。看来是原先的接口已经失效了。

但我装在Firefox工具栏的扩展插件SearchStatus仍然能够正常解析出每个受访页的PR值，找到 SearchStatus 的插件包解开来看源码，果然是使用了不一样的验证码生成算法，在原先的 checksum 生成之后，还需要再进行一次计算，两次演算之后得到的才是正确的ch参数。

于是拿现成的js代码改造一番之后，新的PHP版本的 Google PageRank 查询接口方法就出来了。经过本地测试之后，谁想传到服务器之后又出现了该死的 terms_of_service 错误提示。把checksum的计算过程一步步打出来，发现经过了几次右位移之后本地和服务器上的数字就不一样了。这才想到服务器是64位机，32位系统下位移之后应该被cut掉的bit在那里就活得好好的。加了个 trunkbitForce32bit 方法，对所有算术运算之后的数值进行高位屏蔽，算是搞定了64位系统下的多余位问题。结果拿到32位Linux环境下跑又不兼容了，原因是PHP在进行算术处理出现溢出时，会自动尝试将int转为float。当发生的是负数溢出时，这一操作在Windows下能正确保留精度，但在Linux下就有问题了。

下面这段代码：

$a = -4294967295;
echo dechex($a)."<br />\n";
if ( $a < 0 ) $a += 4294967296;
echo dechex($a)."<br />\n";

第一个echo在Windows下能够正确输出该负数低32位的补码，而在32位Linux机上输出的则是int类型所能表示的最大负数0x80000000了。只有通过取巧的方式给这个溢出的大负数加上一个超出整数范围的大整数来抵消掉溢出的部分，才能复原低32位应该有的样子。

使用这些非常规手段，终于炮制出这个更新版的兼容Linux32/Linux64/Windows的Google PR值查询接口的PHP脚本实现（含完整代码）。

参考:
php异或运算的不可靠性
PHP vs. BIGINT vs. float conversion caveat
http://www.teamworksusa.com/RDS275/HydroWorks275/keygen.php

继续阅读

• 光标处插入文本的jQuery插件
• ZF的TableRow级联删除
• svn post-commit中文转码
• Zeal OpenID Server打包下载
• svn pre-commit hook 的加载

（一）鲜果是什么
鲜果(XianGuo.com)是中国领先的RSS阅读分享平台，在业内一直享有良好的口碑。

（二）鲜果的理想
鲜果有志成为信息爆炸时代人人皆可从中得益的信息聚合、智能推荐平台。

有兴趣的同志可看下边两个链接了解我们团队、了解我们正在做的事情：
http://blog.xianguo.com/2008/04/11/how-can-we-win-134.html
http://blog.xianguo.com/2008/02/25/0220-talk-about-rss-115.html

（三）鲜果求贤
PHP开发工程师 2位

职位描述：
开发并不断完善鲜果(XianGuo.com)。
技能要求：
1、两年以上工作经验。
2、熟练掌握php+mysql编程，熟悉xhtml、css，能熟练使用javascript。
3、具有良好的编程习惯和技术文档编写习惯。
4、有志成为杰出的工程师，且坚毅有恒；有良好的沟通、表达、分析能力；有团队合作精神；能加班，有创业激情。
5、有大型网站开发经验者优先；参与过开源项目者优先；有个人的技术Blog者优先。

业务拓展总监

职位描述：
为鲜果(XianGuo.com)制定针对目标用户群的市场推广计划，并与业内相关公司建立合作关系。有一定的考核指标要求。
技能要求：
1、三年以上互联网业务拓展经验。
2、与业内各网站、传媒等有扎实的业务关系。
3、扎实的文字功底，善于用PPT撰写合作方案、市场计划等。
4、优秀的人际交往能力。
5、成熟稳重，坚毅有恒；能加班，有创业激情。

联系方式：
E-mail：feiyang58@gmail.com

欢迎各位朋友介绍，谢过先