문자열 검색
이 문서에 대한 자세한 정보
Copyright © 2016-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Copyright © 2016-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
이 문서는 더 높은 상호 운용성을 가능하게 하기 위해 웹에서의 문자열 검색 연산을 설명합니다. 문자열 검색은 웹 브라우저의 "찾기" 명령과 같은 자연어 문자열 일치를 의미합니다. 이 문서는 World Wide Web 문자 모델 1.0: 기본 사항 및 World Wide Web 문자 모델: 문자열 일치에서 제시된 개념을 바탕으로, 명세 작성자, 소프트웨어 개발자 및 콘텐츠 개발자가 전 세계 사용자를 대상으로 적합한 검색 기능을 설명하고 구현하는 데 필요한 정보를 제공합니다.
이 절에서는 이 문서의 발행 당시 상태를 설명합니다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정판은 다음 W3C 표준 및 초안 목록에서 확인하실 수 있습니다.
주의: 작업 진행 중
이 문서는 국제화 워킹 그룹에서 활발히 개발하고 있지 않습니다. 다른 I18N 문서의 범위를 벗어나는 자연어 텍스트의 부분 문자열 일치에 관한 정보를 기록하고, 웹에서 부분 문자열 일치의 문제를 논의할 때 바로 참고할 수 있는 자료로 활용하기 위해 작성되었습니다.
독자 여러분께서는 여기에 수록된 자료가 "찾기" 기능의 구현이나 명세 작성을 위한 완전한 지침을 제공한다고 기대해서는 안 됩니다.
이 문서는 국제화 워킹 그룹에서 그룹 노트 초안으로 발행했으며, 노트 트랙을 따릅니다.
그룹 노트 초안은 W3C나 그 회원의 승인을 받은 문서가 아닙니다.
이 문서는 초안이며 언제든지 다른 문서에 의해 갱신되거나 대체되거나 폐기될 수 있습니다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 적절하지 않습니다.
이 문서에는 W3C 특허 정책 에 따른 어떠한 라이선스 요구 사항이나 약정도 적용되지 않습니다.
이 문서에는 2025년 8월 18일자 W3C 프로세스 문서가 적용됩니다.
W3C 국제화 워킹 그룹과 관심 그룹을 비롯한 여러 분께서 많은 의견과 제안을 주셨습니다. 워킹 그룹은 다음 분들께 감사드립니다: 문자 모델 문서 시리즈를 여러 해에 걸쳐 개발하는 동안 기여해 주신 모든 분들입니다.
이 예제의 사례들은 Henri Sivonen이 작성한 페이지에서 가져왔으며, 그가 이 이슈에 기록한 여러 개념과 아이디어도 활용했습니다.
이 문서는 문자열 검색 작업의 명세 작성이나 구현과 관련된 문제, 요구 사항 및 고려 사항을 설명합니다. 문자열 검색의 일반적인 예는 웹 브라우저의 "찾기" 명령이지만, 명세에서 정의하고자 할 수 있는 검색의 형태는 그 밖에도 다양합니다.
이 문서는 월드 와이드 웹을 위한 문자 모델: 기초 [CHARMOD] 및 월드 와이드 웹을 위한 문자 모델: 문자열 일치 [CHARMOD-NORM]를 바탕으로 합니다. 이 문서를 올바르게 이해하고 적용하려면 해당 문서들에서 다루는 개념을 이해하는 것이 중요합니다.
이 명세의 주요 대상 독자는 어떤 형태로든 검색 또는 찾기 알고리즘을 정의해야 하는 W3C 명세 개발자입니다: 필요한 개념, 용어 및 요구 사항에 관한 안정적인 참고 자료를 제공하는 것이 목표입니다.
이 문서에서 설명하는 개념은 명세 작성자, 소프트웨어 개발자 및 콘텐츠 개발자에게 월드 와이드 웹에서 일관되고 상호운용 가능한 텍스트 검색을 위한 공통 참고 자료를 제공합니다. 이 세 집단이 협력하면 전 세계에서 접근할 수 있는 웹을 구축할 수 있습니다.
이 문서에는 다른 명세를 위한 모범 사례와 요구 사항뿐 아니라 구현 및 콘텐츠 작성자를 위한 권고 사항도 포함되어 있습니다. 이러한 명세용 모범 사례와 그 밖의 모범 사례는 국제화 워킹 그룹의 문서인 명세 개발자를 위한 국제화 모범 사례 [INTERNATIONAL-SPECS]에서도 확인할 수 있으며, 이 문서는 W3C 명세의 모든 국제화 모범 사례를 위한 종합 참고 자료로 작성되었습니다.
이 문서에서 [RFC2119]의 키워드는 대문자 기울임꼴로 표시되며 통상적인 의미를 갖습니다. 또한 다음과 같은 스타일 규칙을 사용합니다:
정의는 이와 같이 다른 배경색과 장식으로 표시됩니다.
모범 사례는 이와 같이 다른 배경색과 장식으로 표시됩니다.
이슈, 미비점 및 향후 작업을 위한 권고 사항은 이와 같이 다른 배경색과 장식으로 표시됩니다.
이 절에는 이 문서에 고유한 용어가 포함되어 있습니다.
이 문서를 이해하는 데 필요한 용어의 대부분은 국제화 용어집 [I18N-GLOSSARY]에서 제공합니다. 일부 용어는 [CHARMOD-NORM]에서도 정의하며, 해당 문서의 용어 및 표기법 절에서 확인할 수 있습니다.
유니코드는 범용 문자 집합이라고도 하며, 어떤 컴퓨팅 플랫폼에서든 세계의 모든 표기 체계, 문자 체계 또는 언어로 웹 문서를 작성하고, 전 세계 웹 사용자가 이를 교환하고 읽고 검색할 수 있게 합니다. 유니코드 표준 [Unicode]의 처음 몇 장은 유용한 배경 지식을 제공합니다. 또한 유니코드 정렬 알고리즘 [UTS10]도 참고하십시오. 여기에는 검색에 관한 장이 포함되어 있습니다.
말뭉치 사용자가 검색하려는 문서 또는 문서 집합에 포함된 자연어 텍스트입니다.
민감 또는 비민감. 검색 작업이 검색어와 말뭉치의 텍스트 중 어느 쪽에든 나타나는 특성을 바탕으로 둘 사이의 변형을 구분하는 정도입니다. 검색어와 말뭉치 사이의 어떤 차이나 변형으로 인해 일치하지 않으면 검색이 민감하다고 하며, 말뭉치와 검색어 사이의 그러한 차이를 무시하면 비민감하다고 합니다 (그 결과 검색어가 말뭉치에서 일치합니다). 다양한 민감도의 예는 2.2 동등성 판단의 문제에서 확인할 수 있으며, 대소문자 민감도, 악센트/발음 구별 부호 민감도 또는 문자 체계 민감도 등이 있습니다.
분할 자연어 텍스트를 개별 단어와 구로 나누는 과정입니다. 여기에는 흔히 "개체명 인식" (예를 들어 세 단어로 이루어진 시퀀스인 Dr. Jonas Salk가 사람의 이름임을 인식하는 것)과 같은 작업이 포함됩니다.
어간 추출 단어를 그 "어간" 또는 어근으로 축약하는 과정이나 작업입니다. 예를 들어 runs, ran 및 running이라는 단어는 모두 어간 run을 공유합니다. 이를 때로는 (더 공식적인 용어로) 표제어 추출이라고 부르며, 어간을 표제어라고 부르기도 합니다.
전문 검색은 텍스트 문서 또는 문서 집합의 전체 내용을 처리하는 검색을 의미합니다. 전문 쿼리는 영어 또는 일본어와 같은 특정 언어의 규칙에 따라 단어와 구를 처리하여 전문 색인의 텍스트 데이터에 대해 언어학적 검색을 수행합니다. 전문 쿼리에는 단순한 단어와 구 또는 단어나 구의 여러 형태가 포함될 수 있습니다.
이는 흔히 전문 검색이 색인과 자연어 처리를 사용한다는 의미입니다. 검색 엔진을 사용할 때는 전문 검색의 한 형태를 사용하는 것입니다. 전문 검색은 흔히 자연어 텍스트를 단어나 구로 나누며 (이를 분할이라고 합니다), 복잡한 처리를 적용하여 단어의 의미상 "어근" 값을 구하기도 합니다 (이를 어간 추출이라고 합니다). 이러한 과정은 언어, 문맥 및 텍스트 변형의 여러 다른 측면에 민감합니다.
자연어 처리 (NLP)는 인간의 언어 (즉, 자연 언어)를 이해하고 처리하고 조작하도록 설계된 소프트웨어 영역을 의미합니다. 이는 매우 광범위한 용어입니다. 단어 토큰화와 같은 비교적 단순한 문제부터 텍스트에서 "의미"를 도출하거나, 품사를 인식하거나, 정확한 번역을 수행하는 등의 더 복잡한 동작까지 아우를 수 있습니다.
표의문자 변형 시퀀스는 변형 시퀀스 중 표의문자 변형 데이터베이스에 등록된 것을 의미합니다. 표의문자 변형 시퀀스의 기본 문자는 표의문자여야 하며, U+E0100..U+E01EF 범위의 변형 선택자를 사용합니다. 표의문자 변형 시퀀스라는 용어는 때로 "IVS"로 줄여 씁니다. 유니코드 정의 및 [UTS37]도 참고하십시오.
한자 및 기타 표의문자의 경우, 모든 사용자의 모든 요구를 동시에 충족할 수 있는 단일 변형 시퀀스 모음을 구축하는 것은 불가능합니다. 학자, 정부 및 출판사의 요구 사항은 너무 달라서 단일 모음으로 수용할 수 없습니다. 대신 서로 독립적인 여러 모음을 마련하여 충족할 수 있습니다. 유니코드는 표의문자 변형 데이터베이스 [UTS37]를 정의하여 각 변형 시퀀스에 단 하나의 정의가 존재하도록 보장하며, 그러한 변형 시퀀스를 사용하는 텍스트를 안정적으로 교환할 수 있게 합니다.
웹 사용자는 흔히 문서나 문서 모음을 한 줄씩 읽지 않고 특정 텍스트를 검색하고자 합니다. 명세에서는 이러한 요구를 지원하기 위해 웹 플랫폼에 텍스트 검색 기능을 제공하려 하기도 합니다.
문서 검색에는 여러 유형이 있습니다. 그중 전문 검색이라고 하는 유형은 검색 엔진과 같은 애플리케이션에서 가장 흔히 볼 수 있는 검색 방식입니다. 이러한 검색은 복잡하고 많은 자원을 소모할 수 있으며, 흔히 주어진 검색 요청의 범위를 벗어나는 처리 과정에 의존합니다.
더 제한적인 형태의 텍스트 검색 (그리고 이 문서의 주제)은 부분 문자열 일치
입니다.
익숙한 부분 문자열 일치의 한 형태는 브라우저 및 기타 유형의 사용자 에이전트에서 제공하는 찾기
기능입니다. 물리적 키보드가 있는 사용자 에이전트에서는 흔히
Cmd+F 또는 Ctrl+F와 같은 키 조합으로 이 기능에 접근합니다. 이러한 기능은 웹에서
현재 완전히 표준화되지 않은 API인 window.find를 통해 제공되거나,
제안된 [SCROLL-TO-TEXT-FRAGMENT]와 같은 기능을 통해 제공될 수 있습니다.
찾기 작업은 일치 동작을 개선하거나 조정하기 위한 선택적 수단을 제공할 수 있습니다. 예를 들어 대소문자 구분을 추가하거나 제거하는 기능, 와일드카드 문자와 같은 정규 표현식 언어의 여러 기능을 지원할지 여부, 일치 대상을 단어 전체로 제한할지 여부 등이 있습니다. 검색이 이러한 변형을 고려하는 정도를 검색 민감도라고 하며, 검색 민감도에서 설명합니다.
부분 문자열 일치가 전문 검색과 일반적으로 다른 점 중 하나는, 텍스트 변형을 억제하거나 무시하기 위해 여러 알고리즘을 사용할 수는 있지만, 일반적으로 추가되거나 지정되지 않은 문자 시퀀스, 단어 또는 구를 포함하는 일치 결과는 생성하지 않는다는 것입니다. 이러한 결과는 어간 추출 또는 기타 NLP 처리에서 나타날 수 있습니다.
부분 문자열 일치를 표준화하려 할 때 명세 작성자는 흔히 컴퓨터 시스템에서 자연어를 인코딩하는 데 내재된 복잡성으로 어려움을 겪습니다. 여기에는 [Unicode] 표준에서 문자를 인코딩하는 데 사용하는 다양한 방식도 포함됩니다.
검색 작업마다 텍스트 변형을 고려하는 정도가 다릅니다. 대소문자를 구분하지 않는 검색은
a
와 A
의 차이를 무시합니다; 발음 구별 부호를 무시하는 검색은
cote
와 côte
를 일치시킵니다; 정확한 일치를 요구하는 검색은 이러한 차이를 하나도 무시하지 않습니다.
검색 작업이 이러한 변형을 구분하는 정도를 검색 민감도라고 합니다.
아래에서 설명하는 텍스트 변형의 유형과 검색 시 고려 사항에서는 아무 옵션도 선택하지 않았을 때 검색에 기본적으로 적용할 민감도를 권고합니다. 이러한 기본값이 구현이나 API에서 다른 수준의 민감도를 제공하는 것을 막지는 않습니다.
사용자에게 검색 기능을 제공하는 구현체는 기본 동작보다 더 민감한 일치를 얻을 수 있도록 하는 것이 좋습니다. 여기에는 대소문자와 발음 구별 부호를 구분하는 일치가 포함됩니다.
명세에서 작성자에게 검색 기능을 제공하는 경우, 작성자가 해당 기능을 호출할 때 일치 민감도를 설정할 수 있도록 하는 것이 좋습니다.
콘텐츠 작성자는 브라우저의 찾기
명령과 같이 사용자 에이전트가
사용자에게 직접 제공하는 검색 기능의 민감도를 설정할 수 없습니다. 작성자는 다른 방식으로 일치에 영향을
줍니다: 텍스트의 언어와 같은 정보를 제공하거나 (언어에 따른 일치의 차이 참고), 자체 검색
기능을 구현하는 방식입니다.
구현자는 흔히 단순한 "텍스트 찾기" 알고리즘을 제공해야 하며, 명세에서는 흔히 이러한 요구를 지원하는 API를 정의하려 합니다. 텍스트의 찾기 작업은 문서 형식 및 프로토콜에서 요구하는 완전한 동일성 일치와는 다른 사용자 기대를 낳으며, 따라서 요구 사항도 다릅니다. 분야별 요구 사항에 따라 추가 제약이 부과되거나 여기에서 제시하는 고려 사항이 달라질 수 있다는 점에 유의해야 합니다.
사용자의 입력 노력 증가는 더 선택적인 일치에 반영되는 것이 좋습니다.
사용자가 shift 키로 대문자를 입력하거나 단순한 기본 문자 대신 발음 구별 부호가 있는 문자를 입력하는 등 입력에 더 많은 노력을 들이면, 검색 결과도 자신의 더 구체적인 입력에 (만) 일치하기를 기대할 수 있습니다.
사용자의 입력이 검색 대상 문서에서 사용하는 것과 정확히 같은 코드 포인트 시퀀스로 이루어지지 않았는데도 사용자가 일치를 기대하는 경우가 매우 많습니다. 이는 여러 가지 이유로 발생할 수 있습니다. 검색 대상 텍스트가 사용자가 예측할 수 없는 방식으로 변형되어 있기 때문일 때도 있습니다. 사용자의 키보드나 입력 방법으로 필요한 텍스트 변형을 쉽게 입력할 수 없기 때문인 경우도 있습니다. 심지어 사용자가 텍스트를 정확하게 입력하는 것을 귀찮아하기 때문일 수도 있습니다.
이 절에서는 명세 작성자가 부분 문자열 일치 API나 메커니즘을 명시할 때 고려해야 하는, 알려진 여러 일반적인 사례를 살펴봅니다.
검색어가 문서 또는 말뭉치의 특정 부분과 일치하는지에 대한 사용자의 기대는 때로 사용자의 언어, 문서의 언어 또는 둘 모두에 따라 달라집니다. 특정 기기에서 어떤 키보드나 입력 방법을 사용할 수 있는지와 같은 다른 요인도 관련될 수 있습니다. 이는 케이스 폴딩처럼 검색의 일부인 여러 작업이 로캘의 영향을 받기 때문일 수도 있고, 인간의 언어와 문화가 복잡하여 일치에 대한 기대나 다양한 문자 시퀀스의 사용 및 해석에 대한 기대가 동일한 문자 체계 안에서도 다르기 때문일 수도 있습니다. 마찬가지로 악센트, 대체 문자 체계 또는 문자 인코딩 (예를 들어 자소 클러스터 구성의 차이)의 처리도 해당 텍스트의 특정 언어와 관련됩니다.
여기서 의미하는 것은 언어이며, 문자 체계가 아니라는 점을 강조해야 합니다. 같은 문자 체계를 공유하는 여러 언어가 서로 다른 처리를 적용하거나 서로 다른 기대를 전제합니다.
"찾기" 기능의 구현체는 흔히 사용자의 입력만을 근거로 하거나 실행 환경의 다양한 "단서", 예를 들어 운영 환경의 로캘, 사용자 에이전트의 현지화 언어 또는 활성 키보드의 언어를 근거로 사용자가 의도한 언어를 추측해야 합니다. 이러한 단서는 기껏해야 사용자 의도를 간접적으로 나타내는 지표일 뿐이며, 특히 사용자가 이들 중 어느 것과도 언어가 일치하지 않는 문서를 검색하거나 검색 대상 문서에 둘 이상의 언어가 포함된 경우에는 더욱 그렇습니다.
기본적으로 문자열 검색은 대소문자를 구분하지 않는 것이 좋습니다.
사용자는 소문자로 입력한 검색어가 그에 해당하는 대문자 형태와 일치하기를 (그리고 아마 그 반대도) 기대할 수 있습니다. 브라우저의 "찾기" 명령과 같은 부분 문자열 일치 기능은 흔히 입력과 텍스트의 대소문자를 일치시킬지 여부를 사용자가 선택할 수 있는 옵션을 제공합니다.
케이스 폴딩의 개요는 여기에 있는 [CHARMOD-NORM]의 설명 및 [Unicode] 5장의 대소문자 매핑 절을 참고하십시오.
대소문자를 구분하지 않는 문자열 검색은 기본적으로 유니코드 전체 케이스 폴딩을 사용하는 것이 좋습니다.
유니코드는 각 코드 포인트에 대한 기본 케이스 폴딩을 정의합니다. 대부분의 문자에서 기본 폴딩은
한 문자를 다른 단일 문자로 변환합니다; 유니코드는 이러한 매핑을 공통 (상태
C)이라고 부릅니다. 소수의 문자는 둘 이상의 문자로 폴딩됩니다; 유니코드는
이러한 매핑을 전체 (상태 F)라고 부릅니다. 공통 매핑과 전체
매핑을 함께 사용하면 유니코드 전체 케이스 폴딩이 되며, 이는
유니코드 전체의 기본 케이스 폴딩입니다. 예를 들어 공통 매핑은 켈빈 기호 KU+212A KELVIN SIGN를
k
와 일치시키고, 전체 매핑은 독일어 문자 ßU+00DF LATIN SMALL LETTER SHARP S를 시퀀스 ss
와
일치시킵니다.
매핑과 그 상태 문자는
CaseFolding.txt에
정의되어 있으며,
이 파일은 유니코드 문자 데이터베이스 [UAX44]에 포함되어 있습니다.
케이스 폴딩 자체만으로는 문자의 전각 형태와 반각 형태를 일치시키지 않습니다:
ＫU+FF2B FULLWIDTH LATIN CAPITAL LETTER K는 케이스 폴딩을 거치면
반각 k
가 아니라 전각 ｋ
가 됩니다. 이 형태들을 일치시키려면
동아시아 문자 폭에서 설명하는 추가 처리가 필요합니다.
구현체는 언어별 케이스 폴딩 조정을 기본적으로 적용하지 않는 것이 좋습니다.
구현체는 검색어의 언어를 알 때 언어별 케이스 폴딩 조정을 적용할 수 있습니다. 예를 들어 터키어와 아제르바이잔어에서 사용하는 튀르크어계 매핑이 있습니다.
유니코드의 기본 케이스 폴딩은 언어에 독립적입니다: 모든 언어에서 대문자 I
를
소문자 i
로 케이스 폴딩합니다. 이는 튀르크어계 언어 사용자의 기대와 다릅니다. 해당 언어에서는
I
와 ı
(ıU+0131 LATIN SMALL LETTER DOTLESS I)가
İ
와 i
와 마찬가지로 대소문자만 다른 쌍이기 때문입니다. 유니코드 문자 데이터베이스는 이러한 문자에 대해 별도의
매핑 (상태 T)을 제공하며, 이는 유니코드가 정의하는 유일한
언어별 케이스 폴딩입니다. 이 조정을 적용하면
ILIK
과 같은 검색어가 단어 ılık과 일치하지만, 적용하지 않으면 검색에서 해당
단어가 누락됩니다.
그러나 언어별 조정을 적용하는 것은 기본 동작으로 적합하지 않습니다. 일치 여부를 검사하는 두 문자열은 서로 다른 언어일 수 있으며, 또 다른 제3의 언어 문맥에 나타날 수도 있습니다. 또한 검색어나 텍스트 본문의 언어는 알 수 없거나 신뢰할 수 없는 경우가 많습니다. 이는 위의 언어에 따른 일치의 차이에서 설명합니다.
유니코드는 문자 간의 정규 관계와 호환 관계를 정의하며, 이는 문자열 검색에 대한 사용자의 인식에 영향을 줄 수 있습니다. 유니코드 정규화 형식에 관한 자세한 설명은 [CHARMOD-NORM]의 2.2절 및 유니코드 정규화 형식 [UAX15]의 정의를 참고하십시오.
여러 복잡한 문자 체계에서는 문자나 모음 부호를 둘 이상의 방식으로 인코딩할 수 있지만, 그 대체 형태들은 정규적으로 동등합니다.
일부 언어는 둘 이상의 문자 체계로 표기합니다. 문서를 검색하는 사용자는 한 문자 체계로 텍스트를 입력하더라도 두 문자 체계 모두에서 동등한 텍스트를 찾고자 할 수 있습니다.
검색 중에는 사용자가 달리 지정하지 않는 한 전각과 반각 문자 형태의 차이를 무시하는 것이 좋습니다.
일부 호환 문자는 레거시 문자 인코딩의 단일 바이트 또는 다중 바이트 표현을 수용하거나 동아시아 언어의 특정 레이아웃 동작과 호환되도록 유니코드에 인코딩되었습니다.
유니코드에는 앞선 문자의 글리프 변형을 지정하는 데 사용되는 몇 가지 변형 선택자가 포함되어 있습니다.
예를 들어, 하나의 표의문자는 사용하는
변형 선택자 (VS)에 따라 여러 변형을 가질 수 있습니다. 예를 들어 龍U+9F8D CJK UNIFIED IDEOGRAPH-9F8D
뒤에
U+E0100 VARIATION SELECTOR-17 또는
U+E0101 VARIATION SELECTOR-18과 같은 서로 다른 변형 선택자가 오면 서로 다른 글리프를
나타낼 수 있습니다:
| 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|
| 龍󠄀 | 龍󠄁 | 龍󠄂 | 龍󠄅 | 龍󠄆 |
| VS-17 | VS-18 | VS-19 | VS-22 | VS-23 |
| 龍󠄈 | 龍󠄉 | 龍󠄊 | 龍󠄋 | 龍󠄌 |
| VS-25 | VS-26 | VS-27 | VS-28 | VS-29 |
문자열 검색 작업에서는 표의문자만을 대상으로 일치 여부를 검사할지, 전체 표의문자 변형 시퀀스 (IVS)를 대상으로 할지 고려해야 합니다.
문자열 검색을 수행할 때는 IVS (예: 龍󠄀U+9F8D CJK UNIFIED IDEOGRAPH-9F8D + U+E0100 VARIATION SELECTOR-17)를
하나의 단위로 취급하고 첫 번째 코드 포인트를 처리 기준으로 사용하십시오.
가능하다면 다양한 사용자 요구를 수용할 수 있도록 "유사" 및 "정밀" 검색 모드를 모두 지원하십시오.
IVS 외에도 다른 언어에 변형 선택자가 있습니다.
사용자 에이전트는 문자열 검색 작업에서 숫자 값을 나타내는 문자를 ASCII 형태 (0-9)로 매핑할 수 있습니다.
여러 문자 체계에는 0부터 9까지의 수를 나타내는 고유한 숫자 문자가 있습니다. 일부 웹 애플리케이션에서는 표시를 위해 익숙한 ASCII 숫자를 현지 숫자 형태로 바꿉니다. 다른 경우에는 텍스트에 실제로 현지 숫자의 유니코드 문자가 포함될 수도 있습니다. 문서를 검색하려는 사용자는 한 형태의 숫자를 입력하면 동등한 숫자들도 찾을 수 있다고 기대할 수 있습니다.
일부 언어에는 지역이나 방언에 따라 다른 철자법 전통이 있거나 같은 단어에 여러 철자를 허용합니다. 검색과 맞춤법 검사에서는 이러한 차이를 알아야 할 수 있습니다.
인도계 문자를 사용하는 언어에는 이러한 문제가 많이 나타납니다. 때로는 철자 오류이지만, 다른 경우에는 여러 철자가 허용됩니다.
예를 들어 벵골어 (언어 태그 bn)는
언어에서 허용하는 철자 변형의 폭이 넓기로 유명합니다: 벵골어 단어의 거의 80%가
두 가지 이상의 철자를 갖습니다. 많은 단어에 3개, 4개 또는 그 이상의 변형이 있으며—적어도
한 단어에는 16가지의 서로 다른 유효한 철자가 있습니다.
다른 인도계 문자 체계에서도 특정 소리를 표현하는 대체 방식을 제공하며, 대부분의 경우 어느 표현이든 똑같이 유효한 것으로 간주합니다. 가장 흔한 사례는 음절 말 비음의 표현입니다.
예를 들어 힌디어에서 뱀을 뜻하는 단어의 /n/ 소리는 ँ [U+0901 DEVANAGARI SIGN CANDRABINDU] 또는 ं [U+0902 DEVANAGARI SIGN ANUSVARA]로 표기할 수 있습니다. 다음 두 가지 모두 유효한 철자가 될 수 있습니다:
여기에 더 복잡한 점이 하나 있는데, 서로 다른 코드 포인트를 가진 두 발음 구별 부호를 사용할 수 있다는 것입니다. 앞의 예에서는 ं [U+0902 DEVANAGARI SIGN ANUSVARA ]로 비음을 표현했습니다. 함께 쓰이는 모음 부호가 매달림 기준선 위로 올라가기 때문입니다. 모음 부호가 매달림 기준선 위로 올라가지 않는 형태라면, 보통은 대신 ँ [U+0901 DEVANAGARI SIGN CANDRABINDU ]를 사용합니다. 이 두 발음 구별 부호의 기능은 같지만 코드 포인트는 다릅니다.
음절 말 비음을 문자 또는 발음 구별 부호로 대체하여 표기하는 방식은
다른 여러 인도 언어에서도 흔합니다. 힌디어
(언어 태그 hi)나 마라티어 (언어 태그 mr와 같은 언어를 표기하는
데 사용하는 데바나가리 문자 외에도, 말라얄람 문자, 구자라트 문자, 오리야 문자 등에서
비슷한 철자 선택지를 제공합니다.
일부 언어는 공백으로 단어, 문장 또는 문단을 구분하지만, 그렇지 않은 언어도 있습니다. 부분 문자열 일치를 수행할 때는 [Unicode]에 있는 다양한 형태의 공백을 정규화해야 일치에 성공할 수 있습니다.
발음 구별 부호가 없는 검색어는 말뭉치의 발음 구별 부호가 포함된 텍스트와 일치하는 것이 좋습니다. 이는 사용자가 검색을 달리 설정하지 않은 경우에 적용됩니다.
발음 구별 부호가 있는 검색어는 동등한 발음 구별 부호가 있는 텍스트에만 일치하는 것이 좋습니다.
발음 구별 부호가 있는 문자를 부호가 없는 형태와 구분해야 하는 사용자는 검색 민감도에서 설명한 대로 더 민감한 일치를 요청할 수 있습니다.
사용자는 다양한 발음 구별 부호를 사용하는 문자 체계 (예를 들어 라틴 문자)로 검색어를 입력할 때, 검색 대상 텍스트에 추가 부호가 포함되어 있더라도 악센트나 발음 구별 부호가 있는 문자의 입력 형태를 바꾸기도 합니다. 특히 이러한 문자를 입력하는 데 추가 노력이 들 수 있는 모바일 키보드에서 자주 나타납니다. 이 경우 사용자는 필요한 추가 노력을 들이지 않은 것을 보완하도록 검색 작업이 더 "폭넓게" 일치시키기를 일반적으로 기대합니다.
이러한 효과는 사용 환경에 따라서도 달라질 수 있습니다. 예를 들어 물리적 키보드를 사용하는 사람은 악센트가 있는 문자를 바로 입력할 수 있지만, 가상 키보드나 화면 키보드에서는 같은 문자에 접근하여 선택하는 데 추가 노력이 필요할 수 있습니다.
일부 철자법에서는 문자 수가 서로 다른 문자열을 일치시켜야 합니다.
대표적인 예는 아브자드의 모음 구별 부호입니다. 예를 들어 아랍 문자와 히브리 문자를 사용하는 일부 언어에서는 사용자가 짧은 모음을 입력할 필요가 없지만 선택적으로 입력할 수는 있습니다. (이 문자 체계를 사용하는 다른 일부 언어에서는 짧은 모음의 포함이 선택 사항이 아닙니다.) 입력하거나 검색하는 텍스트에서 모음의 유무는 사용자가 모음을 입력하지 않거나 입력해야 한다는 것을 모를 경우 일치를 방해할 수 있습니다.
경우에 따라 서로 다른 코드 포인트 시퀀스로 시각적으로 비슷하거나 동일한 글리프 패턴을 만들 수 있습니다. 때로는 의도된 것이며, 유니코드 정규화를 통해 차이를 제거할 수 있습니다. 그러나 비슷하게 보이는 자소가 정규화를 거쳐도 같아지지 않으며, 의미적으로도 동등하지 않은 경우가 있습니다.
아랍 문자를 사용하는 일부 언어에도 자소를 둘 이상의 방식으로 인코딩할 수 있는 경우가 있습니다. 이러한 변형 중 일부는 유니코드 정규화로 처리되지만, 다른 경우에는 시각적으로 동일해 보여도 유니코드에서 동등한 것으로 간주하지 않습니다. 때로는 이러한 변형이 유효한 철자 변형으로 간주됩니다. 다른 경우에는 사용자의 잘못된 인식에서 비롯됩니다.
영어나 아랍어와 같은 일부 언어는 단어 사이에 공백을 사용합니다. 중국어, 일본어 또는 태국어와 같은 다른 언어는 사용하지 않습니다. 일부 언어는 구와 같은 다른 텍스트 단위를 구분하는 데 공백을 사용합니다. 단어 사이에 공백을 사용하지 않는 언어에서 "단어 전체" 일치를 계산하는 것은 흔히 경계 자체가 텍스트에 인코딩되어 있지 않을 때 단어 경계를 판별할 수 있는지에 달려 있습니다.