월드 와이드 웹 문자 모델: 문자열 일치

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

월드 와이드 웹 문자 모델의 이 부분에서는 문자열 일치, 즉 명세 또는 구현이 두 문자열 값이 서로 같은지 다른지를 정의하는 과정을 다룹니다. 의미상 동등한 텍스트가 서로 다르게 인코딩될 수 있는 방식과 이것이 형식 언어에서 중요한 일치 연산에 미치는 영향을 설명합니다. 이러한 형식 언어에는 웹을 구성하는 형식과 프로토콜에서 사용되는 언어가 포함됩니다.

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

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

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

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

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

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

두 번째 절에서는 여러 W3C 명세에서 정의된 문서 형식과 같은 형식 언어에서 사용할 문자열 동일성 일치의 요구 사항과 권고 사항을 제공합니다. 이는 주로 웹이 올바르게 작동하도록 하고 문서 작성자에게 일관된 결과를 제공하는 것과 관련됩니다.

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

문자 모델의 핵심에는 유니코드 표준 [Unicode]과 ISO/IEC 10646 [ISO10646]에서 공동으로 정의한 범용 문자 집합(UCS)이 있습니다. 이 문서에서는 유니코드를 범용 문자 집합의 동의어로 사용합니다. 성공적인 문자 모델은 전 세계의 다양한 표기 체계, 문자 및 언어로 여러 플랫폼에서 작성된 웹 문서를 전 세계 웹 사용자가 교환하고 읽고 검색할 수 있도록 합니다.

유니코드 표준의 첫 몇 장은 [Unicode] 유용한 배경 자료를 제공합니다.

이 명세의 중요한 부분을 개발하는 데 기초가 된 요구 사항에 대한 자세한 내용은 문자열 동일성 일치 및 문자열 색인 요구 사항 [CHARREQ]을 참조하십시오.

이 절에서는 이 문서에만 적용되는 용어와 표기법을 설명합니다.

웹은 텍스트 기반 형식과 프로토콜을 기반으로 구축됩니다. 문자열 일치 또는 검색을 효과적으로 설명하려면 주어진 형식이나 프로토콜 내의 서로 다른 텍스트 유형에 관해 논의할 수 있도록 하는 용어를 확립해야 합니다. 유형에 따라 요구 사항과 세부 정보가 크게 다르기 때문입니다.

유니코드 코드 포인트(또는 "코드 포인트")는 각 유니코드 문자에 할당된 숫자 값을 의미합니다. 유니코드 코드 포인트의 범위는 0에서 0x10FFFF까지입니다. 문자 인코딩 용어에 관한 자세한 설명은 [CHARMOD]의 4.1절을 참조하십시오.

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

이 문서의 예시에서 사용되는 일부 문자는 특정 기기나 디스플레이에서 의도한 대로 표시되지 않을 수 있습니다. 일반적으로 이는 로컬에 해당 문자 전용 글꼴이 설치되어 있지 않거나 특정 렌더링 시스템에 다른 제한이 있기 때문입니다. 이 문서는 여러 비라틴 문자의 대체 글리프를 제공하기 위해 웹 글꼴을 사용하지만, 기기가 해당 글꼴의 표시를 지원하지 않을 수 있습니다. 편집자는 가능한 범위에서 이러한 경우에도 예시를 이해할 수 있도록 노력했습니다.

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

트랜스코더는 두 문자 인코딩 사이에서 텍스트를 변환하는 절차입니다. 이 문서에서는 대부분 레거시 문자 인코딩에서 UTF-8과 같은 유니코드 인코딩 형식으로 변환하는 절차를 의미합니다.

자연어는 인간이 사용하는 음성, 문자 또는 수화 의사소통입니다(여기 [LTLI]도 참조하십시오).

