Как найти один китайский иероглиф в журнале со смешанным китайско-английским текстом

Начните с документации по поиску самого приложения

Поиск — это функция приложения, а не универсальное правило. Приложение для ведения журнала может использовать полнотекстовый индекс, базовое сканирование текста или сразу несколько режимов. Даже продукты, созданные на базе SQLite, могут различаться по используемым расширениям SQLite, токенизаторам и специфической логике обработки на стороне приложения. Например, [Joplin документирует использование SQLite FTS4](https://joplinapp.org/help/apps/search/) и указывает, что переключается на специальный режим для языков, не использующих латинские границы слов, включая китайский. На этой же странице разделяются точное совпадение терминов и поиск по подстроке в задокументированном режиме FTS. Эти детали описывают Joplin и не определяют то, как устроен поиск в другом журнале.

Уточните точную версию продукта и платформы, а затем обратите внимание, описаны ли в руководстве полнотекстовый поиск, базовый режим, сопоставление по токенам или словам, поиск по подстроке, языковая специфика и индексируемый контент (например, вложения). Не делайте вывод, что строка поиска сканирует каждый видимый символ, только потому, что она принимает ввод на китайском языке. И наоборот, не думайте, что индекс обязательно проигнорирует китайский текст: в приложении может быть предусмотрен режим с поддержкой языковых особенностей или иная реализация.

Создайте небольшую контрольную заметку

Используйте одну известную заметку в качестве контролируемого теста. Например, создайте тестовую заметку со следующим содержанием: «山水 — 北京 — journal». Здесь 山 — это известный одиночный иероглиф; 北京 — известное двухсимвольное слово; а journal — контрольное слово на английском языке. Сохраните заметку, подождите предусмотренное документацией время для индексации и выполните поиск по каждому элементу отдельно. Зафиксируйте, находится ли заметка по запросам 山, 北京 и journal. Это предложенные проверки, а не результаты тестирования какого-либо конкретного приложения.

Если по запросу journal заметка также не находится, сначала проверьте, сохранена ли она, включена ли в выбранную учетную запись или блокнот и входит ли в область искомых полей. Если запрос journal работает, но ни один китайский запрос не дает результатов, проблема носит более точечный характер и связана с обработкой CJK-символов или интерпретацией поисковых запросов. Если 北京 находит заметку, а 山 — нет, зафиксируйте это различие: оно может указывать на ограничение минимальной длины термина или логику границ токенов, хотя сам по себе этот результат еще не раскрывает причину.

Внимательно сравните полнотекстовый, базовый поиск и поиск по подстроке

При полнотекстовом поиске приложение может разбивать текст на термины (токены) и сопоставлять эти проиндексированные термины. Поиск по подстроке, напротив, ищет заданную последовательность символов внутри более крупного текста. Это принципиально разное поведение: совпадение по целому термину вовсе не означает совпадение по любой более короткой последовательности внутри него. Joplin прямо документирует это различие для своих FTS-запросов и заявляет, что его специальный режим CJK позволяет избежать привязки к латинским границам слов. Задокументированный префикс со слэшем переключает приложение в режим базового поиска для случаев, с которыми FTS справляется плохо, хотя Joplin предупреждает, что этот режим может работать заметно медленнее. Используйте этот синтаксис только в Joplin и строго так, как описано в актуальном руководстве к нему.

Документация по базам данных помогает понять, почему важны детали реализации, но не позволяет заранее предсказать результаты работы конкретного приложения. [Документация FTS5](https://sqlite.org/fts5.html) в SQLite описывает настраиваемые токенизаторы, включая опции Unicode61 и trigram. Однако в упомянутой документации Joplin фигурирует FTS4. Поэтому примеры из FTS5 нельзя использовать как доказательство того, что Joplin — или любой другой журнал — использует именно эти токенизаторы. Всегда сверяйтесь с собственной документацией приложения, прежде чем применять объяснения на уровне базы данных.

Анализируйте закономерность, а не только неудачный запрос

Используйте следующую последовательность, чтобы локализовать проблему:

Не переносите поисковые операторы или выводы из одного приложения в другое. В [руководстве пользователя Apple Заметок](https://support.apple.com/guide/notes/search-your-notes-not18ab658ed/mac) описан поиск по тексту заметок и нескольким типам вложений, а также отмечается, что доступные функции могут зависеть от учетной записи. Там не уточняются границы китайских токенов и не гарантируется поиск одиночных иероглифов как подстроки. Когда в официальной документации этот момент опущен, единственный надежный вывод заключается в том, что поведение приложения в этом аспекте просто не задокументировано.

О чем могут рассказать контрольные запросы

Контрольная заметка помогает отличить отсутствие заметки или неверную область поиска от проблемы, специфичной для конкретного языка. При этом она не дает исчерпывающего представления о том, как приложение индексирует каждую отдельную заметку, вложение, учетную запись или язык. Зафиксируйте вместе точное название приложения, платформу, версию, режим поиска и результаты трех запросов — такая краткая запись гораздо полезнее, чем общая фраза «поиск на китайском не работает». Если вам требуется надежный поиск по отдельным иероглифам для реального архива, проверьте поведение системы на собственных показательных заметках, прежде чем реорганизовывать или заново импортировать их.

Продолжить изучение темы