Одинаковые строки не совпадают: нормализация Unicode

Если две строки выглядят одинаково, а импорт создаёт дубль или проверка считает значения разными, сравните последовательности кодовых точек Unicode. Видимый знак может быть представлен готовым символом либо сочетанием основы и отдельного комбинируемого знака. Скриншот показывает внешний вид, но не раскрывает это различие. До исправления нужно установить точную пару исходных значений и правило сравнения конкретного поля.

Нормализация помогает для определённого класса эквивалентных последовательностей, но не означает «сделать всё похожее одинаковым». Она не заменяет правила регистра, поиск опечаток и решение о принадлежности двух карточек одному человеку. Ниже рассматривается предлагаемая обработка обычного текстового справочника. Это не политика имён в документах, паролей или юридической идентификации.

Контрольная пара: знак и последовательность

Возьмём учебное значение с латинской буквой e и ударением. В первом варианте используется кодовая точка U+00E9. Во втором — U+0065 и U+0301. При подходящем отображении читатель видит похожий результат, однако исходные последовательности различаются. Для воспроизведения полезно сохранить именно коды, а не перепечатать строку с фотографии: при ручном вводе можно случайно получить другой вариант.

MDN демонстрирует применение String.normalize для получения выбранной формы Unicode. В проверенном учебном сравнении этих двух вариантов после NFC получается одинаковое значение. Но латинская a и кириллическая а остаются разными. Это отдельный случай визуального сходства, который нельзя объявить решённым тем же преобразованием.

Таблица относится к указанным строкам и формам, а не ко всем похожим символам. Для собственной базы нужен набор значений из разрешённой тестовой копии. Не проверяйте всю клиентскую выгрузку в случайном онлайн-конвертере. Если проблема воспроизводится на искусственной паре кодовых точек, реальная база для объяснения механизма вообще не нужна.

У каждого поля свой смысл равенства

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

До разработки спросите владельца данных, зачем система сравнивает значения. Она ищет подсказку, запрещает повтор справочного элемента или определяет существование конкретной записи? Одинаковое преобразование может быть приемлемо для одного действия и недостаточно для другого. Например, совпадение поискового ключа помогает предложить кандидата, но не доказывает право перезаписать найденную карточку.

Для первого решения запишите правило обычными словами и приложите положительные и отрицательные примеры. Какие два значения должны находиться вместе? Какие обязаны оставаться различными? Кто решает спорный случай? Если ответ сводится к «пусть программа догадается», автоматизация получит неоднозначность вместо технического требования.

Сохраните исходник рядом с ключом сравнения

Предлагаемая модель разделяет первоначальное значение, результат согласованной нормализации и идентификатор записи. Первое нужно для просмотра происхождения данных. Второе используется в определённой проверке или поиске. Третье связывает операции с сущностью и не должно самопроизвольно меняться из-за исправления способа сравнения текста.

Например, импорт сохранил два написания одного условного справочного названия. Можно сформировать одинаковый ключ и показать группу кандидатов на разбор, оставив исходные строки доступными. Затем уполномоченный сотрудник принимает решение. Это предложенный сценарий проектирования, а не заявление, что любая существующая CRM уже поддерживает подобный журнал.

Полезно фиксировать и версию правила. Если позже изменится преобразование, станет понятно, почему новая проверка нашла дополнительные совпадения. Необязательно выводить технические подробности каждому менеджеру. Но разработчик должен уметь воспроизвести результат для выбранной записи, не подменяя её исходное значение последним вычисленным ключом.

NFC и NFKC нельзя выбирать по числу найденных дублей

Unicode Standard Annex #15 различает канонические формы и формы совместимости. Выбор влияет на то, какие различия будут устранены. В учебной таблице полноширинная буква совпадает с обычной после NFKC, но не после NFC. Большее количество совпадений само по себе не означает более подходящий результат для вашего поля.

Перед изменением правила сформируйте отчёт без записи в рабочую базу: какие пары стали равными, а какие сохранили различие. Попросите владельца справочника проверить несколько групп и отдельно известные исключения. Не стоит принимать решение только по общей цифре «найдено сто дублей». Важнее, какие именно объекты оказались в одной группе и допустимо ли такое сравнение.

Не добавляйте по пути удаление знаков, замену алфавитов и исправление регистра без отдельного согласования. Цепочка преобразований должна быть понятной. Если результат оказался неожиданным, потребуется установить конкретный шаг, который убрал различие. Один общий переключатель «очистить текст» скрывает это основание и делает приёмку почти невозможной.

Совпавший ключ ещё не разрешает слияние

Два поставщика могут использовать одинаковое название. Один человек может иметь несколько независимых договоров. Даже без различий Unicode текстовое совпадение не определяет границы сущности. Поэтому исправление нормализации не должно автоматически превращаться в массовое объединение клиентов, товаров или документов.

Заранее опишите результат коллизии. При проверке уникальности справочника это может быть отказ создания с понятным предложением выбрать существующий элемент. При импорте — строка на ручную проверку. При поиске — несколько подходящих кандидатов с уточняющими признаками. Эти варианты соответствуют разным задачам, поэтому нельзя выбрать один за всех пользователей.

Для исторических данных нужен отдельный план. Сначала сохраняется разрешённая резервная копия и формируется перечень затронутых записей. Затем проверяются связи и согласованные действия с каждой группой. Обновление функции сравнения для новых строк и изменение ранее созданных объектов — разные работы. Их стоит оценивать и принимать раздельно.

Проверьте все пути поступления текста

Если правило применяется только в браузерной форме, импорт и интеграция могут продолжить создавать другую картину. Составьте перечень входов: ручной ввод, загрузка файла, обмен с внешней системой и редактирование существующего значения. Для каждого нужен одинаково определённый результат на контрольной паре, если он относится к тому же полю.

Не ограничивайтесь экраном «успешно сохранено». Откройте запись повторно, выполните поиск и подготовьте небольшую выгрузку учебных данных. Выясните, где показывается исходное написание, а где используется ключ. Если экспорт предназначен для другой системы, согласуйте, какое представление ей требуется. Иначе следующая интеграция снова начнёт сравнивать значения по своим правилам.

Именно поэтому полезно отличать эту задачу от общего разбора поиска, который не находит товары. Пустая выдача может быть связана с индексом, фильтром или отсутствующим полем. Нормализация Unicode объясняет конкретное различие представления строк, а не любую проблему поиска на сайте.

Как принять исправление на небольшом наборе

Составьте проверку из четырёх пар таблицы и нескольких согласованных значений своего справочника. Для каждой заранее укажите ожидаемое сравнение и действие при совпадении. Разработчик должен показать исходные кодовые точки, применённую форму и результат. Если пример проверен только глазами, причина исходной ошибки остаётся неподтверждённой.

Повторите импорт той же пачки и изменение одной существующей строки. Убедитесь, что не появились лишние карточки и не объединились разные объекты. Проверьте отказ и ручное разрешение коллизии там, где они предусмотрены. Финальный результат работы — воспроизводимое правило выбранного поля с сохранённым происхождением, а не универсальное обещание сделать любой похожий текст одинаковым.