Chou先生好。
加密可以说全是我的锅，当时外传数据给某洋群友了，谁知道他拿去做种…
1 个赞
对的，为了性能考虑压缩和复杂加密是使不得的，低压缩率和异或混淆勉强可取，用来防止数据流出。打开一看就是明文的话，app都不好卖了。
1 个赞
自己设计格式当然更好，sqlite 的复杂查询、事务、触发器对词典格式来说都略显繁重，每次查询开销在哪里自己设计的话都一清二楚。
词头的索引最简单就是参考 mdx 的方式把词头分块压缩存储，直接用二分查找就可以了，速度同样很快，slob 就是这个方案；也可以构建 b 树、sstable、fst 等索引结构内嵌到格式中，这些都有开源方案可以参考，goldendict 的索引就是用的 b 树，mdx 的实现方式其实和 sstable 差不多，只是 sstable 更精巧一些。
全文检索的索引复用词头的就可以了，比较困难的是分词，因为分词的结果需要写入到格式中，如果后续改了分词的结果，前后版本的格式就有兼容的问题，slob 虽然不支持全文检索但也有类似的问题。
自己设计格式，需要索引哪些数据，怎么样把这些数据整合到同一个格式中，怎么样在词典软件中展现这些数据，需要权衡的细节会比较多，可能会不断的推倒重来，sqlite 的表结构在早期设计的时候会更方便。
問一下，OLex 英和和英 是不是也是加密所以才沒下聞？
olex3电子版之前还没有，刚刚看了下，四天前才出来。你说olex2，没人做所以没有，站内的monokakido不都是fince和notwind在做吗，别人要么不会，要么懒得做。
2025年3月2日
・「オーレックス英和辞典 第3版」をリリースしました。
1 个赞
olexje2 keystore格式魔数不一样，好像得分开讨论。
嗯。不过我现在对这个问题不太上心了，知道个大概的结构就行，反正也是为了仿制新格式。
我怀疑有多少程序摸到了 SQLite 的瓶颈。。
早期java可能确实性能不够，但现在5202年了…java编译器和虚拟机早就优化了多少个数量级，哪怕写纯java代码在运行时底层还是会涉及到部分native代码的。有些特定程序java版跑起来甚至比C语言版还快（两者都没有优化的情况下）。况且正经安卓程序员有多少会NDK开发的…也不多。总不能要求每个人既要会java又要会C吧…
1 个赞
嗯，主要是我看到十几家安卓词典app都把词典的读取逻辑写在native库里，我猜测是性能需求，如果是使坏的话就是防逆向。
我也觉得物书堂不需要一次性提取几十万词头，不过这个软件就这么设计的。
虽然 sqlite 的上下限都很高，但毕竟不是专门设计的词典格式，有些可以优化的地方比较隐晦，比如 sqlite 的词头如果按顺序写入读取的时候可以接近磁盘的速度，如果随机写入又要按顺序读取，速度可能会下降 10 倍不止。
除了游戏、视频解码等少数场合，一般的APP如果有性能需求那就是伪需求。无非就是防破解，他们需要把key写进native库里…
靠近底层的语言[C/C++]可跨不了平台噢。java表示这活害得我来干
macos、iOS肯定不行，它们的动态库格式是.dylib（Mach-O object file），和Linux .so（ELF格式）不是一回事。
1 个赞
还可能有跨平台的原因，不需要再写多套代码了。
1 个赞
只是 abi 不兼容，跨平台重新编译下就行了。
1 个赞
是iOS词典壳阅读器吗