此文件对2.0.2sp2的数据备份和导入进行了修改（针对专用格式，RSS备份和导入未修改），提供以下新特性：
*COOKIE的存取全部改由javascript操作，避免在部分情况下无法存入COOKIE导致的无法备份和导入的问题；
*修改了可能引起备份时MySQL提示Table doesn't exist的一个问题；
*可以选择同时备份和导入部分未存储在数据库中的重要数据以及先前不能备份的数据（参数设置、模块内容、自定义表情和天气、当前访问数等）；
*导入数据完成自动刷新一切缓存、计数器、重建日历。
2.0.2sp2用户可下载后解压并上传，覆盖admin/ 下的同名文件。
一次性下载2.0.2sp2发布至今的所有性能增强补丁，请访问这个帖子。
下载“备份导入增强版”：
下载文件
*COOKIE的存取全部改由javascript操作，避免在部分情况下无法存入COOKIE导致的无法备份和导入的问题；
*修改了可能引起备份时MySQL提示Table doesn't exist的一个问题；
*可以选择同时备份和导入部分未存储在数据库中的重要数据以及先前不能备份的数据（参数设置、模块内容、自定义表情和天气、当前访问数等）；
*导入数据完成自动刷新一切缓存、计数器、重建日历。
2.0.2sp2用户可下载后解压并上传，覆盖admin/ 下的同名文件。
一次性下载2.0.2sp2发布至今的所有性能增强补丁，请访问这个帖子。
下载“备份导入增强版”：
下载文件
想将您自定义的模块（比如播放器、天气预报等）导出为模块自动安装文件吗？使用此插件可以方便地做到。
类型： 独立插件
适用版本： Bo-Blog 2.0.2 以上
简介： 将自定义模块导出为可自动安装的 .blog 文件或者压缩文件。可用于自定义模块的备份或者发送给他人。
安装方法：
解压后把文件夹 exportmodules 上传到blog安装目录的 plugin 文件夹下，然后到后台的插件管理界面，输入插件所在文件夹的名字exportmodules即可。
使用时，进入后台的插件管理，点击“ExportModules”插件项的“管理”按钮即可进入。
类型： 独立插件
适用版本： Bo-Blog 2.0.2 以上
简介： 将自定义模块导出为可自动安装的 .blog 文件或者压缩文件。可用于自定义模块的备份或者发送给他人。
安装方法：
解压后把文件夹 exportmodules 上传到blog安装目录的 plugin 文件夹下，然后到后台的插件管理界面，输入插件所在文件夹的名字exportmodules即可。
使用时，进入后台的插件管理，点击“ExportModules”插件项的“管理”按钮即可进入。
此次换服务器，完全是借助程序自带的备份和导入功能完成了平滑的数据迁移工作。在此，我写出备份－导入的大致过程和一些提示，希望有助于各位使用者的数据迁移。
请使用程序的备份与导入功能，而不是PHPMyAdmin等第三方程序导入和导出。这是因为：
- 程序的备份和导入功能是根据程序的实际情况编写的；
- 程序的备份和导入功能是MySQL版本无关的；而第三方程序需要考虑到MySQL的版本、字符集等，会使情况复杂化；
- 程序的备份和导入功能在设计时就考虑到了大数据情况下的分卷备份和分卷导入，而第三方程序的分卷导出与导入并不一定会成功。
当然，PHPMyAdmin等程序的优势在于，它们在导出和导入数据是直接生成/读取SQL语句，因此可以在导入之前修改SQL文本达到修改数据的目的。而程序的导出的则是专用格式和base64编码的数据，无法直接修改。
大致的操作流程：
请使用程序的备份与导入功能，而不是PHPMyAdmin等第三方程序导入和导出。这是因为：
- 程序的备份和导入功能是根据程序的实际情况编写的；
- 程序的备份和导入功能是MySQL版本无关的；而第三方程序需要考虑到MySQL的版本、字符集等，会使情况复杂化；
- 程序的备份和导入功能在设计时就考虑到了大数据情况下的分卷备份和分卷导入，而第三方程序的分卷导出与导入并不一定会成功。
当然，PHPMyAdmin等程序的优势在于，它们在导出和导入数据是直接生成/读取SQL语句，因此可以在导入之前修改SQL文本达到修改数据的目的。而程序的导出的则是专用格式和base64编码的数据，无法直接修改。
大致的操作流程：
今天在修改数据库备份和导出部分时，遇到了怪事一桩。确认程序无误的情况下，导入怎么也不成功，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
分页： 1/1 
