월드 와이드 웹을 위한 문자 모델: 문자열 매칭

1.1 목표와 범위

월드 와이드 웹을 위한 문자 모델의 목표는 W3C의 보편적 접근 목표에 따라 언어, 문자, 문자 체계 또는 문화적 관습과 관계없이 모든 사람이 웹을 쉽게 사용할 수 있도록 하는 것이다. 이 목표를 달성하기 위한 기본 전제 조건 중 하나는 전 세계에서 사용되는 문자를 잘 정의되고 잘 이해된 방식으로 전송하고 처리할 수 있어야 한다는 것이다.

월드 와이드 웹을 위한 문자 모델의 이 부분은 문자열 매칭, 즉 명세나 구현이 두 문자열 값이 서로 같은지 다른지를 정의하는 과정을 다룬다. 이 문서는 의미적으로 동등한 텍스트가 서로 다르게 인코딩될 수 있는 방식과, 이것이 형식 언어 (예: 웹을 구성하는 형식과 프로토콜에서 사용되는 언어)에 중요한 매칭 작업에 미치는 영향을 설명한다.

이 명세의 주요 대상 독자는 W3C 명세 개발자이다. 이 명세와 그 일부는 다른 W3C 명세에서 참조할 수 있으며, 이 명세는 W3C 명세뿐 아니라 다른 명세에 대한 적합성 기준을 정의한다.

이 명세의 다른 대상 독자에는 소프트웨어 개발자, 콘텐츠 개발자 및 W3C 외부의 명세 작성자가 포함된다. 소프트웨어 개발자와 콘텐츠 개발자는 W3C 명세를 구현하고 사용한다. 이 명세는 W3C 명세를 구현하고 사용하는 구현(소프트웨어)과 콘텐츠에 대한 일부 적합성 기준을 정의한다. 또한 소프트웨어 개발자와 콘텐츠 개발자가 W3C 명세의 문자 관련 조항을 이해하는 데 도움을 준다.

이 명세에서 설명하는 문자 모델은 명세 작성자, 소프트웨어 개발자 및 콘텐츠 개발자에게 월드 와이드 웹에서 일관되고 상호운용 가능한 텍스트 조작을 위한 공통 참조를 제공한다. 이 세 그룹이 함께 협력하면 전 세계적으로 접근 가능한 웹을 구축할 수 있다.

1.2 이 문서의 구조

이 문서는 문서 형식에서 문자열 동일성 매칭을 위한 규칙과 절차를 정의함으로써, 이 문제와 관련된 웹의 기본 구성 요소 중 하나를 정의한다. 이러한 규칙은 문서 형식에서 사용되는 식별자와 구조적 마크업(구문 콘텐츠)을 대상으로 하며, 각각의 일관된 처리를 보장하도록 설계되었고 명세 작성자를 대상으로 한다. 이 절은 구현자를 대상으로 한다.

이 문서는 두 개의 주요 절로 나뉜다.

첫 번째 절은 문자열 매칭과 관련된 문제, 유니코드와 대소문자 접기가 이러한 문제에 미치는 영향, 그리고 이러한 문제를 해결하는 데 사용할 수 있는 다양한 쟁점과 정규화 메커니즘을 제시한다.

두 번째 절은 W3C 명세에서 정의되는 많은 문서 형식과 같은 형식 언어에서 사용할 문자열 동일성 매칭에 대한 요구사항과 권장사항을 제공한다. 이는 주로 웹을 기능적으로 만들고 문서 작성자에게 일관된 결과를 제공하는 데 관련된다.

1.3 배경

이 절은 이 명세에서 다루는 주제에 대한 역사적 배경을 제공한다.

문자 모델의 핵심에는 유니코드 표준 [Unicode]과 ISO/IEC 10646 [ISO10646]이 공동으로 정의한 범용 문자 집합(UCS)이 있다. 이 문서에서 Unicode는 범용 문자 집합의 동의어로 사용된다. 성공적인 문자 모델은 전 세계의 문자 체계, 문자 및 언어로 작성된 웹 문서가 (그리고 서로 다른 플랫폼에서) 전 세계 웹 사용자에 의해 교환되고, 읽히고, 검색될 수 있게 한다.

유니코드 표준 [Unicode]의 첫 몇 장은 유용한 배경 읽을거리를 제공한다.

이 명세의 중요한 부분 개발에 영향을 준 요구사항에 대한 정보는 문자열 동일성 매칭 및 문자열 인덱싱 요구사항 [CHARREQ]을 참조하라.

1.4 용어 및 표기법

이 절에는 이 문서에 특화된 용어와 표기법이 포함되어 있다.

웹은 텍스트 기반 형식과 프로토콜 위에 구축되어 있다. 문자열 매칭이나 검색을 효과적으로 설명하려면, 요구사항과 세부사항이 크게 달라지므로 주어진 형식이나 프로토콜 내의 다양한 종류의 텍스트에 대해 말할 수 있게 해 주는 용어를 확립할 필요가 있다.

유니코드 코드 포인트(또는 "코드 포인트")는 각 유니코드 문자에 할당된 숫자 값을 가리킨다. 유니코드 코드 포인트의 범위는 0부터 0x10FFFF까지이다. (문자 인코딩 용어에 대한 더 자세한 논의는 [CHARMOD]의 4.1절을 참조하라.)

유니코드 코드 포인트는 U+hhhh로 표기되며, 여기서 hhhh는 최소 네 자리, 최대 여섯 자리의 16진수 숫자 시퀀스이다. 예를 들어 문자 € [U+20AC EURO SIGN]의 코드 포인트는 U+20AC이고, 문자 😺 [U+1F63A SMILING CAT FACE WITH OPEN MOUTH]의 코드 포인트는 U+1F63A이다.

