David Lou

先说文章中提及的一个参数：mbstring.func_overload。这个参数的好处在于当你已经开发了大量程序后发现需要处理多字节字符集的时候，不可能将之前的程序全部检查，将相关函数替换成mbstring多字节字符处理函数。这个时候你可以通过设置这个参数来使php默认使用mbstring系列函数来重载替代相对应的php内置函数（例如常用的substr()会被自动替换为mb_substr()）。有5个可选值：

0：代表不重载任何函数（默认值）；

1：代表重载mail()函数；

2：代表重载str系列字符串处理函数；

4：代表重载ereg系列正则处理函数；

7：代表重载所有以上提及的函数。

不过在php手册中也提及了这么一句：

It is not recommended to use the function overloading option in the per-directory context, because it’s not confirmed yet to be stable enough in a production environment and may lead to undefined behaviour.

哈哈，慎用慎用，毕竟这么强大无视的参数还是谨慎使用为好，影响太大。打开后影响的函数列表如下：

mail()		-> mb_send_mail()
strlen()	-> mb_strlen()
strpos()	-> mb_strpos()
strrpos()	-> mb_strrpos()
substr()	-> mb_substr()
strtolower()	-> mb_strtolower()
strtoupper()	-> mb_strtoupper()
substr_count()	-> mb_substr_count()
ereg()		-> mb_ereg()
eregi()		-> mb_eregi()
ereg_replace()	-> mb_ereg_replace()
eregi_replace()	-> mb_eregi_replace()
split()		-> mb_split()

接下来几个参数也简略介绍一下，自己看注释理解的，可能有误：

mbstring.language：设置默认语言。默认值为neutral，就是UTF-8，这样就不错。

mbstring.internal_encoding：设置默认的内部编码。如果设置过mbstring.language，必须放置在之后，不然无法覆盖之前的设置。默认值NULL。

mbstring.http_input：默认的http输入编码。默认值pass，就是不处理。

mbstring.http_output：默认的http输出编码，前提是必须将output_buffering打开并将output_handler设置为mb_output_handler。默认值pass，也是不处理。

mbstring.encoding_translation：打开后将会自动将输入编码转换为internal_encoding所指定的编码（同样慎用，都交给机器未必是好事）。默认值Off，万幸。

mbstring.detect_order：设置编码的检测顺序，在使用mb_detect_encoding而又没有在第二个参数中指明检测编码顺讯列表时，将会以这里设置的为准。默认值auto，在language为neutral时也就是代表检测顺序为(ASCII, UTF-8)。

mbstring.substitute_character：当编码无法转换时的处理方式。默认值为NULL，也就是不显示无法转换的字符。你也可以设置为long，显示字符的hex编码；或者指定其他特定字符（例如”@_@”，呵呵）。

mbstring.strict_detection：是否打开严格的编码检测模式，这个找了半天才知道什么意思，在处理有不同编码或错误编码字符混杂情况（例如mb_detect_encoding(”testä”)）下打开这个参数能够防止mb_detect_encoding返回错误的编码。可以参见PHP Bug24309。默认值为Off。

mbstring.script_encoding：PHP脚本的默认编码。默认值为NULL。

大多数情况下默认值好像工作的就挺好，而且最好程序中也不要显式依赖于ini设置。使用mbstring系列函数时明确指明编码类型也许是一种更好的处理方式。在Unicode情况下，可以考虑设置为以下形式。

mbstring.language		= neutral
mbstring.internal_encoding	= UTF-8
mbstring.encoding_translation	= Off
mbstring.http_input		= auto
mbstring.http_output		= UTF-8
mbstring.detect_order		= auto
mbstring.substitute_character	= none

美味书签 [2008-07-22]:louyuhang @ del.icio.us

Tue, 22 Jul 2008 00:00:00 +0800

dompdf - The PHP 5 HTML to PDF Converter

美味书签 [2008-07-16]:louyuhang @ del.icio.us

Wed, 16 Jul 2008 00:00:00 +0800

美味书签 [2008-07-16]:louyuhang @ del.icio.us

Wed, 16 Jul 2008 00:00:00 +0800

IBM developerWorks 中国 : SOA 案例分析系列

美味书签 [2008-07-08]:louyuhang @ del.icio.us

