2006年2月26日星期日 15:39,
1. magic_quotes_gpc=on:
\ => \\
' => \'
" => \"
2. 当 \' 、\" 插入数据库时，字符并没有变化，仍然为 ' 和 " 。因此读出时无需再次stripslashes。
例外：magic_quotes_runtime=on时。
3. preg_replace的pattern中使用 /e 修正符，则replacement传递到callback函数中的情形为：
\ => \
' => '
" => \"
4. 从数据库中读取，当magic_quotes_runtime=off时，似乎 \ => 空 ？
总结：引号和反斜杠的问题很复杂，而且因各服务器的设置不同而千变万化。
现在我的解决方法是
\ => & #92;
引号则用 htmlspecialchars ，quote_style设置为 ENT_QUOTES。
希望SP1版本中贴代码的问题能够解决。
\ => \\
' => \'
" => \"
2. 当 \' 、\" 插入数据库时，字符并没有变化，仍然为 ' 和 " 。因此读出时无需再次stripslashes。
例外：magic_quotes_runtime=on时。
3. preg_replace的pattern中使用 /e 修正符，则replacement传递到callback函数中的情形为：
\ => \
' => '
" => \"
4. 从数据库中读取，当magic_quotes_runtime=off时，似乎 \ => 空 ？
总结：引号和反斜杠的问题很复杂，而且因各服务器的设置不同而千变万化。
现在我的解决方法是
\ => & #92;
引号则用 htmlspecialchars ，quote_style设置为 ENT_QUOTES。
希望SP1版本中贴代码的问题能够解决。
2006年1月27日星期五 16:15,
如果您在修改任何PHP文件后发生：
本程序采用UTF-8编码。现在几乎所有的文本编辑软件都可以显示并编辑UTF-8编码的文件。但是很遗憾，其中很多软件的表现并不理想。
类似WINDOWS自带的记事本等软件，在保存一个以UTF-8编码的文件时，会在文件开始的地方插入三个不可见的字符（0xEF 0xBB 0xBF，即BOM）。它是一串隐藏的字符，用于让记事本等编辑器识别这个文件是否以UTF-8编码。对于一般的文件，这样并不会产生什么麻烦。但对于PHP来说，BOM是个大麻烦。
PHP并不会忽略BOM，所以在读取、包含或者引用这些文件时，会把BOM作为该文件开头正文的一部分。根据嵌入式语言的特点，这串字符将被直接执行（显示）出来。由此造成即使页面的 top padding 设置为0，也无法让整个网页紧贴浏览器顶部，因为在html一开头有这3个字符呢！
- 不能登入或者不能登出；
- 页顶出现一条空白；
- 页顶出现错误警告；
- 其它不正常的情况。
本程序采用UTF-8编码。现在几乎所有的文本编辑软件都可以显示并编辑UTF-8编码的文件。但是很遗憾，其中很多软件的表现并不理想。
类似WINDOWS自带的记事本等软件，在保存一个以UTF-8编码的文件时，会在文件开始的地方插入三个不可见的字符（0xEF 0xBB 0xBF，即BOM）。它是一串隐藏的字符，用于让记事本等编辑器识别这个文件是否以UTF-8编码。对于一般的文件，这样并不会产生什么麻烦。但对于PHP来说，BOM是个大麻烦。
PHP并不会忽略BOM，所以在读取、包含或者引用这些文件时，会把BOM作为该文件开头正文的一部分。根据嵌入式语言的特点，这串字符将被直接执行（显示）出来。由此造成即使页面的 top padding 设置为0，也无法让整个网页紧贴浏览器顶部，因为在html一开头有这3个字符呢！
今天接到访客carloschen的报告，称：“試過在別人網誌留言會重複發文好幾篇”。
如果您的blog也遇到了同样的问题，你可以直接跳到我这篇日志的结尾看解决方法。假如您有兴趣了解一下这个问题的成因，那么请往下看。
这个情况和使用的习惯有关。在评论提交处的结尾，是输入验证码的输入框。如果填写完所有信息后，点击下方的“提交”按钮提交评论，那是不会出现问题的。评论在经过处理后会马上反应在页面上，这是符合预期效果的。
但如果用户也可能有这样的习惯，那就是在填完所有信息后，如果最后一个输入框是单行的文本框，那么直接按键盘上的回车键就可以提交了。想当初刚刚上网的时候，这个还是老鸟作为一个“技巧”传授给我的。IE和Firefox均支持这个特性。
不过问题也产生了。当按回车键在验证码输入框内直接提交这个评论的时候，浏览器没有执行点击“提交”按钮时执行的动作，这样就越过了Ajax提交这个步骤，直接提交了评论，也就是最平常的“有刷新”的提交方式。
这也没什么，顶多就是刷新了一次，不如Ajax这么迅速就能看到评论的效果罢了。但是，由于部分模板在form的onsubmit事件中增加了触发ajax回复的事件，这样就导致了提交两次的问题！
如果您的blog也遇到了同样的问题，你可以直接跳到我这篇日志的结尾看解决方法。假如您有兴趣了解一下这个问题的成因，那么请往下看。
这个情况和使用的习惯有关。在评论提交处的结尾，是输入验证码的输入框。如果填写完所有信息后，点击下方的“提交”按钮提交评论，那是不会出现问题的。评论在经过处理后会马上反应在页面上，这是符合预期效果的。
但如果用户也可能有这样的习惯，那就是在填完所有信息后，如果最后一个输入框是单行的文本框，那么直接按键盘上的回车键就可以提交了。想当初刚刚上网的时候，这个还是老鸟作为一个“技巧”传授给我的。IE和Firefox均支持这个特性。
不过问题也产生了。当按回车键在验证码输入框内直接提交这个评论的时候，浏览器没有执行点击“提交”按钮时执行的动作，这样就越过了Ajax提交这个步骤，直接提交了评论，也就是最平常的“有刷新”的提交方式。
这也没什么，顶多就是刷新了一次，不如Ajax这么迅速就能看到评论的效果罢了。但是，由于部分模板在form的onsubmit事件中增加了触发ajax回复的事件，这样就导致了提交两次的问题！
2006年1月19日星期四 22:57,
今天在修改数据库备份和导出部分时，遇到了怪事一桩。确认程序无误的情况下，导入怎么也不成功，MySQL报错为“Column count doesn't match”。查了半天也不知道原因，只好让程序一行行地检查备份数据。结果发现，问题出在某一篇很长的日志上。这篇日志的数据被php的gzfile()函数断为两行，难怪SQL语句会出错。
为了确认这是我的rpwt还是php的问题，到php.net上一看，果然有人反应了类似的问题：
好吧，承认被这个东西打败了。这个问题看来不只是4.4.1的问题，我在本机测试时php版本为5.0，也没有解决这个问题。看来现在暂时的解决方法是，大家在备份的时候不要选‘gz’格式，直接备份为bak文件。或者备份成gz文件，在导入之前手动解压成bak文件上传。
提示您的是备份和导入部分已经修改过，尽可能减少了发生错误的概率。请您到这个帖子下载新的程序：
http://www.bmforum.com/bmb/topic.php?filename=110752
为了确认这是我的rpwt还是php的问题，到php.net上一看，果然有人反应了类似的问题：
引用自 http://cn.php.net/manual/en/function.gzfile.php
In PHP4.4.1 I noticed that gzfile only reads up to 8190 bytes per line. I had a 20K SQL query that was cut into 3 parts - and wondered why the SQL server complained.
Reading an uncompressed file with the file() command works as expected.
Reading an uncompressed file with the file() command works as expected.
好吧，承认被这个东西打败了。这个问题看来不只是4.4.1的问题，我在本机测试时php版本为5.0，也没有解决这个问题。看来现在暂时的解决方法是，大家在备份的时候不要选‘gz’格式，直接备份为bak文件。或者备份成gz文件，在导入之前手动解压成bak文件上传。
提示您的是备份和导入部分已经修改过，尽可能减少了发生错误的概率。请您到这个帖子下载新的程序：
http://www.bmforum.com/bmb/topic.php?filename=110752