구문 콘텐츠는 형식이나 프로토콜의 구조에 속하는 문서 형식 또는 프로토콜 내의 모든 텍스트입니다. 이 정의에는 일반적으로 "마크업"으로 간주되는 값뿐만 아니라 HTTP 헤더의 필드 이름과 같은 다른 값도 포함될 수 있습니다. 구문 콘텐츠는 형식 또는 프로토콜의 구조를 구성하는 모든 문자로 이루어집니다. 예를 들어 <와 > 및 이 기호가 둘러싸는 요소 이름과 여러 속성은 HTML 문서의 구문 콘텐츠에 포함됩니다.

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

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

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

어휘 내의 값은 크게 두 종류로 나뉩니다. 사람이 보고 읽거나 상호 작용하도록 의도된 값으로, 자연어 텍스트를 포함할 것으로 예상할 수 있는 값과, 애플리케이션이나 프로토콜 내부에서 사용되며 사람이 상호 작용하도록 의도되지 않은 값입니다.

사용자 대상 식별자는 어휘에서 사용자가 정의하거나 사용자에게 할당한 식별자로, 최종 사용자에게 적어도 잠재적으로 표시되도록 의도된 식별자입니다. 따라서 이는 현지화 가능한 콘텐츠입니다.

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

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

현지화 가능한 콘텐츠는 사람이 읽을 수 있는 텍스트로 의도된 문서 콘텐츠를 의미하며, 문서 구조의 일부를 형성하는 주변 또는 내장된 구문 콘텐츠는 포함하지 않습니다. 구문 콘텐츠 내부에 현지화 가능한 콘텐츠가 포함될 수 있다는 점에 유의하십시오. 예를 들어 [HTML] img 요소의 alt 속성에 이미지 설명이 포함될 수 있습니다.

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

자소는 일반적인 사용자가 단일 단위(문자)로 인식하는 텍스트의 시각적 표현에서 하나 이상의 문자로 이루어진 시퀀스입니다. 자소는 정렬 또는 텍스트 선택과 같은 여러 텍스트 연산에서 중요하므로 사용자가 인식하는 각 문자 사이의 경계를 계산할 수 있어야 합니다. 유니코드는 유니코드 표준 부록 #29: 텍스트 분할 [UAX29]에서 자소를 계산하는 기본 메커니즘을 정의하며, 이 근사값을 자소 클러스터라고 부릅니다. 두 가지 유형의 기본 자소 클러스터가 정의되어 있습니다. 달리 명시하지 않는 한 이 문서의 자소 클러스터는 확장 기본 자소 클러스터를 의미합니다. 자소 클러스터에 관한 설명은 유니코드 표준의 2장에도 제공됩니다 [Unicode]. 유니코드 표준 버전 8.0의 2.11절 끝부분도 참조하십시오.

자연어마다 요구 사항이 다르므로 자소 클러스터에도 맞춤화가 필요할 수 있습니다. 예를 들어 슬로바키아어 사용자는 기본적으로 두 개의 자소 클러스터인 "ch"를 하나의 자소 클러스터로 취급하고자 할 수 있습니다. 문자열 콘텐츠의 언어와 최종 사용자의 기본 설정 사이의 상호 작용은 복잡할 수 있습니다.

비규범적으로 표시된 절뿐만 아니라 이 명세의 모든 작성 지침, 도표, 예시 및 참고 사항은 비규범적입니다. 이 명세의 나머지 모든 내용은 규범적입니다.

이 문서의 핵심 용어 할 수 있습니다, 반드시 해야 합니다, 해서는 안 됩니다, 선택 사항입니다, 권장됩니다, 해야 합니다 및 하지 않아야 합니다는 여기에 표시된 것처럼 모두 대문자로 나타나는 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 합니다.

이 문서는 다른 명세의 작성자를 위한 모범 사례와 구현자 및 콘텐츠 작성자를 위한 권고 사항을 설명합니다. 이러한 모범 사례는 국제화 작업 그룹의 명세 개발자를 위한 국제화 모범 사례 [INTERNATIONAL-SPECS]에서도 확인할 수 있으며, 이 문서는 W3C 명세의 모든 국제화 모범 사례를 위한 일반 참조로 사용됩니다.

