三省堂クラウン独和辞典第5版 mdx

wynick27 · 2026 年9 月 10 日 06:16

没有反驳的意思啊，我之前确实没注意到这个问题，现在好多词典都得改了

amob · 2026 年9 月 10 日 06:17

本来也没见谁说主要是stripkey的问题。

amob · 2026 年9 月 10 日 06:32

这个问题没有通解，在深蓝词典看来，它的排序推定是跟mdict-utils一致的，你用mdxbuilder就会查不到，总是要放弃一部分人。

而且mdxbuilder可能在部分软件会打乱词条的展示顺序。甚至你能看到有的情况下，mdxbuilder查不到。

amob · 2026 年9 月 10 日 06:41

mdx作为一个闭源格式，很多开源解析库都是用逆向猜测的排序实现的，以讹传讹，不同编程语言和文本编码排序也会有细微区别，已经成了很大的历史问题，你用mdxbuilder就能一劳永逸吗，只能说dicttango和mdict用户可能会舒服一点。

wynick27 · 2026 年9 月 10 日 07:01

看来只能让词典软件作者来解决了，其实mdict_utils的排序才是对的，大小写肯定不应该只处理A-Z

hahaya · 2026 年9 月 10 日 07:38

啊这样好麻烦啊我词典很多

yx_wh · 2026 年9 月 10 日 08:19

另外，PC上直接用GoldenDict-ng不就可以调用OpenCC嘛

hahaya · 2026 年9 月 10 日 08:29

所以现在PC上GD-ng和DictTango搭配着用，其他的暂时还替代不了，真希望能有一个软件能解决所有这些痛点。

yx_wh · 2026 年9 月 10 日 11:31

诶，windows版DictTango有什么独特的功能吗

hahaya · 2026 年9 月 10 日 14:21

我的汉语词典分组有一千多本，在GoldenDict-ng上词典互相干扰，甚至很多词典压根不加载。而在DictTango上加载毫无压力，并且词典之间互相隔离，不会相互干扰显示，还直接内置简繁通搜。只是DictTango有几十本mdx词典不兼容（作者声明过只支持mdx 2.0版本格式的词典，老版本1.2之类的暂时不可用，后续也无计划支持），无法导入，还有就是不支持设置Ctrl+C+C的查词快捷键，所以只能搭配GD-ng一起用了。

神农X · 2026 年9 月 10 日 14:35

牛逼，我分了14个语言栏目也才五百多本，话说你这1.2的都是啥词典，没有替代品必须用它吗，感觉目前500多本我安卓端深蓝DictTango效果都是一样的，没有冲突不显示的，就是有几个藏语的不知道是不是3.0的，加载不了

yx_wh · 2026 年9 月 10 日 14:40

原来如此，上千本的话，词悦怕是撑不住。我是常用汉语词典就那几本，把它们词头一提取生成.aff .dic也能用，安卓版GoldenDict Mobile和词悦我就可以这么操作。
GoldenDict天生的设计就是不隔开，无解。碰到有冲突的我就直接去改.css。繁简通搜这个GoldenDict-ng也自带了。

神农X · 2026 年9 月 10 日 15:13

话说要是安卓端有什么软件可以同时支持mdx, dsl, bgl, stardict就好了，这样又有好多一堆外语词典手机也可以查了，不知道你有没有见过

yx_wh · 2026 年9 月 10 日 15:30

没见过，恐怕必须靠手动转换。普通辞典本身其实还好说，可以转格式嘛，hunspell或者opencc要是不支持就比较尴尬，hunspell的灵活度毕竟远超写死的路由辞典。
安卓版GoldenDict Mobile支持dsl、bgl、stardict，不支持mdx。支持Hunspell。
隔壁论坛2020年有网友给出了一种用stardict词典+.dsl.files.zip的资源文件的思路。这样子hack出来的东西，表现力跟mdx差不多了。就是css冲突必须一个个手调。

hahaya · 2026 年9 月 10 日 15:54

这是其中一些，有很多知名词典也是mdx 1.2的，包括最近平凡社那个大百科：