이 문서의 예에서 사용되는 일부 문자는 특정 장치나 표시 장치에서 의도한 대로 나타나지 않을 수 있다. 일반적으로 이는 로컬에 설치된 문자별 글꼴이 없거나 특정 렌더링 시스템의 다른 제한 때문이다. 이 문서는 여러 비라틴 문자에 대한 대체 글리프를 제공하기 위해 Webfont를 사용하지만, 장치가 해당 글꼴 표시를 지원하지 않을 수도 있다. 가능한 범위에서 편집자는 예가 그럼에도 이해 가능하게 유지되도록 노력했다.

레거시 문자 인코딩은 유니코드 문자 집합의 전체 문자 레퍼토리를 인코딩하지 않는 문자 인코딩 형식이다.

트랜스코더는 두 문자 인코딩 사이에서 텍스트를 변환하는 과정이다. 이 문서에서는 가장 일반적으로 레거시 문자 인코딩에서 UTF-8과 같은 유니코드 인코딩 형식으로 변환하는 과정을 가리킨다.

자연어는 인간이 사용하는 말, 글 또는 수어 의사소통을 말한다(여기도 참조 [LTLI])

구문 콘텐츠는 문서 형식이나 프로토콜의 구조에 속하는 모든 텍스트이다. 이 정의에는 일반적으로 "마크업"으로 여겨지는 값도 포함되지만, HTTP 헤더의 필드 이름과 같은 다른 값도 포함될 수 있다. 구문 콘텐츠는 형식이나 프로토콜의 구조를 형성하는 모든 문자로 구성된다. 예를 들어, <와 >(그리고 이들이 둘러싸는 요소 이름과 다양한 속성)는 HTML 문서의 구문 콘텐츠 일부이다.

구문 콘텐츠는 일반적으로 명세 또는 여러 명세에 의해 정의되며, 주어진 프로토콜이나 형식에 대해 정의되고 예약된 키워드뿐 아니라 문서 작성자가 문서의 ("콘텐츠"가 아니라) 구조를 형성하기 위해 정의하는 문자열 토큰과 식별자를 모두 포함한다.

어휘는 형식이나 프로토콜에서 예약 키워드 및/또는 사용자 제공 값(예: 식별자)을 할당하기 위한 규칙의 목록이다. 여기에는 서로 다른 위치에 나타날 수 있는 문자의 범위, 순서 또는 유형에 대한 제한이 포함될 수 있다.

예를 들어, HTML은 요소와 속성의 이름뿐 아니라 열거형 속성 값도 정의하며, 이는 HTML 구문 콘텐츠의 "어휘"를 정의한다. 또 다른 예는 ECMAScript로, 식별자나 변수 이름의 시작 또는 본문에 나타날 수 있는 문자의 범위를 제한한다. 문자열 리터럴의 값과 같은 다른 경우에는 서로 다른 규칙을 적용한다.

어휘 내의 값은 크게 두 부류로 나뉜다. 하나는 사람이 보고, 읽고, 상호작용하도록 의도된 값(따라서 자연어 텍스트를 포함할 것으로 기대될 수 있음)이고, 다른 하나는 애플리케이션 또는 프로토콜 내부용이며 사람과의 상호작용을 의도하지 않은 값이다.

사용자 대면 식별자는 어휘에서 사용자가 정의하거나 할당한 식별자로, 최종 사용자에게 적어도 잠재적으로 보이도록 의도된 것이다(따라서 지역화 가능 콘텐츠이다).

애플리케이션 내부 식별자는 어휘에서 사용자가 정의하거나 할당한 식별자로, 문서 형식이나 프로토콜 내부용이며 사람과의 상호작용을 의도하지 않은 것이다. 이러한 값은 일반적으로 지역화 가능 콘텐츠가 아니다.

사용자 제공 값은 구문 콘텐츠 중 어휘에서 예약되지 않은 것으로, 주어진 형식이나 프로토콜의 예약 키워드와 구별되며 사용자가 할당한다. 사용자는 일반적으로 자신의 사용자 제공 값이 자신이 선호하는 자연어의 단어나 구문일 수 있기를 기대한다. 이것이 바로 [CHARMOD]가 "명세는 U+0000부터 U+10FFFF까지의 유니코드 코드 포인트 전체 범위에서 임의로 코드 포인트를 제외해서는 안 된다(SHOULD NOT)"라고 권장하는 이유이다.

지역화 가능 콘텐츠는 사람이 읽을 수 있는 텍스트로 의도된 문서 콘텐츠를 가리키며, 문서 구조의 일부를 이루는 주변 또는 삽입된 구문 콘텐츠는 아니다. 구문 콘텐츠에는 지역화 가능 콘텐츠가 포함될 수 있다는 점에 유의하라. 예를 들어 [HTML] img 요소가 이미지 설명을 담은 alt 속성을 갖는 경우가 그렇다.

리소스는 이 문서의 맥락에서 지역화 가능 콘텐츠와, 이를 둘러싸거나 포함하는 식별자 같은 구문 콘텐츠를 모두 포함하는 주어진 문서, 파일 또는 프로토콜 "메시지"이다. 예를 들어 일부 CSS와 몇 개의 script 태그 안에 포함된 JavaScript도 포함하는 HTML 문서에서, 파일로서 고려한 전체 HTML 문서가 리소스이다. 이 용어는 [RFC3986]에서 사용되는 'resource'라는 용어와 의도적으로 유사하지만, 여기서는 느슨하게 적용된다.

자소는 어떤 텍스트의 시각적 표현에서 일반적인 사용자가 하나의 단위(문자)로 인식할 하나 이상의 문자 시퀀스이다. 자소는 정렬이나 텍스트 선택과 같은 여러 텍스트 작업에서 중요하므로, 사용자가 인식하는 각 문자 사이의 경계를 계산할 수 있어야 한다. 유니코드는 Unicode Standard Annex #29: Text Segmentation [UAX29]에서 자소를 계산하기 위한 기본 메커니즘을 정의하고, 이 근사치를 자소 클러스터라고 부른다. 정의된 기본 자소 클러스터에는 두 가지 유형이 있다. 달리 명시하지 않는 한, 이 문서에서 자소 클러스터는 확장 기본 자소 클러스터를 가리킨다. (자소 클러스터에 대한 논의는 유니코드 표준 [Unicode]의 2절에도 제시되어 있다. 또한 The Unicode Standard 버전 8.0의 2.11절 끝부분 근처를 비교하라.)

