早上发了个帖子后来删了，因一位坛友的提醒，惊觉大家有一个普遍的担心，就是释义html内容复杂结构难以统一。
所以我进一步想，论坛是不是可以发起一个项目，目标是做一个像bs4这样的专门针对mdict源文件的python扩展包，大家都可以贡献自己的子模块，站长来做项目的维护者，决定哪些模块可以正式纳入项目。子模块如果不想对释义进行结构化处理，大可将其视为一个黑箱，继续用通用的xml解析工具进行处理。子模块如果能够提出对释义内容的进行结构化处理的优质方案，可以通过解析模块的参数限定反过来推动释义部分的规范化。
说不定几年之后，一个基于现有的mdx源文件规范（这个规范的优点是极其简单所以可扩展性强）的新规范和一个相应的解析包就在本论坛诞生了，最终可能成长为一个集生产和使用mdx于一体的完整解决方案。在内容的管理和呈现方式上，mdx应该说和epub具有高度的互补性，前途不可限量，未来的epub阅读器说不定会把加载mdx作为标配。
（删除的内容）学习OOP编程的朋友可以试试，练练手应该还不错
import mdict
source = open('LDOCE5.txt')
content = source.read()
myDict = mdict(content)
myDict.entry[0].title = "epicurean"
myDict.entry[0].definition[0].type = "adj."
myDict.entry[0].definition[0].content = "享乐主义的"
myDict.entry[0].definition[1].type = "n."
myDict.entry[0].definition[1].content = "享乐主义者"
1 个赞
xdxf了解一下，至于mdx我是根本不做指望，至于为什么，你爬一个网站洗一遍数据你就知道了
1 个赞
你说的这个xdxf用户恐怕远不及mdx吧？mdx有一个现成的生态，这也重要啊
xdxf好歹有个模板，mdx要套也还是可以的，但是，你看后半段啊
我用offline explorer也爬过洗过，不太明白你说的这个和mdx有什么关联？
我认为对mdx的批评都没有说服力，mdx源文件的格式极其简单，简直可以说没有任何规范，所以似乎也没有什么可批评之处，需要新的功能自己扩展就行了。
正使因为没有规范，各种网站，包括各种光盘、硬盘、软件的资源，他们的格式都不一样，想要用统一的api去访问，代价太高
为什么前几年推nosql，不要关系型数据库，也是这种原因（扯远了）
我相信已经有各种工具可以做类似的工作。
但是，现在 mdict 已经有一个初步的生态，一个项目从 0 到 1 是最难的。有这个生态在，一个工具包项目就有逐步成长的机会，因为哪怕项目中目前只有一个函数，只要它有实用性，就会有用户，就能成长。
非也。
你要兼容A网站，就得写A的adaptor
你要兼容B程序，你又要写B的adaptor
如果其中一个网站的接口变了（就像最近的韦氏），你又得更新版本
结果倒腾来倒腾去，就是个无底洞
虽然有人会说“发挥群众的力量也不错”
但是真有那么多人会去维护吗？
还有最绕不开的版权问题。
你恐怕误解我的意思了，我不是在特别针对爬网站做字典，我说的是解析一般的mdx源文件，就是一个一个的词条。
你要做一般的mdx源文件就要面对以上问题，否则你做的东西只能解析特定的词典，这才是重点，重点不是网站
1 个赞
mdx源文件在制作之后的可管理性也是很重要的，一个典型的例子就是添加繁简索引这样的工作，完全就是一个子程序就能解决的问题。（当然有人会认为“添加繁简索引”这样的工作毫无必要，但这不是此处讨论的话题。）
那就更是无底洞了，stripkey和繁简转换、构词法就没一个统一行为，也没有一个统一的答案
没有大量用户基础，再怎么好的标准都苍白无力
javascipt标准化现在这么成熟了，有人还拿着mdict的垃圾IE引擎问为什么弹窗
如果mdx端有一套可行的模板和相应的解析的工具，把抓取到的数据进行结构化处理似乎没有想象的那么困难。
繁简转换这样的工作用一个子程序来做应该是很简单事吧，当然如果你要说机器做繁简转换不可靠那就没办法了。象oed那样的网站css做的极其细致，明显本身就是从服务器上的数据库里生成的，再格式化回去并不难。
现在 mdict 的生态应该说不算小了，完全有条件发展起来。
以现有的生态为基础，完善制作工具和格式的标准化，新的比mdict和GD更开放更好的查词终端的出现只是迟早的事。
我是一个普通的词典用户，使用时间也不短，这还不够啊 
至少在免费(db)的开放词典社区，mdict应该是第一吧？还有竞争者吗？
这个就没法说了，电子书也可以读在线版，但是epub还是主流