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

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

문자열이 생성될 때에는 (a) 문자열과 연결할 적절한 언어 및 문자열 방향을 감지하거나 포착하고, (b) 필요한 경우 언어와 문자열 방향을 저장하고 전달하는 방식으로 문자열을 설정하기 위한 조치를 취해야 합니다.

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

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

문자열의 생산자가 다른 생산자가 저장해 둔 위치에서 문자열을 수신하고, 그곳에서 문자열 방향과 언어가 이미 확립된 경우, 생산자는 언어와 문자열 방향이 이미 설정되어 있음을 이해하고, 그 정보를 자신의 소비자를 위해 어떻게 변환하거나 인코딩할지 이해해야 합니다.

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

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

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

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

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

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

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

구문적 콘텐츠 항목이나 사용자 제공 값의 값은 흔히 (예를 들어 디버깅을 돕기 위해) 사람에게 의미를 전달하는 단어 같은 토큰을 사용하지만, 사용자에게 표시할 때에는 그 값들을 일관되게 지역화 가능한 표시 문자열로 감싸야 합니다.

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

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

블록 방향을 나타내기 위해 메타데이터를 사용하는 것이 선호됩니다. 이는 소비자가 첫 강한 문자와 같은 방법을 사용해 방향을 보간하거나, 데이터 자체의 변경을 요구하는 방법(예: RLM/LRM 마커 삽입 또는 양방향 제어 문자)을 사용할 필요를 피하게 해 주기 때문입니다.

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

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

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

명세가 자체 문서 수준 기본값을 정의하는 경우, 두 개의 선택적 필드를 제공하십시오.

기본값의 예외는 언제나 가능하므로, 사용자가 문자열별로 기본값을 재정의할 수 있어야 합니다.

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

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

세계는 단일 언어가 아닙니다. 단 하나의 언어만 포함하는 문서를 갖는다는 것은 콘텐츠를 지역화하기 위해 언어마다 문서를 여러 번 제공해야 함을 의미합니다. 이는 콘텐츠를 요청할 때 언어 협상을 필요로 할 수도 있습니다.

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

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

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

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

소비자는 문자열에서 강한 Unicode 방향 속성을 가진 첫 번째 문자를 찾아야 하며, 문자열 방향을 그것과 일치하도록 설정해야 합니다. 그런 다음 문자열이 필요한 대로 표시되도록 적절한 조치를 취합니다. 이는 다음과 같은 이유로 보이는 것만큼 단순하지 않습니다.

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

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

그러나 메타데이터를 적용할 메커니즘이 없거나, 그러한 메커니즘이 있지만 콘텐츠 개발자가 그것을 사용하지 않았다면, 첫 강한 문자 휴리스틱은 모든 경우는 아니더라도 많은 경우에 기본 방향을 확립하는 데 도움이 될 수 있습니다. 강한 방향성을 가진 서식 문자를 적용하면 방금 인용한 예와 같은 평문 문자열에서 올바른 결과를 얻는 데 도움이 될 수 있지만, 이러한 문자를 적용하는 것이 항상 가능한 것은 아닙니다(4.3 RLM/LRM 마커를 삽입하여 first-strong 보강하기 참조).

신뢰할 수 있는 경우에는, 문자열을 변경하지 않고도, 대역 외 메타데이터를 지원하는 데 필요한 합의와 구조 없이도 방향에 관한 정보를 얻을 수 있습니다.

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

1. 문자열 전체에 필요한 방향성과 다른 방향성을 가진 강한 문자로 시작하는 문자열 (예: 해시태그로 시작하는 아랍어 트윗)
2. 강한 방향성 문자가 없는 문자열(예: 전화번호)로, RTL 맥락에서 잘못 표시될 가능성이 있는 문자열.
3. span과 같은 마크업으로 시작하는 문자열. 이 경우 첫 번째 강한 문자는 항상 LTR이 됩니다.

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

문자열에서 강한 방향성 문자를 찾지 못한 경우, 방향은 아마도 LTR로 가정되어야 하며 소비자는 이를 기준으로 동작해야 합니다. 그러나 이는 아직 충분히 테스트되지 않았습니다.

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

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

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

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

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

메타데이터를 사용하는 데에는 여러 접근 방식이 있습니다.

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

