一直在寻找.mdx格式的开源替代品，最终锁定了stardict和slob这两种格式。由于stardict在Android下的app都不太好用，于是选择了slob。
用pyglossary将mdx转换成slob，用aard2浏览，效果不错，与mdict相差无几。
项目地址：https://github.com/itkach/slob
中文有些字词搜索不到，但用官方提供的slob工具却能搜到，应该是app的问题。
3 Likes
slob的排序依赖icu的版本，如果客户端上的icu版本，和词典作者电脑上的icu版本不一致，可能问题会出在这。（猜测）
维基百科英文版
mdx
zim
epwing
slob
这些格式中
德国人开发的slob格式
占用最小
非常nice
唯一缺点就是
中文检索
索引支持不理想
2 Likes
这里的占用是指什么？
应该是
体积
slob
体积最小
随便搜了下，iPhone用户要用这个的话，最简单的适配app 是 Alpus 。40元，好像没人推荐过，不知道app怎么样
现在体积小真的不是什么优势了。
楼主转好的SLOB
辞源
能否上传
反正能自由转换文件格式，沿用现有直观好用的mdx不好吗？现在本论坛名为mdx的（不含4.0），实际上就是开源的
看过太多的要新创文件格式、新造词典工具的，多是半途而废。
我实在看不出这些来来去去的新格式，能解决啥现存的切实pain point
半途而废后你当然见不到改进之处了。mdx还是缺点多多，虽然有些缺点能用软件补足，但是没见到做的比较好的软件。
主要痛点如下：
- mdx开发最初过于注重 体积小，导致查询时间较长，体现为查词能感受到的延迟，不过这个延迟影响因素较多。
- 无法快速编辑，更新词典
- 没有好用的索引
不过这些痛点在 能用 这个这个前提下，也就无关痛痒了。解决这些痛点对于大部分人来说都只是锦上添花的事情，更何况使用 mdx 的也就不多，开发新格式也就无人问津了。
我本人也是 能用主义者，不过我现在使用 Google 查词了。
就说索引吧，现在能用的支持全文索引的软件应该就只有 GoldenDict，可是它的表现很差。以单独在 牛津高阶英汉双解词典第八版 中全文查询 天气 一词为例，使用 @xiaoyifang 改进的版本：GoldenDict 需要花费 8 秒，这太慢了。而我最近在尝试的一个格式，同样的查询只需要花 7 毫秒，代价就是全文索引文件和 mdx 文件差不多大了，不过 GoldenDict 的全文索引文件也不小就是了。虽然这个格式都还八字没有两画，但可以看出索引的改进空间还是很大。 @last_idol 2022了欸，那啥有进展吗。
* 查询均指找到词头，而不加载内容。
4 Likes
体积小应该归功于7-zip作者的lzma算法，在常见的压缩算法里，有最高的压缩比。
1 Like
archived_NewCollocationWith
现在能不能先把主要功能做出来试用呀。
-
比如全文regex检索毫秒级的新格式，放出来敏捷迭代开发
-
还有方便自定义词典数据的规范流程IDE之类的，论坛里成千上万的人，可以共同编辑一份词典，每个人查词时的经验就可以汇集到一起进行排序整理，而不至于每个人再重新发明发现一遍知识的连接顺序。
这样人人参与，网上所有相关资料都可以有组织有序的集成到这一本词典中，按需加载各部分。
大仿生数据、人工挖掘、真人学习、分布式、区块链、真人智能
一本词典，这就很奇怪了，究竟是英语，中文，日文，还是其他的？内容是啥，主题是啥。。
1 Like
MDX直观好用，我以为直观更重要，能降低不少学习门槛，节约学习者的宝贵时间更要紧。学会制作mdx，那至少懂如何制作修改epub，更进一步的都可以做点前端的活了。
索引问题，更多的是软件算法问题，不在于词典文件格式。真正的痛点是：改进词典软件为mdx建立索引的数据算法
这些都是有得有失的，算不上解决痛点，因为CPU和内存的负担加大了
占用体积小还是有使用场景的吧，比如要对维基百科，百度百科全文检索，如果索引文件还要另外再占同等大小那就太大了，不知道这个slob做全文检索相比mdx效率如何，如果有明显提升还是很值得期待的
这一点词典格式就应该定义好了，而不是软件来生成，不然为啥一个堪用的可以全文搜索的软件都没有？
1 Like
索引非常重要
日本人的epwing
格式
索引做的最好
谢谢楼主
太感谢了
最后一句，我想，mdict作者已经不更新app 两年多了、有点
Version History
2.2.1 Jul 7, 2020
2.2.0 Jun 24, 2020
楼主的词典
效果不错
可以多做几个