正在看，mac的词典也有类似标准，能在两者基础上扩展最好。
1 个赞
嗯，也就是说，借助 XML 可以实现更强的查询功能，从功能上来说，这是对之前的一个超越，但阻力是词典作者需要借助一些工具来将原来的数据进行结构化
这让我想到，之前我有过一些自制小词典的需要，虽然 mdx 源文件里的词条是 HTML 格式的，但经过多方考虑，我编制的是 XML 格式的词条。准备整理好后，将 XML 格式的数据提取并转换为 HTML，这样可以借助 XML 的一些优势来导出多种不同数据版本的 HTML，然后再制作成 mdx。不过后来有人做了我需要的词典，就没继续这个计划
1 个赞
你这是洗版的问题，和什么载体无关。HTML 也有很好的例子能区分开不同语言的。
HTML没有办法标准化。参考：https://github.com/soshial/xdxf_makedict/blob/master/format_standard/xdxf_description.md#logical-format
1 个赞
不太明白。标准是人定的，而格式也是人定的。
XML本身就是常用的数据交换格式，HTML不是，XML能转换成任意的数据结构，程序使用很方便，而HTML不行。标准是人定的，但要把XDXF的标准应用到现有的HTML上，肯定复杂到不行，还不如清洗出数据来转成XDXF。
也可以只应用一部分到HTML上，比如ex，ex_orig和ex_tran。
是的XML可以转到任意格式，包括HTML，可以用同一份HTML模板统一所有词典的HTML，可以用一份CSS统一所有词典的样式。
以前在编制 XML 词条时研究了一些东西，开始时没什么头绪，虽然 XML 的编制是完全开放的，但还是想找一下有没有现成的模板可用
后来发现国家标准委有一个现行的推荐标准，就是《辞书条目XML格式》，标准号为 GB/T 23829-2009，我当时编制 XML 词条时就部分参考了这里面的一些名称和格式的约定，这样比较容易形成统一的规范，你可以看看是否用的上
1 个赞
这个是个挺好的优点，值得进一步讨论。
技术上我完全是小白，观点不一定正确。我的理解是，现在的问题是底层数据结构是采用sqlite（也是不透明mdx的方式，缺点是全文索引功能简单）还是xml（优点是标准化，易于深入加工，但技术门槛有点高）。从技术角度来看，后者当然优点多多，方便了高端的词典制作或再加工。
不过从生态圈的源头看，大多词典编纂方没有采用xml。假设说 1）朗文在自家网站出了第七版爬虫下来一堆HTML文件，或者 2）通过破解得到了最新的app牛津英汉辞书的sqlite格式底层数据，不知道新的技术路线在这两者基础上制作新格式的词典，比起现有方式制作mdx，到底有多友好？主要是付出的学习成本貌似不小（制作时间可通过工具缩短），看上去要理解xml绕不过HTML+css知识为基础？人的惰性惯性到底有多大？不乐观。
说到底，吸引用户才是生命力所在，即便是开源项目。各个链条各相关方都需要照顾到，整个生态圈才能繁荣起来，步入良性循环。
再或者，xml值得一试，先试试水看看，但也做好退而求其次回到sqlite的准备。这就要看楼主愿意花的时间了。但对于这类无私奉献的事情，我总是建议小目标，细水长流。
不管结果如何，希望在此过程中大家或多或少都有收获。
2 个赞
这种标准最大的问题是过于疏漏，不易扩展。
我自己动手仔细排版过牛津九Online版的css，发现除了普通词条的最基本格式之外，里头还有各种辨析、Usage、文化知识等等小栏目，不胜枚举，边用边排，总是发现排版上有所疏漏。不必说，朗文柯林斯等其他各家词典各具特色，还会有形形色色的其他小栏目，根本不是一个先入为主的辞书标准所能囊括下全部内容的。
不过这或许能启发我们，为什么大多词典编纂方没有采用xml。因为HTML标签的可扩展性，实在是太灵活了，方便新版本增添新的内容。
1 个赞
HTML 实际上是用来显示数据的，难以准确的描述和存储数据，搜索时间也长，所以后来为了解决这些问题，就诞生了 XML，它的中文名称是可扩展标记语言，解决了 HTML 难以扩展数据的问题
辞书条目的 XML 格式之所以有现行的国家推荐标准，是因为 XML 的可扩展性强，各种特色元素（如各种用法、辨析和小常识等）都可以为其定制相关的标签来作为存储单元。这套标准只是一个框架作为参考，已经覆盖了大部分需要，具体到每本辞书的编制上，还需要根据实际情况来自定义少量的特色标签，是很灵活的。
所以出版社编纂辞书的数据，大多是以 XML 格式存储的，我们看到的电子词典的内容之所以是 HTML，是因为它是被显示出来的数据，便于观看但不便于处理，出版社不会把原始数据给读者
2 个赞
妈耶，原来MT发了这么多技术贴了。 
这让水贴的我羞愧难当。
我打算以后经常来论坛水帖。
争取数量全论坛比较靠前。
一次水帖一次爽，一直水帖一直爽。 
1 个赞
这个代码写的并不对.不应该取最小值,而是直接取shadowEndPos.
621行goldendict的代码是RecordIndex.endPos和i->first比,
这里的RecordIndex.endPos是这个record块压缩后的结束位置相对于所有压缩后的record块起始位置的偏移(523行).
这里的i类型是pair<qint64, QString>,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. 和最早的readmdict.py都没有这个问题.这个问题只是goldendict特有的.
2 个赞
之前没细想，确实是这样，应该直接用shadowEndPos，感谢指导！
1 个赞