宣传一下自己写的基于 web 技术的词典软件

Anson夏天 · 2025 年1 月 9 日 00:32

加了以后就如图所示了

Anson夏天 · 2025 年1 月 9 日 00:34

可以了少加了个空格

Anson夏天 · 2025 年1 月 9 日 02:41

新的问题词典文件似乎读取不到

crissium · 2025 年1 月 9 日 12:49

如果愿意帮忙解决这个问题，可以放一下具体的错误信息。

更好的办法是去 GitHub 开个 issue, 管理起来更方便一些。

Anson夏天 · 2025 年1 月 10 日 02:14

似乎是没有提示，mdx文件放到source文件夹，应该就可以吧

knetxp · 2025 年1 月 10 日 09:51

这个有没有exe可执行程序版本的词典

crissium · 2025 年1 月 10 日 12:37

放到 source 文件夹下之后，是否有到 Web UI 去重新扫描源目录呢？

crissium · 2025 年1 月 10 日 12:38

曾经有做成 exe 一键运行的打算，但后来感觉没什么必要就放弃了。

Mandolin · 2025 年2 月 8 日 14:53

不知道哪里有问题，词头都查得到，但都显示词条不存在，图片词典、简单文本词典以及有@@@LINK规则的词典都不行：

有一瞬间进入词条页了，但马上又不行了。

Mandolin · 2025 年2 月 8 日 15:04

有了，这个词典支持：

FengLiang · 2025 年2 月 9 日 02:22

真的很棒的思想。为啥GitHub不好访问呢？

Vim · 2026 年6 月 1 日 15:41

在 docker 中部署了 SilverDict，并成功添加了词典。

但是要想使用好，手头上的词典几乎都要调整适配，因为它的要求比较高：

词典 mdx mdd 和 css 等的文件名称必须完全相同才可以。但我看很多词典的 css 等文件名都是不同的。仅这一条估计就得改一大批词典。很多词典采用多个 mdd，那么文件名也就不同，不知道其是否支持？
虽然软件可以自动扫描添加词典，但对于多层嵌套的目录结构好像不支持，而我习惯将每个词典单独放在一个文件夹中，并放在某个类别目录下，这样方便维护。如果需要手工逐个添加词典，或手工维护词典分类，就很麻烦。
CSS，除非是那种简单的可以直接使用，但凡有点特别的，好像效果都消失了。不知道应该遵循什么规则来调试。

此外，总结了这个过程中遇到的 bug（结合 AI 分析来推断的）

github.com/Crissium/SilverDict

Multiple Critical KeyErrors/AttributeErrors during Dictionary Initialization and Automatic Scanning in Headless/YAML-driven Environments

已打开 03:50PM - 01 Jun 26 UTC

VimWei

