MDX开源实现无法读取部份PNG图片的问题

跟本论坛一样,新开源技术吸引用户应当放在第一位。
用户多了之后,再考虑下一步,没有用户一切无从谈起。

兼容迁就现有用户和技术路线是必要的。如果技术路线跟现有的生态大不一样,通俗说就是门槛高、麻烦,恐怕大多数现有用户还会继续留在mdx生态圈里。毕竟抓取牛津等网站网页清洗成mdx更方便,普通人文科生如我还能改改css。本来这就是个小众圈子没啥人。

当然,作为技术储备探讨xml等新东西也是必要的。

1 Like

对改CSS没影响,最后页面显示还是用浏览器用HTML,只是存储在文件里需要结构化的数据,需要用XML。词典软件本身会支持MDX,对现有用户没影响。考虑数据转换的话,新格式用HTML肯定无缝能转,我出个工具就行,把MDX拖进去就能转出来,但转出来和原来的MDX在使用上没有区别。如果是XML,需要会PYTHON的词典作者的帮助,开始会很困难,但词典数量是有限的,慢慢转能转完现有词典。

例句反查是很强大的功能,不知道能不能吸引到词典作者们的支持。

正在看,mac的词典也有类似标准,能在两者基础上扩展最好。

嗯,也就是说,借助 XML 可以实现更强的查询功能,从功能上来说,这是对之前的一个超越,但阻力是词典作者需要借助一些工具来将原来的数据进行结构化
这让我想到,之前我有过一些自制小词典的需要,虽然 mdx 源文件里的词条是 HTML 格式的,但经过多方考虑,我编制的是 XML 格式的词条。准备整理好后,将 XML 格式的数据提取并转换为 HTML,这样可以借助 XML 的一些优势来导出多种不同数据版本的 HTML,然后再制作成 mdx。不过后来有人做了我需要的词典,就没继续这个计划

1 Like

你这是洗版的问题,和什么载体无关。HTML 也有很好的例子能区分开不同语言的。

HTML没有办法标准化。参考:https://github.com/soshial/xdxf_makedict/blob/master/format_standard/xdxf_description.md#logical-format

不太明白。标准是人定的,而格式也是人定的。

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 词条时就部分参考了这里面的一些名称和格式的约定,这样比较容易形成统一的规范,你可以看看是否用的上

《辞书条目XML格式》PDF 下载

1 Like

这个是个挺好的优点,值得进一步讨论。

技术上我完全是小白,观点不一定正确。我的理解是,现在的问题是底层数据结构是采用sqlite(也是不透明mdx的方式,缺点是全文索引功能简单)还是xml(优点是标准化,易于深入加工,但技术门槛有点高)。从技术角度来看,后者当然优点多多,方便了高端的词典制作或再加工。
不过从生态圈的源头看,大多词典编纂方没有采用xml。假设说 1)朗文在自家网站出了第七版爬虫下来一堆HTML文件,或者 2)通过破解得到了最新的app牛津英汉辞书的sqlite格式底层数据,不知道新的技术路线在这两者基础上制作新格式的词典,比起现有方式制作mdx,到底有多友好?主要是付出的学习成本貌似不小(制作时间可通过工具缩短),看上去要理解xml绕不过HTML+css知识为基础?人的惰性惯性到底有多大?不乐观。

说到底,吸引用户才是生命力所在,即便是开源项目。各个链条各相关方都需要照顾到,整个生态圈才能繁荣起来,步入良性循环。

再或者,xml值得一试,先试试水看看,但也做好退而求其次回到sqlite的准备。这就要看楼主愿意花的时间了。但对于这类无私奉献的事情,我总是建议小目标,细水长流。
不管结果如何,希望在此过程中大家或多或少都有收获。

1 Like

这种标准最大的问题是过于疏漏,不易扩展。

我自己动手仔细排版过牛津九Online版的css,发现除了普通词条的最基本格式之外,里头还有各种辨析、Usage、文化知识等等小栏目,不胜枚举,边用边排,总是发现排版上有所疏漏。不必说,朗文柯林斯等其他各家词典各具特色,还会有形形色色的其他小栏目,根本不是一个先入为主的辞书标准所能囊括下全部内容的。

不过这或许能启发我们,为什么大多词典编纂方没有采用xml。因为HTML标签的可扩展性,实在是太灵活了,方便新版本增添新的内容。

1 Like

HTML 实际上是用来显示数据的,难以准确的描述和存储数据,搜索时间也长,所以后来为了解决这些问题,就诞生了 XML,它的中文名称是可扩展标记语言,解决了 HTML 难以扩展数据的问题
辞书条目的 XML 格式之所以有现行的国家推荐标准,是因为 XML 的可扩展性强,各种特色元素(如各种用法、辨析和小常识等)都可以为其定制相关的标签来作为存储单元。这套标准只是一个框架作为参考,已经覆盖了大部分需要,具体到每本辞书的编制上,还需要根据实际情况来自定义少量的特色标签,是很灵活的。
所以出版社编纂辞书的数据,大多是以 XML 格式存储的,我们看到的电子词典的内容之所以是 HTML,是因为它是被显示出来的数据,便于观看但不便于处理,出版社不会把原始数据给读者

1 Like

看牛九3.1.3的数据,里面的词条主要还是XML,超链接这块混合了XHTML用于跳转,辨析这块是HTML。之前看过有道词典和单词本的数据也是XML的。

里头还有各种辨析、Usage、文化知识等等小栏目

这确实是需要考虑的问题。

妈耶,原来MT发了这么多技术贴了。 :doge:
这让水贴的我羞愧难当。
我打算以后经常来论坛水帖。
争取数量全论坛比较靠前。

一次水帖一次爽,一直水帖一直爽。 :rofl: :rofl: :rofl:

这个代码写的并不对.不应该取最小值,而是直接取shadowEndPos.
621行goldendict的代码是RecordIndex.endPosi->first比,
这里的RecordIndex.endPos是这个record块压缩后的结束位置相对于所有压缩后的record块起始位置的偏移(523行).
这里的i类型是pair<qint64, QString>,i->first也就是607行的headWordId,是解压后的记录数据的相对于所有未压缩数据的起始偏移量,显然一个是压缩后的偏移量,一个是没有压缩的偏移量,直接比是没有意义的.
RecordIndex.shadowEndPos是这个块解压后相对于所有未压缩数据的结束偏移量,显然应该只用这个比.
mdictparser.hh中重载的RecordIndexqint64比较== < >的操作符也表面应该用shadow*Pos和headWordId比较.
621行的目的就是如果这个词条的起始偏移大于块的结束偏移,那么就在块的列表中找下一个块的索引(idx),这里的偏移都是解压后的偏移.
我实现的mdx库https://github.com/12101111/mdict_rs 和最早的readmdict.py都没有这个问题.这个问题只是goldendict特有的.

1 Like

之前没细想,确实是这样,应该直接用shadowEndPos,感谢指导!