이 문서의 모범 사례에서는 특정 권고에 관한 국제화 작업 그룹의 의도를 명확히 하기 위해 [RFC2119] 키워드를 사용합니다. 이 문서의 권고 사항을 따르면 W3C의 "광범위한 검토" 과정, 구현 또는 작성자가 제작하는 콘텐츠에서 발생하는 문제를 방지하는 데 도움이 될 수 있습니다. 이 문서 자체는 규범적이지 않으며 수시로 개정될 수 있습니다.

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

1. 명령형 표현이 반드시 해야 합니다 또는 해서는 안 됩니다인 경우 [S]가 앞에 붙은 적합성 기준을 위반하지 않습니다.
2. 명령형 표현이 해야 합니다, 하지 않아야 합니다 또는 권장됩니다인 기준에서 벗어나는 모든 경우에 그 이유를 문서화합니다.
3. 구현이 이 문서를 준수하도록 적합성 요구 사항을 설정합니다.
4. 콘텐츠가 이 문서를 준수하도록 적합성 요구 사항을 설정합니다.

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

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

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

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

대부분의 문자는 대소문자를 구분하지 않으므로 대소문자 매핑과 마찬가지로 대부분의 유니코드 코드 포인트에는 대소문자 접기가 필요하지 않습니다. 대소문자 접기가 있는 코드 포인트의 대부분은 다른 하나의 일치하는 코드 포인트, 일반적으로 소문자 코드 포인트로 간단하고 직접 매핑됩니다. 유니코드는 이 접기 집합을 공통이라고 부릅니다. 유니코드에서 정의한 두 가지 대소문자 접기 유형 모두에 이 집합이 포함되기 때문입니다.

일부 문자는 하나의 유니코드 코드 포인트를 두 개 이상의 코드 포인트로 매핑하는 대소문자 접기를 가집니다. 이 대소문자 접기 집합을 전체 대소문자 접기라고 합니다. 전체 및 공통 대소문자 접기를 함께 사용하여 모든 유니코드에 대한 기본 대소문자 접기를 제공합니다. 이 문서에서는 이 대소문자 접기 형식을 전체 대소문자 접기 또는 유니코드 전체라고 합니다.

일부 애플리케이션은 대소문자 접기 연산을 수행할 때 추가 저장 공간을 할당할 수 없으므로, 유니코드는 일반적으로 더 많거나 적은 코드 포인트로 접히는 코드 포인트를 비교 목적으로 하나의 코드 포인트에 매핑하는 단순 대소문자 접기를 제공합니다. 전체 접기와 달리 이 접기는 언제나 텍스트의 콘텐츠 및 잠재적으로 의미를 변경합니다. 전체 대소문자 접기와 마찬가지로 단순 대소문자 접기 또는 유니코드 단순 대소문자 접기는 유니코드의 전체 범위를 다루기 위해 단순 및 공통 매핑을 결합한 것입니다. 유니코드 단순은 웹에서 사용하기에 적합하지 않습니다.

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

유니코드 텍스트에는 또 다른 종류의 변형이 발생할 수 있습니다. 경우에 따라 여러 서로 다른 유니코드 코드 포인트 시퀀스를 사용하여 동일한 추상 문자를 나타낼 수 있습니다. 코드 포인트를 비교하여 텍스트를 검색하거나 일치시키는 경우 이러한 인코딩 변형으로 인해 사용자가 동일할 것으로 예상하는 텍스트 값이 일치하지 않을 수 있습니다.

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

리소스는 해당 명세와 웹 구현에서 텍스트의 유니코드 정규화를 요구하지 않고, 이후 구문 콘텐츠( 사용자 제공 값 포함) 및 현지화 가능한 콘텐츠를 처리할 때 사용되는 문자열 일치 알고리즘을 고려하지 않기 때문에 이러한 변형의 영향을 받기 쉽습니다. 따라서 콘텐츠 개발자는 이후의 문제를 방지하기 위해 일관된 표현을 제공해야 합니다.