서로 다른 자연어는 서로 다른 요구를 가지므로, 자소 클러스터에도 때때로 맞춤 조정이 필요할 수 있다. 예를 들어 슬로바키아어 사용자는 기본적으로 두 개의 자소 클러스터인 "ch"를 하나의 자소 클러스터로 다루고자 할 수 있다. 문자열 콘텐츠의 언어와 최종 사용자의 선호 사이의 상호작용은 복잡할 수 있음에 유의하라.

1.5 적합성

비규범으로 표시된 절뿐 아니라, 이 명세의 모든 작성 지침, 도표, 예 및 참고는 비규범이다. 이 명세의 그 밖의 모든 내용은 규범적이다.

이 문서의 핵심어 MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, SHOULD, 및 SHOULD NOT은 여기에 표시된 것처럼 모두 대문자로 나타날 때에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 한다.

이 문서는 다른 명세의 작성자를 위한 모범 사례뿐 아니라 구현 및 콘텐츠 작성자를 위한 권장사항도 설명한다. 이러한 모범 사례는 Internationalization Working Group의 문서 Internationalization Best Practices for Spec Developers [INTERNATIONAL-SPECS]에서도 찾을 수 있으며, 이 문서는 W3C 명세의 모든 국제화 모범 사례에 대한 일반 참조로 제공되도록 의도되었다.

이 문서의 모범 사례는 특정 권장사항에 관한 Internationalization Working Group의 의도를 명확히 하기 위해 [RFC2119] 키워드를 사용한다. 이 문서의 권장사항을 따르면 W3C의 "광범위 검토" 과정, 구현 중, 또는 작성자가 생산하는 콘텐츠에서 문제가 발생하는 것을 피하는 데 도움이 될 수 있다. 이 문서 자체는 규범적이지 않으며 때때로 개정될 수 있다.

명세는 다음을 만족하는 경우 이 문서에 대한 적합성을 주장할 수 있다.

1. 명령형이 MUST 또는 MUST NOT인 경우 [S]가 앞에 붙은 어떠한 적합성 기준도 위반하지 않는다.
2. 명령형이 SHOULD, SHOULD NOT, 또는 RECOMMENDED인 기준에서 벗어나는 경우 그 이유를 문서화한다.
3. 구현이 이 문서를 준수하도록 적합성 요구사항으로 만든다.
4. 콘텐츠가 이 문서를 준수하도록 적합성 요구사항으로 만든다.

이 명세에 절차적 설명이 포함되어 있는 경우, 이는 원하는 외부 동작을 지정하는 한 방법으로 이해해야 한다. 구현은 관찰 가능한 동작에 영향을 주지 않는 한 동일한 결과를 달성하기 위해 다른 수단을 MAY 사용할 수 있다.

2.1 대소문자 매핑과 대소문자 접기

일부 문자와 문자 체계는 대문자, 소문자, 제목형 대소문자를 구분한다. 인도의 브라흐미계 문자, 아랍 문자, 중국어, 일본어 또는 한국어를 표기하는 데 사용되는 문자 등 대부분의 문자는 대소문자 구분을 갖지 않지만, 일부 중요한 문자 체계는 이를 갖는다. 이러한 문자 체계의 예로는 이 문서 대부분에서 사용되는 라틴 문자뿐 아니라 그리스 문자, 아르메니아 문자, 키릴 문자 등이 있다.

대소문자 매핑은 문자를 대문자, 소문자 또는 제목형 대소문자와 같은 특정 대소문자 형태로 변환하는 과정이다. 대소문자 구분이 있는 문자 체계에 대해, 유니코드는 각 유니코드 코드 포인트마다 기본 대문자, 소문자 및 제목형 대소문자 문자 매핑을 정의한다. 대소문자 매핑은 처음에는 단순해 보인다. 그러나 다양한 언어에서 유니코드 전체 범위를 다룰 때 고려해야 할 변이가 있다.

대소문자 접기는 대소문자만 다른 두 텍스트를 비교 목적으로 동일하게 만드는 과정, 즉 문자열 매칭을 위한 과정이다. 이는 주로 표시 목적을 위한 대소문자 매핑과는 구별된다. 기본 대소문자 매핑과 마찬가지로, 유니코드는 각 유니코드 코드 포인트마다 기본 대소문자 접기 매핑("case folding")을 정의한다. 유니코드는 두 가지 형태의 대소문자 접기를 정의하며, 아래에서 이를 살펴본다.

대부분의 문자 체계는 대소문자 구분이 없으므로, 대소문자 매핑과 마찬가지로 대부분의 유니코드 코드 포인트는 대소문자 접기를 필요로 하지 않는다. 대소문자 접기가 있는 코드 포인트의 경우, 대부분은 다른 하나의 일치하는(일반적으로 소문자) 코드 포인트로 단순하고 직접적으로 매핑된다. 유니코드는 이 접기 집합을 common이라고 부르는데, 유니코드가 정의한 두 유형의 대소문자 접기가 모두 이를 포함하기 때문이다.

몇몇 문자는 하나의 유니코드 코드 포인트를 두 개 이상의 코드 포인트로 매핑하는 대소문자 접기를 가진다. 이러한 대소문자 접기 집합을 full 대소문자 접기라고 한다. full 및 common 대소문자 접기는 함께 사용되어 유니코드 전체에 대한 기본 대소문자 접기를 제공한다. 이 문서에서는 이러한 형태의 대소문자 접기를 전체 대소문자 접기 또는 Unicode full이라고 부른다.