神农X · 2026 年9 月 10 日 16:46

百年新词新语，WBD，Spanish Verb Table，古代汉语百科大词典，世界大百科全书这几个我都有同时在深蓝和DictTango使用，都正常啊。哦你是说这些GoldenDict不兼容是吧

神农X · 2026 年9 月 10 日 16:47

谢谢推荐，我下载看看

yx_wh · 2026 年9 月 10 日 17:43

GoldenDict Android用词典链接:https://pan.baidu.com/s/16zxdX0lOVwSEz_k5UToCnA?pwd=1234 提取码:1234 复制这段内容后打开百度网盘手机App，操作更方便哦
更新了一下构词法文件，在Hunspell目录下。“汉语构词法”实际上是根据《汉语大词典》等几部辞典生成的，用于繁简通查

神农X · 2026 年9 月 10 日 17:51

多谢

yx_wh · 2026 年9 月 10 日 18:02

目前手机上除了GoldenDict安卓版之外，《词悦》也支持Hunspell了，但是词悦现在在.dic有多个st:情况下遇到「一个简体对多个繁体」就只会显示一个的结果，而goldendict支持查询「复制」同时显示「複製」「復制」的結果：

github.com/mumu-lhl/Ciyue

关于《词悦》的 Hunspell 的功能建议 / Feature Suggestions for Hunspell in "Ciyue"

已打开 09:02PM - 05 Sep 26 UTC

yx-wh

enhancement

