技术细节
从FireFox中删除插件FoxyTunes
在使用FireFox的过程中我逐渐安装了很多插件,这些插件使得我上网便利了很多。但是最近一段时间来我的FireFox经常占用很多CPU资源,常常一个FireFox就使用了CPU的90%左右的资源,甚至因此导致FireFox死掉,这让我很烦。我猜测这是因为某个插件开发水平差而引起的,但我不知道是哪个插件,我也不想随便删除插件,因为这些插件对我都挺有用的。
今天,在又经历几次FireFox死掉之后,我终于忍无可忍了。既然我不能放弃FireFox,那就让我放弃掉某些FireFox的插件吧。于是我将FireFox的插件一个一个的卸载、跟踪,终于发现,原来是FoxyTunes这款插件捣的鬼!
FoxyTunes是一款将多媒体播放软件控制集成在FireFox浏览器里面的插件,使得用户在使用FireFox的时候不用切换应用程序窗口就可以对正在工作的媒体播放软件进行各种操作。这款插件在以前版本的FireFox中工作得挺好的,不知道为什么当我升级到FireFox v1.5后,反而出问题了。
总之,我把FoxyTunes这款插件从FireFox中删除了之后,整个世界顿时清静了很多。
类别:
令人吃惊的Google搜索新效果
刚刚准备在Google加拿大上搜索信息,震惊地发现当在输入栏输入搜索关键字的时候,输入栏会动态地显示一个下拉菜单,显示可能的一些搜索结果(如下图所示,这里就把这个效果称为“动态搜索结果显示效果”)。
前两天刚刚在FireFox里面安装了一个Google插件(CustomizeGoogle),因此我怀疑是不是插件的原因而产生了这个效果。于是马上切换到google.cn(Google中文),结果发现没有这个效果了。于是我又切换回Google加拿大,输入一些别的我最近都没有用过的关键字测试了一下,终于相信这个效果是Google自己生成的,而且是今天刚刚发布的一项Google搜索的新功能,因为下午的时候我用Google的时候还没有看到这个效果。
我又进一步测试了一下,这个显示效果对于中文关键字搜索同样有效。而且,现在Google香港(中文简体)就已经支持动态搜索结果显示效果,相信Google中文很快也会支持这个效果。
这个效果PHP.net也用过。当在PHP.net用PHP函数名搜索的时候,会产生这个效果。但是,显然PHP.net的动态效果是比较简单、也比较容易实现的。而Google的这个动态效果是惊人的,难道和最近热门的AJAX技术有关系?Deminy没有特别关注过AJAX,但觉得很有些意思。
类别:
如何修复eGroupWare邮件乱码问题
版本: v1.0.0.009
问题: 邮件显示标题和内容均为乱码。此现象应该会出现在所有使用东亚文字的该系统中。
文件: email/inc/class.mail_msg_base.inc.php
函数: htmlspecialchars_encode($str, $charset='')
行数: 5188-5191左右
改写为:
1 if (!$charset)
2 {
3 $charset = "gb2312"; // 修改,仅对中文简体有效
4 }
5 $str = mb_convert_encoding($str, "UTF-8", $charset); // 新增
6 $str = htmlentities($str, ENT_QUOTES, $charset);
[补充说明1] 该bug同样出现在eGroupWare v1.0.0.007中。Deminy所提供的是一个治标的方法,并未全面研究email部分代码,只解决了邮件阅读时的乱码的问题,但未解决发送的邮件中的乱码问题。
[补充说明2] 该系统多处调用函数htmlspecialchars_encode时,并未使用第二个参数,导致该系统的邮件部分并未能实现真正的支持多语言。
类别:
对论坛email的搜集
刚上mycust,突然看到一则新帖《mycust的会员资料成了网上商品》,里面说到,“在试用百度搜索时,想试看看mycust的知名度,作为关键字一搜乖乖不得了,发现了一个链接,点击进入一看发现竟然是一个提供mycust会员资料下载的链接!”。
初阅此贴既吃惊又愤怒:居然有校友吃里爬外把这种内部消息泄露到网络上!继而想到,应该不是校友外泄资料,而是也许网站有漏洞,因此被人偷去了资料;进而想到,哈!这不就是我今天课程陈述里讲的内容吗:有个混蛋写了个程序专门收集论坛的email!
像动网这样的论坛,在个人资料页(例如deminy这个用户)是把email地址显示出来的,因此,好事者可以写个程序,批量地把一个论坛所有注册用户填写的email地址给搜集下来!
如果去那些兜售垃圾邮件的网站,会看到很多网站的论坛用户email在被出售,而这些论坛都有一些共性:就是把注册用户的email直接显示在网页上了!
因此,这次的泄密,应该不是网站任何校友的素质问题,也不是网站管理人员的问题,而是因为有网上的好事者专门用程序来收集论坛email地址。可以说,造成这次事故的原因,可能是动网论坛的设计问题或者使用方面的问题。这类问题同样出现在别的一些有名的论坛程序(例如phpBB)中。
[补充说明] 本文转自此处。
类别:
EditPlus新补丁发布
Deminy经常使用EditPlus里面的FTP远程编辑功能,喜欢通过FTP直接连到服务器上进行文本编辑操作(主要用于管理deminy.net网站)。这时候就发现,新版的EditPlus在FTP功能的某些方面虽有明显改进,但又引出了一个明显的Bug:远程连接常常停滞、失败!
对于这么一个严重影响用户使用的Bug,Deminy相信EditPlus一定会很快地做出反应,发布一个补丁来修复这个问题的。实际上,最近1年来,虽然EditPlus的正式版本更新很慢,但时不时(或者说偶尔)EditPlus会在它的FTP服务器上放最新的软件补丁上去。只不过出于某种原因,这种补丁从来不在官方网站上给出正式说明。
上午考完试,暂时可以休闲一下,于是Deminy捡起以往的爱好——软件试用,去检查自己最欣赏的软件的更新信息。去访问EditPlus的FTP服务器,终于发现一个新的补丁"epp220p279_1007"被放上去了。颇为兴奋地下载下来,查阅一下所附的更新文档,果然发现这个补丁修复了诸多FTP方面的bugs,只是不知道这个补丁能否修复我所碰到的bug。
不管怎么样,对于我这个EditPlus的忠实用户而言,这是一个好消息。
[注] EditPlus及其补丁下载地址: ftp://ftp.editplus.com/
类别:
Serendipity中文乱码解决方案 (2)
前言:
上篇谈到了如何使用UTF-8编码解决Serendipity的RSS中文乱码问题。但是很多时候,我们用中文网页的时候不喜欢网页编码是UTF-8,而希望直接用GB2312编码。在这种情况下,如何解决RSS乱码的问题呢?
进一步的原因分析:
风传Serendipity是几位PHP业界高手联手开发的杰作,因此我们有理由相信这是一套可以作为程序开发范例的系统。因此,在语言国际化方面,不大应该出现编码方面的瑕疵。基于上述考虑,我们有理由相信Serendipity既能支持“Simplified Chinese (UTF-8)”编码,也能支持“Simplified Chinese (GB2312)”编码。实际上,“雪人阁”网站使用的Serendipity就采用的是“Simplified Chinese (GB2312)”编码,而且没有出现乱码问题。
由此,把所有语言选项设置为“Simplified Chinese (GB2312)”编码后,对程序管理界面、数据库等做进一步测试,未发现任何不妥之处。再对出现问题的RSS程序做进一步分析,终于发现问题所在:
默认Serendipity的所有feeds(指RSS、Atom等)都是统一采用UTF-8编码的。因此,当Serendipity系统本身采用其它编码的时候,需要将其它编码的字符串转换成UTF-8编码,再输出到相应的页面中。这个编码转换的工作,是由include/functions.inc.php文件中的一个函数serendipity_utf8_encode()实现的。该函数需要使用iconv函数库,否则将采用utf8_encode()进行编码转换。
因此,如果服务器的PHP嵌入了iconv库的话,那么,就不会有乱码的问题了;但是如果没有嵌入iconv库的话,Serendipity系统将调用utf8_encode()函数,但因为某种原因(不详)调用utf8_encode()后得到的字符串在页面上是乱码的效果。
解决方案(2种):
1. 在服务器上安装iconv库。有关PHP中iconv库的相关信息,参见这里。
2. 如果想用GB2312编码,但没有iconv库,则可以将Serendipity系统从多语言/多编码支持转换为单语言支持。具体来讲,就是把rss.php文件中的“2个upf-8”字符串修改为“gb2312”,把include/functions.inc.php文件中的函数serendipity_utf8_encode()改写,让它直接返回输入字符串。其它可能出现乱码的地方用同样的方式处理。目前,qingqing.us就是采用这个做法。
(完)
[补充说明1] 本文原名为《Serendipity的RSS中文乱码解决方案 (2)》,现更名为《Serendipity中文乱码解决方案 (2)》,以便和后续类似文章的命名统一起来。另,本文比较古老,所述内容(以后)可能过时。2006-06-22 20:06:21
[补充说明2] 如欲浏览更多关于Serendipity的使用、维护信息,请参考《网志程序Serendipity中文维护个人文集》一文。2007-07-15 14:23:19
类别:
Serendipity中文乱码解决方案 (1)
Serendipity是一个用PHP+MySQL开发的非常出色的Blog程序*,拥有众多的特性和功能:界面简单、功能强大的编辑界面、用户评论、多级分类、反垃圾功能、多插件、Trackback and Pingback、国际化语言支持、超强兼容性(兼容XHTML、CSS、RSS、ATOM等)等。
在当前最新版的Serendipity (v0.8.4)中,支持如下两种中文简体编码:“Simplified Chinese (GB2312)”和“Simplified Chinese (UTF-8)”。
在当前最新版的Serendipity (v0.8.4)中,有2处编码选项设定:一是在“Administration->管理设定->一般设定->语系”(此为全局编码设定),一是在“Administration->管理作者->作者/编辑->语系”(此为用户编码设定)。以下所有关于编码编辑/修改的地方,均指需要同时修改这2处的编码选择。(注意,因为翻译的原因,此处“语系”和“编码”是同一个意思)
问题/现象:
如果界面编码选择“Simplified Chinese (GB2312)”,用户会发现Blog主界面等中文显示都很正常,但所有聚合页面(RSS等)都是乱码。
解决方案(2种):
1. 如果是新安装的话,界面编码选择“Simplified Chinese (UTF-8)”,则一切正常了。
2. 如果用户设定的界面编码是“Simplified Chinese (GB2312)”,并且在此状态下发表了多篇文字,那么,首先要把MySQL数据库内的内容编码进行一次转换操作(从GB2312转换到UTF-8),然后把Serendipity的界面编码选择为“Simplified Chinese (UTF-8)”,则一切正常了。
如何进行MySQL数据库内容编码的转换?参见文章“关于GB2312/Big5中文WordPress站点向UTF-8的转换”。其实操作非常简单,就是在phpMyAdmin数据转换时,“导出时用gb2312/big5 (zh/zh-tw),导入时用 zh-utf-8/zh-tw-utf-8。”
[补充说明*] 在建立qingqing.us网站的Blog的时候,Deminy曾对网上流行的几套基于PHP的Blog程序(国产程序除外)作过简单的评测,初步认定Serendipity是这几套程序当中最棒的。
(接下篇“Serendipity的RSS中文乱码解决方案 (2)”)
[补充说明1] 本文原名为《Serendipity的RSS中文乱码解决方案 (1)》,现更名为《Serendipity中文乱码解决方案 (1)》,以便和后续类似文章的命名统一起来。另,本文比较古老,所述内容(以后)可能过时。2006-06-22 20:06:21
[补充说明2] 如欲浏览更多关于Serendipity的使用、维护信息,请参考《网志程序Serendipity中文维护个人文集》一文。2007-07-15 14:23:19
类别:
刚刚发现EditPlus最新版的一个bug
所编辑的文件内容:
a
1.
(a,空格,换行,换行,1,英文句号)
bug现象:使用替换功能,替换全部(Replace All)模式为“^[^0-9]*”的正则表达式,替换过程则会陷入死循环。
该现象未在UltraEdit下测试过。
类别:
无标题 (3353)
鼓励鼓励自己:好好睡觉。
类别:
正则表达式效率研究
[正则表达式简介] 正则表达式并非一门专用语言,但它可用于在一个文件或字符里查找和替代文本的一种标准。
[正则表达式相关网址]
揭开正则表达式语法的神秘面纱
http://www.zdnet.com.cn/developer/tech/story/0,2000081602,39077620,00.htm
[补充说明1] 前几个星期在和GeSHi(一个PHP软件)作者email交流的时候,我建议他使用某正则表达式函数来进行字符串替换,以提高语言编码(encoding)的兼容性。而他回信认为正则表达式效率相对较低,因此不予采纳。为此我对正则表达式的效率做了些了解,写成此篇。2005-03-24 12:01:18
[补充说明2] 我已经找到对于研究上述题目很有参考价值的一书:Jeffrey E. F. Friedl编写的《Mastering Regular Expressions》第二版 (2002年O'Reilly出版)。我不打算完成这篇文字了,因为有思路了,就不一定非要完成它。 2005-04-06 02:59:21