사양 개발자를 위한 국제화 모범 사례
이 문서에 대한 자세한 정보
Copyright © 2014-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Copyright © 2014-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
이 문서는 사양을 개발할 때 국제화와 관련해 고려해야 할 사항의 체크리스트를 제공합니다. 대부분의 체크리스트 항목은 다른 문서의 자세한 지원 정보로 연결됩니다. 그러한 정보가 아직 존재하지 않는 경우, 이 문서에 임시로 둘 수 있습니다. 이 문서의 정보는 새 콘텐츠가 추가되고 경험과 논의를 바탕으로 기존 콘텐츠가 수정됨에 따라 정기적으로 변경됩니다.
이 섹션은 발행 시점의 이 문서의 상태를 설명합니다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정본은 W3C 표준 및 초안 색인에서 찾을 수 있습니다.
이 문서는 사양 개발자에게 국제적 사용을 위한 요구 사항을 통합하는 방법에 대한 조언을 제공합니다. 현재 여기에서 제공되는 내용은 즉시 유용할 것으로 기대되지만, 아직 초기 초안이며 문서는 유동적이고, 검토와 논의에서 적용된 지식이 지침으로 구체화됨에 따라 시간이 지나며 확장될 것입니다.
이 문서는 국제화 워킹 그룹이 노트 트랙을 사용하여 그룹 노트로 발행했습니다.
이 그룹 노트는 국제화 워킹 그룹의 승인을 받았지만, W3C 자체나 그 회원들의 승인을 받은 것은 아닙니다.
W3C 특허 정책은 이 문서에 대해 어떠한 라이선스 요구 사항이나 약속도 부과하지 않습니다.
이 문서는 2023년 11월 03일 W3C 프로세스 문서의 적용을 받습니다.
사양 개발자는 자신이 만드는 것이 전 세계 커뮤니티에서 제대로 작동하도록 하기 위한 조언이 필요합니다.
국제화(Internationalization, i18n) WG는 사양을 검토하고 논의에 참여함으로써 워킹 그룹을 지원하려고 노력합니다. 그러나 이러한 개입은 종종 이상적인 시점보다 늦게 이루어지거나, i18n WG가 상호작용하는 각 워킹 그룹마다 같은 정보를 반복해야 함을 의미합니다.
사양 개발자가 모범 사례 체크리스트에 접근할 수 있고, 개발자에게 필요할 때 설명, 예제 및 근거를 가리킬 수 있다면 더 좋을 것입니다. 그러면 개발자는 가장 이른 단계부터 이러한 지식을 작업에 반영할 수 있고, i18n WG가 사양을 검토할 때 필요한 재작업을 줄일 수 있습니다.
이 문서는 체크리스트의 시작 부분을 포함하며, 제시된 권고 사항에 대한 설명, 예제 및 근거를 찾을 수 있는 위치를 가리킵니다. 그러한 다른 위치가 없다면, 해당 추가 정보는 이 문서에 추가됩니다. 또한 아이디어를 발전시키고 정리하는 데 사용될 수도 있습니다.
이 문서의 지침은 엄격하고 고정된 요구 사항이 되도록 의도된 것이 아닙니다. 이 문서는, 여러분이 지침을 이해하지 못하거나 이에 동의하지 않는 경우 국제화 WG에 연락하여 무엇을 해야 하는지 논의하게 된다면, 그 목적의 상당 부분을 달성한 것입니다.
이 문서에서 자연어라는 용어는 일반적으로 사람이 소비하도록 의도된 문서나 프로토콜의 부분을 가리키는 데 사용됩니다. 지역화 가능한 텍스트라는 용어는 형식 언어, 프로토콜 구문 등의 자연어 콘텐츠를 가리키는 데 사용되며, 구문 콘텐츠 또는 사용자 제공 값과 구별됩니다. 국제화 워킹 그룹에서 사용하는 이러한 용어와 기타 용어의 정의는 [I18N-GLOSSARY]를 참조하십시오.
국제화 측면에서 여러분의 사양을 검토하는 데 도움이 되도록 이 페이지에는 체크리스트 기능이 제공됩니다. 검토 결과는 GitHub 이슈에 게시해야 합니다.
여러분의 사양과 관련된 각 섹션에 대해 다음 단계를 따르십시오:
국제화 고려 사항 섹션에 대한 모든 추가 또는 변경은 국제화(i18n) WG의 검토를 반드시 받아야 합니다.
국제화 고려 사항 섹션을 만드는 경우, 그 제목은 Internationalization Considerations 또는 Internationalization (i18n) Considerations이어야 합니다.
사양은 해당 사양의 국제화 고려 사항을 설명하는 특별한 섹션이나 부록을 포함할 필요가 없습니다. 일반적으로 국제화 WG는 그 대신 언어, 지역 또는 문화적 변이, 지원 또는 적응에 관한 정보가 관련 기능과 밀접하게 연결되어 사양 본문에 나타나는 것을 선호합니다.
그러나 이와 같은 섹션을 제공하는 것을 고려할 수 있는 몇 가지 경우가 있습니다. 다음과 같은 경우 국제화 고려 사항 섹션을 포함하는 것을 고려하십시오:
국제화 고려 사항 섹션을 만들기로 결정했다면, 일반적으로 이는 부록이 됩니다. 그러나 사양의 다른 부분이나 다른 부록과 관련된 순서와 배치는 여러분에게 달려 있습니다.
국제화 고려 사항 섹션을 만들기로 결정했다면, 국제화 WG에 보내는 수평 검토 요청에서 이를 언급해야 합니다. 검토 요청 템플릿에는 이를 쉽게 수행할 수 있도록 하는 체크박스가 포함되어 있습니다.
이것은 이 섹션의 요구 사항만을 나열한 목록이며, 자체 검토에 사용할 수 있습니다. 여러분의 사양과 관련된 모든 요구 사항에 대해 한 줄의 첫 번째 체크박스를 선택하십시오. 여러분의 사양이 그 요구 사항을 충족하는 경우 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
언어 기본 사항
lang 및 XML xml:lang
언어 속성을 사용하십시오. 더 보기
lang 및
XML xml:lang 언어 속성을 사용해서는 안 되며,
메타데이터(특정 텍스트 범위의 언어가 아니라 리소스의 의도된 사용을 나타내는 것)를
나타낼 때는 다른 속성을 사용해야 합니다. 더 보기언어 값 정의하기
언어 선언하기
문자열의 언어 식별하기
zxx ("No
linguistic content")를 각 문자열 값과 연결할 것을 권장해야 합니다. 더 보기
und ("Undetermined")를 각 문자열과 연결할 것을
권장해야 합니다. 사양은 적절한 경우 휴리스틱을 사용하거나 다른
필드 값에서 언어를 추론하는 것을 허용할 수도 있습니다. 더 보기
U+E0000부터
U+E007F까지)를 사용해서는 안 됩니다. 더 보기
@context와 내장 @language 속성을 문서 수준 기본값으로 사용하는 것이 권장됩니다.
더 보기
i18n
Namespace 기능을 사용해야 합니다. 더 보기i18n
Namespace를 사용할 수 없거나 사용하기에 부적절한 경우, 사양은 자연어
값에 대해 문자열별 언어 정보를 제공하기 위해 [JSON-LD]
일반 문자열 리터럴을 요구해야 합니다. 더 보기언어 감지 및 일치
텍스트는 그것이 쓰인 언어에 따라 다르게 렌더링되거나 처리됩니다. 예를 들어, 스크린 리더는 언어가 변경될 때 알림을 받아야 하며, 맞춤법 검사기는 언어에 민감해야 합니다. 텍스트를 렌더링할 때는 올바른 글꼴, 하이픈 넣기, 줄바꿈, 대문자/소문자 변경 및 기타 기능을 적용하기 위해 언어에 대한 지식이 필요합니다.
예를 들어 雪, 刃, 直, 令, 垔과 같은 표의 문자는 일본어 글꼴과 중국어 글꼴에서 사용할 때 작지만 중요한 차이가 있으며, 일본어 텍스트에 중국어 글꼴을 적용하지 않고, 그 반대도 하지 않는 것이 사용자에게 제시될 때 중요합니다.
주어진 리소스의 언어 정보는 두 가지 주요 목적을 염두에 두고 사용할 수 있습니다. 텍스트 처리를 위한 것이거나, 리소스의 의도된 사용에 대한 진술로서 사용되는 것입니다. 아래에서 그 차이를 설명합니다.
텍스트 처리 언어를 지정할 때, 여러분은 특정 텍스트 범위가 실제로 쓰인 언어를 선언하는 것입니다. 이를 통해 음성 브라우저, 맞춤법 검사기, 스타일 처리기, 하이픈 처리기 등 텍스트를 조작하는 사용자 에이전트나 애플리케이션이 해당 텍스트에 적절한 규칙을 적용할 수 있습니다. 따라서 우리는 필연적으로 하나의 언어를 특정한 텍스트 범위와 연결하는 것에 대해 이야기하고 있습니다.
텍스트 처리 언어를 리소스 전체를 처리하기 위한 기본 언어로 표현하는 것은 일반적이지만, 리소스 내에서 언어가 바뀌는 위치를 나타내는 것도 필요할 수 있습니다.
텍스트 범위의 텍스트 처리 언어를 식별하기 위해 HTML은lang 속성을 제공하고, XML은 모든 XML 형식에서
사용할 수 있는 xml:lang을 제공합니다. 관련 마크업 형식에서는 이러한 속성을 계속 사용하는 것이
유용합니다. 작성자도 이를 알고 있으며, HTML 및 XML 처리기도 이를 인식하기 때문입니다.
리소스의 언어를 전체로서 설명하는 것도 유용할 수 있습니다. 이러한 유형의 언어 선언은 리소스의 의도된 언어적 대상이라고 합니다. 예를 들어 이러한 메타데이터는 검색, 올바른 언어 버전 제공, 분류 등에 사용될 수 있습니다.
이러한 유형의 언어 선언은 텍스트 처리 선언과 다릅니다. 그 차이는 (a) 그러한 선언의 값이 둘 이상의 언어 하위 태그일 수 있고, (b) 선언된 언어 값이 다국어 리소스의 어느 부분이 어느 언어로 되어 있는지를 나타내지 않는다는 점입니다.
특정 텍스트 범위의 언어가 아니라 리소스의 의도된 사용을 나타내는 메타데이터 유형 언어 선언을 여러 언어 값과 연결할 수 있어야 합니다.
리소스의 의도된 사용을 설명하는 언어(들)가 문서에서 사용되는 모든 언어를 반드시 포함하는 것은 아닙니다. 예를 들어 웹상의 많은 문서에는 다른 언어로 된 콘텐츠 조각이 포함되어 있지만, 그 페이지는 명확히 특정 언어의 화자를 대상으로 합니다. 예를 들어 베이징에 대한 독일어 도시 안내서는 중국어로 된 유용한 표현을 포함할 수 있지만, 이는 중국어 사용자가 아니라 독일어 사용자를 대상으로 합니다.
반면에 문서가 둘 이상의 언어로 동일하거나 병렬적인 콘텐츠를 포함하는 상황도 상상할 수 있습니다. 예를 들어 웹 페이지가 왼쪽 열에는 프랑스어 콘텐츠로, 오른쪽 열에는 같은 콘텐츠를 영어로 제공하여 캐나다 독자를 맞이할 수 있습니다. 여기에서 문서는 두 언어의 화자를 동등하게 대상으로 하므로 대상 언어가 두 개입니다. 또 다른 사용 사례는 다국어 커뮤니티를 대상으로 하는 블로그나 뉴스 페이지로, 한 페이지의 일부 기사는 한 언어로, 일부는 다른 언어로 되어 있는 경우입니다. 이 경우 언어 선언의 값으로 둘 이상의 언어 태그를 나열하는 것이 타당할 수 있습니다.
외부 리소스의 언어를 표현하는 속성은 HTML lang 및 XML
xml:lang 언어 속성을 사용해서는 안 되며,
메타데이터(특정 텍스트 범위의 언어가 아니라 리소스의 의도된 사용을 나타내는 것)를
나타낼 때는 다른 속성을 사용해야 합니다.
XML 문서 스키마의 xml:lang – 언제
xml:lang을 사용해야 하며, 언제 XML 문서 스키마(DTD)에서 언어 값을 전달하기 위한
자체 요소나 속성을 정의해야 하는가?
외부 리소스의 언어를 나타내기 위해 다른 속성을 사용하면 그 속성이 둘 이상의 언어를 지정할 수 있습니다. 또한 가리키는 리소스가 단일 언어로 되어 있지 않은 경우에도 더 잘 작동합니다.
이러한 구분은 HTML에서 lang 속성과 hreflang 속성의
분리에서 볼 수 있습니다. 전자는 HTML 페이지 안의 텍스트 언어를 나타내고, 후자는 연결된
페이지의 예상 언어를 나타내는 메타데이터입니다.
이에 대한 더 긴 논의는 XML 문서
스키마의 xml:lang을 참조하십시오. 이 글은 구체적으로 xml:lang에 대해 다루지만,
그 개념은 다른 상황에도 적용될 수 있습니다.
BCP 47은 인터넷 및 웹 표준(그리고 다른 많은 곳)에서 사용되는 언어 태그 시스템입니다. 이는 IANA 레지스트리의 하위 태그를 사용하여 콘텐츠의 언어를 설명하는 문자열을 형성하는 방법을 정의합니다. 레지스트리의 하위 태그는 주로 언어, 문자, 지역 및 국가를 식별하기 위한 ISO 및 UN 표준에 기반을 두며(그리고 엄격한 호환성을 유지합니다). BCP47은 또한 Unicode 로캘의 기반이 됩니다.
BCP 47의 주요 기능에 대한 개요는 HTML 및 XML의 언어 태그를 참조하십시오.
RFC 5646 또는 RFC 4647과 같은 구성 부분이 아니라 BCP 47을 참조하십시오.
BCP 47에 대한 링크와 이름은 Tags for the Identification of Languages의 정의에 대한 변하지 않는 참조가 있도록 특별히 만들어졌습니다. RFC 1766, 3066, 4646은 이전(대체된) 버전입니다. 현재 버전의 BCP 47은 두 개의 RFC, 즉 5646과 4647로 구성되어 있습니다.
언어 태그에 대해 기대하는 적합성 수준을 구체적으로 명시하십시오. BCP 47은 "valid"와 "well-formed"라는 두 수준의 적합성을 정의합니다.
well-formed BCP 47 언어 태그는 언어 태그에 대해 정의된 구문을 따릅니다. 구현은 각 언어 태그가 하이픈으로 구분된 하위 태그로 이루어졌는지, 각 하위 태그가 태그 내 위치에 따라 특정 길이와 특정 내용(문자, 숫자 또는 특정 조합)을 갖는지 확인합니다. valid BCP 47 언어 태그는 well-formed이지만, 추가로 IANA Subtag Registry에 나열된 하위 태그만 사용되는지 확인합니다. IANA Subtag Registry는 새 하위 태그로 자주 업데이트된다는 점에 유의하십시오.
사양은 구현이 언어 태그가 "valid"인지 검사하도록 요구할 수 있지만, 대부분의 상황에서는 언어 태그가 "well-formed"일 것만 요구해야 합니다.
대부분의 사양은 언어 메타데이터의 2차 소비자입니다. 즉, 문서 형식(HTML lang, XML xml:lang 또는 문서 형식의 언어 필드/속성)에 이미 제공된 데이터를 사용합니다.
일반적으로 대부분의 사양은 리소스(맞춤법 검사기, 토크나이저, 글꼴 등)를 선택하거나 일치(예를 들어 어떤 문자열을 표시할지 선택)하는 데 관심이 있으며, 언어 태그의 내용 자체에는 직접적으로 관심이 없습니다. 유효하지 않지만 well-formed인 태그는 아무것과도 일치하지 않을 뿐이며, 보통 폴백 방식이 적절한 동작을 제공합니다.
사양이 구현 수준의 유효성 검사를 정말로 원할 수 있는 경우도 있습니다. 그러한 경우 태그가 valid가 되지 못한 결과를 지정해야 합니다(애플리케이션이 중단되어야 하는지, 사용자에게 경고해야 하는지 등). 또한 레지스트리는 규모가 크고 시간이 지나며 변경되므로, 각 구현은 레지스트리 버전에 의존하게 된다는 문제도 있습니다. 시간에 따른 변경은 종종 사소하지만, 사양의 무작위(오래된) 구현이 나중에 유효해진 언어 태그를 거부한다면 실제 사용자는 상호운용성 문제를 겪게 됩니다.
또한 BCP 47에는 추가 하위 태그 시퀀스를 정의하는 확장 메커니즘이 있습니다. 예를 들어 한 확장 [RFC6067](싱글턴 -u를 사용하는 Unicode Locales)은 JavaScript의 국제화 기능을 제어하는 데 흔히 사용됩니다(다른 용도도 있습니다). 이러한 추가 하위 태그의 유효성 검사는 대부분의 사양 범위를 벗어날 가능성이 큽니다.
사양은 콘텐츠와 콘텐츠 작성자가 "valid" 언어 태그를 사용하도록 요구해야 합니다.
언어 태그에 관한 규범적 문구는 콘텐츠 요구 사항과 구현 요구 사항 사이에서 다를 수 있습니다. 사양 작성자는 자신의 사양에 어떤 적합성 요구 사항과 테스트가 필요한지, 그리고 구현이 무엇을 해야 하는지를 신중하게 고려해야 합니다. 한 가지 해결책은 콘텐츠 작성자에게 "valid" 언어 태그를 사용하도록 규범적으로 요구하되, 구현에는 "well-formed" 언어 태그만 검사하도록 요구하는 것입니다.
사양은 ISO 639, ISO 3166 또는 기타 표준에서 추출한 코드 목록을 제공하는 대신 IANA Language Subtag Registry를 참조해야 합니다.
과거에는 언어 태그에서 발견되는 하위 태그를 제공하는 데 사용된 일부 표준이 자유롭게 또는 공개적으로 제공되지 않았으므로, 일부 사양은 상호운용성을 보장하는 데 도움이 되도록 목록을 제공했습니다. 이는 더 이상 필요하지 않습니다. BCP 47의 일부로서 IANA는 언어 하위 태그 레지스트리를 유지관리하며, 이는 언어 태그를 구성하는 데 사용할 수 있는 유효한 하위 태그의 공개적이고 기계 판독 가능한 목록입니다. 이 레지스트리는 ISO 639의 다양한 부분(639-1, 639-2, 639-3 등), ISO 15924 문자 코드, ISO 3166 및 UN M.49 지역 코드 등 기반 표준에 기반합니다. 레지스트리는 인터넷에서 찾을 수 있는 다른 목록과 달리 적극적으로 유지관리되고, 안정화되며, 포괄적입니다. 각 하위 태그 유형은 해당 표준 유지관리자의 도움과 참여를 통해 상위 표준과 동기화되므로, 코드를 추출하거나 자체 목록을 만들거나 다른 곳에서 찾은 목록을 참조하면 유지관리 문제나 혼란이 생길 수 있습니다.
완전히 형성된 언어 태그의 자체 목록을 만들면 사용할 수 있는 언어 목록이 불필요하게 제한됩니다. 또한 로캘 데이터는 계속 확장되므로 오늘의 지원을 설명하는 목록은 미래에는 오래된 것이 됩니다. 사용자에게 사용할 수 있는 태그나 하위 태그를 제한하는 것은 보편적 접근을 제공하려는 우리의 목표와 충돌합니다.
여기서는 구조화된 텍스트를 포함하는 독립적인 데이터 단위에 대해 이야기하고 있습니다. 예로는 전체 HTML 페이지, XML 문서, JSON 파일, WebVTT 스크립트, 주석 등이 포함될 수 있습니다.
사양은 리소스 전체에 대한 기본 텍스트 처리 언어를 정의하는 방법을 나타내야 합니다.
리소스 전체의 언어, 또는 적어도 기본 언어를 한 곳에서 식별하면 종종 문제를 줄일 수 있습니다.
예를 들어 HTML 파일에서는 html 요소에 lang 속성을 설정하여 이를 수행합니다.
리소스 내의 콘텐츠는 특별히 재정의되지 않는 한, 리소스 수준에서 선언된 텍스트 처리의 언어를 상속해야 합니다.
텍스트 처리 언어와 리소스의 예상 사용에 관한 메타데이터를 나타내기 위해 별도의 선언이 필요한지 고려하십시오.
많은 경우 리소스에는 하나의 언어로 된 텍스트만 포함되며, 더 많은 경우 텍스트 처리를 위한 기본 언어로 선언된 언어가 리소스 전체에 대한 메타데이터를 설명하는 언어와 같습니다. 그러한 경우에는 단일 선언을 갖는 것이 타당합니다.
그러나 단일 선언이 둘 이상의 언어를 가리킬 때, 어떤 하나의 언어가 텍스트 처리 기본값으로 사용되어야 하는지 결정할 방법이 없다면 그 선언을 사용하는 것은 문제가 됩니다.
리소스에 언어 선언이 하나뿐이고 그 값이 둘 이상의 언어 태그를 갖는 경우, 리소스의 기본 텍스트 처리 언어를 식별할 수 있어야 합니다.
여기에서 블록 및/또는 청크라는 단어는 리소스 전체 안에서 콘텐츠를 함께 묶고 인접한 콘텐츠와 분리하는 구조적 구성 요소를 가리키는 데 사용됩니다. 한 블록과 다른 블록 사이의 경계는 텍스트의 단락 또는 섹션 경계, 혹은 파일 내부의 개별 데이터 항목과 같습니다.
예를 들어 이는 XML 또는 HTML의 블록이나 단락, JSON의 객체 선언, WebVTT의 cue, CSV 파일의 한 줄 등을 가리킬 수 있습니다. 이를 단락, 문장 등 안의 범위를 설명하는 인라인 콘텐츠와 대조하십시오.
사양에 정의된 어떤 구조가 이러한 요구 사항과 관련되는지 해석하는 데는 약간의 고려가 필요할 수 있으며, 관련 데이터 형식에 따라 달라집니다.
기본적으로 콘텐츠 블록은 리소스 전체에 대해 설정된 모든 텍스트 처리 언어를 상속해야 합니다.
기본 텍스트 처리 언어 정보와 관련된 지침은 2.1 언어 기본 사항을 참조하십시오.
언어가 바뀌는 콘텐츠 블록에 대해 언어 변경을 나타낼 수 있어야 합니다.
이 섹션에서는 단락이나 문자열의 중간에 있는 문자 범위에 대해 제공해야 하는 정보를 다룹니다.
언어가 바뀌는 인라인 텍스트 범위에 대해 언어를 나타낼 수 있어야 합니다.
언어 전환이 맞춤법 검사, 렌더링, 스타일링, 음성 생성, 번역, 정보 검색 등 콘텐츠에 대한 작업에 영향을 줄 수 있는 경우, 영향을 받는 텍스트 범위를 나타내고 해당 콘텐츠의 언어를 식별해야 합니다.
이 섹션의 정보는 데이터 형식의 언어 및 방향 메타데이터 요구 사항 [STRING-META]에서 개발 중입니다. 해당 문서는 아직 작성 중이므로, 이 지침은 언제든지 변경될 가능성이 있습니다.
웹에서의 데이터 교환은 가능한 한 로캘 중립적 표준 형식을 사용해야 합니다. 그러나 웹상의 일부 데이터는 필연적으로 사람이 보도록 의도된 자연어 정보로 구성됩니다. 이러한 자연어 정보는 적절한 표시를 위해 언어 및 방향 메타데이터의 존재에 의존하고 그로부터 이점을 얻습니다. Unicode 지원과 함께, 기본 방향과 텍스트 범위의 자연어를 포함하고 지정하는 메커니즘은 웹을 위한 새 형식과 기술을 개발할 때 핵심적인 국제화 고려 사항 중 하나입니다.
국제화 워킹 그룹이 모든 사양에서 찾는 가장 기본적인 모범 사례는 다음과 같습니다:
자연어 텍스트를 포함하는 모든 문자열 필드에 대해, 해당 특정 문자열의 언어와 문자열 방향을 결정할 수 있어야 합니다. 그러한 결정은 문자열 또는 문서 수준의 메타데이터를 사용해야 하며, 휴리스틱에 의존해서는 안 됩니다.
문자열 형식의 언어 및 방향 메타데이터 작업은 진행 중입니다. 사양은 향후 메타데이터 채택의 필요성을 나타내는 참고를 포함해야 할 수도 있습니다. 다음은 프로토타입입니다:
필드 {fieldname}는
웹상의 문자열: 언어 및 방향 메타데이터 [STRING-META]의
모범 사례를 따라야 합니다. 여기에는 문자열 언어 및 방향 메타데이터 보고와 관련하여 등장하는
모든 향후 표준을 활용하는 것이 포함됩니다.
개별 지역화 가능한 텍스트 값에 대해 언어와 문자열 방향을 나타내려면 필드 기반 메타데이터 또는 문자열 데이터형을 사용하십시오.
개별 데이터 값은 같은 데이터 파일이나 문서에서 발견되는 다른 값과 언어나 방향이 다를 수 있습니다. 각 지역화 가능한 텍스트 필드와 직접 연결된 메타데이터 값을 제공하면 메타데이터를 적절히 재정의할 수 있으며, 애플리케이션이 각 데이터 필드를 사용하기 위해 조립, 추출, 전달 또는 기타 처리할 때 처리를 자동화하는 데 도움이 됩니다.
사양은 주어진 리소스의 모든 문자열에 대해 기본 언어와 기본 문자열 방향을 제공하는 메커니즘을 정의할 수 있습니다. 그러나 사양은 리소스 전체 기본값이 충분하다고 가정해서는 안 됩니다. 리소스 전체 설정이 가능하더라도, 문자열별 메타데이터를 사용하여 그 기본값을 재정의할 수 있어야 합니다.
많은 문서에는 단일 언어의 데이터가 포함됩니다. 아마도 헤더에서 의도된 언어적 대상을 나타내는 수단을 제공하면 전체 문서 크기와 복잡성을 줄일 수 있습니다. 그러나 특정 문자열 값을 재정의할 수 있는 능력은 여전히 중요합니다. 일부 문자열이 문서 언어로 제공되지 않을 수 있거나, 기본 방향이 문서 전체의 다른 지역화 가능한 텍스트 값의 기본 방향과 일치하지 않을 수 있기 때문입니다.
다른 정보가 없는 경우 기본 방향과 기본 언어는 알 수 없다고 지정하십시오.
사양은 사용자 제공 값을 포함하는 구문 콘텐츠와 지역화 가능한 텍스트를 구별하는 데 주의해야 합니다.
사양은 자연어 텍스트를 포함할 수 없는 필드에 대해 언어 메타데이터의 사용을 지정하거나 요구해서는 안 됩니다.
웹상의 문서 형식은 텍스트로 구성됩니다. 대부분의 경우, 주어진 문서 형식의 데이터 값은 단지 임의의 문자열이 아니라 대표적이고 의미 있는 것이 되도록 의도됩니다. 데이터 값이 예를 들어 영어 키워드로 구성되어 있다는 사실이 그 데이터 값을 텍스트로 표시하기 위한 자연어 문자열로 만들지는 않습니다(즉, 그 값은 지역화 가능한 텍스트가 아닙니다). 그러한 데이터 값은 문서의 구문 콘텐츠의 일부입니다. 이는 언어 및 방향 메타데이터를 필요로 하지 않을 뿐만 아니라, 그러한 메타데이터와 연결되어서도 안 됩니다.
지역화 가능한 텍스트가
아닌 문자열 값과 문자열 필드에 대해, 사양은 해당 필드가 언어적 성격이 아니라고
지정하고 언어 태그 zxx ("No linguistic content")를
각 문자열 값과 연결할 것을 권장해야 합니다.
지역화 가능한 텍스트를
포함한다고 알려져 있지만 기본 형식에서 언어 메타데이터를 제공할 가능성이 없는 문자열 값과
문자열 필드에 대해, 사양은 콘텐츠의 언어가 알 수 없다고 지정하고 언어 태그
und ("Undetermined")를 각 문자열과 연결할 것을 권장해야
합니다. 사양은 적절한 경우 휴리스틱을 사용하거나 다른 필드 값에서
언어를 추론하는 것을 허용할 수도 있습니다.
일부 문자열 값은 기존 프로토콜이나 형식에 의존하거나 그것들에 의해 정의됩니다. 종종 이러한 문자열은 언어 또는 방향 메타데이터와 연결되어 있지 않거나 이를 제공하지 않습니다. 예를 들어 많은 HTTP 헤더는 일부 경우 자연어 텍스트를 포함하더라도, 그 내용이 지역화 가능한 텍스트가 아닌 것처럼 정의합니다. 소비 사양은 때때로 이러한 성격의 문자열에 의존하거나, 이러한 문자열 중 하나를 설명하는 형식을 정의해야 할 수 있습니다. 이러한 경우, 사양의 데이터 구조나 문서 형식에서 소비자가 문자열과 연결할 언어 또는 방향 메타데이터는 없으며, 사양의 데이터 구조나 문서 형식이 생산자로 기능할 때 제공하는 메타데이터도 기본 형식을 통해 직렬화되지 않습니다.
사양은 언어 식별을 위해 Unicode "language tag" 문자(코드 포인트
U+E0000부터 U+E007F까지)를 사용해서는 안 됩니다.
Unicode "language tag" 문자는 언어 태그로 사용하는 것이 더 이상 권장되지 않으며, 문서 형식과 유선 프로토콜에서 언어 메타데이터 문제를 해결하기 위한 좋지 않은 해법인 이유가 많습니다. 사양 작성자는 이러한 문자를 다른 용도로 쓰거나, 이를 기반으로 언어 정보를 전송하는 새 메커니즘을 만들려고 하지 않도록 주의해야 합니다.
생산자는 때때로 주어진 콘텐츠 항목이나 데이터 레코드에 대해 지역화된 값을 제공해야 합니다. 때로는 이것이 생산자와 소비자 사이의 언어 협상을 통해 이루어집니다. 그러면 지역화는 반환되는 콘텐츠를 선택하기 위해 협상된 언어를 사용하여 생산자에서 이루어집니다.
다른 경우에는 콘텐츠 항목의 지역화가, 생산자가 해당 항목에 대해 여러 언어 표현을 반환하고 소비자가 표시할 값을 선택하도록 함으로써 이루어집니다. 이 후자의 과정은 언어 인덱싱이라고 합니다. 언어 인덱싱에 대한 자세한 내용은 [STRING-META]의 지역화 고려 사항을 참조하십시오.
[JSON-LD]는 이 섹션에서 찾을 수 있는 일부 모범 사례를 충족하기 위한 여러 메커니즘을 제공합니다:
BCP 47은 언어 태그를 정의하는 것(RFC 5646) 외에도, 언어 태그를 언어 범위와 일치시키는 주제에 관한 RFC도 포함합니다. 언어 태그의 정의를 위해 안정적인 식별자인 BCP 47을 참조하는 것이 가장 적절한 것과 마찬가지로, 그 안에서 찾을 수 있는 일치 방식들을 참조할 때도 BCP 47을 참조하는 것이 가장 좋습니다.
Unicode의 [CLDR] 프로젝트는 언어 태그가 로캘 식별자로 사용될 때 이를 일치시키기 위한 추가 알고리즘, 규칙 및 절차를 정의합니다.
이것은 이 섹션의 요구 사항만을 나열한 목록이며, 자체 검토에 사용할 수 있습니다. 여러분의 사양과 관련된 모든 요구 사항에 대해 한 줄의 첫 번째 체크박스를 선택하십시오. 여러분의 사양이 그 요구 사항을 충족하는 경우 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
기본 요구 사항
배경 정보
기본 방향 값
마크업에서 방향 처리하기
auto로 설정할 수 있어야 합니다. 이는 콘텐츠 자체를 검사하여 기본
방향이 결정됨을 의미합니다. 더 보기auto로 설정된 경우, 콘텐츠 단락의 방향은 단락별로
결정되어야 합니다. 더 보기
문자열의 기본 방향 처리하기
인라인 또는 부분 문자열 텍스트의 기본 방향 설정하기
auto로 설정할 수 있어야 하며, 이는 콘텐츠 자체를 검사하여 기본
방향이 결정됨을 의미합니다. 여기서 일반적인 접근 방식은 마크업 바깥의 첫 번째 강한
방향성 문자를 기준으로 방향을 설정하는 것입니다. 더 보기방향 감지 및 일치 (TBD)
오른쪽에서 왼쪽으로 쓰는 문자로 작성되었거나 그러한 문자와 섞인 텍스트의 방향을 설정하는 것은 중요합니다. 이러한 문자의 글자는 입력되고 발음되는 순서대로 메모리에 저장되며, 이를 논리적 순서라고 합니다. Unicode Bidirectional Algorithm(UBA)은 논리적 순서로 저장된 문자 시퀀스를 예상대로 시각적으로 정렬되도록 자동 렌더링하는 데 많은 지원을 제공합니다. 안타깝게도 UBA만으로는 양방향 텍스트를 올바르게 렌더링하기에 충분하지 않으며, 주어진 문자 시퀀스에 적용할 기본 방향 문맥에 대한 추가 정보를 제공해야 합니다.
기본 요구 사항은 다음과 같습니다.
위 요구 사항의 특수한 경우가 데이터 구조와 문서 형식의 자연어 문자열 값에 적용됩니다:
자연어 텍스트를 포함하는 모든 문자열 필드에 대해, 해당 특정 문자열의 언어와 문자열 방향을 결정할 수 있어야 합니다. 그러한 결정은 문자열 또는 문서 수준의 메타데이터를 사용해야 하며, 휴리스틱에 의존해서는 안 됩니다.
모든 지역화 가능한 텍스트에 대해 포함된 인라인 양방향 텍스트 구간의 기본 방향 변경을 나타낼 수 있어야 합니다.
오른쪽에서 왼쪽으로 쓰는 텍스트에 주석을 다는 일은 오른쪽에서 왼쪽으로 쓰는 문자를 모국어처럼 다루는 사람들에게 최소한의 노력만 요구해야 합니다.
Arabic, Divehi, Hebrew, Persian, Urdu 등의 화자에게 자신이 쓰는 모든 단락이나 작은 데이터 항목마다 마크업이나 제어 문자를 추가하도록 요구하는 것은 관리하기에 너무 큰 부담입니다. 일반적으로 형식은 기본 방향을 설정하고, 예외를 처리해야 할 때에만 사용자의 개입을 요구해야 합니다.
이 섹션에서는 뒤따르는 권고 사항을 더 쉽게 이해할 수 있도록 텍스트 방향과 관련된 몇 가지 핵심 개념을 설명하려고 합니다.
'오른쪽에서 왼쪽' 문자로 작성된 텍스트 또는 양방향 요소를 포함하는 왼쪽에서 오른쪽 텍스트를 올바르게 표시하려면, 텍스트의 요소가 표시될 순서를 지시하는 데 사용될 기본 방향을 설정하는 것이 중요합니다.
Unicode Bidirectional Algorithm(UBA)이 무엇을 하는지와 하지 않는지, 그리고 왜 기본 방향이 그렇게 중요한지에 익숙하지 않다면 Unicode Bidirectional Algorithm 기본 사항을 읽으십시오.
이 섹션에서 단락이라는 단어는 일반 텍스트에서 하드 줄바꿈이
뒤따르는 텍스트 구간을 나타내지만, 다른 상황에서는 다른 것을 의미할 수 있습니다. CSV에서는
'cell'에 해당하므로, 쉼표로 구분된 항목들의 한 줄은 실제로 쉼표로 구분된 단락들의 집합입니다.
HTML에서는 가장 낮은 수준의 블록 요소에 해당하며, 이는 보통 p 요소이지만, 텍스트 및/또는 인라인
요소만 포함하는 경우
div, li 등이 될 수도 있습니다.
JSON에서는 종종 따옴표로 묶인 문자열 값에 해당하지만, 문자열 값이 마크업을 사용하는 경우 단락은
블록 요소와 연결되고, 문자열 값이 여러 줄의 일반 텍스트인 경우 각 줄이 단락입니다.
여기에서 메타데이터라는 용어는 데이터와 연결된 주석이나 속성일 수 있는 정보, 또는 이를 허용하는 시나리오의 마크업일 수 있는 정보, 또는 더 높은 수준의 프로토콜 등을 의미합니다.
기본 방향을 설정하는 데는 여러 가지 가능한 방법이 있습니다.
ltr, rtl 또는 auto가 포함될 수 있습니다.
dir=auto를 설정했을 때 발생하는 일입니다.)
dir
속성이 없을 때 발생하는 일입니다.)html 태그에
dir 속성을 설정했을 때 발생하는 일입니다.
또 다른 예로는 모두 Arabic으로 작성된 많은 cue를 포함하는 자막 파일이 있습니다.
작성자가 파일의 시작에서 모든 cue 텍스트의 기본값이 RTL이라고 말할 수 있도록 하는
것이 가장 좋습니다. 필요한 경우 특정 단락의 방향 정보를 재정의할 수 있는 방법은
항상 있어야 합니다.
auto로 설정된 경우에만 발생합니다. HTML은 기본 방향을
지정하기 때문입니다.)
사용자의 텍스트 입력을 캡처할 때는 일반적으로 입력의 기본 방향을 결정하기 위해 사용자가 데이터를
입력하고 있던 문맥을 이해해야 합니다. 예를 들어 HTML에서는 이것이 html 태그에서 상속된 방향으로
설정될 수도 있고, 사용자가 폼 필드의
기본 방향을 설정하기 위해 키를 눌러 설정될 수도 있습니다. 그런 다음 기본 방향에 대한 정보를
저장하거나 렌더링될 때 문자열과 연결할 방법을 찾아야 합니다. 일반적으로 이 상황에서는 입력되는
문자열 내부의 모든 방향 변경은 사용자가 처리하며 문자열의 일부로 캡처됩니다.
단일 단락 안의 포함된 텍스트 범위는 서로 다른 기본 방향을 가져야 할 수 있습니다. 예를 들어,
"The title was '!NOITASILANOITANRETNI'."
작은따옴표 안의 범위가 Hebrew/Arabic/Divehi 등으로 되어 있고 느낌표를 올바르게 배치하기 위해 주변 단락의 LTR 기본 방향 대신 RTL 기본 방향을 가져야 하는 경우입니다.
콘텐츠 작성자가 마크업을 사용할 수 있다면, 그러한 인라인 범위를 나타내는 데 마크업을 사용하는
것이 더 쉽고 안전할 가능성이 큽니다(아래 참조). HTML에서는 보통 dir 속성이 있는 인라인 요소를
사용하여 그러한 텍스트 구간의 기본
방향을 설정합니다. HTML의 title 요소처럼 텍스트에 마크업을 할 수 없거나, 일반 텍스트 콘텐츠만
처리하는 어떤 환경이라면, 그러한 내부 범위의 기본 방향을 설정하기 위해 Unicode의 쌍 제어 문자에
의존해야 합니다.
또한 기본 방향이 변경된 인라인 범위는 주변 텍스트로부터 bidi 격리되어야 합니다. 그래야 Unicode Bidirectional Algorithm이 경계 간 간섭 때문에 잘못된 결과("넘침 효과")를 만들지 않습니다.
이는 콘텐츠 작성자가 Unicode 제어 코드를 사용하는 경우 포함 제어 문자
RLE/LRE…PDF가 아니라 격리 제어 문자
RLI/LRI/FSI…PDI를 사용해야 함을 의미합니다.
방향을 설정하기 위해 제어 문자에 의존하는 것을 피해야 하는 이유는 다음과 같습니다:
위의 마지막 두 항목은 마크업에도 적용될 수 있지만, 구현자는 포함된 제어 코드보다 포함된 마크업을 더 잘 지원하는 경우가 많습니다.
사용자가 모든 단락의 시작과 끝에 제어 코드를 추가할 것이라고 기대하지 마십시오. 그것은 너무 많은 작업입니다.
Unicode 문자 
U+200F RIGHT-TO-LEFT MARK (RLM),
U+200E LEFT-TO-RIGHT MARK (LRM), 그리고 
U+061C ARABIC LETTER MARK (ALM)에 대해 이 시점에서 한마디 할
필요가 있습니다.
먼저 분명히 해야 할 점은 이 세 문자가 텍스트 범위의 기본 방향을 설정하지 않는다는 것입니다. 이들은 단지 강한 방향성 속성을 가진 보이지 않는 문자일 뿐입니다.
앞선 예제를 떠올려 보면, 이는 예를 들어 RLM을 사용하여 W3C 텍스트가 Hebrew 텍스트의 왼쪽에 나타나게 할 수 없다는 뜻입니다. 메타데이터나 쌍 제어 문자를 사용하는 경우에만 올바른 표시가 만들어집니다.
물론 HTML의 dir="auto"와 같은 first-strong 휴리스틱을 사용하여 기본 방향을 감지하는
경우에는, 문제의 텍스트가 그렇지 않으면 잘못된 결과를 줄 수 있는 것으로 시작할 때 감지되는
기본 방향에 영향을 주기 위해 RLM, ALM 또는 LRM을 삽입하는 것이 유용할 수 있습니다.
기본 방향을 설정하기 위해 메타데이터가 사용되는 경우, 그 메타데이터가 first-strong 휴리스틱을 사용해야 한다고 구체적으로 말하지 않는 한, 강한 방향성 서식 문자는 무시된다는 점을 기억하십시오.
마지막으로 U+061C ARABIC LETTER MARK (ALM) 사용에 대한 참고입니다.
이 문자는 숫자 앞에 Arabic 문자가 나타나지 않는 경우 Arabic 문자 텍스트 안의 숫자 시퀀스 표시 방식에
영향을 주기 위해 사용됩니다.
다음은 모두 기본 방향에 대한 정보를 제공하기 위해 언어 태그를 사용할 수 없는 이유입니다:
auto 값을 만들 수 없습니다.Suppress-Script: Hebr)처럼 보통 필요하지 않은
언어에 대해서는 script 태그 사용을 억제할 것을 권장합니다. Persian과 같이 보통 RTL 문자로
작성되는 언어도 전사된 형태로 작성될 수 있으며, 방향 정보를 담는 데 필요한 script 태그가
존재한다고 보장할 수 없습니다. 요약하면, 방향에 영향을 주기 위해 사람들이 언어 정보의 일부로
script 태그를 제공할 것이라고 의존할 수 없습니다.기본 기본 방향의 값에는 왼쪽에서 오른쪽, 오른쪽에서 왼쪽, auto가 포함되어야 합니다.
auto 값은 텍스트 조각의 기본 방향을 자동으로 감지할 수 있게
합니다. 예를 들어 HTML의 dir에서 auto 값은 텍스트에서 첫 번째 강한 방향성 문자를 찾되, 텍스트의
기본 방향을 추측하기 위해 특정 마크업 항목도 무시합니다. 자동 감지 알고리즘은 완벽과는 거리가 멀다는
점에 유의하십시오. First-strong 감지는 실제로는 오른쪽에서 왼쪽인 텍스트가 강한 LTR 문자로 시작할
때 이를 올바르게 식별하지 못합니다. 텍스트의 내용에 기반해 기본 방향을 판단하려는 알고리즘도
문제가 있습니다. 가장 좋은 시나리오는 기본 방향이 알려져 있고 선언되어 있는 경우입니다.
이 섹션은 마크업을 사용하여 콘텐츠를 구성하는 리소스와 함께 작동하는 bidi 처리 접근 방식을 정의하는 것에 관한 내용입니다. 일부 권고 사항은 웹상의 문자열을 처리하기 위한 권고 사항과 다릅니다(3.5 문자열의 기본 방향 처리하기 참조).
사양은 리소스 전체에 대한 기본 기본 방향을 정의하는 방법, 즉 전체 기본 방향을 설정하는 방법을 나타내야 합니다.
다른 정보가 없는 경우 기본 기본 방향은 auto여야 합니다.
콘텐츠 작성자는 기본 방향이 바뀌는 텍스트 부분을 나타낼 수 있어야 합니다. 블록 수준에서는 이를 속성이나 메타데이터를 사용하여 달성해야 하며, 콘텐츠 작성자가 방향 제어를 위해 Unicode 제어 문자를 사용하도록 요구해서는 안 됩니다.
모든 블록의 방향을 설정하기 위해 Unicode 제어 문자에 의존하는 것은 가능하지 않습니다. 줄바꿈이 그러한 제어 문자의 효과를 종료하기 때문입니다. 또한 필요한 모든 지점에 제어 문자가 나타나야 한다면 데이터가 훨씬 덜 안정적이 되고, 관리하기가 불필요하게 어려워집니다.
콘텐츠 조각의 방향도 auto로 설정할 수 있어야 합니다. 이는 콘텐츠
자체를
검사하여 기본 방향이 결정됨을 의미합니다.
추정 알고리즘, HTML 및 CSS의 Bidi에 대한 추가 요구 사항에서.
여기서 일반적인 접근 방식은 마크업 바깥의 첫 번째 강한 방향성 문자를 기준으로 방향을 설정하는 것이지만, 이것이 유일한 가능한 방법은 아닙니다. 방향이 auto로 설정되었을 때 방향성을 결정하는 데 사용되는 알고리즘은 수신자가 기대하는 것과 일치해야 합니다.
first-strong 알고리즘은 Unicode 정의에 따라 단락에서 강한 방향성 속성을 가진 첫 번째 문자를 찾습니다. 그런 다음 그 문자의 방향에 따라 단락의 기본 방향을 설정합니다.
first-strong 알고리즘은 첫 번째 문자가 단락의 나머지 부분을 대표하지 않는 경우, 예를 들어 RTL 단락이나 줄이 LTR 브랜드 이름 또는 기술 용어로 시작하는 경우 단락의 방향을 잘못 추측할 수 있다는 점에 유의하십시오.
방향 감지 알고리즘에 대한 추가 정보는 HTML과 관련하여 논의된 문서의 추정 알고리즘을 참조하십시오.
일반 텍스트에 대해 전체 기본 방향이 auto로 설정된 경우, 콘텐츠
단락의 방향은 단락별로 결정되어야
합니다.
포함된 줄의 시작과 끝을 기준으로 텍스트 블록의 면을 나타내려면 'top' 및 'bottom' 대신 'block-start'와 'block-end'를 사용하십시오.
줄의 시작/끝을 나타내려면 'left' 및 'right' 대신 'start'와 'end', 또는 'inline-start'와 'inline-end'를 사용해야 합니다.
기본 방향과 양방향 재정의를 제어하기 위한 전용 속성을 제공하십시오. bidi 제어를 달성하기 위해 사용자가 임의의 마크업에 스타일 속성을 적용하는 것에 의존하지 마십시오.
bidi 지원을 위한 CSS와 마크업 비교, W3C 글.
예를 들어 HTML에는 CSS 스타일의 도움 없이 기본 방향을 관리할 수 있는 dir 속성이 있습니다. XML
형식은 필요한 표시를 달성하기 위해 CSS가
필요하더라도 방향 정보를 나타내는 전용 마크업을 정의해야 합니다. 텍스트가 다른 방식으로 사용될 수
있기 때문입니다.
CSS와 같은 스타일 시트는 항상 데이터와 함께 사용되거나, 데이터가 신디케이션될 때 데이터와 함께 전달되는 것은 아닙니다. 방향 정보는 데이터를 올바르게 표시하는 데 근본적으로 중요하므로, 마크업이나 데이터와 더 밀접하고 더 영구적으로 연결되어야 합니다.
이 섹션의 정보는 웹상의 문자열: 언어 및 방향 메타데이터에서 가져온 것입니다. 해당 문서는 아직 작성 중이므로 이 지침은 언제든지 변경될 가능성이 있습니다.
모든 자연어 문자열의 기본 방향을 나타내는 데 사용할 수 있는 메타데이터 구조를 제공하십시오.
모범 사례, 권고 사항 및 격차, 웹상의 문자열: 언어 및 방향 메타데이터에서
메타데이터가 제공되는 경우를 제외하고, 문자열 소비자는 문자열의 기본 방향을 감지하기 위해, 가능하면 Unicode Standard의 first-strong 알고리즘에 기반한 휴리스틱을 사용해야 한다고 지정하십시오.
모범 사례, 권고 사항 및 격차, 웹상의 문자열: 언어 및 방향 메타데이터에서
가능한 경우, 주어진 리소스나 문서의 모든 문자열에 대한 기본 방향을 나타내는 필드를 정의하십시오.
모범 사례, 권고 사항 및 격차, 웹상의 문자열: 언어 및 방향 메타데이터에서
어떤 문자열에 대해서도 방향을 변경할 수 있는 능력 없이 문서 수준 기본값을 만드는 것만으로 충분하다고 가정해서는 안 됩니다.
모범 사례, 권고 사항 및 격차, 웹상의 문자열: 언어 및 방향 메타데이터에서
레거시 구현 때문에 메타데이터를 사용할 수 없고 다른 방식으로도 제공할 수 없는 경우, 사양은 사용 가능한 언어 메타데이터에서 문자열 방향을 보간하는 것을 허용할 수 있습니다.
모범 사례, 권고 사항 및 격차, 웹상의 문자열: 언어 및 방향 메타데이터에서
여기에서 '인라인 텍스트'는 마크업에서 쉽게 이해할 수 있는 의미를 갖습니다. 또한 JSON, CSV 또는 다른 일반 텍스트 형식의 문자열에도 적용되며, 이는 문자열의 모든 문자를 포함하지 않는 문자 구간을 의미합니다.
기본 방향이 바뀌는 인라인 텍스트 범위를 나타낼 수 있어야 합니다. 마크업을 사용할 수 있다면 이것이 선호되는 방법입니다. 그렇지 않으면 여러분의 사양은 Unicode 제어 문자가 수신 애플리케이션에 의해 인식되고 올바르게 구현될 것을 요구해야 합니다.
인라인 텍스트 범위의 방향도 auto로 설정할 수 있어야 하며, 이는 콘텐츠
자체를 검사하여
기본 방향이 결정됨을 의미합니다. 여기서 일반적인 접근 방식은 마크업 바깥의 첫 번째 강한 방향성
문자를 기준으로 방향을 설정하는 것입니다.
first-strong 알고리즘은 Unicode 정의에 따라 단락에서 강한 방향성 속성을 가진 첫 번째 문자를 찾습니다. 그런 다음 그 문자의 방향에 따라 단락의 기본 방향을 설정합니다.
first-strong 알고리즘은 첫 번째 문자가 단락의 나머지 부분을 대표하지 않는 경우, 예를 들어 RTL 단락이나 줄이 LTR 브랜드 이름 또는 기술 용어로 시작하는 경우 단락의 방향을 잘못 추측할 수 있다는 점에 유의하십시오.
방향 감지 알고리즘에 대한 추가 정보는 HTML과 관련하여 논의된 문서의 추정 알고리즘을 참조하십시오.
사용자가 Unicode 양방향 제어 문자를 사용하는 경우, PDI 문자와 함께 격리 RLI/LRI/FSI가 애플리케이션에서 지원되어야 하며, 사양은 RLE/LRE와 PDF 대신 이를 권장해야 합니다.
RLM/LRM 사용은 적절해야 하며, 이러한 제어 문자가 할 수 있는 것과 할 수 없는 것에 대한 기대가 사양에서 명확해야 합니다.
Unicode 양방향 제어 문자 U+200F RIGHT-TO-LEFT MARK와 U+200E LEFT-TO-RIGHT MARK는 양방향 텍스트를 관리하기에 그 자체만으로는
충분하지 않습니다. 이들은 포함된 텍스트에 대해 다른 기본 방향을 만들 수 없습니다. 이를 위해서는
포함된 텍스트 범위의 시작과 끝을 나타낼 수 있어야 합니다. 이는 사용할 수 있다면 마크업으로
처리하는 것이 가장 좋으며, 그렇지 않으면 바로 위에서 언급한 다른 Unicode 양방향 제어 문자를 사용하는
것이 좋습니다.
마크업에서는 기본 방향과 양방향 재정의를 제어하기 위한 전용 속성을 제공하십시오. bidi 제어를 달성하기 위해 사용자가 임의의 마크업에 스타일 속성을 적용하는 것에 의존하지 마십시오.
마크업에서는 텍스트를 포함하는 모든 인라인 요소에 bidi 속성을 허용하십시오.
마크업에서는 사용자가 (a) 격리되거나 포함된 기본 방향을 만들거나 (b) 양방향 알고리즘을 완전히 재정의할 수 있게 하는 속성을 제공하십시오. 이러한 속성은 사용자가 이 두 시나리오 중 어느 경우에도 방향을 LTR, RTL 또는 Auto로 설정할 수 있게 해야 합니다.
이것은 이 섹션의 요구 사항만을 나열한 목록이며, 자체 검토에 사용할 수 있습니다. 여러분의 사양과 관련된 모든 요구 사항에 대해 한 줄의 첫 번째 체크박스를 선택하십시오. 여러분의 사양이 그 요구 사항을 충족하는 경우 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
문자 및 문자 인코딩 기본 사항
'string'의 정의 선택하기
DOMString을
사용하십시오. (이 사용 목록은 완전한 것이 아닙니다.) 더 보기USVString을
사용하십시오. UTF-8
encode를 포함하는 모든
프로세스나, 짝이 없는 surrogate 코드 포인트가 오류를
생성할 수 있는 곳에는 USVString을
사용하십시오. 더 보기DOMString과 USVString을 섞어
사용하지 마십시오. 대개는 USVString보다
DOMString을
선택하게 됩니다. 후자는 대부분의 문서 형식이나 프로토콜에 이점을 주지 않는 추가 처리를
요구하기 때문입니다. 더 보기
DOMString 또는,
드물게, USVString을
지정하십시오. 더 보기Uint8Array를
지정하십시오. 더 보기ByteString을
지정하십시오. 더 보기참조 처리 모델 정의하기
문자 범위 포함 및 제외하기
사적 사용 영역 사용하기
문자 인코딩 선택하기
문자 인코딩 식별하기
문자 이스케이프 설계하기
텍스트 저장하기
공백 문자
character라는 단어는 서로 다른 문맥에서 서로 다른 의미를 갖습니다. 주어진 텍스트 단위의 시각적, 논리적 또는 바이트 수준 표현을 다양하게 가리킬 수 있습니다. 이 때문에 이 용어는 사양에서 가볍게 사용하기에는 너무 부정확합니다. 따라서 컴퓨팅 시스템에서 텍스트가 어떻게 정의되고 인코딩되는지, 그리고 그러한 사양을 모호하지 않게 만드는 데 사용되는 관련 용어를 이해하는 것은 문자열 데이터 처리를 논의하기 위한 필수 전제 조건입니다.
사양 개발자와 그 사양에 기반한 소프트웨어 개발자는 자신이 경험한 'character'라는 용어의 사용에는 더 익숙하지만, 국제적 문맥에서의 다양한 사용에는 덜 익숙할 가능성이 큽니다. 또한 컴퓨팅 문맥에서 문자는 종종 관련 개념과 혼동되어 불완전하거나 부적절한 사양과 소프트웨어로 이어집니다.
문자, 문자열 또는 문자나 문자열을 다루는 모든 프로세스를 지정할 때는 가장 구체적이고 적절한 용어를 사용하십시오. 그렇게 하지 않을 이유가 없다면, 코드 포인트를 Unicode Scalar Value를 의미하도록 정의하고, 'character'보다 그 용어를 우선 사용하십시오.
이 섹션에서 찾을 수 있는 가장 적절한 용어를 사용하십시오. 다음은 다른 권장 용어입니다:
| 단위 유형 | character 대신 사용할 것... | 설명 |
|---|---|---|
| 텍스트 단위 | 코드
포인트, Unicode 코드 포인트, Unicode Scalar Value |
문자 인코딩 형식이나 특정 직렬화와 무관한 텍스트의 논리적 단위. |
| 저장, 처리, 직렬화, 인코딩 | 코드 단위 | 인코딩 및 직렬화의 단위. 코드 단위는 일반적으로 wire 및 파일 형식, 저수준 텍스트 처리에서 지정됩니다. 사용되는 문자 인코딩(가급적 UTF-8 또는 UTF-16)에 의존합니다. |
| 시각적 단위, 사용자가 인식하는 문자, 선택/분절 | 자소
클러스터, 타이포그래피 문자 단위 |
텍스트를 시각적 단위로 나누는 것, 대부분의 시각적 선택과 잘라내기. 이 권고 사항에는 가장 많은 뉘앙스가 있습니다. |
| 글꼴의 요소 | 글리프 | 개별 표시 값. 주로 글꼴의 내용을 이야기할 때 이 용어를 사용하십시오. |
'character'라는 용어 사용을 피할 수 없다면, 그 용어에 대한 명확한 정의를 포함해야 합니다.
다음은 핵심 용어의 간단한 용어집입니다:
[Unicode] [D7]는 추상
문자를 다음과 같이 정의합니다: 텍스트 데이터의 조직, 제어 또는 표현에 사용되는
정보 단위.
이 정의는 필연적으로 모호하며, 이어서 추상 문자는 특정한 구체적 형태를 갖지
않으므로(따라서 글꼴의 글리프와
혼동해서는
안 됨), 사용자가 "문자"라고 생각할 수 있는 것과도 다르다고 설명합니다(따라서 자소와 혼동해서는 안 됨). 여러분의
사양에서는 이 용어 사용을 피하십시오.
문자 집합은 텍스트를 인코딩하기 위해 함께 사용할 수 있는 추상 문자의 순서 없는 모음(즉, 집합)입니다. 문자 집합에 있는 문자들의 모음은 때때로 그 레퍼토리라고도 합니다. 대부분의 문자 집합은 특정 범위의 언어나 문자만 지원합니다.
[Unicode]는 때때로 Universal Character Set라고도 불리며, 역사적이거나 사라진 문자 체계뿐만 아니라 현대적 사용, 사적 사용, 조판 기호, emoji와 같은 다른 것들을 포함하여 컴퓨터 시스템에서 텍스트를 인코딩하는 데 현재 사용되는 모든 문자를 포함합니다. 다른 모든 문자 집합은 Unicode의 정의된 부분집합입니다. 매년 개정판은 인코딩된 문자 집합을 확장합니다.
[Unicode] 표준은 단순한 문자 집합보다 훨씬 많은 것을 정의합니다. 또한 텍스트의 처리와 표현을 위한 많은 속성, 알고리즘 및 기타 세부 사항을 정의합니다.
코드 포인트는 추상 문자가 문자 집합 안에서 갖는 고유 식별자입니다. 문자 집합이 유용하려면 각 문자를 모호하지 않게 식별해야 합니다. 대부분의 문자 집합에서 코드 포인트는 집합의 문자 표나 차트에서 문자의 위치를 설명하는 숫자(또는 숫자 집합)입니다.
[Unicode]에서 코드 포인트는 0x0000부터
0x10FFFF까지를 포함하는 정수입니다. 이는 16진 표기법으로 작성됩니다(4.11
Unicode 문자 참조하기 참조). Unicode 코드 포인트는
때때로 Unicode Scalar
Value라고 불립니다.
Unicode에서 추상 문자에 할당된 각 코드 포인트에는 고유하고 불변인 이름도 부여됩니다. Unicode는 또한
각 할당된 문자와 다양한 속성을 연결합니다. 이러한 속성 중 많은 것은 Unicode Character Database(또는
UCD]) [UAX44]에
나타나며, 다른 속성은 보조 파일이나 표에 할당됩니다.
[Unicode] [D11]은 인코딩된
문자를 추상 문자와 코드 포인트 사이의 연관(또는 매핑)
으로
정의합니다. 일반적으로 사양에서는 코드
포인트,
또는 더 구체성이 필요할 때 Unicode 코드 포인트나 Unicode Scalar
Value라는 용어가 선호됩니다.
코드 포인트는 소프트웨어에서 문자의 저장과 교환에 직접 사용되지 않습니다. 대신, 그것이 나타내는 문자를 인코딩하고 처리하거나 한 표현에서 다른 표현으로 변환하기 위한 다양한 방식이 존재합니다.
코드 단위는 물리적 저장과 정보 교환의 단위이며, 컴퓨터 처리, 저장 및 통신의 기반을 형성합니다. 가장 익숙한 코드 단위는 byte 또는 octet이라고 불리며, 8비트로 구성됩니다.
서로 다른 실행 환경에서는 서로 다른 크기의 코드 단위가 사용됩니다. 다른 일반적인 크기에는 16비트 또는 32비트 단위가 포함됩니다. 예를 들어 웹에서는 [DOM], JavaScript 및 [INFRA]의 다양한 문자열 유형에서 16비트 코드 단위가 사용됩니다. 이러한 사양은 [Unicode]의 UTF-16 문자 인코딩 규칙에 따라 처리되는 16비트 코드 단위를 사용합니다.
문자 인코딩 형식(때로는 단순히 문자 인코딩이라고도 함)은 문자 집합의 코드 포인트를 텍스트를 저장하고 처리하는 데 사용되는 코드 단위로 인코딩하는 규칙의 집합입니다. 또는 코드 단위를 다시 코드 포인트로 디코딩하는 규칙의 집합입니다. Unicode가 아닌 문자 인코딩 형식은 통칭하여 레거시 문자 인코딩이라고 합니다.
UTF-8은 [Unicode]의 멀티바이트 문자 인코딩 형식입니다. 이는 웹에서 사용되는 가장 일반적인 문자 인코딩입니다. UTF-8은 8비트 바이트를 그 코드 단위로 사용합니다. UTF-8은 가변 폭 인코딩으로, 인코딩되는 코드 포인트에 따라 서로 다른 수의 코드 단위를 사용합니다.
익숙한 7비트 ASCII 문자(U+0000부터 U+007F까지의 코드 포인트)는 UTF-8로
인코딩하는 데 1바이트가 필요합니다.
| 문자 | 코드 포인트 | UTF-8 코드 단위(바이트) |
|---|---|---|
| A | U+0041 |
0x41 |
U+0080부터 U+07FF까지의 코드 포인트는 2바이트가 필요합니다.
| À | U+00C0 |
0xC3 0x80 |
U+0800부터 U+FFFF까지의 코드 포인트는 3바이트를 차지합니다.
| न | U+0928 |
0xE0 0xA4 0xA8 |
그리고 마지막으로, U+10000부터 U+10FFFF까지의 코드 포인트는 4바이트를
차지합니다.
| 👪 | U+1F46A |
0xF0 0x9F 0x91 0xAA |
사양, 소프트웨어 및 콘텐츠는 문자(코드 포인트)와 물리적 저장 단위(코드 단위) 사이의 일대일 관계를 요구하거나 이에 의존해서는 안 됩니다.
저장 단위 C009, 월드 와이드 웹을 위한 문자 모델 1.0: 기본 사항에서
사양, 소프트웨어 및 콘텐츠는 코드 포인트와 표현 단위(예: 자소 클러스터, 글리프 또는 타이포그래피 문자 단위) 사이의 일대일 매핑을 요구하거나 이에 의존해서는 안 됩니다.
시각적 렌더링 단위 C002, 월드 와이드 웹을 위한 문자 모델 1.0: 기본 사항에서.
문자, 키 입력 및 글리프의 예, 월드 와이드 웹을 위한 문자 모델 1.0: 기본 사항에서.
이 문서에서 시각적 텍스트 단위는 사용자가 인식하는 보이는 텍스트의 단일 단위를 가리킵니다. 이는 화면에 있을 수도 있고, 종이에 인쇄되거나 냅킨 뒷면에 쓰인 것과 같은 다른 매체에 있을 수도 있습니다. 이 용어는 필연적으로 부정확합니다. 특히 결합 기호, 복잡한 위치 지정 또는 문맥에 기반한 복잡한 shaping을 사용하는 문자 체계에서는 사용자 인식이 문자와 쓰기 체계에 대한 친숙도에 자주 의존하기 때문입니다. 여러분의 사양에서는 이 용어 사용을 피하십시오.
자소 클러스터는 인코딩된 텍스트에서 시각적 텍스트 단위를 계산적으로 근사한 것입니다. 즉, 사용자 관점에서 단일 시각적 텍스트 단위를 형성할 것으로 예상되는 코드 포인트의 시퀀스입니다. [Unicode]는 텍스트 처리를 돕기 위해 이러한 경계를 계산하는 방법을 제공합니다. 많은 텍스트 작업에서 그러한 시퀀스는 단일한, 나눌 수 없는 텍스트 단위로 처리되어야 하기 때문입니다. 예를 들어 텍스트에서 커서를 이동할 때, 커서는 전체 시각적 텍스트 단위(및 그 underlying 코드 포인트)를 함께 "건너뛰거나" 선택해야 합니다. 시각적 텍스트 단위의 "중간"으로 커서를 이동하는 것이 가능해서는 안 됩니다. (달리 지정되지 않는 한, 이 문서에서 자소 클러스터라는 용어는 Unicode Text Segmentation [UAX29]이 "extended default grapheme cluster"라고 부르는 것을 가리킵니다.)
일부 텍스트 작업은 사용자가 자소 클러스터 안의 개별 코드 포인트와 상호작용하는 것을 허용한다는 점에 유의하십시오. 예를 들어 백스페이스 같은 일부 편집 기능은 시각적 텍스트 단위의 끝에서 문자를 점진적으로 삭제합니다 (예를 들어 사용자가 전체 클러스터를 지우지 않고 철자 오류를 고칠 수 있도록 하기 위함).
타이포그래피 문자 단위라는 용어는 [CSS]에서 정의되며, 특정 작업에 대해 "하나의 단위"로 취급되어야 하는 서로 다른 유형의 코드 포인트 시퀀스를 가리키는 데 사용됩니다. 때때로 이는 자소 클러스터라는 용어와 일치하지만, 다른 때에는 구별됩니다. 문맥과 사용법을 이해하는 경우에만 이 용어를 사용하십시오.
글리프는
특정 글꼴로 렌더링될 때 문자(또는 문자 시퀀스)의 시각적 표현입니다. 글리프는
추상 문자와 항상 1:1 관계를 갖는 것은 아닙니다. 글리프는
문자의 일부 또는 여러 문자의 조합을 나타낼 수 있습니다. 서로 다른 글리프가 같은 코드 포인트를
나타낼 수 있습니다. 예를 들어 다음은 모두 AU+0041 LATIN CAPITAL LETTER A에 대한 서로
다른 글리프입니다:
따라서 글꼴은 텍스트를 렌더링하는 데 사용되는 특정 글리프의 모음입니다.
사양, 소프트웨어 및 콘텐츠는 문자와 언어의 소리 사이의 일대일 대응을 요구하거나 이에 의존해서는 안 됩니다.
청각적 렌더링 단위 C001, 월드 와이드 웹을 위한 문자 모델 1.0: 기본 사항에서
일부 문자에서는 문자가 음소(특정 구어의 맥락에서 최소한으로 구별되는 소리인 phoneme)와 밀접한 관계를 가지며, 다른 문자에서는 의미와 밀접하게 관련됩니다. 문자가 (느슨하게) 음소와 대응하는 경우에도, 이 관계는 단순하지 않을 수 있으며 문자와 음소 사이에 일대일 대응이 있는 경우는 드뭅니다.
다음은 character라는 용어와 소리 단위 사이의 불일치 예입니다:
사양과 소프트웨어는 단일 키 입력이 단일 문자를 생성한다거나, 단일 문자가 단일 키 입력(수정 키를 포함하더라도)으로 입력되어야 한다거나, 전 세계의 키보드가 동일하다는 것을 요구하거나 이에 의존해서는 안 됩니다.
입력 단위 C005, 월드 와이드 웹을 위한 문자 모델 1.0: 기본 사항에서.
문자, 키 입력 및 글리프의 예, 월드 와이드 웹을 위한 문자 모델 1.0: 기본 사항에서.
키보드 입력에서 키 입력과 입력 문자가 항상 일대일로 대응하는 것은 아닙니다. 키보드에는 제한된 수의 키만 들어갈 수 있습니다. 일부 키보드는 단일 키 누름에서 여러 코드 포인트를 생성합니다. 다른 경우('dead keys')에는 키가 문자를 생성하지 않지만 이후 키 입력의 결과에 영향을 줍니다. 많은 문자 체계는 키보드에 넣기에는 문자가 너무 많으므로, 키 입력 시퀀스를 문자 시퀀스로 변환하는 더 복잡한 입력 방법에 의존해야 합니다. 다른 언어는 일부 문자를 특수 수정 키로 입력해야 할 수도 있습니다.
사소하지 않은 입력의 예는 문자, 키 입력 및 글리프의 예를 참조하십시오.
문자열은 보통 '문자'의 시퀀스로 이해됩니다. [Unicode]는 레거시 문자 인코딩을 사용하는 텍스트를 포함해 텍스트를 이해하고 다루는 데 기본이 되므로, 문자열의 기본 정의는 Unicode와 그 인코딩된 문자 개념에 의존합니다. 구체적으로는 다음과 같습니다:
string은 0개 이상의 Unicode Scalar Values로 이루어진 well-formed 시퀀스입니다.
문자열을 다루는 방법이 여러 가지이기 때문에, 서로 다른 사양의 요구를 지원하기 위해 "string"에 대한 서로 다른 정의가 발전해 왔습니다. 여러분의 사양에 필요한 것을 확실히 이해하고 가장 적절하고 정확한 정의를 사용하십시오.
웹에는 세 가지 문자열 유형이 있습니다:
USVString. Unicode 코드
포인트, 즉 Unicode Scalar Values에 기반한 문자열
DOMString. UTF-16 코드 단위에 기반한 문자열ByteString. 어떤 문자 인코딩
형식
(가급적 UTF-8)의
바이트에 기반한 문자열이 서로 다른 문자열 유형들의 차이 중 하나는 surrogate 코드 포인트를 처리하는 방식입니다. 코드 포인트(Unicode Scalar Value, 즉 문자를 나타냄)와 코드 단위(문자 인코딩 형식의 인코딩 단위)의 차이에 유의하십시오.
UTF-16 문자 인코딩 형식은 16비트
코드 단위를
사용합니다. scalar
values가 16비트보다 더
많이 필요한 문자는 surrogate 코드 단위 쌍을 사용하여
인코딩됩니다.
즉, "low surrogate"(U+D800-U+DBFF 범위) 뒤에 "high surrogate"(U+DC00-U+DFFF 범위)가 옵니다. Unicode는 이 범위의 코드 포인트를 비문자로 예약하여,
코드 단위가 UTF-16 안에서 일반 텍스트와 혼동되지
않도록 합니다.
USVString에서는 고립된 surrogate 코드 포인트가
유효하지 않으며, 구현은 문자열에서 발견된 모든 것을 Unicode replacement character(�U+FFFD REPLACEMENT CHARACTER)로 바꾸어야 합니다. 가장
일반적인
알고리즘이 scalar value에서 동작하는 문자열(예: percent-encoding)이나, 입력에서 surrogate를 처리할
수 없는 작업(예: 문자열을 네이티브 플랫폼 API로 전달하는 API)에는 USVString을 사용해야 합니다.
다음 참조들은 모두 이와 동등합니다:
DOMString에서는 짝이 없는 surrogate 코드 단위가
문자열에 나타날 수 있습니다. 대부분의 문자열 작업은 문자열 내부의 코드 단위를 해석할 필요가 없습니다.
DOMString을 지정한다는 것은
구현이 문자열의 내용을 검증할 필요가 없다는 뜻이며, 이는 대부분의 데이터 구조, 형식 또는 API에
이상적인 문자열 유형이 되게 합니다. [DOM]과 JavaScript 문자열은 DOMString을
문자열 유형으로
사용하며, [INFRA] 표준은 'string'이라는 용어를 DOMString을
의미하도록
정의합니다:
string은 부호 없는 16비트 정수의 시퀀스이며, 코드 단위라고도 합니다.
[INFRA]에서 코드 단위라는 용어를 사용하는 것은 서로 다른 크기 값(예: 바이트)을 어떤 문자 인코딩 형식에서도 가리킬 수 있는 더 일반적인 코드 단위 정의가 아니라, 구체적으로 UTF-16 문자 인코딩의 코드 단위를 가리킵니다.
ByteString은 문자를 바이트로
인코딩하는 데 사용되는 문자
인코딩 형식에 의존합니다. 레거시 문자
인코딩에는 "surrogates"라는 개념이 없으므로, 일반적으로 surrogate 코드 포인트를 인코딩할
방법이 없습니다. 유효한 UTF-8은
surrogate 코드 포인트를 허용하지
않습니다. 텍스트를 UTF-8로
인코딩하거나 UTF-8에서
디코딩할 때 이들은 �U+FFFD REPLACEMENT CHARACTER로 대체됩니다. UTF-16을 UTF-8로 변환할 때, 모든 surrogate pairs는 특정 scalar value를
인코딩하는 적절한
UTF-8 바이트 시퀀스로 변환됩니다.
문서 형식이나 프로토콜의 wire format을 정의할 때, 또는 [DOM]과
관련된 모든 프로세스, 또는 개별 문자 내용이 평가될 의도가 없는 불투명 값으로 문자열을 정의하는
프로세스에는 DOMString을 사용하십시오.
(이 사용 목록은 완전한 것이 아닙니다.)
Web Platform Design Principles [DESIGN-PRINCIPLES]의 IDL String Types
Character Model for the World Wide Web: Fundamentals의 String concepts, C012.
문자열의 코드 포인트를 반복하는 알고리즘을
정의할 때는 USVString을 사용하십시오.
USVString은 UTF-8
encode를 포함하는 모든 프로세스나, 짝이 없는 surrogate 코드 포인트가 오류를 생성할 수
있는 모든 곳에 사용하십시오.
[INFRA]의 Scalar value string 정의
단일 문서나 프로토콜 작업에서 DOMString과 USVString을 섞어 사용하지
마십시오. 대개는 USVString보다 DOMString을 선택하게 됩니다.
후자는 대부분의 문서 형식이나 프로토콜에 이점을 주지 않는 추가 처리를 요구하기 때문입니다.
4.6 문자 인코딩 선택하기에서 문자 인코딩과 관련된 추가 모범 사례를 참조하십시오.
웹상의 문자열: 언어 및 방향 메타데이터 [STRING-META]의 레거시 프로토콜이나 형식의 일부인 문자열
Unicode가 널리 채택되기 전에는 문자열을 byte
string으로 정의하는 것이 일반적이었습니다. 그러한 문자열은 단순히 문자나
코드 포인트의 시퀀스가
아니라
바이트 값의 시퀀스입니다. byte string의 익숙한 형태는 C 프로그래밍 언어의 char*입니다.
byte string을 처리하거나 해석하는 것은 문자 인코딩 형식에 의존합니다. 많은 레거시 문자 인코딩은 상태를 가집니다. 그러한 인코딩을 처리하려면 문자 상태가 유지되고 추상 문자가 성공적으로 디코딩, 처리 또는 수정될 수 있도록 바이트 버퍼의 시작부터 처리해야 하는 경우가 많습니다. 그러한 인코딩에서 주어진 바이트 값은 그 주변의 바이트에 따라 서로 다른 의미를 가질 수 있습니다. 예를 들어 정확히 같은 바이트 값이 단독으로는 어떤 문자를 나타낼 수도 있고, 앞선 바이트에 따라 다른 문자를 나타내는 멀티바이트 시퀀스의 일부일 수도 있습니다. 각 바이트나 바이트 시퀀스를 어떻게 해석할지 결정하는 규칙은 서로 다른 레거시 문자 인코딩마다 다릅니다. 잘못된 문자 인코딩을 사용해 byte string을 처리하면 잘못 형성된 문자(때때로 mojibake라고 불리는 효과)가 발생합니다.
UTF-8은 웹의 wire 및 문서 형식 [ENCODING]이나 일반적인 인터넷 [RFC3629]에서 선호되는 문자 인코딩입니다. 콘텐츠가 UTF-8로 인코딩되어 있으면, 이를 바이트 시퀀스로 다루어야 할 이유는 드뭅니다. 대부분의 Web API와 인터페이스는 특정 바이트 값보다 해당 문자를 나타내는 코드 포인트 시퀀스에 더 관심이 있습니다.
때때로 사양은 바이트 값의 저장, 해석 및 조작을 다루어야 합니다. 특히 많은 문서 형식과 프로토콜은
7비트 [ASCII]
바이트 사용을 중심으로 정의되었으며, 다양한 문자 또는 데이터 인코딩 방식을 사용하여 non-ASCII
데이터 값을 포함하거나 교환하는 것을 허용했습니다. 때로는 text 미디어 타입의
charset 매개변수처럼 문자 인코딩 형식을
지정함으로써 이를 수행합니다. 또는 어떤 특수 구문을 사용해 바이트 값을 인코딩함으로써 이를 수행할
수도 있는데, 그 예가 percent
encoding입니다.
선호되고 기본인 문자 인코딩 형식으로서 UTF-8이 널리 쓰이게 되면서, 대부분의 사양이 underlying 바이트 값에 접근하거나 이를 조작해야 할 필요가 줄어듭니다. UTF-8은 7비트 ASCII 텍스트도 유효한 UTF-8이 되도록 설계되었으며, 이는 ASCII에 기반한 형식을 인코딩하거나 디코딩할 때 중요할 수 있습니다.
특정 바이트 값과 상호작용할 이유가 있거나 UTF-8 문자 인코딩을
가정할 수 없는 경우가 아니라면, 바이트를 사용하여 정의되는 프로토콜이나 문서 형식의 필드에는
DOMString 또는,
드물게, USVString을
지정하십시오.
문제의 필드가 문자열로 취급되도록 의도되었다면, 바이트 값을 직접 다루려고 하는 것보다 Unicode 문자로 작업하는 편이 더 신뢰할 수 있습니다. 이러한 필드에 인코딩된 데이터는 wire format에서 [DOM], JavaScript 문자열 또는 여러분 플랫폼의 네이티브 Unicode 문자열 유형 같은 로컬 메모리 내 문자열 표현으로 역직렬화됩니다. 나중에는 어떤 문자 인코딩 형식 (보통, 그리고 가급적, UTF-8)을 사용하여 wire format으로 직렬화해야 합니다.
텍스트를 포함하지 않는 데이터나, 처리가 전혀 필요하지 않은 텍스트를 나타내는
바이트 시퀀스(예: 버퍼를 복사할 때)처럼 바이트 시퀀스를 다룰 때는 Uint8Array를
지정하십시오.
사양이 바이트를 사용하여 인코딩된 문자열을 다루어야 하고 Unicode로 또는
Unicode에서 변환하는 것이 부적절한 드문 경우에는 ByteString을
지정하십시오.
Web Platform Design Principles [DESIGN-PRINCIPLES]의 IDL String Types
ByteString은 범용 문자열
유형이 아닙니다. [WebIDL]에서
데이터 구조를 정의하는 데 사용하지 마십시오.
프로토콜이나 형식 사양에 의해 정의된 텍스트 데이터 객체는 단일 문자 인코딩이어야 합니다.
참조 처리 모델 C013, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
텍스트 처리를 포함하는 모든 사양은 이 목록의 나머지 권고 사항에서 설명하는 참조 처리 모델에 따라 텍스트 처리를 지정해야 합니다.
참조 처리 모델 C014, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
사양은 텍스트를 바이트나 글리프가 아니라 Unicode 문자 관점에서 정의해야 합니다.
참조 처리 모델 C014, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
사양은 그 텍스트 데이터 객체에 대해 Unicode 인코딩 형식으로 트랜스코딩할 수 있는 모든 문자 인코딩의 사용을 허용할 수 있습니다.
참조 처리 모델 C014, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
사양은 일부 문자 인코딩을 허용하지 않거나 사용 중단으로 표시하고, 다른 인코딩을 필수로 만들기로 선택할 수 있습니다. 실제 문자 인코딩과 무관하게, 지정된 동작은 처리가 다음과 같이 일어난 것과 동일해야 합니다: (a) 사양을 구현하는 애플리케이션이 수신한 모든 텍스트 데이터 객체의 문자 인코딩은 결정되어야 하며, 데이터 객체는 Unicode 문자 시퀀스로 해석되어야 합니다 - 이는 데이터 객체를 어떤 Unicode 인코딩 형식으로 트랜스코딩하고, 필요한 경우 문자 인코딩 레이블을 조정한 뒤, 그 Unicode 인코딩 형식으로 수신하는 것과 동등해야 합니다. (b) 모든 처리는 이 Unicode 문자 시퀀스에서 이루어져야 합니다. (c) 애플리케이션이 텍스트를 출력하는 경우, Unicode 문자 시퀀스는 사양에서 허용하는 것 중에서 선택한 문자 인코딩을 사용하여 인코딩되어야 합니다.
참조 처리 모델 C014, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
사양이 여러 텍스트 데이터 객체를 포함하는 경우(예: 외부 parsed entity를 참조하는 XML 문서), 이러한 데이터 객체가 서로 다른 문자 인코딩을 사용하도록 허용하기로 선택할 수 있습니다. 모든 경우에 참조 처리 모델은 모든 텍스트 데이터 객체에 적용되어야 합니다.
참조 처리 모델 C014, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
사양은 U+0000부터 U+10FFFF까지를 포함하는 전체 Unicode 코드 포인트 범위에서 코드 포인트를 임의로 제외해서는 안 됩니다.
참조 처리 모델 C070, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서.
사양은 Unicode가 내부 사용을 위해 예약한 코드 포인트의 사용을 허용해서는 안 됩니다.
참조 처리 모델 C079, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서.
여기에서 "surrogate code point"는 U+D800부터
U+DFFF까지를 포함하는 범위의 문자 값을 사용하는 것을 가리킵니다. 이러한 코드 포인트는
UTF-16 문자 인코딩이 보충
문자를 다룰 수 있도록 예약되어 있습니다. Surrogate는 항상 쌍으로 사용되며 UTF-16 인코딩이
사용될 때만 나타납니다. 단일 surrogate 코드 포인트는 "unpaired surrogate"라고 하며 절대 사용해서는
안 됩니다.
사양은 자신이 정의하는 형식의 구문 요소(마크업, 구분자, 식별자)에서 호환 문자를 제외해야 합니다.
호환 및 서식 문자 C050, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서.
사양은 사용자 정의 값에 대해 Unicode 전체 범위를 허용해야 합니다.
Unicode 대소문자 비구분 일치, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서.
사양은 특정 할당을 가진 사적 사용 영역 문자의 사용을 요구해서는 안 됩니다.
사적 사용 코드 포인트, C038, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
사양은 사적 사용 코드 포인트에 대한 합의를 정의하는 메커니즘의 사용을 요구해서는 안 됩니다.
사적 사용 코드 포인트, C039, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
사양과 구현은 사적 합의에 따른 사적 사용 코드 포인트의 사용을 금지해서는 안 됩니다.
사적 사용 코드 포인트, C040, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
사양은 Unicode에 없는 기호의 전송을 허용하거나 Unicode 문자의 특정 변형을 식별하기 위한 마크업을 정의할 수 있습니다.
사적 사용 코드 포인트, C041, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
사양은 적절한 경우 그림과 그래픽을 포함하거나 참조할 수 있도록 허용해야 하며, 이를 통해 그림이나 그래픽을 위해 문자 지향 메커니즘을 (오)용할 필요를 없애야 합니다.
사적 사용 코드 포인트, C068, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
역사적으로(특히 Unicode가 만들어지기 전 시기에는) 컴퓨터 시스템의 메모리나 저장소에 문자를 인코딩하고 직렬화하기 위한 서로 다른 방식과 함께, 많은 coded character sets가 일반적으로 사용되었습니다. ISO/IEC 8859에서 지정한 것과 같은 표준 기반 방식 외에도, 관련 문자 인코딩 형식을 갖는 독점 벤더 또는 플랫폼별 문자 집합도 많았습니다. 이 문서에서 레거시(비Unicode) coded character sets의 문자 인코딩 형식을 가리킬 때, 우리는 [Encoding]에 지정된 바이트에서 Unicode 코드 포인트로의 특정한 현대적 매핑을 의미합니다.
모든 문서 형식, 프로토콜 및 직렬화 형식에 UTF-8을 사용하십시오.
UTF-8은 거의 모든 애플리케이션에 가장 좋은 선택입니다.
새 프로토콜과 형식뿐 아니라 새 문맥에 배포되는 기존 형식도 UTF-8 문자 인코딩을 사용해야 합니다. 이 정책은 IETF 및 웹 표준에 적용되며 [RFC2277], [RFC3629], [Encoding], [design-principles] 및 그 밖의 많은 문서에 명시되어 있습니다. 레거시 문자 인코딩이 필요한 유일한 사양은 오래된 프로토콜이나 형식을 다루는 사양이며, 그 경우에도 UTF-8이 강력히 권장됩니다.
역사적 이유로 사양이 레거시 문자 인코딩을 허용하는 경우, 해당 사양은 문자 인코딩 집합을 Encoding Standard의 "Names and Labels" 섹션에 나열된 것으로 제한해야 합니다. 사적 합의를 제외하고 다른 인코딩은 사용해서는 안 됩니다.
문자 인코딩 식별, C021, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
문자 인코딩 식별, C022, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
문자 인코딩 식별, C023, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
여러 문자 인코딩 형식을 허용하는 사양은 텍스트의 인코딩을 명확하게 식별하는 필드나 매개변수 같은 메커니즘을 제공해야 합니다.
문자 인코딩의 선택과 식별, C015, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
문자 인코딩은 바이트 값만으로 신뢰성 있게 감지할 수 없습니다. UTF-8 이외의 인코딩이 허용된다면, 소비자가 인코딩이 무엇인지 결정할 수 있는 어떤 메커니즘이 있어야 합니다.
프로토콜, 형식 또는 API가 이미 문자 인코딩을 선택, 적용 또는 레이블링하는 규칙을 가진 형식을 기반으로 하는 경우, 사양은 문자 인코딩을 식별하기 위한 별도 메커니즘을 정의해서는 안 됩니다.
문자 인코딩의 선택과 식별, C017, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
문서 형식이나 프로토콜은 때때로 레거시 문자 인코딩 지원을 제공합니다. 그러한 형식 위에 구축된 사양은, 가능하다면, 적합한 구현이 UTF-8만 사용하도록 지정할 수 있습니다.
사양은 데이터의 인코딩을 결정하기 위해 휴리스틱을 사용하는 것을 제안해서는 안 됩니다.
문자 인코딩 식별, C028, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
사양은 문자 인코딩에 대한 정보가 여러 개이거나 충돌하는 경우를 위한 충돌 해결 메커니즘(예: 우선순위)을 정의해야 합니다.
문자 인코딩 식별, C028, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
입력하거나 편집하기 어려운 시퀀스를 일반 텍스트 편집기를 사용하여 도입할 수 있도록 문자 이스케이프를 제공하는 것이 일반적으로 권장됩니다. 이스케이프 시퀀스는 zero-width spaces, soft-hyphens, 다양한 bidi controls, mongolian vowel separators 등 보이지 않거나 모호한 Unicode 문자에 특히 유용합니다.
마크업에서 이스케이프를 사용하는 것에 대한 조언은, 대부분 다른 형식에도 일반화할 수 있는 마크업과 CSS에서 문자 이스케이프 사용하기를 참조하십시오.
적절한 이스케이프 메커니즘이 이미 존재한다면 사양은 새 이스케이프 메커니즘을 만들어서는 안 됩니다.
문자 이스케이프, C042, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
다음은 웹이나 일반적인 프로그래밍 언어에서 볼 수 있는 일반적인 이스케이프 메커니즘의 예입니다.
여기의 예제 문자는 😽U+1F63D KISSING CAT FACE WITH CLOSED EYES입니다.
| 발견되는 곳 | 유형 | 예 | 설명 |
|---|---|---|---|
| HTML, XML | 16진 NCRs | 😽 |
Unicode 코드 포인트의 16진 인코딩 |
| 10진 NCRs | 😽 |
Unicode 코드 포인트의 10진 인코딩 | |
| JavaScript, Ruby, Rust, [UTS18] | \u 구분 |
\u{1F63D} |
Unicode 코드 포인트의 16진 인코딩 |
| Perl | \x 구분 |
\x{1F63D} |
Unicode 코드 포인트의 16진 인코딩; 더 일반적인 u 대신 x 사용 |
| Java, JavaScript, JSON, C, C++, Python | \u UTF-16 코드 단위 |
\uD83D\uDE3D |
UTF-16 코드 단위의 고정 폭 16진 인코딩; 보충 문자는 surrogate pair로 인코딩됩니다 |
| C, C++, Python | \U UTF-32 코드 단위 |
\U0001f63d |
UTF-32 코드 단위의 고정 폭 16진 인코딩; 대부분 더 일반적인 BMP
문자에 더 효율적인 \u 이스케이프와 함께 사용됩니다.예: \u00c0 \U0001f63d \u12fe
|
| URLs | URL Encode | %F0%9F%98%BD |
UTF-8 바이트의 16진 인코딩; 각 바이트에는 세 문자가 필요하며, 각 코드 포인트에는 1~4바이트가 필요합니다 |
이스케이프 메커니즘을 선택할 때, Unicode Standard와 그 참조에서 16진수가 흔히 사용되므로 일반적으로 10진 인코딩보다 16진수가 선호된다는 점에 유의하십시오.
문자를 이스케이프하는 서로 다른 방법의 수는 (이상적으로는 하나로) 최소화해야 합니다.
문자 이스케이프, C043, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
이스케이프 구문은 각 문자 이스케이프에 대해 명시적 종료 구분자 또는 고정된 문자 수를 요구해야 합니다. 종료가 문자 이스케이프 자체에 허용되는 문자 집합 밖의 임의 문자에 의해 결정되는 이스케이프 구문은 피해야 합니다.
문자 이스케이프, C044, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
사양이 숫자를 사용하여 문자를 표현할 수 있는 문자 이스케이프를 정의할 때마다, 그 숫자는 문자의 Unicode 코드 포인트를 나타내야 하며, 16진 표기법이어야 합니다.
문자 이스케이프, C045, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
이스케이프된 문자는 이스케이프되지 않은 형태가 허용되는 모든 곳에서 허용되어야 합니다. 이는 구문적으로 중요한 문자가 이스케이프될 때 구문상의 의미를 잃는 것을 배제하지 않습니다. 특히 문자가 식별자와 주석에서 허용된다면, 그 이스케이프 형태도 허용되어야 합니다.
문자 이스케이프, C046, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
프로토콜, 데이터 형식 및 API는 텍스트 데이터를 논리적 순서로 저장, 교환 또는 처리해야 합니다.
시각적 렌더링 및 논리적 순서, C003, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서.
어떤 구현이 논리적 선택을 사용하든 시각적 선택을 사용하든 관계없이, 선택된 문자는 저장 시 논리적 순서로 유지되어야 합니다.
시각적 렌더링 및 논리적 순서, C075, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서.
범위 선택을 포함하는 프로토콜 및 API 사양은, 적어도 해당 프로토콜과 API 위에서 화면의 시각적 선택 구현을 지원하는 데 필요한 범위까지, 비연속 논리 선택을 제공해야 합니다.
시각적 렌더링 및 논리적 순서, C004, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서.
공백 문자는 타이포그래피에서 가로 또는 세로 공간을 나타내는 문자입니다. 공백 문자는 서로 다른 시각적 효과를 가질 수 있습니다. 어떤 공백 문자는 보이는 효과가 없고, 다른 문자는 페이지에서 더 크거나, 더 작거나, 가변적인 양의 공간을 나타냅니다.
"whitespace"라는 용어를 사용하는 사양은 그 용어가 무엇을 의미하는지 명시적으로 정의해야 합니다.
대부분의 사양은 공백을 Unicode White_Space 속성을 가진 문자로 정의해야 합니다.
ASCII로 제한되거나 공백으로 구분되는 형식(예: HTML 또는 CSS)의 어휘에서 사용하기 위해 공백을 정의하는 사양은 문법의 일부로 ASCII whitespace를 지정해야 합니다.
사양이 "whitespace"를 ASCII 또는 Unicode 공백과 다르게 정의하는 경우, 구체적인 코드 포인트를 나열해야 합니다.
ECMAScript와 같은 일부 사양은 자신만의 특정 요구 사항을 충족하기 위해 위와 다른 공백 정의를 제공했습니다.
다음 표는 여러 사양에서의 공백 문자 정의입니다.
white_space 속성 |
pattern_white_space 속성 |
ASCII whitespace (HTML) | CSS whitespace | ECMAScript | XML | |
|---|---|---|---|---|---|---|
 U+0009 (horizontal tab) |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
 U+000A (line feed) |