Tue, 08 Jul 2008 00:00:00 +0800

美味书签 [2008-07-08]:louyuhang @ del.icio.us

Tue, 08 Jul 2008 00:00:00 +0800

美味书签 [2008-07-07]:louyuhang @ del.icio.us

Mon, 07 Jul 2008 00:00:00 +0800

美味书签 [2008-07-07]:louyuhang @ del.icio.us

Mon, 07 Jul 2008 00:00:00 +0800

PHPUnit - Trac

美味书签 [2008-07-02]:louyuhang @ del.icio.us

Wed, 02 Jul 2008 00:00:00 +0800

美味书签 [2008-07-02]:louyuhang @ del.icio.us

Wed, 02 Jul 2008 00:00:00 +0800

China Search Daily

美味书签 [2008-06-30]:louyuhang @ del.icio.us

Mon, 30 Jun 2008 00:00:00 +0800

Oracle | PHP Developer Center

美味书签 [2008-06-30]:louyuhang @ del.icio.us

Mon, 30 Jun 2008 00:00:00 +0800

Oracle | PHP Developer Center

顺利解决 Firefox 3 无法保存设置的问题

David Lou — Thu, 26 Jun 2008 01:15:06 +0800

安装了Firefox 3之后的日子，出现了一件怪事，单位的Firefox 3.0用的好好的，家里的出现了所有设置在关闭浏览器后消失，再开启变为原始状态的怪毛病。网上搜索了一下，发现是与\Documents and Settings\{你所使用的用户名}\Application Data\Mozilla\Firefox\Profiles\{一串随机字符}.default下的pref.js有关。无论我如何设置浏览器，pref.js始终不变。尝试删除pref.js让浏览器重建，却发现无法删除，关闭Firefox 3后依然无法删除，始终提示有进程在使用。下了个WhoLockMe看看是何方神圣，发现是PPLive所带的一个PP加速器锁定了该文件，删除PP加速器后一切正常。不过至于为何就不瞭了，如果有其它同学碰到这个问题，也请重点关注pref.js，这是保持所有firefox设置的文件，也是about:config中看到的那些。

另：今天看到了一个Firefox 3的小彩蛋，在地址栏中输入about:robots看看：）总算知道为啥Volcano老大之前的msn签名是“机器人有咬不得的闪亮的金属屁股。”，哈哈，小生愚钝了。。。

美味书签 [2008-06-20]:louyuhang @ del.icio.us

Fri, 20 Jun 2008 00:00:00 +0800

维基百科（Wikipedia）——访问英文、中文维基百科全书网站

美味书签 [2008-06-20]:louyuhang @ del.icio.us

Fri, 20 Jun 2008 00:00:00 +0800

维基百科（Wikipedia）——访问英文、中文维基百科全书网站

Firefox 3.0 正式发布

David Lou — Wed, 18 Jun 2008 10:39:39 +0800

2008.6.18北京时间01:00正式发布Firefox3的下载，本来想等到1点抢鲜下载的，最后还是没有熬住，顺带着连意法大战都没精神看了。到单位后立马开始下载了一份，安装速度倒是很快，之后使用的感觉也是区别不大。毕竟从RC到Release不会有大的区别，事实上也不会区别，可以参看Volcano老大的说法。

具体使用上面的差别之前提过一些，对于页面开发人员来说，对于js和css的支持改进是绝对值得关注的。可以尝试着在ff环境下使用些更高级的手段来得到更好的页面效果。

美味书签 [2008-06-11]:louyuhang @ del.icio.us

Wed, 11 Jun 2008 00:00:00 +0800

美味书签 [2008-06-11]:louyuhang @ del.icio.us

Wed, 11 Jun 2008 00:00:00 +0800

美味书签 [2008-06-09]:louyuhang @ del.icio.us

Mon, 09 Jun 2008 00:00:00 +0800

Google 公交

美味书签 [2008-06-03]:louyuhang @ del.icio.us

Tue, 03 Jun 2008 00:00:00 +0800

美味书签 [2008-06-02]:louyuhang @ del.icio.us

Mon, 02 Jun 2008 00:00:00 +0800

Regular expression tool - regex.larsolavtorvik.com