한 번에 문자열 집합을 저장하거나 전송하는 경우, 리소스 전체에 대해 전역 기본 문자열 방향을 설정하는 필드가 있으면 도움이 되며, 이 값은 리소스의 모든 문자열에 상속될 수 있습니다. 전역 필드에 더하여, 문자열의 문자열 방향이 기본값과 같지 않은 경우에는 문자열별 메타데이터 필드를 첨부할 수 있는 가능성이 여전히 필요하다는 점에 유의하십시오. 개별 문자열에 설정된 문자열 방향은 항상 기본값보다 우선해야 합니다.

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

JSON 기반 문서 형식의 개별 값에는 Localizable dictionary 구조의 사용이 RECOMMENDED됩니다. 이는 언어와 방향 메타데이터를 모두 결합하며, 일관되게 채택되면 서로 다른 형식 간의 교환을 더 쉽게 만들기 때문입니다.

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

모든 문자열에 방향 레이블이 붙어 있거나, 전역 설정과 문자열별 차이를 적용하여 모든 문자열의 방향을 확인할 수 있다면, 각 개별 문자열의 문자열 방향을 결정하기 위해 검사하고 휴리스틱을 실행할 필요를 피할 수 있습니다.

대역 외 정보는 문자열과 연결되고 문자열과 함께 유지되어야 합니다. 이는 정의된 프레임워크의 일부가 아닌 일부 문자열 데이터 집합에서는 문제가 될 수 있습니다.

특히 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 문자를 위한 키를 제공하지 않습니다. 아마도 더 중요한 점은, 문자가 보이지 않고 Unicode bidi가 복잡하기 때문에 사용자가 그 문자를 효과적으로 사용하는 방법을 알기 어려울 수 있다는 것입니다. 실제로 많은 사용자는 이러한 문자가 무엇인지 또는 무엇을 하는지 알지 못합니다.

더 나아가, 사람이 RTL 페이지의 HTML 양식에 정보를 입력하거나 단축키를 사용하여 양식 필드의 방향을 설정하면, 문자열은 RLM/LRM을 추가할 필요 없이 올바르게 보입니다. 그러나 그 맥락 밖에서 사용되면, 필요한 블록 방향에 관한 정보와 연결되어 있지 않은 한 문자열은 잘못 보일 것입니다. 마찬가지로, html 요소에 dir=rtl이 설정된 웹 페이지에서 스크랩한 문자열은 HTML 안에서는 보통 문자열 시작 부분에 RLM/LRM 문자를 갖고 있거나 필요로 하지 않습니다.

생산자가 사용하는 단계에 문자열의 원래 맥락에서 방향 정보를 검사하는 것(예: HTML 양식 필드의 계산된 방향을 테스트하는 것)을 포함한 다음, 필요한 경우 문자열 시작 부분에 RLM/LRM 마크를 자동으로 삽입하는 것이 가능할 수 있습니다. 이 접근 방식의 문제는 문자열 값과 식별성을 변경한다는 것입니다. 이는 특히 일부 생산자는 마커를 추가하고 다른 생산자는 추가하지 않는 경우, 문자열 길이나 포인터 위치를 다루는 데에도 문제를 일으킬 수 있습니다.

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

문자열의 생산자는 문자열 시작 부분에 RLM 또는 LRM을 자동으로 적용해서는 안 되며, 그것이 필요한지 테스트해야 합니다. 예를 들어, 텍스트 안에 이미 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 문자열)에만 마커를 추가합니다.

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

쌍을 이루는 서식 문자는 두 종류가 있습니다. 원래의 제어 문자 집합은 Unicode 양방향 알고리즘에 양방향 “embedding”의 추가 수준을 더할 수 있는 기능을 제공합니다. 더 최근에 Unicode는 보완적인 “isolating” 제어 문자 집합을 추가했습니다. 격리 제어 문자는 문자열을 둘러싸는 데 사용됩니다. 문자열 내부는 자체 양방향 시퀀스로 취급되며, 문자열은 주변 텍스트와 관련된 넘침 효과로부터 보호됩니다. 둘러싸는 문자열은 둘러싸인 문자열 전체를 bidi 재정렬에서 무시되는 하나의 단위로 취급합니다. 이 문제는 여기에 설명되어 있습니다.

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

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

이 접근 방식은 문자열의 값을 변경하는 것이 허용되는 경우에만 적절합니다. 문자열 길이나 포인터 위치가 변경되는 것과 같은 가능한 문제에 더해, 이 접근 방식은 처리 오류나 텍스트 잘림 등을 통해 쌍을 이루는 문자 중 하나가 손실될 실제적이고 심각한 위험을 안고 있습니다.

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