✓ | ✓ | ✓ | ✓ | ✓ | |
 U+000B (vertical tab) |
✓ | ✓ | ✓ | |||
 U+000C (form feed) |
✓ | ✓ | ✓ | ✓ | ||
 U+000D (carriage return) |
✓ | ✓ | ✓ | ✓ | ||
 U+0020 SPACE |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
 U+0085 (next line) |
✓ | ✓ | ||||
 U+00A0 NO-BREAK SPACE |
✓ | ✓ | ||||
 U+1680 OGHAM SPACE MARK |
✓ | ✓ | ||||
 U+2000 EN QUAD |
✓ | ✓ | ||||
 U+2001 EM QUAD |
✓ | ✓ | ||||
 U+2002 EN SPACE |
✓ | ✓ | ||||
 U+2003 EM SPACE |
✓ | ✓ | ||||
 U+2004 THREE-PER-EM SPACE |
✓ | ✓ | ||||
 U+2005 FOUR-PER-EM SPACE |
✓ | ✓ | ||||
 U+2006 SIX-PER-EM SPACE |
✓ | ✓ | ||||
 U+2007 FIGURE SPACE |
✓ | ✓ | ||||
 U+2008 PUNCTUATION SPACE |
✓ | ✓ | ||||
 U+2009 THIN SPACE |