일부 애플리케이션은 대소문자 접기 작업을 수행할 때 추가 저장 공간을 할당할 수 없기 때문에, 유니코드는 일반적으로 더 많거나 더 적은 코드 포인트로 접힐 코드 포인트를 비교 목적으로 대신 하나의 코드 포인트로 매핑하는 simple 대소문자 접기를 제공한다. 전체 접기와 달리, 이 접기는 항상 텍스트의 내용(그리고 잠재적으로 의미)을 변경한다. 전체 대소문자 접기와 마찬가지로, 단순 대소문자 접기 또는 Unicode simple 대소문자 접기는 유니코드 전체 범위를 포괄하기 위해 simple 매핑과 common 매핑을 결합한 것이다. Unicode simple은 웹에서 사용하기에 적절하지 않다.

대소문자 접기는 문자열에서 정보를 제거하며, 이 정보는 나중에 복구할 수 없다는 점에 유의하라. 예를 들어 독일어에서 두 개의 s 글자가 접기 전 텍스트의 ß를 반드시 나타내는 것은 아니다.

2.2 유니코드 정규화

유니코드 텍스트에서는 다른 종류의 변이가 발생할 수 있다. 때로는 서로 다른 여러 유니코드 코드 포인트 시퀀스를 사용하여 같은 추상 문자를 나타낼 수 있다. 코드 포인트를 비교하여 텍스트를 검색하거나 매칭할 때, 이러한 인코딩상의 변이는 사용자가 같을 것으로 기대하는 텍스트 값이 매칭되지 않게 만든다.

애플리케이션은 서로 다른 코드 포인트 시퀀스를 사용하는 텍스트들 사이에서 의미적 동등성을 찾아야 하므로, 유니코드는 의미적으로 동등한 두 텍스트를 동일하게 만드는 수단인 유니코드 정규화 형식 [UAX15]을 정의한다.

리소스는 이러한 변이의 영향을 받기 쉽다. 웹에서 그 명세와 구현은 텍스트의 유니코드 정규화를 요구하지 않는 경우가 많고, 나중에 구문 콘텐츠(사용자 제공 값 포함)와 지역화 가능 콘텐츠를 처리할 때 사용되는 문자열 매칭 알고리즘을 고려하지도 않기 때문이다. 이러한 이유로 콘텐츠 개발자는 이후 문제를 피하기 위해 일관된 표현을 제공했는지 확인해야 한다.

그러나 사용자는 주어진 리소스 또는 리소스 집합이 일관된 텍스트 표현을 사용하는지 확인하기 어려울 수 있다. 그 차이는 보통 텍스트로 볼 때 보이지 않기 때문이다. 따라서 도구와 구현은 시각적으로 또는 논리적으로 동등한 문자열이 (사용자의 생각에는) "당연히" 매칭되어야 하는데도 서로 다른 값으로 간주될 때 사용자가 겪는 어려움을 고려해야 한다. 사용자가 이러한 차이를 보고 및/또는 적절히 정규화할 수 있는 수단을 제공하면, 최종 사용자가 원본 문서의 보이지 않는 차이에서 비롯되는 실패를 피할 수 있다. 예를 들어, W3C Validator는 HTML 문서가 유니코드 정규화 형식 C에 완전히 속하지 않을 때 경고한다.

2.3 동일하게 보이는 문자와 정규화의 한계

많은 사용자는 특정 유니코드 정규화 형식이 적용된 문자열을 포함하여 동일하게 보이는 두 문자열이 실제로는 같은 기본 유니코드 코드 포인트를 사용하지 않을 수 있다는 사실에 놀란다. 여기에는 더 파괴적인 NFKC 및 NFKD 호환 정규화 형식이 적용된 문자열도 포함된다. 문자열, 토큰 또는 식별자가 시각적으로 같아 보이더라도 서로 다르게 인코딩될 수 있다.

유니코드 정준 정규화 형식은 주어진 추상 문자나 자소 클러스터에 사용할 수 있는 여러 서로 다른 코드 포인트 시퀀스를 같은 코드 포인트 시퀀스로 접는 데 관련된다. 그러나 논리적으로 구별되는 문자나 자소 클러스터도 여전히 같거나 매우 비슷하게 보일 수 있다. 한 쌍의 자소가 동일하게(또는 매우 비슷하게) 보일 때, 이를 동형문자라고 한다. 한 쌍의 자소가 비슷하게 보이거나 동형문자이지만 실제로는 논리적으로 다른 문자 또는 문자 시퀀스를 나타낼 때, 이들은 혼동 가능하다고 한다.

동일하거나 동일해 보이는 모양의 예는 단일 문자 체계 안에서도 나타날 수 있다. 이는 "0"과 "O" 또는 "l"과 "1"처럼 모양이 비슷한 문자의 형태를 취할 수 있다. 그러나 다른 문자 체계나 서로 다른 호환 문자의 사용은 훨씬 덜 쉽게 구별되는 변이를 나타낼 수 있다. 어떤 경우에는 유니코드 정규화가 이들을 하나로 모으지만, 다른 많은 경우에는 그렇지 않다.

모양이 동일하거나 혼동 가능한 문자는 스푸핑 및 기타 보안 위험을 초래할 수 있다. 이는 단일 문자 체계 안에서도, 별개의 문자 체계에 있는 유사한 문자에서도 참일 수 있다. 동형 글리프와 혼동 가능성에 대한 추가 논의와 예는 [UTS39]가 유용한 참고문헌 중 하나이다.

동일하거나 비슷하게 보이는 문자 외에도 반대 문제도 존재한다. 유니코드 정규화는 NFKC 및 NFKD 호환 형식조차도 같은 본질적 의미나 기능을 갖지만 모양이나 사용 방식이 다른 문자를 하나로 모으지 않는다. 예를 들어 U+002E(.)와 U+3002(。)는 모두 문장 끝 문장부호로 기능하지만, 두 문자는 구별되는 정체성을 가지므로 그 차이는 정규화로 제거되지 않는다.

2.4 정규화와 대소문자 접기의 상호작용

대소문자를 구분하지 않는 방식으로 문자열을 매칭할 때 한 가지 복잡한 점은, 원래 문자열이 정규화되어 있었더라도 대소문자 접기 과정이 정규화되지 않은 문자열을 생성할 수 있다는 점이다. 문자열 비교는 코드 포인트 시퀀스의 매칭에 의존하므로, 매칭 과정이 신뢰할 수 있으려면 대소문자 접기가 적용된 각 문자열을 정규화해야 한다.

