OmniDocТермін вказує на те, що слово існує, але збіг не вдається? Спочатку перевірте представлення Unicode
Це слово чітко є в глосарії, але програма каже, що звернення немає. Роздрукуйте рядок і переконайтеся, що обидві сторони здаються абсолютно однаковими. Причина може полягати не в перекладі, а в представленні Юнікоду: символ із наголосом може бути або однією точкою коду, або основною літерою плюс символ об’єднання.
Це слово чітко є в глосарії, але програма каже, що звернення немає. Роздрукуйте рядок і переконайтеся, що обидві сторони здаються абсолютно однаковими. Цей тип проблеми є поширеним у сценаріях пакетного перекладу, пошуку термінів і порівняння документів. Причина часто полягає не в самому перекладі, а в представленні Юнікоду: символ із наголосом може бути або однією кодовою точкою, або складатися з основних літер і комбінованих символів.
У цій статті використовуються синтетичні зразки, щоб продемонструвати метод обробки, який допоможе вам спочатку знайти джерело різниці, а потім вирішити, як нормалізувати та зберегти дані.
Код було перевірено з прикладами в ізольованому середовищі, це не є гарантією всіх реальних файлів або продуктивності продукту. Перед обробкою важливих документів збережіть оригінали та перегляньте їх відповідно до меж і пунктів прийняття в тексті.
Що робити, якщо не вдається зіставити термін? Висновок одним реченням
Спочатку визначте, чи це різниця у представленні чи різниця у вмісті: відмінності у представленні можна вирівняти за допомогою нормалізації, наприклад NFC, тоді як відмінності у вмісті потрібно обробити назад до самого терміну.
| ваша ситуація | Рекомендовані практики | причина |
|---|---|---|
| Рядки виглядають однаково, але збіг не вдається | Виконайте нормалізацію NFC перед порівнянням | NFC часто використовується для вирівнювання канонічно еквівалентних представлень |
| Потрібні ширші збіги пошуку, наприклад повна ширина та половинна ширина | Оцініть NFKC, але не перезаписуйте вихідний текст | NFKC має ширшу область застосування, згортає сумісні символи та не обов’язково підходить для архівних або технічних символів. |
| Непослідовний відмінок | Створюйте ключі відповідності без урахування регістру | casefold можна використовувати для незалежного зіставлення |
| Потрібно виділити або повернутися до вихідного тексту | Збережіть відображення фрагментів оригінального тексту або змініть розташування на рівні оригінального тексту | Довжина може змінитися після нормалізації, а використання зміщення безпосередньо призведе до скорочення неправильного діапазону. |
Спочатку перевірте, чи це відмінність чи вміст.
Виконайте нормалізацію NFC перед порівнянням, яка часто використовується для вирівнювання канонічно еквівалентних представлень. NFKC має ширший діапазон і згортає деякі сумісні символи. Це може задовольнити потреби пошуку, але не обов’язково збереження архіву чи порівняння технічних символів.
Не плутайте "легше зіставити" з "семантика має залишатися незмінною".
У синтетичному прикладі два способи написання é повинні бути послідовними після NFC; літери повної ширини та верхні індекси використовуються, щоб показати зміни, які внесе NFKC. Вони є лише конкретними прикладами і не означають, що всі проекти повинні приймати певну форму.
Використовуйте код, щоб побачити відмінності, яких ви не бачили раніше.
import unicodedata as ud
composed = "café"
decomposed = "cafe\u0301"
assert composed != decomposed
assert ud.normalize("NFC", composed) == ud.normalize("NFC", decomposed)
fullwidth = "ＡＢＣ"
assert ud.normalize("NFC", fullwidth) == fullwidth
assert ud.normalize("NFKC", fullwidth) == "ABC"
assert ud.normalize("NFKC", "x²") == "x2"
def term_key(text):
return ud.normalize("NFC", text).casefold()
assert term_key("CAFÉ") == term_key(decomposed)
assert term_key("x²") != term_key("x2")
print([f"U+{ord(c):04X}" for c in decomposed])У прикладі вибрано NFC плюс casefold для відповідності термінів, що є навмисно обмеженою стратегією відповідності. casefold також створює залежні від мови результати згортання, тому незручно просто замінювати весь вихідний текст згенерованими ключами.
Оригінальний текст і відповідні ключі зберігаються окремо.
Збережіть original_text і створіть інший normalized_key. Перший використовується для відображення, відстеження та перегляду, а другий використовується для пошуку відповідно до поточної стратегії.
Також запишіть назву та версію політики. У майбутньому, коли використовуються інші правила, індекс можна буде перебудувати відповідно, замість того, щоб виявляти, що вихідний текст було незворотно перезаписано.
| спостерігати | Дії, які варто спробувати | Речі, які не можна робити випадково |
|---|---|---|
| Комбінована різниця наголосів | Дотримуйтесь чіткої стратегії для NFC | Стверджувати, що кількість символів більше не має значення |
| Різниця напівширини повної ширини | Оцініть NFKC відповідно до потреб бізнесу | Безпосередньо покривати оригінальний текст технічної документації |
| Різниця між регістрами | Створіть відповідні ключі без урахування регістру | Зробити весь текст у нижньому регістрі |
| Досі не влучили | Перевірте кодові точки та фактичні деталі нижче | Продовжуйте накопичувати і замінювати правила, щоб спробувати удачу |
Нормалізація не вирішує всі проблеми «виглядає однаково»
Латинські літери з подібними формами можуть не мати стандартизованого або сумісного еквівалентного зв'язку з ієрогліфами інших шрифтів. Символи нульової ширини, різні пробіли та розпізнавання літер OCR як цифр — усе це вимагає індивідуальної діагностики.
Коли йдеться про ситуації, чутливі до безпеки, такі як облікові записи чи ідентифікатори файлів, будь ласка, не сприймайте приклади відповідності термінології в цій статті як повний захист від заплутаних символів.
Відстежуваність місцезнаходження має працювати окремо
Після нормалізації довжина струни може змінюватися. Використання зсув символів у клавіші match для обрізання оригінального тексту може призвести до неправильного обрізання діапазону.
Коли потрібне виділення або бекрайтинг, відображення між оригінальним текстовим сегментом і відповідним ключем слід зберегти або перемістити на початковому рівні тексту.
Перед тим, як передавати запитання перекладачам, зберігайте докази на початку
При оцінці термінології та перекладацького робочого процесу OmniDoc ви можете підготувати два Unicode-представлення одного й того ж терміна, записуючи вихідний текст, використану стратегію та переклад.
Таким чином, коли виявляються невідповідності, можна розрізнити, чи проблема полягає у відповідності вхідних даних чи виборі перекладу, уникаючи звинувачень у всіх відмінностях на моделі перекладу.
📊 Порівняння ядра
| Стратегія | Основна функція | Потрібна обережність |
|---|---|---|
| NFC | Еквівалентні представлення стандарту вирівнювання підходять для порівняльної попередньої обробки | Форма сумісних символів не змінюється |
| NFKC | Ширший діапазон дозволяє складати сумісні символи, що може полегшити пошук | Він може бути непридатним для архівного збереження або порівняння технічних символів |
| casefold | Створення ключів, що не залежні від регістру | Результати пов'язані з мовою і не повинні бути безпосередньо замінені оригінальним текстом |
🎯 Який метод тобі підходить?
Якщо потрібно перевірити, чи дві струни однакові
Спочатку зробіть нормалізацію NFC, потім порівняйте. Це відправна точка для перевірки відмінностей для їх представлення.
Якщо ви робите пошук або пошук за запитом
Ви можете створити normalized_key і записати назву та версію політики, залишивши оригінальний текст незмінним.
Якщо потрібно зберегти оригінальний текст для відображення або перегляду
Залишайте original_text, не перезаписуйте його ключем match.
Якщо ви маєте справу з архівами, технічними символами або контентом, чутливим до безпеки
Спочатку оцінюйте, чи підходить NFKC, і окремо перевіряйте на символи нульової ширини, схожі символи та інші проблеми. Не розглядайте нормалізацію як повний захист.
❓ Поширені запитання (FAQ)
1. Дві струни виглядають однаково, то чому вони не можуть поєднуватися?
Можливо, один і той самий акцентований символ використовує два представлення: одну кодову точку або базову літеру плюс комбінований символ. Порівняно з нормалізацією NFC, їх можна вирівняти.
2. Чи можна використовувати NFKC безпосередньо для об'єднання всіх персонажів?
Не обов'язково. NFKC складає сумісні символи і може не відповідати потребам архівного архівування або технічного порівняння символів; оцінка має базуватися на бізнес-вимогах.
3. Після нормалізації чи можете ви безпосередньо виділити оригінальний текст, зміщуючи символи?
Його не можна використовувати безпосередньо. Після нормалізації довжина може змінюватися, тому необхідно зберігати фрагментні відображення або переставляти їх у початковому тексті.
4. Чи може нормалізація розпізнати всіх персонажів із схожою зовнішністю?
Ні. Символи з подібним виглядом можуть не мати стандартизованої або сумісної еквівалентності; символи нульової ширини, пробіли та помилки OCR також потребують окремої діагностики.
📝 Резюме
Коли відповідність термінів не вдається, спочатку переконайтеся, чи відображає Unicode різницю чи різницю вмісту, а потім оберіть чітку стратегію нормалізації. Оригінальний текст і відповідні ключі зберігаються окремо для балансування ефективності пошуку та відстежуваності.
Джерела: Python unicodedata
Досвід зараз: завантажте документ, щоб почати переклад, зберігаючи оригінальне форматування
