OmniDoc용어는 단어가 존재하지만 일치가 실패함을 나타냅니다. 유니코드 표현을 먼저 확인하세요
이 단어는 용어집에 분명히 나와 있는데, 프로그램에서는 히트가 없다고 나옵니다. 문자열을 인쇄하여 양쪽이 정확히 동일한지 확인합니다. 그 이유는 번역에 있는 것이 아니라 유니코드 표현에 있을 수 있습니다. 악센트 문자는 단일 코드 포인트이거나 기본 문자와 결합 기호일 수 있습니다.
이 단어는 용어집에 분명히 나와 있는데, 프로그램에서는 히트가 없다고 나옵니다. 문자열을 인쇄하여 양쪽이 정확히 동일한지 확인합니다. 이러한 유형의 문제는 일괄 번역, 용어 검색 및 문서 비교 시나리오에서 일반적입니다. 그 이유는 종종 번역 자체가 아니라 유니코드 표현에 있습니다. 악센트 문자는 단일 코드 포인트이거나 기본 문자와 결합 기호로 구성될 수 있습니다.
이 기사에서는 합성 샘플을 사용하여 먼저 차이의 원인을 찾은 다음 데이터를 정규화하고 저장하는 방법을 결정하는 데 도움이 되는 처리 방법을 보여줍니다.
코드는 격리된 환경에서 예제로 확인되었으며, 이는 모든 실제 파일이나 제품 성능을 보장하지는 않습니다. 중요한 서류를 처리하기 전, 원본을 보관하시고, 본문에 기재된 경계 및 허용 항목에 따라 검토하시기 바랍니다.
용어 매칭에 실패하면 어떻게 해야 하나요? 한 문장 결론
먼저 표현 차이인지 내용 차이인지 결정합니다. 표현 차이는 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 평가 | 기술문서의 원문을 직접 커버 |
| 대소문자 차이 | 대소문자를 구분하지 않는 일치 키 만들기 | 표시 텍스트를 모두 소문자로 만들기 |
| 아직도 안 맞았어 | 실제 컨텍스트로 코드 포인트 보기 | 계속해서 규칙을 중첩하고 교체하여 행운을 시험해 보세요. |
정규화는 "같은 모양"을 모두 해결하지 못합니다.
라틴 문자와 유사한 모양을 가진 다른 스크립트의 문자 간에는 표준화되거나 호환 가능한 등가 관계가 없을 수 있습니다. 너비가 0인 문자, 공백이 다른 문자, 문자를 숫자로 인식하는 OCR 등은 모두 별도로 진단해야 합니다.
계정 및 파일 식별자와 같이 보안에 민감한 시나리오의 경우 이 문서의 용어 일치 예제를 완전한 난독화된 문자 보호로 간주하지 마십시오.
위치 추적은 별도로 처리해야 합니다.
문자열 길이는 정규화 후에 변경될 수 있습니다. 일치하는 키의 문자 오프셋을 사용하여 원본 텍스트를 자르면 잘못된 범위가 잘릴 수 있습니다.
강조 표시하거나 다시 작성해야 하는 경우 원본 텍스트 조각과 일치하는 키 간의 매핑을 유지하거나 원본 텍스트 수준에서 재배치해야 합니다.
번역가에게 질문을 제출하기 전에 증거를 보관하세요
OmniDoc의 용어 및 번역 작업 흐름을 평가할 때 소스 텍스트, 사용된 전략 및 번역을 문서화하여 동일한 용어에 대한 두 개의 유니코드 표현을 준비할 수 있습니다.
이런 방식으로 불일치가 발견되면 문제가 입력 일치에 있는지 또는 번역 선택에 있는지 구분할 수 있으며 모든 차이점을 번역 모델에 비난하는 것을 피할 수 있습니다.
📊 핵심 비교
| 전략 | 주요 기능 | 주의가 필요하다 |
|---|---|---|
| NFC | 정렬 사양 등가 표현, 비교 전처리에 적합 | 호환되는 문자의 형태를 변경하지 마세요. |
| NFKC | 범위가 넓어지고 호환되는 문자가 축소되며 검색이 더 쉬워질 수 있습니다. | 기술 기호의 보관 보존이나 비교에 반드시 적합한 것은 아닙니다. |
| casefold | 대소문자를 구분하지 않는 일치 키 만들기 | 결과는 언어에 따라 다르며 원본 텍스트를 직접 바꾸는 것은 적절하지 않습니다. |
🎯 어떤 방법이 당신에게 적합합니까?
두 문자열이 동일한지 확인해야 하는 경우
NFC 정규화를 먼저 수행한 후 비교하세요. 이것이 표현의 차이를 검토하는 출발점입니다.
검색이나 용어검색을 하고 있는 경우
normalized_key를 생성하고 정책 이름과 버전을 기록할 수 있으며 원본 텍스트는 변경되지 않습니다.
표시나 검토를 위해 원문을 보관해야 하는 경우
original_text를 유지하고 일치하는 키로 덮어쓰지 마십시오.
아카이브, 기술 기호 또는 보안에 민감한 콘텐츠를 다루는 경우
먼저 NFKC가 적절한지 평가하고 너비가 0인 문자 및 유사 문자 등의 문제를 별도로 해결합니다. 정규화를 완전한 보호로 간주하지 마십시오.
❓ 자주 묻는 질문(FAQ)
1. 두 문자열이 똑같아 보이는데 왜 일치하지 않나요?
동일한 액센트 문자가 단일 코드 포인트 또는 기본 문자와 결합 기호의 두 가지 방법으로 표시될 수 있습니다. 비교하기 전에 NFC 정규화를 수행하면 정렬할 수 있습니다.
2. NFKC를 직접 사용해 모든 캐릭터를 통합할 수 있나요?
불확실한. NFKC는 보관 보존 또는 기술 기호 비교 요구 사항을 충족하지 못할 수 있는 호환 문자를 축소하고 비즈니스 요구에 따라 평가해야 합니다.
3. 정규화 후 문자 오프셋을 직접 사용하여 원본 텍스트를 강조할 수 있나요?
직접 사용할 수는 없습니다. 정규화 후에 길이가 변경될 수 있으므로 조각 매핑을 유지하거나 원본 텍스트 수준에서 위치를 변경해야 합니다.
4. 정규화하면 외모가 비슷한 모든 문자를 인식할 수 있나요?
할 수 없습니다. 유사한 모양의 문자는 정식 또는 호환 동등성이 없을 수 있으며 너비가 0인 문자, 공백 및 OCR 오류도 별도로 진단해야 합니다.
📝 요약
용어 일치가 실패하면 명시적 정규화 전략을 선택하기 전에 먼저 차이가 유니코드 표현인지 아니면 콘텐츠 차이인지 확인하세요. 원본 텍스트와 일치하는 키를 별도로 저장한 경우에만 검색 효과와 추적성을 고려할 수 있습니다.