유니코드 정준 정규화 형식(NFC 또는 NFD)과 대소문자 접기는 함께 사용될 때 닫혀 있다. 즉, 한 문자열에 대소문자 접기를 적용한 뒤 NFD 또는 NFC를 적용하면, 같은 대소문자 접기나 유니코드 정규화 형식을 추가로 적용해도 다른 문자열이 나오지 않는다.

문자 사이의 호환 동등성 (다시 말해 NFKC/NFKD 형식)을 비교할 때는, 대소문자 접기 후 정규화 작업을 두 번 수행해야 한다. 호환 분해 단계가 대소문자 접기가 필요한 문자를 생성할 수 있고, 이어지는 대소문자 접기가 다시 정규화해야 하는 시퀀스를 생성할 수 있기 때문이다.

2.5 문자 이스케이프와 포함

대부분의 문서 형식이나 프로토콜은 입력, 처리 또는 인코딩하기 어려운 문자를 포함할 수 있도록 이스케이프 메커니즘을 제공한다. 이러한 이스케이프 메커니즘은 주어진 리소스 안에서 문자를 표현하는 추가적인 동등 수단을 제공한다. 또한 문서에서 사용되는 문자 인코딩 체계로 표현되지 않는 유니코드 문자를 인코딩할 수 있게 한다.

예를 들어, € U+20AC EURO SIGN은 HTML에서 16진수 엔터티 € 또는 10진수 엔터티 €로도 인코딩될 수 있다. JavaScript나 JSON 파일에서는 \u20ac 또는 \u{20AC}로 나타날 수 있고, CSS 스타일시트에서는 \20ac로 나타날 수 있다. 이러한 모든 표현은 동일한 리터럴 문자 값인 €를 인코딩한다.

문자 이스케이프는 일반적으로 문서가 처리되고 형식이나 프로토콜 안의 문자열이 매칭되기 전에 해석된다. 위에서 사용한 예로 돌아가면 다음과 같다.

이 텍스트는 다음과 같이 표시될 것으로 기대할 수 있다. Hello world!

이것이 작동하려면 사용자 에이전트(브라우저)가 클래스 이름 héllo를 나타내는 두 문자열을 매칭해야 했다. CSS와 HTML이 각각 서로 다른 이스케이프 메커니즘을 사용했음에도 그렇다. 위 단편은 텍스트가 달라질 수 있으면서도 명세에 따라 여전히 "같은 것"으로 간주될 수 있는 한 가지 방식을 보여준다. 클래스 이름 h\e9llo는 HTML 마크업의 클래스 이름 héllo와 매칭되었다(또한 코드 포인트 é [U+00E9 LATIN SMALL LETTER E WITH ACUTE]를 사용하는 리터럴 값 héllo와도 매칭될 것이다).

형식 언어와 문서 형식은 한 리소스의 텍스트 일부를 다른 리소스 안에 포함하기 위한 기능을 제공하는 경우가 많다. 포함은 리소스의 본문에 콘텐츠를 삽입하는 메커니즘이다. 포함 메커니즘은 처리 시점에 콘텐츠를 리소스로 가져온다. 이는 문서의 구조와 잠재적으로 문서의 어휘에 대한 매칭에 영향을 준다. 포함의 예로는 XML의 엔터티 참조, XInclude [XInclude] 명세, 그리고 CSS의 @import 규칙이 있다.

포함은 결합 마크로 시작하지 않는 경우(문자 이스케이프 형태이든 포함된 리소스의 문자 리터럴이든) 포함 정규화됨이라고 한다.

2.6 보이지 않는 유니코드 문자

유니코드는 문서 작성자가 텍스트의 모양이나 동작을 제어하는 데 도움이 되는 여러 특수 목적 문자를 제공한다. 이러한 문자 중 다수는 보이지 않거나 키보드에 대응 항목이 없기 때문에 사용자는 그 존재나 부재를 항상 인식하지 못한다. 그 결과, 이러한 문자가 인코딩된 문자 시퀀스의 일부이지만 예상되는 매칭 텍스트에는 포함되어 있지 않은 경우 문자열 매칭을 방해할 수 있다. 이러한 문자의 몇 가지 예는 다음과 같다.

유니코드 제어 문자 U+200D Zero Width Joiner (ZWJ라고도 함)와 U+200C Zero Width Non-Joiner (ZWNJ라고도 함). 이러한 문자는 원치 않는 합자의 형성을 방지하거나 원하는 합자의 형성을 유도하는 등 합자 형성을 제어하는 데 사용할 수 있지만, 주된 용도는 아랍 문자나 여러 인도계 문자와 같은 복합 문자에서 결합 및 형태 선택을 제어하는 것이다. 일부 인도계 문자는 작성자가 특정 결합자가 취하는 형태를 제어할 수 있도록 ZWJ 및 ZWNJ 문자를 사용한다. [Unicode] 12장의 논의를 참조하라.

Zero Width Non-Joiner는 페르시아어에서 특정 "일반" 아랍 문자 결합을 방지하는 데 사용된다. 이러한 경우에는 해당 문자의 존재 여부가 의미에 영향을 준다. 예를 들어 단어 تنها("alone")와 단어 تن‌ها ("bodies" 또는 "corpuses")는 각각 "U+062A U+0646 U+0647 U+0627"와 "U+062A U+0646 U+200C U+0647 U+0627"로 인코딩되며, 유일한 차이는 뒤 단어의 ZWNJ이다.

ZWJ 문자는 특정 이모지 시퀀스를 형성하는 데도 사용되며, 이에 대해서는 아래에서 더 자세히 논의한다.

