# MDX开源实现无法读取部份图片的问题 **URL:** \ **Category:** 技术交流与词典编修\ **Created:** [2020 年4 月 4 日 05:52 UTC](https://forum.freemdict.com/t/topic/1329 "2020-04-04T05:52:16Z")\ **Posts on this page:** 15\ **Page:** 2
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2020 年4 月 11 日 13:41 UTC](https://forum.freemdict.com/t/topic/1329/30 "2020-04-11T13:41:58Z")
正在看，mac的词典也有类似标准，能在两者基础上扩展最好。 ---
作者： ![Word](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/word/32/696_2.png) [@Word](https://forum.freemdict.com/u/Word)\ 发布日期： [2020 年4 月 11 日 13:56 UTC](https://forum.freemdict.com/t/topic/1329/31 "2020-04-11T13:56:49Z")
嗯，也就是说，借助 XML 可以实现更强的查询功能，从功能上来说，这是对之前的一个超越，但阻力是词典作者需要借助一些工具来将原来的数据进行结构化 这让我想到，之前我有过一些自制小词典的需要，虽然 mdx 源文件里的词条是 HTML 格式的，但经过多方考虑，我编制的是 XML 格式的词条。准备整理好后，将 XML 格式的数据提取并转换为 HTML，这样可以借助 XML 的一些优势来导出多种不同数据版本的 HTML，然后再制作成 mdx。不过后来有人做了我需要的词典，就没继续这个计划 ---
作者： ![hua](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/hua/32/11090_2.png) [@hua](https://forum.freemdict.com/u/hua)\ 发布日期： [2020 年4 月 11 日 14:25 UTC](https://forum.freemdict.com/t/topic/1329/32 "2020-04-11T14:25:40Z")
你这是洗版的问题，和什么载体无关。HTML 也有很好的例子能区分开不同语言的。 ---
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2020 年4 月 11 日 14:27 UTC](https://forum.freemdict.com/t/topic/1329/33 "2020-04-11T14:27:24Z")
HTML没有办法标准化。参考：[https://github.com/soshial/xdxf\_makedict/blob/master/format\_standard/xdxf\_description.md#logical-format](https://github.com/soshial/xdxf_makedict/blob/master/format_standard/xdxf_description.md#logical-format) ---
作者： ![hua](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/hua/32/11090_2.png) [@hua](https://forum.freemdict.com/u/hua)\ 发布日期： [2020 年4 月 11 日 14:29 UTC](https://forum.freemdict.com/t/topic/1329/34 "2020-04-11T14:29:14Z")
不太明白。 **标准是人定的** ，而格式也是人定的。 ---
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2020 年4 月 11 日 15:01 UTC](https://forum.freemdict.com/t/topic/1329/35 "2020-04-11T15:01:00Z")
XML本身就是常用的数据交换格式，HTML不是，XML能转换成任意的数据结构，程序使用很方便，而HTML不行。标准是人定的，但要把XDXF的标准应用到现有的HTML上，肯定复杂到不行，还不如清洗出数据来转成XDXF。 ---
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2020 年4 月 11 日 15:31 UTC](https://forum.freemdict.com/t/topic/1329/36 "2020-04-11T15:31:27Z")
也可以只应用一部分到HTML上，比如ex，ex\_orig和ex\_tran。 ---
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2020 年4 月 11 日 15:46 UTC](https://forum.freemdict.com/t/topic/1329/37 "2020-04-11T15:46:16Z")
是的XML可以转到任意格式，包括HTML，可以用同一份HTML模板统一所有词典的HTML，可以用一份CSS统一所有词典的样式。 ---
作者： ![Word](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/word/32/696_2.png) [@Word](https://forum.freemdict.com/u/Word)\ 发布日期： [2020 年4 月 11 日 16:45 UTC](https://forum.freemdict.com/t/topic/1329/38 "2020-04-11T16:45:20Z")
以前在编制 XML 词条时研究了一些东西，开始时没什么头绪，虽然 XML 的编制是完全开放的，但还是想找一下有没有现成的模板可用 后来发现国家标准委有一个现行的推荐标准，就是《辞书条目XML格式》，标准号为 GB/T 23829-2009，我当时编制 XML 词条时就部分参考了这里面的一些名称和格式的约定，这样比较容易形成统一的规范，你可以看看是否用的上 [《辞书条目XML格式》PDF 下载](http://www.wdfxw.net/Fulltext78775877.htm) ---
作者： ![endnote](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/e/9de0a6/32.png) [@endnote](https://forum.freemdict.com/u/endnote)\ 发布日期： [2020 年4 月 11 日 18:01 UTC](https://forum.freemdict.com/t/topic/1329/39 "2020-04-11T18:01:01Z")
> [@last\_idol](#): > > 例句反查是很强大的功能，不知道能不能吸引到词典作者们的支持 这个是个挺好的优点，值得进一步讨论。 技术上我完全是小白，观点不一定正确。我的理解是，现在的问题是底层数据结构是采用sqlite（也是不透明mdx的方式，缺点是全文索引功能简单）还是xml（优点是标准化，易于深入加工，但技术门槛有点高）。从技术角度来看，后者当然优点多多，方便了高端的词典制作或再加工。 不过从生态圈的源头看，大多词典编纂方没有采用xml。假设说 1）朗文在自家网站出了第七版爬虫下来一堆HTML文件，或者 2）通过破解得到了最新的app牛津英汉辞书的sqlite格式底层数据，不知道新的技术路线在这两者基础上制作新格式的词典，比起现有方式制作mdx，到底有多友好？主要是付出的学习成本貌似不小（制作时间可通过工具缩短），看上去要理解xml绕不过HTML+css知识为基础？人的惰性惯性到底有多大？不乐观。 说到底，吸引用户才是生命力所在，即便是开源项目。各个链条各相关方都需要照顾到，整个生态圈才能繁荣起来，步入良性循环。 再或者，xml值得一试，先试试水看看，但也做好退而求其次回到sqlite的准备。这就要看楼主愿意花的时间了。但对于这类无私奉献的事情，我总是建议小目标，细水长流。 不管结果如何，希望在此过程中大家或多或少都有收获。 ---
作者： ![endnote](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/e/9de0a6/32.png) [@endnote](https://forum.freemdict.com/u/endnote)\ 发布日期： [2020 年4 月 11 日 18:26 UTC](https://forum.freemdict.com/t/topic/1329/40 "2020-04-11T18:26:48Z")
> [@Word](#): > > 《辞书条目XML格式》 这种标准最大的问题是过于疏漏，不易扩展。 我自己动手仔细排版过牛津九Online版的css，发现除了普通词条的最基本格式之外，里头还有各种辨析、Usage、文化知识等等小栏目，不胜枚举，边用边排，总是发现排版上有所疏漏。不必说，朗文柯林斯等其他各家词典各具特色，还会有形形色色的其他小栏目，根本不是一个先入为主的辞书标准所能囊括下全部内容的。 不过这或许能启发我们，为什么大多词典编纂方没有采用xml。因为HTML标签的可扩展性，实在是太灵活了，方便新版本增添新的内容。 ---
作者： ![Word](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/word/32/696_2.png) [@Word](https://forum.freemdict.com/u/Word)\ 发布日期： [2020 年4 月 12 日 01:06 UTC](https://forum.freemdict.com/t/topic/1329/41 "2020-04-12T01:06:10Z")
HTML 实际上是用来显示数据的，难以准确的描述和存储数据，搜索时间也长，所以后来为了解决这些问题，就诞生了 XML，它的中文名称是可扩展标记语言，解决了 HTML 难以扩展数据的问题 辞书条目的 XML 格式之所以有现行的国家推荐标准，是因为 XML 的可扩展性强，各种特色元素（如各种用法、辨析和小常识等）都可以为其定制相关的标签来作为存储单元。这套标准只是一个框架作为参考，已经覆盖了大部分需要，具体到每本辞书的编制上，还需要根据实际情况来自定义少量的特色标签，是很灵活的。 所以出版社编纂辞书的数据，大多是以 XML 格式存储的，我们看到的电子词典的内容之所以是 HTML，是因为它是被显示出来的数据，便于观看但不便于处理，出版社不会把原始数据给读者 ---
作者： ![Brice](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/brice/32/5_2.png) [@Brice](https://forum.freemdict.com/u/Brice)\ 发布日期： [2020 年4 月 12 日 07:05 UTC](https://forum.freemdict.com/t/topic/1329/43 "2020-04-12T07:05:01Z")
妈耶，原来MT发了这么多技术贴了。 :doge: 这让水贴的我羞愧难当。 我打算以后经常来论坛水帖。 争取数量全论坛比较靠前。 一次水帖一次爽，一直水帖一直爽。 🤣 🤣 🤣 ---
作者： ![12101111](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/1/3bc359/32.png) [@12101111](https://forum.freemdict.com/u/12101111)\ 发布日期： [2020 年9 月 4 日 17:31 UTC](https://forum.freemdict.com/t/topic/1329/44 "2020-09-04T17:31:21Z")
这个代码写的并不对.不应该取最小值,而是直接取shadowEndPos. 621行goldendict的代码是`RecordIndex.endPos`和`i->first`比, 这里的`RecordIndex.endPos`是这个record块压缩后的结束位置相对于所有压缩后的record块起始位置的偏移(523行). 这里的i类型是`pair`,`i->first`也就是607行的`headWordId`,是解压后的记录数据的相对于所有未压缩数据的起始偏移量,显然一个是压缩后的偏移量,一个是没有压缩的偏移量,直接比是没有意义的. 而`RecordIndex.shadowEndPos`是这个块解压后相对于所有未压缩数据的结束偏移量,显然应该只用这个比. 在`mdictparser.hh`中重载的`RecordIndex`和`qint64`比较== \< \>的操作符也表面应该用`shadow*Pos`和headWordId比较. 621行的目的就是如果这个词条的起始偏移大于块的结束偏移,那么就在块的列表中找下一个块的索引(idx),这里的偏移都是解压后的偏移. 我实现的mdx库[GitHub - 12101111/mdict\_rs: Rust crates to read and use Octopus MDict Dictionary.](https://github.com/12101111/mdict_rs) 和最早的readmdict.py都没有这个问题.这个问题只是goldendict特有的. ---
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2020 年9 月 4 日 22:24 UTC](https://forum.freemdict.com/t/topic/1329/45 "2020-09-04T22:24:22Z")
之前没细想，确实是这样，应该直接用`shadowEndPos`，感谢指导！ [上一页](https://forum.freemdict.com/t/topic/1329.md?page=1)