• 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

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

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

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

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

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

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

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

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

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

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

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

国难

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

全国哀悼日

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

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

愿国难永远被人们铭记

1. 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.

2. 从上一点也可以看出，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.

3. 另外值得注意的是，有文章提到作为<a>的href属性时，URL不能超过1024bytes，这点没有详细查证

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

参考：

1. What is the maximum length of a URL?
2. What is the limit on QueryString / GET / URL parameters?

从简单做起，期待自己的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)

日子在困惑中过去,直到有一天在本地编写程序时,使用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,显示出一句话:

首先发现group 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要那么久,说起来还算快地…

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