변형 선택자(U+FE00부터 U+FE0F까지)는 대체 모양이나 글리프를 선택하는 데 사용되는 문자이다 (Character Model: Fundamentals [CHARMOD] 참조). 예를 들어 흑백 이모지와 컬러 이모지 중 하나를 선택하는 데 사용된다. 이들은 미리 정의된 표의문자 변형 시퀀스(IVS)에도 사용된다. Unicode Character Database(UCD)의 "Standardized Variants" 부분에는 많은 예가 제시되어 있다.

몇몇 문자 체계도 시각적 변형 선택을 인코딩하는 방법을 제공한다. 대표적인 예는 몽골 문자의 자유 변형 선택자(U+180B부터 U+180D까지)이다.

이름이 오해를 부르는 U+034F Combining Grapheme Joiner (실제로 자소를 결합하지 않음)는 정렬 목적상 그렇지 않으면 하나의 자소로 간주될 수 있는 문자를 분리하거나, 텍스트에 유니코드 정규화를 적용할 때 특정 텍스트상의 구별을 유지하는 수단을 제공하는 데 사용된다.

공백 변이도 텍스트의 해석과 매칭에 영향을 줄 수 있다. 예를 들어 NBSP, NNBSP 등과 같은 다양한 줄바꿈 없는 공백 문자가 있다.

U+200B Zero Width Space는 공백이 원래 나타나지 않는 텍스트에서 단어 경계를 나타내는 데 사용되는 문자이다. 예를 들어 태국어 문서에서 단어 분리를 돕기 위해 사용될 수 있다.

U+00AD Soft Hyphen은 텍스트에서 가능한 또는 선호되는 하이픈 위치를 나타내는 데 사용할 수 있다. 텍스트가 해당 위치에서 줄바꿈되도록 재배치될 때만 보이게 된다.

U+2060 WORD JOINER는 때때로 WJ라고 불리며, 폭이 없는 줄바꿈 없는 공백 문자이다. 그 목적은 두 문자 사이의 줄바꿈을 방지하는 것이다. 줄바꿈 목적을 제외하고는 무시되어야 한다. 이는 U+FEFF ZERO WIDTH NO-BREAK SPACE 문자를 대체하는 역할을 한다. U+FEFF는 "Byte Order Mark"(BOM)로 더 널리 알려져 있기 때문이다. 바이트 순서 표시는 일부 일반 텍스트 파일의 시작 부분에서 해당 파일이 유니코드 문자 인코딩으로 되어 있음을 알리는 데 사용된다.

마지막으로, 대부분의 문자 체계는 가로로 쓰일 때 왼쪽에서 오른쪽으로 진행된다. 그러나 아랍 문자와 히브리 문자 같은 일부 문자 체계는 주로 오른쪽에서 왼쪽으로 쓰인다. 텍스트는 이러한 문자 체계가 혼합되어 쓰이거나, 숫자나 다른 문자 체계의 따옴표처럼 텍스트의 다른 부분과 반대 방향으로 진행되는 문자 시퀀스를 포함할 수 있다. 이러한 텍스트 방향의 혼합을 양방향 텍스트 또는 줄여서 bidi라고 한다. Unicode Bidirectional Algorithm [UAX9]은 이러한 혼합 방향 텍스트가 표시를 위해 처리되는 방식을 설명한다. 대부분의 텍스트에서는 방향 처리를 텍스트 자체에서 도출할 수 있다. 그러나 알고리즘이 텍스트를 올바르게 표시하기 위해 추가 정보를 필요로 하는 경우도 많다. 더 많은 예는 [html-bidi]를 참조하라.

유니코드가 텍스트 방향의 모호성을 해결하기 위해 정의한 방법 중 하나는 방향 진행의 시작과 끝을 표시하는 보이지 않는 제어 문자 집합이다. 양방향 제어 문자는 텍스트의 표시 방식에 영향을 줄 수 있지만 (유니코드 양방향 알고리즘이 텍스트 표시를 처리하는 데 도움을 주기 때문에), 제어 문자가 없더라도 텍스트가 자연스럽게 양방향 진행으로 나뉘었을 경우에는 텍스트에 아무 영향이 없을 수도 있다. 이러한 제어 문자는 위에서 언급한 문자들과 마찬가지로 보이지 않기 때문에, 매칭에 의도치 않은 영향을 줄 수 있다.

이러한 거의 모든 경우에, 사용자는 주어진 문서나 텍스트 문자열이 이러한 문자 중 하나를 포함했는지 또는 생략했는지 알지 못하거나 확신하지 못할 수 있다. 텍스트 매칭은 기본 코드 포인트의 매칭에 의존하므로, 이러한 표식으로 인한 텍스트 인코딩의 변이는 성공해야 할 매칭이 (사용자의 관점에서는) 알 수 없는 이유로 실패하게 만들 수 있다.

2.7 이모지 시퀀스

유니코드의 비교적 새로운 기능은 이모지 문자이다. [UTR51]에서 유니코드는 이를 다음과 같이 설명한다.

이모지는 일반적으로 다채로운 만화 형태로 표시되고 텍스트 안에 인라인으로 사용되는 그림문자(그림 기호)이다. 얼굴, 날씨, 차량과 건물, 음식과 음료, 동식물, 또는 감정, 느낌, 활동을 나타내는 아이콘과 같은 것들을 표현한다.

이모지는 U+200D ZERO WIDTH JOINER 또는 ZWJ를 포함한 다양한 이모지 수정자와 함께 사용되어 더 복잡한 이모지를 형성할 수 있다.

예를 들어 이모지(👪 [U+1F46A FAMILY])는 이모지 문자 사이에 ZWJ를 사용하는 시퀀스 U+1F468 U+200D U+1F469 U+200D U+1F466로도 형성될 수 있다. 다른 이모지 문자를 변경하거나 추가하면 가족의 구성이 달라질 수 있다. 예를 들어 시퀀스 👨‍👩‍👧‍👧 U+1F468 U+200D U+1F469 U+200D U+1F467 U+200D U+1F467는 이러한 종류의 조합을 지원하는 시스템에서 "family: man, woman, girl, girl"에 대한 조합 이모지 문자를 생성한다. 많은 일반적인 이모지는 ZWJ 시퀀스를 사용해야만 형성될 수 있다. 자세한 내용은 [UTR51]를 참조하라.