그러나 텍스트로 볼 때 이러한 차이는 일반적으로 보이지 않으므로 사용자가 특정 리소스 또는 리소스 집합이 일관된 텍스트 표현을 사용하는지 확인하기 어려울 수 있습니다. 따라서 도구와 구현은 시각적으로나 논리적으로 동등하여 사용자의 관점에서 일치해야 하는 문자열이 서로 다른 값으로 간주될 때 사용자가 겪는 어려움을 고려해야 합니다. 사용자가 이러한 차이를 확인하거나 적절히 정규화할 수 있는 수단을 제공하면 최종 사용자가 원본 문서의 보이지 않는 차이로 인해 발생하는 실패를 방지할 수 있습니다. 예를 들어 W3C 검사기는 HTML 문서가 유니코드 정규화 형식 C로 완전히 정규화되지 않은 경우 경고합니다.

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

유니코드 정준 정규화 형식은 특정 추상 문자 또는 자소 클러스터에 사용할 수 있는 여러 서로 다른 코드 포인트 시퀀스를 동일한 코드 포인트 시퀀스로 접는 것과 관련됩니다. 그러나 논리적으로 서로 다른 문자 또는 자소 클러스터도 여전히 동일하거나 매우 유사하게 보일 수 있습니다. 한 쌍의 자소가 동일하거나 매우 유사하게 보이는 경우 이를 동형 문자라고 합니다. 한 쌍의 자소가 비슷하게 보이거나 동형 문자이지만 실제로 논리적으로 서로 다른 문자나 문자 시퀀스를 나타내는 경우 이를 혼동 가능하다고 합니다.

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

외관이 동일하거나 혼동 가능한 문자는 스푸핑 및 기타 보안 위험을 초래할 수 있습니다. 이는 하나의 문자 체계 내에서 또는 서로 다른 문자 체계의 유사한 문자 사이에서 발생할 수 있습니다. 동형 글리프 및 혼동 가능성에 대한 추가 설명과 예시는 [UTS39]를 참조하는 것이 유용합니다.

동일하거나 비슷하게 보이는 문자 외에도 반대의 문제도 존재합니다. 유니코드 정규화는 NFKC 및 NFKD 호환성 형식을 포함하더라도 본질적인 의미나 기능은 동일하지만 외관 또는 사용 방식이 다른 문자를 하나로 만들지 않습니다. 예를 들어 U+002E(.)와 U+3002(。)는 모두 문장을 끝내는 구두점으로 기능하지만 문자가 별개의 식별성을 가지므로 정규화로 이러한 구분이 제거되지 않습니다.

대소문자를 구분하지 않는 방식으로 문자열을 일치시키는 경우 발생하는 한 가지 복잡성은 원래 문자열이 정규화되어 있더라도 대소문자 접기 과정에서 정규화되지 않은 문자열이 생성될 수 있다는 것입니다. 문자열 비교는 코드 포인트 시퀀스의 일치에 의존하므로 일치 과정의 신뢰성을 보장하려면 대소문자가 접힌 각 문자열을 정규화해야 합니다.

유니코드 정준 정규화 형식(NFC 또는 NFD)과 대소문자 접기를 함께 사용하면 닫혀 있습니다. 즉, 문자열의 대소문자를 접은 다음 NFD 또는 NFC를 적용한 후 동일한 대소문자 접기나 유니코드 정규화 형식을 추가로 적용해도 다른 문자열이 생성되지 않습니다.

문자 사이의 호환성 동등성, 즉 NFKC/NFKD 형식으로 문자열을 비교하는 경우 대소문자 접기와 정규화 연산을 두 번 수행해야 합니다. 호환성 분해 단계에서 대소문자 접기가 필요한 문자가 생성될 수 있고, 이후의 대소문자 접기에서 다시 정규화해야 하는 시퀀스가 생성될 수 있기 때문입니다.

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

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