## 💻 Environment * **OS:** Linux (Synology NAS DSM 7.2) * **Deployment:** Docke…r / Docker Compose * **Dictionary Library Size:** Large-scale library (~428 dictionaries, ~100GB of .mdx/.mdd files) --- ## 🛑 Bug 1: Unhandled `AttributeError` during file-existence check failure (Cascading Failure) ### 📝 Description When the application starts up, it reads `dictionaries.yaml` and verifies if each file physically exists using `os.path.isfile()`. If a dictionary file is missing, or returns `False` due to permission/encoding mismatches on Linux, the system attempts to remove it from the list by calling `self.remove_dictionary(dictionary_info)`. However, during this early initialization phase, `self.dictionary_metadata` **has not been loaded or defined yet**. This causes a fatal `AttributeError` which crashes the entire server container, trapping it in an infinite boot-loop. ### 🔍 Root Cause in Source Code In `settings.py` around line 213 (inside `__init__`): ```python if not os.path.isfile(dictionary_info['dictionary_filename']): logger.warning(f'Dictionary {dictionary_info["dictionary_name"]} not found, removing from the list.') self.remove_dictionary(dictionary_info) # 🚨 Throws AttributeError because metadata hasn't initialized yet! ``` The `remove_dictionary` method explicitly iterates over `self.dictionary_metadata`, which is defined **later** in the `__init__` sequence: ```python def remove_dictionary(self, dictionary_info: str) -> None: self.dictionaries_list.remove(dictionary_info) self._save_dictionary_list() for m in self.dictionary_metadata: # ❌ AttributeError: 'Settings' object has no attribute 'dictionary_metadata' ... ``` ### 💡 Suggested Fix Move the block that loads `self.dictionary_metadata` **before** the file-existence check loop, or wrap the early-stage `remove_dictionary` call in a safe mechanism that doesn't expect metadata to exist yet. --- ## 🛑 Bug 2: `KeyError` in Logger Warning and Save Logic due to Refactored Dictionary Keys ### 📝 Description During the recent refactoring where dictionary metadata keys changed between versions (e.g., introduction of `dictionary_filename` and format enums), the error handling logs and file-saving sequences still rely on old key constraints. When a dictionary triggers the "Not Found" warning mentioned in Bug 1, it crashes with `KeyError: 'dictionary_name'` or `KeyError: 'dictionary_format'` because the fallback code paths were not completely updated. ### 🔍 Root Cause in Source Code 1. **Logger KeyError:** In `settings.py` line 212: ```python logger.warning(f'Dictionary {dictionary_info["dictionary_name"]} not found...') ``` If the YAML configuration relies purely on newer unique fields, `dictionary_name` might raise a KeyError or crash the warning. 2. **Format KeyError:** In `_save_dictionary_list()` around line 183: ```python for dictionary_info in self.dictionaries_list: if dictionary_info['dictionary_format'] == 'DSL (.dsl/.dsl.dz)'... # ❌ Throws KeyError if 'dictionary_format' is absent during early removals ``` ### 💡 Suggested Fix Use safe dictionary get methods (e.g., `dictionary_info.get('dictionary_name', 'Unknown')`) within the logging and serialization layers to prevent a simple warning from becoming a hard, breaking crash. --- ## 🛑 Bug 3: Automatic Scanning (`scan_sources`) Is Unusable for Large/Complex Local Libraries ### 📝 Description The built-in automatic source scanner (`scan_sources()`) works well for simple English filenames, but completely breaks when encountering large-scale local dictionary folders that contain spaces, brackets, or non-ASCII (Chinese) characters. The scanner directly uses the raw filename (minus extension) as both `dictionary_name` and `dictionary_display_name`. When the server reboots and reads this newly generated list, the unescaped spaces and special characters in `dictionary_name` fail inner path validation or database lookups, leading back to the catastrophic crash loops described in Bug 1 and 2. ### 🔍 Root Cause in Source Code In `scan_source()` around line 374: ```python if filename.endswith('.dsl.dz'): name = filename[:-len('.dsl.dz')] else: name = os.path.splitext(filename)[0] # 🚨 Directly uses raw filename string with spaces/special characters yield { 'dictionary_display_name': name, 'dictionary_name': name, # ❌ Becomes illegal database slug if it contains spaces/brackets/non-ASCII 'dictionary_format': dictionary_format, 'dictionary_filename': full_filename } ``` ### 💡 Suggested Fix Implement a proper slugification algorithm or a regular expression filter (e.g., `re.sub(r'[^a-zA-Z0-9_]', '', name)`) for generating the `dictionary_name` field during scanning, keeping it completely alphanumeric and distinct from the user-facing `dictionary_display_name`. --- ## 🎨 Architectural Limitation Notice (Optional, for developer's awareness) ### Strict Case-Sensitive Sandboxing for Asset Routing (.css/.mdd) The web server's routing system rigidly maps a dictionary's asset folder (styles, images) using the exact string value of `dictionary_name` (e.g., `CACHE_ROOT + "/" + dictionary_name`). While desktop clients like GoldenDict gracefully read any arbitrary CSS filename specified inside the `.mdx` HTML layer, SilverDict will throw silent `Entry not found` or 404 styling errors if the physical `.css` file on a Linux filesystem does not precisely match the case-sensitive casing of the registered `dictionary_name` id. It would be helpful to document this strict同名 naming convention or lowercase the asset routing path automatically.

Vim · 2026 年6 月 2 日 02:50

即使借助 AI 分析 SilverDict 仓库的源码，依然搞不懂 SilverDict 解析 mdx 词典的规律，请看案例：

对于以下部署环境中的 3 个词典：
（1）我如果使用 windows + goldendict，这 3 个词典都能正常使用；
（2）在 synology 中采用 docker（mathdodger/silverdict）部署的 SilverDict，使用自动扫描添加这些词典，我们可以看到程序已经正确识别这些词典，但是检索时，只有 Longman WordWise Dictionary2 这个词典可以正常识别和查询词条，但它的查询结果中，每个例句的音频文件却又都看不见；
（3）如果我将 oxfordprimary.css 更名为 OxfordPrimary.css，则 SilverDict 也能查询；
（4）如果将 lpd.css 和 lpd.js 的文件名也都更名为与 mdx 相同的名称，那么也可以查询，但是查询结果中其样式好像没有启用 css。

\01 Pronunciation\Longman Pronunciation Dictionary.mdd
\01 Pronunciation\Longman Pronunciation Dictionary.mdx
\01 Pronunciation\Longman Pronunciation Dictionary.png
\01 Pronunciation\Longman Pronunciation Dictionary.1.mdd
\01 Pronunciation\lpd.css
\01 Pronunciation\lpd.js
\02 Primary Children\Longman WordWise Dictionary2.mdd
\02 Primary Children\Longman WordWise Dictionary2.mdx
\02 Primary Children\Longman WordWise Dictionary2.png
\02 Primary Children\LWWD.css
\02 Primary Children\oxfordprimary.css
\02 Primary Children\OxfordPrimary.mdd
\02 Primary Children\OxfordPrimary.mdx

是否与这个因素有关呢：GD 支持外部的 css 文件取代 mdd 内部打包的 css 文件，而SilverDict的处理机制有所不同？
猜测（没有指导文档，只能盲猜）：如果 mdd 打包了 css 文件，那么 SilverDict 就能解析（采用源码html中指向的css名称）；如果 mdd 没打包 css 文件，而外部的 css 文件名又与 mdx 文件名不同，那么就无法解析（采用 mdx 名称去匹配 css）？