이모지 문자 뒤에는 이모지 수정자 문자가 올 수 있다. 이러한 수정자는 사람을 나타내는 이모지의 피부색을 선택할 수 있게 한다. 이 문자들은 일반적으로 수정 대상인 기본 이모지 뒤에 오는 보이지 않는 수정자이다. 예를 들면 다음과 같다. 👨 👨🏻 👨🏼 👨🏽 👨🏾 👨🏿

이모지 문자 뒤에는 기본 이모지의 텍스트(흑백, U+FE0E Variation Selector 15로 표시) 또는 컬러 (U+FE0F Variation Selector 16로 표시) 표시를 나타내기 위해 변형 선택자가 올 수도 있다.

이모지 사용의 또 다른 복잡한 점은 깃발이다. 국가 깃발은 국가 Zambia의 국가 코드(ZM)인 🇿🇲처럼, [BCP47] 레지스트리에서 파생된 국가 코드, 예컨대 시퀀스 🇿 [U+1F1FF REGIONAL INDICATOR SYMBOL LETTER Z] 🇲 [U+1F1F2 REGIONAL INDICATOR SYMBOL LETTER M]를 사용하여 구성할 수 있다. 다른 지역 깃발이나 특수 목적 깃발은 다양한 기호와 함께 깃발 이모지를 사용하거나, 취소 태그로 끝나는 지역 표시자 코드를 사용하여 구성할 수 있다. 예를 들어 스코틀랜드의 깃발(🏴)은 다음과 같이 구성할 수 있다.

• 🏴 [U+1F3F4 WAVING BLACK FLAG]
• [U+E0067 TAG LATIN SMALL LETTER G]
• [U+E0062 TAG LATIN SMALL LETTER B]
• [U+E0073 TAG LATIN SMALL LETTER S]
• [U+E0063 TAG LATIN SMALL LETTER C]
• [U+E0074 TAG LATIN SMALL LETTER T]
• [U+E007F CANCEL TAG]

이러한 메커니즘은 각각 함께 사용될 수 있으므로, 매우 복잡한 문자 시퀀스가 하나의 이모지 자소나 이미지 형성에 사용될 수 있다. 매우 비슷한 이모지 시퀀스라도 정확히 같은 인코딩 시퀀스를 사용하지 않을 수 있다. 대부분의 경우 위에서 언급한 수정자와 조합은 최종 사용자의 키보드에서 생성된다 (여기서는 하나의 이모지 "문자"로 표시된다). 이러한 인코딩 옵션의 다양성은 서로 다른 벤더가 유니코드가 "교환용으로 권장"하는 시퀀스만을(그리고 정확히 그 시퀀스를) 사용하는 범위에서 부분적으로 해결된다. 이는 벤더가 글꼴과 키보드가 사용자가 기대하는 옵션을 제공할 준비가 되도록 보장하는 데 도움이 된다. 그래도 사용자는 일반적으로 기본 인코딩의 복잡성과 생성 메커니즘을 인식하지 못하며, 생성 메커니즘은 권장된 것에만 제한되지 않는다. 이모지 시퀀스는 빠르게 발전하고 있으므로 가까운 미래에 이모지 매칭을 돕거나 방해하는 추가 발전이 있을 수 있다. 유니코드 정규화는 이러한 시퀀스를 재정렬하거나 수정자를 삽입 또는 제거하지 않는다. 따라서 사용자와 구현자는 네임스페이스 및 기타 매칭 문맥에서 이모지 문자를 사용하는 사용자가 인코딩 변이 때문에 예상치 못한 "문자" 불일치를 쉽게 겪을 수 있음을 주의해야 한다.

2.8 레거시 문자 인코딩

리소스는 웹에서 문서 형식을 직렬화하기 위해 레거시 문자 인코딩을 포함한 서로 다른 문자 인코딩 체계를 사용할 수 있다. 각 문자 인코딩 체계는 범용 문자 집합의 주어진 하위 집합을 표현하기 위해 서로 다른 바이트 값과 시퀀스를 사용한다.

예를 들어 € [U+20AC EURO SIGN]은 UTF-8 문자 인코딩에서 바이트 시퀀스 0xE2.82.AC로 인코딩된다. 같은 문자는 레거시 문자 인코딩 windows-1252에서 바이트 시퀀스 0x80으로 인코딩된다. (다른 레거시 문자 인코딩은 이 문자를 인코딩할 바이트 시퀀스를 전혀 제공하지 않을 수도 있다.)

명세는 주로 문서를 문서의 문자 인코딩(레거시 문자 인코딩이든 UTF-8과 같은 유니코드 인코딩이든)에서 변환하고 문자 이스케이프를 모두 해제한 뒤, 문서 처리를 계속하기 전에 각 문서를 유니코드 문자 시퀀스로 간주함으로써 이러한 결과적 변이를 다룬다.

유니코드로 변환할 때 추가로 고려할 사항 하나는 시각적 저장 순서를 사용하는 양방향 문자 체계(예: 히브리어 및 아랍어)의 레거시 문자 인코딩이 존재한다는 점이다. 즉, 유니코드 및 기타 현대적 인코딩과 달리, 문자는 (라인 프린터에서처럼) 화면에 왼쪽에서 오른쪽으로 인쇄되는 순서대로 메모리에 저장된다. 이러한 인코딩을 유니코드로 변환하거나 이러한 인코딩의 텍스트를 비교할 때는 원본 텍스트와 대상 텍스트 모두를 논리적 순서로 배치하도록 주의해야 한다. 자세한 내용은 [CHARMOD]의 3.3.1절을 참조하라.

2.9 기타 동등성 유형

3.1 콘텐츠 제한 지정

