문자열 검색
이 문서에 대한 자세한 정보
Copyright © 2016-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Copyright © 2016-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
이 문서는 더 높은 상호 운용성을 가능하게 하기 위해 웹에서의 문자열 검색 작업을 설명합니다. 문자열 검색은 웹 브라우저의 "찾기" 명령과 같은 자연어 문자열 매칭을 가리킵니다. 이 문서는 Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD] 및 Character Model for the World Wide Web 1.0: String Matching [CHARMOD-NORM]에서 찾을 수 있는 개념을 바탕으로, 전 세계 사용자를 대상으로 하는 검색 기능을 설명하고 구현하는 데 필요한 정보를 명세 작성자, 소프트웨어 개발자, 콘텐츠 개발자에게 제공합니다.
이 절은 이 문서가 발행된 시점의 상태를 설명합니다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정판은 https://www.w3.org/TR/의 W3C 기술 보고서 색인에서 찾을 수 있습니다.
주의: 진행 중인 작업
이 문서는 국제화 워킹 그룹에서 활발히 개발되고 있지 않습니다. 이 문서는 다른 I18N 문서에서는 주제에서 벗어났던 자연어 텍스트의 부분 문자열 매칭에 관한 정보를 포착하고, 웹에서 부분 문자열 매칭 문제에 관한 논의를 위한 즉시 참조 자료로 쓰이도록 작성되었습니다.
독자는 여기에 있는 자료가 "찾기" 기능의 구현 또는 명세화를 위한 완전한 지침을 나타낸다고 기대해서는 안 됩니다.
이 문서는 국제화 워킹 그룹이 노트 트랙을 사용하여 그룹 초안 노트로 발행했습니다.
그룹 초안 노트는 W3C나 그 회원의 승인을 받은 것이 아닙니다.
이 문서는 초안 문서이며 언제든지 다른 문서로 갱신, 대체 또는 폐기될 수 있습니다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 적절하지 않습니다.
W3C 특허 정책은 이 문서에 대해 어떠한 라이선스 요구사항이나 약속도 수반하지 않습니다.
이 문서는 2023년 11월 3일 W3C 프로세스 문서의 적용을 받습니다.
이 문서는 문자열 검색 작업의 명세 또는 구현을 위한 문제, 요구사항, 고려사항을 설명합니다. 문자열 검색의 일반적인 예는 웹 브라우저의 "찾기" 명령이지만, 명세가 정의하고자 할 수 있는 검색의 형태는 이 외에도 많습니다.
이 문서는 Character Model for the World Wide Web: Fundamentals [CHARMOD] 및 Character Model for the Word Wide Web: String Matching [CHARMOD-NORM]을 바탕으로 합니다. 이 문서를 성공적으로 이해하고 적용하려면 해당 문서들의 개념을 이해하는 것이 중요합니다.
이 명세의 주요 대상 독자는 어떤 형태의 검색 또는 찾기 알고리즘을 정의해야 하는 W3C 명세 개발자입니다. 목표는 필요한 개념, 용어, 요구사항에 대한 안정적인 참조를 제공하는 것입니다.
이 문서에서 설명하는 개념은 명세 작성자, 소프트웨어 개발자, 콘텐츠 개발자에게 월드 와이드 웹에서 일관되고 상호 운용 가능한 텍스트 검색을 위한 공통 참조를 제공합니다. 이 세 그룹이 함께 작업하면 전 세계에서 접근 가능한 웹을 구축할 수 있습니다.
이 문서는 다른 명세를 위한 모범 사례와 요구사항뿐 아니라, 구현 및 콘텐츠 작성자를 위한 권장사항도 포함합니다. 명세(및 기타 대상)를 위한 이러한 모범 사례는 국제화 워킹 그룹의 문서 Internationalization Best Practices for Spec Developers [INTERNATIONAL-SPECS]에서도 찾을 수 있으며, 이 문서는 W3C 명세의 모든 국제화 모범 사례에 대한 일반 참조로 쓰이도록 의도되었습니다.
이 문서에서 [RFC2119]의 대문자 이탤릭체 키워드는 일반적인 의미를 가집니다. 또한 다음과 같은 스타일 규약을 사용합니다.
정의는 이와 같이 다른 배경색과 장식으로 표시됩니다.
모범 사례는 이와 같이 다른 배경색과 장식으로 표시됩니다.
이슈, 공백, 향후 작업에 대한 권장사항은 이와 같이 다른 배경색과 장식으로 표시됩니다.
이 절은 이 문서에 특화된 용어를 포함합니다.
이 문서를 이해하는 데 필요한 용어의 상당 부분은 Internationalization Glossary [I18N-GLOSSARY]에서 제공합니다. 일부 용어는 [CHARMOD-NORM]에서도 정의되어 있으며, 해당 문서의 용어와 표기법 절에서 찾을 수 있습니다.
Unicode는 Universal Character Set이라고도 하며, 웹 문서가 전 세계의 모든 문자 체계, 문자 또는 언어로, 어떤 컴퓨팅 플랫폼에서도 작성된 뒤 전 세계 웹 사용자에 의해 교환되고, 읽히고, 검색될 수 있도록 합니다. Unicode Standard [Unicode]의 처음 몇 장은 유용한 배경 읽을거리를 제공합니다. 또한 검색에 관한 장을 포함하는 Unicode Collation Algorithm [UTS10]도 참조하십시오.
코퍼스 사용자가 검색하고자 하는 문서 또는 문서 집합에 포함된 자연어 텍스트입니다.
분할 자연어 텍스트를 서로 구별되는 단어와 구로 나누는 과정입니다. 여기에는 종종 "개체명 인식"과 같은 작업이 포함됩니다(예: 세 단어의 순서인 Dr. Jonas Salk가 사람 이름임을 인식하는 것).
어간 추출 단어를 그 "어간" 또는 어근으로 줄이는 과정 또는 작업입니다. 예를 들어 runs, ran, running이라는 단어는 모두 run이라는 어간을 공유합니다. 이는 때때로 (더 공식적으로는) 표제어 추출이라고 하며, 어간은 때때로 표제어라고 합니다.
전문 검색은 텍스트 문서 또는 문서 집합의 전체 내용을 처리하는 검색을 가리킵니다. 전문 질의는 영어 또는 일본어와 같은 특정 언어의 규칙을 기반으로 단어와 구에 대해 동작함으로써, 전문 색인의 텍스트 데이터에 대해 언어적 검색을 수행합니다. 전문 질의에는 단순한 단어와 구, 또는 단어와 구의 여러 형태가 포함될 수 있습니다.
이는 흔히 전문 검색이 색인과 자연어 처리를 사용한다는 뜻입니다. 검색 엔진을 사용할 때, 사용자는 전문 검색의 한 형태를 사용하고 있는 것입니다. 전문 검색은 종종 자연어 텍스트를 단어 또는 구로 나누며(이를 분할이라고 합니다), 단어의 의미상 "어근" 값에 접근하기 위해 복잡한 처리를 적용할 수 있습니다(이를 어간 추출이라고 합니다). 이러한 과정은 언어, 문맥, 그리고 텍스트 변이의 여러 다른 측면에 민감합니다.
자연어 처리(NLP)는 인간의 언어(즉, 자연 언어)를 이해하고, 처리하고, 조작하도록 설계된 소프트웨어 영역을 가리킵니다. 이는 매우 폭넓은 용어입니다. 단어 토큰화와 같은 비교적 단순한 문제부터, 텍스트에서 "의미"를 도출하거나, 품사를 인식하거나, 정확한 번역을 수행하는 것 등 더 복잡한 동작까지 포함할 수 있습니다.
웹 사용자는 줄 단위로 읽지 않고도 문서 또는 문서 모음에서 특정 텍스트를 검색하고자 하는 경우가 많습니다. 명세는 때때로 웹 플랫폼에 텍스트 검색을 노출함으로써 이러한 요구를 지원하려고 합니다.
문서 검색에는 여러 유형이 있습니다. 그중 하나는 전문 검색이라고 하며, 검색 엔진과 같은 애플리케이션에서 가장 자주 볼 수 있는 검색 유형입니다. 이러한 유형의 검색은 복잡하고, 자원을 많이 사용할 수 있으며, 주어진 검색 요청의 범위를 벗어나는 과정에 의존하는 경우가 많습니다.
더 제한적인 형태의 텍스트 검색(이 문서의 주제)은 부분 문자열 매칭
입니다. 부분 문자열 매칭의 익숙한 형태 중 하나는
브라우저와 다른 유형의 사용자 에이전트에 있는 찾기
기능입니다. 물리적 키보드가 있는 사용자 에이전트에서는
이 기능이 흔히 Cmd+F 또는 Ctrl+F와 같은 키 조합으로 접근됩니다. 이러한 기능은 웹에서
현재 완전히 표준화되어 있지 않은 API window.find 또는 제안된 [SCROLL-TO-TEXT-FRAGMENT]와 같은 기능을 통해 노출될 수 있습니다.
찾기 작업은 매칭 동작을 개선하거나 맞춤화하기 위한 선택적 메커니즘을 제공할 수 있습니다. 예를 들어 대소문자 구분을 추가(또는 제거)하는 기능, 와일드카드 문자와 같은 정규 표현식 언어의 다양한 측면을 지원하는지 여부, 또는 매칭을 전체 단어로 제한할지 여부가 있습니다.
부분 문자열 매칭이 보통 전문 검색과 다른 한 가지 점은, 텍스트 변이를 억제하거나 무시하기 위해 다양한 알고리즘을 사용할 수는 있지만, 보통 어간 추출이나 기타 NLP 과정에서 생기는 것처럼 추가적이거나 명시되지 않은 문자 시퀀스, 단어 또는 구를 포함하는 매칭 결과를 생성하지는 않는다는 점입니다.
부분 문자열 매칭을 표준화하려고 할 때, 명세 작성자는 컴퓨터 시스템에서 자연 언어를 인코딩하는 데 내재한 복잡성, 특히 [Unicode] 표준에서 문자를 인코딩하기 위해 사용되는 다양한 메커니즘을 포함한 복잡성으로 인해 종종 어려움을 겪습니다.
매우 자주, 사용자의 입력은 검색 대상 문서에서 사용된 것과 정확히 같은 코드 포인트 시퀀스로 구성되지 않지만, 사용자는 여전히 매칭이 일어나기를 기대합니다. 이는 다양한 이유로 발생할 수 있습니다. 때로는 검색 대상 텍스트가 사용자가 예측할 수 없었던 방식으로 달라지기 때문입니다. 다른 경우에는 사용자의 키보드나 입력 방식이 필요한 텍스트 변이에 바로 접근할 수 있게 해 주지 않기 때문입니다. 심지어 사용자가 텍스트를 정확하게 입력하는 수고를 하려 하지 않기 때문일 수도 있습니다.
이 절에서는 명세 작성자가 부분 문자열 매칭 API 또는 메커니즘을 명세할 때 고려해야 하는 것으로 알려진 여러 일반적인 사례를 살펴봅니다.
검색어가 문서나 코퍼스의 특정 부분과 매칭되는지에 대한 사용자의 기대는 때때로 사용자의 언어, 문서의 언어, 또는 둘 모두에 따라 달라집니다. 또한 특정 장치에서 사용할 수 있는 키보드나 입력 방식과 같은 다른 요소가 관련될 수도 있습니다. 이는 대소문자 폴딩과 같이 검색의 일부인 여러 작업이 로캘의 영향을 받거나, 인간 언어와 문화의 복잡성으로 인해 특정 문자 체계 안에서도 다양한 문자 시퀀스의 매칭, 사용, 해석에 대한 기대가 달라지기 때문일 수 있습니다. 마찬가지로 악센트, 대체 문자 체계, 또는 문자 인코딩(예: 그래핌 클러스터 형성 방식의 변이)의 처리는 해당 텍스트의 특정 언어와 연결되어 있습니다.
여기서 우리가 의미하는 것은 언어이지 문자 체계가 아니라는 점을 강조하는 것이 중요합니다. 같은 문자 체계를 공유하는 여러 다른 언어도 서로 다른 처리를 적용하거나 서로 다른 기대를 내포합니다.
"찾기" 기능의 구현은 종종 사용자의 입력만을 바탕으로, 또는 운영 환경 로캘, 사용자 에이전트의 현지화, 활성 키보드의 언어와 같은 런타임 환경의 여러 "힌트"를 바탕으로 사용자가 의도한 언어를 추측해야 합니다. 이러한 힌트는 기껏해야 사용자의 의도에 대한 대용물이며, 특히 사용자가 이러한 힌트와 일치하지 않는 문서를 검색하거나 검색 대상 문서에 둘 이상의 언어가 포함되어 있을 때 그렇습니다.
사용자는 소문자로 입력한 용어가 대문자 등가형과 매칭되기를(그리고 아마 그 반대도) 기대할 수 있습니다. 브라우저의 "찾기" 명령과 같은 부분 문자열 매칭 기능은 입력의 대소문자를 텍스트의 대소문자와 맞출지 여부를 사용자가 선택할 수 있는 옵션으로 제공하는 경우가 많습니다.
대소문자 폴딩에 대한 개요는 [CHARMOD-NORM]의 여기 논의를 참조하십시오.
Unicode는 문자열 검색에 대한 사용자의 인식에 영향을 줄 수 있는 문자 간의 정준 관계와 호환 관계를 정의합니다. Unicode 정규화 형식에 대한 자세한 논의는 [CHARMOD-NORM]의 Section 2.2 및 Unicode Normalization Forms [UAX15]에 있는 정의를 참조하십시오.
많은 복잡한 문자 체계에서는 글자나 모음 기호를 둘 이상의 방식으로 인코딩할 수 있지만, 그 대안들은 정준적으로 동등합니다.
일부 언어는 둘 이상의 문자 체계로 표기됩니다. 문서를 검색하는 사용자는 한 문자 체계로 텍스트를 입력하더라도, 두 문자 체계 모두에서 동등한 텍스트를 찾고자 할 수 있습니다.
일부 호환 문자는 레거시 문자 인코딩에서의 단일 바이트 또는 다중 바이트 표현을 고려하거나 동아시아 언어의 특정 레이아웃 동작과의 호환성을 위해 Unicode에 인코딩되었습니다.
많은 문자 체계는 0부터 9까지의 숫자를 위한 고유한 숫자 문자를 가지고 있습니다. 일부 웹 애플리케이션에서는 익숙한 ASCII 숫자가 표시 목적으로 현지 숫자 모양으로 대체됩니다. 다른 경우에는 텍스트가 실제로 현지 숫자를 위한 Unicode 문자를 포함할 수 있습니다. 문서를 검색하려는 사용자는 한 형태의 숫자를 입력하면 동등한 숫자를 찾을 것이라고 기대할 수 있습니다.
일부 언어에는 지역이나 방언에 따라 달라지거나 같은 단어의 다른 철자를 허용하는 서로 다른 철자법 전통이 있습니다. 검색과 맞춤법 검사는 이러한 변이를 알아야 할 수 있습니다.
인도 문자 언어에는 이러한 종류의 문제가 많이 있습니다. 때로는 철자 오류이지만, 다른 경우에는 여러 철자가 허용됩니다.
예를 들어 벵골어(언어 태그 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]에서 발견되는 다양한 형태의 공백은 매칭이 성공하도록 정규화되어야 합니다.
사용자는 다양한 발음 구별 부호를 사용하는 문자 체계(예: 라틴 문자)에서 검색어를 입력할 때, 검색 대상 텍스트에는 추가 부호가 포함되어 있더라도 악센트나 발음 구별 부호가 있는 문자를 다루는 과정에서 입력을 달리할 때가 있습니다. 이는 특히 이러한 문자를 입력하는 데 추가 노력이 필요한 모바일 키보드에서 그렇습니다. 이러한 경우 사용자는 일반적으로 필요한 추가 노력을 하지 않은 것을 보완하기 위해 검색 작업이 더 "관대"하기를 기대합니다.
이 효과는 문맥에 따라서도 달라질 수 있습니다. 예를 들어 물리적 키보드를 사용하는 사람은 악센트가 있는 문자에 직접 접근할 수 있지만, 가상 키보드나 화면 키보드는 같은 문자에 접근하고 선택하는 데 추가 노력이 필요할 수 있습니다.
일부 철자법에서는 서로 다른 수의 문자를 가진 문자열을 매칭할 필요가 있습니다.
대표적인 예는 아브자드의 모음 발음 구별 부호와 관련됩니다. 예를 들어 아랍 문자와 히브리 문자를 사용하는 일부 언어는 사용자가 단모음을 입력할 것을 요구하지 않지만(선택적으로 허용합니다). (이 문자 체계의 일부 다른 언어에서는 단모음의 포함이 선택 사항이 아닙니다.) 입력되거나 검색되는 텍스트에 모음이 있거나 없다는 점은 사용자가 이를 입력하지 않거나 입력해야 한다는 것을 모를 경우 매칭을 방해할 수 있습니다.
어떤 경우에는 시각적으로 유사하거나 동일한 글리프 패턴이 서로 다른 코드 포인트 시퀀스로 만들어질 수 있습니다. 때로는 이것이 의도적인 것이며, 변이는 Unicode 정규화를 통해 제거될 수 있습니다. 그러나 유사하게 보이는 그래핌이 정규화로 같아지지 않고 의미상 동등하지 않은 다른 경우도 있습니다.
아랍 문자를 사용하는 일부 언어에도 둘 이상의 방식으로 인코딩될 수 있는 그래핌이 있습니다. 어떤 경우에는 이러한 변이가 Unicode 정규화로 처리되지만, 다른 경우에는 시각적으로 동일해 보이더라도 Unicode에서 동등한 것으로 간주되지 않습니다. 때로는 이러한 변이가 유효한 철자 변이로 간주됩니다. 다른 경우에는 사용자의 잘못된 인식에서 비롯됩니다.
영어나 아랍어와 같은 일부 언어는 단어 사이에 공백을 사용합니다. 중국어, 일본어, 태국어와 같은 다른 언어는 그렇지 않습니다. 일부 언어는 구와 같은 다른 텍스트 단위를 구분하기 위해 공백을 사용합니다. 단어 사이에 공백을 사용하지 않는 언어에서 "전체 단어" 매칭을 계산하는 것은, 경계 자체가 텍스트에 인코딩되어 있지 않을 때 단어 경계를 결정할 수 있는 능력에 의존하는 경우가 많습니다.
이 절은 문서 전체를 재설계하는 과정의 일부로 문서화가 필요한 새로운 영역으로 식별되었습니다. 여기에 있는 텍스트는 불완전하며 추가 개발이 필요합니다. 커뮤니티의 기여를 환영합니다.
구현자는 단순한 "텍스트 찾기" 알고리즘을 제공해야 하는 경우가 많으며, 명세는 이러한 요구를 지원하기 위한 API를 정의하려고 하는 경우가 많습니다. 텍스트에 대한 찾기 작업은 서로 다른 사용자 기대를 생성하므로, 문서 형식과 프로토콜에서 필요한 절대적 동일성 매칭의 요구와는 다른 요구사항을 가집니다. 도메인별 요구사항이 추가 제한을 부과하거나 여기에 제시된 고려사항을 바꿀 수 있다는 점에 유의하는 것이 중요합니다.
사용자의 입력 노력이 증가할수록 더 선택적인 매칭으로 반영되어야 합니다.
사용자가 입력에 더 많은 노력을 들일 때—예를 들어 Shift 키를 사용해 대문자를 만들거나 기본 문자 대신 발음 구별 부호가 있는 문자를 입력할 때—사용자는 검색 결과가 자신의 더 구체적인 입력과 (만) 매칭되기를 기대할 수 있습니다.
문자열 검색 API 또는 알고리즘을 만들 때, 다음 텍스트 옵션이 사용자에게 유용할 수 있습니다.
W3C 국제화 워킹 그룹과 관심 그룹, 그리고 그 외 많은 사람들이 여러 의견과 제안을 제공했습니다. 워킹 그룹은 다음에 감사드립니다: 수년에 걸쳐 Character Model 문서 시리즈의 개발에 기여한 모든 기여자.
이 예제의 예들은 Henri Sivonen이 작성한 페이지에서 가져온 것이며, 그가 이 이슈에 기록한 여러 개념과 아이디어도 마찬가지입니다.