在编写将 wiktionary dumps 转为词典文件的开源工具

个人一直很向往开源世界,正好打算学习一下 Python 这门语言,于是考虑用它实现这样一个工具。

wiktionary 提供了如 Index of /enwiktionary/latest/ 这样的存档文件,不过这也就涉及到处理大文件的一系列问题。

我是倾向于优先考虑内存占用,其次考虑并行,于是这就要考虑每个步骤的流。

  1. bz2 流:很幸运,bz2 这个格式以及 Python 核心库都支持这一点,很简单的 bz2.BZ2File 就可以做到;
  2. xml 解析流:SAX 方式解析,核心库的 pulldom.parse 实现这一点也很方便;

基于以上两点,并配合开源社区的 wikitextparser,仅遍历和解析 enwiktionary-latest-pages-articles.xml.bz2( 950MB,解压后 7.3 GB ) 在我的笔记本上花费 30-40 分钟,只能跑满一个核心,内存占用很低。

  1. 并行解析,这个我没有办到,可能基于这种思路也很难办到

  2. mdx/mdd 写入流:闭源实在是让我头疼,在看前辈们的资料和源码来探索流处理的可能性。

挑选词典格式也是很头疼的事情,个人使用 Goldendict Desktop 和欧路 iOS,交叉一下似乎也没有什么开源友好的格式。

目前完成度还很低,欢迎参与!个人 Python 经验很少,也欢迎指出源码或者结构方面的任何问题!有任何关于此项目的建议也可以通过 issues 或者本帖告诉我。

附上链接( 字换成小写的字母 o):

https://github.c圈m/hell圈dw圈rd/wikti圈nary2dict

1 个赞

你网址打码干嘛?

MDX MDD 的写入:mdict-utils · PyPI

1 个赞

回复太长被当 spam 了,我重新编辑一下。

大致就是:

  1. 目前没有生成 sample mdx,但是我对比了 dumps 里面的一些 page 和网站上的对应词条,似乎没有什么缺少的数据,可能更多是解析问题?所以作为优先级最低的部分了,打算在解决完词典写入问题后再考虑详细的解析和排版,这个相对比较简单。

  2. 爬取所有词条会对 Wiktionary 造成负担,个人不希望也不建议大家这样做。


十分感谢你补充的例子,我将 ['a', 'of', 'to', 'in', 'for', 'have', 'you', 'let', 'make', 'get', 'free', 'idiom', 'the', 'be', 'and'] 这些词 grep 出来附到 data/en.sample.xml 里了。我对于专业人士的词典需求不太了解,方便的话你可以看看 xml 文件里和 Wiktionary 网页上相比有什么缺失吗?

1 个赞

zim格式的词典?

打码是避免被搜索引擎关联

这些开源的 writemdict 的问题在于它们都是一次性写入所有词条,面对 wiktionary 会造成很高的内存负担,这也是我目前努力想避免的

1 个赞

调研的时候发现 zim 在 iOS 上似乎没有多少客户端支持?

对 mdx 结构不了解,看到排序、stripkey、block 已经晕了,真能一条一条地写入?

陆陆续续有人在爬,跟网站正常访问量相比,这点负担算不了什么。

可以的,先写RecordBlock,再写KeyBlock,最后拼起来。

在 readme 里有写一点点,目前看起来是有希望的

1 个赞

我认为还是很有负担的,仅 wiktionary 就有千万级的页面。

enwiktionary 一天的正常用户请求也就几十M

https://stats.wikimedia.org/#/en.wiktionary.org/reading/total-page-views/normal|line|1-year|agent~user|monthly

由于是期望做开源工具,用户数量是未知的,所以我个人比较在意这种数字。

GoldenDict 在第一次索引词库的时候,是不是也是所有词库一起索引的?
好像不是一个词库索引完,释放内存那种(直观感觉,不确定)。感觉这是GoldenDict可以优化的点

GD是遍历词典目录,发现一个索引一个。会释放内存吧,我这感觉不到没释放。

没看过代码,总感觉全部索引完才释放内存 :joy: 也许是错觉