문자 이스케이프는 일반적으로 문서를 처리하고 형식 또는 프로토콜 내의 문자열을 일치시키기 전에 해석됩니다. 위에서 사용한 예로 돌아가 보겠습니다.

이 텍스트는 다음과 같이 표시될 것으로 예상할 수 있습니다. Hello world!

이 기능이 작동하려면 사용자 에이전트(브라우저)가 CSS와 HTML에서 서로 다른 이스케이프 메커니즘을 사용했더라도 클래스 이름 héllo를 나타내는 두 문자열을 일치시켜야 합니다. 위 조각은 텍스트가 달라질 수 있지만 명세에 따라 여전히 "동일한" 것으로 간주될 수 있는 한 가지 방법을 보여 줍니다. 클래스 이름 h\e9llo는 HTML 마크업의 클래스 이름 héllo와 일치하며, 코드 포인트 é [U+00E9 LATIN SMALL LETTER E WITH ACUTE]를 사용하는 리터럴 값 héllo와도 일치합니다.

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

포함된 리소스가 결합 마크로 시작하지 않는 경우, 즉 문자 이스케이프나 문자 리터럴 형태의 결합 마크로 시작하지 않는 경우 해당 포함을 포함 정규화됨이라고 합니다.

유니코드는 문서 작성자가 텍스트의 외관이나 동작을 제어하는 데 도움을 주는 여러 특수 목적 문자를 제공합니다. 이러한 문자 중 다수는 보이지 않거나 키보드에 대응하는 키가 없으므로 사용자가 해당 문자의 존재 여부를 항상 인식하는 것은 아닙니다. 그 결과 이러한 문자가 인코딩된 문자 시퀀스의 일부이지만 일치가 예상되는 텍스트에는 포함되지 않은 경우 문자열 일치를 방해할 수 있습니다. 이러한 문자의 예는 다음과 같습니다.

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

Zero Width Non-Joiner는 페르시아어에서 특정 "일반적인" 아랍 문자 연결을 방지하는 데 사용됩니다. 이러한 경우 문자의 존재 여부는 실제로 의미에 영향을 줍니다. 예를 들어 단어 تنها("혼자")와 단어 تن‌ها ("신체들" 또는 "시신들")는 각각 "U+062A U+0646 U+0647 U+0627" 및 "U+062A U+0646 U+200C U+0647 U+0627"로 인코딩되며, 유일한 차이는 두 번째 단어에 ZWNJ가 있다는 것입니다.

ZWJ 문자는 특정 이모지 시퀀스를 형성할 때도 사용되며 이에 대해서는 아래에서 자세히 설명합니다.

변형 선택자(U+FE00부터 U+FE0F까지)는 대체 외관 또는 글리프를 선택하는 데 사용하는 문자입니다. 문자 모델: 기본 원칙 [CHARMOD]을 참조하십시오. 예를 들어 흑백 이모지와 컬러 이모지 사이를 선택하는 데 사용됩니다. 이러한 문자는 미리 정의된 표의 문자 변형 시퀀스(IVS)에도 사용됩니다. 유니코드 문자 데이터베이스(UCD)의 "표준화된 변형" 부분에는 많은 예가 제공되어 있습니다.

