Wiki 这么反人类的语法是怎么存在这么久的？？？？？？？

总之受不了 Wiki 语法的可维护性了。什么？这玩意儿有维护性？？？

以及万年不更新的各种插件。系统升级后 PHP 7 不兼容，一看还是 swiftmail 的问题。生气。

正好有需求要整合一套知识库平台，搜索了一下 Confluence 的 alternative，发现了 BookStackApp 和 Phabricator。

前者适合个人或开源社区使用，后者则是一整套企业协作解决方案。对于我的需求来讲，BookStackApp 就足够啦。

页面数据

DokuWiki 并不使用数据库，因此没有一个通用的中间件来实现数据格式转换。而 DokuWiki 的语法非常奇葩——比如，它的一级标题是 ====== 这样 ======，六级标题才是 = 这样 =，正好和一般的 Wikitext 倒置。图片、内链等的表达方式也相当愚蠢，这些问题使我在思考迁移方案的第一个小时内就放弃了直接从源码转移的途径。

顺便，还有另外一个问题——本来为了使 Wiki 易于编写，这 DokuWiki 还安装了 Markdown 插件。因此部分页面中混杂着 Markdown 语法，更增加了源码处理的复杂度。

综合来看，最通用的数据格式，就是最终渲染出来的 XHTML 了。

图片

DokuWiki 的图片存储策略也是非常的奇特。由于它没有数据库，因此为了保持图片与页面的对应，它将图片存储在每个页面同样的路径下，并通过执行 PHP 的方式获取（扶额。

更甚者！！！

外链的图片，也是通过 /lib/exe/fetch.php 带参数来获取！！

我 的 天 哪。

因此既然在页面数据的考量中决定了使用最终渲染输出的 XHTML 来处理数据格式，图片也需要特殊的下载和归档技巧。这将需要使用 sanitize-html 提供的 transformer 方法来实现。

逻辑实现

一开始尝试了一些 Site Exporter 插件，但遗憾的是并没有什么真正能派上用场。甚至一些暴力递归下载所有页面和资源的脚本的表现也非常糟糕。

但是根据 DokuWiki 的官方 Tips，它可以将文章内容单纯导出 XHTML，只需要加上 ?do=export_xhtmlbody 参数即可。这就方便了，因为这样只需要一个完整的页面列表就可以了。随便找一个可以输出子命名空间的插件，新建一个页面用于从根命名空间展开就 OK 啦。

请求这个列表页面的 XHTML body 输出，使用 cheerio 遍历所有的 a 标签，就获得了所有要导出的页面地址。分别再去请求这些页面的 XHTML body 输出，做如下处理：

  1. 跟踪所有的 img 标签，下载图片文件并按预定义的路径规则和文件名归档。
  2. sanitize-html 清除所有不必要的标签、样式、id 和 class。
  3. sanitize-html 按预定义的路径规则更新所有 a 和 img 标签属性。

看代码

后来发现 DokuWiki 的性能不足以支撑异步请求的速度，额外加上了 sleep 模块来控制请求频率（扶额。

脚本执行完后，将图片目录移动到 BookStackApp 的对应位置，便可以直接读取所有的 HTML 文件来导入数据啦。

用了这么久，才发现原来还有比 raw HTML 更难以维护的数据格式啊…（望天。