Unicode는 유효한 embedding 수에 제한을 지정하며, embedding은 시간이 지나면서 누적되어 그 제한을 초과할 수 있습니다.

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

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

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

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

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

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

언어 정보는 [BCP47] 언어 태그를 사용해야 MUST 합니다. 정보를 담는 언어 태그의 부분은 주 언어 하위 태그가 아니라 문자 하위 태그입니다. 예를 들어, Azeri는 LTR(라틴 문자 또는 키릴 문자) 또는 RTL(아랍 문자)로 쓰일 수 있습니다. 따라서 하위 태그 az만으로는 의도된 블록 방향을 명확히 하기에 충분하지 않습니다. 그러나 az-Arab(아랍 문자로 쓰인 Azeri)와 같은 언어 태그는 일반적으로 블록 방향이 RTL이어야 함을 나타내는 것으로 신뢰할 수 있습니다.

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

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

문자열 텍스트 콘텐츠의 언어를 설정하는 마크업(예: <cite lang="zh-Hans">)으로 시작하는 문자열은 여기에서 문제가 되지 않는다는 점에 유의하십시오. 그 언어 선언은 문자열 방향 설정에 관여할 것으로 기대되지 않기 때문입니다.

위에서 개요를 제시한 메타데이터의 사용은 가능하다면 훨씬 더 나은 접근 방식입니다. 이 문자 관련 접근 방식은 레거시 이유로 그 접근 방식을 사용할 수 없는 경우에만 사용하기 위한 것입니다.

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

문자 하위 태그 목록은 앞으로 추가될 수 있습니다. 이 경우 기본 RTL 방향을 나타내는 모든 하위 태그는 문자열의 소비자가 사용하는 목록에 추가되어야 합니다.

적절한 단락 방향을 문자 하위 태그로부터 식별할 수 없는 드문 상황도 일부 있지만, 이는 실제로는 텍스트의 고어적 사용에 제한됩니다. 예를 들어, 제2차 세계대전 이전의 일본어와 중국어 텍스트는 종종 LTR이 아니라 RTL로 쓰였습니다. 이집트 상형문자나 Tifinagh Berber 문자로 쓰인 언어와 같은 경우에는 이전에 LTR 또는 RTL 중 어느 방향으로도 쓰일 수 있었지만, 학술 연구의 기본값은 LTR인 경향이 있습니다.

여기서 개요를 제시한 접근 방식은 문자열과 연결될 전체 문자열 방향에 관한 정보를 선언할 때에만 적절합니다. 문자열 내부의 텍스트 방향을 나타내기 위해 언어 데이터를 사용하는 것은 권장하지 않습니다. 사용 패턴이 서로 호환되지 않기 때문입니다.

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

이 예는 HTML 마크업을 사용합니다. (단순히 예를 읽기 쉽게 만들기 위해, 문자가 저장된 순서가 아니라 문자열의 텍스트 콘텐츠가 표시되어야 하는 방식으로 표시합니다.)

그런 다음 소비자는 문자열이 표시될 때 그 텍스트 콘텐츠 주위의 기본 방향을 설정하기 위해 마크업에 의존합니다. (추가 메타데이터가 제공되지 않는 한, 소비자는 문자열을 대상 위치에 통합하기 전에 마크업을 제거할 수 없다는 점에 유의하십시오. 무엇이 생산자가 추가한 마크업이고 무엇이 이미 있던 것인지 알 수 없기 때문입니다. 그러나 일반적으로 그러한 추가 마크업은 해롭지 않습니다.)

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

HTML의 경우, dir 속성은 콘텐츠를 주변 텍스트로부터 양방향으로 격리하여 넘침 충돌을 제거합니다. 이는 소비자의 작업을 줄여 줍니다.

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

이는 앞서 논의한 문자열과 함께 메타데이터를 전송하는 생각과 유사하지만, 메타데이터가 (4.2 메타데이터에서처럼) 완전히 별개의 필드에 저장되거나, (4.3 RLM/LRM 마커를 삽입하여 first-strong 보강하기에서처럼) 문자열 자체에 삽입되는 것이 아니라, 문자열의 직렬화 형식의 일부로 문자열과 연결됩니다.

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

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

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

생산자는 필요에 따라 각 문자열에 문자열 방향을 첨부해야 할 것입니다.

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

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

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

이것이 현재 작동하지 않는다는 사실을 제외하면, 데이터 타입을 추가하는 것의 단점은 JSON이 많은 임시 구현을 포함하여 널리 구현된 형식이라는 점입니다. 새로운 직렬화 형식은 이러한 기존 구현을 깨뜨리거나 상호운용성 문제를 일으킬 가능성이 큽니다. JSON은 “버전이 있는” 형식으로 설계되지 않았습니다. 사용되는 모든 직렬화 형식은 기존 JSON 프로세서에 투명해야 하며, 따라서 기존 문자열과 형식에 원치 않는 데이터나 데이터 손상을 도입할 수 있습니다.

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

한 번에 문자열 집합을 저장하거나 전송할 때에는, 리소스 전체에 대해 리소스 안의 모든 문자열이 상속할 수 있는 언어를 설정하는 필드가 있으면 도움이 됩니다. 전역 필드에 더하여, 문자열의 언어가 기본값의 언어와 다른 경우에는 문자열별 메타데이터 필드를 첨부할 수 있는 가능성이 여전히 필요하다는 점에 유의하십시오. 개별 문자열에 설정된 언어는 모든 리소스 수준 값을 재정의해야 합니다.

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

일관되고 잘 정의된 데이터 구조를 사용하면 서로 다른 표준들이 조합 가능하고 매끄럽게 함께 동작할 가능성이 더 높아집니다.

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

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

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

dictionary와 그 데이터 값을 사용하는 직렬화된 파일은 추가 필드를 포함하게 되며, 그 결과 읽기가 더 어려워질 수 있습니다.

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

문서가 HTML 또는 XML 조각으로 구성될 것으로 기대되고 엄격하게 마크업 맥락에서 처리 및 표시될 경우, 생산자는 lang 또는 xml:lang 속성을 가진 요소로 문자열을 감싸 콘텐츠의 언어를 전달하는 데 마크업을 사용할 수 있습니다.

이 접근 방식과 그 장점은 사실상 이 절의 경우와 같습니다.

생산자는 문자열에 언어를 태그하기 위해 데이터 안에 Unicode 태그 문자를 삽입합니다.

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

Unicode는 언어 태그로 사용할 수 있는 특수 문자를 정의합니다. 이러한 문자는 “기본적으로 무시 가능”하며 시각적 모양을 가져서는 안 됩니다. Unicode 태그가 작동해야 하는 방식은 다음과 같습니다.

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

태그 범위의 끝은 문자열의 끝으로 신호되거나, 취소 태그 문자 U+E007F를 단독으로 사용하여 (모든 태그를 취소하기 위해) 또는 언어 태그 식별 문자 U+E0001 앞에 두어 (즉, 언어 태그만 끝내기 위한 시퀀스 <U+E0001,U+E007F>) 명시적으로 신호될 수 있습니다.

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

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

언어 식별을 위해 Unicode 태그 문자를 사용하는 것은 Unicode Consortium에서 강하게 권장하지 않습니다(따라서 폐기되었습니다). 이러한 태그 문자는 평문 텍스트 맥락에서 언어 태깅에 사용하기 위해 의도되었으며, 대역 내 비마크업 언어 태깅을 제공하는 대체 수단으로 종종 제안됩니다. 우리는 이들을 언어 태그로 사용하는 구현을 알지 못합니다.

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

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

더 나아가, 언어 태그는 [BCP47]를 준수하기 위해 유효한 하위 태그로 형성되어야 합니다. 유효한 하위 태그는 IANA 레지스트리에 보관되며 새 하위 태그가 정기적으로 추가되므로, 이러한 종류의 태깅을 다루는 애플리케이션은 각 하위 태그를 항상 최신 버전의 레지스트리와 대조해 확인해야 할 것입니다.

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

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

마지막으로, Unicode는 최근 이러한 문자를 스코틀랜드 국기(🏴)와 같은 하위 지역 깃발을 형성하는 데 사용하도록 “재활용”했습니다. 이는 다음 시퀀스로 만들어집니다.

• 🏴 [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-gram 빈도를 사용하는 것과 같은 통계 기반 휴리스틱이며, 다른 데이터와 결합될 수도 있습니다.

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

휴리스틱은 스캔되는 텍스트가 길고 대표성이 있을수록 더 정확합니다. 짧은 문자열은 잘 감지되지 않을 수 있습니다.

언어 감지는 감지기를 보유한 언어로 제한됩니다.

다른 언어나 문자로 된 개인 이름 또는 브랜드 이름과 같은 포함 요소는 감지를 어긋나게 할 수 있습니다.

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