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

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.