AISS写真
2024 年11 月 7 日 01:45
1
你可以把世界上所有语言都放到 .odict格式里
.odict 可以存储10亿行条目没有问题
词典 GitHub - TheOpenDictionary/odict: A blazingly-fast, offline-first format and toolchain for lexical data 📖
转换成 .odict 格式工具GitHub - TheOpenDictionary/converters: Converts dictionaries from various formats to the .odict format 📔
1 个赞
last_idol
2024 年11 月 7 日 03:37
2
Entry lookups take less than 1s and don’t require indexing.
注意这条介绍，不知道为什么他们认为没有索引是件值得宣传的事，GoldenDict 的索引单个词条的查找时间通常小于 20 ms。
hereissun
2024 年11 月 7 日 08:12
4
这种事儿，好解决，要么生成字典的同时，在网盘上，随机附上索引文件，要么，下载字典文件的时候，也一并给索引文件也下载了，要么，自己本机的话， 干脆一开始就不设置全文索引，在系统空闲的时候，再改回来全文索引，然后手动在gd里指定一下重新扫描，属于闲着没事儿给事儿就办了的。个人感觉，不是啥语料级别的，普通人背个单词啥的，全文搜索意义不大，真就事儿说事儿的，自己网上搜索，网上的资源肯定比自己本地里一堆电子字典的语料多得多。而且网络响应速度这年头的网速也不慢。不折腾全文索引的话，基本上，建立个简单索引的时间不会太多，属于秒杀那种，都可以忍受。
1 个赞
last_idol
2024 年11 月 7 日 09:20
5
只是和标题中现代的新词典格式有点差距。
看作者的介绍，是个狂热的语言爱好者，正在学习中文，可以拉来论坛。
I myself love languages. Over the years, I’ve tried many times to learn different languages through Duolingo.
1 个赞
seid
2024 年11 月 7 日 13:17
6
简单走马观花，这个格式并不算多优秀的格式，和mdx等格式相比并不占什么优势，本质上就是一个大 json 结构，并且不直接支持压缩技术，需要使用其他手段协助（字段预先压缩或整体后置压缩）。
他号称快，因为直接一次二分查找法，理论上是比mdx直接查找是要快一点点，但是也就是一点点，代价就是不压缩。
mdx使用分块索引（每块64k？），定位到某块和定位到块内某单词都可以使用二分查找法。
如果mdx不压缩，和这个格式查找速度差不多。
goldendict等词典软件给mdx额外建立一个索引（使用B+树或字典树），查找速度甚至比odict更快。
2 个赞
cdef68935
2024 年11 月 8 日 23:53
7
小白不懂，既然是开源格式，如果直接用 sqlite 不是挺符合各种需求吗？什么压缩全文搜索都省心不是
seid
2024 年11 月 9 日 00:52
8
如果不考虑体积，sqlite 算是比较好的选择。
Sqlite 不压缩文件体积会比一般的格式要大不少，如果使用压缩扩展，平台兼容性会有问题。
尽管计算机存储空间很大了，但是省空间还是一个恒需求，就比如utf-8 ，差不多就省空间一个优点，但带来很多缺点，解码复杂，无法随机存取。
1 个赞
hkreporter
2024 年11 月 9 日 04:43
9
是的，sqlite的通用性很关键
1 个赞
Mandolin
2024 年11 月 9 日 05:28
11
看这个 odict 格式的源文本是 xml 格式，并且只支持预定义的有限的几个标签，要是支持 mdx 格式源文本 html 格式就好了，这样就也可以将 mdx 源文本打包成 odict 格式。
在我看来，这个 odict 格式的唯一优点就是不需要索引（词头检索的方式），当然它也支持全文检索（需要额外建立 .index 格式的全文索引）。
1 个赞
last_idol
2024 年11 月 9 日 08:17
12
开源的坏处就是优点缺点都一目了然。
1 个赞
last_idol
2024 年11 月 9 日 08:20
13
6lj6:
问题是目前的词典的性能是够用的，安全性也没有频频崩溃，也有开源软件，缺的是功能。
是的，MDX 格式本身设计的够好了，如果新的词典格式没有什么让人眼睛一亮的东西，很难吸引到词典作者和新的用户。
hua
2024 年11 月 10 日 07:22
15
还是想要一些更新，想有一些新鲜血液和鲶鱼。
1 个赞
Mandolin
2024 年11 月 10 日 09:57
16
本来是有人想做个支持 mdx 格式的 SDK
MDX SDK 技术交流与词典编修
i wanted to create a mdx SDK in c++ and i think this is the right place to ask.
i dont know much about the mdict format, but i know that some people have done for reverse engineering in it, but the k…
不过似乎没有下文了……
seid
2024 年11 月 10 日 10:15
17
可能他发帖之前没有先搜索吧。
github上已经早就有python/javascript/c++/c#/dart/java等语言的mdx读写实现代码了。
因为自从python代码先出现后，其他语言就是一个人工转译而已，难度并不大，只是工作量的差异而已。
2 个赞
Mandolin
2024 年11 月 10 日 10:49
18
在我看来，现有的词典格式（mdx、stardict）各式各样，但其实它们都只是压缩/解压算法不一样，关系到的只是检索速度。多一个或少一个这样的格式，其实对现在的电子词典生态影响不大。
由于词典数据的内容结构的多样性，数据源文本或最终渲染呈现的格式必然是较为复杂的半结构化甚至非结构化的，它们基本无一例外都是 xml、html、json 这些半/非结构化的文本格式。
针对以上两个方面，我想我们最需要的应该是：
对这些半结构化的词典源数据，建立统一的内容结构规范，这方便数据复用和格式转换；
针对这个统一的内容结构，有个好的从中提取有效信息的算法，比如好用的全文检索、AI加持的内容检索算法
2 个赞
seid
2024 年11 月 10 日 10:51
19
OK，我就动动手，搜索一番，贴上几个流行编程语言的典型代码库：
首先，让我们对 Xiaoqiang Wang 寄予崇高敬意，是他首先逆向成功mdx格式。
原初Python代码
!--------------!
Python
C++
C#
C#
Java
Dart
Javascript
Javascript
Node.js
Go
Dart完整app
Swift
Rust
C++的实现还可以参考 Goldendict的源码，可能更成熟一些，主要代码在这几个文件。
mdictparser.cc
mdictparser.hh
mdx.cc
mdx.hh
Java的实现还可以参考 无限词典的源码 的实现。
github上面还有大把的其他mdx读写源码和各种成品，不缺素材。
3 个赞
last_idol
2024 年11 月 10 日 11:02
20
作者也在论坛：
github.com
GitHub - dictlab/mdict-cpp: *.mdx/*.mdd file interpreter cpp implementation
*.mdx/*.mdd file interpreter cpp implementation
last_idol
2024 年11 月 10 日 11:08
21
Mandolin:
对这些半结构化的词典源数据，建立统一的内容结构规范，这方便数据复用和格式转换；
针对这个统一的内容结构，有个好的从中提取有效信息的算法，比如好用的全文检索、AI加持的内容检索算法
这两点标题里的 ODict 除了 AI 加持都实现了。你愿意尝试吗？
Mandolin
2024 年11 月 10 日 11:14
22
ODict 的这种思路正是我想要的，不过它的标签设计和结果呈现适合语言词典，要再加上对百科类的词典标签组及结果呈现的支持就好了，能自定义标签组则更好。还有就只目前只有CLI查词，没有GUI应用，也不能多词典联合查询。
源数据用统一的 xml 格式（使用指定的标签组），结果呈现则可使用比如css来自定义样式，就是这样的思路。
关键还是简单的模板式的半结构化格式，否则往复杂了其实又绕回 html 了……
2 个赞
评论留言