#
这两天花了点时间看 Dojo 0.3.1 的新功能, 发现Dojo果然兑现承诺, 在0.3.1加入了一点国际化支持的功能。最主要的是改动是引进了 dojo.locale 属性和 dojo.i18n 包, 从而于 javascript 实现了Client端的本地 message bundle 机制,从现在起,我们可以在客户端根据locale装载JS消息文件了! 完整的示例代码如下:
<script type="text/javascript">
djConfig = {
isDebug: true
};
</script>
<script type="text/javascript" src="../../dojo.js"></script>
<script type="text/javascript" src="../_bootstrap.js"></script>
<script type="text/javascript">
dojo.locale = "fr";
dojo.requireLocalization("g11n.messages","salutations","en");
dojo.requireLocalization("g11n.messages","salutations","fr");
dojo.requireLocalization("g11n.messages","salutations","zh-cn");
dojo.require('dojo.i18n.common');
</script>
<script type="text/javascript">
function init() {
var salutations_default = dojo.i18n.getLocalization("g11n.messages", "salutations");
dojo.debug("default language: "+salutations_default.hello);
var salutations_zh = dojo.i18n.getLocalization("g11n.messages", "salutations", "zh-cn");
dojo.debug("Chinese: "+salutations_zh.hello);
}
dojo.addOnLoad(init);
</script>
首先是 dojo.locale 这个属性,这个属性是一个全局,作为用户默认的locale,如果用户不明确指定,dojo会根据浏览器的locale对这个属性赋值。和Java不同,目前在dojo中locale并没有对应对象,只是一个String对象,典型的格式应该是 "zh","zh-cn"。注意后者用的是 "-" ,而不是Java中的 "_"。
现在来看最让人心动的 message bundle 机制, 首先分成三步来把message文件组织好:
1) 要建立一个集中存放message文件的目录,我建的是 g11n\messages;
2) 和在java中一样,为不同的locale建立存放message文件的文件夹,比如我建的是"en","fr","zh-cn"; 这里要注意文件夹的名称必须要全部小写,原因是dojo从文件装载消息会把传入的locale属性进行 toLowerCase() 的处理(晕,不知道作者怎么想的)。
3) 把翻译完并用native2ascii转换好的消息文件放入对应的文件夹内。和Java不同的是,dojo用 JSON 格式来组织message文件,所以要把property文件转换到JSON格式的js文件, 不过这也很容易: 在文件开始的位置加入一个"{", 结尾的地方加入"}", 将所有的 "=" 替换成 ":" , 然后在每一行结尾处加入一个"," ,最后把文件改成js结尾便可以了。一个典型的JSON格式的文件如下(假设文件名叫 salutations.js ) :
{
hello: "Hello",
dojo: "Dojo",
hello_dojo: "%{hello}, %{dojo}!",
file_not_found:"The file you requested, %{0}, is not found."
}
把消息文件放好后,便可以在 dojo 中通过 dojo.requireLocalization() 调用这些文件了,对应的代码是:
//下载需要的locale的消息文件到客户端
dojo.requireLocalization("g11n.messages","salutations","en");
dojo.requireLocalization("g11n.messages","salutations","fr");
dojo.requireLocalization("g11n.messages","salutations","zh-cn");
//调用国际化包
dojo.require('dojo.i18n.common');
现在就可以调用指定locale的 message 了!在示例代码中我举了两个简单的例子:
//调用 dojo.locale 指定的locale中对应的消息文件中 hello 那条消息
var salutations_default = dojo.i18n.getLocalization("g11n.messages", "salutations");
dojo.debug("default language: " + salutations_default.hello);
//调用"zh-cn"中 hello 那条消息
var salutations_zh = dojo.i18n.getLocalization("g11n.messages", "salutations", "zh-cn");
dojo.debug("Chinese: "+salutations_zh.hello);
怎么样,非常简单吧?
除了message bundle, dojo 还声明要支持其他的一些国际化功能,比如Date,Number,Currency等等,在0.3.1中我只发现Date有一定的实现,但是基本就是对 Javascript Date 对象的几个locale相关的方法进行了一下封装,没有多少实质性的提高,看来dojo在国际化的支持方面还有很长的路要走。无论如何0.3.1中提供的message bundle已经有了一个良好的开端,值得期待。
前几天遇到一个bug,在一个填email的文本框,当用户录入比较长的一段文本后(比如40位以上),页面就死掉了。检查后发现校验Email的是下面这样一段javascript代码:
function checkEmail(email)
{
if (email.length == 0 )
return true;
var validEmail = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/;
if (validEmail.test(email))
{
return true
}
return false
}
checkEmail("123456789012345678901234567890123456789012345abcdefghijkl");
第一反应是正则表达式写的有问题,'@'前后的 ([\.-]?\w+)* 都可能会引起效率问题。下面仔细分析一下:
1. 从输入的值来看, engine会首先匹配 \w+, 这是一个贪婪匹配,可以一直匹配到结尾;
2. 然后按优先级开始匹配 ([\.-]?\w+)*中的 [\.-]?\w+,这个时候前面的 \w+ 为了后面的匹配成功,必须要重现匹配,让出一点匹配的内容,假设先让出的是 'l',([\.-]?\w+)*匹配成功;
3. ([\.-]?\w+)* 意味着要尽量去匹配多次,再第二次对 [\.-]?\w+ 匹配,这个时候为了第二次匹配的成功,第一次匹配的 [\.-]?\w+ 要让出能满足第二次 [\.-]?\w+ 的内容,也就是它匹配到的'l',这个时候,第一次匹配的 [\.-]?\w+ 又不满足了,\w+ 又得让出来一个'k'。
4. 这样未知匹配次数的 ([\.-]?\w+)* 就形成了一个很大的循环,而在正则表达式中,每次匹配时被括号里模式匹配的东西都是要被存起来供以后使用的,大量的中间结果被缓存,最终导致IE死掉。
所以这是一条典型的因为循环尝试匹配导致效率低下的正则表达式, 表达式中两个 ([\.-]?\w+)* 都可能导致解释器的crash,在本例中不需要利用匹配的中间结果,所以解决的办法很简单,在括号加入一个冒号,不保存中间结果就是了。即将那个正则表达式改成如下:
/^\w+(?:[\.-]?\w+)*@\w+(?:[\.-]?\w+)*(\.\w{2,3})+$/
如果性能还是不能满足需求,可以考虑把这个正则表达式拆成几个小的表达式,分别进行验证。
1) SVN配置文件中各个属性行前不能有空格
在Windows平台下安装Subversion之后,使用时提示svnserve.conf中一些行有问题。打开svnserve.conf一看 "password-db = passwd" 这一行最前面被我无意中加了个空格,删掉后SVN便工作正常了。
2) Tomcat 5.5 连接池的古怪错误
在tomcat 5.5下配置连接池,使用时总是出错: Cannot create JDBC driver of class '' for connect URL 'null'。
一样的配置以前在5.0下都是可以正常工作的。查了Tomcat的联机文档也没有什么发现,多次尝试最后找到解决办法:在 $CATALINA_HOME/conf/Catalina/Host Name/ 下建一个和应用同名的xml文件,将原来放在server.xml文件中的该应用对应的Context定义放在这个xml文件中,便不会有这个错了。
3) Velocity配置文件中${webapp.root}变量不起作用
在spring中使用velocity作为显示层,以前一直是用绝对路径来指定velocity模板文件的根目录,这次想直接和应用的root路径挂起来。
在velocity.properties中file.resource.loader.path的注释中看到有一个${webapp.root}的描述,便在velocity.properties中设置 file.resource.loader.path=${webapp.root}\\velocity\\,不起作用。看来velocity自己并不会设置类似于${webapp.root}这样一个变量,查velocity的Developer's Guide,也没有找到有类似${webapp.root}的变量,Guide中倒是推荐将模板文件打成jar,然后用ClasspathResourceLoader来找模板文件,开发阶段可不想弄的如此晦涩,还是直接改回用绝对路径好了。
几个小问题虽然都解决了,但却不知道为什么,因为时间的原因我也没有深究。现在贴出来,有人知道原因的,还请不吝赐教。
用了四五年的Table排版,没觉得有什么不好,这一段时间迷上了Dojo,才发现如今已经到了不用DIV不行的年代。还是赶紧跟上潮流,把Table换成DIV吧! 改了几个页面,发现比想象的简单,更是尝到了用div的甜头。share自己一点浅浅的经验:
1. 先上网搜一下找点前人经验。推荐两篇好文:
http://www.glish.com/css/ "CSS Layout Techniques: for Fun and Profit"
http://www.alistapart.com/articles/practicalcss "Practical CSS Layout Tips, Tricks, & Techniques"
2. 随便找几个用DIV+CSS实现,结构又比较简单的网站,研究一下它的页面结构和CSS。比如我就是主要看了下面几个网站:
CSS禅花园 http://csszengarden.com/
Eclipse.org http://www.eclipse.org/
mozilla.com http://www.mozilla.com/
作为世界上CSS高手比武的擂台,CSS禅花园的模板实在多的恐怖,以前都只站在欣赏的角度不觉得,自己研究起来,也就只能是挑了一两个看看,再感慨了一番作者真是好创意好美工。有趣的是Eclipse.org的首页居然基本用的都是mozilla.com的CSS,对比着这两个网站看更能看出端倪。
3. 自己上手干吧,让你的页面内容和显示样式彻底分离,其实并不难。
GB18030 的正式名称为“中文国家标准 GB 18030-2000:信息技术 - 信息交换用汉字编码字符集- 基本集的扩充”。它是针对在中国出售的所有产品制定的政府强制标准要求,该标准于 2001 年 9 月 1 日生效。这也意味着从理论说,每个在出售的产品都要支持GB18030字编码字符集,否则就不让卖[嘿嘿,您的产品达标了么?]。
有人曾经在他的一篇blog[ http://blog.cathayan.org/archive/1/2005-7-4 ]里非常形象的介绍过 GB18030 的历史,转贴精彩部分如下:
1,GB2312是很老的东西了,早就发现不够用了。
2,94年(还是之前)国家推出了建议性标准gb18000(还是13000我忘了),这个标准其实就是utf-8标准(除了名字,完全一样),同时也建议微软公司采纳。--(据说是1993年,GB13000,应该是ISO10646)
3,微软借口说gb18000还不成熟,为了取得中国市场的垄断地位,自己搞了一套汉字标准,于是它就随着win95和office之类的流行起来了,国家看生米已经煮成了熟饭,只好把这套标准定为国标GBK标准。--(其实只是指导性标准,并非强制性,GB18030是强制性标准)
4,微软到了99年(前后吧),又说GBK已经落伍了,现在流行utf-8标准,准备全盘转换成utf-8,这些把有关部门惹怒了。NND,当年我们推utf-8你说不成熟,自己搞了一套,现在赚得盆满钵满了又自己说要推utf-8了,你丫微软分明就没把政府放在眼里。
5,于是政府怒了,强制推行gb18030标准(这个标准前面兼容GBK,其他码位兼容utf-8),算是过渡标准吧。要求微软强制执行,否则产品不得在大陆买。于是基本搞死了微软的WindowsMe,差点搞死了Office2000(据说发行前几个月,微软除了改字符编码就没干其他什么事情)--(确实,WinMe是我认为的最差的Windows版本,而office2k也是前不着村,后不着店,前后兼容性都差)
6,由于以上历史原因,现在就是GB2312,GBK,GB18030,UTF-8并存了。
7,如果不是万恶的微软,我们早就用上UTF-8了。
或许正是因为微软和中国之间为GB18030发生了这么多的恩恩怨怨和当年微软的仓促上阵,直到现在微软的很多产品对GB18030支持的依然不是很好。访问下面的页面,了解MS对GB18030支持情况及下载Windows下的GB18030安装包:
http://www.microsoft.com/globaldev/DrIntl/columns/015/default.mspx
虽然MS声明在Windows XP 和 Windows 2000 中通过"add-on"来支持GB18030,但是IE 6.0直接显示 List Box、Drop Down Menu、Text Area、Text Field中的GB18030字符依然还是有问题,下面的这篇文章有相关的介绍:
http://www-306.ibm.com/software/globalization/gb18030support/retrieve.jsp
在IBM的这篇名为"Globalize your On Demand Business"的文章里,给出的solution是在要显示GB18030的元素上加上类似 "STYLE="font-family:'SimSun-18030'"的CSS声明。在当今WEB2.0如火如荼的年代,我们当然要把内容和显示分离,在CSS中进行配置!当然实际问题要比这个文档说的略微复杂一点,有下面几个比较明显的问题:
1) 一般来说,大部分html标签(包括Input)都不要,但<Select> 要必须要在CSS中强制指定"font-family"为"SimSun-18030"。
2) 当要为一个元素指定多个字体的时候,要将"SimSun-18030"作为首选,即放在最前面。
3) 对于大部分标签,当font-family设为 SimSun-18030 时,而font-size 为:8pt,9pt,11px 时,有一部分字符比如 "㊣"和一些标点 会显示成其他的字符,对 "㊣" 这样的字符,IE 会出现乱码。原因可能是因为这些个font-size针对WEB做了优化。
小结:GB18030是个形式大于内容的东西,但是如果想要让你的产品理直气壮的再中国销售,略微花点时间设置一下还是有必要的。
昨天抽出空来装了一个Ruby,体会体会这个最近很多人提起的东西。从下载到安装,包括装Cygwin一共也就用了一个小时。看了看它自带的文档,写了两个小脚本试了一下,觉得和perl很点类似,语法很简单,上手非常快,用起来也没感到什么特别神奇之处。接着下了久仰大名的Ruby on rails 装了一下试试,发现用它建站的确很快,就像当年用傻瓜相机的感觉。
简单来说,Ruby 给我的感觉一般,没有让我有一见钟情的感觉。我不是很喜欢Ruby这种很随意的语法,对于Ruby on rails这个轻量级的构架未来内能达到的高度也有所怀疑。Ruby就是Ruby,还是不能和Java来比较,离取代Java更是差十万八千里,Ruby本身是一个普通的脚本语言,和Java差别太大,Ruby无非是在各有千秋的众多编程语言里又加了一种。Ruby on Rails 的思路是比较前卫的,不过主要就是个思路,别人很容易就借鉴了,没准用不了多久java on rails,dotnet on rails就会出来。不知道Ruby on rails在事务、安全方面是怎么处理的,运行起来效率会怎样,反正觉得Ruby on Rails好像是用来做中小型网站的。网上好像Ruby的fans很多,其实回头看看,每种流行一点的脚本语言的Fans都很多。
我认为Ruby的语法、Ruby on Rails的特点注定了它只能给一些想快速建网站的人使用,是很难得到大公司青睐从而在商业领域获得更大空间的。对于目前新流行起来的几个脚本语言,我觉得groovy的定位还是很不错的,傍着Java这个巨人,将来没准能吃香的喝辣的。虽然不是特别看好Ruby,以后有时间还是准备系统的看一下ruby的语法和试一试ruby on rails的应用开发,应该能从里面找到很多可以借鉴的东西。
刚才无意中发现自己很久以前写给同事看的东西,干脆贴出来。
- 安装环境
Wiki的功能比较简单,因此互联网上Wiki的实现非常非常的多,有各种各样的实现,基于asp、java、php、Python、perl等等,大家可以根据情况自己挑一个。从这方面看,Wiki映证了一个道理,简单的就是最美的,好像有一大筐做工精致的艺术品摆在你面前让你挑,真是人生快事。至于俺么,当然是选择基于Java的了!有人做好了给你用,爽哦。
我的安装环境:Linux + Tomcat-5.0.19 + JSPWiki 2.0.52 + jdk1.4 。
- 开始安装的准备工作
下载 JDK, Tomcat 并安装,这里就不说了,呵呵。
从 http://www.jspwiki.org/ 下载JSPWiki, 当前的稳定版本是2.0.52。当然这个网站本身也是用Wiki做的,去下载时你就已经认识到Wiki是什么东东了。下载下来的是一个压缩文件 jspwiki-2.0.52-bin.zip ,解压后进入解压的文件夹,可以看到JSPWiki.war、JSPWiki-samplepages.zip两个文件,前者就是JSPWiki的程序了,JSPWiki-samplepages.zip里是其官方给出的一些例子页面,很有价值哦。
- 安装
将JSPWiki.war解压到一个文件夹,假设叫wiki,后放到 Tomcat 的Webapps文件夹下,进入 wiki/WEB-INF/ , 编辑 jspwiki.properties ,进行相关的设置,几个重要的参数:
a) jspwiki.applicationName = your app name -------- 你这个Wiki网站的名称
b) jspwiki.pageProvider = VersioningFileProvider -------- Wiki对页面的管理方式,有三种: RCSFileProvider, FileSystemProvider, VersioningFileProvider(推荐使用).
c) jspwiki.fileSystemProvider.pageDir = /home/wiki -------- 网站内容存放地点
d) jspwiki.basicAttachmentProvider.storageDir = /home/wiki/attach -------- 网站用户上传的附件的存放地点
e) jspwiki.encoding = UTF-8 -------- 设置页面的编码格式
f) jspwiki.rss.channelLanguage = zh-cn -------- 设置rss语言格式,如果你不需要rss功能的话可以不设置
g) jspwiki.baseURL= ——wiki的基本URL,如果你不需要rss功能的话可以不设置
h)jspwiki.translatorReader.allowHTML = false -------- 是否允许wiki里面支持html,网站对外开放时最好不要设,因为wiki是协同编辑的,如果有人恶意使用js的话,就惨了,呵呵。
- 设置字符集
安装后要使有中文问题,注意看上一项4中的 e ,f 两项是不是都设置对了.
- 运行Wiki,添加页面
jspWiki内置了一些用于布局的版面page,包括Home、Index、LeftFooter、LeftMenu、LegalAndPrivacyNotice、MenuBar、RightFooter、RightMenuBar、Website、Contacts、ErrorMessage等等,只要稍加编辑就可以攒一个挺专业的网站。激活它们的方法是浏览器中输入: http://localhost:8080/wiki/Wiki.jsp?page=pageName.
- 后期处理
设置tomcat为自启动: 在startup.sh 中设置 JAVA_HOME , CLASSPATH , PATH 等环境变量,在 /etc/rc.d/rc.local 中添加启动脚本。
熟悉wiki之后可以进一步学习FitNesse之类的 Wiki 的较高级的应用。
上周末按一个朋友的要求,写一个整合Tomcat-5.5.4与apache-2.0.49的文档。很久没用Apache了,在家用了一两个小时才在自己的XP下配成功,简单整理了一个文档贴出来,与需要的人共享。我开始是在 apache 的conf 文件夹里建了一个mod_jk2.conf个文件,用JkSet config.file ***语句指到TOMCAT_HOME\conf\workers2.properties, 无论如何都不成功,最后就直接把workers2.properties拷到apache 的 conf 文件夹里就OK了。具体步骤如下:
1、假设Apache2安装在 C:\Program Files\Apache Group\Apache2, 上Apache网站下载jakarta-tomcat-connectors-jk2.0.4-win32-apache2.0.49.zip , 解压后将modules\mod_jk2.so拷贝到C:\Program Files\Apache Group\Apache2\modules里面。
2、 在C:\Program Files\Apache Group\Apache2\httpd.conf中设置Dynamic Shared Object (DSO) Support的那块区域里增加一行:
LoadModule jk2_module modules/mod_jk2.so
3、修改 Tomcat-5.5.4 HOME\conf\ 下的配置文件, 编辑jk2.properties,修改handler.list的值,要注意端口channelSocket.port设置的值,默认是8019,改成8009, 这样改各个配置文件的改动量最小。
# Set the desired handler list
# handler.list=apr,request,channelJni
handler.list=channelSocket,request
#,
# Override the default port for the socketChannel
channelSocket.port=8009
4、将 Tomcat-5.5.4 HOME \conf\ 下的workers2.properties 拷贝到 C:\Program Files\Apache Group\Apache2\conf 中,然后修改workers2.properties 内容:
[logger.apache2]
level=INFO
[shm]
file=C:\\apache\\Apache2\\logs\\shm.file
size=1048576
[channel.socket:localhost:8009]
port=8009
host=localhost
[ajp13:localhost:8009]
channel=channel.socket:localhost:8009
[uri:/*]
worker=ajp13:localhost:8009
要进一步设置的,修改[uri:/*],比如改为[uri:/*.jsp]。当然这样记住要先将Apache的默认目录指到tomcat下的对应的应用. 此外[uri:/*] 这部分可以设置多个。
5、重新启动apache、tomcat, 访问apache的地址http://localhost/和tomcat的地址http://localhost:****/ ,如果看到一样的东西,应该就可以了。
6、配Apache的默认目录或虚拟主机,指到要用Apache来显示的目录里面去;网上很多,Apache本身的文档说的也比较清楚,就不详细说了。
7、如果是 Linux 平台的话,Apache 必须要在编译的时候加上选项,使其能动态的加载DSO模块,大概的步骤就是下载Apache源文件 ,然后依次执行:
#cd /usr/local/src/ ( /usr/local/src/ 就是保存安装源文件的文件夹 )
#tar -xzvf httpd-2.0.49.tar.gz
#cd httpd-2.0.49
#./configure --prefix=/usr/local/apache2 --enable-so (-enable-so 这个选项最重要,一定要加上 )
#make
#make install
后来的步骤和windows下应该是一样的(那个so文件应该也可以在linux用),linux下面我这次没有试,不过思路和步骤应该差不多就是这样,俺以前配过。
从年初到现在,AJAX之风预演愈烈,尤其是在国内,大多是一片叫好的声音。目前好像很多人都在搞基于AJAX的框架,国外也有一些都已经发布。对于这种一直都存在技术,Google、微软一造势,大家的热度好像有点过了头。看来现在咱们这些程序员真的都是些追星族啊!
难到AJAX真的就那么优秀,值得提升到框架的高度,让系统UI端围着它转?单纯从AJAX本身来说,其最主要不过就是解决在网页上一个无刷新获取数据的问题,再加上减少了数据的传输量,将数据解析的工作推到了客户端,的确能解决很多传统的问题,很方便的实现一些动态效果。然而,要围绕AJAX建立一个框架,通过AJAX完成UI端绝大部分内容的展现,我个人认为却是欠妥。现在很多人在网站上说,AJAX多多成熟,能达到多好多好的效果,但是问题是,AJAX技术本身成熟,但AJAX框架却是十分的不成熟。
笔者前一段一直在参与一个国外知名大公司的一个产品的开发,这套系统好几年前就开始做了,系统的UI很多是基于AJAX的,对AJAX的应用可谓登峰造极(当然,那个时候肯定还没有AJAX这个名词),其界面的可操作行几乎可与桌面系统媲美。这系统有一个强大的AJAX框架,光是相关基础JS文件就是数十个,整个UI基于Javascript事件驱动,数据由XMLHttp获取。整个方案看上去的确很棒,或许正是现在很多人想要实现的。但实际情况是如何呢?效果是实现了,程序开发和测试、维护的效率则是大大的下降了。开发就不说了,前期投入巨大,系统复杂性剧增,程序也只能用IE访问。测试的时候这边 AJAX的javascript的bug满天飞,那边调试这种错误极不方便,没有好的JS的调试器,更看不到实际输出的html代码。维护那就糟糕,加个新功能,JSP文件、标签、JS、后台类全要过一遍。或许正是这些不易克服的问题,我看到在最近开发的配套软件里,就基本没有用什么AJAX了。
大公司的尝试和经验,或许能给大家一些启示。说到底,所有的技术都是有利有弊的,AJAX也是一样。我个人认为AJAX 最适合的就是Google Map这种网上地图系统,展现方案相对比较单一,又非常的需要无刷新的获取数据。对于那些业务比较多,展现风格非常多样的业务系统,万万不可脑子一热,真的要用什么AJAX框架,到头了只回为了一点无谓的效果砸了自己的脚。
最后强调一下,AJAX是个好东西,在项目里用它来实现一些辅助效果(最传统的比如用户输入数据时实时的验证,给出相关提示)即快捷又神奇,但过度使用很容易让自己系统陷入麻烦之中,一定要慎重!此外目前公布出来的所谓的那些AJAX框架大多都是实现一个Form或者一部分页面的无刷新取数,根本谈不上什么Web框架,目前没必要抱太大的希望。最近down了几个开源的ajax的东西看了看,觉得对一般开发人员来说,ajaxtags (http://sourceforge.net/projects/ajaxtags/) 是个不错的东东,简单易懂,可以仿照它的标签做一些自己的实现,值得看一看。
声明:本博客中所有文章均为版主原创,转载请保留作者信息,并请注明出处。
昨天无意中发现教育网内也能上google了,高兴之余也颇有感慨。回想过去数年我和朋友在教育网里搜资料,每每破费周折的设代理、找国际网关,还常常不如愿,不得不用蹩脚的baidu, 现在终于是方便了。
细想起来,这事情还得感谢我一向不太看的起的百度了! 数年前百度不过是个有些小聪明的模仿者,用一个类似Google的界面,搜出一堆杂乱的糟粕,前一段时间却因为上市一下誉满神州了。在我看来百度的红火,除了百度自己说的和门户网站合作挣钱之外,两个因素发挥了很大的作用,一个百度提供的mp3搜索下载,另一个是教育网内数量巨大的网民无法使用google,迫不得已就用百度了。
前者当然不用说,为了自己的利益,百度用一份所谓“著作权保护声明”做掩护便大张旗鼓的为侵犯知识产权的行为推波助澜,就连这份用来做作的声明,估计也还是被人告了一通之后才炮制出台的。写到这里,突然想去以前百度被告时申述的理由:要告应该去告那些侵权的网站,我百度只是提供搜索服务的,这跟我没关系。呵呵,百度逻辑的荒谬,由此可见一斑!分门别类的把那些侵权的东东排列好让人去down,还说和他没关系。倘若按这种逻辑,那些销赃的人就可以说,我知道这东西是偷来的,但这不是我偷的,我只是卖的,要抓抓那些小偷去!当然,销赃的人不只是百度一家,然百度却必是其中之一。
再看第二个因素,教育网内网民无法用google是历史问题,google最早是国外网站访问要算国际流量。于是缺乏就产生了,在经济学家眼里,缺乏、竞争、物产是同义词,有了缺乏就会有竞争,于是百度来了,承担起和google来compitition的责任,结果大家都看到了,百度受益不小。现在Google当然不会容忍在地球上人口最多,经济最有活力的国家有这样一个竞争对手,也开始反思其漠视中国最具前卫性的网民群体的行为,于是我在家能上google了。红尘俗世、莫不竞争,我这个老百姓又一次深深的感受到竞争的好处。
教育网内能有google了,百度会沦为一个mp3搜索站么?百度钱圈了一大笔,但是搜索的质量没有任何提高,倒是网站的乱七八糟的东西多了不少。我绝不并是刻意的要说百度的不是,我是中国人,当然希望我们自己国家的搜索引擎能强过美国人。最盼望的是百度能认真的把搜索做好,销赃的事情少做一点,compitition的责任多承担一点。等过些年倘若大家不用因教育网能上google欣喜,我们这些网民也算是有幸了。