# 关于《词悦》的 Hunspell 的功能建议 --- ## 1. 显示所有的 `st:` 结果日文的混书（混ぜ書き、mazegaki）是一种很日本的…现象。汉字和假名都是日文的正式文字，日文可以把有汉字的词汇写成汉字假名交杂的形式。比如说まんえん【蔓延】，写成汉字是「蔓延」，写成假名是「まんえん」，写成「まん延」「蔓えん」当然也可以（虽然「蔓えん」很少见）。加之二战后日本文字改革的时候推行了「当用汉字」政策限制汉字的使用，「まん延」这样的写法大行其道。这和中文不同，中文正式文本只会写成「蔓延」，「màn延」像小学生写作文。但是，日文辞典的条目入口一般只会收录全假名写法和尽量全汉字（能写汉字的部分都写成汉字）的写法。这时候可以在 `ja_JP.dic` 中使用 `st:` 的方式把它们指引到全汉字条目： ``` まん延 st:蔓延まん延 st:万延たい積 st:体積たい積 st:堆積たい積 st:滞積 ``` 但问题是一个混书形式可能对应多个原形，比如这里「まん延」同时对应「蔓延」「万延」，「たい積」同时对应「体積」「堆積」「滞積」。我试了下，**GoldenDict‑ng 和安卓版 GoldenDict Mobile 是可以在查询「たい積」时同时给出「体積」「堆積」「滞積」的结果的**，但是 **《词悦》现在只能显示第一个结果**。另外这个写法也能用来实现中文的简体繁体通查。 `zh_CN.aff` 不需要任何实质内容，指定编码为 UTF‑8 就行： ``` SET UTF-8 LANG zh FLAG long # 空壳 ``` `zh_CN.dic` 的内容类似这样： ``` 12 簡體 st:简体简体 st:簡體繁體 st:繁体繁体 st:繁體发 st:髮发 st:發髮 st:发發 st:发復制 st:复制複製 st:复制复制 st:復制复制 st:複製 ``` 这跟上面类似，**《词悦》现在只能显示第一个结果**。 **希望能显示所有的 `st:` 结果。** <img width="1200" height="1920" alt="Image" src="https://github.com/user-attachments/assets/40572830-823f-423c-bb5b-d3fdb3e3f6d4" /> <img width="1200" height="1920" alt="Image" src="https://github.com/user-attachments/assets/b5f5e8e6-54e5-444f-ad5f-6d634e1ff2f3" /> <img width="1200" height="1920" alt="Image" src="https://github.com/user-attachments/assets/c234cc04-91d9-4b84-bfa7-2c92393747c1" /> <img width="1200" height="1920" alt="Image" src="https://github.com/user-attachments/assets/4eae873f-e4ef-486e-9de8-1462072f1377" /> --- ## 2. 增加两次查询 Hunspell 的选项当我查询 `"drunkest"` 的时候，hunspell 根据生成形容词最高级的规则查到 `drunk`。当我查询 `"drunk"` 的时候才会根据 `drunk st:drink` 生成 `drink`。 ```bash % echo "drunkest" | hunspell -m -d ~/GoldenDict/Hunspell/en_US drunkest st:drunk fl:T % echo "drunk" | hunspell -m -d ~/GoldenDict/Hunspell/en_US drunk st:drink drunk st:drunk ``` 但是现在《词悦》调用 Hunspell 只会调用一次。**希望能给出一个调用两次 Hunspell 的选项**。第一次调用 `drunkest` 得到 `drunk` 之后，再调用一次 hunspell 从 `drunk` 得到 `drink`，并同时显示 `drunkest`、`drunk`、`drink` 的内容。当然对于英语这样词形变化比较简单的语言，直接硬编码 `"drunkest st:drink"` 也完全够用。但是对日语或者德语这样的语言来说，直接硬编码会让 `.dic` 里面到处充斥着硬编码，难以阅读和维护。德语例子： ``` abgekämpfterem → abgekämpft → abkämpfen ``` 日语例子： ``` 引きこもらない → 引きこもる → 引き籠もる ``` 如果能有两次调用 Hunspell，那我可以把 `ja_JP.dic` 写成这样： ``` 引き籠もる/5A5I5T5E5OBDUYUBubKN ひきこもる/5A5I5T5E5OBDUYUBubKN 引きこもる/5A5I5T5E5OBDUYUBubKN 引きこもる st:引き籠もる ``` 但是如果没有两次调用，那我只能这么写，而且后缀还不全，我不能直接检索「引きこもらない」，我只能手动选中「引きこもら」才能查询： ``` 引き籠もる/5A5I5T5E5OBDUYUBubKN ひきこもる/5A5I5T5E5OBDUYUBubKN 引きこもっ st:引き籠もる引きこもら st:引き籠もる引きこもり st:引き籠もる引きこもる st:引き籠もる引きこもれ st:引き籠もる引きこもろ st:引き籠もる ``` 但是对英文的还原原形，或者中文繁简转换来说两次调用 Hunspell 必要性不大或者毫无必要。因此**可以把两次调用 Hunspell 做成每个 Hunspell 文件上的一个开关**。 --- 希望以上建议能被采纳，让《词悦》在非英语语言（尤其是日语、德语）的查词体验上更上一层楼。 **Feature Suggestions for Hunspell in "Ciyue" (《词悦》)** --- ## 1. Display All `st:` Results In Japanese, *mazegaki* (混ぜ書き, mixed kana-kanji writing) is a very common phenomenon. Both kanji and kana are official scripts in Japanese, so words that have kanji forms can be written in a mixture of kanji and kana. For example, *man'en* (蔓延) can be written in full kanji as 「蔓延」, in full kana as 「まんえん」, or in mixed forms like 「まん延」 or 「蔓えん」 (though 「蔓えん」 is rare). Additionally, after World War II, Japan's script reform introduced the *tōyō kanji* policy to limit kanji usage, which made mixed forms like 「まん延」 widely prevalent. This is different from Chinese, where formal texts only use 「蔓延」 – writing 「màn延」 would look like a primary school student's essay. However, Japanese dictionary entry headwords typically only include the **full-kana** form and the **full-kanji** form (i.e., writing as many parts as possible in kanji). In this case, we can use the `st:` mechanism in `ja_JP.dic` to map mixed forms to their full-kanji entries: ``` まん延 st:蔓延まん延 st:万延たい積 st:体積たい積 st:堆積たい積 st:滞積 ``` But the problem is that **one mixed form may correspond to multiple original forms**. For instance, 「まん延」 maps to both 「蔓延」 and 「万延」, while 「たい積」 maps to 「体積」, 「堆積」, and 「滞積」. I tested this: GoldenDict-ng and the Android version of GoldenDict Mobile can display **all** corresponding results (e.g., querying 「たい積」 shows entries for all three). However, **Ciyue currently only displays the first result**. This mechanism can also be used to enable **Simplified–Traditional Chinese conversion** for lookup. `zh_CN.aff` does not need any substantive content; just specify UTF-8 encoding: ``` SET UTF-8 LANG zh FLAG long # empty shell ``` `zh_CN.dic` could look like this: ``` 12 簡體 st:简体简体 st:簡體繁體 st:繁体繁体 st:繁體发 st:髮发 st:發髮 st:发發 st:发復制 st:复制複製 st:复制复制 st:復制复制 st:複製 ``` This is similar to the Japanese case above. Again, **Ciyue currently only shows the first match**. **I hope Ciyue will display *all* `st:` results, not just the first one.** --- ## 2. Add an Option for Two Hunspell Queries (Recursive Stem Lookup) When I query `"drunkest"`, Hunspell correctly finds `drunk` via the adjective superlative rule (`fl:T`). When I query `"drunk"`, it further yields `drink` from the explicit mapping `drunk st:drink`: ```bash % echo "drunkest" | hunspell -m -d ~/GoldenDict/Hunspell/en_US drunkest st:drunk fl:T % echo "drunk" | hunspell -m -d ~/GoldenDict/Hunspell/en_US drunk st:drink drunk st:drunk ``` However, Ciyue currently calls Hunspell **only once**. I would like an option to call Hunspell **twice**: 1. **First call**: `drunkest` → get the immediate stem `drunk`. 2. **Second call**: feed `drunk` back into Hunspell → get the deeper stem `drink`. Then display all related forms together: `drunkest`, `drunk`, and `drink`. Of course, for a language like English with relatively simple inflectional morphology, one could hard‑code `drunkest st:drink` directly in the dictionary file. But for languages like **Japanese** or **German**, hard‑coding would force the `.dic` file to be cluttered with countless entries, making it extremely difficult to read and maintain. Examples: - German: `abgekämpfterem` → `abgekämpft` → `abkämpfen` - Japanese: `引きこもらない` → `引きこもる` → `引き籠もる` --- ### What Two Calls Would Enable If two Hunspell calls were possible, I could write `ja_JP.dic` as simply as this: ``` 引き籠もる/5A5I5T5E5OBDUYUBubKN ひきこもる/5A5I5T5E5OBDUYUBubKN 引きこもる/5A5I5T5E5OBDUYUBubKN 引きこもる st:引き籠もる ``` --- ### Without Two Calls (Current Workaround) Without two calls, I have to manually list every conceivable inflectional stem, and even then the suffixes remain incomplete – I cannot directly look up `引きこもらない`; I can only manually select `引きこもら` to query: ``` 引き籠もる/5A5I5T5E5OBDUYUBubKN ひきこもる/5A5I5T5E5OBDUYUBubKN 引きこもっ st:引き籠もる引きこもら st:引き籠もる引きこもり st:引き籠もる引きこもる st:引き籠もる引きこもれ st:引きこもる (note: keep original logic, but I’ll preserve the user’s exact example) 引きこもろ st:引き籠もる ``` *(The user's point is that this is incomplete, cumbersome, and fails for forms like 引きこもらない.)* --- ### Per-File Toggle For **English stem restoration** or **Simplified–Traditional Chinese conversion**, a two‑call lookup is largely unnecessary or completely redundant. Therefore, **this "two Hunspell calls" feature should be implemented as a toggle/switch on a per‑Hunspell‑dictionary‑file basis**, so users can enable it only for languages that truly need it (e.g., Japanese, German) and keep it off for others (e.g., English, Chinese) to avoid unnecessary overhead.

三省堂 クラウン独和辞典 第5版 mdx

三省堂クラウン独和辞典第5版 mdx