如何在中文與英文混用的數位日記中搜尋單個中文字

從應用程式本身的搜尋說明文件著手

搜尋是應用程式的功能，並非放諸四海皆準的通用規則。日記軟體可能會使用全文檢索索引、基本文字掃描，或是多種模式併用。即使是基於 SQLite 建置的產品，其 SQLite 擴充套件、斷詞器（tokenizer）以及針對特定應用程式的處理方式也可能各不相同。例如，[Joplin 的文件說明其使用了 SQLite FTS4](https://joplinapp.org/help/apps/search/)，並指出對於不使用拉丁詞界的語言（包括中文），它會切換到自訂模式。其頁面也區分了在記載的 FTS 模式下「精確詞匹配」與「子字串匹配」的差異。這些細節是 Joplin 的專門設計，並不代表其他日記軟體的運作方式。

請確認確切的產品與平台版本，接著查看操作手冊是否描述了全文檢索搜尋、基本模式、斷詞（token）或詞語匹配、子字串匹配、特定語言行為，以及是否包含附件等索引內容。不要僅僅因為搜尋框允許輸入中文，就推斷它會掃描每一個可見的字元。反之，也不要直接認定索引會排除中文：該應用程式可能具備語言辨識模式或其他實作方式。

建立一篇小型的對照測試筆記

使用一篇已知內容的筆記作為對照檢查。例如，建立一篇內容為「山水 — 北京 — journal」的測試筆記。在這裡，「山」是一個已知的單一中文字；「北京」是一個已知的雙字詞；而「journal」則是作為對照的英文單字。儲存該筆記，預留文件說明的索引建立延遲時間，然後分別搜尋每個項目。記錄下該筆記是否會在搜尋「山」、「北京」和「journal」時出現。這些是建議的檢查步驟，而非測試特定真實應用程式所得的結果。

如果連搜尋「journal」也找不到該筆記，請先檢查筆記是否已儲存、是否包含在所選的帳號或筆記本中，以及是否屬於被搜尋的欄位範圍內。如果「journal」可以找到，但兩個中文查詢都找不到，則問題較偏向於 CJK（中日韓）處理機制或搜尋詞的解讀方式。如果「北京」可以找到但「山」不行，請記錄下這一區別：這可能指向最小詞長度限制或詞界斷詞行為，但僅憑此結果尚無法確定根本原因。

仔細比對全文檢索、基本搜尋與子字串搜尋

在全文檢索中，應用程式可能會將文字切分為詞元（terms）並匹配這些已建立索引的詞元。子字串搜尋則是在較長的文字內部尋找特定的字元序列。這兩者是不同的行為：能夠匹配整個詞，並不一定代表能夠匹配其中包含的每個較短序列。Joplin 的說明文件明確指出了其 FTS 查詢的這項差異，並表示其 CJK 自訂模式可避免依賴拉丁語系詞界。其文件中記載的斜線前綴（slash prefix）可用於切換至基本搜尋，以處理 FTS 表現不佳的情況，儘管 Joplin 提醒此模式的速度可能慢得多。請僅在 Joplin 中且僅依其目前手冊的說明使用該語法。

資料庫文件可以解釋實作細節為何重要，但不能預測特定應用程式的實際結果。SQLite 的 [FTS5 說明文件](https://sqlite.org/fts5.html)介紹了可配置的斷詞器，包含 Unicode61 和 trigram 選項。然而，前面引用的 Joplin 文件指明使用的是 FTS4。因此，不能拿 FTS5 的範例來宣稱 Joplin 或所有日記軟體都使用這些斷詞器。在套用資料庫層級的解釋之前，請務必先查閱應用程式本身的說明文件。

診斷問題模式，而非單看查詢失敗

請依照以下順序逐步縮小問題範圍：

不要將某個應用程式的搜尋運算子或測試結論套用到另一個應用程式上。Apple 的 [備忘錄使用者指南](https://support.apple.com/guide/notes/search-your-notes-not18ab658ed/mac) 介紹了搜尋筆記內文及多種附件類型的方式，並提到可用功能可能取決於帳號類型。該指南並未指明中文詞界規則，亦未保證支援單字子字串檢索。當官方文件對該點未予說明時，最可靠的結論就只是該行為在該處「未經記載」。

對照搜尋能告訴你什麼

對照筆記有助於釐清究竟是筆記遺失、搜尋範圍錯誤，還是特定語言的搜尋機制問題。它無法證明應用程式是如何對每篇筆記、附件、帳號或語言建立索引的。將確切的應用程式、平台、版本、搜尋模式以及三種查詢結果彙整在一起；這樣的精確記錄比單純反映「中文搜尋壞了」有用得多。如果你在管理真實的筆記封存時需要可靠的單字查詢功能，在重新整理或重新匯入之前，請務必先使用你最具代表性的筆記確認其運作行為。

繼續探索這個主題