일부 문자도 시각적 변형 선택을 인코딩하는 방법을 제공합니다. 대표적인 예로 몽골 문자의 자유 변형 선택자(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라고도 하며, 폭이 0인 줄바꿈 방지 공백 문자입니다. 이 문자의 목적은 두 문자 사이의 줄바꿈을 방지하는 것입니다. 줄바꿈 목적을 제외하면 무시해야 합니다. 이 문자는 U+FEFF ZERO WIDTH NO-BREAK SPACE를 대체합니다. U+FEFF는 더 일반적으로 "바이트 순서 표시"(BOM)로 알려져 있기 때문입니다. 바이트 순서 표시는 일부 일반 텍스트 파일의 시작 부분에서 해당 파일이 유니코드 문자 인코딩을 사용한다는 것을 나타내는 데 사용됩니다.

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

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

이러한 거의 모든 경우에 사용자는 특정 문서나 텍스트 문자열에 이러한 문자가 포함되거나 생략되었는지 인식하지 못하거나 확신할 수 없습니다. 텍스트 일치는 기본 코드 포인트의 일치에 의존하므로 이러한 표시자로 인한 텍스트 인코딩의 변형은 사용자의 관점에서 성공해야 하는 일치가 설명할 수 없이 실패하도록 만들 수 있습니다.

유니코드의 비교적 새로운 기능에는 이모지 문자가 있습니다. [UTS51]에서 유니코드는 이를 다음과 같이 설명합니다.

이모지는 일반적으로 다채로운 만화 형식으로 표시되며 텍스트 안에 인라인으로 사용되는 그림 문자입니다. 얼굴, 날씨, 차량과 건물, 음식과 음료, 동물과 식물 또는 감정, 느낌이나 활동을 나타내는 아이콘 등을 표현합니다.

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

예를 들어 이모지 👪 [U+1F46A FAMILY]는 시퀀스 U+1F468 U+200D U+1F469 U+200D U+1F466에서 이모지 문자 사이에 ZWJ를 사용하여 형성할 수도 있습니다. 다른 이모지 문자를 변경하거나 추가하면 가족의 구성이 달라질 수 있습니다. 예를 들어 시퀀스 👨‍👩‍👧‍👧 U+1F468 U+200D U+1F469 U+200D U+1F467 U+200D U+1F467는 이러한 유형의 결합을 지원하는 시스템에서 "가족: 남자, 여자, 여자아이, 여자아이"를 나타내는 결합 이모지 문자를 생성합니다. 여러 일반적인 이모지는 ZWJ 시퀀스를 사용해야만 형성할 수 있습니다. 자세한 내용은 [UTS51]을 참조하십시오.

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

이모지 문자 뒤에 변형 선택자를 추가하여 기본 이모지를 텍스트 형식으로 표시하거나 (U+FE0E Variation Selector 15로 표시되는 흑백) 컬러 형식으로 표시하도록 (U+FE0F Variation Selector 16으로 표시) 지정할 수도 있습니다.

이모지 사용에서 또 다른 복잡한 요소는 국기입니다. 국가의 국기는 [BCP47] 레지스트리에서 파생된 국가 코드를 사용하여 구성할 수 있습니다. 예를 들어 시퀀스 🇿 [U+1F1FF REGIONAL INDICATOR SYMBOL LETTER Z] 🇲 [U+1F1F2 REGIONAL INDICATOR SYMBOL LETTER M]은 잠비아의 국가 코드(ZM)이며 🇿🇲를 생성합니다. 다른 지역 또는 특수 목적의 국기는 여러 기호와 함께 국기 이모지를 사용하거나 취소 태그로 끝나는 지역 표시 코드를 사용하여 구성할 수 있습니다. 예를 들어 스코틀랜드 국기(🏴󠁧󠁢󠁳󠁣󠁴󠁿)는 다음과 같이 구성할 수 있습니다.

• 🏴 [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]

이러한 각 메커니즘은 함께 사용할 수 있으므로 상당히 복잡한 문자 시퀀스로 하나의 이모지 자소 또는 이미지를 형성할 수 있습니다. 매우 유사한 이모지 시퀀스도 정확히 동일한 인코딩 시퀀스를 사용하지 않을 수 있습니다. 대부분의 경우 위에서 언급한 수정자와 조합은 최종 사용자의 키보드에서 생성되며 키보드에서는 하나의 이모지 "문자"로 표시됩니다. 서로 다른 공급업체가 유니코드에서 "교환에 권장되는" 시퀀스만 정확히 사용한다면 이러한 다양한 인코딩 선택지로 인한 문제가 어느 정도 완화됩니다. 이를 통해 공급업체는 글꼴과 키보드가 사용자가 예상하는 선택지를 제공하도록 준비할 수 있습니다. 그러나 사용자는 일반적으로 기본 인코딩의 복잡성을 인식하지 못하며, 생성 메커니즘은 권장되는 시퀀스로 제한되지 않습니다. 이모지 시퀀스는 빠르게 발전하고 있으므로 가까운 미래에 이모지 일치를 지원하거나 방해하는 추가적인 변화가 발생할 수 있습니다. 유니코드 정규화는 이러한 시퀀스의 순서를 바꾸거나 수정자를 삽입 또는 제거하지 않습니다. 따라서 사용자와 구현자는 사용자가 이름 공간 및 기타 일치 문맥에서 이모지 문자를 사용할 때 인코딩 변형으로 인해 예상하지 못한 "문자" 불일치를 쉽게 겪을 수 있다는 점에 주의해야 합니다.

리소스는 레거시 문자 인코딩을 포함한 서로 다른 문자 인코딩 체계를 사용하여 웹에서 문서 형식을 직렬화할 수 있습니다. 각 문자 인코딩 체계는 범용 문자 집합의 특정 하위 집합을 나타내기 위해 서로 다른 바이트 값과 시퀀스를 사용합니다.

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

명세에서는 주로 문서의 문자 인코딩이 레거시 문자 인코딩인지 UTF-8과 같은 유니코드 인코딩인지에 관계없이 해당 인코딩에서 변환한 후 각 문서를 유니코드 문자 시퀀스로 간주하고, 문서를 처리하기 전에 문자 이스케이프를 해제함으로써 이러한 변형을 처리합니다.

유니코드로 변환할 때 추가로 고려할 사항 중 하나는 시각적 저장 순서를 사용하는 히브리어와 아랍어 같은 양방향 문자의 레거시 문자 인코딩이 존재한다는 것입니다. 즉, 유니코드 및 다른 최신 인코딩과 달리 문자는 라인 프린터와 마찬가지로 화면에 왼쪽에서 오른쪽으로 인쇄되는 순서로 메모리에 저장됩니다. 이러한 인코딩을 유니코드로 변환하거나 해당 인코딩의 텍스트를 비교할 때는 원본 텍스트와 대상 텍스트 모두를 논리적 순서로 배치하도록 주의해야 합니다. 자세한 내용은 [CHARMOD]의 3.3.1절을 참조하십시오.

문자열 일치를 더 효과적이고 일관되게 만드는 방법 중 하나는 일치시킬 콘텐츠에 제한을 적용하는 것입니다. 어휘, 특히 해당 어휘 내에서 사용자 제공 값을 허용하는 어휘의 정의에는 필연적으로 "유효한 식별자"를 구성하는 규칙이 포함됩니다. 여기에는 일반적으로 길이 및 콘텐츠 제한이 포함됩니다. 이러한 제한을 정의하기 위한 몇 가지 모범 사례는 다음과 같습니다.

식별자는 크게 사용자 대상 식별자와 애플리케이션 내부 식별자의 두 종류로 나뉩니다.

애플리케이션 내부 식별자는 기계가 읽을 수 있고 표시를 목적으로 하지 않는 문서 형식 또는 프로토콜의 어휘 부분입니다. 문서 형식이나 프로토콜의 콘텐츠를 다루거나 디버깅해야 하는 개발자 또는 콘텐츠 작성자에게 편의를 제공하기 위해 이러한 식별자에는 의미 있는 이름, 일반적으로 영어 이름이 지정되는 경우가 많습니다.

사용자 대상 식별자는 사용자가 할당하거나 편집하거나 선택할 수 있도록 사용자에게 제시되는 문서 형식 또는 프로토콜의 어휘 부분입니다. 사용자 대상 식별자의 예로는 SSID와 같은 네트워크 이름, 기기 이름, 클래스, 스타일 또는 속성 이름, 사용자가 정의한 설정 또는 값이 있습니다. 이러한 식별자는 이 문서에서 설명하는 문제로 인해 일치시키기가 더 복잡하지만, 특히 영어를 사용하지 않거나 라틴 문자에 익숙하지 않은 사용자에게 가장 좋은 경험을 제공합니다.

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

광범위한 유니코드 문자를 허용해야 하지만 명세는 여전히 사용자 대상 식별자의 콘텐츠에 특정한 실용적 제한을 적용할 수 있습니다. 이러한 유형의 콘텐츠 규칙을 정의하는 명세의 예는 유니코드 식별자 및 패턴 구문 [UAX31]에서 확인할 수 있습니다.

특정 명세에 사용할 일치 알고리즘을 선택할 때의 기본 결정은 일치시킬 문자열에 적용할 텍스트 정규화 수준입니다. 여기에는 대소문자 구분과 유니코드 정규화가 모두 포함됩니다. 역사적으로 웹의 대부분 명세는 유니코드 정규화를 적용하지 않는 대소문자 구분 일치를 선택해 왔으며, 이는 모든 새로운 명세에 권장되는 일치 형식입니다. 그러나 대소문자를 구분하지 않는 방식과 정규화가 유용한 경우도 있습니다.

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

대소문자를 구분하지 않는 특수한 사례로 ASCII/기본 라틴 문자 범위, 즉 코드 포인트 U+0000부터 U+007F까지로 제한된 어휘가 있습니다. 이러한 명세는 해당 문자 범위에서만 대소문자를 구분하지 않도록 선택할 수 있습니다. 이는 일치 구현을 크게 단순화합니다. 그러나 이 일치 형식은 식별자 또는 구문에서 더 넓은 유니코드 범위를 허용하는 명세에는 적합하지 않습니다. 사용자가 일치 동작을 이해하기 어렵고 ASCII가 아닌 문자와 언어를 사용하는 사용자에게 불리하기 때문입니다. 즉, 사용자는 green이 GREEN과 일치하지만 grüß가 GRÜẞ 또는 GRÜSS와는 일치하지 않고 대신 GRüß과 일치하는 경우 이를 이상하고 예측할 수 없는 동작으로 받아들입니다.

정규 표현식 구문은 사용자가 일부만 알려져 있거나 예측 가능한 방식으로 달라질 수 있는 값을 지정할 수 있게 하므로 형식이나 프로토콜을 정의할 때 유용할 수 있습니다. 이 문서의 여러 절에서 살펴본 것처럼 문자를 유니코드로 인코딩할 수 있는 방식에는 변형이 있으며, 이는 표현식에서 문자열을 지정하거나 일치시키는 방식을 방해할 수 있습니다. 예를 들어 문자 수를 셀 때는 사용되는 유니코드 코드 포인트 수가 아니라 자소 경계에 의존해야 할 수 있습니다. 대소문자를 구분하지 않는 일치는 대소문자 접기 변형을 고려해야 할 수 있으며, 처리되는 표현식 또는 텍스트의 유니코드 정규화를 고려해야 할 수도 있습니다.

유니코드 정규 표현식 수준 1 지원에는 이스케이프를 사용하는 방식을 포함하여 정규 표현식에서 유니코드 코드 포인트를 지정하는 기능과 유니코드 문자 속성 및 대부분의 정규 표현식 구문에 공통적인 특정 유형의 경계에 접근하는 기능이 포함됩니다.

수준 2는 이를 여러 중요한 기능으로 확장합니다. 특히 특정 유형의 자소 클러스터 경계에서 텍스트를 선택하는 기능과 대소문자 변환 지원이 포함됩니다. 이 두 주제는 위에서 자세히 설명했습니다. 수준 3은 로케일 [LTLI]을 기반으로 정규 표현식을 맞춤화하는 기능을 제공합니다. 이는 형식 언어에서는 유용성이 낮지만 현지화 가능한 콘텐츠를 처리할 때 유용할 수 있습니다.