✓ | ✓ | ||||
 U+200A HAIR SPACE |
✓ | ✓ | ||||
U+200E LEFT-TO-RIGHT MARK |
✓ | |||||
U+200F RIGHT-TO-LEFT MARK |
✓ | |||||
 U+2028 LINE SEPARATOR |
✓ | ✓ | ||||
 U+2029 PARAGRAPH SEPARATOR |
✓ | ✓ | ||||
 U+202F NARROW NO-BREAK SPACE |
✓ | ✓ | ||||
 U+205F MEDIUM MATHEMATICAL SPACE |
✓ | ✓ | ||||
 U+3000 IDEOGRAPHIC SPACE |
✓ | ✓ | ||||
 U+FEFF ZERO WIDTH NO-BREAK SPACE |
✓ |
일부 사양은 위 열 중 하나와 같은 정의를 사용하며 표에는 나열되어 있지 않습니다.
예를 들어 WebDriver는 white_space 속성을 사용하고, WebGPU Shading Language는
pattern_white_space 속성을 사용합니다.
사양에서 Unicode 코드 포인트를 나타내려면 U+XXXX 구문을
사용하십시오.
U+XXXX 형식은 사양에서 Unicode 코드 포인트를 참조할 때 잘 이해됩니다.
이들이 시퀀스로 나타날 때는 공백으로 구분됩니다. 추가 장식은 필요하지 않습니다. 코드 포인트는 네 자리,
다섯 자리 또는 여섯 자리 16진수를 포함할 수 있다는 점에 유의하십시오. 네 자리보다 적은 자릿수가
필요한 경우, 코드 포인트 번호는 0으로 채웁니다.
특정 코드 포인트를 설명하려면 Unicode 문자 이름을 사용하십시오.
Unicode는 할당된 각 Unicode 코드 포인트에 고유하고 불변인 이름을 부여합니다. 사양에서 특정 문자를
참조할 때 이러한 이름을 사용하면(U+XXXX 표기의 코드 포인트와 함께) 사양을 모호하지 않게 만드는 데
도움이
됩니다.
문자 명명 템플릿의 사용이 권장됩니다.
대부분의 문자에 대해 템플릿은 다음과 같습니다:
<span class="codepoint" translate="no"><bdi lang="??">&#xXXXX;</bdi><code class="uname">U+XXXX UNICODE_CHARACTER_NAME_ALL_IN_CAPS</code></span>
bdi 요소는 오른쪽에서 왼쪽으로 쓰는 예제 문자가 페이지 레이아웃을
방해하지 않도록 하는 데 사용됩니다. 닫는 bdi와 뒤따르는
code 요소 사이에는 줄바꿈이나 공백을 포함하지 마십시오. 간격과 표현은 스타일로
제어됩니다.
lang 속성은 주어진 문맥에 맞는 올바른 글꼴 선택을 얻기 위해
적절히 채워야 합니다. 동아시아 언어(예: Chinese, Japanese 또는 Korean)나 Arabic 문자 예제에서는
언어 태그를 선택할 때 때때로 더 큰 주의가 필요할 수 있습니다.
드물게 특정 언어의 경우, 자신의 스타일시트에서 font-family 및/또는
font-size로 bdi 요소의 스타일을 조정해야 할 수도 있습니다.
보이지 않는 문자(예: 제어 문자), 결합 문자 또는 공백의 경우 문자 대신 이미지를 사용하십시오. 또는
문자와 이를 둘러싼 bdi 요소를 생략할 수도 있습니다.
<span class="codepoint" translate="no"><img alt="..." src="..."><code class="uname">U+XXXX UNICODE_CHARACTER_NAME_ALL_IN_CAPS</code></span>
짧은 문자 시퀀스는 +로 구분하여 문자 이름을 나열해야 합니다.
문자 이름과 추가 마크업을 포함하는 것이 지나치게 현학적이고 사용성을 해치는 경우도 있지만, 의미를
손상시킬 만큼 너무 비격식적으로 작성하지 않도록 주의하십시오. 특히 긴 시퀀스는 때때로 코드 포인트만
나열하지만, 명확성을 위해 가능하면 문자 이름을 유지해야 합니다. 예는 이 문서의 합성된 "family" emoji에 대한 논의에서
찾을 수 있습니다: 👨👩👧👧U+1F468 U+200D U+1F469 U+200D U+1F467 U+200D U+1F467
일반적으로 사양에는 문자에 대한 정의와 그 문자와 연결된 의미론이 모두 필요하므로, 사양은 ISO/IEC 10646에 대한 참조를 포함하는지 여부와 관계없이 Unicode 표준에 대한 참조를 포함해야 합니다.
Unicode 표준 및 ISO/IEC 10646 참조하기, C062, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서.
사양이 발행된 뒤 할당되는 문자를 해당 사양에서 사용할 수 있기를 원한다면, Unicode 표준에 대한 일반 참조를 만들어야 합니다. 특정 버전에 의존하는 기능을 사용할 수 있고 시간이 지나도 변하지 않도록 보장하려면 Unicode 표준에 대한 특정 참조를 포함할 수 있습니다.
Unicode 표준 및 ISO/IEC 10646 참조하기, C063, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서.
Unicode 표준에 대한 모든 일반 참조는 이를 포함하는 사양의 발행일에 사용할 수 있는 Unicode 표준의 최신 버전을 참조해야 합니다.
Unicode 표준 및 ISO/IEC 10646 참조하기, C064, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서.
ISO/IEC 10646에 대한 모든 일반 참조는 이를 포함하는 사양의 발행일에 사용할 수 있는 ISO/IEC 10646의 최신 버전을 참조해야 합니다.
Unicode 표준 및 ISO/IEC 10646 참조하기, C065, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서.
이것은 이 섹션의 요구 사항만을 나열한 목록이며, 자체 검토에 사용할 수 있습니다. 여러분의 사양과 관련된 모든 요구 사항에 대해 한 줄의 첫 번째 체크박스를 선택하십시오. 여러분의 사양이 그 요구 사항을 충족하는 경우 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
분절, 색인화 등을 위한 텍스트 단위 선택하기
식별자 및 구문 콘텐츠의 문자열 동일성 일치
Unicode 정규화 다루기
Case folding
문자열 잘라내기 또는 길이 제한하기
문자열 연결
파일 및 경로 이름 다루기
정렬 및 검색 기능 지정하기
소프트웨어 프로세스가 부분 문자열에 접근하거나 문자열 안의 지점을 가리켜야 하고, 이를 위해 인덱스, 즉 문자열 안의 숫자 "위치"를 사용하는 상황은 많습니다. 이러한 인덱스가 웹의 구성요소 사이에서 교환되는 경우, 일관된 동작을 보장하기 위해 문자열 색인화에 대한 합의된 정의가 필요합니다. 여기서 발생하는 두 가지 주요 질문은 "계산 단위는 무엇인가?"와 "0에서 세기 시작하는가, 1에서 세기 시작하는가?"입니다.
사용자 상호작용이 주된 관심사인 애플리케이션에서는 자소 클러스터를 문자열 색인화의 기반으로 사용할 수 있습니다.
월드 와이드 웹을 위한 문자 모델: 기본 사항, 문자열 색인화, C071
복잡한 문자에서의 타이포그래피 문자 단위 자소 클러스터가 복잡한 문자를 분절하는 데 충분하지 않을 수 있는 상황.
문자 인코딩: 핵심 개념, 문자 및 클러스터
자소 클러스터 관점에서 색인화를 정의하는 사양은 반드시 다음 중 하나를 해야 합니다. (a) Unicode Standard Annex #29, Unicode Text Segmentation(UTR #29)에 정의된 확장 자소 클러스터 관점에서 자소 클러스터를 정의하거나, (b) 색인화 작업에 tailoring이 어떻게 적용되는지 구체적으로 정의해야 합니다.
월드 와이드 웹을 위한 문자 모델: 기본 사항, 문자열 색인화, C071
Unicode Standard Annex #29, Unicode Text Segmentation, 자소 클러스터 경계
복잡한 문자에서의 타이포그래피 문자 단위 자소 클러스터가 복잡한 문자를 분절하는 데 충분하지 않을 수 있는 상황.
문자 인코딩: 핵심 개념, 문자 및 클러스터
반례는 DOM Level 1에서 UTF-16을 사용하는 것입니다. UTF-16 코드 포인트 사용은 두 surrogate 문자 사이에 인덱스가 위치할 가능성을 열어 두며, 이는 심각한 문제를 일으킬 수 있으므로 권장되지 않습니다(6.5 문자열 잘라내기 또는 길이 제한하기 참조).
부분 문자열을 식별하거나 문자열 안의 지점을 식별하는 방법이 필요한 사양은 이 작업을 수행하기 위해 문자열 색인화 이외의 방법을 고려해야 합니다.
사양은 계산 단위 선택과 관계없이 단일 문자를 부분 문자열로 이해하고 처리해야 하며, 인덱스를 계산 단위 사이의 경계 위치로 취급해야 합니다.
API 사양은 단일 문자나 단일 '인코딩 단위'를 인수 또는 반환 유형으로 지정해서는 안 됩니다.
식별자 및 구문 콘텐츠의 문자열 동일성 일치는 다음 단계를 포함해야 합니다. (a) 비교할 문자열이 Unicode 코드 포인트 시퀀스를 구성하도록 보장한다. (b) 모든 문자 이스케이프와 include를 확장한다. (c) 적절한 case-folding 및 Unicode 정규화 단계를 수행한다. (d) 사양에 특화된 추가 일치 tailoring을 수행한다. (e) 결과 코드 포인트 시퀀스의 동일성을 비교한다.
일치 알고리즘, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서
식별자 및 구문 콘텐츠에서 문자열을 일치시키기 위한 기본 권고는 콘텐츠에 대해 정규화(즉, case folding 또는 Unicode Normalization)를 하지 않는 것입니다.
적절한 정규화 단계 수행하기, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서
'ASCII case fold' 및 'Unicode canonical case fold' 접근법은 특별한 상황에서만 사용해야 합니다.
적절한 정규화 단계 수행하기, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서
'Unicode compatibility case fold' 접근법은 사용해서는 안 됩니다.
적절한 정규화 단계 수행하기, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서
어휘 사양은 구문 콘텐츠와 문자 데이터 사이의 경계뿐 아니라 entity 경계(언어에 include 메커니즘이 있는 경우)도 정의해야 합니다.
정규화에 대한 추가 고려 사항, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서
사양은 주어진 어휘의 인코딩, 저장 또는 교환을 위해 Unicode 정규화 형식을 지정해서는 안 됩니다.
정규화에 대한 추가 고려 사항, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서.
구현은 교환, 읽기, 파싱 또는 처리되는 텍스트 데이터의 정규화 형식을 변경해서는 안 됩니다. 다만 콘텐츠를 Unicode 문자 인코딩으로 트랜스코딩하거나, case folding하거나, 기타 사용자가 시작한 변경과 같은 텍스트 변환의 부작용으로 그렇게 해야 하는 경우는 예외입니다. 소비자나 콘텐츠 자체가 비정규화된 표현에 의존할 수 있기 때문입니다.
정규화에 대한 추가 고려 사항, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서.
정준적으로 동등하지만 분리된 Unicode 문자 시퀀스가 보안 문제를 나타내는 경우, 사양은 이를 문서화하거나 health-warning을 제공해야 합니다.
정규화에 대한 추가 고려 사항, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서.
정규화된 텍스트 입력으로부터 비정규화된 출력을 생성할 수 있는 작업의 경우, 사양은 결과 출력이 정규화되어야 하는지 여부를 정의해야 합니다. 사양은 일부 작업에 대해 정규화를 수행하는 것이 선택 사항이라고 명시할 수 있습니다. 이 경우 기본값은 정규화가 수행되는 것이어야 하며, 정규화를 끄기 위해 명시적 옵션을 사용해야 합니다.
문서 형식에서 정규화를 지정할 때의 요구 사항, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서.
정규화를 요구하는 사양은 정규화 구현을 선택 사항으로 만들어서는 안 됩니다.
문서 형식에서 정규화를 지정할 때의 요구 사항, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서.
정규화에 민감한 작업은 구현이 먼저 검사를 통해 텍스트가 정규화된 형식임을 확인했거나 텍스트를 직접 다시 정규화하지 않는 한 수행해서는 안 됩니다. 이러한 규칙의 적용을 받지 않는 사적 시스템 안에서는 사적 합의를 만들 수 있지만, 외부에서 관찰 가능한 결과는 그 규칙을 준수한 것과 동일해야 합니다.
문서 형식에서 정규화를 지정할 때의 요구 사항, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서.
텍스트를 수정하고 정규화에 민감한 작업을 수행하는 정규화 텍스트 처리 구성요소는 각 수정 후 정규화가 일어난 것처럼 동작해야 하며, 그 결과 이후의 모든 정규화에 민감한 작업은 항상 정규화된 텍스트를 다루는 것처럼 동작해야 합니다.
문서 형식에서 정규화를 지정할 때의 요구 사항, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서.
문자열 값의 비교 또는 일치를 수행하는 사양은 Unicode 정규화와 관련하여 적절한 참고 또는 경고를 지정해야 합니다.
사양에서 Unicode 정규화를 사용하거나 채택하는 것은 보통 주어진 형식이나 프로토콜에서 일치가 어떻게 일어나는지를 정의하는 일의 일부입니다. 사양 작성자와 구현자가 관련된 복잡성 일부를 이해할 수 있도록, 국제화 워킹 그룹은 문자열의 일치와 비교에 대한 고려 사항을 설명하는 문서를 개발했습니다: 월드 와이드 웹을 위한 문자 모델: 문자열 일치 [CHARMOD-NORM].
사양이 내려야 하는 선택 중 하나는 사양 어휘의 일부로 정의된 다양한 "값"의 일치 과정에서 Unicode 정규화를 요구할지 여부입니다. 값은 보통 문서 형식이나 프로토콜의 구문 일부이며, 속성 이름이나 값, 요소 이름이나 값, ID 등이 포함됩니다. 권고에 따라 일치의 일부로 정규화를 사용하지 않는 사양은 콘텐츠 작성자를 위한 알림으로 다음 참고를 포함해야 합니다.
예제 참고. 필연적으로 이 버전은 무엇이 "값"을 구성하는지에 대해 구체적이지 않습니다. 사양은 더 구체적으로 작성하고자 할 수 있습니다.
이 사양은 비교 목적을 위한 값의 Unicode 정규화를 허용하지 않습니다. 시각적으로 그리고 의미적으로 동일하지만 서로 다른 Unicode 문자 시퀀스를 사용하는 값은 일치하지 않습니다. 콘텐츠 작성자는 값을 선택할 때 동일한 인코딩 시퀀스를 일관되게 사용하거나 잠재적으로 문제를 일으킬 수 있는 문자를 피하는 것이 좋습니다. 자세한 내용은 [CHARMOD-NORM]을 참조하십시오.
문자열 일치의 일부로 정규화를 요구하기로 선택한 사양은 다음 경고를 포함해야 합니다:
예제 경고. 필연적으로 이 버전은 무엇이 "값"을 구성하는지에 대해 구체적이지 않습니다. 사양은 더 구체적으로 작성하고자 할 수 있습니다.
이 사양은 값의 일치 중 Unicode 정규화를 적용합니다. 이는 영향을 받는 텍스트의 모양과 의미에 영향을 줄 수 있습니다. 자세한 내용은 [CHARMOD-NORM]을 참조하십시오.
위 내용이 여러분의 요구를 충족하지 않거나 사용법이 확실하지 않다면, 대안이나 지원을 위해 I18N WG에 문의하십시오.
형식, 프로토콜 또는 형식 언어의 정의 일부로 문자열 일치(파싱, 매칭, 토큰화 등의 작업을 포함할 수 있음)를 정의하는 사양과 구현은 사용되는 기준과 일치 형식을 정의해야 합니다. 이는 다음 중 하나여야 합니다. (a) 대소문자 구분 (b) Unicode full case-folding을 사용하는 Unicode 대소문자 비구분 (c) ASCII 대소문자 비구분.
Unicode의 Basic Latin(ASCII) 범위를 넘는 어휘에서 대소문자 비구분 일치를 정의하는 사양은 Unicode full casefold matching을 지정해야 합니다.
Unicode 대소문자 비구분 일치, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서.
Unicode의 Basic Latin(ASCII) 부분집합으로 제한된 어휘에서 대소문자 비구분 일치를 정의하는 사양은 ASCII 대소문자 비구분 일치를 지정할 수 있습니다.
ASCII 대소문자 비구분 일치, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서.
언어에 민감한 대소문자 구분 일치가 지정되는 경우, Unicode case mappings는 언어에 따라 tailoring되어야 하며, 각 tailoring에 사용되는 언어의 출처를 지정해야 합니다.
언어별 tailoring, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서.
어휘에서 대소문자 비구분 일치를 정의하는 사양은 언어에 민감한 대소문자 비구분 일치를 지정해서는 안 됩니다.
언어별 tailoring, 월드 와이드 웹을 위한 문자 모델: 문자열 일치에서.
일부 사양, 형식, 프로토콜 또는 그 구현은 주어진 문자열의 크기에 대한 제한을 지정해야 할 수 있습니다. 이는 처리, 메모리, 데이터 구조 크기 등의 제한과 같은 여러 이유 때문일 수 있습니다. 길이 제한은 종종 텍스트의 잘라내기나 크기 제한을 포함하므로, 사양과 그 구현은 텍스트가 손상되지 않고 선택된 제한이 특정 대상에게 기능을 사용할 수 없게 만들지 않도록 추가적인 주의를 기울여야 합니다.
사양은 구체적인 실무적 또는 기술적 제한이 없는 한 문자열 길이에 제한을 부과해서는 안 됩니다.
사양이 길이 제한을 지정하는 경우, 잘린 모든 문자열에는 생략 부호와 같이 문자열이 변경되었음을 나타내는 표시가 포함되어야 한다고 지정해야 합니다.
사양이나 형식에서 길이 제한이 필요할 수 있는 이유는 많습니다. 가장 일반적인 이유는 데이터에 underlying 크기 제한이 있기 때문입니다. 예를 들어 데이터베이스에 고정 크기 필드가 있거나, 패킷 크기와 같은 실무적 경계가 있거나, 저장 할당 또는 효율성과 관련된 다른 구현 세부 사항이 있을 수 있습니다. 또 다른 일반적인 이유는 표시 크기나 보이는 출력에 제한이 있을 수 있기 때문입니다.
문자열을 잘라낼 때는 문자열의 크기를 계산할 때 어떤 단위를 사용할지 결정해야 합니다. 어떤 경우에는 미리 정해진 이유로 잘라내기가 일어나므로 이것이 사양의 통제를 벗어납니다. 그러나 선택이 가능한 경우 몇 가지 일반 지침을 적용할 수 있습니다.
저장된 문자열을 일정 수의 시각적 텍스트 단위(예: 자소 클러스터)를 사용하여 잘라내도록 지정하는 것은 피하십시오.
시각적 길이 제한이 필요하다면, CSS text-overflow [css-overflow-4]와
같이 문자열을 변경하지 않고 텍스트 렌더링의 복잡성을 고려하는 텍스트 렌더링 또는 clipping 메커니즘을
사용하여 시각적 잘라내기를 지정하십시오.
사양은 때때로 사용 가능한 보이는 공간의 대리값으로 시각적 텍스트 단위의 수를 사용하려고 하여 시각적 제한을 처리하려 합니다. 이러한 제한은 한 줄의 문자 수 제한이나 모든 시각적 텍스트 단위가 동일한 렌더링 폭을 갖도록 하려는 시도와 같이 다양한 형태를 취할 수 있습니다. 시각적 텍스트 단위를 사용하는 것은 인코딩된 문자열의 코드 포인트 수나 코드 단위 수보다 그러한 임의 제한에 더 가깝게 대응합니다. 그러나 텍스트 표시의 특성상 이러한 노력은 대개 효과가 없습니다. 비례 폭 글꼴, 복잡한 문자, 스타일링, 접근성 기능 및 그 밖의 많은 요인이 이를 복잡하게 만듭니다. 거의 모든 경우, 시각적 텍스트 단위 제한은 실제로 픽셀 폭을 근사하려는 시도입니다. 제한을 실제로 측정하려면 표시 문맥의 글꼴 메트릭이 필요합니다. 접근성 설정과 같은 로컬 설정의 영향을 받을 수도 있습니다. 웹 페이지에서는 CSS text-overflow 속성이 텍스트 콘텐츠를 방해하지 않고 시각적 잘라내기를 제공합니다. Unicode 코드 포인트 수나 심지어 자소 클러스터 수를 기반으로 주어진 텍스트 조각의 크기를 추정하려는 시도는 대부분 헛된 일입니다.
문자열의 최대 허용 저장 길이를 제한하는 사양은 그 길이를 Unicode 코드 포인트 관점에서 지정해야 합니다.
대부분의 제한은 데이터베이스 필드의 크기나 프로토콜의 길이 제한과 같은 저장 제한과 실제로 관련되어 있습니다. 이러한 제한은 Unicode의 코드 포인트 관점으로 표현되거나, 특정 문자 인코딩의 코드 단위(예: 바이트) 관점으로 표현됩니다. 코드 포인트는 모든 Unicode 코드 포인트가 동일하게 취급되므로 최고의 사용자 경험을 제공합니다. 텍스트가 40개의 코드 포인트 뒤에서 잘리면 모든 언어와 문자가 작업할 동일한 수의 코드 포인트를 얻습니다. 반대로 크기 제한이 UTF-8의 바이트와 같은 코드 단위로 표현되는 경우, 주로 ASCII 문자를 사용하는 언어로 쓰는 사용자는 주어진 크기 제한에서 코드 포인트당 2, 3 또는 4바이트를 차지하는 문자로 주로 구성된 언어 사용자보다 훨씬 더 많은 문자(코드 포인트)를 얻습니다.
어떤 길이 제한에 맞추기 위해 문자열을 잘라내는 것을 허용하는 사양은 그러한 잘라내기가 시각적 텍스트 단위 경계(보통 자소 클러스터 경계로 근사됨)에서 일어나도록 요구해야 합니다.
어떤 길이 제한에 맞추기 위해 문자열 잘라내기를 수행하는 구현은 시각적 텍스트 단위 경계(보통 자소 클러스터 경계로 근사됨)에서 잘라야 합니다.
시각적 텍스트 단위의 중간, 예를 들어 결합 문자 시퀀스의 중간에서 잘라내면 남은 문자열의 의미가 바뀔 수 있습니다.
길이 제한이 어떻게 표현되는지(코드 포인트와 바이트 중 무엇인지)를 선택하는 것 외에도, 잘라내기 경계를 선택하는 문제도 있습니다. 텍스트는 코드 포인트의 중간에서 절대 나누어서는 안 됩니다. 그렇게 하면 문자가 손상됩니다. 텍스트는 자소 클러스터의 중간에서 나누어서는 안 됩니다. 이는 표시되는 문자의 모양과 의미를 바꾸기 때문입니다. 이는 의미가 영향을 받지 않도록 하기 위해 추가 코드 포인트를 제거해야 함을 의미할 수 있습니다.
때로는 문자열의 길이 제한이 데이터베이스 필드의 크기나 다른 곳에서 지정된 데이터 값에 할당된 바이트 수와 같은 외부 요인에 의해 결정됩니다. 또는 고정 길이 바이트 지향 wire protocol을 설명하는 것과 같은 실무적 설계 이유 때문에 길이 제한을 코드 단위로 지정해야 할 수도 있습니다. 그러한 사양과 그 구현은 아래 고려 사항을 포함하여 이것이 부과하는 추가 복잡성을 명시해야 합니다.
이 모범 사례는 UTF-8과 같은 멀티바이트 인코딩뿐만 아니라 16비트 코드 단위를 사용하는
UTF-16에도 동일하게 적용됩니다. U+10000과 U+10FFFF 사이의 Unicode 코드
포인트를 인코딩하는 데 사용되는 UTF-16 surrogate pair는 두 개의
코드 단위가
필요합니다. surrogate pair 중간에서 임의로 잘라내면 인코딩된 문자가 손상됩니다.
[DOM]을 참조하는 사양은 문자열 작업이 코드 포인트 경계로 제한되어야 한다고 지정해야 하며, 적절한 경우 시각적 텍스트 단위 또는 자소 클러스터 내부에서 시작하거나 끝나는 것을 피해야 합니다.
[DOM]과 상호작용하는 사양이나 API는 length, substringData, insertData, deleteData 등의 작업을 포함한 문자 데이터가 Unicode 코드 포인트가 아니라 UTF-16 코드 단위를 사용하여 지정된다는 사실에 대처해야 합니다. 이는 부적절한 문자(코드 포인트) 중간 잘라내기로 이어질 수 있습니다.
사양이 문자열 길이 제한을 코드 단위로 표현해야 하지만 문자열의 크기를 자유롭게 지정할 수 있다면, 허용 가능한 코드 포인트 수에 관련 문자 인코딩의 최대 인코딩 크기를 곱한 값을 기준으로 제한을 선택하십시오.
고정 크기 버퍼에 저장할 수 있는 코드
포인트의 수는 문자 인코딩 형식과 그 코드 단위에
의존합니다. 예를 들어 UTF-8은 Unicode 코드 포인트를 문자당
1~4바이트로 인코딩합니다. 따라서 최대 인코딩 크기는 네 개의 코드 단위입니다. 반대로 UTF-16은
1개 또는 2개의 16비트 코드 단위를 사용합니다. 따라서 최대 인코딩 크기는 두 개의 코드 단위입니다.
주어진 문자열이 적어도 50개의 코드
포인트를 저장해야 한다면,
UTF-8 바이트의 길이 제한은 50 * 4, 즉 200바이트가 됩니다. UTF-16의 길이 제한은
50 * 2, 즉 100개의 16비트 코드 단위(200바이트와 동일)가 됩니다. 이러한 제한은
문자열이 항상 적어도 50개의 코드 포인트를 저장할 수 있음을 보장하지만, 사용된 문자에 따라
특정 언어에서는 훨씬 더 많은 문자를 저장할 수 있을 수도 있습니다.
길이 제한을 선택할 때는 Unicode에서 서로 다른 문자와 언어의 요구를 염두에 두십시오. 주어진 문자 인코딩에서 텍스트 크기 제한이 코드 단위(예: byte-length limit)로 설정되어 있다면, 그 제한은 서로 다른 문자에서 문자 인코딩의 상대적 효율성을 고려해야 합니다. 특히 UTF-8은 [Unicode]의 멀티바이트 문자 인코딩입니다. UTF-8은 문자의 Unicode Scalar Value가 무엇인지에 따라 코드 포인트당 1~4바이트를 사용합니다.
텍스트 필드에 부과된 제한이 바이트 단위로 계산될 때, 해당 필드에 저장할 수 있는 문자 수는 어떤 문자가 저장되는지에 따라 달라집니다. 다양한 언어를 사용하는 사용자가 불리해지지 않도록 하려면, 해당 언어로 인코딩된 합리적인 문자 수를 허용해야 합니다.
사양이 코드 단위(예: 바이트)로 길이 제한을 지정하는 경우, 그 제한을 측정하는 데 사용되는 문자 인코딩을 지정해야 합니다. 그러한 제한은 레거시 문자 인코딩을 지정해서는 안 됩니다.
사양이 문자열의 잘라내기를 허용하거나 요구하고, 그 길이가 코드 단위로 표현되는 경우, 그 제한이 무엇을 의미하는지 알기 위해 문자 인코딩이 중요해집니다. 제한이 바이트 단위이고 레거시 문자 인코딩이 허용된다면, Unicode 데이터를 비Unicode 인코딩으로 변환하면 데이터 손실이 발생할 수 있음에 유의하십시오(대부분의 레거시 문자 인코딩은 Unicode의 부분집합만 인코딩하기 때문입니다).
여러 문자열을 함께 연결하여 자연어 텍스트 값을 생성하는 것은 국제화 anti-pattern입니다. 언어는 어순, 수량, 문법적 성 또는 격, 구두점 및 기타 많은 요구 사항에서 크게 다릅니다. 따라서 구현이 하위 문자열로부터 사람이 읽을 수 있는 메시지를 생성하도록 요구하거나 제안하는 것을 피하십시오.
사양이 구현이 사용자에게 표시될 텍스트를 만들거나 생성하도록 요구하는 경우, 사양은 텍스트 방향과 관련된 잠재적 문제를 피하는 방법에 대한 지침을 구현자에게 제공해야 합니다.
API, 프로토콜 또는 문서 형식에 대한 사양은 때때로 구현이 표시 이름이나 설명을 포함하는 필드를 만들거나 제공하도록 요구합니다. 이러한 문자열이 별도 부분들로 조립될 때, Unicode Bidirectional Algorithm [UAX9]이 조립된 문자열을 처리하는 방식 때문에 표현이나 이해에 문제가 발생할 수 있습니다. 그러한 경우 사양은 제대로 표시될 값을 만드는 방법에 대해 구현자에게 안내해야 합니다.
일부 사양은 다양한 구현이 파일 이름이나 파일 경로를 어떻게 구성하는지 정의해야 합니다. 한 가지 과제는 서로 다른 운영 체제가 사용하는 서로 다른 파일 시스템에서 일관되게 작동하는 정의를 만드는 것입니다. 이 섹션은 파일 이름이나 파일 경로에 대한 제한을 정의할 때의 일반 지침을 포함합니다. 이는 [EPUB-33]에서 개발된 요구 사항과 구현 경험에 기반합니다.
파일 이름은 길이가 255바이트로 제한되어야 합니다.
이 제한은 원래 MS-DOS뿐 아니라 특정 Unix 파일 시스템과 같은 일부 파일 시스템에서 발견되는 제한과 관련됩니다. 또한 이러한 파일 시스템에 의존하거나 그 제한을 포함한 PKZIP 같은 패키징 방식도 관련됩니다. 이들에서는 특정 "path element"(디렉터리 이름 포함)의 제한이 255바이트로 제한됩니다.
경로 이름은 길이가 65535바이트로 제한되어야 합니다.
이 제한은 UTF-16 문자 인코딩에서 경로 길이를 32760(32K) 코드 단위로 제한하는 FAT32나 NTFS와 같은 파일 시스템에서 발견되는 제한과 관련됩니다. 각 UTF-16 코드 단위는 16비트(또는 2바이트)를 차지하므로 바이트로 측정할 때 제한은 65,535가 됩니다. UTF-8에서 64K 바이트로 제한된 경로 이름은 UTF-8이 가변 폭 인코딩이므로 이러한 파일 시스템의 경로 길이 제한을 초과할 수 있다는 점에 유의하십시오.
파일 이름 및 경로 이름 정의는 다음 Unicode 코드 포인트를 사용해서는 안 됩니다.
이 문자들은 다양한 파일 시스템과 상호운용성 문제를 일으키는 것으로 알려져 있습니다. 콘텐츠의 상호운용성이 핵심인 경우, 사양과 구현은 파일 이름 지정에서 매우 신중해야 합니다. 제한된 문자 목록은 알려진 문제 영역 일부를 피하는 데 도움을 주기 위한 것이지만, 다른 모든 Unicode 문자가 지원된다는 것을 보장하지는 않습니다.
U+0022 QUOTATION MARKU+002A ASTERISKU+002F SOLIDUSU+003A COLONU+003C LESS-THAN SIGN
U+003E GREATER-THAN SIGNU+005C REVERSE SOLIDUS
U+007C VERTICAL LINE
U+007F DELU+0000...U+001FU+0080...U+009FU+E000...U+F8FFU+FFF0...U+FFFFU+F0000...U+FFFFFU+100000...U+10FFFFU+002E FULL STOP이 마지막
문자로 오는 경우(여기에는 많은 파일 시스템에서 특별한 의미를 갖는 파일 이름 .과
..가 포함된다는 점에 유의하십시오)
애플리케이션은 종종 정보나 콘텐츠 집합을 조직해야 합니다. 이는 자주 콘텐츠 정렬을 포함합니다. 숫자나 날짜와 같은 많은 비텍스트 데이터 유형은 내부 데이터 표현을 사용하여 쉽게 정렬할 수 있습니다. 그러나 텍스트 정보의 경우, 문자 인코딩의 특성과 "알파벳순"에 대한 사용자 기대가 추가적인 복잡성을 가져옵니다.
한 가지 핵심 선택은 텍스트 데이터 정렬이 엄격히 내부용인지, 아니면 결과가 사용자에게 표시될 것인지입니다.
사람이 보거나 상호작용하기 위한 것이 아닌 프로그램 내부의 빠르고 결정적인 텍스트 정렬이 필요한 사양 또는 구현은 문자열이 해당 문자열의 정의에 따라 정렬된다고 지정해야 합니다. scalar value strings(예: USVString 또는 많은 XML 프로세스)의 경우 오름차순 코드 포인트 순서를 지정하십시오. UTF-16 기반 문자열 유형(예: DOMString 또는 많은 JavaScript API)의 경우 오름차순 코드 단위 순서를 지정하십시오.
잠재적인 내부 정렬 시퀀스는 두 가지입니다. Unicode 코드 포인트로 정렬하거나 UTF-16 코드 단위로 정렬하는 것입니다. 어느 방식의 정렬이든 결과 목록은 특정 알파벳순이나 사전식 순서와 일치하지 않습니다.
코드 포인트로 정렬하는 것은 문자열이 USVString처럼 코드 포인트 시퀀스로 저장되고 처리될 때 의미가 있습니다. 코드 단위로 정렬하는 것은 문자열이 DOMString처럼 underlying 인코딩을 사용하여 저장되고 처리될 때 의미가 있습니다.
이 두 정렬 순서 모두 비교되는 문자열에 어떠한 유형의 정규화도 적용하지 않습니다. 이는 겉보기에 동등한 일부 문자열이 서로 다르게 비교됨을 의미합니다. 자세한 내용은 문자열 일치 [CHARMOD-NORM]를 참조하십시오.
사용자에게 표시하기 위해 자연어 텍스트 정렬을 다루어야 하는 사양이나 애플리케이션은 몇 가지 추가적인 복잡성에 직면합니다. Unicode는 Unicode Collation Algorithm [UTS10]의 일부로 기본 collation(정렬) 순서를 정의하며, 이는 특정 언어, 로케일 및 문화의 요구를 충족하도록 tailoring됩니다.
사용자에게 표시하기 위해 텍스트를 정렬할 때, 정렬 순서는 해당 애플리케이션에서 특정 사용자에게 가장 적절한 로케일에 따라 tailoring되어야 합니다. 따라서 표시 순서는 사용자마다 다를 수 있습니다.
Unicode Collation Algorithm [UTS10]
Locale Data Markup Language의 Collation 섹션 [UTS35]
Collation 단위, C007, 월드 와이드 웹을 위한 문자 모델: 기본 사항에서
언어와 문화는 텍스트를 정렬하거나 알파벳 또는 쓰기 체계를 사용하여 텍스트 데이터를 조직하는 방식이
다릅니다. 예를 들어 German 화자는 문자 üU+00FC LATIN SMALL LETTER U WITH DIAERESIS를 문자
u와 비슷하게 정렬되는 것으로 취급하지만(실제로 이 문자의 정확한 처리 방식이 약간
다른 두 가지 German 정렬 시퀀스가 있습니다), Danish 화자는 같은 문자를 알파벳에서 별도의
문자로 취급하고 문자 "y" 뒤에 정렬합니다.
정렬된 목록에 사용할 로케일을 결정하는 것은 여러 요인에 따라 달라질 수 있습니다. 예를 들어 애플리케이션은 데이터가 나타나는 페이지의 지역화에 따라 값 목록을 정렬할 수 있습니다. 다른 경우에는 user-agent의 런타임 로케일이나 API에 전달된 어떤 매개변수에 따라 정렬하는 것이 더 타당할 수도 있습니다. 중요한 것은 이 순서가 사용자마다 또는 시스템마다 다를 수 있음을 인식하는 것입니다.
이것은 이 섹션의 요구 사항만을 나열한 목록이며, 자체 검토에 사용할 수 있습니다. 여러분의 사양과 관련된 모든 요구 사항에 대해 한 줄의 첫 번째 체크박스를 선택하십시오. 여러분의 사양이 그 요구 사항을 충족하는 경우 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
리소스 식별자에서 비ASCII 문자 지원을 지정하는 상황은 복잡합니다. 리소스 식별자와 그 직렬화를 정의하는 사양이 적어도 세 가지(URI [RFC3986], IRI [RFC3987], 그리고 [URL]) 있기 때문입니다. WhatWG [URL] 사양은 브라우저와 다른 user agent의 실제 관행을 문서화하여 이러한 복잡성을 다루려는 시도입니다. URL 사양의 명시된 목표는 두 RFC를 모두 대체하는 것입니다.
일반적으로 웹의 문서 형식은 비ASCII 문자를 일반 텍스트로, 즉 "IRIs"로 인코딩하는 리소스 식별자를 사용합니다. HTTP [RFC9110]와 같은 프로토콜(이에 한정되지는 않음)은 비ASCII 문자를 퍼센트 인코딩을 사용한 바이트 시퀀스로 인코딩하는 리소스 식별자, 즉 "URIs"를 사용합니다. [RFC3986]은 문자를 바이트로 인코딩하기 위한 특정 문자 인코딩을 지정하지 않으므로, 퍼센트 인코딩 이스케이프는 잘못 해석되기 쉽습니다. 이를 방지하기 위해 많은 현대 프로토콜과 사양은 wire 형식과 프로토콜에서 지원되는 ASCII 부분집합으로 문자를 인코딩할 때, IRI에서 지정한 그대로 UTF-8 문자 인코딩을 리소스 식별자에 사용할 것을 기대합니다.
문서 형식이나 프로토콜은 비ASCII 문자를 포함하는 리소스 식별자를 지원해야 합니다. 많은 경우 주어진 리소스의 이름이나 식별자가 사용자 입력에서 생성되기 때문입니다. 사용자는 일반적으로 이러한 값에 자신의 언어를 사용하는 능력에서 제한되지 않으며 제한되어서도 안 됩니다.
문서 형식, 데이터 구조 또는 API를 정의하는 웹 사양은 리소스 식별자를 지정할 때 [URL]을 참조해야 합니다. [URL] 사양에서 지원하지 않는 경우에는 대신 IRI [RFC3987]를 지정할 수 있습니다.
프로토콜을 정의하는 사양은 wire 형식에서 사용할 리소스 식별자를 지정할 때 URI [RFC3986]를 참조할 수 있지만, 퍼센트 인코딩된 값을 문자로 해석할 때 UTF-8을 사용해야 한다는 추가 요구 사항을 포함해야 합니다.
[RFC3986]의 정의에 따르면, URI 참조는 ASCII의 부분집합으로 제한되며 비ASCII 문자를 직접 사용할 수 없습니다. 퍼센트 인코딩은 임의의 바이트 값을 이스케이프하기 위해 제공됩니다. 그러나 퍼센트 인코딩 자체는 제한된 가치만 있습니다. 주어진 바이트 시퀀스를 문자로 해석하거나 주어진 문자 시퀀스를 바이트로 인코딩하는 데 많은 서로 다른 레거시 문자 인코딩이 사용될 수 있기 때문입니다. Internationalized Resource Identifiers(IRIs) [RFC3987]는 [Unicode]의 UTF-8 인코딩에 기반한 통일된 접근 방식으로 리소스 식별자의 비ASCII 문자를 인코딩하고 해석하는 문제를 해결합니다.
사양은 리소스 식별자에서 허용되는 문자에 자체 제한을 부과할 수 있지만, 이러한 제한은 리소스 식별자의 구문, 전송 형식 또는 사양 자체가 정의한 다른 요소와 충돌하는 문자에 초점을 맞추어야 합니다.
일반적으로 권장되지는 않지만, 추가 제한을 고려하는 경우 추가 지침을 위해 [UAX31]과 [CHARMOD-NORM]을 검토하십시오.
이것은 이 섹션의 요구 사항만을 나열한 목록이며, 자체 검토에 사용할 수 있습니다. 여러분의 사양과 관련된 모든 요구 사항에 대해 한 줄의 첫 번째 체크박스를 선택하십시오. 여러분의 사양이 그 요구 사항을 충족하는 경우 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
마크업에서 요소와 속성 정의하기
마크업에서 일반 텍스트 처리하기
식별자 정의하기
U+D800부터 U+DFFF)나 non-character 코드 포인트를
허용해서는 안 됩니다. 더 보기
U+0000부터 U+001F) 및 C1
(U+0080부터 U+009F) 제어 문자를 허용해서는 안 됩니다. 더 보기
형식 언어, 문서 형식, 프로토콜 또는 API를 다루는 사양은 종종 마크업, 구문 또는 애플리케이션 내부 식별자를 정의해야 합니다. 이 섹션의 모범 사례는 이러한 것들을 정의할 때의 다양한 요구를 다룹니다.
마크업 언어나 주어진 마크업 언어에 기반한 구문을 정의하는 사양은 요소, 속성 및 그 값을 정의하는 데 관심이 있습니다. 예를 들어 [XML] DTD는 특정 문서 유형에서 유효한 요소와 속성을 정의합니다.
주어진 문서 형식, 프로토콜 또는 API를 정의하는 사양은 보통 예약된 키워드, 필드 이름 또는 허용된 값에 대한 식별자를 정의하는 데 관심이 있습니다. 이들 중 다수는 애플리케이션 내부 식별자이며, 그 이름과 값은 사양에 의해 완전히 정의됩니다. 어떤 경우 사양은 이들 중 일부 또는 전부가 사용자가 채우거나 이름 붙일 수 있는 사용자 제공 값이 되도록 허용할 것입니다.
사용자가 읽을 수 있는 콘텐츠를 포함할 속성 값을 정의하지 마십시오. 그러한 콘텐츠에는 요소를 사용하십시오.
모범 사례 3: 번역 가능한 속성 값 피하기, XML 국제화를 위한 모범 사례에서
사용자가 읽을 수 있는 콘텐츠를 포함하는 속성 값을 정의하는 경우, 요소에 포함된 텍스트와 별도로 해당 텍스트의 방향 및 언어 정보를 표시할 수 있는 수단을 제공하십시오.
작성자가 span과 유사한 요소나 구성을 사용하여 임의의 인라인 콘텐츠에
주석을 달 수 있는 방법을 제공하십시오.
모범 사례 14: span과 유사한 요소 정의하기, XML 국제화를 위한 모범 사례에서
국제화에 필요한 정보를 적용하기 위해 모든 텍스트 콘텐츠에 사용할 수 있는 span과 유사한 요소를 제공하십시오.
국제화 정보에는 언어 및 기본 방향 메타데이터, 언어의 인라인 변경, 양방향 텍스트 동작 변경, translate 플래그 등이 포함될 수 있습니다.
문서 형식의 일반적인 특징 중 하나는 다양한 식별자의 정의입니다. 여기에는 예약된 키워드와 사용자 정의 값이 포함됩니다. 상호운용성을 촉진하려면 구현이 식별자 값을 신뢰할 수 있고 일관되게 일치시킬 수 있어야 합니다. 이 문제를 자세히 살펴보려면 문자 모델: 문자열 일치 [CHARMOD-NORM]를 참조하십시오.
애플리케이션 내부 식별자(사용자에게 절대 표시되지 않고 항상 애플리케이션이나 프로토콜 안에서 일치 또는 처리에 사용됨)를 정의하는 사양은 콘텐츠를 인쇄 가능한 ASCII 부분집합으로 제한해야 합니다. ASCII 대소문자 비구분 일치가 권장됩니다.
때때로 사양은 콘텐츠 작성자가 상호작용하거나 여러 유형의 최종 사용자에게 의미 있는 식별자 집합을 정의해야 합니다. 허용 가능한 문자 집합을 ASCII로 제한하면 사용성이 저해되며, 특히 Latin 문자를 사용하지 않거나 ASCII 범위 밖의 문자를 사용하는 언어의 화자에게 그러합니다.
식별자가 사용자에게 보이거나 잠재적으로 보일 수 있는 경우, 모든 언어의 사용자가 결과 문서 형식이나 프로토콜을 동등하게 사용할 수 있도록 사양은 비ASCII Unicode 문자 사용을 허용해야 합니다. 대소문자 구분(즉, case folding 없음)이 권장됩니다.
애플리케이션 내부 식별자가 ASCII로 제한되지 않는 경우, 사양은 유효한 식별자를 시작할 수 있고 그 일부가 될 수 있는 문자를 정의해야 합니다.
Unicode Identifier and Pattern Syntax [UAX31]
예: ECMAScript 5, 섹션 7.6 Identifier Names and Identifiers
새 사양에서 식별자 namespace나 식별자 집합을 정의할 때의 핵심 문제 중 하나는 문서 형식을 파싱할 때 결합 기호와 특정 다른 문자(예: joiners 또는 bidi controls)를 처리하는 방식입니다. 식별자가 어떻게 "tokenized"(주변 텍스트에서 분리)될 수 있는지에 특별히 주의를 기울여야 합니다. 이를 수행하는 한 가지 방법은 식별자를 시작할 수 있는 문자 범위를 제한하여 일반 텍스트 처리가 나중에 식별자를 일치시키는 것을 방해하지 않도록 하는 것입니다.
Unicode Identifier and Pattern Syntax [UAX31]는 Java나 JavaScript와 같은 프로그래밍 언어에서 특히 사용되는 하나의 모델을 제공합니다. HTML과 CSS도 사용자 정의 식별자에 대한 문자 범위 정의를 제공하며, 예를 들어 다음 EBNF [XML] 생성식이 있습니다:
PCENChar ::=
"-" | "." | [0-9] | "_" | [a-zA-Z] | #xB7 | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x37D] |
[#x37F-#x1FFF] | [#x200C-#x200D] | [#x203F-#x2040] | [#x2070-#x218F] | [#x2C00-#x2FEF] |
[#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]HTML과 CSS 처리는 식별자와 토큰을 파싱할 때 Unicode 문자 속성(예: 주어진 문자가 결합 기호인지 여부)을 고려하지 않도록 정의되어 있습니다. 이를 통해 식별자가 결합 문자로 시작해도 안정적으로 처리될 수 있지만, 일반 텍스트 편집기는 그 값을 동일하게 처리하지 않을 수 있습니다.
사양은 whitespace 처리와 관련하여 식별자를 정의할 때 주의를 기울여야 합니다. ASCII 문자 U+0020 SPACE 및 U+0009 TAB 이외에도 Unicode 가로 whitespace 문자가 있다는 점에
유의하십시오.
필드와 값에는 로케일 중립적이고 문화적으로 중립적인 이름을 선택하십시오.
필드 이름과 값을 포함하여 식별자를 정의할 때는 가능한 한 문화적으로 중립적인 이름을 선택하십시오. 예를
들어 (미국에 특화된) ZIPCode보다 postalCode를 선호하거나, 더 문화적으로
연결된 firstName/lastName보다 givenName/familyName을 선호하십시오.
일부 사양은 문서 형식이나 프로토콜에서 주어진 필드에 대한 값을 정의해야 합니다. 데이터 값이 숫자나 날짜와 같은 특정 유형과 연결된 경우, 필드의 형식은 보통 [XMLSCHEMA11-2] 또는 [JSON-SCHEMA]와 같은 잘 알려진 schema를 사용하여 정의됩니다.
기계가 읽도록 의도된 지역화 불가능한 문자열 데이터 값을 정의하는 사양은 자연어 텍스트와 쉽게 혼동되지 않는 값을 사용해야 합니다.
많은 프로토콜, 문서 형식 또는 데이터 구조는 내부 사용을 위한 열거 값을 정의합니다. 이러한 값은 사람이 직접 보도록 의도된 것이 아닙니다. 때로는 사양, 프로토콜 또는 API를 다루는 사용자나 주어진 문서 또는 상호작용을 디버그해야 할 수 있는 사용자를 돕기 위해 이러한 값에 설명적인 이름(종종 영어)을 부여하는 것이 유용합니다. 사양에서 이러한 값을 할당할 때, 선택된 이름은 사용자가 그 값을 자연어 텍스트처럼 표시할 수 있다고 가정하지 않도록 "code-like"하게 보여야 합니다.
여러 그룹은 애플리케이션 내부 값을 "code-like"하게 보이도록 만들기 위해 여러 스타일을 채택했습니다. 여러분의 사양에 가장 적합한 것을 선택하십시오. 여기에는 다음이 포함됩니다:
U+005F LOW LINE)로 구분됩니다.사람이 읽을 수 있는 문자열, 특히 설명적인 성격의 문자열을 포함하는 필드는 자연어 문자열로 간주되어야 합니다. 이는 그 문자열을 보는 사용자가 소프트웨어 개발자로 예상되는 경우에도 마찬가지입니다. 문서나 데이터 구조의 그러한 각 필드에 대해 언어 태그와 문자열 방향을 결정할 수 있어야 합니다.
이 유형의 필드에 대한 일반적인 이름에는 name, description,
title, message, 또는 때때로 value가 포함됩니다. 이를
판단하는 한 가지 테스트는, 사양 작성자나 사용자로서 필드의 콘텐츠를 SNAKE_CASE_SHOUTED로
만드는 것이 불편하다면, 그 필드는 자연어 텍스트로 간주하는 것이 더 나을 수 있다는 것입니다.
사람이 소비하도록 의도된 필드는 지역화 가능해야 합니다.
이는 다양한 형태를 취할 수 있습니다. 예를 들어 사양이나 프로토콜은 언어 협상을 허용하고 가장 잘 일치하는 지역화된 문자열만 반환할 수 있습니다. 또는 주어진 리소스가 소비자가 선택할 수 있는 여러 언어를 포함할 수도 있습니다.
필드 이름과 기타 열거 값은 지역화 가능한 표시 이름으로 감싸야 합니다.
필드 이름과 열거 값은 이름이 일반 텍스트처럼 보이고 사용자가 이해할 수 있더라도 자연어 텍스트가 아닙니다. 이러한 필드와 값에는 언어 또는 방향 메타데이터가 연결되어서는 안 되며, 필요한 경우 구현자는 적절한 지역화 wrapper를 제공하도록 사양의 안내를 받아야 합니다.
이것은 이 섹션의 요구 사항만을 나열한 목록이며, 자체 검토에 사용할 수 있습니다. 여러분의 사양과 관련된 모든 요구 사항에 대해 한 줄의 첫 번째 체크박스를 선택하십시오. 여러분의 사양이 그 요구 사항을 충족하는 경우 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
세로 텍스트
before 및 after
줄 위치에 의존해서는 안 됩니다. 더 보기vertical-
값과 (오직) 동등한 세로 쓰기 모드는 문자의 기본 텍스트 방향을 적용하기 위해 [UTR50]을 사용해야 합니다. (이는 CSS의
sideways-와 동등한 쓰기 모드에는 적용되지 않습니다.)
더 보기
sideways-lr 및 sideways-rl 같은 값을 제공해야 합니다. UTR50은 이러한 경우에 적용할 수
없습니다. 더 보기
RTL/bidi 텍스트
텍스트 방향이 달라질 때 box 위치 좌표 설정하기
논리적 속성(TBD)
초서체 텍스트
Ruby 텍스트 주석
rb rb rt rt에 가까운 시퀀스로 배열될 수 있도록)을
지원해야 합니다. 더 보기rb 요소처럼 ruby base를 위한 명시적 요소를 사용할 수 있게 해야 합니다.
더 보기
글꼴 관리(TBD)
밑줄 및 윗줄 같은 텍스트 장식은 선이 ink를 건너뛸 수 있도록 해야 합니다.
텍스트에서 윗줄과 밑줄까지의 거리를 지정할 수 있어야 합니다.
밑줄과 같은 텍스트 장식에서 ink를 건너뛰는 것은 Arabic 같은 일부 문자 체계에는 적절하지 않을 수 있으며, 그러한 문자 체계에서는 대신 밑줄을 baseline에서 더 멀리 이동하는 것을 선호합니다.
Japanese, Chinese, Korean, Mongolian 등의 언어에 대해 텍스트를 세로로 렌더링할 수 있어야 합니다.
세로 텍스트는 LTR(예: Mongolian) 및 RTL(예: Japanese)의 줄 진행을 지원해야 합니다.
기본적으로, 줄이 왼쪽에서 오른쪽으로 쌓이는 세로 텍스트(예: Mongolian)에서 텍스트 장식,
ruby 등은 CJK 세로 텍스트와 같은 쪽에 나타나야 합니다. 배치는 before 및 after 줄 위치에 의존해서는 안 됩니다.
CSS의 vertical- 값과 (오직) 동등한 세로 쓰기 모드는 문자의 기본
텍스트 방향을
적용하기 위해 [UTR50]을 사용해야 합니다. (이는 CSS의 sideways-와 동등한 쓰기 모드에는 적용되지 않습니다.)
쓰기 모드는 가로 문자 텍스트 줄을 세로로 회전할 수 있도록 CSS의 sideways-lr 및 sideways-rl 같은 값을
제공해야 합니다. UTR50은 이러한 경우에 적용할 수 없습니다.
기본적으로, 보통 가로로 쓰이는 문자 체계의 글리프는 세로 텍스트에서 문자의 위쪽이 세로줄의 오른쪽을 향하도록 줄을 따라 배치되어야 하지만, 이들이 upright 방향으로 줄 아래로 진행할 수 있도록 하는 메커니즘도 있어야 합니다. 그러한 메커니즘은 최소 텍스트 단위로 시각적 텍스트 단위(예: 자소 클러스터)를 사용해야 하지만, 필요한 경우 둘 이상의 자소 클러스터를 포함하는 음절 클러스터를 하나의 단위로 취급할 수 있도록 해야 합니다.
세로줄의 upright Arabic 텍스트는 분리형 글자 형태를 사용해야 하며, 텍스트 순서는 위에서 아래로 읽혀야 합니다.
일부 문자 시퀀스(특히 숫자)가 세로줄 안에서 가로로 진행할 수 있어야 합니다(tate chu yoko).
글자꼴 기울기를 가능하게 하는 사양은 특정 언어의 요구에 따라 문자가 오른쪽 또는 왼쪽으로 기울 수 있도록 제공하는 것이 권장됩니다.
Box 위치 좌표는 텍스트가 가로인지 세로인지 고려해야 합니다.
사용자 인터페이스나 웹 페이지를 지역화할 때 RTL 및 LTR 버전에 대해 mirror-image를 만드는 것은 일반적입니다.
예를 들어 English 콘텐츠가 있는 창의 왼쪽 근처에 나타나는 box는 콘텐츠가 Arabic이나 Hebrew인 경우 창의
오른쪽 근처에 나타날 가능성이 큽니다. 절대 geometry를 사용해야 할 강한 이유가 없는 한, 현재 문맥의
기본 방향에 따라 이것이 자동으로 바뀌는 것이 바람직합니다. 이를 달성하는 한 가지 방법은 위치를 나타내기
위해 left 및 right 대신 start 및 end 같은
키워드를 사용하는 것입니다.
Arabic, Mongolian, N'Ko와 같은 초서체 텍스트에서 연결된 글자에 투명도가 적용될 때 겹침이 노출되어서는 안 됩니다.
텍스트 stroke나 shadow를 추가할 때, 초서체 문자 텍스트에서 연결된 글자가 이웃 글자와 분리되어서는 안 됩니다.
base 텍스트 옆의 'Ruby' 스타일 주석은 가로 및 세로 쓰기 모드 모두에서 Chinese, Japanese, Korean 및 Mongolian 텍스트에 대해 지원되어야 합니다.
Ruby 구현은 Traditional Chinese를 위한 zhuyin fuhao(bopomofo) ruby를 지원해야 합니다.
Ruby 구현은 tabular content model(ruby 내용이 rb rb rt rt에 가까운 시퀀스로 배열될 수 있도록)을 지원해야 합니다.
Ruby 구현은 HTML의 rb 요소처럼 ruby base를
위한 명시적 요소를 사용할 수 있게 해야 합니다.
Ruby 구현은 주석이 base 텍스트의 한쪽 또는 양쪽에 나타날 수 있도록 해야 합니다.
HTML의 ruby 마크업은 Chinese, Japanese, Korean 및 Mongolian 요구 사항을 위해 특별히 설계되었으며, 일반 glossing 메커니즘으로 사용해서는 안 됩니다.
줄 높이는 English보다 큰 문자를 허용해야 합니다.
Box 크기는 번역 시 텍스트 확장을 허용해야 합니다.
줄바꿈은 비Latin 문자 체계에 필요한 특수 규칙을 고려해야 합니다.
다양한 비Latin 쓰기 체계는 단순히 단어 사이 공백에서 텍스트를 줄바꿈하지 않습니다. 준수해야 하는 추가 규칙이 있습니다. 예:
추가 배경은 CSS Text Level 3 사양을 참조하십시오. (필요하다면 이 튜토리얼이 추가 예를 제공합니다.)
presentational 마크업 b, i 또는
u는 쓰기 체계 간에 상호운용되지
않으며, 더 나아가 지역화에 불필요한 문제를 일으킬 수 있으므로 피하는 것이 가장 좋습니다. 또한 일부
문자 체계에는 강조와 같은 것에 대해 native 접근법이 있으며, 이는 bolding, italicisation 등을 포함하지
않고, 그것들과 매우 다를 수 있습니다.
HTML의 경우에는 레거시 이슈가 있었지만, 여러분의 사양에 그러한 이슈가 없다면, 권고는 텍스트의 표현을 결정하기 위해 styling을 대신 사용하고, 모든 마크업이나 tagging은 일반적인 의미론적 접근을 허용해야 한다는 것입니다.
b 및 i 태그를 둘러싼 문제에 대한 설명은 <b> 및 <i>
요소 사용하기를 참조하십시오.
이것은 이 섹션의 요구 사항만을 나열한 목록이며, 자체 검토에 사용할 수 있습니다. 여러분의 사양과 관련된 모든 요구 사항에 대해 한 줄의 첫 번째 체크박스를 선택하십시오. 여러분의 사양이 그 요구 사항을 충족하는 경우 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
로케일 영향을 받는 값 다루기
시간 다루기
개인 이름 다루기
숫자 다루기
Form 설계하기
사용자 입력(TBD)
예제 만들기(TBD)
지역화
언어와 문화적 선호를 지원하는 소프트웨어 시스템은 국제화되었다
고 합니다.
국제화된 시스템은 사용자 선호를 기반으로 언어 또는 문화에 특화된 처리를 제공하기 위해 API를 사용합니다.
이러한 사용자 선호는 일반적으로 로케일
이라고 합니다. 일반적인 국제화 용어에 대한 자세한 내용은
Language Tags and Locale Identifiers [LTLI]를 참조하십시오.
데이터 형식을 정의할 때 로케일 중립적인 직렬화 형식을 사용하십시오.
기계가 읽을 수 있고 특정 언어나 문화에 특화되지 않은 데이터 값은 여러 문화적 표현 중 하나를 사용하는 값보다 더 오래 유지되고 오해될 가능성이 적습니다. 날짜, 통화, 숫자 같은 것은 비슷해 보일 수 있지만 서로 다른 로케일에서는 다른 의미를 가질 수 있습니다. 예를 들어 문자열 4/7로 표현된 날짜는 사용자의 선호에 따라 4월 7일 또는 7월 4일로 읽힐 수 있습니다. 마찬가지로 €2,000은 2천 유로이거나 2유로를 지나치게 정밀하게 표현한 것일 수 있습니다. 로케일 중립 형식을 사용하면 시스템은 사용자의 언어나 위치에 따라 달라지는 특정 교환 규칙을 설정할 필요를 피할 수 있습니다. 데이터가 이미 로케일별 형식인 경우, 로케일 매개변수(보통 언어 태그의 형태)를 제공하여 로케일과 언어를 명시하면, 사용자가 데이터 작업 방법을 결정하거나 자동 번역 서비스를 사용할 수 있게 할 수 있습니다.
대부분의 일반적인 데이터 직렬화 형식은 로케일 중립적입니다. 예를 들어 [XMLSchema-2]의
xsd:integer 및 xsd:date 같은 유형은 로케일 중립적인 데이터 교환을 의도합니다.
로케일 중립 표현을 사용하면 복잡한 파싱이나 오해 없이 데이터 값을 정확하게 처리할 수 있고, 또한 어떤
로케일에서든 데이터 소비자에게 가장 편안한 형식으로 데이터를 표시할 수 있습니다. 예를 들어 "€2000,00"을
문자열로 저장하기보다 다음과 같은 데이터 구조를 교환하는 것이 강력히 선호됩니다:
…
"price" {
"value": 2000.00,
"currency": "EUR"
}
…달력 및 날짜 체계를 정의할 때 common era 이전의 날짜를 허용하거나, 적어도 가장 일반적인 범위 밖 날짜의 처리를 정의하도록 하십시오.
시간 또는 날짜 데이터 유형을 정의할 때, 시간대 또는 UTC와의 관계가 항상 정의되도록 하십시오.
"floating"인 시간 또는 날짜 데이터 유형을 incremental 유형으로/에서 변환하는 것에 대해, 필요한 경우 Time Zones WG Note를 참조하는 health warning을 제공하십시오.
날짜 및 시간 데이터 유형에서 leap seconds를 허용하십시오.
이는 1분의 초 수가 0부터 60까지 허용될 때 가끔 발생합니다(즉, 그 1분에는 61초가 있습니다).
날짜 및 시간 값을 논의할 때 일관된 용어를 사용하십시오. 시간대에 독립적인 값에는 'floating' time을 사용하십시오.
시간대 정의와 시간대 offset을 분리하여 유지하십시오.
시간대를 식별하기 위해 IANA time zone ID를 사용하십시오. 시간대의 proxy로 offset이나 LTO를 사용하지 마십시오.
시간대를 식별하기 위해 별도 필드를 사용하십시오.
"week"에 대한 규칙을 정의할 때, 문화적으로 특화된 규칙을 적용할 수 있도록 허용하십시오.
예를 들어 주말이 항상 토요일/일요일인 것은 아니며, 주의 첫날이 항상 일요일[또는 월요일 또는...]인 것도 아닙니다.
연도의 주 번호에 대한 규칙을 정의할 때, 문화적으로 특화된 규칙을 적용할 수 있도록 허용하십시오.
비Gregorian 달력이 허용되는 경우, "month" 필드가 13(undecimber)까지 갈 수 있음을 명시하십시오.
개인 이름을 사용하는 애플리케이션(웹 form, 데이터베이스, 온톨로지 등)을 만드는 개발자는 다른 나라의 이름이 얼마나 다를 수 있는지 모르는 경우가 많습니다. 그들은 외국 사용자에 대해 너무 많은 것을 가정하는 방식으로 form이나 데이터베이스를 만듭니다. 이 섹션은 전 세계의 개인 이름을 다루기 위한 지침을 제공합니다.
given name(s)와 family name(s)를 별도로 저장하거나 접근할 필요가 정말 있는지 확인하십시오.
나눌 것인가, 나누지 않을 것인가?, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
전 세계의 이름은 구성과 구성 요소의 순서가 크게 다릅니다(전 세계의 개인 이름 참조). 예를 들어 어떤 사람의 이름을 데이터베이스에 저장하기 위해 더 작은 부분으로 나눈 다음, 나중에 이를 검색하려고 할 때, 특히 어떤 재구성이 필요한 경우 어려움이 생길 수 있습니다. 어려움에는 이름의 어느 부분이 데이터베이스의 어느 필드에 속하는지 이해하는 것(특히 데이터베이스 필드보다 부분이 더 많거나 적을 때)과, 데이터베이스에서 누군가의 이름을 실제 사용을 위해 가져올 때 이름 부분의 순서를 처리하는 것이 포함됩니다.
다양한 배경의 사람들로부터 이름을 받을 form이나 데이터베이스를 설계하는 경우, given name 및 family name 같은 항목에 별도 필드가 정말 필요한지 스스로 물어봐야 합니다. 이는 데이터로 무엇을 해야 하는지에 따라 달라지지만, 가능한 경우에는 사용자가 제공한 full name을 그대로 사용하는 것이 분명히 더 간단합니다.
이름 길이에 제한을 두지 마십시오. 제한을 둔다면 긴 문자열을 허용하십시오.
나눌 것인가, 나누지 않을 것인가?, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
어떤 문화권의 이름은 여러분 자신의 이름보다 훨씬 더 길 수 있다는 점을 염두에 두십시오. 긴 이름을 입력할 수 있도록 필드를 충분히 길게 만드십시오. 또한 이름이 한 글자보다 길 것이라고 가정하지 마십시오.
특히 길이를 바이트 단위로 세는 것은 피하십시오(4.2 'string'의 정의 선택하기 참조). UTF-8에서 네 글자 일본어 이름이 4바이트에 들어갈 것이라고 가정하지 마십시오. 실제로는 12바이트가 필요할 가능성이 큽니다.
이 섹션의 지침은 저장 또는 표시를 위해 사람의 이름을 나누는 것이 필요하다고 결정된 경우에 적용됩니다.
'first name'과 'last name' 레이블 사용을 피하십시오. 'given name(s)' 및 'family name(s)' 같은 대안을 고려하십시오.
이름을 나누기 위한 전략, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
'first'와 'last'라는 용어 사용은 보통 family name을 given name 앞에 쓰는 사람들에게 혼란스러울 수 있습니다. 미국의 사용자를 대상으로 하는 form에는 'first'와 'last'를 사용하는 것이 허용되는 것처럼 보일 수 있지만, 그 form은 결국 미국 안팎의 서로 다른 문화적 배경을 가진 사람들이 사용할 수 있습니다.
또한 어떤 문화권에서는 이것이 여전히 문제가 된다는 점도 염두에 두십시오. 예를 들어 Icelanders는 실제로 family name이 없고 given name과 patronymic을 갖습니다(Given name and patronymic 참조). 하지만 고도로 지역화된 맞춤화를 하지 않는 한, 이것이 일반적 해결책으로 우리가 할 수 있는 최선일 가능성이 큽니다.
full name 필드 외에, 특정 목적에 사용해야 하는 이름의 일부를 사용자가 제공할 수 있는 하나 이상의 추가 필드를 두는 것이 타당한지 고려하십시오.
이름을 나누기 위한 전략, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
누군가가 연락할 때 사용자가 어떻게 불리기를 원하는지 별도로 묻는 것을 허용하십시오.
이름을 나누기 위한 전략, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
예를 들어 어떤 경우에는 이름 목록을 알파벳순으로 정렬하거나, 연락할 때 부르는 등의 목적으로 이름의 일부를 식별하고 싶을 수 있습니다.
이 추가 필드는 긴 이름 구성 요소 목록에서 적절한 이름을 찾거나, 별명을 처리하는 데에도 유용할 것입니다 (예를 들어 Thailand에서는 별명이 사람을 지칭하는 데 흔히 사용됩니다).
때로는 이름의 일부를 사용해 그 사람에게 직접 말하거나 그 사람을 지칭하고 싶기 때문에 별도 필드를 선택할 수 있습니다. 예를 들어 소셜 미디어 앱이 "David's contacts"라고 말하는 경우입니다. 또는 이메일 상단에 이름을 넣어 보내고 싶기 때문일 수도 있습니다. 여기서는 이름 구문 때문에 문제가 생길 수 있을 뿐 아니라, 격식에 대한 전 세계의 다양한 기대도 고려해야 한다는 점에 유의하십시오(낯선 사람이 자신을 given name으로 부르는 것을 모두가 좋아하는 것은 아닙니다). 예를 들어 프로필을 설정할 때, 그 사람이 어떻게 불리기를 원하는지 별도로 묻는 편이 더 나을 수 있습니다.
사람 이름의 일부를 별도로 캡처하는 경우, 별도 항목이 모든 관련 정보를 캡처할 수 있도록 하십시오.
이름을 나누기 위한 전략, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
예를 들어, 사용자가 제공한 이름의 순서가 'given name' 뒤에 'family name'이 오는 것이라고 가정하지 마십시오. 또한 여러 단어로 구성된 이름에서 어느 부분이 이러한 범주 중 어디에 들어가는지, 그리고 어느 부분이 아버지의 이름, 마을 이름, clan 이름 등과 같이 완전히 다른 것과 관련되는지를 식별할 수 있다고도 가정하지 마십시오.
이름의 일부를 자동으로 추출하는 알고리즘에 내장된 가정에 주의하십시오.
이름을 나누기 위한 전략, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
예를 들어, v-card 및 h-card 접근법의 implied “n” 최적화는 Chinese 이름 같은 경우에 어려움을 겪을 수 있습니다. 입력 form은 사람들이 자신의 이름을 어떻게 지정해야 하는지 알려줄 때 가능한 한 명확해야 하며, 그래야 여러분이 필요하다고 생각하는 데이터를 캡처할 수 있습니다.
한 글자 이름을 initial이라고 가정하지 마십시오.
이름을 나누기 위한 전략, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
사람들은 한 글자 길이의 이름을 실제로 가지고 있습니다. form validator가 그들의 이름을 받아들이지 않고 이름을 완전하게 제공하라고 요구하면 이러한 사람들은 문제를 겪을 수 있습니다. 사람들이 initials를 사용하지 않도록 권장하고 싶다면, form 제출을 막기보다 warning message로 만드는 것이 좋을 수 있습니다.
사람들이 family name을 제공하도록 요구하지 마십시오.
이름을 나누기 위한 전략, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
Southern India, Malaysia, Indonesia의 일부 지역 같은 문화권에서는 많은 사람이 patronym 없이 given name만으로 구성된 이름을 가집니다. family name을 요구하면 이러한 문화권에서 큰 문제를 만들 수 있습니다. 사용자가 form을 벗어나기 위해 family name 필드에 "." 또는 "Mr." 같은 쓰레기 데이터를 입력하기 때문입니다.
사람들이 이름에 hyphens, apostrophes 등의 문장부호를 사용할 수 있도록 허용하고, 그러한 문자에 대한 가능한 대체 코드 포인트를 고려하십시오.
기타 사항, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
이는 Dina Asher-Smith 및 Christopher O'Connell 같은 사람들의 이름이 올바르게 처리되도록 보장합니다.
apostrophe는 'U+0027 APOSTROPHE 또는 ʼU+02BC MODIFIER LETTER APOSTROPHE, 또는 어쩌면
’U+2019 RIGHT SINGLE QUOTATION MARK로 나타날 수도 있다는 점에
유의하십시오. hyphen은 -U+002D HYPHEN-MINUS 또는 ‐U+2010 HYPHEN로
표현될 수 있으며, Japan에서는 ゠U+30A0 KATAKANA-HIRAGANA DOUBLE HYPHEN로 표현될 수도 있습니다.
이름을 모두 대문자로 입력하도록 요구하지 마십시오.
기타 사항, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
이름의 대소문자를 정규화하지 마십시오.
기타 사항, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
일부 이름(예: 'McNamara')은 첫 글자가 아닌 곳에 대문자를 포함합니다. 다른 이름(예: 'van der Waals')은 대문자로 시작하지 않는 단어를 포함합니다. form은 사용자가 입력한 대소문자를 보존해야 하며, 이러한 이름이 항상 또는 오직 각 단어의 시작에서만 대문자를 사용하도록 강제해서는 안 됩니다.
사용자가 공백이 있는 이름을 입력할 수 있도록 허용하십시오.
기타 사항, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
이를 통해 Gabriel García Márquez의 family name(García Márquez), 또는 José María Olazábal의 given name(family name은 Olazábal) 같은 이름을 올바르게 캡처할 수 있습니다.
같은 가족 구성원이 같은 family name을 공유한다고 가정하지 마십시오.
기타 사항, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
같은 가족 구성원이 같은 family name을 공유한다고 가정하는 것은 잘못입니다. West에서는 결혼 후에도 각자가 자신의 이름을 유지하는 추세가 커지고 있지만, China와 같은 다른 문화권에서는 이것이 일반적인 방식입니다. 어떤 나라에서는 아내가 남편의 이름을 따를 수도 있고 그렇지 않을 수도 있습니다.
Hispanic 이름을 다룰 때는 가족 안에서 오직 자녀만 같은 family name을 가지며, 그 이름이 부모 각각과 다를 수 있습니다. Manuel Pérez Quiñones는 자신의 apellidos(Pérez Quiñones)를 그의 아버지의 apellidos인 Pérez Rodríguez와 어머니의 apellidos인 Quiñones Alamo에서 얻었습니다. 시간이 지나 그는 Padilla Falto라는 apellidos를 가진 여성과 교제했습니다. 그들이 결혼했을 때 그녀의 apellidos는 Padilla de Pérez가 되었습니다. 그들의 자녀는 Pérez Padilla라고 불렸고, 이런 식으로 이어집니다.
form이 'Maiden name' 또는 'née'보다 'Previous name'을 묻는 편이 더 나을 수 있습니다.
기타 사항, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
또한 이름 채택이 남편에서 아내로만 이어진다고 단순히 가정해서는 안 됩니다. 때로는 남성이 결혼하면서 아내의 이름을 따르기도 합니다. 이러한 경우 form은 'Maiden name'이나 'née'보다 'Previous name'이라고 말하는 편이 더 나을 수 있습니다.
이름을 Latin 문자와 native 문자 모두로 저장해야 할 가능성이 크며, 이 경우 사용자에게 native 문자와 Latin 전용 형태 모두의 이름을 별도 항목으로 제출하도록 요청해야 합니다.
문자 지원에 대한 영향, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
여러 필드가 필요한지는 어느 정도 사람들의 이름을 무엇을 위해 수집하고, 이를 어떻게 사용할 것인지에 따라 달라집니다.
필요한 경우 이름의 transcription을 위한 필드를 제공하십시오.
문자 지원에 대한 영향, Personal Names Around the World에서.
차이점의 예, Personal Names Around the World에서.
예를 들어 Japanese 사용자는 ideographic 형태 대신/또는 그에 더해 Japanese syllabic script로 transcription을 제공해야 할 수 있습니다. 이 필드는 Japanese 이름을 정렬하는 데 사용되지만, 이름을 보는 사람이 그것이 어떻게 발음되는지 확인할 수도 있게 합니다.
real name 사용을 강제하려고 할 때 특이하거나 예상치 못한 이름을 차단하지 마십시오.
개발자의 기대에 맞지 않는 이름 때문에 서비스 사용이 차단된 사람들의 예를 찾기는 어렵지 않습니다. real name 사용을 강제하려는 경우, 이름이 드물거나 예상치 못한 구조를 가진 사람들이 실제 이름을 검증할 수 있는 메커니즘을 허용해야 합니다.
사람 이름이 포함된 예를 담은 표준 및 표준 관련 문서에서는 전 세계 독자를 반영하기 위해 다양한 이름을 사용하십시오. 특정 지역에 특화된 이름의 편향을 피하십시오.
많은 사양은 user stories나 use cases처럼 서사를 강화하는 수단으로 개인 이름을 사용하는 예를 제공합니다. 어떤 그룹은 security 사양에서 "Alice"와 "Bob"이라는 이름을 사용하여 일정 수준의 일관성을 제공하는 관행을 갖기도 합니다. 포용성은 시스템과 서비스를 구축할 때 중요한 목표여야 하므로, 예를 만들 때 전 세계적으로 다양한 이름을 사용하자는 제안이 나옵니다. 이는 우리가 우리의 기술을 사용하는 전 세계 사용자 커뮤니티를 대표하도록 보장하는 데 도움이 되며, 사양이 글로벌 사용자에게 더 관련 있어 보이게 합니다.
European 기원의 몇몇 이름만 사용하는 대신, 전 세계 여러 지역의 사람들을 대표하는 이름을 선택해 보십시오. 비ASCII 문자를 포함하는 이름을 선택하면 구현자에게 Unicode 지원과 기타 국제화 문제가 사용자에게 적용된다는 점을 상기시키는 데 도움이 될 수 있다는 점에 유의하십시오.
어떤 이름 모음도 문화 및 gender 관련 문제를 다룰 때 완전히 agnostic할 수는 없습니다. 사양 작성자가 더 포용적인 예를 만들 수 있도록 돕기 위해, 이 문서는 여러 문화에서 가져온 이름 모음을 제공합니다. 이러한 이름은 대략 지역별로 조직되어 있으며, 보통 국가나 언어를 나타냅니다. 이러한 지역 안에서도 개인 이름을 다루는 데 매우 다양한 영향과 관행이 있다는 점에 유의하십시오. 또한 사양 작성자가 예를 작성하는 데 도움이 되도록 이름은 문화적 gender 연관성에 따라 나뉘어 있지만, 많은 이름은 특정 gender에 국한되지 않습니다.
다른 문화권의 개인 이름을 English-language 예제에 삽입하는 것은 전 세계에서 이름이 문화적으로 사용되는 방식이 매우 다르다는 점의 영향을 받습니다. 예를 들어 어떤 문화권에서는 given name에 더해 patronym/matronym을 사용할 것을 기대합니다. 또는 어떤 문화권에서는 더 격식 있는 이름을 선호합니다 (예: 비격식적인 "Albrecht"보다 "Herr Dürer").
Chinese 사람들은 family name도 포함하지 않고 given name만 사용하는 일이 거의 없습니다. Chinese로 예를 작성할 때는 "exemplar name" 대신 路人甲(Han "Heavenly Stem" ordinals를 사용하는 Person A를 의미함, Ready-made Counter Styles 참조) 같은 것을 볼 수 있습니다. 예에서 이름이 사용될 때는 family name과 given name을 모두 포함합니다. Chinese에서는 family name이 given name 앞에 먼저 온다는 점을 염두에 두십시오.
Japanese에서는 격식 수준과 관련된 복잡한 선택이 있습니다. 매우 비격식적인 상황에서는 사람이 given
name으로 불릴 수도 있지만(Hiroshi), 보통은 family name에 (무례하게 굴지 않는 한)
-san 또는 -sama 같은 title 또는 suffix를 붙여 부릅니다(예:
Tanaka-san). senpai나 sensei(선배나 매우 존경받는 사람에게), 또는
shi(그 사람을 잘 모를 때) 같은 다른 suffix나 title도 사용됩니다. 따라서 English 예제에서
Suppose Hiroki wants to set up a...라고 할 수 있는 경우에도, 문화적으로는 Suppose
Tanaka-san wants to set up a...라고 읽히는 편이 더 적절할 가능성이 큽니다.
다음 표는 Internationalization Working Group이 편집한 것입니다. 추가나 수정에 대한 기여와 제안을 환영합니다.
이 이름 모음의 목적은 일반적으로 English-speaking 독자를 위해 작성하는 사양 작성자를 돕는 것입니다. 이 모음은 주로 given name으로 구성되며, 필요한 경우 Latin 문자로 음역되어 있습니다. 또한 많은 문화권에서 실제로 이름이 이렇게 사용되지는 않더라도, 이름은 비격식적으로 표현됩니다("Ms. Jones"가 아니라 "Alice"). 사양을 번역할 때는 대상 독자에게 적절한 조정을 해야 합니다.
이름이 비Latin 문자 언어나 문화에서 온 경우, 이름이 결코 Latin 문자로 제한되지 않음을 상기시키거나 비Latin 문자 예를 포함하고 싶은 경우를 위해 비Latin 표현도 함께 제공합니다.
이 표는 헤더 행의 △ 또는 ▽ 화살표를 클릭하여 정렬할 수 있습니다.
| 이름 △▽ | 원어 △▽ | 성별 △▽ | 지역 및 참고 △▽ | 언어 △▽ |
|---|---|---|---|---|
| Akamu | m | Oceania; Polynesia; Hawaiian 이름 | haw | |
| Alinta | f | Oceania; Australian indigenous 이름 | nys | |
| Amélie | f | Europe; France | fr | |
| An | 杏 | f | East Asia; Japan | ja |
| Aoi | 葵; 蒼; 碧 | f, m | East Asia; Japan | ja |
| Aroha | f | Oceania; Maori | mi | |
| Åsa | f | Europe; Sweden | sv | |
| Asahi | 朝陽 | m | East Asia; Japan | ja |
| Atlahua | m | Latin America; Nahuatl 이름 | nah | |
| Beata | f | Europe; 여러 국가 | it, de, pl, sv, etc. | |
| Chanda | चंदा | f | South Asia; 원래 Sanskrit에서 유래 | sa |
| Chirapathi | சிரபதி | f | South Asia; Tamil | ta |
| Citlali | f | Latin America; Nahuatl | nah | |
| Coen | m | Europe; Netherlands; 또한 Oceania(Australian indigenous) 또는 Hebrew 이름 | nl, he, nys | |
| Daisho | 大翔 | m | East Asia; Japan | ja |
| Dara | f | West Asia; Europe; Türkiye | tr | |
| Eva | Е́ва | f | Europe; Russia | ru |
| Faheem | فهيم | m | West Asia; Arabic | ar |
| Fátima | فَاطِمَة | f | West Asia; Arabic; Latin 문자로 여러 European 문화에서도 사용됨 | ar |
| Genet | ገነት | f | Africa; Ethiopia | am |
| Haruto | 陽翔 | m | East Asia; Japan | ja |
| Haukea | f | Oceania; Polynesia; Hawaiian 이름 | haw | |
| Himari | 陽葵 | f | East Asia; Japan | ja |
| Hina | 陽菜 | f | East Asia; Japan | ja |
| Hīnano | m | Oceania; Polynesia; Tahitian | ty | |
| Hua | 李华 | m | East Asia; China | zh-Hans |
| Iakopo | m | Oceania; Samoa | sm | |
| Ilango | இளங்கோ | m | South Asia; Tamil | ta |
| Irepani | m | Latin America; Purepecha 언어 | tsz | |
| Işık | f | West Asia; Europe; Türkiye | tr | |
| Işıtan | m | West Asia; Europe; Türkiye | tr | |
| Itsuki | 樹 | m | East Asia; Japan | ja |
| Jarra, Jarrah, Cerrah | جراح | m | West Asia; Arabic | ar, tr |
| Jean-François | m | Europe; French | fr | |
| João | m | Latin America; Brazil | pt-BR | |
| Júlía | f | Europe; Iceland | is | |
| Kai | f, m | Oceania; Australia; 많은 언어에 나타나며 좋은 일반 예입니다 | aus, sm | |
| Khaliun | f, m | East Asia; Mongolia | mn | |
| Kylie | f | Oceania; Australian indigenous 이름 | aus | |
| Lani | f | Oceania; Philippines | fil | |
| Lei | 李雷 | m | East Asia; China | zh-Hans |
| Livia | f | Europe, Latin America | es | |
| Lowanna | f | Oceania; Australian indigenous | aus | |
| Lucas | m | Latin America | es | |
| Maevarau | m | Oceania; Samoa | sm | |
| Mahmut | m | West Asia; Europe; Türkiye | tr | |
| Martina | f | Latin America | es | |
| Mei | 芽依 (ja); 梅
(zh) |
f | East Asia; China; Japan | ja, zh |
| Minato | 湊 | m | East Asia; Japan | ja |
| Mio | 澪 | f | East Asia; Japan | ja |
| Miriam | מרים | f | West Asia; Hebrew | he |
| Müge | f | West Asia; Europe; Türkiye | tr | |
| Muhammad | محمد | m | West Asia; Arabic; 많은 변형과 언어. | ar |
| Ngatemi | f | Oceania; Indonesia | id, ms | |
| Onosaʻi | f | Oceania; Samoa | sm | |
| Potira | f | Latin America; Brazil; indigenous 이름 | gn | |
| Qiàn | 倩 | f | East Asia; China | zh-Hans |
| Rattiya | รัตติยา | f | South-East Asia; Thailand | th |
| Ren | 蓮 | m | East Asia; Japan | ja |
| Rin | 凛 | f | East Asia; Japan | ja |
| Ritthichai | ฤทธิชัย | m | South-East Asia; Thailand | th |
| Santiago | m | Latin America | es | |
| Senthil | செந்தில் | m | South Asia; Tamil | ta |
| Sione | m | Oceania; Tonga | to | |
| Slobodan | Слободан | m | Europe; Serbian | sr |
| Sofia | f | Europe; Latin America | es | |
| Tahnee | f | Oceania; Australian indigenous | aus | |
| Tamizhachi | தமிழச்சி | f | South Asia; Tamil | ta |
| Temuera | m | Oceania; Polynesia | sm | |
| Thị Anh | f | South-East Asia; Vietnam | vi-VN | |
| Tuulikki | f | Europe; Finland | fi | |
| Uriel | אוּרִיאֵל | m | West Asia; Hebrew | he |
| Văn Hoa | m | South-East Asia; Vietnam | vi-VN | |
| Vasa | m | Oceania; Samoa; Europe; Vasilije/Василије의 지소형 | sm, hr, sr | |
| Vassilios | Βασίλειος | m | Europe; Greek | el |
| Voula | Βούλα | f | Europe; Greek | el |
| Wafaa | وفاء | f | West Asia; Arabic | ar |
| Wissam | وسام | m | West Asia; Arabic | ar |
| Xiaoxia | 晓霞 | f | East Asia; China | zh-Hans |
| Xóchitl | f | Latin America; Nahuatl | nah | |
| Yevdokia | Евдокия | f | Europe; Russia | ru |
| Yevgeny | Евгений | m | Europe; Russia | ru |
| Zafirah | زفره | f | West Asia; Arabic | ar |
숫자 값에 대한 사용자 입력을 파싱할 때 digit shaping(비ASCII 숫자)을 허용하십시오.
표시를 위해 숫자 값을 formatting할 때, 비ASCII 숫자 사용(digit shaping)을 포함해 문화적으로 민감한 표시를 허용하십시오.
사용자에게 표시하기 위해 항목에 자동으로 증가하는 레이블을 붙이는 기능(예: numbered list 생성)을 정의할 때, 다양한 counting/listing 체계나 스타일뿐 아니라 레이블의 지역화된 표현도 허용하십시오.
이에 대한 예는 CSS Counter Styles [css-counter-styles-3]와 특히 동반 문서인 Ready-made Counter Styles [predefined-counter-styles]에서 찾을 수 있습니다.
email 필드 검증을 정의할 때, EAI(smtputf8) 이름을 허용하십시오.
지역화 [LTLI]는 사용자가 자신이 선택한 언어와 로케일로 소프트웨어를 사용할 수 있게 합니다. 프로토콜 및 문서 형식에 대한 사양은 최종 사용자가 기대하는 언어와 formatting을 어떻게 제공할지 고려해야 합니다.
자연어 데이터 값은 지역화된 메시지가 제공되지 않더라도 올바른 표현을 보장하기 위해 언어와 기본 방향이 필요합니다. 여기에는 API나 프로토콜에서 사람이 읽을 수 있는 모든 오류 메시지 또는 기타 내부 메시지가 포함됩니다. [STRING-META]도 참조하십시오.
주어진 API나 프로토콜이 정의하는 오류 메시지를 포함한 모든 자연어 필드나 메시지는 사용자의 선호 로케일로 지역화되거나, 해당 언어를 사용할 수 없는 경우 적절한 fallback 또는 default와 함께 제공되는 것이 권장됩니다.
사양은 API 또는 프로토콜의 메시지나 오류에 대해 특정 기본 언어를 정의할 수 있습니다.
사양은 메시지가 가능한 모든 로케일이나 사용 가능한 모든 로케일로 반환되도록 요구할 필요가 없습니다. 최종 사용자의 고객 경험을 지역화할 수 있게 하는 것으로 충분합니다. 구현은 어떤 언어나 로케일을 지원할지 선택할 수 있습니다.
프로토콜, API 및 문서 형식은 때때로 서비스에서 호출자에게 사람이 읽을 수 있는 오류 또는 예외 메시지를 문자열 형태로 전달하기 위한 필드를 제공합니다. 일반적으로, 그리고 위에서 표시한 것처럼, 사람이 읽을 수 있는 메시지나 사람이 읽을 수 있는 콘텐츠를 전달하는 모든 자연어 텍스트는 언어 및 방향 메타데이터와 연결되어야 합니다. 이 메타데이터가 없으면 텍스트의 처리나 표시가 손상될 수 있습니다.
오류 또는 예외 메시지를 제공하는 사양 작성자의 의도는 대개 소프트웨어 개발자에게 디버깅 정보를 전달하는 것입니다. 사양 작성자는 때때로 오류 또는 예외 메시지가 최종 사용자에게 보이지 않는다고 가정합니다. 소프트웨어 개발자가 이러한 메시지가 지역화되지 않거나 특정 언어(보통 English)로 나타나는 것을 선호한다고 가정하기도 합니다. 또는 오류 메시지 지역화가 장벽이 될 수 있는 다른 "practical reasons"가 있다고 가정하기도 합니다. 예를 들어 오류의 (보통 모호한) 텍스트 자체가 문제를 충분히 잘 설명하지 못하기 때문에 개발자가 그 텍스트로 웹을 검색하는 것이 더 쉽다고 느끼는 사례가 있습니다. 이 텍스트를 검색하면 개발자가 선호하는 언어로 된 더 도움이 되는 결과를 얻을 수 있습니다.
오류 메시지는 메시지이며, 기계가 아니라 사람을 위한 것입니다. 많은 경우 오류 메시지는 무엇이 잘못되었는지에 대한 모든 추가 정보를 포함하며, 어떤 경우에는 문제를 해결하는 방법을 호출자에게 전달할 다른 방법이 없기 때문에 호출자가 실제 최종 사용자에게 메시지를 보여주어야 합니다("Your credit card has expired"; "The value 10484977 is too large" [이런, 소수점을 잊었습니다]; 등). 이러한 유형의 메시지 지역화는 실제로 좋은 일이며, 일부 애플리케이션에서는 의무일 수도 있습니다.
API와 프로토콜은 오류에 대해 언어 독립적 식별자를 제공하는 것이 권장됩니다.
예를 들어 익숙한 404 같은 HTTP result code는 사용자가 자신이 받은 오류를 전달하거나
번역을 찾아보는 데 도움이 됩니다.
자연어 오류 메시지 필드가 제공되는 경우, 이는 선택 사항인 것이 권장되며 언어 및 방향 메타데이터를 포함하는 것이 권장됩니다.
자연어 오류 메시지 필드가 제공되는 경우, 가능하면 요청에 대해 협상된 사용자 인터페이스 언어와 일치하는 것이 권장됩니다.
다음은 이전 발행 이후의 실질적 변경 사항을 요약한 것이지만, 자료는 개발 과정에서 여전히 크게 변동될 수 있습니다. 이것이 문서를 사용하지 않을 이유가 되어서는 안 됩니다. 지금까지 포함된 내용은 유용하며, 부족한 부분은 보고하거나 논의할 수 있습니다.
자세한 내용은 github commit log를 참조하십시오.
권고를 위해 오래된 검토를 살펴보는 데 도움을 준 Addison Phillips에게 감사드립니다.
검토나 이슈를 통해 기여한 다른 사람들은 다음과 같습니다: Steve Atkin, Andrew Cunningham, Martin Dürst, Asmus Freytag, John Klensin, Tomer Mahlin, Chaals McCathieNevile, Florian Rivoal, Najib Tounsi. 로케일 중립 표현에 관한 일부 자료는 [DWBP]에서 각색되었습니다.
참조된 곳: