웹의 문자열: 언어 및 방향 메타데이터

문자열은 콘텐츠 작성자가 일반 텍스트 편집기, 문자 메시지 또는 편집 도구에 문자열을 입력하거나, 스크립트가 웹 페이지에서 텍스트를 추출하거나, 다른 애플리케이션 또는 저장소에서 기존 문자열 집합을 가져오는 등 다양한 방식으로 생성될 수 있습니다. 이 문서에서 고려하는 데이터 형식에서는 많은 문자열이 백엔드 데이터 저장소 또는 여러 종류의 데이터베이스에서 생성됩니다. 문자열의 출처는 데이터의 문자열 방향과 언어에 관한 정보를 포함하는 인터페이스, API 또는 메타데이터를 제공할 수 있습니다. 일부 출처는 방향이나 언어가 제공되거나 지정되지 않았을 때 사용할 적절한 기본값도 제공합니다. 이 문서에서 문자열의 생산자는 사람이든 메커니즘이든 저장 또는 전송을 위해 문자열을 생성하거나 제공하는 출처입니다.

문자열이 생성될 때는 (a) 문자열과 연결할 적절한 언어와 문자열 방향을 감지하거나 캡처하고, (b) 필요한 경우 언어와 문자열 방향을 저장하고 전달할 수 있도록 문자열을 설정해야 합니다.

예를 들어 HTML 양식에서 추출된 문자열의 경우, 문자열 방향은 양식 필드의 계산된 값에서 감지할 수 있습니다. 이러한 값은 html 요소와 같은 앞선 요소에서 상속될 수도 있고, input 요소 자체의 마크업 또는 스타일링을 사용하여 설정될 수도 있습니다. 사용자는 키보드 단축키를 사용하여 양식 필드의 방향을 변경함으로써 텍스트 방향을 설정할 수도 있습니다. dirname 속성은 양식을 제출할 때 해당 값을 자동으로 전달하는 방법을 제공합니다.

마찬가지로 HTML 양식의 언어 정보는 일반적으로 html 태그의 lang 속성 또는 트리에서 lang 속성을 가진 상위 요소에서 상속됩니다.

문자열 생산자가 다른 생산자가 저장한 위치에서 문자열을 수신하고 있으며 해당 위치에서 문자열 방향과 언어가 이미 확립되어 있다면, 생산자는 언어와 문자열 방향이 이미 설정되었음을 이해하고 이 정보를 소비자를 위해 변환하거나 인코딩하는 방법을 이해해야 합니다.

소비자는 처리를 위해 문자열을 수신하고, 사용자가 볼 수 있는 맥락에 문자열을 배치할 수도 있는 애플리케이션 또는 프로세스입니다. 표시 목적의 경우 소비자는 해당 맥락에서 문자열의 블록 방향과 언어가 문자열에 올바르게 적용되도록 해야 합니다. 처리 목적의 경우 소비자는 적어도 언어와 방향을 유지해야 하며, 언어별 작업을 수행하기 위해 언어 및 방향 데이터를 사용해야 할 수도 있습니다.

문자열을 올바르게 표시하려면 추가 마크업을 적용하거나, 제어 코드를 추가하거나, 표시 속성을 설정하여 문자열 방향과 언어를 렌더링 문서 또는 프로세스에 제공해야 합니다. 이는 이 표시 맥락에서 문자열이 올바르게 나타나도록 문자열에 적용해야 하는 문자열 방향 또는 언어를 렌더링 소프트웨어에 나타냅니다. 언어와 방향 모두에서 해당 언어가 적용되는 텍스트 범위의 경계를 명확히 해야 합니다. 텍스트 방향의 경우 양방향 알고리즘 [UAX9]의 영향이 주변 텍스트로 번지는 것을 방지하기 위해 포함된 문자열을 주변 텍스트로부터 격리해야 합니다.

한 문서 형식의 소비자가 다른 문서 형식의 생산자일 수도 있다는 점에 유의하십시오.

모든 생산자와 소비자 사이에는 문서 형식에 포함되는 내용과 각 필드 또는 속성의 데이터가 의미하는 바에 대한 규약이 필요합니다. 문자열 생산자가 해당 문자열의 문자열 방향 또는 언어에 관한 정보를 수집하고 전달하기 위해 특별한 조치를 취할 때마다, 문자열 소비자가 생산자가 이 정보를 인코딩한 방법을 이해할 것이라는 전제하에 그렇게 해야 합니다.

생산자가 아무런 조치를 취하지 않더라도, 소비자는 적절한 문자열 방향과 언어를 결정하기 위해 어떤 규칙을 따를지 정해야 합니다. 이는 단지 어떤 형태의 기본값을 제공하는 것일 수도 있습니다.

일부 시스템 또는 문서 형식에서는 문자열 생산자와 소비자에게 필요한 동작이 완전히 명시되어 있습니다. 다른 경우에는 이러한 규약이 제공되지 않으므로 필요한 언어 또는 방향 정보를 인코딩하고, 전송하고, 나중에 디코딩하는 방법에 대한 규약을 사용자가 제공해야 합니다. JSON과 같은 저수준 명세는 기본적으로 문자열 메타데이터 구조를 제공하지 않으므로 이를 기반으로 하는 모든 문서 형식은 자체적으로 "규약"을 제공해야 합니다.

비언어적 필드 (즉, 인간 언어가 아닌 데이터를 포함하는 문자열)에 언어 또는 방향 메타데이터를 할당하거나 요구하지 마십시오. 여기에는 애플리케이션 내부 데이터 값도 포함된다는 점에 유의하십시오. [INTERNATIONAL-SPECS]

구문 콘텐츠 항목이나 사용자 제공 값의 값이 사람에게 의미를 전달하는 단어 형태의 토큰을 자주 사용하더라도(예: 디버깅을 돕기 위해), 사용자에게 표시할 때는 해당 값을 지역화 가능한 표시 문자열로 일관되게 감싸야 합니다.

단일 언어로 나타나는 지역화 가능한 텍스트 필드의 경우 값을 나타내는 데이터 구조를 사용하십시오. 권장 표현은 세 개의 필드를 가진 객체입니다. value 필드에는 실제 문자열이 포함됩니다. lang 필드에는 유효한 [BCP47] 언어 태그가 포함됩니다. dir 필드에는 문자열의 문자열 방향 (ltr, rtl, auto 중 하나)이 포함됩니다.

언어 또는 문자열 방향을 결정하기 위해 휴리스틱을 사용하면 특정한 경우에는 항상 실패하므로, 해당 문자열에 올바른 결과를 제공할 수 있는 방법이 필요합니다. 메타데이터를 할당하는 것(리소스 전체 기본값 또는 문자열별 레이블)은 의도적인 행위이며, 휴리스틱을 적용해 결과를 추측할 필요를 없애 줍니다.

블록 방향을 나타내기 위해 메타데이터를 사용하는 것이 선호됩니다. 이는 소비자가 첫 강한 문자와 같은 방법을 사용해 방향을 추론하거나, RLM/LRM 표시자 삽입 또는 양방향 제어 문자와 같이 데이터 자체를 수정해야 하는 방법을 사용할 필요가 없도록 하기 때문입니다.

이는 언어와 방향 메타데이터를 모두 결합하며, 일관되게 채택되면 서로 다른 형식 간의 교환을 더 쉽게 만듭니다. 서로 다른 명세와 문서 형식 사이의 일관성은 문자열 데이터를 쉽게 교환할 수 있게 합니다. 필드 속성의 이름을 동일하게 지정하고 같은 의미 체계를 채택하면 서로 다른 명세가 다른 데이터 출처의 리소스에서 값을 더 쉽게 추출하거나 해당 리소스에 값을 추가할 수 있습니다.

리소스에 여러 자연어 문자열이 포함되어 있고 특히 이러한 문자열이 모두 같은 언어인 경우, 위에서 설명한 지역화된 문자열 표현을 사용하면 비효율적일 수 있습니다. 이러한 문자열의 인코딩 복잡성을 줄이기 위해 명세는 언어와 문자열 방향에 대한 리소스 수준 기본값을 설정할 수 있습니다. 언어가 방향을 내포하지 않으므로 이 둘은 별개의 값입니다. 여전히 위에서 설명한 표현을 사용하여 특정 문자열 값의 언어나 방향을 재정의할 수 있어야 합니다.

리소스 전체 기본값은 리소스 또는 문서 수준에서 지정되며 해당 리소스에 포함된 레이블 없는 모든 값에 적용할 수 있는 값입니다.

명세가 자체 문서 수준 기본값을 정의한다면 다음과 같은 두 개의 선택적 필드를 제공하십시오.

기본값에 대한 예외는 언제든 존재할 수 있으므로 사용자가 문자열별로 기본값을 재정의할 수 있어야 합니다.

메타데이터를 사용하여 외부에서 방향이 설정된 문자열에는 첫 강한 문자 휴리스틱이 적용되지 않습니다. U+200F RIGHT-TO-LEFT MARK와 같은 강한 방향성을 가진 문자가 문자열 앞에 추가되었더라도 리소스 전체 기본 메타데이터가 문자열의 표현을 재정의하여 번짐 효과를 일으킬 수 있습니다. 따라서 문자열 방향이 리소스 전체 기본값과 일치하지 않는 문자열의 경우 콘텐츠가 문자열 수준 메타데이터를 제공하여 기본값을 재정의할 수 있어야 합니다.

[JSON-LD]의 @context 메커니즘을 사용할 수 있는 명세에서는 @language 및 @direction 필드를 사용하여 문서 수준 기본값을 제공하십시오.

세계는 단일 언어로 이루어져 있지 않습니다. 한 가지 언어만 포함하는 문서로 콘텐츠를 지역화하려면 언어마다 문서를 반복해서 제공해야 합니다. 또한 콘텐츠를 요청할 때 언어 협상이 필요할 수도 있습니다.

이를 해결하는 한 가지 방법은 문서 안의 각 지역화 가능한 텍스트 필드에 다국어 값을 허용하는 것입니다.

언어 선택은 단순히 언어 태그 문자열 값을 사용자가 선호하는 로캘과 정확히 일치시키는 작업이 아닙니다. 일반적인 객체 표현을 사용하는 지역화 가능한 텍스트 필드는 값과 연결된 언어 태그를 알아내기 위해 객체를 역직렬화해야 합니다. 특정 파일에 값이 많을 때는 이 과정이 비효율적일 수 있습니다. 이러한 경우에는 언어 맵을 사용하여 지역화 가능한 텍스트 값을 구성하는 것이 모범 사례입니다. 이러한 맵은 선택을 위해 언어 태그를 노출하지만, 특정 문자열 값에 대해 언어와 방향을 모두 재정의해야 할 수 있으므로 맵의 값 쪽에서는 여전히 객체 표현을 사용합니다.

생산자는 아무 작업도 할 필요가 없습니다.

문자열은 그대로 저장됩니다.

소비자는 문자열에서 강한 유니코드 방향 속성을 가진 첫 번째 문자를 찾고, 그 문자와 일치하도록 문자열 방향을 설정해야 합니다. 그런 다음 문자열이 필요한 방식으로 표시되도록 적절한 작업을 수행합니다. 다음과 같은 이유로 이는 겉보기만큼 단순하지 않습니다.

1. 첫 번째 강한 문자를 찾으려면 문자열 시작 부분의 강한 방향이 없는 문자(예: 문장 부호, 숫자 등)와 문자열 안의 격리된 시퀀스, 즉 RLI/LRI/FSI...PDI 서식 문자로 둘러싸인 문자 시퀀스를 건너뛰어야 합니다.
2. 감지 알고리즘은 문자열 시작 부분의 마크업을 처리할 수 있어야 합니다. 해당 마크업이 단순한 문자열 텍스트인지, 대상 위치에서 파싱해야 하는 마크업인지 구분할 수 있어야 합니다. 파싱해야 하는 경우에는 마크업을 이해하고 마크업에 포함된 방향 관련 정보도 이해해야 합니다.

첫 강한 문자 감지는 필요한 문자열 방향이 아직 알려지지 않은 경우에만 필요합니다. 문자열별 메타데이터나 리소스 전체 선언을 통해 문자열의 방향이 지정되어 있다면 첫 강한 문자 휴리스틱을 호출해서는 안 됩니다. 예를 들어 첫 강한 문자 휴리스틱은 "HTML و CSS: تصميم و إنشاء مواقع الويب"와 같은 문자열에 잘못된 결과를 생성합니다. 정보에 근거한 의도를 나타내는 메타데이터를 사용하면 이를 수정할 수 있으며, 결과를 다시 잘못 만들 수 있는 휴리스틱을 적용할 필요도 없고 적용해서도 안 됩니다.

그러나 메타데이터를 적용할 메커니즘이 없거나 그러한 메커니즘이 있지만 콘텐츠 개발자가 사용하지 않았다면 첫 강한 문자 휴리스틱은 전부는 아니지만 많은 경우에 기본 방향을 확립하는 데 도움이 될 수 있습니다. 강한 방향성을 가진 서식 문자를 적용하면 방금 언급한 예와 같은 일반 텍스트 문자열에 올바른 결과를 제공할 수 있지만 항상 이러한 문자를 적용할 수 있는 것은 아닙니다 (4.3 RLM/LRM 표시자를 삽입하여 첫 강한 문자 보완하기 참조).

신뢰할 수 있는 경우 문자열을 변경하지 않고도 방향 정보를 얻을 수 있으며, 별도 메타데이터를 지원하는 데 필요한 규약과 구조도 필요하지 않습니다.

이 접근 방식의 주요 문제는 다음과 같은 경우에 잘못된 결과를 생성한다는 것입니다.

1. 문자열 전체에 필요한 방향과 다른 강한 방향성 문자로 시작하는 문자열(예: 해시태그로 시작하는 아랍어 게시물)
2. 강한 방향성 문자가 없는 문자열(예: 전화번호). 이러한 문자열은 RTL 맥락에서 잘못 표시될 가능성이 높습니다.
3. span과 같은 마크업으로 시작하여 첫 번째 강한 문자가 항상 LTR이 되는 문자열

전체 문자열이 RLI/LRI/FSI...PDI 서식 문자로 시작하고 끝나는 경우 유니코드 양방향 알고리즘을 따르면 첫 번째 강한 문자를 감지할 수 없습니다. 알고리즘이 양방향으로 격리된 텍스트를 감지 대상에서 제외하도록 요구하기 때문입니다.

문자열에서 강한 방향성 문자를 찾지 못하면 방향을 LTR로 가정하고 소비자가 그에 따라 동작해야 할 가능성이 높습니다. 그러나 이는 아직 충분히 검증되지 않았습니다.

문자열에 소비자가 마크업으로 파싱할 마크업이 포함되어 있다면 추가 문제가 발생합니다. 첫 번째 강한 방향성 문자를 검색할 때 문자열 시작 부분의 그러한 마크업도 건너뛰어야 합니다.

문자열의 파싱 가능한 마크업에 의도된 문자열 방향에 관한 정보가 포함되어 있다면 (예: HTML에서 값이 rtl인 dir 속성), 첫 강한 문자 휴리스틱에 의존하기보다 해당 정보를 사용해야 합니다. 이는 두 가지 면에서 문제가 됩니다. (a) 문자열 소비자가 마크업의 의미 체계를 이해한다고 가정합니다. 모든 당사자가 HTML 마크업만 사용한다는 규약이 있다면 괜찮을 수 있지만 임의의 XML 어휘를 다룰 때는 문제가 될 수 있습니다. (b) 소비자는 문자열의 처음 일부에만 마크업이 있어 마크업이 전체 문자열이 아니라 인라인 텍스트 범위에 적용되는 상황을 인식하고 처리할 수 있어야 합니다.

그러나 꺾쇠괄호로 묶인 콘텐츠가 실제 마크업이 아니라 마크업의 예제라면 해당 마크업을 건너뛰어서는 안 됩니다. RTL 맥락에서 마크업 소스 코드를 표시하려 하면 매우 혼란스러운 결과가 발생합니다. 그러나 문자열 소비자가 예제와 파싱 가능한 문자열의 차이를 항상 어떻게 알 수 있는지는 명확하지 않습니다.

첫 강한 문자 감지는 유니코드 양방향 알고리즘(UBA) [UAX9]에 설명되어 있지만 문자열 방향을 추정하기 위해 언급된 유일한 상위 수준 프로토콜은 아닙니다. 예를 들어 X(이전의 Twitter)와 Facebook은 현재 텍스트의 기본 방향을 추측하기 위해 서로 다른 기본 휴리스틱을 사용합니다. 어느 쪽도 단순한 첫 강한 문자 감지만 사용하지 않으며, 한쪽은 완전히 다른 방법을 사용합니다.

생산자는 문자열의 문자열 방향을 확인하고, 문자열이 저장되거나 전송될 때 함께 전달되는 메타데이터 필드에 이를 추가합니다.

메타데이터를 사용하는 방법에는 여러 가지가 있습니다.

1. 모든 문자열에 문자열 방향 레이블을 지정합니다.
2. 블록 방향에 대한 문서 수준 기본값을 제공하고 값이 다른 문자열에만 메타데이터를 포함합니다. 문자열의 방향을 알 수 없을 때는 auto 값을 사용합니다.
3. 소비자가 첫 강한 문자 감지를 수행하도록 하고, 잘못된 결과를 생성할 문자열, 즉 왼쪽에서 오른쪽으로 쓰는 강한 문자로 시작하는 오른쪽에서 왼쪽 문자열에만 레이블을 지정합니다.

한 번에 문자열 집합을 저장하거나 전송하는 경우 리소스 전체에 적용되는 전역 기본 문자열 방향을 설정하는 필드가 있으면 리소스의 모든 문자열이 이를 상속할 수 있어 유용합니다. 전역 필드 외에도 문자열의 문자열 방향이 기본값과 다른 경우에는 문자열별 메타데이터 필드를 연결할 수 있어야 합니다. 개별 문자열에 설정된 문자열 방향은 항상 기본값보다 우선해야 합니다.

소비자는 문자열과 함께 전송된 메타데이터를 읽는 방법을 이해해야 하며, 메타데이터가 없을 때는 첫 강한 문자 휴리스틱을 적용해야 합니다.

JSON 기반 문서 형식의 개별 값에는 언어와 방향 메타데이터를 모두 결합하고 일관되게 채택될 경우 서로 다른 형식 간의 교환을 쉽게 만드는 Localizable 딕셔너리 구조를 사용하는 것이 권장됩니다.

메타데이터를 문자열과 별개의 데이터 값으로 전달하면 문자열의 실제 콘텐츠에 영향을 주지 않고 의도된 문자열 방향을 전달하는 간단하고 효과적이며 효율적인 방법을 제공합니다.

모든 문자열에 방향 레이블이 지정되어 있거나 전역 설정과 문자열별 예외를 적용하여 모든 문자열의 방향을 확인할 수 있다면 각각의 문자열을 검사하고 휴리스틱을 실행하여 문자열 방향을 결정할 필요가 없습니다.

별도 정보는 문자열과 연결하여 함께 유지해야 합니다. 이는 정의된 프레임워크에 속하지 않는 일부 문자열 데이터 집합에서 문제가 될 수 있습니다.

특히 JSON-LD에서는 언어와 같은 방식으로 개별 문자열에 방향을 연결할 수 없습니다.

생산자는 문자열의 문자열 방향을 확인하고, 문자열 시작 부분에 표시자 문자(U+200F RIGHT-TO-LEFT MARK (RLM) 또는 U+200E LEFT-TO-RIGHT MARK (LRM))를 추가합니다. 표시자는 기능적으로 동작하지 않습니다. 즉, 소비자가 사용할 수 있는 기본 방향을 문자열에 자동으로 적용하는 것이 아니라 단순한 표시자일 뿐입니다.

가능한 접근 방식은 여러 가지가 있습니다.

1. 모든 문자열에 표시자를 추가합니다(권장되지 않음).
2. 소비자가 첫 강한 문자 감지를 수행하도록 하고, 잘못된 결과를 생성할 문자열(예: LTR 강한 문자로 시작하는 RTL 문자열)에만 표시자를 추가합니다.
3. LTR을 기본값으로 가정하고 표시자를 사용하지 않으며 RLM 표시자만 적용합니다.

소비자는 첫 강한 문자 휴리스틱을 적용하여 문자열의 문자열 방향을 감지합니다. RLM 및 LRM 문자는 방향상 강한 유형이므로 적절한 기본 방향이 감지되어야 합니다.

4.1 첫 강한 문자 속성 감지에서 설명한 것처럼 방향 정보가 메타데이터를 통해 제공된다면 이 접근 방식은 관련이 없습니다.

생산자가 표시자를 신뢰성 있게 적용할 수 있다면 기본 방향을 나타내는 신뢰할 수 있는 방법을 제공합니다.

이론적으로 올바른 RLM/LRM이 문자열 앞에 추가되어 있다면 마크업으로 시작하는 문자열에서도 첫 강한 문자를 더 쉽게 찾을 수 있습니다.

생산자가 사람이라면 이론적으로 문자열을 만들 때 이러한 문자 중 하나를 적용하여 방향성을 나타낼 수 있습니다.

특히 모바일 기기에서 중요한 문제는 RLM/LRM 문자를 입력할 수 없거나 입력하기 불편하다는 것입니다. 모바일 기기의 키보드는 일반적으로 RLM/LRM 문자용 키를 제공하지 않습니다. 더 중요한 점은 해당 문자가 보이지 않고 유니코드 양방향 처리가 복잡하므로 사용자가 문자를 효과적으로 사용하는 방법을 알기 어렵다는 것입니다. 실제로 많은 사용자는 이러한 문자가 무엇인지 또는 어떤 역할을 하는지 알지 못합니다.

또한 사용자가 RTL 페이지의 HTML 양식에 정보를 입력하거나 단축키를 사용하여 양식 필드의 방향을 설정하면 RLM/LRM을 추가하지 않아도 문자열이 올바르게 보입니다. 그러나 해당 맥락 밖에서 사용하면 필요한 블록 방향 정보와 연결되지 않는 한 문자열이 잘못 표시됩니다. 마찬가지로 html 요소에 dir=rtl이 설정된 웹 페이지에서 추출한 문자열은 일반적으로 HTML의 문자열 시작 부분에 RLM/LRM 문자가 없으며 필요하지도 않습니다.

생산자가 사용하는 단계에 문자열의 원래 맥락에서 방향 정보를 검사하는 작업을 포함할 수 있습니다. 예를 들어 HTML 양식 필드의 계산된 방향을 검사한 뒤 필요한 경우 문자열 시작 부분에 RLM/LRM 표시자를 자동으로 삽입할 수 있습니다. 이 접근 방식의 문제는 문자열 값과 동일성을 변경한다는 것입니다. 일부 생산자는 표시자를 추가하고 다른 생산자는 추가하지 않는 경우 특히 문자열 길이나 포인터 위치를 처리할 때도 문제가 발생할 수 있습니다.

방향 정보가 소비자가 마크업으로 파싱할 마크업 안에 포함된 경우(예: HTML의 dir=rtl) 문자열 생산자는 RLM/LRM 문자를 적절히 설정하거나 설정하지 않기 위해 해당 마크업을 이해해야 합니다. 생산자가 항상 그러한 문자열 시작 부분에 RLM/LRM을 추가한다면 소비자는 이를 알고 있어야 합니다. 생산자가 마크업이 해석될 것이라고 가정한다면 소비자는 해당 마크업을 이해해야 합니다.

문자열 생산자는 문자열 시작 부분에 RLM이나 LRM을 자동으로 적용해서는 안 되며, 필요한지 검사해야 합니다. 예를 들어 텍스트에 이미 RLM이 있다면 다른 RLM을 추가할 필요가 없습니다. 첫 강한 문자 휴리스틱으로 맥락이 올바르게 전달된다면 추가 문자를 넣을 필요도 없습니다. 그러나 이러한 종류의 보조 방향 정보가 필요한지 검사하려면 생산자가 문자열의 원래 맥락에 접근할 수 있으며 자신이 해당 맥락에 접근할 수 있다는 사실을 알아야 합니다. 많은 문서 형식은 원래 맥락과 떨어져 저장된 데이터에서 생성됩니다. 예를 들어 위의 원래 예제에 있는 책 카탈로그는 양방향 텍스트를 입력한 사용자와 분리되어 있습니다.

생산자는 문자열의 문자열 방향을 확인하고, 문자열 시작 부분에 방향 서식 문자(U+2066 LEFT-TO-RIGHT ISOLATE (LRI), U+2067 RIGHT-TO-LEFT ISOLATE (RLI), U+2068 FIRST STRONG ISOLATE (FSI), U+202A LEFT-TO-RIGHT EMBEDDING (LRE) 또는 U+202B RIGHT-TO-LEFT EMBEDDING (RLE) 중 하나)를 추가하고 끝부분에 U+2069 POP DIRECTIONAL ISOLATE (PDI) 또는 U+202C POP DIRECTIONAL FORMATTING (PDF)을 추가합니다.

가능한 접근 방식은 여러 가지가 있습니다.

1. 모든 문자열에 서식 코드를 추가합니다.
2. 소비자가 첫 강한 문자 감지를 수행하도록 하고, 잘못된 결과를 생성할 문자열(예: LTR 강한 문자로 시작하는 RTL 문자열)에만 표시자를 추가합니다.

이론적으로 소비자는 표시할 위치에 문자열을 삽입하고 서식 코드가 방향성을 관리하도록 하면 됩니다. 그러나 실제로는 그렇게 단순하지 않습니다(아래 참조).

쌍을 이루는 서식 문자에는 두 가지 유형이 있습니다. 기존 제어 문자 집합은 유니코드 양방향 알고리즘에 양방향 "임베딩"의 추가 수준을 넣는 기능을 제공합니다. 이후 유니코드는 이를 보완하는 "격리" 제어 문자 집합을 추가했습니다. 격리 제어 문자는 문자열을 둘러싸는 데 사용됩니다. 문자열 내부는 독립적인 양방향 시퀀스로 취급되며 문자열은 주변 텍스트와 관련된 번짐 효과로부터 보호됩니다. 바깥 문자열은 둘러싸인 전체 문자열을 양방향 재정렬에서 무시되는 단일 단위로 취급합니다. 이 문제는 여기에서 설명합니다.

쌍을 이루는 서식 문자를 사용한다면 RLE 또는 LRE가 아니라 RLI, LRI, FSI로 시작하는 격리 문자를 사용해야 합니다.

이 접근 방식을 사용하는 데 실질적인 장점은 없습니다.

이 접근 방식은 문자열 값을 변경해도 허용되는 경우에만 적절합니다. 문자열 길이나 포인터 위치가 변경되는 문제 외에도 처리 오류나 텍스트 잘림 등으로 쌍을 이루는 문자 중 하나가 유실될 실제적이고 심각한 위험이 있습니다.

문자열의 생산자와 소비자는 서식 문자가 문자열의 일부만 설명하기 때문에 문자열이 쌍을 이루는 서식 문자로 시작하지만 해당 문자로 끝나지 않는 상황을 인식하고 처리해야 합니다.

유니코드는 유효한 임베딩 수에 제한을 지정하며, 임베딩이 시간에 따라 누적되어 해당 제한을 초과할 수 있습니다.

소비 애플리케이션은 격리 서식 문자를 인식하고 적절히 처리해야 합니다. 현재 RLI/LRI/FSI에 대한 이러한 지원은 널리 보급되지 않았습니다.

이 접근 방식을 인식하지 못하는 소비자가 사용할 경우 문자열에 UBA 첫 강한 문자 휴리스틱을 적용할 수 없게 됩니다. 유니코드 양방향 알고리즘은 RLI/LRI/FSI로 시작하고 PDI로 끝나는 문자열의 기본 방향을 확인할 수 없기 때문입니다. 알고리즘이 격리된 시퀀스를 건너뛰고 중립 문자로 취급하기 때문입니다. 문자열의 소비자는 이러한 경우 첫 강한 문자를 찾기 위해 특별한 단계를 수행해야 합니다.

생산자는 문자열에 언어 메타데이터를 제공하고 필요한 경우 사용 중인 문자 체계를 지정합니다.

가능한 접근 방식은 여러 가지가 있습니다.

1. 필요에 따라 문자 체계 하위 태그를 포함하여 모든 문자열에 언어 레이블을 지정합니다. 소비자는 생산자가 문자 체계 하위 태그를 제공하지 않은 경우 이를 계산해야 할 수 있습니다.
2. 문자 체계 하위 태그가 명시적이거나 암시적으로 RTL을 나타내는 언어 태그로 표시되지 않은 모든 문자열에 대해 LTR을 기본값으로 가정하는 것이 합리적일 수 있습니다.
3. 또는 첫 강한 문자 휴리스틱이 실패할 것으로 예상되는 상황으로 문자 체계 하위 태그 메타데이터 사용을 제한할 수 있습니다. 단, 이러한 사례를 식별하고 생산자가 적절한 조치를 취할 수 있어야 하며 이는 항상 신뢰할 수 있는 것은 아닙니다. 소비자는 적절한 문자열 방향을 식별하기 위해 문자 체계 하위 태그가 없을 때 첫 강한 문자 휴리스틱을 사용해야 합니다. 그러나 문자 체계 하위 태그의 사용을 방향을 나타내야 하는 문자열로 제한해서는 안 됩니다. 모든 문자열에 문자 체계 하위 태그를 연결하는 것은 완전히 유효합니다.
4. 더 높은 수준에서 문자열 집합에 기본 언어를 설정하되 필요한 경우 특정 문자열에서 해당 기본값을 재정의할 수 있는 메커니즘을 제공합니다.

소비자는 각 문자열과 연결된 언어 태그에서 문자 체계 하위 태그를 추출하고 필요한 경우 문자열의 문자열 방향을 계산합니다. RTL 문자 체계와 연결된 문자 체계 하위 태그는 연결된 문자열에 RTL 방향을 할당하는 데 사용됩니다.

언어 정보는 [BCP47] 언어 태그를 사용해야 합니다. 정보를 전달하는 언어 태그 부분은 기본 언어 하위 태그가 아니라 문자 체계 하위 태그입니다. 예를 들어 아제르바이잔어는 라틴 문자나 키릴 문자로 LTR로 작성하거나 아랍 문자로 RTL로 작성할 수 있습니다. 따라서 az 하위 태그만으로는 의도된 블록 방향을 명확히 할 수 없습니다. 그러나 az-Arab(아랍 문자로 작성된 아제르바이잔어)과 같은 언어 태그는 일반적으로 블록 방향이 RTL이어야 함을 나타낸다고 신뢰할 수 있습니다.

문자열 자체를 검사하거나 변경할 필요가 없습니다.

이 접근 방식은 첫 번째 강한 문자가 문자열에 필요한 문자열 방향을 나타내지 않을 때 발생하는 첫 강한 문자 감지 문제를 피하고, 마크업 해석과 관련된 문제도 피합니다.

문자열 텍스트 콘텐츠의 언어를 설정하는 마크업(예: <cite lang="zh-Hans">)으로 시작하는 문자열은 여기서 문제가 되지 않습니다. 해당 언어 선언이 문자열 방향 설정에 사용될 것으로 예상되지 않기 때문입니다.

사용할 수 있다면 위에서 설명한 메타데이터 사용이 훨씬 더 나은 접근 방식입니다. 문자 체계와 관련된 이 접근 방식은 레거시상의 이유로 메타데이터 접근 방식을 사용할 수 없는 경우에만 사용합니다.

언어별로 구분되지는 않지만 올바르게 소비하려면 특정 블록 방향과 반드시 연결되어야 하는 문자열이 많습니다. 예를 들어 RTL 맥락에 삽입된 MAC 주소는 전체 기본 방향을 LTR로 표시하고 주변 텍스트와 격리해야 합니다. 이러한 사례를 다른 사례와 구분하는 방법은 명확하지 않습니다. 방향 메타데이터를 사용할 때 실현 가능한 방식이어야 합니다. 이러한 유형의 콘텐츠를 식별하기 위해 zxx(비언어적)와 같은 특수 언어 태그가 있지만, 이러한 유형의 데이터 필드는 언어 정보가 적용되지 않으므로 일반적으로 언어 정보를 완전히 생략합니다.

문자 체계 하위 태그 목록은 이후에 추가될 수 있습니다. 이 경우 기본 RTL 방향을 나타내는 모든 하위 태그를 문자열 소비자가 사용하는 목록에 추가해야 합니다.

적절한 단락 방향을 문자 체계 하위 태그에서 식별할 수 없는 드문 상황이 있지만 이는 실제로 고어 텍스트 사용에만 제한됩니다. 예를 들어 제2차 세계 대전 이전의 일본어와 중국어 텍스트는 LTR이 아니라 RTL로 작성되는 경우가 많았습니다. 이집트 상형문자나 티피나그 베르베르 문자로 작성되는 언어는 과거에 LTR 또는 RTL로 작성할 수 있었지만 학술 연구의 기본값은 LTR인 경향이 있습니다.

여기에서 설명한 접근 방식은 문자열과 연결할 전체 문자열 방향에 관한 정보를 선언할 때만 적절합니다. 사용 패턴이 서로 대체 가능하지 않으므로 문자열 내부의 텍스트 방향을 나타내기 위해 언어 데이터를 사용하는 것은 권장하지 않습니다.

생산자는 모든 문자열이 해당 문자열의 적절한 기본 방향을 나타내는 마크업으로 시작하고 끝나도록 보장합니다. 이를 위해 생산자는 문자열을 검사해야 합니다. 문자열이 방향 정보를 가진 마크업으로 둘러싸여 있지 않다면 생산자는 dir 또는 its:direction [ITS20] 속성을 가진 요소나 특정 XML 애플리케이션에 적절한 다른 마크업으로 문자열을 감싸야 합니다. 문자열이 마크업으로 둘러싸여 있지만 HTML h1 요소와 같은 것이라면 생산자는 문자열을 단순히 span으로 감싸는 대신 기존 마크업에 방향 정보를 추가해야 합니다.

이 예제는 HTML 마크업을 사용합니다. 예제를 더 쉽게 읽을 수 있도록 문자가 저장되는 순서가 아니라 표시되어야 하는 순서로 문자열의 텍스트 콘텐츠를 보여 줍니다.

그런 다음 소비자는 문자열이 표시될 때 마크업이 문자열의 텍스트 콘텐츠 주변에 기본 방향을 설정하도록 합니다. 추가 메타데이터가 제공되지 않는 한 소비자는 문자열을 대상 위치에 통합하기 전에 마크업을 제거할 수 없습니다. 생산자가 추가한 마크업과 원래 존재하던 마크업을 구분할 수 없기 때문입니다. 그러나 일반적으로 이러한 추가 마크업은 해롭지 않습니다.

이미 마크업을 사용하는 콘텐츠에 대한 이점은 명확합니다. 콘텐츠가 텍스트의 표시 및 처리에 필요한 완전한 마크업을 이미 제공하거나 출처 페이지의 맥락에서 이를 추출할 수 있습니다. HTML 및 XML 처리기는 이미 이러한 마크업을 처리하는 방법을 알고 있으며 즉시 검증할 수 있습니다.

HTML에서 dir 속성은 콘텐츠를 주변 텍스트와 양방향으로 격리하여 번짐 충돌을 제거합니다. 이는 소비자의 작업을 줄여 줍니다.

마크업은 문자열 자체의 문자열 방향만으로 해결할 수 없는 문자열 내부의 방향 정보에도 사용할 수 있습니다.

이는 앞에서 설명한 문자열과 함께 메타데이터를 전송하는 개념과 비슷합니다. 그러나 메타데이터는 4.2 메타데이터처럼 완전히 별개의 필드에 저장되거나 4.3 RLM/LRM 표시자를 삽입하여 첫 강한 문자 보완하기처럼 문자열 자체에 삽입되는 것이 아니라 문자열 직렬화 형식의 일부로 문자열과 연결됩니다.

[RDF-PLAIN-LITERAL]과 같이 문자열 값의 일부로 언어 메타데이터를 직렬화할 수 있는 데이터 유형이 이미 존재합니다. 그러나 이러한 데이터 유형은 방향을 고려하지 않습니다. 문서 형식이 언어와 방향 메타데이터를 모두 포함하는 자연어 문자열을 직렬화하는 데 사용할 수 있는 새로운 데이터 유형을 정의하거나 기존 데이터 유형을 확장하여 이를 해결할 수 있습니다.

[JSON-LD] 1.1에서는 JSON 문서가 문자열 값과 함께 언어 및 방향 메타데이터를 직접 직렬화할 수 있도록 i18n 네임스페이스를 추가했습니다. 필요한 명세를 위해 RDF로 역직렬화하는 방법도 제공합니다.

마지막 문자열은 내부 데이터 값이므로 언어 정보를 포함하지 않지만, 이러한 종류의 문자열은 LTR 순서로 표시되어야 하므로 방향 정보는 포함합니다.

생산자는 필요에 따라 각 문자열에 문자열 방향을 연결해야 합니다.

각 소비자는 이 접근 방식을 사용하지 않거나 문자열 방향을 포함하지 않는 문자열에 첫 강한 문자 휴리스틱을 사용해야 합니다. 그러면 생산자는 첫 강한 문자 접근 방식이 잘못된 결과를 생성하는 경우에만 문자열 방향 정보를 추가하면 됩니다. 메타데이터가 필요한 문자열의 수가 상대적으로 적으므로 문자열 관리와 전송할 데이터 양이 간소화될 수 있습니다.

소비자는 문자열에 메타데이터가 연결되어 있는지 확인하고, 연결되어 있다면 표시된 문자열 방향을 설정합니다. 그렇지 않다면 첫 강한 문자 휴리스틱을 사용하여 문자열의 문자열 방향을 결정합니다.

자연어 문자열을 지원하기 위한 새로운 데이터 유형이 JSON에 추가된다면 명세는 해당 유형을 문서 형식에서 사용하도록 쉽게 지정할 수 있습니다. 형식이 표준화되어 있으므로 생산자와 소비자는 인코딩된 방향 또는 언어 정보를 추측할 필요가 없습니다.

현재 이 방법이 작동하지 않는다는 사실 외에도 데이터 유형을 추가할 때의 단점은 JSON이 임시 구현을 포함하여 널리 구현된 형식이라는 점입니다. 새로운 직렬화 형식은 이러한 기존 구현을 중단시키거나 상호 운용성 문제를 일으킬 가능성이 높습니다. JSON은 "버전이 지정되는" 형식으로 설계되지 않았습니다. 사용하는 모든 직렬화 형식은 기존 JSON 처리기에 투명해야 하므로 기존 문자열과 형식에 원치 않는 데이터가 추가되거나 데이터가 손상될 수 있습니다.

생산자는 문자열의 언어를 확인하고(일반적으로 상위 단계에서 제공된 메타데이터에서 확인함), 문자열이 저장되거나 전송될 때 함께 전달되는 메타데이터 필드에 이 정보를 포함합니다.

한 번에 문자열 집합을 저장하거나 전송할 때는 리소스의 모든 문자열이 상속할 수 있는 언어를 설정하는 리소스 전체 필드가 있으면 유용합니다. 전역 필드 외에도 문자열의 언어가 기본값과 다른 경우 문자열별 메타데이터 필드를 연결할 수 있어야 한다는 점에 유의하십시오. 개별 문자열에 설정된 언어는 모든 리소스 수준 값보다 우선해야 합니다.

소비자는 문자열과 연결된 메타데이터를 읽고 이를 자신이 생성하는 표시, 처리 또는 데이터 구조에 적용하는 방법을 이해해야 합니다. 여기에는 개별 값을 직렬화하거나 교환할 때 리소스 수준 기본 언어를 적용해야 하는 경우도 포함될 수 있습니다.

일관되고 명확하게 정의된 데이터 구조를 사용하면 서로 다른 표준을 조합할 수 있고 원활하게 함께 작동할 가능성이 높아집니다.

콘텐츠 자체에 영향을 주지 않고 메타데이터를 제공할 수 있습니다.

메타데이터를 사용할 수 없는 경우 생략할 수 있습니다.

소비자와 생산자는 일반적인 처리 범위를 벗어나 데이터를 내부적으로 검사할 필요가 없습니다.

딕셔너리와 그 데이터 값을 사용하는 직렬화된 파일에는 추가 필드가 포함되므로 읽기가 더 어려워질 수 있습니다.

기존 문서 형식에서는 교환되는 값의 변경을 의미합니다.

문서가 HTML 또는 XML 조각으로 구성될 것으로 예상되고 마크업 맥락에서만 처리되고 표시되는 경우, 생산자는 lang 또는 xml:lang 속성이 있는 요소로 문자열을 감싸 콘텐츠의 언어를 마크업으로 전달할 수 있습니다.

이 접근 방식과 그 장점은 실질적으로 이 절에서 설명한 것과 동일합니다.

생산자는 문자열에 언어 태그를 지정하기 위해 데이터에 유니코드 태그 문자를 삽입합니다.

소비자는 유니코드 태그 문자를 처리하고 이를 사용하여 언어를 할당합니다.

유니코드는 언어 태그로 사용할 수 있는 특수 문자를 정의합니다. 이러한 문자는 "기본적으로 무시 가능"하며 시각적으로 나타나지 않아야 합니다. 유니코드 태그는 다음과 같이 작동하도록 되어 있습니다.

각 태그는 문자 시퀀스입니다. 시퀀스는 태그 식별 문자로 시작합니다. 현재 정의된 유일한 문자는 U+E0001이며, 이는 [BCP47] 언어 태그를 식별합니다. 비공개 규약을 통해 다른 유형의 태그도 사용할 수 있습니다. 태그를 구성하기 위한 유니코드 블록의 나머지 부분은 출력 가능한 ASCII 문자를 대응시킵니다. 즉, U+E0020은 공백 (U+0020에 대응), U+E0041은 대문자 A (U+0041에 대응)이며, 나머지도 같은 방식입니다. 태그 식별 문자 뒤에서 생산자는 각 태그 문자를 사용하여 대문자와 소문자, 숫자 및 하이픈 문자로 [BCP47] 언어 태그를 작성합니다. ASCII 문자, 숫자 및 하이픈으로 구성된 특정 원본 언어 태그는 각 문자의 코드 포인트에 0xE0000을 더하여 태그로 변환할 수 있습니다. 언어 우선순위 목록과 같은 추가 구조([RFC4647] 참조)는 쉼표나 세미콜론 같은 다른 문자를 사용하여 구성할 수 있지만, 유니코드는 이를 정의하거나 반드시 허용하지는 않습니다.

태그의 적용 범위 끝은 문자열의 끝으로 나타내거나, 취소 태그 문자 U+E007F를 단독으로 사용하여 모든 태그를 취소하거나 언어 태그 식별 문자 U+E0001 앞에 배치하여 명시적으로 나타낼 수 있습니다. 즉, 언어 태그만 끝내려면 <U+E0001,U+E007F> 시퀀스를 사용합니다.

따라서 태그는 최소 세 개의 문자로 구성되며 쉽게 12개 이상의 문자가 될 수 있습니다. 또한 이러한 문자는 보충 문자입니다. 즉, UTF-8에서는 문자마다 4바이트를 사용하여 인코딩되고, UTF-16에서는 서로게이트 쌍(두 개의 16비트 코드 단위)으로 인코딩됩니다. 내부적으로 UTF-16을 사용하는 Java 및 JavaScript와 같은 언어의 문자열 유형에서 이러한 문자를 인코딩하려면 서로게이트 쌍이 필요합니다. 서로게이트를 사용하면 문자열을 다소 이해하기 어렵게 만듭니다. 예를 들어 U+E0020은 UTF-16에서 0xDB40.DC20으로, UTF-8에서는 바이트 시퀀스 0xF3.A0.80.A0으로 인코딩됩니다.

이러한 언어 태그 문자는 문서 형식의 구조를 변경하지 않고 일반 유니코드 텍스트의 일부로 사용할 수 있습니다.

언어 식별을 위한 유니코드 태그 문자의 사용은 유니코드 컨소시엄에서 강하게 권장하지 않으며 따라서 폐기되었습니다. 이러한 태그 문자는 일반 텍스트 맥락에서 언어 태그를 지정하기 위해 고안되었으며, 대역 내 비마크업 언어 태그를 제공하는 대체 방법으로 자주 제안됩니다. 이를 언어 태그로 사용하는 구현은 알려져 있지 않습니다.

이 문자를 알 수 없는 유니코드 문자로 취급하는 애플리케이션은 이를 두부 문자 (속이 빈 사각형 대체 문자)로 표시하고 길이 제한 등에 포함할 수 있습니다. 따라서 애플리케이션이나 교환 메커니즘이 이 문자를 완전히 인식하고 적절하게 제거하거나 무시할 수 있을 때만 유용합니다. 이 문자는 표시되거나 텍스트 처리에 영향을 주어서는 안 되지만 실제로는 잘림, 줄 바꿈, 하이픈 넣기, 맞춤법 검사 등의 일반적인 텍스트 처리를 방해할 수 있습니다.

설계상 [BCP47] 언어 태그는 ASCII 대소문자를 구분하지 않도록 되어 있습니다. 유니코드 태그 문자를 처리하는 애플리케이션은 언어를 올바르게 식별하기 위해 유사한 대소문자 비구분 처리를 적용해야 합니다. 유니코드 데이터에는 이러한 문자에 대한 대소문자 변환 쌍이 지정되어 있지 않으므로 태그 문자로 인코딩된 언어 태그 값을 처리하고 일치시키는 작업이 복잡해집니다.

또한 언어 태그가 [BCP47]을 준수하려면 유효한 하위 태그로 구성되어야 합니다. 유효한 하위 태그는 IANA 레지스트리에 유지되며 새로운 하위 태그가 정기적으로 추가되므로 이러한 종류의 태그를 처리하는 애플리케이션은 각 하위 태그를 항상 최신 버전의 레지스트리와 대조해야 합니다.

언어 태그 문자는 언어 태그의 중첩을 허용하지 않습니다. 예를 들어 영어 문장 안에 프랑스어 인용문이 있는 것처럼 문자열에 두 언어가 포함되어 있다면 유니코드 태그 문자는 한 언어가 시작되는 위치만 나타낼 수 있습니다. 중첩된 언어를 나타내려면 태그를 문자열 앞에만 추가하는 것이 아니라 텍스트 내부에도 삽입해야 합니다.

구현된 적은 없지만 유니코드 태그 문자를 사용하여 다른 유형의 태그를 문자열이나 문서에 삽입할 수도 있습니다. 이러한 태그는 언어 태그가 지정된 텍스트 구간과 겹칠 수 있습니다.

마지막으로 유니코드는 최근 스코틀랜드 국기(🏴)와 같은 하위 지역 국기를 구성하는 데 이러한 문자를 다시 사용했습니다. 이 국기는 다음 시퀀스로 구성됩니다.

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

생산자는 아무 작업도 하지 않습니다.

소비자는 텍스트의 언어를 결정하기 위해 언어 감지 알고리즘을 실행합니다. 일반적으로 언어의 n-그램 빈도를 사용하고 다른 데이터와 결합할 수도 있는 통계 기반 휴리스틱입니다.

이 접근 방식에는 근본적인 장점이 없습니다.

검사하는 텍스트가 길고 해당 언어를 잘 대표할수록 휴리스틱의 정확도가 높아집니다. 짧은 문자열은 제대로 감지되지 않을 수 있습니다.

언어 감지는 감지기가 존재하는 언어로 제한됩니다.

다른 언어나 문자 체계로 된 사람 이름이나 브랜드 이름 같은 삽입 요소는 감지를 방해할 수 있습니다.

언어 감지는 느린 경향이 있고 많은 메모리를 사용할 수 있습니다. 단순한 소비자는 언어를 결정하는 데 필요한 복잡성을 감당하기 어려울 수 있습니다.