Firefox 3.0 RC1使用初体验之二

David Lou — Thu, 29 May 2008 11:33:16 +0800

自从下载Firefox 3.0 RC1（以下简称FF3）后，使用已近十天。这里就简单说说感受。

FF3总体来说，毕竟还不是正式版本，不稳定的情况还是有不少。比如在Vista上表现不佳，据同事反映，FF3在Vista上的第一次启动时就出现界面上的bug。另外在Vista上会出现频繁崩溃的情况。以我个人在XP上的使用来说，大部分时间表现正常，但是内存和CPU占用还是不小。CPU可能飚至80-90，内存大致在3位数。假死情况也是时有发生，不过就是有时候能恢复正常，比FF2表现略佳。

好的方面也是有，Tab切换的速度，页面的流畅度都有提升，但是这个是感觉，因人而异。智能地址栏还是很有特点，包括一键站点信息，还是很方便的。书签方面的改进并没有去体验，还是保持使用del.icio.us的插件，所有的书签也是存放在上面，本地完全不存放。

插件方面不必有大的担心，总是会有更新保证你的使用，需要的是等待。一些插件的使用情况可以参见前一篇。

FF3RC2的话应该在6.6能够面世，不清楚还有没有RC3。RC多些倒也无所谓，我只希望FF3面世有一个稳定的表现，对于FF3的市场拓展应该是很有好处。FF目前也有一个活动，是承诺在下载日下载Firefox 3来创造吉尼斯世界记录。我也参加了，不过要是参加的人都能发些纪念品就好了，哈哈哈。。。

美味书签 [2008-05-29]:louyuhang @ del.icio.us

Thu, 29 May 2008 00:00:00 +0800

Firefox 3.0 RC1使用初体验

David Lou — Tue, 20 May 2008 23:51:49 +0800

今天终于对于firefox 2.0版本的内存及CPU使用问题忍无可忍！在本身就很慢的破机器上，firefox更是日趋不稳定。偏巧我又是个已经离不开firefox的使用者了，于是下决心试试之前还不是很想切换的3.0RC1。不想切换的原因很简单，做小白鼠是辛苦的，要面对很多问题。不过既然RC1了，而且3.0也不是出来一时半会了，想来能从www上获得相当的支持。

下载安装不表。安装是全新的，之前把FF2的所有目录全部删除，迎接3的到来。

安装以后打开的第一感觉就是快。界面上改动不表，并没有太注意这些细节。但是地址栏还是值得提一提，确实方便，提示功能比以前要更实用，打入关键字后会搜索历史并显示标题及链接，关键字有下划线表示，中文支持亦备。

打开附加组件菜单，首先默认显示推荐组件，个人倒以为未必好。虽然推荐的都是很好的东西，但未必各个用得到。但是集成了组件搜索，还是不错的，只要记得大概的名字，获取还是很快的，值得推荐。

不过说到组件，还是有很多不能兼容的。相信并不是问题，并且这也是一次洗牌的过程，FF的插件极大丰富，功能无可避免有重复的。这次正好可以淘汰一批已经无人或无能力维护的组件，让新人崭露头角。下面是张列表，其中包括我原来FF2中使用的组件，列出在FF3中的情况：

组件名	FF3RC1兼容与否	FF3中可替代组件
Adblock Plus	Y
Adblock Filterset.G Updater	Y
Better Gmail 2	Y
Customize Google	Y
Delicious Bookmarks	N	已有测试版本
Fasterfox	N
Firebug	N	已有测试版本
Fire Cookie	N
Gladder	N
Gmail Manager	Y
Gspace	Y
Google Browser Sync	N
Google Notes	Y
Google Toolbar	N
Html Validator	N	已有测试版本
IE Tab	Y
Media Wrap	Y
Search Status	Y
Selenium IDE	N
Super DragAndGo	N	Easy DragToGo
TabMixPlus	N
Web Developer	Y
YSlow	N

总的来说，大部分组件还是有问题，尤其是外部提供，未收录在firefox组件目录中的，如google的相关等。好在基本功能还能满足，因此问题不大，还能凑合。而且很多组件都在新版本开发中，应该过段时间会好很多。开源社区的热情是不能被低估的。再者说来，就冲着FF3带来的性能提升，也是值得升级的。