문자열 매칭을 더 효과적이고 일관되게 만들 수 있는 방법 중 하나는 매칭 대상 콘텐츠에 제한을 적용하는 것이다. 어휘의 정의, 특히 그 어휘 안에서 사용자 제공 값을 허용하는 정의에는 필연적으로 "유효한 식별자"를 만드는 규칙이 포함된다. 여기에는 보통 길이와 콘텐츠 제한이 포함된다. 이러한 제한을 정의하기 위한 몇 가지 모범 사례는 다음과 같다.

식별자에는 크게 두 가지 부류가 있다. 사용자 대면 식별자와 애플리케이션 내부 식별자이다.

애플리케이션 내부 식별자는 기계가 읽을 수 있고 표시를 의도하지 않는 문서 형식 또는 프로토콜의 어휘 부분이다. 이러한 식별자에는 문서 형식이나 프로토콜의 내용을 다루거나 디버그해야 하는 개발자 또는 콘텐츠 작성자를 돕기 위해 (일반적으로 영어로) 의미 있는 이름이 부여되는 경우가 많다.

사용자 대면 식별자는 사용자가 할당하거나 편집하거나, 사용자가 선택할 수 있도록 제시되는 문서 형식 또는 프로토콜의 어휘 부분이다. 사용자 대면 식별자의 예로는 네트워크 이름(예: SSID), 장치 이름, class, style 또는 attribute 이름, 사용자 정의 설정이나 값 등이 있다. 이러한 종류의 식별자는 이 문서에서 설명하는 문제 때문에 매칭이 더 복잡하지만, 특히 영어를 하지 않거나 라틴 문자에 덜 익숙한 사용자에게 최상의 경험을 제공한다.

많은 사용자 대면 식별자는 또한 사용자 제공 값이며, 문서 형식이나 프로토콜의 사용자가 할당할 수 있다. 사용자가 선호하거나 사용자의 공동체 또는 문화에서 선호하는 자연어를 사용할 수 있는 능력은 더 나은 사용자 경험을 제공하고, 특히 영어에서 언어 능력이 제한될 수 있는 대상에게 기능을 더 접근 가능하게 만든다.

넓은 범위의 유니코드 문자가 허용되어야 하지만, 명세는 여전히 사용자 대면 식별자의 콘텐츠에 특정한 실용적 제한을 부과할 수 있다. 이러한 유형의 콘텐츠 규칙을 정의하는 명세의 한 예는 Unicode Identifier and Pattern Syntax [UAX31]에서 찾을 수 있다.

3.2 매칭 알고리즘 선택

주어진 명세에 사용할 매칭 알고리즘을 선택할 때의 기본 결정은 매칭되는 문자열에 적용할 텍스트 정규화 수준(대소문자 민감성과 유니코드 정규화를 모두 포함)이다. 역사적으로 웹의 대부분의 명세는 유니코드 정규화 없이 대소문자 구분 매칭을 선택해 왔으며, 이는 모든 새 명세에 대해 권장되는 매칭 형식이다. 그러나 대소문자 비구분과 정규화가 유용한 경우도 있다.

명세는 해당 형식이나 프로토콜 사용자에게 주는 이점이 구현 비용과 복잡성을 능가한다면 대소문자 비구분을 선택할 수 있다. 대소문자 접기와 정규화는 모두 비교되는 값에 영향을 줄 수 있고, 텍스트의 표시 및 경우에 따라 의미에도 영향을 줄 수 있으며, 이러한 작업은 상대적으로 비용이 많이 들기 때문에, 대소문자 비구분을 선택하는 것은 일반적으로 권장되지 않는다.

대소문자 비구분의 특수한 경우는 ASCII/Basic Latin 범위(즉, 코드 포인트 U+0000부터 U+007F까지)로 제한된 어휘이다. 이러한 명세는 해당 문자 범위에 대해서만 대소문자 비구분을 선택할 수 있다. 이는 매칭 구현을 크게 단순화한다. 그러나 이 매칭 형식은 식별자나 구문에서 더 넓은 범위의 유니코드를 허용하는 명세에는 적절하지 않다. 사용자가 매칭 동작을 이해하기 어렵고, 비ASCII 문자 체계와 언어의 사용자에게 불리하기 때문이다. 즉 사용자는 green은 GREEN과 매칭되지만 grüß는 GRÜẞ 또는 어쩌면 GRÜSS와 매칭되지 않고(대신 GRüß와 매칭되는) 상황을 이상하고 예측 불가능하다고 느낀다.

4.1 정규 표현식

정규 표현식 구문은 사용자가 부분적으로만 알려진 값이나 예측 가능한 방식으로 달라질 수 있는 값을 지정할 수 있게 하므로, 형식이나 프로토콜을 정의할 때 때때로 유용하다. 이 문서의 여러 절에서 보았듯이, 유니코드에서 문자가 인코딩될 수 있는 여러 방식에는 변이가 있으며, 이는 표현식에서 문자열이 지정되거나 매칭되는 방식에 잠재적으로 간섭한다. 예를 들어, 문자를 세는 작업은 사용된 유니코드 코드 포인트 수가 아니라 자소 경계에 의존해야 할 수 있고, 대소문자 없는 매칭은 대소문자 접기의 변이를 고려해야 할 수 있으며, 처리되는 표현식이나 텍스트의 유니코드 정규화를 고려해야 할 수도 있다.

Unicode Regular Expressions Level 1 지원에는 정규 표현식에서 이스케이프 사용을 포함해 유니코드 코드 포인트를 지정하는 기능, 그리고 대부분의 정규 표현식 구문에 공통적인 특정 종류의 경계뿐 아니라 유니코드 문자 속성에 접근하는 기능이 포함된다.

Level 2는 이를 확장하여 여러 중요한 기능을 제공하는데, 특히 특정 종류의 자소 클러스터 경계에서 텍스트를 선택하는 기능과 대소문자 변환 지원(위에서 광범위하게 언급한 두 주제)을 포함한다. Level 3은 로캘 [LTLI] 기반 정규 표현식 맞춤 조정을 제공하며, 이는 형식 언어에서는 덜 유용하지만 지역화 가능 콘텐츠를 처리할 때 유용할 수 있다.