嗯，不晓得其他地方有没有这个词，不过川渝地区是用得最多的。
你这句话最后一个哈字也是川渝人爱用的
，我感觉这个哈字有种需要别人确定的语气，类似于日语中的ね，不过我也没啥数据支持，纯粹我个人的猜想和感觉。
列下 MDX 已知的问题：
- 缺乏辅助索引：汉语拼音被完全忽略，外语学习者被直接放弃；日语则把假名当作主索引，在同音字多的时候会加载很多不相关的词条。
- 缺乏变音符号支持：目前仅有 ASCII 大小写忽略，对法语、西班牙语、越南语等含变音符号的语言极不友好，特别是越南语完全不可用。
- 缺乏内容校验：打包工具不检查词条 HTML，出现问题时无论是作者还是开发者都难以判断来源，脚本兼容性更无从谈起。
- 缺乏结构化数据：词条内容完全是 HTML，没有字段、没有语义结构，无法做义项和例句的精确检索、无法做跨词典统一展示，也无法支持现代词典所需的变形、同义词、词性等结构化信息。
- 版本管理失控：文件本身没有唯一的编号，没有版本约束，MDX 与 MDD 也没有强绑定，常出现新版配旧资源、多个 MDD 互相覆盖、外部资源路径失效等混乱情况。（建议使用单文件，大文件可以区分有声版和文本版。
希望新的格式能解决上述问题。
3 个赞
mdx只是个载体，你想让他完美无缺或者十八般武艺样样精通不现实，世上任何一个东西想找缺点都能找到
上面这 5 个已知的问题技术上完全能解决，我只是觉得生态已经挤满了，推广困难所以没有做。
这些确实是问题，但解决起来谈何容易！在没有利益驱动的情况下（至今mdx属于完全免费使用），谁来做呢？而且我曾说过的，即使有了更完善的结构，但词典源文件从哪里找？
我认为只有一个问题就是推广，用户的需求已经基本满足了，其他都是小问题。
1 2 实现应该不难，不过还得要词典软件“配合”，mdx(2.0)的索引似乎(只?)是针对程序内部的，词典软件都拿到所有词条名自己一套处理补全 模糊 啥的逻辑
3 html js css 的合法性能解决最好，各种奇葩的html，span里套div的，其他自定义元素的，甚至用元素改名实现某种特性的。关键还不少词典还有很多，真要仅允许完全合法的html不知改这些能不能改得过来，还有js，现有的更是一坨了
4 实现不难，但可能并那么好 或者说 例外或不常用的会“干扰” ，我自己整得词典都搞得一般，搞个音标吧，不同变形不同词性还不一样；搞个短语 同近义 同根 词 表，释义里套个例句，短语里套个近义词，同根词里套个辨析……比想象的复杂的多，总之尽力解决吧
5 也是个问题，mdd就只充当个“压缩包”的作用，只存文件，不少词典都用mdd里的css判断是否有mdd，这个修改了css那个添加了资源，也确实挺乱的
1 个赞
现在畸形的词典也挺多的，比韦氏大学，跟其他词典都不一样。制作的时候想要提取关键内容也很困难。
这个15G的mdx，由111G数据分10MB块压缩得来，改用zstd可压缩到8G（窗口大小=4MB时）
mdx v2 只支持lzo和zlib压缩，前者压缩率相对不高但解压很快，不常用，后者压缩率更高但解压慢点。数据被分块压缩，解压速度只要不是可感知的慢就没影响，块分得大了，zlib的压缩率就不够看了
后续测试
lzma2的压缩率比zstd高一些，意料之内，但解压速度比zstd慢一个数量级，对于压缩率很高的html，zstd zlib lzma2的解压时间关系大概是3 5 60，到了移动端（mt6757）差不多是2 3 18，zstd最慢也有200M/s的速度
还是得从用户需求这边入手
面向用户的辅助索引是个很好的功能，比如汉字或词语的拼音 笔顺，这些可由词典制作者自定义，像由错误的拼音指向目标词条，或者其他能方便查词的，“3火”→“焱”、针对异体字等
结构化数据还有各种显示结构通过html内指定class或属性实现，兼容性也好，有点是点。还可以给词条加标签，比如作者xx 日期xx 中考 高考 这些，还可由用户标记。检索选项更丰富，比如实现在英语词典找 中考 并且 有（特殊变形）的词条，都是些很有用的新特性
2 个赞
索引，文件内部的索引，用于快速定位和给出候选
英语词典大的几十万条，百科的归档有几百万条，加上不同语言或者变形的“辅助索引”还会翻几倍
目前计划的是用一个B+树，几千万条是没啥问题的
字符的规范化也不能漏了，NFD规范化对那些带有音号的字符算编辑距离有优势
NFKD适合用于处理语义兼容的字符，① ② ③ ④ Ⓐ Ⓑ Ⓒ ㊥ ㊤ ㊦ ㍿ Ａ（全角）Ⅳ（罗马数字）这类会被替换为1 2 3 4 A B C 中 上 下 株式会社 A IV
当然词条名就不应该存在这些字符，所以词条名可以是什么也得规范
说到索引，不得不考虑排序
程序为文本排序一般只能是按照字符码位排，1 2 a b c A这样，对人可读的只有纯英文字母统一小写+单个数字，其他语言的照着码位排出来的就不是给人看的，涉及到数字像5 9 10结果会是10 5 9，也不符合直觉
“辅助索引”这时候显出优势来了
像下面这些，除了把这些词条名加入索引
阿Q正传、第9章、第10章、café、apple tree、Apple、西安、先
还可编写或生成辅助索引例如：
aqzhengzhuan aqzz di9zhang di10zhang cafe appletree apple xian xian ……
如果要为候选排序，用这些：
a1 q zheng4 zhuan4、di4 00000009 zhang1、di4 00000010 zhang1、cafe(?)、apple tree、xi1 an1、xian1
café这种咋排序还没研究，其他语言也都挺陌生，五花八门的字符，有拆字的有音调的，这些应该有法应对
有针对特定语言环境的ICU排序，不过3.0没人用就是了。其实很多词典作者拿到的源文件都有官方排序的，最大的问题是，mdx连原始排序都无法呈现，解包后也无法还原。
有官方排序，好办多了，mdx这玩意跟个黑盒一样，单靠ICU排序大部分可能没错，但遇到多音字应该搞不定
ICU 的排序结果不能写到文件里，这样会有版本问题，Unicode 的规范里也明确说过排序结果是不稳定的，参考 PostgreSQL 的实践就知道了，PG 数据库也可以用 ICU 排序，但是一旦 ICU 版本更新，索引就会失效，会让你重做索引。（从这点上说 MDX 3.0 和 SLOB 根子上就有问题。
想了一个春节，新词典格式还是应该使用 JSON，彻底放弃 HTML，要和现存词典格式的竞争，就必须走差异化的精品路线，不然完全没可能挑战 MDX。（这种想法在脑海里固化了，旧的王座已朽，新的王座当立，结构化的语义，就是未来。
只按ICU排序的结果写进文件肯定会乱套，至少查找键一列排序键一列。可以只生成排序键，或排序结果的序号，这样客户端就不用非得对版本了。当然能用上原词典的顺序最好，结果对人可读是最重要的。