关于组件的情况，可以参考这个帖子，列的很详细了，包括了一些beta版的老组件。

哀悼国难

David Lou — Mon, 19 May 2008 12:58:35 +0800

二零零八年五月十二日

国难

二零零八年五月十九日至二零零八年五月二十一日

全国哀悼日

深切哀悼在5.12地震大灾难中逝去的人们

衷心祝愿在5.12地震大灾难中身体和心灵受伤的人们早日康复

愿国难永远被人们铭记

美味书签 [2008-05-19]:louyuhang @ del.icio.us

Mon, 19 May 2008 00:00:00 +0800

URL最大长度限制

David Lou — Tue, 06 May 2008 17:03:00 +0800

在开发调试支付宝接口时，突然发现支付宝接口的URL很长，远远大于之前自己印象中的255个字符。赶紧搜索查证了一番，理解如下：

URL不能大于255bytes的说法确实存在，在RFC2616中提到：

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.
从上一点也可以看出，255bytes的说法也是为了兼容性考虑。实际上现代浏览器的限制如下：

Microsoft Internet Explorer (Browser)
Microsoft states that the maximum length of a URL in Internet Explorer is 2,083 characters, with no more than 2,048 characters in the path portion of the URL. In my tests, attempts to use URLs longer than this produced a clear error message in Internet Explorer.
Firefox (Browser)
After 65,536 characters, the location bar no longer displays the URL in Windows Firefox 1.5.x. However, longer URLs will work. I stopped testing after 100,000 characters.
Safari (Browser)
At least 80,000 characters will work. I stopped testing after 80,000 characters.
Opera (Browser)
At least 190,000 characters will work. I stopped testing after 190,000 characters. Opera 9 for Windows continued to display a fully editable, copyable and pasteable URL in the location bar even at 190,000 characters.
Apache (Server)
My early attempts to measure the maximum URL length in web browsers bumped into a server URL length limit of approximately 4,000 characters, after which Apache produces a “413 Entity Too Large” error. I used the current up to date Apache build found in Red Hat Enterprise Linux 4. The official Apache documentation only mentions an 8,192-byte limit on an individual field in a request.
Microsoft Internet Information Server
The default limit is 16,384 characters (yes, Microsoft’s web server accepts longer URLs than Microsoft’s web browser). This is configurable.
Perl HTTP::Daemon (Server)
Up to 8,000 bytes will work. Those constructing web application servers with Perl’s HTTP::Daemon module will encounter a 16,384 byte limit on the combined size of all HTTP request headers. This does not include POST-method form data, file uploads, etc., but it does include the URL. In practice this resulted in a 413 error when a URL was significantly longer than 8,000 characters. This limitation can be easily removed. Look for all occurrences of 16×1024 in Daemon.pm and replace them with a larger value. Of course, this does increase your exposure to denial of service attacks.
另外值得注意的是，有文章提到作为<a>的href属性时，URL不能超过1024bytes，这点没有详细查证

综上，URL还是不适合太长，不是不得已，尽量不要通过GET方式提交大量参数，可以考虑用POST方式（大约在2M左右，应该是和服务器及设定有关）。另外这么长的URL在访问和收藏（有文章提到有些浏览器在收藏超长地址时也是会出现问题）时也是相当不友好的。当然，之前数据库字段设置时还是作为255bytes处理，现在可能要考虑扩充一下了。

参考：

计划重新设计一个自己的主题

David Lou — Mon, 05 May 2008 22:05:26 +0800

(Last Update: 计划暂时搁置，目前使用Xu Yiyang 的 RGB 1.1主题)

搬家到这里开始使用wordpress后，挑选了好几个主题，加了一些插件，可是还是觉得有些不爽和不合适的地方。虽然关于插件方面还没有整理出自己的需求，但是主题可以先着手做起来，也可以顺带熟悉一下wordpress这个不错的blog系统，还可以练练很久没写的css。不过估计设计就没法做了，肯定不如人家的好看，毕竟photoshop这个东西自己始终没提起勇气去学。当然，主要是自己也没那方面的感觉，呵呵。

从简单做起，期待自己的WP主题诞生。

