我技术小白，请教大佬们，对比而言，是不是yomitan格式比起mdx/mdd格式更为结构化和规整一些？为什么没有大佬考虑做一个yomitan查词app或者变成goldendict支持格式？
最近接触yomitan格式，感觉很方便就是一个压缩包安装也不用担心mdx/mdd不配套或者css对不上之类的，要是有独立app工具，说不定我都想慢慢把mdx/mdd转换成yomitan格式，既能在浏览器点击查词，又能在独立app查词或者阅读。
做一个符合标准和规范的yomitan词典太麻烦了。。。词典现在都是XML或者HTML存储，还要转成复杂的json，一本词典你就得写一个专门的转json解析器。yomitan改动js和css还很麻烦，你基本不能使用原始网站或者app的文件了。
用json就不太明智，还是20年前就发明的Apple Dict最有先见之明，用的XML，格式规范。所有格式都可以向此学习。唯一的缺点是，编译器只有Mac OS才能用，完全的闭源，其他平台都无法编译苹果词典和使用。这个格式有很多文件的构造都没被弄明白，所以也没人能基于逆向弄一个其他平台的编译器。不过基本特性还是可以学习的。
我接触了无数的词典格式，Apple Dict几乎就是最佳的答案，被无数人推崇的物书堂，很多影子都跟Apple Dict差不多。
1 Like
唉，这个缺点就很劝退了，毕竟连iPhone都用不了吧？更别说win pc了
得坐等一个能够完全对苹果词典逆向工程的大神。苹果官方文档也一直不更新，还是二十年前的，说真的，现在的人做一个符合苹果官方标准的苹果词典都难！苹果对于XML的原始文件，一些关键字段和标签都有下定义，需要特殊处理的。问题就在于压根没人在意词典。
现在的逆向工程，只解析了关键的EntryID.data（正文的偏移量记录），Body.data（正文主体）和KeyText.data（同义词跳转）。其他两个.index文件都不知道有什么用（我自己翻过，估计就是偏移量记录，但是不逆向出来写不了完整的编译器）。
基本的逆向工作都是这位soshial完成的，以前其他的人只是看到了Zlib的压缩头简单解压了Body.data（我翻了无数文章和代码，都这样），对苹果词典格式一点都不了解，很简陋和可笑。不过说实话，soshial还有很多字段没弄懂，以及他有的结果是错误的。
Support AppleDict Binary key texts (morphology) · Issue #406 · ilius/pyglossary
XML和HTML也很结构化啊，json也没有明显优势，反而显得冗余和不便于人工操作和修改，做json只能纯代码批量处理。（这完全就是翻版的HTML）
再者Yomitan没有索引设计（全部让软件端处理），搜索效率得看软件作者。（导入一本yomitan还要等构建索引）
我只感觉这个格式缺点太多了，主要是因为他是基于浏览器扩展设计的，这样来讲使用json是合理的，便于网页上的API信息通信（避免CORS限制）和js处理（毕竟做前端的处理最多的就是json）。
以及他是为了日语学习设计的，有的设计对于其他语言就是纯粹的冗余。
yomitan/docs/making-yomitan-dictionaries.md at master · yomidevs/yomitan
因为太麻烦了，yomitan格式的解析器都是纯js，而且只在yomitan浏览器扩展项目内部，没人拆解出来，也没人迁移语言。现在的人要写程序支持得从0开始写。这就很矛盾，让做后端弄懂一个前端的，得找全栈工程师。epwing和mdx一大堆不同语言的解析器，代码直接拿来用。
yomitan都是学日语的在浏览器上划词用，本来就有够小众的。纯划词搜索的词典软件，除了yomitan还真没见过。