我是认为这个需求太少了，从做产品的角度讲真不值得做。为了这么小的需求就要实现一个完整的跨平台的软件和新的格式，工程量太大了，而且现在生态已经被塞满了，后来者根本没有任何现实的突破口。（我也不看好论坛里的大多数人会支持，不是对错的问题，用户习惯很难改变的
现成的能跑还没bug我至于写个新的吗？我要是不写新的reader至今可能还认为是那个词典软件的bug，无意义的加密倒是小事，顶多费点时间解密，编码 link 格式 这么重要的模棱两可，遇到问题了怪词典软件，这些明确规定了哪还有这么多坑？说到sound:// 还有提到webview，官方builder里这么写的是用<a href=”sound://…”点击可发音，到web里无非就注入js来listen这个，但现实并没有这么简单，词典里的js可以listen这个去外部网络找音频，也可以实现其他的，词典注入的不阻止其他listen可能会播不止一遍，阻止了其他功能可能就废了……应对这个可能词典的js会listen父元素等，这屎山不就堆起来了吗？外面有里面也有
这个可能有的词典软件自己的js实现了音频播放，有的软件得词库作者的js来实现，或者冲突了，这个确实是坑就是了。不过这不还是和词典软件有关吧，这个要不参考些那些其它可以在多个词典软件里正常播放的词库的实现吧，或者那些老旧的词典软件就不管了好了，要我来弄的话，那些不支持es6写法的软件我理都不理。
软件解决不了 JavaScript 脚本的兼容问题，除非一次只加载一本词典的内容。
目前计划的是一个新的文件格式，大体上是 头部、索引、主数据，数都为无符号大端序。
暂定了文件头
- 固定的8字节文件头
- 接着版本号2字节，n.n
- 加密，2字节，待定
- CRC32，4字节，由5、6生成
- 表示后面JSON块的字节数，4字节
- JSON块：编码为UTF-8的JSON，有说明字典的 标题 描述 创建日期 词条数 等，待定
用新的文件格式，而不是把数据存进现有的容器内比如SQLite数据库，也是思考了一番，词典内的数据要分块压缩，尽量少出现未处理的明文，分段校验，加密，这些硬凑到一个容器里有些牵强，所以用新的格式
内容则可以是纯文本或HTML，有考虑md还有特定格式的json。纯文本没啥可说的，HTML js css 虽然有兼容性问题，但目前来看没啥更优解，抛弃这些也不现实，提到js css，目前计划是一并放进字典文件中，可规定哪些文件可从字典文件目录下查找，资源文件像音频 图片 计划放在同目录下的另一个fdict文件，和mdd的逻辑相似，只放资源文件，也可base64嵌入HTML，但太大尽量不要这么干，具体细节待定
新的格式，主要解决mdx里含糊的内容或定义，以及这些衍生出的特定html等，表现不管是bug还是啥，从现有的mdx转到新格式，如果原来的比较规范清晰，兴许没有问题，如果碰到遗留的屎山，这个无力解决。优势是新制作这个格式的词典才体现出的，对现有的mdx使用者，优势不大，更别说生态问题了，新格式预设较大的压缩块，可能文件小点
1 Like
我的想法既然要做新东西，那就要把差异化做出来，如果新产品和现有产品没啥区别，那用户当然停留在他们用惯很多年的东西不愿折腾新格式。（如果做新格式只是为了规范化mdx那还不如不做）其实搜索功能对于词典来说挺重要的，处理特殊符号的索引也不是大工程，全是自动化了，后面词库制作者无需担心搞个ÀÁÂ词条能不能被搜到，只要专注做内容即可，软件都帮你处理好了。（这个根据开发者自身技术水平决定，只要新功能足够多，覆盖全面，还是能吸引到一些用户
1 Like
软件要足够好用，格式才能推广。格式设计再好，没软件支持，一切都白扯。流程反过来才能推广，先开发自己的词典软件，把大量mdx批量转为自己的格式并分发，而且要有一键转换器。有扎实的前后端全栈开发基础，能对自己的软件维持数年更新，不然都是纸上谈兵。
开发专有词典格式的话，做词典应用的人要用此格式还要专门写个自己语言的读取代码，这个人得多热爱词典和喜欢你的格式。有写出高效读取器能力的人为什么不干脆直接设计一个格式用于自己的应用？为什么不用生态完整至今有活力（词典作者众多）的mdx、dsl和yomichan？现在的一大堆词典软件，解析代码不都是能直接搬就搬，省事为主。
我是忠诚的sqlite+xml派，让你的格式好理解好读取好利用，最重要。推广开了，要添加什么新特性都好说。
4 Likes
其实golden dict开源，设计新格式可以直接给它贡献代码。但我是比较支持在现有的格式上做扩展的。比如楼主设计那个有crc，文件名什么的，还能压缩加密什么的，zip就能实现这些功能，那就用zip。然后zip里面加html的话epub就是这样实现的，那给epub加个索引，给一个词条能找到html里面的一部分就完了，现在所有的电子书软件也能直接打开阅读，然后词典软件加上读索引的逻辑就好，也方便开发读取工具。
这种制订新词典格式的贴子，每过两三年来一次，每次都无疾而终，MDX仍然大行其道。“秦人不暇自哀，而后人哀之；后人哀之而不鉴之，亦使后人而复哀后人也”？
这几十年冒出了那么多种词典格式，之所以MDX能走到今天，我并不认为是MDX的设计者有多么远见卓识。并不是其从一开始规划设计好了一切、因而有如此的生命力，而很大程度上是大浪淘沙、适者生存。这里很多人有个误区，以为：自己的方案能解决这个或那个痛点、技术如何如何先进、所以必然成功。MDX是适合大众和流行的词典格式，并不是技术上最先进的词典格式。要在大众和流行上获得成功，其实是众多因素取舍折中的结果，而并非只适用于小众领域的一招鲜。
所以，如果目标是取代MDX，首先要做的是总结其为什么能成功。之前的讨论已经很多了，我无意一次又一次重复，只提示“生态”“闭环”两个关键词，不要陷入技术至上的误区。
1 Like
mdx的设计方案并不差，才有如此强大的生命力。目前很多人都想推出一个规范划一的东西，孰不知词典本身是一个很复杂的内容体，难以用一个统一的格式来定义，也没有必要。想要显示丰富多彩，就要用HTML格式；想要互动，就要加 JS。结果是一些词典做得太复杂了，被人诟病。技术怎么用，是一个选择取舍的问题，不一定是技术本身的原因。稳妥的做法是，只有当一个技术不堪胜任的时候，再考虑升级替换。
真以为技术不重要？想做新格式就需要把电脑、手机平台客户端都做一遍，对技术要求本身就很高，你问那些想做新格式的人，有多少是同时会做电脑客户端和手机客户端的，他们没成功的原因是没有拿出东西来，根本没走到生态那一步。至于生态问题一开始不要想着替代就行了，而是做共存，开发一个客户端既可以用我自己的格式又能兼容mdx、epwing等，但你用mdx就是有些功能实现不了，只有我的格式才可以。当然能做到这个的人更是寥寥无几。时间久了用户自然知道哪个更好用，他们会做选择
2 Likes
有了定下来的格式才有词典软件，词典软件不少，为了这个新格式单开个软件工程量太大也，不如直接完善现有的，让更多软件都能用，这也是目的之一，新格式会有详细的文档，读取不难，不管提供库还是直接贡献。
至于外在格式，不同块放进sqlite或zip，还有可选的部分的加密、压缩，分卷，掩码，额外的资源，纠错(码)，这些整到一块还是认为有些牵强，不同块读出来涉及字节的处理，和直按字节接读文件，简单不了多少，似乎epub只允许严格的html，处理五花八门的词典也不好搞
mdx词典格式显得有些乱，是因为它的来源很多，有根据早期光盘制作的，有从其他格式词典转来的，有根据网上下载到的htm文件集合的，还有根据epub电子书制作的等待，但目前通用的mdx词典程序大多能兼容这些，可能文档显得臃肿些罢了。新的词典格式，其词典源来自哪里？不可能词典都自己编写吧？能否将此前的词典完美转换为新的词典格式？我以为很难，而且到底价值何在呢？词典关键不在于格式，而在于优良的源文件。
楼主是四川人？
我不是楼主啊。不是四川，不过在四川隔壁，话说咋看出来的。
你有用到恼火这个词，所以就以为你是四川人
。
你这么一说还真是，恼火这个词 可能是川渝那边用得比较多些哈