页脚 (footer.php)
页眉 (header.php)
主页面模板 (index.php)
CSS 样式表 (style.css)
Archives (archives.php)
评论 (comments.php)
存档页 (archive.php)
404 页 (404.php)
Links (links.php)
弹出式评论 (comments-popup.php)
image.php (image.php)
模板函数 (functions.php)
页面模板 (page.php)
搜索结果页 (search.php)
搜索表单 (searchform.php)
侧边栏 (sidebar.php)
单篇日志页 (single.php)

在数据库上发生的一些有趣的事

David Lou — Mon, 11 Jun 2007 15:32:30 +0800

这段时间网站的数据在不断增长,数据量不断加大,同时并发的数据操作也比较频繁了起来,一些问题就慢慢浮出水面了.症状就是网站的前后台都是不定期的突然很缓慢,页面读取的进度条一直在缓慢读取,一般来说大概需要一分钟的时间才变得正常.但是过一会又会突然卡死,一时不知道是什么原因导致,之前都很正常.有一个小细节是但是重启了数据库以后一切恢复正常,但是好景不长,过了一段时间又会复现,游魂不散.

日子在困惑中过去,直到有一天在本地编写程序时,使用SQL Manager 2005 For MySQL连接局域网的数据库查看数据,突然发现读取一个视图巨慢,高达50多秒,太不正常了…于是滑行到部门大牛老大身边讨论这个不寻常的情况,一番讨论和实验后发现视图的写法有小小问题,在视图语句中使用了一个UNION操作,开始怀疑,search一番后改成UNION ALL,情况基本没大改善.继续研究,发现把UNION的两个部分分拆开执行都是巨快,瞬间觉得光明大神出现,将视图拆分成两个视图,然后跑了跑前台程序,发现有快,觉得应该是解决问题.初步断定是因为视图中不合适的UNION操作拖累了整个数据库,导致其它的读取写入操作不能迅速执行,周四在快乐中结束.

第二天一早回归单位,才发现问题依然存在,在怀疑了一遍程序中有遗留的地方仍然在读老视图后又被结果无情推翻后,再度无限迷惑,不知道这个缓慢瘟神什么时候才离开宝贝数据库…Anyway,新网站还是上线了(www.easytvc.com),虽然有如水土不服脸上小爆了几个火气的美女…

时间滑过了两天,今天回到单位时,听闻媒体部周末加班录数据时状况惨烈,整个网页操作慢到如同回归33.6K小猫时代,显然这不是什么网络问题,数据库啊…

大拿上午已经开始研究了,我边看自己的事,然后不断滑行过去以崇拜和无奈的眼光看着大拿操作…后来发现表经常有死锁,是在命令行下用show processlist(很奇怪在phpmyadmin里并看不到有lock的进程),然后发现有个sql可疑的很,号称在copying to tmp table,然后要3XX(单位不明,可能是秒)的时间,无奈看不到完整的sql语句,后来改用show all processlist,显示出一句话:
SELECT channel_id, channel_name
FROM channel
JOIN normal ON normal_id = normal_channel_id
JOIN package ON channel_id = package_channel_id
WHERE channel_valid = ‘T’
AND normal_valid = ‘T’
AND package_valid = ‘T’
GROUP BY channel_name

首先发现group by操作有问题:

1.channel_name未索引;

2.channel_name是个字符型字段;

3.据称mysql在执行group by的时候会自动再做一个order by.

后来加上了一个order by null,可以强制mysql不再排序,速度有快很多,欣喜一下.然后发现如果不加那个order by null,即使是group by channel_id(主键)时,或者是直接order by channel_id时,都是巨慢,再度困惑,觉得mysql可以去撞墙,怎么会这么差…不过….只见大拿眼睛一亮,发现normal_id和normal_channel_id同属normal表,构成了一个完美的自链接,如此一来,大致会产生40G左右的数据,无怪乎执行一个copying to tmp table要那么久,说起来还算快地…

所以,这个故事告诉我们:

1.show all processlist用来监视进程很好,可以确定出问题的语句;

2.mysql也许是聪明过头,group还再搭个order,当然以后不管是group还是order,尽量避开字符型字段为好,总是会降低性能的;

3.join语句写的时候要小心,不要手一抖就产生了一个巨量的数据…