사양 개발자를 위한 국제화 모범 사례
이 문서에 대한 자세한 정보
Copyright © 2014-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Copyright © 2014-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
이 문서는 사양을 개발할 때 국제화와 관련해 고려해야 할 사항의 체크리스트를 제공합니다. 대부분의 체크리스트 항목은 다른 문서의 자세한 지원 정보로 연결됩니다. 그러한 정보가 아직 존재하지 않는 경우, 이 문서에 임시로 둘 수 있습니다. 이 문서의 정보는 새 콘텐츠가 추가되고 경험과 논의를 바탕으로 기존 콘텐츠가 수정됨에 따라 정기적으로 변경됩니다.
이 절에서는 이 문서가 발행된 시점의 상태를 설명합니다. 현재 W3C 간행물 목록과 이 기술 보고서의 최신 개정판은 W3C 표준 및 초안 색인에서 확인할 수 있습니다.
이 문서는 명세 개발자에게 국제적 사용을 위한 요구사항을 포함하는 방법에 관한 조언을 제공합니다. 현재 여기에서 제공되는 내용은 즉시 유용할 것으로 예상되지만, 아직 초기 초안이며 문서는 계속 변경되고 있습니다. 검토와 논의에서 얻은 지식을 지침으로 구체화함에 따라 시간이 지나면서 내용이 늘어날 것입니다.
이 문서는 국제화 작업 그룹이 노트 트랙을 사용하여 그룹 노트로 발행했습니다.
이 그룹 노트는 국제화 작업 그룹의 승인을 받았지만, W3C 자체 또는 그 회원의 승인을 받은 것은 아닙니다.
W3C 특허 정책은 이 문서에 어떠한 라이선스 요구사항이나 약정도 부과하지 않습니다.
이 문서는 2025년 8월 18일 W3C 프로세스 문서의 적용을 받습니다.
명세 개발자는 자신이 만드는 결과물이 전 세계 공동체에서 작동하도록 보장하기 위한 조언이 필요합니다.
국제화(i18n) 작업 그룹은 명세를 검토하고 논의에 참여하여 다른 작업 그룹을 지원하려고 노력합니다. 그러나 이러한 개입은 이상적인 시점보다 늦게 이루어지는 경우가 많으며, i18n 작업 그룹이 교류하는 각 작업 그룹에 동일한 정보를 반복해서 전달해야 하는 경우도 있습니다.
명세 개발자가 개발자에게 필요한 설명, 예제 및 근거를 가리키는 모범 사례 체크리스트를 이용할 수 있다면 더 좋을 것입니다. 그러면 개발자는 초기 단계부터 이러한 지식을 작업에 반영할 수 있으며, i18n 작업 그룹이 명세를 검토할 때 필요한 재작업을 줄일 수 있습니다.
이 문서에는 체크리스트의 초기 내용이 포함되어 있으며, 제시된 권고사항에 대한 설명, 예제 및 근거를 찾을 수 있는 위치를 안내합니다. 그러한 다른 위치가 없는 경우 추가 정보가 이 문서에 추가됩니다. 또한 아이디어를 발전시키고 정리하는 데 사용할 수도 있습니다.
이 문서의 지침은 엄격하고 절대적인 요구사항으로 작성된 것이 아닙니다. 지침을 이해하지 못하거나 동의하지 않는 경우 국제화 작업 그룹에 연락하여 어떻게 해야 하는지 논의한다면, 이 문서는 그 목적의 상당 부분을 달성하게 됩니다.
이 문서에서 자연어라는 용어는 일반적으로 사람이 이용하도록 의도된 문서 또는 프로토콜의 부분을 가리키는 데 사용됩니다. 현지화 가능한 텍스트라는 용어는 구문 콘텐츠 또는 사용자 제공 값과 구별되는, 형식 언어, 프로토콜 구문 등에 포함된 자연어 콘텐츠를 가리키는 데 사용됩니다. 국제화 작업 그룹에서 사용하는 이러한 용어와 기타 용어의 정의는 [I18N-GLOSSARY]를 참조하십시오.
국제화 관점에서 명세를 검토하는 데 도움이 되도록 이 페이지에서 체크리스트 기능을 제공합니다. 검토 결과는 GitHub 이슈에 게시해야 합니다.
명세와 관련된 각 절에서 다음 단계를 따르십시오.
국제화 고려사항 절에 대한 모든 추가 또는 변경은 국제화(i18n) 작업 그룹의 검토를 반드시 받아야 합니다.
국제화 고려사항 절을 만드는 경우 제목은 국제화 고려사항 또는 국제화(i18n) 고려사항이어야 합니다.
명세에는 명세의 국제화 고려사항을 설명하는 별도의 절이나 부록을 반드시 포함할 필요는 없습니다. 일반적으로 국제화 작업 그룹은 언어, 지역 또는 문화적 차이, 지원 또는 적응에 관한 정보가 관련 기능과 밀접하게 연결되어 명세 본문에 나타나는 것을 선호합니다.
그러나 다음과 같은 경우에는 이러한 절을 제공하는 것을 고려할 수 있습니다. 다음과 같은 경우 국제화 고려사항 절을 포함하는 것을 고려하십시오.
국제화 고려사항 절을 만들기로 결정한 경우 일반적으로 부록으로 작성합니다. 그러나 명세의 다른 부분이나 다른 부록과 비교한 순서와 위치는 작성자가 결정할 수 있습니다.
국제화 고려사항 절을 만들기로 결정한 경우 국제화 작업 그룹에 보내는 수평적 검토 요청에서 이를 언급해야 합니다. 검토 요청 템플릿에는 이를 쉽게 표시할 수 있는 체크박스가 포함되어 있습니다.
이 목록에는 이 절의 요구사항만 포함되어 있으며 자체 검토에 사용할 수 있습니다. 명세와 관련된 모든 요구사항에 대해 해당 줄의 첫 번째 체크박스를 선택하십시오. 명세가 요구사항을 충족하면 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
언어 기본 사항
lang 및 XML xml:lang 언어 속성을 사용하여 텍스트 처리
언어를 식별하십시오. 자세히lang 및 XML xml:lang 언어 속성을 사용해서는 안 됩니다. 해당 속성이
메타데이터를 나타내는 경우에는 다른 속성을 사용해야 합니다. 메타데이터는 특정
텍스트 범위의 언어가 아니라 리소스의 의도된 용도를 나타냅니다. 자세히언어 값 정의하기
언어 선언하기
문자열의 언어 식별하기
zxx("언어적 콘텐츠
없음")를 연결하도록
권고해야 합니다. 자세히und("확인되지 않음")를 연결하도록 권고해야
합니다. 명세는 적절한 경우 휴리스틱을 사용하거나 다른
필드 값에서 언어를 추론하도록 허용할 수도 있습니다. 자세히
U+E0000부터 U+E007F)를
사용해서는 안 됩니다. 자세히
@context와 내장 @language 속성을
사용하는 것이
권장됩니다. 자세히
i18n 네임스페이스 기능을 사용해야
합니다. 자세히
i18n
네임스페이스를 사용할 수 없거나 사용하는 것이 적절하지
않은 경우, 명세는 자연어 값에 대해 문자열별 언어 정보를 제공하도록 [JSON-LD] 일반 문자열 리터럴을 요구해야
합니다. 자세히
언어 감지하기
모든 현지화 가능한 텍스트 또는 자연어 콘텐츠에 언어를 연결할 수 있어야 합니다.
텍스트는 사용된 언어에 따라 다르게 렌더링되거나 처리됩니다. 예를 들어 언어가 변경될 때 스크린 리더에 알려야 하며, 맞춤법 검사기는 언어에 맞게 작동해야 합니다. 텍스트를 렌더링할 때 올바른 글꼴, 하이픈 처리, 줄바꿈, 대소문자 변환 및 기타 기능을 적용하려면 언어에 대한 정보가 필요합니다.
예를 들어 雪, 刃, 直, 令, 垔과 같은 표의 문자는 일본어 글꼴과 중국어 글꼴에서 사용할 때 미세하지만 중요한 차이가 있습니다. 사용자에게 표시할 때 일본어 텍스트에 중국어 글꼴을 적용하거나 그 반대로 적용하지 않는 것이 중요합니다.
특정 리소스의 언어 정보는 텍스트 처리 또는 리소스의 의도된 용도에 관한 설명이라는 두 가지 주요 목적에 사용할 수 있습니다. 아래에서 그 차이를 설명합니다.
텍스트 처리 언어를 지정할 때는 음성 브라우저, 맞춤법 검사기, 스타일 처리기, 하이픈 처리기 등 텍스트를 조작하는 사용자 에이전트 또는 애플리케이션이 해당 텍스트에 적절한 규칙을 적용할 수 있도록 특정 텍스트 범위가 실제로 작성된 언어를 선언합니다. 따라서 필요에 따라 하나의 언어를 특정 텍스트 범위와 연결해야 합니다.
리소스 전체를 처리하기 위한 기본 언어로 텍스트 처리 언어를 표현하는 것이 일반적이지만, 리소스 내에서 언어가 변경되는 위치를 표시해야 할 수도 있습니다.
텍스트 범위의 텍스트 처리 언어를 식별하기 위해 HTML은lang 속성을 제공하고, XML은 모든 XML 형식에서
사용할 수 있는
xml:lang을 제공합니다. 작성자는 이러한 속성을 알고
있으며 HTML 및 XML 처리기도 이를 인식하므로 관련 마크업 형식에서 이러한 속성을 계속
사용하는 것이 유용합니다.
리소스 전체의 언어를 설명하는 것도 유용할 수 있습니다. 이러한 유형의 언어 선언을 리소스의 대상 언어 사용자층이라고 합니다. 예를 들어 이러한 메타데이터는 검색, 적절한 언어 버전 제공, 분류 등에 사용될 수 있습니다.
이러한 유형의 언어 선언은 (a) 선언 값이 둘 이상의 언어 하위 태그일 수 있고, (b) 선언된 언어 값이 다국어 리소스의 어느 부분이 어느 언어인지 나타내지 않는다는 점에서 텍스트 처리 선언과 다릅니다.
메타데이터 유형 언어 선언은 특정 텍스트 범위의 언어가 아니라 리소스의 의도된 용도를 나타내며, 여러 언어 값과 연결할 수 있어야 합니다.
리소스의 의도된 용도를 설명하는 언어에는 문서에서 사용된 모든 언어가 반드시 포함되는 것은 아닙니다. 예를 들어 웹의 많은 문서에는 다른 언어로 된 콘텐츠 조각이 포함되어 있지만, 페이지는 명확히 특정 언어 사용자에게 제공됩니다. 베이징에 관한 독일어 도시 안내서에는 유용한 중국어 표현이 포함될 수 있지만, 중국어 사용자가 아니라 독일어 사용자를 대상으로 합니다.
반면 하나의 문서에 둘 이상의 언어로 동일하거나 병렬적인 콘텐츠가 포함된 상황도 생각할 수 있습니다. 예를 들어 웹 페이지의 왼쪽 열에는 캐나다 독자를 위한 프랑스어 콘텐츠가 있고, 오른쪽 열에는 같은 내용의 영어 콘텐츠가 있을 수 있습니다. 이 경우 문서는 두 언어 사용자 모두를 동일하게 대상으로 하므로 대상 언어가 두 개입니다. 또 다른 사용 사례는 다국어 공동체를 대상으로 하는 블로그나 뉴스 페이지로, 페이지의 일부 기사는 한 언어로 작성되고 다른 기사는 다른 언어로 작성될 수 있습니다. 이러한 경우 언어 선언 값으로 둘 이상의 언어 태그를 나열하는 것이 적절할 수 있습니다.
외부 리소스의 언어를 표현하는 속성은 HTML lang 및 XML
xml:lang 언어 속성을 사용해서는 안 됩니다. 해당 속성이
메타데이터를 나타내는 경우에는 다른 속성을 사용해야 합니다. 메타데이터는 특정
텍스트 범위의 언어가 아니라 리소스의 의도된 용도를 나타냅니다.
XML 문서 스키마의
xml:lang – XML 문서 스키마(DTD)에서
언어 값을 전달할 때 언제 xml:lang을 사용하고 언제 자체 요소나 속성을 정의해야
합니까?
외부 리소스의 언어를 나타내는 데 다른 속성을 사용하면 속성에 둘 이상의 언어를 지정할 수 있습니다. 또한 가리키는 리소스가 하나의 언어로만 되어 있지 않은 경우에도 더 적절하게 작동합니다.
이러한 구분은 HTML의 lang 속성과 hreflang 속성이 분리되어 있는 것에서 확인할 수
있습니다. 전자는 HTML 페이지 내 텍스트의 언어를 나타내며, 후자는 링크된 페이지의
예상 언어를 나타내는 메타데이터입니다.
이에 대한 자세한 논의는 XML 문서 스키마의
xml:lang을 참조하십시오. 이 문서는 구체적으로 xml:lang을 다루지만 해당 개념은
다른 상황에도 적용됩니다.
BCP 47은 인터넷 및 웹 표준과 기타 많은 곳에서 사용하는 언어 태그 체계입니다. IANA 레지스트리의 하위 태그를 사용하여 콘텐츠의 언어를 설명하는 문자열을 만드는 방법을 정의합니다. 레지스트리의 하위 태그는 주로 언어, 문자 체계, 지역 및 국가를 식별하는 ISO 및 UN 표준을 기반으로 하며, 해당 표준과 엄격한 호환성을 유지합니다. BCP47은 유니코드 로캘의 기반이기도 합니다.
BCP 47의 주요 기능에 대한 개요는 HTML 및 XML의 언어 태그를 참조하십시오.
RFC 5646 또는 RFC 4647과 같은 구성 요소가 아니라 BCP 47을 참조하십시오.
BCP 47의 링크와 이름은 언어 식별용 태그 정의에 대한 변경되지 않는 참조를 제공하기 위해 특별히 만들어졌습니다. RFC 1766, 3066 및 4646은 이전 버전이며 현재는 대체되었습니다. 현재 버전의 BCP 47은 RFC 5646과 RFC 4647의 두 RFC로 구성됩니다.
언어 태그에 기대하는 적합성 수준을 명확히 지정하십시오. BCP 47은 "유효함"과 "올바른 형식"이라는 두 가지 적합성 수준을 정의합니다.
올바른 형식의 BCP 47 언어 태그는 언어 태그에 정의된 구문을 따릅니다. 구현은 각 언어 태그가 하이픈으로 구분된 하위 태그로 구성되는지 검사합니다. 각 하위 태그는 태그 내 위치에 따라 특정 길이와 특정 내용(문자, 숫자 또는 특정 조합)을 갖습니다. 유효한 BCP 47 언어 태그는 올바른 형식이며, 추가로 IANA 하위 태그 레지스트리에 나열된 하위 태그만 사용하도록 보장합니다. IANA 하위 태그 레지스트리는 새로운 하위 태그로 자주 업데이트된다는 점에 유의하십시오.
명세는 구현이 언어 태그의 "유효함"을 검사하도록 요구할 수 있지만, 대부분의 경우 언어 태그가 "올바른 형식"인지만 요구해야 합니다.
대부분의 명세는 언어 메타데이터를 간접적으로 사용하는 소비자입니다. 즉, 문서 형식에서 이미 제공된 데이터(HTML lang, XML xml:lang 또는 문서 형식의 언어 필드 및 속성)를 사용합니다.
일반적으로 대부분의 명세는 리소스(맞춤법 검사기, 토크나이저, 글꼴 등)를 선택하거나 일치시키는 작업(예: 표시할 문자열 선택)에 관심이 있으며, 언어 태그의 내용 자체에는 직접 관심을 두지 않습니다. 유효하지 않지만 올바른 형식인 태그는 어떠한 항목과도 일치하지 않을 뿐이며, 일반적으로 대체 방식이 적절한 동작을 제공합니다.
명세에서 구현 수준의 유효성 검사가 실제로 필요한 경우도 있을 수 있습니다. 그러한 경우 태그가 유효하지 않을 때의 결과를 지정해야 합니다. 애플리케이션을 종료할지, 사용자에게 경고할지 등을 정해야 합니다. 또한 레지스트리는 크기가 크고 시간이 지남에 따라 변경되므로 각 구현은 레지스트리 버전에 의존하게 됩니다. 시간에 따른 변경은 대개 사소하지만, 오래된 임의의 구현이 나중에 유효해진 언어 태그를 거부하면 실제 사용자가 상호 운용성 문제를 겪게 됩니다.
또한 BCP 47에는 추가 하위 태그 시퀀스를 정의하는 확장 메커니즘이 있습니다. 예를 들어 하나의 확장인 [RFC6067](싱글턴 -u를 사용하는 유니코드 로캘)은 JavaScript의 국제화 기능을 제어하는 데 널리 사용되며 다른 용도로도 사용됩니다. 이러한 추가 하위 태그를 검증하는 작업은 대부분의 명세 범위를 벗어날 가능성이 큽니다.
명세는 콘텐츠와 콘텐츠 작성자가 "유효한" 언어 태그를 사용하도록 요구해야 합니다.
언어 태그에 관한 규범적 표현은 콘텐츠 요구사항과 구현 요구사항에서 서로 다를 수 있습니다. 명세 작성자는 명세에 필요한 적합성 요구사항과 테스트가 무엇인지, 구현이 무엇을 해야 하는지를 신중하게 고려해야 합니다. 한 가지 해결책은 콘텐츠 작성자가 "유효한" 언어 태그를 사용하도록 규범적으로 요구하되, 구현에는 "올바른 형식"의 언어 태그만 검사하도록 요구하는 것입니다.
명세는 ISO 639, ISO 3166 또는 기타 표준에서 추출한 코드 목록을 제공하는 대신 IANA 언어 하위 태그 레지스트리를 참조해야 합니다.
과거에는 언어 태그에 사용되는 하위 태그를 제공하는 일부 표준을 무료 또는 공개적으로 이용할 수 없었으므로, 일부 명세는 상호 운용성을 보장하기 위해 목록을 제공했습니다. 이제는 그럴 필요가 없습니다. 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의 큐, CSV 파일의 한 줄 등을 가리킬 수 있습니다. 이는 단락이나 문장 등의 내부 범위를 설명하는 인라인 콘텐츠와 대조됩니다.
명세에 정의된 구조 중 어떤 구조가 이러한 요구사항과 관련되는지를 해석하려면 어느 정도 고려가 필요할 수 있으며, 관련 데이터 형식에 따라 달라집니다.
기본적으로 콘텐츠 블록은 리소스 전체에 설정된 텍스트 처리 언어를 상속해야 합니다.
기본 텍스트 처리 언어 정보와 관련된 지침은 2.1 언어 기본 사항을 참조하십시오.
언어가 변경되는 콘텐츠 블록에서 언어 변경을 나타낼 수 있어야 합니다.
이 절에서는 단락이나 문자열 중간의 문자 범위에 제공해야 하는 정보를 다룹니다.
언어가 변경되는 인라인 텍스트 범위의 언어를 나타낼 수 있어야 합니다.
언어 전환이 맞춤법 검사, 렌더링, 스타일 지정, 음성 생성, 번역, 정보 검색 등 콘텐츠에 대한 작업에 영향을 줄 수 있는 경우, 영향을 받는 텍스트 범위를 표시하고 해당 콘텐츠의 언어를 식별해야 합니다.
이 절의 정보는 데이터 형식의 언어 및 방향 메타데이터 요구사항 [STRING-META]에서 개발되고 있습니다. 해당 문서는 아직 작성 중이므로 이 지침은 언제든지 변경될 수 있습니다.
가능한 한 웹에서 데이터를 교환할 때는 표준화된 로캘 중립적 형식을 사용해야 합니다. 그러나 웹의 일부 데이터는 필연적으로 사람에게 표시하기 위한 자연어 정보로 구성됩니다. 이러한 자연어 정보를 올바르게 표시하려면 언어 및 방향 메타데이터가 필요하며, 이러한 메타데이터가 있으면 표시 품질이 향상됩니다. 유니코드 지원과 함께 텍스트 범위의 기본 방향과 자연어를 포함하고 지정하는 메커니즘은 웹의 새로운 형식과 기술을 개발할 때 고려해야 하는 핵심 국제화 사항 중 하나입니다.
국제화 작업 그룹이 모든 명세에서 확인하는 가장 기본적인 모범 사례는 다음과 같습니다.
자연어 텍스트가 포함된 모든 문자열 필드에서 해당 문자열의 언어와 문자열 방향을 결정할 수 있어야 합니다. 이러한 결정에는 문자열 또는 문서 수준의 메타데이터를 사용해야 하며 휴리스틱에 의존해서는 안 됩니다.
문자열 형식의 언어 및 방향 메타데이터에 관한 작업은 진행 중입니다. 명세에는 향후 메타데이터를 채택해야 함을 나타내는 참고사항을 포함해야 할 수도 있습니다. 다음은 원형입니다.
{fieldname} 필드는 웹의 문자열: 언어 및 방향
메타데이터 [STRING-META]에서
제시하는 모범 사례를 따라야 합니다. 여기에는 문자열 언어 및 방향 메타데이터 보고와
관련하여 향후 등장하는 모든 표준을 사용하는 것이 포함됩니다.
필드 기반 메타데이터 또는 문자열 데이터 유형을 사용하여 개별 현지화 가능한 텍스트 값의 언어와 문자열 방향을 나타내십시오.
개별 데이터 값의 언어나 방향은 같은 데이터 파일 또는 문서의 다른 값과 다를 수 있습니다. 각 현지화 가능한 텍스트 필드와 직접 연결된 메타데이터 값을 제공하면 메타데이터를 적절하게 재정의할 수 있으며, 각 데이터 필드를 조합, 추출, 전달 또는 기타 방식으로 처리할 때 애플리케이션이 처리를 자동화하는 데 도움이 됩니다.
명세는 특정 리소스의 모든 문자열에 기본 언어와 기본 문자열 방향을 제공하는 메커니즘을 정의할 수 있습니다. 그러나 명세는 리소스 전체의 기본값만으로 충분하다고 가정해서는 안 됩니다. 리소스 전체 설정을 사용할 수 있더라도 문자열별 메타데이터를 사용하여 해당 기본값을 재정의할 수 있어야 합니다.
많은 문서에는 한 언어의 데이터가 포함됩니다. 헤더 등에서 대상 언어 사용자층을 나타내는 방법을 제공하면 전체 문서 크기와 복잡성을 줄일 수 있습니다. 그러나 일부 문자열은 문서 언어로 제공되지 않을 수 있고, 기본 방향이 문서 전체의 다른 현지화 가능한 텍스트 값의 기본 방향과 일치하지 않을 수 있으므로 특정 문자열 값을 재정의하는 기능은 여전히 중요합니다.
다른 정보가 없을 때 기본 방향과 기본 언어는 알 수 없는 것으로 지정하십시오.
명세는 사용자 제공 값을 포함한 구문 콘텐츠와 현지화 가능한 텍스트를 주의하여 구별해야 합니다.
명세는 자연어 텍스트를 포함할 수 없는 필드에 언어 메타데이터를 사용하도록 지정하거나 요구해서는 안 됩니다.
웹의 문서 형식은 텍스트로 구성됩니다. 대부분의 경우 특정 문서 형식의 데이터 값은 단순한 임의 문자열이 아니라 어떠한 대상을 나타내고 의미를 갖도록 만들어집니다. 예를 들어 데이터 값이 영어 키워드로 구성되어 있다는 사실만으로 해당 데이터 값이 텍스트로 표시하기 위한 자연어 문자열이 되는 것은 아닙니다. 즉, 해당 값은 현지화 가능한 텍스트가 아닙니다. 이러한 데이터 값은 문서의 구문 콘텐츠에 포함됩니다. 이러한 값에는 언어 및 방향 메타데이터가 필요하지 않을 뿐만 아니라 그러한 메타데이터를 연결해서도 안 됩니다.
현지화 가능한 텍스트가
아닌 문자열 값과 문자열 필드에 대해 명세는 해당 필드가 언어적 성격을 갖지
않는다고 지정하고, 각 문자열 값에 언어 태그 zxx("언어적 콘텐츠 없음")를 연결하도록 권고해야
합니다.
현지화 가능한 텍스트가
포함된 것으로 알려졌지만 기반 형식에서 언어 메타데이터를 제공할 가능성이 없는 문자열
값과 문자열 필드에 대해, 명세는 콘텐츠의 언어를 알 수 없다고 지정하고 각 문자열에
언어 태그 und("확인되지 않음")를 연결하도록
권고해야 합니다. 명세는 적절한 경우 휴리스틱을 사용하거나
다른 필드 값에서 언어를 추론하도록 허용할 수도 있습니다.
일부 문자열 값은 기존 프로토콜 또는 형식에 의존하거나 해당 프로토콜 또는 형식에서 정의됩니다. 이러한 문자열에는 언어 또는 방향 메타데이터가 연결되지 않거나 제공되지 않는 경우가 많습니다. 예를 들어 많은 HTTP 헤더는 경우에 따라 자연어 텍스트를 포함해도 그 내용이 현지화 가능한 텍스트가 아닌 것처럼 정의합니다. 소비 명세는 때때로 이러한 성격의 문자열에 의존하거나 해당 문자열 중 하나를 설명하는 형식을 정의해야 합니다. 이 경우 명세의 데이터 구조 또는 문서 형식에서 소비자가 문자열과 연결할 언어 또는 방향 메타데이터가 없으며, 명세의 데이터 구조 또는 문서 형식이 생산자로 작동하면서 제공하는 메타데이터도 기반 형식을 통해 직렬화되지 않습니다.
명세는 언어 식별에 유니코드 "언어 태그" 문자(코드 포인트
U+E0000부터 U+E007F)를 사용해서는
안 됩니다.
유니코드 "언어 태그" 문자는 언어 태그 용도로 더 이상 권장되지 않으며, 문서 형식과 유선 프로토콜의 언어 메타데이터 문제를 해결하기에 적합하지 않은 많은 이유가 있습니다. 명세 작성자는 이러한 문자를 다른 용도로 다시 사용하거나 이를 기반으로 언어 정보를 전송하는 새로운 메커니즘을 만들지 않도록 주의해야 합니다.
생산자는 때때로 특정 콘텐츠 항목이나 데이터 레코드에 대한 현지화된 값을 제공해야 합니다. 경우에 따라 이는 생산자와 소비자 사이의 언어 협상을 통해 수행됩니다. 그러면 생산자가 협상된 언어를 사용하여 반환할 콘텐츠를 선택하는 방식으로 현지화를 수행합니다.
다른 경우에는 생산자가 해당 항목에 대해 여러 언어 표현을 반환하고 소비자가 표시할 값을 선택하도록 하여 콘텐츠 항목을 현지화합니다. 이러한 후자의 과정을 언어 인덱싱이라고 합니다. 언어 인덱싱에 대한 자세한 내용은 [STRING-META]의 현지화 고려사항을 참조하십시오.
[JSON-LD]는 이 절의 일부 모범 사례를 충족하기 위한 여러 메커니즘을 제공합니다.
이 문서의 모범 사례와 웹의 문자열: 언어 및 방향 메타데이터 [STRING-META]에서는 자연어 콘텐츠를 언어 메타데이터와 연결하도록 요구합니다. 웹에서 "언어 메타데이터"는 언어 태그, 구체적으로 [BCP47]에서 정의한 언어 태그를 의미합니다. 명세 또는 애플리케이션은 때때로 언어나 사용자의 로캘에 따라 콘텐츠를 선택하거나 필터링해야 합니다.
[BCP47]은 두 개의 RFC로 구성됩니다.
첫 번째인 [RFC5646]은 언어 태그의 문법, 처리 및 형성과 유효한 하위 태그를 나열하는 IANA 언어 하위 태그 레지스트리의 내용 및 유지 관리를 정의합니다.
두 번째인 [RFC4647]은 언어 범위, 언어 우선순위 목록 및 애플리케이션이 언어 태그를 사용하여 선택하거나 필터링할 때 사용할 수 있는 여러 일반적인 일치 방식을 정의합니다. 이러한 방식은 명세에서 지정할 수도 있습니다.
유니코드 [CLDR]은 언어 태그를 로캘 식별자로 사용할 때 이를 관리하고 일치시키기 위한 추가 알고리즘, 규칙 및 절차를 정의합니다.
언어 태그를 일치시키는 방법에는 조회와 필터링이라는 두 가지 유형이 있습니다.
조회 [RFC4647]는 기본 언어 범위로 구성된 언어 우선순위 목록을 언어 태그 집합과 일치시켜 지정된 범위에 가장 잘 맞는 하나의 정확한 언어 태그를 찾습니다. 즉, 사용자의 요구에 가장 잘 맞는 결과 또는 적절한 기본값으로 정확히 하나의 항목이나 값을 반환해야 할 때 조회를 사용합니다. 조회의 예는 다음과 같습니다.
필터링은 언어 우선순위 목록을 언어 태그 집합과 일치시켜 0개 이상의 일치 항목을 생성합니다. 즉, 언어 우선순위 목록과 일치하는 항목만 생성하도록 콘텐츠를 필터링하는 데 사용됩니다. 이 작업으로 모든 언어 태그 값이 제외될 수도 있고, 많은 항목 또는 모든 항목이 포함될 수도 있습니다.
[BCP47]은 기본 필터링과 확장 필터링이라는 두 가지 필터링 유형을 정의합니다. [RFC4647]
기본 필터링은 기본 언어 범위로 구성된 언어 우선순위 목록을 사용하여 언어 태그 또는 언어 태그가 지정된 콘텐츠 목록을 필터링합니다. 기본 필터링에서는 언어 태그의 접두사를 각 언어 범위와 일치시킵니다. 기본 필터링은 언어 우선순위 목록에 포함된 언어 범위의 엄격한 하위 항목인 언어 태그만 모두 선택해야 할 때 유용합니다.
확장 필터링은 확장 언어 범위로
구성된 언어
우선순위 목록을
사용하여 언어 태그 또는 언어 태그가 지정된 콘텐츠 목록을 필터링합니다. 확장 언어 범위는
하나 이상의 하위 태그 위치에 와일드카드 * 하위 태그를 포함할 수 있습니다.
첫 번째 "주 언어 하위 태그" 위치 외부의 와일드카드는 무시됩니다. 기본 필터링과 달리 확장 필터링은
언어 태그 내부의 특정 하위 태그를 선택하는 데 사용됩니다. 확장 필터링을 사용하여 지정된
언어 범위에 포함된
특정 하위 태그 목록과 일치하지 않는 언어 태그를
필터링하십시오.
이 목록에는 이 절의 요구사항만 포함되어 있으며 자체 검토에 사용할 수 있습니다. 명세와 관련된 모든 요구사항에 대해 해당 줄의 첫 번째 체크박스를 선택하십시오. 명세가 요구사항을 충족하면 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
기본 요구사항
배경 정보
기본 방향 값
마크업에서 방향 처리하기
auto로 설정할 수도 있어야 합니다. 이는
콘텐츠 자체를 검사하여 기본 방향을 결정한다는 의미입니다. 자세히auto로 설정된 경우 콘텐츠 단락의 방향은
각 단락별로 결정해야 합니다. 자세히
문자열의 기본 방향 처리하기
인라인 또는 부분 문자열 텍스트의 기본 방향 설정하기
auto로 설정할 수도 있어야 하며, 이는
콘텐츠 자체를 검사하여 기본 방향을 결정한다는 의미입니다. 일반적인 접근 방식은
마크업 외부의 첫 번째 강한 방향 문자를 기준으로 방향을 설정하는 것입니다. 자세히
방향 감지 및 일치시키기(TBD)
오른쪽에서 왼쪽으로 쓰는 문자 체계로 작성되거나 그러한 문자 체계와 혼합된 텍스트에는 방향을 설정하는 것이 중요합니다. 이러한 문자 체계의 문자는 입력되고 발음되는 순서로 메모리에 저장되며, 이를 논리적 순서라고 합니다. 유니코드 양방향 알고리즘(UBA)은 논리적 순서로 저장된 문자 시퀀스를 예상되는 시각적 순서로 자동 렌더링하는 데 많은 기능을 제공합니다. 그러나 UBA만으로는 양방향 텍스트를 올바르게 렌더링하기에 충분하지 않으며, 특정 문자 시퀀스에 적용할 기본 방향 컨텍스트에 대한 추가 정보를 제공해야 합니다.
기본 요구사항은 다음과 같습니다.
위 요구사항의 특수한 경우가 데이터 구조와 문서 형식에 포함된 자연어 문자열 값에 적용됩니다.
자연어 텍스트가 포함된 모든 문자열 필드에서 해당 문자열의 언어와 문자열 방향을 결정할 수 있어야 합니다. 이러한 결정에는 문자열 또는 문서 수준의 메타데이터를 사용해야 하며 휴리스틱에 의존해서는 안 됩니다.
모든 현지화 가능한 텍스트에서 삽입된 인라인 양방향 텍스트 구간의 기본 방향 변경을 나타낼 수 있어야 합니다.
오른쪽에서 왼쪽으로 쓰는 문자 체계를 일상적으로 사용하는 사람이 오른쪽에서 왼쪽 텍스트에 주석을 추가할 때는 최소한의 노력만 필요해야 합니다.
아랍어, 디베히어, 히브리어, 페르시아어, 우르두어 등의 사용자가 작성하는 모든 단락이나 작은 데이터 항목에 마크업 또는 제어 문자를 추가하도록 요구하는 것은 감당하기에 지나치게 많은 작업입니다. 일반적으로 형식은 기본 방향을 설정하고 예외를 처리해야 할 때만 사용자가 개입하도록 해야 합니다.
이 절에서는 이후의 권고사항을 더 쉽게 이해할 수 있도록 텍스트 방향과 관련된 몇 가지 핵심 개념을 설명합니다.
'오른쪽에서 왼쪽' 문자 체계로 작성된 텍스트 또는 양방향 요소가 포함된 왼쪽에서 오른쪽 텍스트를 올바르게 표시하려면 텍스트 요소가 표시되는 순서를 결정하는 데 사용되는 기본 방향을 설정하는 것이 중요합니다.
유니코드 양방향 알고리즘(UBA)이 수행하는 것과 수행하지 않는 것, 그리고 기본 방향이 중요한 이유를 잘 모른다면 유니코드 양방향 알고리즘 기본 사항을 참조하십시오.
이 절에서 단락이라는 단어는 일반 텍스트에서
강제 줄바꿈이 뒤따르는 텍스트 구간을 나타내지만, 다른 상황에서는 다른 의미를 가질 수
있습니다. CSV에서는 '셀'에 해당하므로 쉼표로 구분된 항목의 한 줄은 실제로 쉼표로
구분된 단락의 집합입니다. HTML에서는 가장 낮은 수준의 블록 요소에 해당하며,
보통 p 요소이지만 텍스트 및/또는 인라인 요소만
포함하는 경우 div, li 등이 될
수도 있습니다. JSON에서는 흔히 따옴표로 묶인 문자열
값에 해당하지만, 문자열 값이 마크업을 사용하는 경우 단락은 블록 요소와 연결되고,
문자열 값이 여러 줄의 일반 텍스트인 경우 각 줄이 하나의 단락입니다.
여기서 메타데이터라는 용어는 데이터와 연결된 주석이나 속성, 이를 허용하는 경우의 마크업, 상위 수준 프로토콜 등의 정보라는 의미로 사용됩니다.
기본 방향을 설정할 수 있는 방법은 여러 가지입니다.
ltr, rtl 또는 auto가 포함될 수 있습니다.
dir=auto를 설정할 때 발생합니다.dir 속성이 없을 때 발생합니다.
html 태그에 dir 속성을 설정할 때 발생합니다. 또 다른 예로는
모두 아랍어로 작성된 여러 큐가 포함된 자막 파일이 있습니다. 작성자가 파일
시작 부분에서 모든 큐 텍스트의 기본값이 RTL이라고 지정할 수 있도록 하는
것이 좋습니다. 필요한 경우 특정 단락의 방향 정보를 재정의하는 방법이 항상
있어야 합니다.
auto로 설정한 경우에만 발생합니다.
사용자가 입력한 텍스트를 수집할 때는 일반적으로 입력의 기본 방향을 결정하기 위해
사용자가 데이터를 입력한 컨텍스트를 이해해야 합니다. 예를 들어 HTML에서는 html 태그에서 상속된
방향이나 사용자가 폼 필드의
기본 방향을 설정하기 위해 누른 키를 통해 이를 설정할 수 있습니다. 그런 다음 기본
방향에 대한 정보를 저장하거나 문자열이 렌더링될 때 문자열과 연결할 방법을 찾아야
합니다. 일반적으로 이러한 상황에서는 입력 중인 문자열 내부의 방향 변경을 사용자가
처리하며, 해당 변경은 문자열의 일부로 수집됩니다.
하나의 단락 내부에 삽입된 텍스트 범위에는 다른 기본 방향이 필요할 수 있습니다. 예를 들면 다음과 같습니다.
"The title was '!NOITASILANOITANRETNI'."
작은따옴표 안의 범위가 히브리어, 아랍어 또는 디베히어 등으로 되어 있는 경우 느낌표를 올바르게 배치하려면 주변 단락의 LTR 기본 방향 대신 RTL 기본 방향을 사용해야 합니다.
콘텐츠 작성자가 마크업을 사용할 수 있다면 마크업을 사용하여 이러한 인라인 범위를
나타내는 것이 더 쉽고 안전할 가능성이 큽니다. 아래 내용을 참조하십시오. HTML에서는
일반적으로 dir 속성이 있는 인라인 요소를
사용하여 이러한 텍스트 구간의 기본 방향을 설정합니다. HTML의 title 요소처럼 텍스트에 마크업을 적용할
수 없거나 일반
텍스트 콘텐츠만 처리하는 환경에서는 유니코드의 쌍으로 된 제어 문자를 사용하여 이러한
내부 범위의 기본 방향을 설정해야 합니다.
또한 기본 방향이 변경되는 인라인 범위는 주변 텍스트로부터 양방향 격리되어야 합니다. 그래야 경계를 넘어서는 간섭으로 인해 유니코드 양방향 알고리즘이 잘못된 결과인 "유출 효과"를 생성하지 않습니다.
이는 콘텐츠 작성자가 유니코드 제어 코드를 사용하는 경우 삽입 제어 문자인 RLE/LRE…PDF 대신 격리 제어
문자인 RLI/LRI/FSI…PDI를 사용해야 한다는 의미입니다.
방향 설정을 제어 문자에 의존하지 않아야 하는 이유는 다음과 같습니다.
위의 마지막 두 항목은 마크업에도 적용될 수 있지만 구현자는 일반적으로 포함된 제어 코드보다 포함된 마크업을 더 잘 지원합니다.
사용자가 모든 단락의 시작과 끝에 제어 코드를 추가할 것으로 기대하지 마십시오. 지나치게 많은 작업입니다.
여기에서는 유니코드 문자 
U+200F RIGHT-TO-LEFT MARK
(RLM), 
U+200E LEFT-TO-RIGHT MARK (LRM) 및 
U+061C ARABIC LETTER MARK (ALM)에 관해 설명할 필요가
있습니다.
먼저 명확히 해야 할 점은 이 세 문자가 텍스트 범위의 기본 방향을 설정하지 않는다는 것입니다. 이러한 문자는 강한 방향 속성이 있는 보이지 않는 문자일 뿐입니다.
앞의 예를 떠올려 보면, 예를 들어 RLM을 사용한다고 해서 W3C 텍스트가 히브리어 텍스트의 왼쪽에 표시되지는 않습니다. 메타데이터나 쌍으로 된 제어 문자를 사용해야만 올바르게 표시됩니다.
물론 HTML의 dir="auto"처럼 첫 번째 강한 문자 휴리스틱을 사용하여 기본
방향을 감지하는 경우, 텍스트가 잘못된 결과를 생성하는 문자로 시작할 때 RLM, ALM
또는 LRM을 삽입하면 감지되는 기본 방향에 영향을 줄 수 있습니다.
메타데이터를 사용하여 기본 방향을 설정하면, 메타데이터에서 첫 번째 강한 문자 휴리스틱을 사용해야 한다고 명시하지 않는 한 강한 방향 서식 문자는 무시된다는 점을 기억하십시오.
마지막으로 U+061C ARABIC LETTER MARK
(ALM)의 사용에 대해 설명합니다. 이 문자는 숫자 앞에 아랍어 문자가 없는 경우 아랍어
문자 체계 텍스트에서 숫자 시퀀스의 표시에 영향을 주기 위해 사용됩니다.
언어 태그를 사용하여 기본 방향에 관한 정보를 제공할 수 없는 이유는 다음과 같습니다.
auto 값을 생성할 수
없습니다.Suppress-Script:
Hebr)처럼 일반적으로 문자 체계 태그가 필요하지 않은 언어에서는 해당
태그의 사용을 생략하도록 권고합니다. 일반적으로 RTL 문자 체계로 작성되는
페르시아어와 같은 언어도 전사된 형태로 작성될 수 있으며, 방향 정보를 전달하는 데
필요한 문자 체계 태그가 존재한다고 보장할 수 없습니다. 요약하면 방향에 영향을
주기 위해 사람들이 언어 정보의 일부로 문자 체계 태그를 제공할 것이라고 의존할
수 없습니다.기본 기본 방향 값에는 왼쪽에서 오른쪽, 오른쪽에서 왼쪽 및 자동이 포함되어야 합니다.
auto 값을 사용하면 텍스트 조각의 기본 방향을
자동으로 감지할 수 있습니다. 예를 들어 HTML에서 dir의 auto 값은 텍스트의
기본 방향을 추정하기 위해 텍스트의 첫 번째 강한 방향 문자를 찾으며 특정 마크업 항목도
무시합니다. 자동 감지 알고리즘은 완벽하지 않다는 점에 유의하십시오. 첫 번째 강한 문자
감지는 실제로는 오른쪽에서 왼쪽 텍스트이지만 강한 LTR 문자로 시작하는 텍스트를 올바르게
식별할 수 없습니다. 텍스트 내용을 기준으로 기본 방향을 판단하려는 알고리즘에도 문제가
있습니다. 가장 좋은 상황은 기본 방향을 알고 있으며 명시적으로 선언하는 경우입니다.
이 절에서는 마크업을 사용하여 콘텐츠를 구성하는 리소스에서 작동하는 양방향 텍스트 처리 방법을 정의합니다. 일부 권고사항은 웹에서 문자열을 처리하기 위한 권고사항과 다릅니다. 3.5 문자열의 기본 방향 처리하기를 참조하십시오.
명세는 리소스 전체의 기본 기본 방향, 즉 전체 기본 방향을 정의하는 방법을 나타내야 합니다.
다른 정보가 없는 경우 기본 기본 방향은 auto여야 합니다.
콘텐츠 작성자는 텍스트에서 기본 방향이 변경되는 부분을 나타낼 수 있어야 합니다. 블록 수준에서는 속성이나 메타데이터를 사용하여 이를 수행해야 하며, 콘텐츠 작성자가 방향을 제어하기 위해 유니코드 제어 문자를 사용하도록 요구해서는 안 됩니다.
줄바꿈이 유니코드 제어 문자의 효과를 종료하므로 모든 블록의 방향을 설정하기 위해 유니코드 제어 문자에 의존하는 것은 적절하지 않습니다. 또한 필요한 모든 지점에 제어 문자를 배치해야 한다면 데이터의 안정성이 크게 떨어지고 관리가 불필요하게 어려워집니다.
콘텐츠 조각의 방향을 auto로 설정할 수도 있어야 합니다. 이는
콘텐츠 자체를
검사하여 기본 방향을 결정한다는 의미입니다.
HTML 및 CSS의 양방향 텍스트를 위한 추가 요구사항의 추정 알고리즘
일반적인 접근 방식은 마크업 외부의 첫 번째 강한 방향 문자를 기준으로 방향을 설정하는 것이지만, 이것이 유일한 방법은 아닙니다. 방향이 auto로 설정된 경우 방향성을 결정하는 데 사용하는 알고리즘은 수신자가 예상하는 알고리즘과 일치해야 합니다.
첫 번째 강한 문자 알고리즘은 유니코드 정의에 따라 단락에서 강한 방향 속성을 갖는 첫 번째 문자를 찾습니다. 그런 다음 해당 문자의 방향에 따라 단락의 기본 방향을 설정합니다.
RTL 단락이나 줄이 LTR 브랜드 이름 또는 기술 용어로 시작하는 경우처럼 첫 문자가 나머지 단락을 대표하지 않으면 첫 번째 강한 문자 알고리즘이 단락의 방향을 잘못 추정할 수 있다는 점에 유의하십시오.
방향을 감지하는 알고리즘에 대한 추가 정보는 HTML을 참조하여 이 문제를 논의한 문서의 추정 알고리즘을 참조하십시오.
일반 텍스트의 전체 기본 방향이 auto로 설정된 경우 콘텐츠 단락의
방향은 각 단락별로
결정해야 합니다.
텍스트 블록에 포함된 줄의 시작과 끝을 기준으로 블록의 면을 나타내려면 'top'과 'bottom' 대신 'block-start'와 'block-end'를 사용하십시오.
줄의 시작과 끝을 나타내려면 'left'와 'right' 대신 'start'와 'end' 또는 'inline-start'와 'inline-end'를 사용해야 합니다.
기본 방향과 양방향 재정의를 제어하기 위한 전용 속성을 제공하십시오. 사용자가 임의의 마크업에 스타일 속성을 적용하여 양방향 텍스트를 제어하도록 의존하지 마십시오.
양방향 텍스트 지원을 위한 CSS와 마크업, W3C 문서.
예를 들어 HTML에는 CSS 스타일의 도움 없이 기본 방향을 관리할 수 있는 dir 속성이 있습니다. XML
형식은 필요한 표시를
위해 CSS가 필요하더라도 방향 정보를 나타내는 전용 마크업을 정의해야 합니다. 텍스트가
다른 방식으로 사용될 수 있기 때문입니다.
CSS와 같은 스타일시트가 항상 데이터와 함께 사용되거나 데이터가 배포될 때 함께 전달되는 것은 아닙니다. 방향 정보는 데이터를 올바르게 표시하는 데 근본적으로 중요하므로 마크업이나 데이터와 더 밀접하고 영구적으로 연결해야 합니다.
이 절의 정보는 웹의 문자열: 언어 및 방향 메타데이터에서 가져왔습니다. 해당 문서는 아직 작성 중이므로 이 지침은 언제든지 변경될 수 있습니다.
메타데이터가 제공된 경우를 제외하고, 문자열 소비자가 가급적 유니코드 표준의 첫 번째 강한 문자 알고리즘을 기반으로 한 휴리스틱을 사용하여 문자열의 기본 방향을 감지하도록 지정하십시오.
웹의 문자열: 언어 및 방향 메타데이터의 모범 사례, 권고사항 및 미비점
가능한 경우 특정 리소스나 문서의 모든 문자열에 대한 기본 방향을 나타내는 필드를 정의하십시오.
웹의 문자열: 언어 및 방향 메타데이터의 모범 사례, 권고사항 및 미비점
개별 문자열의 방향을 변경할 수 없는 문서 수준 기본값을 만드는 것만으로 충분하다고 가정하지 마십시오.
웹의 문자열: 언어 및 방향 메타데이터의 모범 사례, 권고사항 및 미비점
레거시 구현으로 인해 메타데이터를 사용할 수 없고 다른 방법으로도 제공할 수 없는 경우, 명세는 사용 가능한 언어 메타데이터에서 문자열 방향을 추론하도록 허용할 수 있습니다.
웹의 문자열: 언어 및 방향 메타데이터의 모범 사례, 권고사항 및 미비점
여기서 '인라인 텍스트'는 마크업에서 쉽게 이해할 수 있는 의미를 갖습니다. 또한 JSON, CSV 또는 기타 일반 텍스트 형식의 문자열에도 적용되며, 문자열의 모든 문자를 포함하지 않는 문자 구간을 의미합니다.
기본 방향이 변경되는 인라인 텍스트 범위를 나타낼 수 있어야 합니다. 마크업을 사용할 수 있다면 이것이 선호되는 방법입니다. 그렇지 않으면 명세는 수신 애플리케이션이 유니코드 제어 문자를 인식하고 올바르게 구현하도록 요구해야 합니다.
인라인 텍스트 범위의 방향을 auto로 설정할 수도 있어야 하며, 이는 콘텐츠
자체를 검사하여
기본 방향을 결정한다는 의미입니다. 일반적인 접근 방식은 마크업 외부의 첫 번째 강한
방향 문자를 기준으로 방향을 설정하는 것입니다.
첫 번째 강한 문자 알고리즘은 유니코드 정의에 따라 단락에서 강한 방향 속성을 갖는 첫 번째 문자를 찾습니다. 그런 다음 해당 문자의 방향에 따라 단락의 기본 방향을 설정합니다.
RTL 단락이나 줄이 LTR 브랜드 이름 또는 기술 용어로 시작하는 경우처럼 첫 문자가 나머지 단락을 대표하지 않으면 첫 번째 강한 문자 알고리즘이 단락의 방향을 잘못 추정할 수 있다는 점에 유의하십시오.
방향을 감지하는 알고리즘에 대한 추가 정보는 HTML을 참조하여 이 문제를 논의한 문서의 추정 알고리즘을 참조하십시오.
사용자가 유니코드 양방향 제어 문자를 사용하는 경우 애플리케이션은 PDI 문자와 함께 격리 제어 문자인 RLI/LRI/FSI를 지원해야 하며, 명세는 PDF와 함께 사용하는 RLE/LRE 대신 이러한 문자를 권고해야 합니다.
RLM/LRM은 적절하게 사용해야 하며, 이러한 제어 문자가 할 수 있는 것과 할 수 없는 것을 명세에서 명확히 설명해야 합니다.
유니코드 양방향 제어 문자 U+200F RIGHT-TO-LEFT MARK 및
U+200E LEFT-TO-RIGHT MARK만으로는 양방향 텍스트를
관리하기에 충분하지 않습니다. 이러한 문자로는 삽입된 텍스트에 다른 기본 방향을 생성할
수 없습니다. 그러려면 삽입된 텍스트 범위의 시작과 끝을 나타낼 수 있어야 합니다.
가능한 경우 마크업을 사용하는 것이 가장 좋으며, 마크업을 사용할 수 없다면 바로 앞에서
언급한 다른 유니코드 양방향 제어 문자를 사용해야 합니다.
마크업에서는 기본 방향과 양방향 재정의를 제어하기 위한 전용 속성을 제공하십시오. 사용자가 임의의 마크업에 스타일 속성을 적용하여 양방향 텍스트를 제어하도록 의존하지 마십시오.
마크업에서는 텍스트가 포함된 모든 인라인 요소에 양방향 속성을 허용하십시오.
마크업에서는 사용자가 (a) 격리되거나 삽입된 기본 방향을 만들거나 (b) 양방향 알고리즘을 완전히 재정의할 수 있는 속성을 제공하십시오. 이러한 속성은 두 상황 모두에서 방향을 LTR, RTL 또는 Auto로 설정할 수 있도록 해야 합니다.
이 목록에는 이 절의 요구사항만 포함되어 있으며 자체 검토에 사용할 수 있습니다. 명세와 관련된 모든 요구사항에 대해 해당 줄의 첫 번째 체크박스를 선택하십시오. 명세가 요구사항을 충족하면 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
문자와 문자 인코딩의 기본 사항
'문자열' 정의 선택하기
DOMString을
사용하십시오. 이 사용 사례 목록이 전부는 아닙니다. 자세히USVString을
사용하십시오. UTF-8
인코딩이
포함되는 프로세스나 짝이 없는 서로게이트 코드
포인트가 오류를 발생시키는 모든 곳에도 USVString을
사용하십시오. 자세히
DOMString과
USVString을
혼합하지 마십시오. 대부분의 문서 형식이나 프로토콜에는 도움이 되지 않는 추가
처리가 후자에 필요하므로, 흔히 USVString보다
DOMString을
선택하게 됩니다. 자세히
DOMString
또는 드물게 USVString을
지정하십시오. 자세히Uint8Array를
지정하십시오. 자세히ByteString을
지정하십시오. 자세히참조 처리 모델 정의하기
문자 범위 포함 및 제외하기
사용자 정의 영역 사용하기
문자 인코딩 선택하기
문자 인코딩 식별하기
문자 이스케이프 설계하기
ካ 또는 \u{12F}처럼 명시적인 종료 구분
기호를 사용하거나, \u12AB 또는 \U001234AB처럼
고정된 자릿수를 사용해야 합니다. 자세히
텍스트 저장하기
공백 문자
문자라는 단어는 컨텍스트에 따라 서로 다른 의미를 갖습니다. 특정 텍스트 단위의 시각적 표현, 논리적 표현 또는 바이트 수준 표현을 가리킬 수 있습니다. 따라서 이 용어는 명세에서 특별한 정의 없이 사용하기에는 지나치게 부정확합니다. 그러므로 문자열 데이터의 처리를 논의하려면 컴퓨팅 시스템에서 텍스트가 정의되고 인코딩되는 방식과 명세를 명확하게 만드는 데 사용되는 관련 용어를 이해해야 합니다.
명세 개발자와 해당 명세를 기반으로 소프트웨어를 개발하는 사람은 자신이 경험한 '문자'라는 용어의 사용 방식에는 익숙하지만 국제적인 컨텍스트의 다양한 용례에는 익숙하지 않을 수 있습니다. 또한 컴퓨팅 컨텍스트에서 문자는 흔히 관련 개념과 혼동되어 불완전하거나 부적절한 명세와 소프트웨어가 만들어집니다.
문자, 문자열 또는 문자나 문자열을 처리하는 프로세스를 지정할 때는 가장 구체적이고 적절한 용어를 사용하십시오. 달리 해야 할 이유가 없다면 코드 포인트를 유니코드 스칼라 값을 의미하도록 정의하고 '문자'보다 이 용어를 우선하여 사용하십시오.
이 절에 나오는 용어 중 가장 적절한 용어를 사용하십시오. 다음은 권장되는 다른 용어입니다.
| 단위 유형 | 문자 대신 사용할 용어 | 설명 |
|---|---|---|
| 텍스트 단위 | 코드
포인트, 유니코드 코드 포인트, 유니코드 스칼라 값 |
문자 인코딩 형식이나 특정 직렬화 방식과 관계없는 텍스트의 논리적 단위입니다. |
| 저장, 처리, 직렬화, 인코딩 | 코드 단위 | 인코딩과 직렬화의 단위입니다. 코드 단위는 일반적으로 유선 및 파일 형식과 저수준 텍스트 처리에서 지정됩니다. 사용되는 문자 인코딩 (가급적 UTF-8 또는 UTF-16)에 따라 달라집니다. |
| 시각적 단위, 사용자가 인식하는 문자, 선택/분할 | 자소
클러스터, 타이포그래피 문자 단위 |
텍스트를 시각적 단위로 분할하는 작업, 대부분의 시각적 선택 및 잘라내기에 사용됩니다. 이 권고사항에는 가장 많은 세부적인 차이가 있습니다. |
| 글꼴의 구성 요소 | 글리프 | 개별 표시 값입니다. 주로 글꼴의 내용을 설명할 때 이 용어를 사용하십시오. |
'문자'라는 용어의 사용을 피할 수 없다면 해당 용어의 명확한 정의를 반드시 포함해야 합니다.
다음은 핵심 용어에 대한 간략한 용어집입니다.
[유니코드]
[D7]은 추상 문자를 다음과 같이 정의합니다. 텍스트 데이터의
구성, 제어 또는 표현에 사용되는 정보 단위.
이 정의는 필연적으로 모호하며, 추상
문자는 구체적인 형태를 갖지 않으므로 글꼴의 글리프와 혼동해서는 안 되고,
사용자가 "문자"라고 인식하는 것과도 다르므로 자소와 혼동해서는 안 된다고
설명합니다. 자체 명세에서는 이 용어를 사용하지 마십시오.
문자 집합은 텍스트를 함께 인코딩하는 데 사용할 수 있는 순서가 없는 추상 문자 모음입니다. 즉, 하나의 집합입니다. 문자 집합에 포함된 문자 모음을 해당 문자 집합의 레퍼토리라고 부르기도 합니다. 대부분의 문자 집합은 특정 범위의 언어나 문자 체계만 지원합니다.
[유니코드]는 때때로 범용 문자 집합이라고도 하며, 현대에 사용되는 문자뿐만 아니라 역사적이거나 소멸한 문자 체계, 사용자 정의 문자, 조판 기호, 이모지 등 현재 컴퓨터 시스템에서 텍스트를 인코딩하는 데 사용되는 모든 문자를 포함합니다. 다른 모든 문자 집합은 유니코드의 정의된 하위 집합입니다. 매년 개정판이 발표되면서 인코딩된 문자 집합이 확장됩니다.
[유니코드] 표준은 단순한 문자 집합보다 훨씬 많은 내용을 정의합니다. 텍스트 처리와 표시에 관한 다양한 속성, 알고리즘 및 기타 세부 사항도 정의합니다.
코드 포인트는 문자 집합의 추상 문자를 위한 고유 식별자입니다. 문자 집합이 유용하려면 각 문자를 모호하지 않게 식별해야 합니다. 대부분의 문자 집합에서 코드 포인트는 집합의 문자 표나 차트에서 해당 문자의 위치를 설명하는 숫자 또는 숫자 집합입니다.
[유니코드]에서
코드 포인트는
0x0000 이상 0x10FFFF 이하의 정수입니다. 16진수 표기법으로
작성합니다(4.11
유니코드 문자 참조하기 참조). 유니코드 코드 포인트를
유니코드 스칼라 값이라고
부르기도 합니다. 유니코드에서 추상 문자에 할당된 각 코드 포인트에는 변경되지 않는 고유한
이름도 부여됩니다. 유니코드는 할당된 각 문자에 여러 속성도 연결합니다. 이러한 속성 중
다수는 유니코드 문자 데이터베이스
(UCD) [UAX44]에 나타나며, 다른 속성은 보조
파일이나 표에서 할당됩니다.
[유니코드]
[D11]은 인코딩된 문자를 추상
문자와 코드 포인트 사이의
연결 또는
매핑
으로 정의합니다. 일반적으로 명세에서는 코드 포인트라는 용어를 사용하며,
더 구체적인 표현이 필요한 경우 유니코드 코드 포인트
또는 유니코드 스칼라 값을
사용합니다.
코드 포인트는 소프트웨어에서 문자를 저장하고 교환할 때 직접 사용되지 않습니다. 대신 코드 포인트가 나타내는 문자를 인코딩하고 처리하거나 한 표현에서 다른 표현으로 변환하기 위한 여러 체계가 존재합니다.
코드 단위는 물리적 저장과 정보 교환의 단위이며 컴퓨터 처리, 저장 및 통신의 기반이 됩니다. 가장 익숙한 코드 단위는 바이트 또는 옥텟이며 8비트로 구성됩니다.
런타임 환경에 따라 서로 다른 크기의 코드 단위를 사용합니다. 일반적인 다른 크기에는 16비트 또는 32비트 단위가 있습니다. 예를 들어 웹에서는 [DOM], JavaScript 및 [INFRA]의 여러 문자열 유형에서 16비트 코드 단위를 사용합니다. 이러한 명세는 [유니코드]의 UTF-16 문자 인코딩 규칙에 따라 처리되는 16비트 코드 단위를 사용합니다.
문자 인코딩 형식은 때때로 단순히 문자 인코딩이라고도 하며, 문자 집합의 코드 포인트를 텍스트 저장과 처리에 사용되는 코드 단위로 인코딩하거나, 코드 단위를 다시 코드 포인트로 디코딩하기 위한 규칙 집합입니다. 유니코드가 아닌 문자 인코딩 형식을 통틀어 레거시 문자 인코딩이라고 합니다.
UTF-8은 [유니코드]의 멀티바이트 문자 인코딩 형식입니다. 웹에서 가장 일반적으로 사용되는 문자 인코딩입니다. UTF-8은 8비트 바이트를 코드 단위로 사용합니다. UTF-8은 인코딩되는 코드 포인트에 따라 서로 다른 수의 코드 단위를 사용하는 가변 너비 인코딩입니다.
익숙한 7비트 ASCII 문자(U+0000부터 U+007F까지의 코드
포인트)는 UTF-8에서 한 바이트로 인코딩됩니다.
| 문자 | 코드 포인트 | UTF-8 코드 단위(바이트) |
|---|---|---|
| A | U+0041 |
0x41 |
U+0080부터 U+07FF까지의 코드 포인트에는 두 바이트가
필요합니다.
| À | U+00C0 |
0xC3 0x80 |
U+0800부터 U+FFFF까지의 코드 포인트에는 세 바이트가
필요합니다.
| न | U+0928 |
0xE0 0xA4 0xA8 |
마지막으로 U+10000부터 U+10FFFF까지의 코드 포인트에는 네
바이트가 필요합니다.
| 👪 | U+1F46A |
0xF0 0x9F 0x91 0xAA |
명세, 소프트웨어 및 콘텐츠는 문자(코드 포인트)와 물리적 저장 단위 (코드 단위) 사이의 일대일 관계를 요구하거나 이에 의존해서는 안 됩니다.
월드 와이드 웹 문자 모델 1.0: 기본 사항의 저장 단위 C009
명세, 소프트웨어 및 콘텐츠는 코드 포인트와 표시 단위(예: 자소 클러스터, 글리프 또는 타이포그래피 문자 단위) 사이의 일대일 매핑을 요구하거나 이에 의존해서는 안 됩니다.
월드 와이드 웹 문자 모델 1.0: 기본 사항의 시각적 렌더링 단위 C002
월드 와이드 웹 문자 모델 1.0: 기본 사항의 문자, 키 입력 및 글리프의 예
이 문서에서 시각적 텍스트 단위는 사용자가 인식하는 표시 텍스트의 한 단위를 가리킵니다. 화면일 수도 있고 종이에 인쇄되거나 냅킨 뒷면에 쓰인 것처럼 다른 매체일 수도 있습니다. 이 용어는 필연적으로 부정확합니다. 특히 결합 부호, 복잡한 위치 지정 또는 컨텍스트에 따른 복잡한 형태 변환을 사용하는 문자 체계의 경우 사용자의 인식은 문자 체계와 표기 체계에 대한 친숙도에 따라 달라지기 때문입니다. 자체 명세에서는 이 용어를 사용하지 마십시오.
자소 클러스터는 인코딩된 텍스트에서 시각적 텍스트 단위를 계산하여 근사한 것입니다. 즉, 사용자 관점에서 하나의 시각적 텍스트 단위를 형성할 것으로 예상되는 코드 포인트 시퀀스입니다. [유니코드]는 많은 텍스트 작업에서 이러한 시퀀스를 하나의 나눌 수 없는 텍스트 단위로 처리해야 하므로 텍스트 처리를 지원하기 위해 이러한 경계를 계산하는 방법을 제공합니다. 예를 들어 텍스트에서 커서를 이동할 때 커서는 전체 시각적 텍스트 단위와 그 기반 코드 포인트를 함께 건너뛰거나 선택해야 합니다. 시각적 텍스트 단위의 "중간"으로 커서를 이동할 수 없어야 합니다. 달리 지정하지 않는 한 이 문서의 자소 클러스터라는 용어는 유니코드 텍스트 분할 [UAX29]에서 "확장 기본 자소 클러스터"라고 부르는 것을 가리킵니다.
일부 텍스트 작업은 사용자가 자소 클러스터 내부의 개별 코드 포인트와 상호 작용하도록 허용한다는 점에 유의하십시오. 예를 들어 백스페이스 같은 일부 편집 기능은 시각적 텍스트 단위의 끝에서 문자를 점진적으로 삭제합니다. 이를 통해 사용자가 전체 클러스터를 지우지 않고도 오타를 수정할 수 있습니다.
타이포그래피 문자 단위라는 용어는 [CSS]에서 정의하며, 특정 작업에서 "하나의 단위"로 취급해야 하는 서로 다른 유형의 코드 포인트 시퀀스를 가리킬 때 사용합니다. 때로는 자소 클러스터라는 용어와 일치하지만 다른 경우에는 구별됩니다. 컨텍스트와 용례를 이해하는 경우에만 이 용어를 사용하십시오.
글리프는
특정 글꼴을 사용하여 렌더링할 때 문자 또는 문자 시퀀스를 시각적으로
표현한 것입니다. 글리프와 추상 문자가 항상 일대일 관계인 것은 아닙니다.
글리프는 문자의 일부나 여러 문자의 조합을 나타낼 수 있습니다. 서로 다른 글리프가 동일한 코드 포인트를
나타낼 수도 있습니다. 예를 들어 다음은 모두 AU+0041 LATIN CAPITAL LETTER A에
대한 서로 다른 글리프입니다.
따라서 글꼴은 텍스트 렌더링에 사용되는 특정 글리프 모음입니다.
명세, 소프트웨어 및 콘텐츠는 문자와 언어의 소리 사이의 일대일 대응 관계를 요구하거나 이에 의존해서는 안 됩니다.
월드 와이드 웹 문자 모델 1.0: 기본 사항의 청각적 렌더링 단위 C001
일부 문자 체계에서 문자는 음소와 밀접한 관계가 있습니다. 음소는 특정 구어의 컨텍스트에서 의미를 구별할 수 있는 최소 소리 단위입니다. 다른 문자 체계에서는 문자가 의미와 밀접하게 관련됩니다. 문자가 느슨한 의미에서 음소와 대응하는 경우에도 이 관계는 단순하지 않을 수 있으며, 문자와 음소가 일대일로 대응하는 경우는 드뭅니다.
다음은 문자라는 용어와 소리 단위가 일치하지 않는 예입니다.
명세와 소프트웨어는 한 번의 키 입력으로 하나의 문자가 생성되거나, 하나의 문자를 한 번의 키 입력으로 입력할 수 있거나(보조 키를 사용하는 경우도 포함), 전 세계의 키보드가 동일하다고 요구하거나 이에 의존해서는 안 됩니다.
월드 와이드 웹 문자 모델 1.0: 기본 사항의 입력 단위 C005
월드 와이드 웹 문자 모델 1.0: 기본 사항의 문자, 키 입력 및 글리프의 예
키보드 입력에서 키 입력과 입력 문자가 항상 일대일로 대응하는 것은 아닙니다. 키보드에 배치할 수 있는 키의 수는 제한되어 있습니다. 일부 키보드는 한 번의 키 입력으로 여러 코드 포인트를 생성합니다. 다른 경우에는 '데드 키'가 문자를 생성하지 않고 이후 키 입력의 결과에 영향을 줍니다. 많은 표기 체계에는 키보드에 배치하기에 지나치게 많은 문자가 있으므로 키 입력 시퀀스를 문자 시퀀스로 변환하는 더 복잡한 입력 방식에 의존해야 합니다. 다른 언어에서는 특수 보조 키를 사용하여 일부 문자를 입력해야 할 수 있습니다.
단순하지 않은 입력의 예는 문자, 키 입력 및 글리프의 예를 참조하십시오.
문자열은 일반적으로 '문자'의 시퀀스로 이해됩니다. [유니코드]는 레거시 문자 인코딩을 사용하는 텍스트를 포함하여 텍스트를 이해하고 처리하는 데 핵심적이므로, 문자열의 기본 정의는 유니코드와 인코딩된 문자라는 개념에 의존합니다. 구체적으로 다음과 같습니다.
문자열은 0개 이상의 유니코드 스칼라 값으로 이루어진 올바른 형식의 시퀀스입니다.
문자열을 처리하는 방법이 여러 가지이므로 서로 다른 명세의 요구사항을 지원하기 위해 "문자열"에 대한 여러 정의가 발전했습니다. 명세에 필요한 사항을 정확히 이해하고 가장 적절하고 정밀한 정의를 사용하십시오.
웹에는 세 가지 문자열 유형이 있습니다.
USVString.
코드 포인트,
즉 유니코드 스칼라
값을
기반으로 하는 문자열
DOMString.
UTF-16 코드 단위를
기반으로 하는 문자열
ByteString.
특정 문자 인코딩
형식
(가급적 UTF-8)의 바이트를 기반으로 하는
문자열이러한 문자열 유형의 차이 중 하나는 서로게이트 코드 포인트를 처리하는 방식입니다. 유니코드 스칼라 값, 즉 문자를 나타내는 코드 포인트와 문자 인코딩 형식의 인코딩 단위인 코드 단위의 차이에 유의하십시오.
UTF-16 문자 인코딩 형식은
16비트 코드 단위를 사용합니다. 스칼라 값에 16비트보다
많은 비트가 필요한 문자는 서로게이트 코드 단위 한 쌍을 사용하여
인코딩됩니다. U+D800-U+DBFF 범위의 "하위 서로게이트" 뒤에
U+DC00-U+DFFF 범위의 "상위 서로게이트"가 옵니다. 유니코드는
UTF-16의 코드 단위와
일반 텍스트가 혼동되지 않도록 이러한 범위의 코드
포인트를 비문자로 예약합니다.
USVString에서는
분리된 서로게이트 코드 포인트가 유효하지
않으며, 구현은 문자열에서 이러한 코드 포인트가 발견되면 유니코드 대체 문자(�U+FFFD REPLACEMENT CHARACTER)로 바꿔야 합니다.
퍼센트 인코딩처럼 가장 일반적인 알고리즘이 스칼라 값에서 작동하는 문자열이나 문자열을
네이티브 플랫폼 API로 전달하는 API처럼 입력에 있는 서로게이트를 처리할 수 없는 작업에는
USVString을 사용해야
합니다. 다음 참조는 모두 이 정의와 같습니다.
DOMString에서는 짝이
없는 서로게이트 코드 단위가 문자열에 나타날 수
있습니다. 대부분의 문자열 작업은 문자열 내부의 코드
단위를 해석할 필요가 없습니다.
DOMString을 지정하면
구현에서 문자열의 내용을 검증할 필요가 없으므로 대부분의 데이터 구조, 형식 또는 API에
이상적인 문자열 유형이 됩니다. [DOM]과 JavaScript 문자열은 DOMString을
문자열
유형으로 사용하며, [INFRA] 표준은 '문자열'이라는 용어를 DOMString을
의미하도록
정의합니다.
문자열은 부호 없는 16비트 정수의 시퀀스이며, 이를 코드 단위라고도 합니다.
[INFRA]에서 사용하는 코드 단위라는 용어는 모든 문자 인코딩 형식에서 바이트처럼 서로 다른 크기의 값을 가리킬 수 있는 더 일반적인 코드 단위 정의가 아니라, 구체적으로 UTF-16 문자 인코딩의 코드 단위를 가리킵니다.
ByteString은 문자를
바이트로 인코딩하는 데 사용되는 문자 인코딩 형식에
따라 달라집니다. 레거시 문자
인코딩에는 "서로게이트"라는 개념이 없으므로 일반적으로 서로게이트 코드 포인트를
인코딩할 수 없습니다. 유효한 UTF-8은 서로게이트
코드 포인트를
허용하지 않습니다. 텍스트를 UTF-8로 인코딩하거나 UTF-8에서 디코딩할 때 이러한 코드
포인트는 �U+FFFD REPLACEMENT CHARACTER로 대체됩니다. UTF-16을 UTF-8로 변환할
때 모든 서로게이트 쌍은
특정 스칼라 값을 인코딩하는
올바른 UTF-8 바이트 시퀀스로 변환됩니다.
문서 형식이나 프로토콜의 유선 형식을 정의할 때, [DOM]과 관련된 프로세스를 정의할 때 또는 개별 문자
콘텐츠를 평가하지 않는 불투명한 값으로 문자열을 정의할 때는 DOMString을
사용하십시오. 이 사용 사례 목록이 전부는 아닙니다.
문자열의 코드
포인트를 순회하는 알고리즘을
정의할 때는 USVString을
사용하십시오. UTF-8 인코딩이
포함되는
프로세스나 짝이 없는 서로게이트 코드 포인트가
오류를 발생시키는 모든 곳에도 USVString을
사용하십시오.
하나의 문서나 프로토콜 작업에서 DOMString과 USVString을 혼합하지
마십시오. 대부분의 문서 형식이나 프로토콜에는 도움이 되지 않는 추가 처리가 후자에
필요하므로, 흔히 USVString보다
DOMString을
선택하게 됩니다.
4.6 문자 인코딩 선택하기에서 문자 인코딩과 관련된 추가 모범 사례를 참조하십시오.
웹의 문자열: 언어 및 방향 메타데이터 [STRING-META]의 레거시 프로토콜 또는 형식의 일부인 문자열
유니코드가 널리 채택되기 전에는 문자열을 바이트 문자열로
정의하는 것이 일반적이었습니다. 이러한 문자열은 문자 또는 코드 포인트의 시퀀스가
아니라 단순한 바이트 값의 시퀀스입니다. 바이트 문자열의 익숙한 예는 C 프로그래밍
언어의 char*입니다.
바이트 문자열을 처리하거나 해석하는 방식은 문자 인코딩 형식에 따라 달라집니다. 많은 레거시 문자 인코딩은 상태를 갖습니다. 이러한 인코딩을 처리할 때는 문자 상태를 유지하여 추상 문자를 성공적으로 디코딩, 처리 또는 수정할 수 있도록 바이트 버퍼의 시작부터 처리해야 하는 경우가 많습니다. 이러한 인코딩에서 동일한 바이트 값도 인접한 바이트에 따라 서로 다른 의미를 가질 수 있습니다. 예를 들어 정확히 동일한 바이트 값이 하나의 문자를 단독으로 나타내거나, 앞에 오는 바이트에 따라 다른 문자를 나타내는 멀티바이트 시퀀스의 일부가 될 수 있습니다. 각 바이트 또는 바이트 시퀀스를 해석하는 방법을 결정하는 규칙은 레거시 문자 인코딩마다 다릅니다. 잘못된 문자 인코딩을 사용하여 바이트 문자열을 처리하면 잘못된 문자가 생성됩니다. 이러한 현상을 모지바케라고도 합니다.
UTF-8은 웹의 유선 및 문서 형식 [ENCODING]과 일반적인 인터넷 [RFC3629]에서 선호되는 문자 인코딩입니다. 콘텐츠가 UTF-8로 인코딩되어 있다면 이를 바이트 시퀀스로 직접 처리할 이유는 거의 없습니다. 대부분의 웹 API와 인터페이스는 특정 바이트 값이 아니라 해당 문자를 나타내는 코드 포인트 시퀀스에 더 관심이 있습니다.
때로는 명세에서 바이트 값의 저장, 해석 및 조작을 처리해야 합니다. 특히 많은 문서 형식과
프로토콜은 7비트 [ASCII]
바이트를 기반으로 정의되었으며, 여러 문자 또는 데이터 인코딩 체계를 사용하여 비ASCII
데이터 값을 포함하거나 교환하도록 허용합니다. 이는 text 미디어 유형의
charset 매개변수처럼 문자 인코딩 형식을
지정하여 수행할 수 있습니다. 또는 바이트 값을 특별한 구문으로 인코딩할 수 있으며
퍼센트
인코딩이 그
예입니다.
선호되는 기본 문자 인코딩 형식으로 UTF-8이 널리 사용되면서 대부분의 명세에서 기반 바이트 값에 접근하거나 이를 조작할 필요성이 줄어듭니다. UTF-8은 7비트 ASCII 텍스트도 유효한 UTF-8이 되도록 설계되었으며, 이는 ASCII 기반 형식을 인코딩하거나 디코딩할 때 중요할 수 있습니다.
특정 바이트 값과 상호 작용해야 할 이유가 있거나 UTF-8 문자 인코딩을
가정할 수 없는 경우가 아니라면, 바이트를 사용하여 정의된 프로토콜이나 문서 형식의
필드에는 DOMString
또는 드물게 USVString을
지정하십시오.
해당 필드를 문자열로 처리하려는 경우 바이트 값을 직접 처리하는 것보다 유니코드 문자를 처리하는 편이 더 안정적입니다. 이러한 필드로 인코딩된 데이터는 유선 형식에서 역직렬화되어 [DOM], JavaScript 문자열 또는 플랫폼의 네이티브 유니코드 문자열 유형 같은 로컬 메모리 내 문자열 표현으로 변환됩니다. 이후에는 특정 문자 인코딩 형식 (일반적으로, 그리고 가급적 UTF-8)을 사용하여 유선 형식으로 직렬화해야 합니다.
텍스트를 포함하지 않는 데이터나 버퍼 복사처럼 처리가 전혀 필요하지
않은 텍스트를 나타내는 바이트 시퀀스 등, 바이트 시퀀스를 처리할 때는 Uint8Array를
지정하십시오.
명세에서 바이트를 사용하여 인코딩된 문자열을 처리해야 하고
유니코드와의 변환이 부적절한 드문 경우에는 ByteString을
지정하십시오.
웹 플랫폼 설계 원칙 [DESIGN-PRINCIPLES]의 IDL 문자열 유형
ByteString은
범용 문자열 유형이 아닙니다. [WebIDL]에서 데이터 구조를
정의하는 데 사용하지 마십시오.
프로토콜 또는 형식 명세에서 정의하는 텍스트 데이터 객체는 하나의 문자 인코딩을 사용해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 참조 처리 모델 C013
텍스트 처리가 포함되는 모든 명세는 이 목록의 나머지 권고사항에서 설명하는 참조 처리 모델에 따라 텍스트 처리를 지정해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 참조 처리 모델 C014
명세는 텍스트 데이터 객체에 대해 유니코드 인코딩 형식으로 트랜스코딩할 수 있는 모든 문자 인코딩의 사용을 허용할 수 있습니다.
월드 와이드 웹 문자 모델: 기본 사항의 참조 처리 모델 C014
명세는 일부 문자 인코딩을 금지하거나 폐기 예정으로 지정하고 다른 인코딩을 필수로 지정할 수 있습니다. 실제 문자 인코딩과 관계없이 지정된 동작은 다음과 같이 처리가 이루어진 것과 동일해야 합니다. (a) 명세를 구현하는 애플리케이션이 수신한 텍스트 데이터 객체의 문자 인코딩을 확인하고 데이터 객체를 유니코드 문자 시퀀스로 해석해야 합니다. 이는 필요한 경우 문자 인코딩 레이블을 조정하고 데이터 객체를 유니코드 인코딩 형식으로 트랜스코딩한 다음 해당 유니코드 인코딩 형식으로 수신한 것과 동일해야 합니다. (b) 모든 처리는 이 유니코드 문자 시퀀스에서 이루어져야 합니다. (c) 애플리케이션이 텍스트를 출력하는 경우 유니코드 문자 시퀀스는 명세에서 허용하는 문자 인코딩 중 하나를 사용하여 인코딩해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 참조 처리 모델 C014
XML 문서가 외부 파싱 엔터티를 참조하는 경우처럼 여러 텍스트 데이터 객체가 관련되는 명세는 이러한 데이터 객체가 서로 다른 문자 인코딩을 사용하도록 허용할 수 있습니다. 모든 경우에 참조 처리 모델을 모든 텍스트 데이터 객체에 적용해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 참조 처리 모델 C014
명세는 U+0000부터 U+10FFFF까지 포함하는 전체 유니코드 코드 포인트 범위에서 코드 포인트를 임의로 제외해서는 안 됩니다.
월드 와이드 웹 문자 모델: 기본 사항의 참조 처리 모델 C070
여기서 "서로게이트 코드 포인트"는 U+D800부터 U+DFFF까지
포함하는 범위의 문자 값을 사용하는 것을 가리킵니다. 이러한 코드 포인트는 UTF-16 문자
인코딩에서 보충 문자를
표현할 수 있도록 예약되어 있습니다. 서로게이트는 항상 쌍으로 사용되며 UTF-16 인코딩을
사용할 때만 나타납니다. 하나만 있는 서로게이트 코드 포인트를 "짝이 없는 서로게이트"라고
하며 절대로 사용해서는 안 됩니다.
명세는 정의하는 형식의 구문 요소(마크업, 구분 기호, 식별자)에서 호환성 문자를 제외해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 호환성 및 서식 문자 C050
명세는 사용자 정의 코드 포인트에 관한 합의를 정의하는 메커니즘의 사용을 요구해서는 안 됩니다.
월드 와이드 웹 문자 모델: 기본 사항의 사용자 정의 코드 포인트, C039
명세와 구현은 사적인 합의에 따른 사용자 정의 코드 포인트의 사용을 금지해서는 안 됩니다.
월드 와이드 웹 문자 모델: 기본 사항의 사용자 정의 코드 포인트, C040
명세는 유니코드에 없는 기호를 전송하거나 유니코드 문자의 특정 변형을 식별하기 위한 마크업을 정의할 수 있습니다.
월드 와이드 웹 문자 모델: 기본 사항의 사용자 정의 코드 포인트, C041
명세는 그림이나 그래픽에 문자 중심 메커니즘을 잘못 사용할 필요가 없도록 적절한 경우 그림과 그래픽의 포함 또는 참조를 허용해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 사용자 정의 코드 포인트, C068
역사적으로, 특히 유니코드가 만들어지기 전에는 문자를 컴퓨터 시스템의 메모리나 저장소에 인코딩하고 직렬화하는 서로 다른 체계를 사용하는 여러 부호화 문자 집합이 일반적으로 사용되었습니다. ISO/IEC 8859에서 지정한 것과 같은 표준 기반 체계뿐만 아니라 관련 문자 인코딩 형식이 있는 독점적인 공급업체 또는 플랫폼별 문자 집합도 많이 존재했습니다. 이 문서에서 레거시 유니코드 비기반 부호화 문자 집합의 문자 인코딩 형식을 언급할 때는 [인코딩]에서 지정한 바이트와 유니코드 코드 포인트의 구체적인 현대적 매핑을 의미합니다.
모든 문서 형식, 프로토콜 및 직렬화 형식에 UTF-8을 사용하십시오.
UTF-8은 거의 모든 애플리케이션에 가장 적합한 선택입니다.
새로운 프로토콜과 형식 및 새로운 컨텍스트에 배포되는 기존 형식은 UTF-8 문자 인코딩을 사용해야 합니다. 이 정책은 IETF와 웹 표준에 적용되며 [RFC2277], [RFC3629], [인코딩], [design-principles] 등 여러 문서에 명시되어 있습니다. 레거시 문자 인코딩이 필요한 명세는 이전 프로토콜이나 형식을 처리하는 명세뿐이며, 그러한 경우에도 UTF-8을 강력히 권고합니다.
역사적인 이유로 명세가 레거시 문자 인코딩을 허용하는 경우, 허용되는 문자 인코딩 집합을 인코딩 표준의 "이름과 레이블" 절에 나열된 인코딩으로 제한해야 합니다. 사적인 합의에 따른 경우를 제외하고 다른 인코딩을 사용해서는 안 됩니다.
월드 와이드 웹 문자 모델: 기본 사항의 문자 인코딩 식별, C021
월드 와이드 웹 문자 모델: 기본 사항의 문자 인코딩 식별, C022
월드 와이드 웹 문자 모델: 기본 사항의 문자 인코딩 식별, C023
여러 문자 인코딩 형식을 허용하는 명세는 필드나 매개변수처럼 텍스트의 인코딩을 명확하게 식별하는 메커니즘을 제공해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 문자 인코딩 선택 및 식별, C015
문자 인코딩은 바이트 값만으로는 신뢰성 있게 감지할 수 없습니다. UTF-8 이외의 인코딩을 허용한다면 소비자가 인코딩을 확인할 수 있는 메커니즘이 있어야 합니다.
프로토콜, 형식 또는 API가 이미 문자 인코딩을 선택, 적용 또는 레이블 지정하는 규칙이 있는 형식을 기반으로 하는 경우, 명세는 문자 인코딩을 식별하는 별도의 메커니즘을 정의해서는 안 됩니다.
월드 와이드 웹 문자 모델: 기본 사항의 문자 인코딩 선택 및 식별, C017
문서 형식이나 프로토콜은 때때로 레거시 문자 인코딩을 지원합니다. 이러한 형식을 기반으로 하는 명세는 가능한 경우 적합한 구현이 UTF-8만 사용하도록 지정할 수 있습니다.
명세는 문자 인코딩에 관한 정보가 여러 개이거나 서로 충돌하는 경우를 위한 충돌 해결 메커니즘(예: 우선순위)을 정의해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 문자 인코딩 식별, C028
입력하거나 편집하기 어려운 시퀀스를 일반 텍스트 편집기로 입력할 수 있도록 문자 이스케이프를 제공하는 것이 일반적으로 권장됩니다. 이스케이프 시퀀스는 너비가 0인 공백, 소프트 하이픈, 여러 양방향 제어 문자, 몽골 문자 모음 구분자 등 보이지 않거나 모호한 유니코드 문자에 특히 유용합니다.
마크업에서 이스케이프를 사용하는 방법에 관한 조언은 대부분 다른 형식에도 일반화할 수 있는 마크업과 CSS에서 문자 이스케이프 사용하기를 참조하십시오.
다음은 웹이나 일반적인 프로그래밍 언어에서 사용되는 대표적인 이스케이프 메커니즘의
예입니다. 예제 문자는 😽U+1F63D KISSING CAT FACE WITH CLOSED
EYES입니다.
| 사용 환경 | 유형 | 예 | 설명 |
|---|---|---|---|
| HTML, XML | 16진수 NCR | 😽 |
유니코드 코드 포인트의 16진수 인코딩 |
| 10진수 NCR | 😽 |
유니코드 코드 포인트의 10진수 인코딩 | |
| JavaScript, Ruby, Rust, [UTS18] | \u 구분 형식 |
\u{1F63D} |
유니코드 코드 포인트의 16진수 인코딩 |
| Perl | \x 구분 형식 |
\x{1F63D} |
유니코드 코드 포인트의 16진수 인코딩. 더 일반적인 u 대신
x를 사용합니다.
|
| Java, JavaScript, JSON, C, C++, Python | \u UTF-16 코드 단위 |
\uD83D\uDE3D |
UTF-16 코드 단위의 고정 너비 16진수 인코딩. 보충 문자는 서로게이트 쌍으로 인코딩됩니다. |
| C, C++, Python | \U UTF-32 코드 단위 |
\U0001f63d |
UTF-32 코드 단위의 고정 너비 16진수 인코딩. 더 일반적인 BMP
문자에는 더 효율적인 \u 이스케이프와 함께 사용하는 경우가
많습니다.예: \u00c0 \U0001f63d \u12fe
|
| URL | URL 인코딩 | %F0%9F%98%BD |
UTF-8 바이트의 16진수 인코딩. 각 바이트에는 세 문자가 필요하며 각 코드 포인트에는 1~4바이트가 필요합니다. |
이스케이프 메커니즘을 선택할 때는 유니코드 표준과 해당 참조에서 16진수를 일반적으로 사용하므로 10진수 인코딩보다 16진수를 선호한다는 점에 유의하십시오.
하나의 문자를 이스케이프하는 서로 다른 방법의 수는 최소화해야 합니다. 이상적으로는 하나여야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 문자 이스케이프, C043
이스케이프 구문은 ካ 또는
\u{12F}처럼 명시적인 종료 구분 기호를 사용하거나,
\u12AB 또는 \U001234AB처럼 고정된 자릿수를 사용해야
합니다.
월드 와이드 웹 문자 모델: 기본 사항의 문자 이스케이프, C044
종료 구분 형식이 권장됩니다.
종료 구분 이스케이프는 코드 포인트에 필요한 자릿수만 사용할 수 있으므로 고정 너비 형식보다 간결하며, 닫는 구분 기호를 사용하면 이스케이프가 끝나는 위치를 더 쉽게 확인할 수 있습니다.
명세가 숫자를 사용하여 문자를 표현할 수 있는 문자 이스케이프를 정의할 때마다 숫자는 문자의 유니코드 코드 포인트를 나타내야 하며 16진수 표기법을 사용해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 문자 이스케이프, C045
이스케이프된 문자는 이스케이프되지 않은 형식이 허용되는 모든 위치에서 허용되어야 합니다. 다만 구문상 중요한 문자를 이스케이프하면 구문에서의 의미를 잃을 수 있습니다. 특히 식별자와 주석에서 문자가 허용되는 경우 이스케이프된 형식도 허용되어야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 문자 이스케이프, C046
프로토콜, 데이터 형식 및 API는 텍스트 데이터를 논리적 순서로 저장, 교환 또는 처리해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 시각적 렌더링과 논리적 순서, C003
구현이 논리적 선택을 사용하는지 시각적 선택을 사용하는지와 관계없이 선택된 문자는 저장소에서 논리적 순서로 유지되어야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 시각적 렌더링과 논리적 순서, C075
범위 선택이 포함되는 프로토콜 및 API 명세는 적어도 해당 프로토콜과 API 위에서 화면의 시각적 선택 구현을 지원하는 데 필요한 범위까지 비연속적인 논리적 선택을 제공해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 시각적 렌더링과 논리적 순서, C004
공백 문자는 타이포그래피에서 수평 또는 수직 공간을 나타내는 문자입니다. 공백 문자는 서로 다른 시각적 효과를 가질 수 있습니다. 일부 공백 문자는 눈에 보이는 효과가 없지만 다른 문자는 페이지에서 더 크거나 작거나 가변적인 공간을 나타냅니다.
"공백"이라는 용어를 사용하는 명세는 해당 용어의 의미를 명시적으로 정의해야 합니다.
대부분의 명세는 공백을 유니코드 White_Space 속성이 있는 문자로 정의해야 합니다.
명세가 "공백"을 ASCII 또는 유니코드 공백과 다르게 정의하는 경우 구체적인 코드 포인트를 나열해야 합니다.
ECMAScript 같은 일부 명세는 자체 요구사항을 충족하기 위해 위의 정의와 다른 고유한 공백 정의를 제공합니다.
다음 표는 여러 명세의 공백 문자 정의를 보여줍니다.
white_space 속성 |
pattern_white_space 속성 |
ASCII 공백 (HTML) | CSS 공백 | 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 셰이딩 언어는
pattern_white_space 속성을 사용합니다.
명세에서 유니코드 코드 포인트를 표현할 때는 U+XXXX 구문을 사용하십시오.
U+XXXX 형식은 명세에서 유니코드 코드 포인트를 참조할 때 널리
이해됩니다. 시퀀스로 나타날 때는 공백으로 구분합니다. 추가 장식은 필요하지 않습니다.
코드 포인트는 4개, 5개 또는 6개의 16진수 숫자를 포함할 수 있습니다. 네 자리보다 적은
숫자가 필요한 경우 코드 포인트 숫자 앞을 0으로 채웁니다.
특정 코드 포인트를 설명할 때는 유니코드 문자 이름을 사용하십시오.
유니코드는 할당된 각 유니코드 코드 포인트에 고유하고 변경되지 않는 이름을 부여합니다.
특정 문자를 참조할 때 이러한 이름을 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 속성에는 주어진 컨텍스트에 올바른 글꼴이
선택되도록 적절한 값을 입력해야 합니다. 중국어, 일본어 또는 한국어 같은 동아시아 언어나
아랍어 문자 체계의 예에서는 언어 태그를 선택할 때 더 주의해야 할 수 있습니다. 드물게
특정 언어에서는 자체 스타일시트에서 bdi 요소의 스타일을 font-family 및/또는 font-size로
조정해야 할 수 있습니다.
제어 문자처럼 보이지 않는 문자, 결합 문자 또는 공백에는 문자 대신 이미지를 사용하십시오.
또는 문자와 이를 둘러싼 bdi 요소를 생략할 수도
있습니다.
<span class="codepoint" translate="no"><img alt="..." src="..."><code class="uname">U+XXXX UNICODE_CHARACTER_NAME_ALL_IN_CAPS</code></span>
짧은 문자 시퀀스에서는 문자 이름을 +로 구분하여 나열해야 합니다.
문자 이름과 추가 마크업을 포함하는 것이 지나치게 엄격하여 사용성을 떨어뜨리는 경우도
있지만, 의미를 훼손할 정도로 비형식적으로 작성하지 않도록 주의하십시오. 특히 긴
시퀀스는 코드 포인트만 나열하는 경우가 있지만, 명확성을 위해 가능하면 문자 이름을
유지해야 합니다. 이 문서의 조합된 "가족" 이모지에 관한
설명에서 예를 확인할 수 있습니다. 👨👩👧👧U+1F468 U+200D U+1F469 U+200D U+1F467 U+200D U+1F467
일반적으로 명세에는 문자에 대한 정의와 해당 문자에 연결된 의미 체계가 모두 필요하므로, ISO/IEC 10646에 대한 참조를 포함하는지 여부와 관계없이 유니코드 표준에 대한 참조를 포함하는 것이 권장됩니다.
월드 와이드 웹 문자 모델: 기본 사항의 유니코드 표준 및 ISO/IEC 10646 참조하기, C062.
명세가 게시된 이후에 할당된 문자를 해당 명세에서 사용할 수 있도록 하려면 유니코드 표준에 대한 일반적인 참조를 포함해야 합니다. 특정 버전에 의존하는 기능을 사용할 수 있고 시간이 지나도 변경되지 않도록 보장하기 위해 유니코드 표준의 특정 버전에 대한 참조를 포함할 수 있습니다.
월드 와이드 웹 문자 모델: 기본 사항의 유니코드 표준 및 ISO/IEC 10646 참조하기, C063.
유니코드 표준에 대한 모든 일반적인 참조는 해당 참조를 포함하는 명세의 게시일에 사용할 수 있는 최신 버전의 유니코드 표준을 가리켜야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 유니코드 표준 및 ISO/IEC 10646 참조하기, C064.
ISO/IEC 10646에 대한 모든 일반적인 참조는 해당 참조를 포함하는 명세의 게시일에 사용할 수 있는 최신 버전의 ISO/IEC 10646을 가리켜야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 유니코드 표준 및 ISO/IEC 10646 참조하기, C065.
이 목록에는 이 절의 요구사항만 포함되어 있으며 자체 검토에 사용할 수 있습니다. 명세와 관련된 모든 요구사항에 대해 해당 줄의 첫 번째 체크박스를 선택하십시오. 명세가 요구사항을 충족하면 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
분할, 인덱싱 등에 사용할 텍스트 단위 선택하기
식별자와 구문 콘텐츠의 문자열 동일성 일치
다음 단계에 따라 식별자와 구문 콘텐츠의 문자열 동일성 일치를 정의하십시오.
유니코드 정규화 처리하기
대소문자 접기
문자열 길이 잘라내기 또는 제한하기
문자열 연결
파일 및 경로 이름 처리하기
정렬 및 검색 기능 지정하기
소프트웨어 프로세스가 부분 문자열에 접근하거나 문자열 내부의 지점을 가리켜야 하며, 이를 문자열 내부의 숫자 "위치"인 인덱스를 사용하여 수행하는 상황이 많습니다. 이러한 인덱스가 웹의 구성 요소 사이에서 교환되는 경우 일관된 동작을 보장하기 위해 합의된 문자열 인덱싱 정의가 필요합니다. 발생하는 두 가지 주요 질문은 "계수 단위는 무엇인가?"와 "0부터 셀 것인가, 1부터 셀 것인가?"입니다.
사용자 상호 작용이 주된 관심사인 애플리케이션에서는 문자열 인덱싱의 기반으로 자소 클러스터를 사용할 수 있습니다.
월드 와이드 웹 문자 모델: 기본 사항의 문자열 인덱싱, C071
복잡한 문자 체계의 타이포그래피 문자 단위 자소 클러스터만으로 복잡한 문자 체계를 분할하기에 충분하지 않을 수 있는 상황을 설명합니다.
문자 인코딩: 필수 개념의 문자 및 클러스터
자소 클러스터를 기준으로 인덱싱을 정의하는 명세는 다음 중 하나를 수행해야 합니다. (a) 유니코드 표준 부속서 #29, 유니코드 텍스트 분할(UTR #29)에서 정의하는 확장 자소 클러스터를 기준으로 자소 클러스터를 정의하거나, (b) 인덱싱 작업에 맞춤화가 적용되는 방식을 구체적으로 정의해야 합니다.
월드 와이드 웹 문자 모델: 기본 사항의 문자열 인덱싱, C071
유니코드 표준 부속서 #29, 유니코드 텍스트 분할의 자소 클러스터 경계
복잡한 문자 체계의 타이포그래피 문자 단위 자소 클러스터만으로 복잡한 문자 체계를 분할하기에 충분하지 않을 수 있는 상황을 설명합니다.
문자 인코딩: 필수 개념의 문자 및 클러스터
반례는 DOM 레벨 1에서 UTF-16을 사용하는 것입니다. UTF-16 코드 포인트의 사용은 두 서로게이트 문자 사이에 인덱스가 위치할 가능성을 남기므로 권장되지 않습니다. 이는 심각한 문제를 일으킬 수 있습니다 (6.5 문자열 길이 잘라내기 또는 제한하기 참조).
부분 문자열이나 문자열 내부의 지점을 식별하는 방법이 필요한 명세는 이 작업을 수행할 때 문자열 인덱싱 이외의 방법을 고려해야 합니다.
계수 단위 선택과 관계없이, 명세는 단일 문자를 부분 문자열로 이해하고 처리하며 인덱스를 계수 단위 사이의 경계 위치로 취급해야 합니다.
다음 단계에 따라 식별자와 구문 콘텐츠의 문자열 동일성 일치를 정의하십시오.
월드 와이드 웹 문자 모델: 문자열 일치의 일치 알고리즘
특별한 이유가 없다면 식별자와 구문 콘텐츠의 정규화(즉, 대소문자 접기 또는 유니코드 정규화)를 지정하지 마십시오.
월드 와이드 웹 문자 모델: 문자열 일치의 적절한 정규화 단계 수행하기
'ASCII 대소문자 접기'는 ASCII로 제한된 애플리케이션 내부 식별자에만 사용해야 합니다.
어휘 명세는 구문 콘텐츠와 문자 데이터 사이의 경계뿐만 아니라 엔터티 경계(언어에 포함 메커니즘이 있는 경우)를 정의해야 합니다.
월드 와이드 웹 문자 모델: 문자열 일치의 정규화를 위한 추가 고려사항
명세는 주어진 어휘의 인코딩, 저장 또는 교환을 위한 유니코드 정규화 형식을 지정해서는 안 됩니다.
월드 와이드 웹 문자 모델: 문자열 일치의 정규화를 위한 추가 고려사항.
소비자나 콘텐츠 자체가 비정규화된 표현에 의존할 수 있으므로, 콘텐츠를 유니코드 문자 인코딩으로 트랜스코딩하거나 대소문자 접기 또는 사용자가 시작한 기타 변경 같은 텍스트 변환의 부수 효과로 필요한 경우를 제외하고, 구현은 교환, 읽기, 파싱 또는 처리 중인 텍스트 데이터의 정규화 형식을 변경해서는 안 됩니다.
월드 와이드 웹 문자 모델: 문자열 일치의 정규화를 위한 추가 고려사항.
정준적으로 동등하지만 서로 다른 유니코드 문자 시퀀스가 보안 문제를 나타내는 경우, 명세는 이를 문서화하거나 주의 경고를 제공해야 합니다.
월드 와이드 웹 문자 모델: 문자열 일치의 정규화를 위한 추가 고려사항.
정규화된 텍스트 입력으로부터 비정규화된 출력을 생성할 수 있는 작업이 있는 경우, 명세는 결과 출력을 정규화해야 하는지 정의해야 합니다. 명세는 일부 작업에서 정규화 수행을 선택 사항으로 지정할 수 있습니다. 이 경우 기본값은 정규화를 수행하는 것이어야 하며, 정규화를 해제하려면 명시적인 옵션을 사용해야 합니다.
월드 와이드 웹 문자 모델: 문자열 일치의 문서 형식에서 정규화를 지정할 때의 요구사항.
정규화를 요구하는 명세는 정규화 구현을 선택 사항으로 만들어서는 안 됩니다.
월드 와이드 웹 문자 모델: 문자열 일치의 문서 형식에서 정규화를 지정할 때의 요구사항.
구현이 먼저 검사를 통해 텍스트가 정규화된 형식임을 확인하거나 텍스트를 직접 다시 정규화하지 않았다면 정규화에 민감한 작업을 수행해서는 안 됩니다. 이러한 규칙이 적용되지 않는 사설 시스템 내부에서는 사적인 합의를 만들 수 있지만, 외부에서 관찰할 수 있는 모든 결과는 규칙을 준수한 경우와 동일해야 합니다.
월드 와이드 웹 문자 모델: 문자열 일치의 문서 형식에서 정규화를 지정할 때의 요구사항.
텍스트를 수정하고 정규화에 민감한 작업을 수행하는 정규화 텍스트 처리 구성 요소는 각 수정 후 정규화가 수행된 것처럼 동작해야 하며, 그 결과 이후의 정규화에 민감한 작업은 항상 정규화된 텍스트를 처리하는 것처럼 동작해야 합니다.
월드 와이드 웹 문자 모델: 문자열 일치의 문서 형식에서 정규화를 지정할 때의 요구사항.
문자열 값을 비교하거나 일치시키는 명세는 유니코드 정규화에 관한 적절한 참고 또는 경고를 지정해야 합니다.
명세에서 유니코드 정규화를 사용하거나 채택하는 것은 일반적으로 해당 형식이나 프로토콜에서 일치가 이루어지는 방식을 정의하는 일부입니다. 명세 작성자와 구현자가 관련된 복잡성을 이해하는 데 도움을 주기 위해 국제화 작업 그룹은 문자열의 일치와 비교에 관한 고려사항을 설명하는 문서인 월드 와이드 웹 문자 모델: 문자열 일치 [CHARMOD-NORM]를 개발했습니다.
명세에서 선택해야 하는 사항 중 하나는 명세 어휘의 일부로 정의된 여러 "값"의 일치에 유니코드 정규화를 요구할지 여부입니다. 값은 일반적으로 문서 형식이나 프로토콜 구문의 일부이며 속성 이름이나 값, 요소 이름이나 값, ID 등을 포함합니다. 일치의 일부로 정규화를 사용하지 않도록 하는 권고사항을 따르는 명세는 콘텐츠 작성자에게 이를 상기시키기 위해 다음 참고를 포함해야 합니다.
참고 예제. 이 버전은 필연적으로 "값"을 구성하는 요소를 구체적으로 지정하지 않습니다. 명세에서 더 구체적으로 작성할 수 있습니다.
이 명세는 비교를 목적으로 값의 유니코드 정규화를 허용하지 않습니다. 시각적·의미적으로 동일하지만 서로 다른 유니코드 문자 시퀀스를 사용하는 값은 일치하지 않습니다. 콘텐츠 작성자는 값을 선택할 때 동일한 인코딩 시퀀스를 일관되게 사용하거나 잠재적으로 문제가 될 수 있는 문자를 피하는 것이 좋습니다. 자세한 내용은 [CHARMOD-NORM]을 참조하십시오.
문자열 일치의 일부로 정규화를 요구하도록 선택하는 명세는 다음 경고를 포함해야 합니다.
경고 예제. 이 버전은 필연적으로 "값"을 구성하는 요소를 구체적으로 지정하지 않습니다. 명세에서 더 구체적으로 작성할 수 있습니다.
이 명세는 값을 일치시킬 때 유니코드 정규화를 적용합니다. 이는 영향을 받는 텍스트의 모양과 의미에 영향을 줄 수 있습니다. 자세한 내용은 [CHARMOD-NORM]을 참조하십시오.
위 내용이 요구사항을 충족하지 못하거나 사용 방법이 확실하지 않은 경우 대안이나 도움을 받으려면 I18N WG에 문의하십시오.
형식, 프로토콜 또는 형식 언어의 정의 일부로 문자열 일치(파싱, 일치, 토큰화 등의 작업을 포함할 수 있음)를 정의하는 명세와 구현은 사용되는 기준과 일치 형식을 정의해야 합니다. 이는 다음 중 하나여야 합니다. (a) 대소문자 구분, (b) 유니코드 전체 대소문자 접기를 사용하는 유니코드 대소문자 비구분, (c) ASCII 대소문자 비구분.
유니코드의 기본 라틴(ASCII) 범위를 초과하는 문자가 포함된 어휘에서 대소문자 비구분 일치를 정의하는 명세는 유니코드 전체 대소문자 접기 일치를 지정해야 합니다.
월드 와이드 웹 문자 모델: 문자열 일치의 유니코드 대소문자 비구분 일치.
유니코드의 기본 라틴(ASCII) 하위 집합으로 제한된 어휘에서 대소문자 비구분 일치를 정의하는 명세는 ASCII 대소문자 비구분 일치를 지정할 수 있습니다.
월드 와이드 웹 문자 모델: 문자열 일치의 ASCII 대소문자 비구분 일치.
일부 명세, 형식, 프로토콜 또는 그 구현은 주어진 문자열의 크기 제한을 지정해야 합니다. 이는 처리, 메모리, 데이터 구조 크기 등에 대한 제한을 포함한 여러 이유 때문일 수 있습니다. 길이 제한에는 흔히 텍스트를 잘라내거나 크기를 제한하는 작업이 포함되므로, 명세와 구현은 텍스트가 손상되지 않고 선택한 제한으로 인해 특정 사용자가 해당 기능을 사용할 수 없게 되지 않도록 각별히 주의해야 합니다.
특별한 실용적 또는 기술적 제한이 없다면 명세는 문자열 길이에 제한을 두어서는 안 됩니다.
명세에서 길이 제한을 지정하는 경우, 잘린 문자열에는 줄임표처럼 문자열이 변경되었음을 나타내는 표시가 포함되도록 지정해야 합니다.
명세나 형식에서 길이 제한이 필요한 이유는 많습니다. 가장 일반적인 이유는 데이터에 기반 크기 제한이 있기 때문입니다. 예를 들어 데이터베이스에 고정 크기 필드가 있거나 패킷 크기 같은 실질적인 경계 또는 저장소 할당이나 효율성과 관련된 기타 구현 세부 사항이 있을 수 있습니다. 또 다른 일반적인 이유는 표시 영역이나 눈에 보이는 출력의 크기에 제한이 있기 때문입니다.
문자열을 잘라낼 때는 문자열 크기를 셀 때 사용할 단위를 결정해야 합니다. 일부 경우에는 잘라내기가 미리 정해진 이유로 발생하므로 명세가 이를 제어할 수 없습니다. 그러나 선택할 수 있는 경우에는 몇 가지 일반적인 지침을 적용할 수 있습니다.
일정 수의 시각적 텍스트 단위(예: 자소 클러스터)를 사용하여 저장된 문자열을 잘라내도록 지정하지 마십시오.
시각적 길이 제한이 필요한 경우 문자열을 변경하지 않으며 텍스트 렌더링의 복잡성을 고려하는
CSS text-overflow [css-overflow-4]
같은 텍스트 렌더링 또는 클리핑 메커니즘을 사용하여 시각적 잘라내기를 지정하십시오.
명세는 때때로 사용할 수 있는 가시 영역의 대용으로 시각적 텍스트 단위 수를 사용하여 시각적 제한을 처리하려고 합니다. 이러한 제한은 한 줄의 문자 수를 제한하거나 모든 시각적 텍스트 단위의 렌더링 너비를 동일하게 만들려는 시도처럼 여러 형태로 나타날 수 있습니다. 시각적 텍스트 단위를 사용하는 것은 인코딩된 문자열의 코드 포인트 또는 코드 단위 수보다 이러한 임의의 제한에 더 가깝게 대응합니다. 그러나 텍스트 표시의 특성상 이러한 시도는 대체로 효과가 없습니다. 비례 너비 글꼴, 복잡한 문자 체계, 스타일, 접근성 기능 및 여러 다른 요인으로 인해 문제가 복잡해집니다. 거의 모든 경우 시각적 텍스트 단위 제한은 실제로 픽셀 너비를 근사하려는 시도입니다. 제한을 실제로 측정하려면 표시 컨텍스트의 글꼴 메트릭이 필요합니다. 접근성 설정 같은 로컬 설정의 영향도 받을 수 있습니다. 웹 페이지에서는 CSS text-overflow 속성이 텍스트 콘텐츠를 손상하지 않고 시각적 잘라내기를 제공합니다. 주어진 텍스트의 크기를 유니코드 코드 포인트 수 또는 자소 클러스터 수를 기반으로 추정하려는 시도는 대부분 의미가 없습니다.
문자열의 허용 가능한 최대 저장 길이를 제한하는 명세는 해당 길이를 유니코드 코드 포인트 단위로 지정해야 합니다.
대부분의 제한은 실제로 데이터베이스 필드의 크기나 프로토콜의 길이 제한 같은 저장소 제한과 관련됩니다. 이러한 제한은 유니코드의 코드 포인트 단위 또는 특정 문자 인코딩의 코드 단위(예: 바이트)로 표현됩니다. 코드 포인트는 모든 유니코드 코드 포인트를 동일하게 취급하므로 최상의 사용자 경험을 제공합니다. 텍스트를 40개의 코드 포인트 뒤에서 자르면 모든 언어와 문자 체계에 동일한 수의 코드 포인트가 제공됩니다. 반대로 크기 제한을 UTF-8의 바이트 같은 코드 단위로 표현하면, 대부분 ASCII 문자를 사용하는 언어의 사용자는 주어진 크기 제한에서 코드 포인트당 2, 3 또는 4바이트가 필요한 문자를 주로 사용하는 언어의 사용자보다 훨씬 많은 문자(코드 포인트)를 사용할 수 있습니다.
길이 제한에 맞추기 위해 문자열 잘라내기를 허용하는 명세는 이러한 잘라내기가 시각적 텍스트 단위 경계(일반적으로 자소 클러스터 경계로 근사됨)에서 이루어지도록 요구해야 합니다.
길이 제한에 맞추기 위해 문자열을 잘라내는 구현은 시각적 텍스트 단위 경계(일반적으로 자소 클러스터 경계로 근사됨)에서 잘라내야 합니다.
결합 문자 시퀀스 같은 시각적 텍스트 단위의 중간에서 잘라내면 남은 문자열의 의미가 바뀔 수 있습니다.
길이 제한을 표현하는 방법(코드 포인트 또는 바이트)을 선택하는 것 외에도 잘라내기 경계를 선택하는 문제가 있습니다. 텍스트를 코드 포인트 중간에서 나누면 문자가 손상되므로 절대로 나누면 안 됩니다. 텍스트를 자소 클러스터 중간에서 나누면 표시되는 문자의 모양과 의미가 바뀌므로 나누지 않아야 합니다. 의미에 영향을 주지 않도록 추가 코드 포인트를 제거해야 할 수 있습니다.
문자열 길이 제한은 데이터베이스 필드의 크기나 다른 곳에서 지정된 데이터 값에 할당된 바이트 수 같은 외부 요인에 의해 결정되는 경우가 있습니다. 또는 고정 길이 바이트 중심 유선 프로토콜을 설명하는 것 같은 실질적인 설계 이유로 길이 제한을 코드 단위로 지정해야 할 수 있습니다. 이러한 명세와 구현은 아래의 고려사항을 포함하여 이로 인해 추가되는 복잡성을 명시해야 합니다.
이 모범 사례는 UTF-8 같은 멀티바이트 인코딩뿐만 아니라 16비트 코드 단위를
사용하는 UTF-16에도 동일하게 적용됩니다. U+10000과
U+10FFFF 사이의 유니코드 코드 포인트를
인코딩하는 데 사용되는 UTF-16 서로게이트 쌍에는
두 개의 코드
단위가 필요합니다.
서로게이트 쌍의 중간에서 임의로 잘라내면 인코딩된 문자가 손상됩니다.
[DOM]을 참조하는 명세는 문자열 작업을 코드 포인트 경계로 제한하도록 지정해야 하며, 적절한 경우 시각적 텍스트 단위 또는 자소 클러스터 내부에서 시작하거나 끝나는 것을 피해야 합니다.
[DOM]과 상호 작용하는 명세나 API는 length, substringData, insertData, deleteData 등의 작업을 포함한 문자 데이터가 유니코드 코드 포인트가 아니라 UTF-16 코드 단위를 사용하여 지정된다는 사실을 처리해야 합니다. 이로 인해 문자(코드 포인트)의 중간에서 부적절하게 잘라낼 수 있습니다.
명세에서 문자열 길이 제한을 코드 단위로 표현해야 하지만 문자열 크기를 자유롭게 지정할 수 있다면, 허용 가능한 코드 포인트 수에 관련 문자 인코딩의 최대 인코딩 크기를 곱한 값을 기준으로 제한을 선택하십시오.
고정 크기 버퍼에 저장할 수 있는 코드
포인트 수는 문자 인코딩 형식과
해당 코드 단위에 따라
달라집니다.
예를 들어 UTF-8은 문자당 1~4바이트를 사용하여 유니코드 코드 포인트를
인코딩합니다. 따라서 최대 인코딩 크기는 네 개의 코드 단위입니다. 반면 UTF-16은
1개 또는 2개의 16비트 코드 단위를 사용합니다. 따라서 최대 인코딩 크기는
두 개의 코드 단위입니다. 주어진 문자열이 최소 50개의 코드 포인트를 저장해야 하는
경우, UTF-8 바이트의 길이 제한은 50 * 4, 즉 200바이트입니다. UTF-16의
길이 제한은 50 * 2, 즉 100개의 16비트 코드 단위이며, 이는 200바이트와
같습니다. 이러한 제한을 사용하면 문자열에 항상 최소 50개의 코드 포인트를
저장할 수 있으며, 사용하는 문자에 따라 특정 언어에서는 더 많은 문자를 저장할 수
있습니다.
길이 제한을 선택할 때 유니코드에 있는 서로 다른 문자 체계와 언어의 요구사항을 고려하십시오. 주어진 문자 인코딩에서 텍스트 크기 제한을 코드 단위(예: 바이트 길이 제한)로 설정하는 경우, 서로 다른 문자 체계에서 문자 인코딩의 상대적인 효율성을 고려해야 합니다. 특히 UTF-8은 [유니코드]의 멀티바이트 문자 인코딩입니다. UTF-8은 문자의 유니코드 스칼라 값에 따라 코드 포인트당 1~4바이트를 사용합니다.
텍스트 필드의 제한을 바이트 단위로 계산하는 경우 해당 필드에 저장할 수 있는 문자 수는 저장되는 문자에 따라 달라집니다. 여러 언어를 사용하는 사용자가 불리하지 않도록 하려면 해당 언어로 인코딩했을 때 합리적인 수의 문자를 허용하도록 제한을 설정해야 합니다.
명세가 코드 단위(예: 바이트)로 길이 제한을 지정하는 경우, 제한을 측정하는 데 사용되는 문자 인코딩을 지정해야 하며, 이러한 제한은 레거시 문자 인코딩을 지정해서는 안 됩니다.
명세가 문자열의 잘라내기를 허용하거나 요구하며 길이를 코드 단위로 표현하는 경우, 제한의 의미를 이해하려면 문자 인코딩이 중요합니다. 제한이 바이트 단위이고 레거시 문자 인코딩이 허용되는 경우, 유니코드 데이터를 비유니코드 인코딩으로 변환하면 데이터가 손실될 수 있다는 점에 유의하십시오. 대부분의 레거시 문자 인코딩은 유니코드의 하위 집합만 인코딩하기 때문입니다.
여러 문자열을 연결하여 자연어 텍스트 값을 만드는 것은 국제화 안티패턴입니다. 언어는 어순, 수, 문법적 성 또는 격, 구두점 및 여러 다른 요구사항에서 크게 다릅니다. 따라서 구현이 부분 문자열로 사람이 읽을 수 있는 메시지를 생성하도록 요구하거나 제안하지 마십시오.
명세가 구현에 사용자에게 표시될 텍스트를 만들거나 생성하도록 요구하는 경우, 명세는 텍스트 방향과 관련된 잠재적 문제를 피하는 방법에 관한 지침을 구현자에게 제공해야 합니다.
API, 프로토콜 또는 문서 형식의 명세는 때때로 구현이 표시 이름이나 설명을 포함하는 필드를 만들거나 제공하도록 요구합니다. 이러한 문자열을 별도의 부분으로 조합하면 유니코드 양방향 알고리즘 [UAX9]이 조합된 문자열을 처리하는 방식으로 인해 표시 또는 이해 문제가 발생할 수 있습니다. 이러한 경우 명세는 올바르게 표시되는 값을 만드는 방법을 구현자에게 안내해야 합니다.
일부 명세는 여러 구현에서 파일 이름이나 파일 경로가 구성되는 방식을 정의해야 합니다. 한 가지 과제는 서로 다른 운영 체제에서 사용하는 다양한 파일 시스템에서도 일관되게 작동하는 정의를 만드는 것입니다. 이 절에는 파일 이름이나 파일 경로의 제한을 정의할 때 적용하는 일반 지침이 포함되어 있습니다. 이 지침은 [EPUB-33]에서 개발된 요구사항과 구현 경험을 기반으로 합니다.
파일 이름은 길이를 255바이트로 제한해야 합니다.
이 제한은 원래 MS-DOS와 특정 Unix 파일 시스템 및 이러한 파일 시스템에 의존하거나 해당 제한을 포함한 PKZIP 같은 패키징 체계에서 발견되는 제한과 관련이 있습니다. 이러한 시스템에서는 디렉터리 이름을 포함한 특정 "경로 요소"가 255바이트로 제한됩니다.
경로 이름은 길이를 65535바이트로 제한해야 합니다.
이 제한은 FAT32 또는 NTFS 같은 파일 시스템에서 발견되는 제한과 관련이 있습니다. 이러한 시스템은 경로 길이를 UTF-16 문자 인코딩의 32760(32K) 코드 단위로 제한합니다. 각 UTF-16 코드 단위는 16비트(2바이트)이므로 바이트로 측정하면 제한은 65,535가 됩니다. UTF-8은 가변 너비 인코딩이므로 UTF-8에서 64K 바이트로 제한된 경로 이름은 이러한 파일 시스템의 경로 길이 제한을 초과할 수 있습니다.
파일 이름과 경로 이름 정의는 다음 유니코드 코드 포인트를 사용해서는 안 됩니다.
이러한 문자는 여러 파일 시스템에서 상호 운용성 문제를 일으키는 것으로 알려져 있습니다. 콘텐츠의 상호 운용성이 중요한 경우 명세와 구현은 파일 이름을 지정할 때 각별히 주의해야 합니다. 제한 문자 목록은 알려진 문제 영역 중 일부를 방지하기 위한 것이지만 다른 모든 유니코드 문자의 지원을 보장하지는 않습니다.
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+FFFFF
U+100000...U+10FFFF
U+002E FULL STOP(여기에는 여러 파일 시스템에서
특별한 의미가 있는 파일 이름 .과 ..도 포함됨)애플리케이션은 정보나 콘텐츠 집합을 구성해야 하는 경우가 많습니다. 여기에는 흔히 콘텐츠 정렬이 포함됩니다. 숫자나 날짜 같은 여러 비텍스트 데이터 유형은 내부 데이터 표현을 사용하여 쉽게 정렬할 수 있습니다. 그러나 텍스트 정보의 경우 문자 인코딩의 특성과 "알파벳순"에 대한 사용자의 기대 때문에 추가적인 복잡성이 발생합니다.
한 가지 중요한 선택은 텍스트 데이터의 정렬이 완전히 내부용인지 또는 결과가 사용자에게 표시되는지 여부입니다.
사람이 보거나 상호 작용하기 위한 것이 아닌 프로그램 내부의 빠르고 결정론적인 텍스트 정렬이 필요한 명세나 구현은 문자열 정의에 따라 문자열을 정렬하도록 지정해야 합니다. 스칼라 값 문자열(USVString 또는 여러 XML 프로세스 등)에는 코드 포인트 오름차순을 지정하십시오. UTF-16을 기반으로 하는 문자열 유형(DOMString 또는 여러 JavaScript API 등)에는 코드 단위 오름차순을 지정하십시오.
내부 정렬 시퀀스에는 유니코드 코드 포인트에 따른 정렬과 UTF-16 코드 단위에 따른 정렬이라는 두 가지 가능성이 있습니다. 어느 유형의 정렬도 결과 목록이 특정 알파벳순이나 사전식 순서와 일치하지 않습니다.
코드 포인트 정렬은 USVString처럼 문자열이 코드 포인트 시퀀스로 저장되고 처리되는 경우에 적합합니다. 코드 단위 정렬은 DOMString처럼 문자열이 기반 인코딩을 사용하여 저장되고 처리되는 경우에 적합합니다.
이러한 정렬 순서는 비교되는 문자열에 어떤 유형의 정규화도 적용하지 않습니다. 따라서 겉보기에 동등한 일부 문자열이 서로 다른 것으로 비교됩니다. 자세한 내용은 문자열 일치 [CHARMOD-NORM]을 참조하십시오.
사용자에게 표시할 자연어 텍스트 정렬을 처리해야 하는 명세나 애플리케이션은 추가적인 복잡성을 고려해야 합니다. 유니코드는 유니코드 조합 알고리즘 [UTS10]의 일부로 기본 조합(정렬) 순서를 정의하며, 이후 특정 언어, 로캘 및 문화의 요구사항에 맞게 조정합니다.
사용자에게 표시하기 위해 텍스트를 정렬할 때 정렬 순서는 해당 애플리케이션의 특정 사용자에게 가장 적절한 로캘에 맞게 조정해야 합니다. 따라서 표시 순서는 사용자마다 다를 수 있습니다.
언어와 문화에 따라 텍스트를 정렬하거나 알파벳 또는 문자 체계를 사용하여 텍스트 데이터를
구성하는 방법이 다릅니다. 예를 들어 독일어 사용자는 üU+00FC LATIN SMALL LETTER U WITH DIAERISIS 문자를
u 문자와 비슷하게 정렬되는 문자로 취급합니다. 독일어에는 실제로 이
문자를 처리하는 방식이 약간 다른 두 가지 정렬 시퀀스가 있습니다. 반면
덴마크어 사용자는 동일한 문자를 알파벳의 별도 문자로 취급하고 "y" 뒤에 정렬합니다.
정렬된 목록에 사용할 로캘을 결정하는 것은 여러 요인에 따라 달라질 수 있습니다. 예를 들어 애플리케이션은 데이터가 나타나는 페이지의 현지화에 따라 값 목록을 정렬할 수 있습니다. 다른 경우에는 사용자 에이전트의 런타임 로캘이나 API에 전달된 특정 매개변수에 따라 정렬하는 것이 더 적절할 수 있습니다. 중요한 점은 이 순서가 사용자나 시스템에 따라 달라질 수 있다는 사실을 인식하는 것입니다.
이 목록에는 이 절의 요구사항만 포함되어 있으며 자체 검토에 사용할 수 있습니다. 명세와 관련된 모든 요구사항에 대해 해당 줄의 첫 번째 체크박스를 선택하십시오. 명세가 요구사항을 충족하면 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
리소스 식별자에서 비ASCII 문자 지원을 지정하는 상황은 복잡합니다. 리소스 식별자와 그 직렬화를 정의하는 명세가 URI [RFC3986], IRI [RFC3987], [URL] 등 최소 세 개이기 때문입니다. WHATWG [URL] 명세는 브라우저와 기타 사용자 에이전트의 실제 동작을 문서화하여 이러한 복잡성을 해결하려는 시도입니다. URL 명세에서 명시한 목표는 두 RFC를 모두 폐기하는 것입니다.
일반적으로 웹의 문서 형식은 비ASCII 문자를 일반 텍스트, 즉 "IRI"로 인코딩하는 리소스 식별자를 사용합니다. HTTP [RFC9110]를 포함하되 이에 국한되지 않는 프로토콜은 비ASCII 문자를 퍼센트 인코딩을 사용하는 바이트 시퀀스, 즉 "URI"로 인코딩하는 리소스 식별자를 사용합니다. [RFC3986]은 문자를 바이트로 인코딩할 특정 문자 인코딩을 지정하지 않으므로, 퍼센트 인코딩 이스케이프는 잘못 해석되기 쉽습니다. 이를 방지하기 위해 여러 최신 프로토콜과 명세는 유선 형식과 프로토콜이 지원하는 ASCII 하위 집합으로 문자를 인코딩할 때 IRI에 지정된 것과 정확히 동일하게 UTF-8 문자 인코딩을 사용하도록 요구합니다.
여러 경우 주어진 리소스의 이름이나 식별자가 사용자 입력에서 생성되므로 문서 형식이나 프로토콜은 비ASCII 문자를 포함하는 리소스 식별자를 지원해야 합니다. 일반적으로 사용자는 이러한 값에 자신의 언어를 사용하는 능력을 제한받지 않으며 제한받아서도 안 됩니다.
문서 형식, 데이터 구조 또는 API를 정의하는 웹 명세는 리소스 식별자를 지정할 때 [URL]을 참조해야 합니다. [URL] 명세가 지원하지 않는 경우에는 대신 IRI [RFC3987]를 지정할 수 있습니다.
프로토콜을 정의하는 명세는 유선 형식에 사용할 리소스 식별자를 지정할 때 URI [RFC3986]를 참조할 수 있지만, 퍼센트 인코딩된 값을 문자로 해석할 때 UTF-8을 사용해야 한다는 추가 요구사항을 포함해야 합니다.
[RFC3986]의 정의에 따르면 URI 참조는 ASCII 하위 집합으로 제한되며 비ASCII 문자를 직접 사용할 수 없습니다. 임의의 바이트 값을 이스케이프하기 위해 퍼센트 인코딩이 제공됩니다. 그러나 여러 다른 레거시 문자 인코딩을 사용하여 주어진 바이트 시퀀스를 문자로 해석하거나 주어진 문자 시퀀스를 바이트로 인코딩할 수 있으므로, 퍼센트 인코딩만으로는 가치가 제한적입니다. 국제화 리소스 식별자(IRI) [RFC3987]는 [유니코드]의 UTF-8 인코딩을 기반으로 하는 일관된 접근 방식을 통해 리소스 식별자에서 비ASCII 문자를 인코딩하고 해석할 때 발생하는 문제를 해결합니다.
명세는 리소스 식별자에서 허용되는 문자에 자체 제한을 둘 수 있지만, 이러한 제한은 리소스 식별자의 구문, 전송 형식 또는 명세 자체에서 정의한 다른 요소와 충돌하는 문자에 초점을 맞춰야 합니다.
일반적으로 권장되지는 않지만 추가 제한을 고려하는 경우 [UAX31]과 [CHARMOD-NORM]을 검토하여 추가 지침을 확인하십시오.
이 목록에는 이 절의 요구사항만 포함되어 있으며 자체 검토에 사용할 수 있습니다. 명세와 관련된 모든 요구사항에 대해 해당 줄의 첫 번째 체크박스를 선택하십시오. 명세가 요구사항을 충족하면 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
마크업에서 요소와 속성 정의하기
마크업에서 일반 텍스트 처리하기
구문 콘텐츠의 키워드, 식별자 및 네임스페이스 정의하기
U+D800~U+DFFF) 또는 비문자 코드 포인트를 허용해서는
안 됩니다. 자세히
U+0000~U+001F) 및 C1
(U+0080~U+009F) 제어 문자를 허용해서는
안 됩니다. 자세히
형식 언어, 문서 형식, 프로토콜 또는 API를 다루는 명세는 마크업, 구문 또는 애플리케이션 내부 식별자를 정의해야 하는 경우가 많습니다. 이 절의 모범 사례는 이를 정의할 때 서로 다른 요구사항을 다룹니다.
마크업 언어나 특정 마크업 언어를 기반으로 하는 구문을 정의하는 명세는 요소, 속성 및 그 값을 정의하는 데 중점을 둡니다. 예를 들어 [XML] DTD는 특정 문서 유형에서 유효한 요소와 속성을 정의합니다.
특정 문서 형식, 프로토콜 또는 API를 정의하는 명세는 일반적으로 예약 키워드, 필드 이름 또는 허용되는 값의 식별자를 정의하는 데 중점을 둡니다. 이들 중 다수는 이름과 값이 명세에서 완전히 정의되는 애플리케이션 내부 식별자입니다. 경우에 따라 명세는 이들 중 일부 또는 전부를 사용자가 입력하거나 이름을 지정할 수 있는 사용자 제공 값으로 허용합니다.
사용자가 읽을 수 있는 콘텐츠를 포함할 속성 값을 정의하지 마십시오. 이러한 콘텐츠에는 요소를 사용하십시오.
XML 국제화를 위한 모범 사례의 모범 사례 3: 번역 가능한 속성 값 피하기
사용자가 읽을 수 있는 콘텐츠를 포함하는 속성 값을 정의하는 경우, 요소에 포함된 텍스트와 별도로 해당 텍스트의 방향 및 언어 정보를 나타내는 방법을 제공하십시오.
작성자가 span과 유사한 요소
또는 구성을 사용하여 임의의 인라인 콘텐츠에 주석을 달 수 있는 방법을 제공하십시오.
XML 국제화를 위한 모범 사례의 모범 사례 14: span과 유사한 요소 정의하기
국제화에 필요한 정보를 적용하기 위해 모든 텍스트 콘텐츠에 사용할 수 있는 span과 유사한 요소를 제공하십시오.
국제화 정보에는 언어 및 기본 방향 메타데이터, 인라인 언어 변경, 양방향 텍스트 동작 변경, 번역 플래그 등이 포함될 수 있습니다.
월드 와이드 웹 문자 모델: 문자열 일치 [CHARMOD-NORM]의 2절. 문자열 일치 문제에서는 다음과 같이 설명합니다.
웹은 주로 문자 데이터를 기반으로 하는 문서 형식과 프로토콜로 구성됩니다. 이러한 형식이나 프로토콜은 주로 특정 형태의 구조적 마크업 또는 구문 콘텐츠를 포함하는 텍스트 파일로 이루어진 리소스 집합으로 볼 수 있습니다. 이러한 구문 콘텐츠나 문서 데이터를 처리하려면 일치(정규 표현식 포함), 인덱싱, 검색, 정렬 등의 문자열 기반 작업이 필요합니다.
사용자, 특히 구현자는 유사한 문자열이 일치하거나 일치하지 않는 방식 또는 텍스트, 특히 구문 콘텐츠에 적용할 수 있는 여러 변환의 효과에 대해 순진한 기대를 하는 경우가 있으며, 이는 웹의 여러 유형의 텍스트 처리에도 해당합니다.
웹은 문서에서 텍스트를 표현할 수 있는 서로 다른 방식에 민감하므로 동일한 텍스트를 표현할 수 있는 여러 방식을 고려하지 않으면 사용자를 혼란스럽게 하거나 예상하지 못한 결과 또는 불편한 결과를 일으킬 수 있습니다.
구문 콘텐츠는 이렇게 정의된 형식의 전체 텍스트 콘텐츠를 나타냅니다. 형식 문법의 여러 토큰(예: 식별자)을 어휘라고 합니다.
일반적으로 어휘의 "예약 키워드"는 애플리케이션 내부 식별자로 간주됩니다. 즉, 선택된 값이 대개 영어로 일부 의미를 전달하더라도 프로그램 내부용이며 최종 사용자에게 표시하기 위한 값이 아닙니다.
명세는 콘텐츠 작성자가 변수 이름이나 여러 종류의 ID를 포함하되 이에 국한되지 않는 값을 설정하도록 허용할 수도 있습니다.
상호 운용성을 높이려면 구현이 정의한 구문 콘텐츠의 서로 다른 부분을 안정적이고 일관되게 일치시킬 수 있어야 합니다.
제한이 컨텍스트에서 명백한 경우를 제외하고, 콘텐츠에 대한 제한, 특히 허용되는 코드 포인트 범위에 대한 제한을 문서화해야 합니다.
모든 문서 형식이나 프로토콜은 유니코드 문자열로 구성되며 유니코드 데이터를 전송할 수 있어야 한다는 전제에서 시작하십시오. 속성 때문에 처리가 "복잡해" 보이는 문자는 여러 언어에서 필수적인 요소입니다. 유효한 문자 범위에 제한을 두면 국제 사용자의 사용성을 의도치 않게 저해할 수 있으며, 특히 모국어가 라틴 문자를 사용하지 않는 사용자에게 그러합니다. 반드시 필요한 경우가 아니라면 국제 데이터를 전송, 처리 및 교환하는 능력을 저해하거나 금지하지 마십시오.
명세에서 콘텐츠를 제한하는 이유는 많습니다. 중요한 것은 명세 작성자가 콘텐츠에 이러한 제한을 두기로 한 결정의 영향을 고려하고 구현자를 위해 제한을 문서화하는 것입니다.
제한이 상위 명세에 문서화되어 있는 경우 콘텐츠 제한은 컨텍스트에서 명백합니다. 예를 들어 HTTP 헤더를 정의하는 경우 헤더의 이름이 특정 ASCII 하위 집합으로 제한된다는 점은 암시됩니다. 이 제한은 HTTP 헤더의 값에는 적용되지 않습니다.
명세 작성자가 사용하는 일반적인 전략은 어휘 또는 애플리케이션 내부 식별자나 로컬에서 정의한 네임스페이스 같은 어휘의 하위 집합을 신중하게 선택한 ASCII 문자 집합으로 제한하는 것입니다. 값이 임의의 데이터를 전송하기 위한 것이 아니라면 식별자, 예약 키워드 및 값을 ASCII로 제한하면 유니코드 문자열의 입력, 표시 및 특히 비교에 내재된 기술적 어려움을 피할 수 있습니다.
인쇄 가능한 ASCII 하위 집합은
C0 제어 문자(U+0000부터 U+001F까지 포함)와
U+007F DEL을 제외한 유니코드
기본 라틴 코드 포인트의 모든 하위 집합입니다.
특정 하위 집합은 명세나 애플리케이션의 로컬 요구사항에 따라 달라집니다. 대부분의 하위
집합에는 모든 ASCII 영숫자
문자가
포함됩니다. 허용되는 구두점 범위 및 U+0020 SPACE 문자의 포함 여부는 구문, 이스케이프 또는
구분자로 해당 문자를 사용하는 것 같은 로컬 요구사항에 따라 달라집니다.
문서 작성자가 선택하거나 데이터에서 파생되는 식별자 또는 데이터 값은 흔히 다른 언어를 지원해야 합니다. 허용되는 문자 집합을 ASCII로 제한하면 특히 라틴 문자를 사용하지 않는 언어의 사용자나 ASCII 범위 밖의 문자를 사용하는 애플리케이션의 국제적 사용성을 저해할 수 있습니다. 식별자 같은 값이 사용자 데이터에서 생성되거나 강한 기억 보조 가치를 지닌 방식으로 외부에서 참조될 수 있는 경우 특히 그렇습니다. 예를 들어 CSS는 예약 키워드의 어휘를 인쇄 가능한 ASCII 하위 집합으로 제한하지만 클래스 이름에는 광범위한 유니코드 코드 포인트를 사용할 수 있도록 허용합니다.
이름 선택 지침은 8.3.2 애플리케이션 내부 데이터 값 정의하기를 참조하십시오.
결합 부호와 특정 다른 문자(예: 결합 문자 또는 양방향 서식 문자)를 처리하면 주어진 문서 형식을 파싱할 때 문제가 발생할 수 있습니다. 각 식별자를 "토큰화"(주변 텍스트와 분리)하는 방식에 특별히 주의를 기울여야 합니다. 이를 수행하는 한 가지 방법은 일반적인 텍스트 처리가 나중에 식별자를 일치시키는 작업을 방해하지 않도록 식별자를 시작할 수 있는 문자 범위를 제한하는 것입니다.
유니코드 식별자 및 패턴 구문 [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 처리는 식별자와 토큰을 파싱할 때 주어진 문자가 결합 부호인지 여부 같은 유니코드 문자 속성을 고려하지 않도록 정의되어 있습니다. 따라서 식별자가 결합 문자로 시작하더라도 안정적으로 처리할 수 있지만, 일반 텍스트 편집기는 값을 동일하게 처리하지 않을 수 있습니다.
공백 처리와 관련하여 식별자를 정의할 때 주의하십시오. ASCII 문자 U+0020 SPACE와 U+0009 TAB
이외에도 유니코드
가로 공백 문자가 있다는 점에 유의하십시오.
필드와 값에는 로캘 및 문화에 중립적인 이름을 선택하십시오.
필드 이름과 값을 포함한 식별자를 정의할 때 가능한 한 문화에 중립적인 이름을 선택하십시오.
예를 들어 미국에 특화된 ZIPCode보다 postalCode를 사용하고,
문화적 연관성이 더 강한 firstName/lastName보다
givenName/familyName을 사용하십시오.
명세는 형식이 대소문자를 구분할지 구분하지 않을지
결정해야 합니다. 예를 들어 green 값이 GREEN 또는
GrEeN 값과 일치하는지를 결정해야 합니다.
이 절에서는 대소문자 구분
과
대소문자 비구분
이라는 용어가 쉽게 혼동될 수 있으므로 여기에
표시된 것처럼 추가 강조와 함께 나타납니다.
ASCII 대소문자 비구분 [INFRA]을 사용하여 인쇄 가능한 ASCII 하위 집합으로 제한된 값의 대소문자 비구분 일치를 지정하십시오.
비ASCII 문자가 허용되는 경우 식별자는 항상 대소문자를 구분하도록 만드십시오. 콘텐츠가 인쇄 가능한 ASCII 하위 집합으로 제한된 경우에만 비교를 대소문자 비구분으로 만드십시오. 비ASCII 문자열을 대소문자 비구분 방식으로 비교하려면 정규화 및 언어 민감도를 포함하여 월드 와이드 웹 문자 모델: 문자열 일치 [CHARMOD-NORM]에 문서화된 수많은 문제를 처리해야 합니다.
일부 명세는 문서 형식이나 프로토콜에 있는 특정 필드의 값을 정의해야 합니다. 데이터 값이 숫자나 날짜 같은 특정 유형과 연결된 경우 필드 형식은 일반적으로 [XMLSCHEMA11-2] 또는 [JSON-SCHEMA] 같은 잘 알려진 스키마를 사용하여 정의됩니다.
기계가 읽도록 만들어진 현지화할 수 없는 문자열 데이터 값을 정의하는 명세는 자연어 텍스트와 쉽게 혼동되지 않는 값을 사용해야 합니다.
여러 프로토콜, 문서 형식 또는 데이터 구조는 내부에서 사용할 열거 값을 정의합니다. 이러한 값은 사람이 직접 보도록 만들어진 것이 아닙니다. 명세, 프로토콜 또는 API로 작업하거나 특정 문서 또는 상호 작용을 디버깅해야 하는 사용자를 돕기 위해 이러한 값에 설명적인 이름(흔히 영어)을 부여하는 것이 유용한 경우가 있습니다. 명세에서 이러한 값을 할당할 때 사용자가 값을 자연어 텍스트처럼 표시할 수 있다고 생각하지 않도록 선택한 이름이 "코드와 유사하게" 보여야 합니다.
서로 다른 그룹에서는 애플리케이션 내부 값이 "코드와 유사하게" 보이도록 여러 스타일을 채택했습니다. 명세에 가장 적합한 스타일을 선택하십시오. 여기에는 다음이 포함됩니다.
U+005F LOW LINE)로 구분합니다.사람이 읽을 수 있는 문자열, 특히 설명적인 성격의 문자열을 포함하는 필드는 자연어 문자열로 간주해야 합니다. 문자열을 보는 사용자가 소프트웨어 개발자일 것으로 예상되는 경우에도 마찬가지입니다. 문서나 데이터 구조의 이러한 각 필드에서 언어 태그와 문자열 방향을 확인할 수 있어야 합니다.
이 유형의 일반적인 필드 이름에는 name, description,
title, message 또는 때때로 value가
포함됩니다. 이를 판단하는 한 가지 방법은 명세 작성자나 사용자로서 필드 콘텐츠를
SNAKE_CASE_SHOUTED로 만드는 것이 불편하다면 해당 필드를 자연어 텍스트로
간주하는 것이 더 적절할 수 있다는 것입니다.
사람이 사용하도록 만들어진 필드는 현지화할 수 있어야 합니다.
이는 여러 형태를 취할 수 있습니다. 예를 들어 명세나 프로토콜은 언어 협상을 허용하고 가장 잘 일치하는 현지화된 문자열만 반환할 수 있습니다. 또는 특정 리소스에는 소비자가 선택할 수 있는 여러 언어가 포함될 수 있습니다.
필드 이름과 기타 열거 값은 현지화 가능한 표시 이름으로 감싸야 합니다.
필드 이름과 열거 값은 이름이 일반 텍스트처럼 보이고 사용자가 이해할 수 있더라도 자연어 텍스트가 아닙니다. 이러한 필드와 값에는 언어나 방향 메타데이터를 연결해서는 안 되며, 필요한 경우 명세는 구현자가 적절한 현지화 래퍼를 제공하도록 안내해야 합니다.
이 목록에는 이 절의 요구사항만 포함되어 있으며 자체 검토에 사용할 수 있습니다. 명세와 관련된 모든 요구사항에 대해 해당 줄의 첫 번째 체크박스를 선택하십시오. 명세가 요구사항을 충족하면 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
세로 텍스트
before 및 after 줄 위치에 의존해서는 안 됩니다. 자세히vertical- 값과 동등한 세로 쓰기 모드에만
[UTR50]을 사용하여 문자의
기본 텍스트 방향을 적용해야 합니다. 이는 CSS의 sideways-와 동등한 쓰기 모드에는
적용되지 않습니다.
자세히
sideways-lr 및 sideways-rl 같은 값을 제공해야 합니다. 이러한 경우에는
UTR50이 적용되지 않습니다. 자세히
RTL/양방향 텍스트
텍스트 방향이 달라질 때 상자 위치 지정 좌표 설정하기
논리적 속성(TBD)
필기체 텍스트
루비 텍스트 주석
rb rb rt rt에 가까운 시퀀스로 배열할 수 있어야
합니다.
자세히
rb 요소처럼 루비 기본 텍스트에 명시적 요소를
사용할 수 있도록 해야 합니다. 자세히글꼴 관리(TBD)
밑줄과 윗줄 같은 텍스트 장식은 선이 글리프를 피할 수 있어야 합니다.
윗줄과 밑줄이 텍스트에서 떨어진 거리를 지정할 수 있어야 합니다.
아랍어처럼 밑줄을 글리프에서 피하는 대신 기준선에서 더 멀리 이동하는 방식을 선호하는 일부 문자에서는 밑줄 같은 텍스트 장식이 글리프를 피하도록 하는 것이 적절하지 않을 수 있습니다.
일본어, 중국어, 한국어, 몽골어 등의 언어에서 텍스트를 세로로 렌더링할 수 있어야 합니다.
세로 텍스트는 LTR(예: 몽골어)과 RTL(예: 일본어) 방향의 줄 진행을 지원해야 합니다.
기본적으로 줄이 왼쪽에서 오른쪽으로 쌓이는 세로 텍스트(예: 몽골어)의
텍스트 장식, 루비 등은 CJK 세로 텍스트와 동일한 쪽에 표시되어야 합니다. 배치는
before 및 after 줄 위치에
의존해서는 안 됩니다.
CSS의 vertical- 값과 동등한
세로 쓰기 모드에만 [UTR50]을 사용하여 문자의 기본
텍스트 방향을 적용해야 합니다. 이는 CSS의 sideways-와 동등한 쓰기 모드에는 적용되지 않습니다.
쓰기 모드는 가로 문자 텍스트 줄을 세로로 회전할 수 있도록 CSS의
sideways-lr 및 sideways-rl 같은 값을 제공해야 합니다. 이러한 경우에는 UTR50이
적용되지 않습니다.
기본적으로 일반적으로 가로로 쓰는 문자의 글리프는 문자의 위쪽이 세로줄의 오른쪽을 향하도록 세로 텍스트의 줄을 따라 배치되어야 하지만, 세운 방향으로 줄 아래쪽을 따라 진행하도록 허용하는 메커니즘도 있어야 합니다. 이러한 메커니즘은 시각적 텍스트 단위(예: 자소 클러스터)를 최소 텍스트 단위로 사용해야 하지만, 필요한 경우 둘 이상의 자소 클러스터가 포함된 음절 클러스터를 하나의 단위로 취급할 수 있어야 합니다.
세로줄에서 똑바로 세운 아랍어 텍스트는 분리형 글자 형태를 사용해야 하며 텍스트 순서는 위에서 아래로 읽혀야 합니다.
일부 문자 시퀀스, 특히 숫자를 세로줄 안에서 가로로 배치할 수 있어야 합니다(세로쓰기 가로조판).
글자 모양을 기울일 수 있도록 하는 명세는 특정 언어의 필요에 따라 문자를 오른쪽이나 왼쪽으로 기울일 수 있도록 제공해야 합니다.
상자 위치 지정 좌표는 텍스트가 가로인지 세로인지를 고려해야 합니다.
사용자 인터페이스나 웹 페이지를 현지화할 때 RTL 버전과 LTR 버전을 서로 거울상으로 만드는
것이 일반적입니다. 예를 들어 영어 콘텐츠를 포함하는 창의 왼쪽 근처에 나타나는 상자는 콘텐츠가
아랍어나 히브리어인 경우 창의 오른쪽 근처에 나타날 가능성이 높습니다. 절대적 기하 구조를
사용해야 할 강한 이유가 없다면 현재 컨텍스트의 기본 방향을 바탕으로 이러한 변경이 자동으로
이루어지는 것이 바람직합니다. 이를 구현하는 한 가지 방법은 위치를 나타낼 때 left 및 right 대신 start 및 end 같은 키워드를 사용하는 것입니다.
아랍어, 몽골어 및 응코어와 같은 필기체 텍스트에서 연결된 글자에 투명도를 적용할 때 겹치는 부분이 드러나서는 안 됩니다.
텍스트 외곽선이나 그림자를 추가할 때 필기체 텍스트의 연결된 글자가 인접한 글자와 분리되어서는 안 됩니다.
가로 및 세로 쓰기 모드 모두에서 중국어, 일본어, 한국어 및 몽골어 텍스트의 기본 텍스트 옆에 '루비' 형식 주석을 지원해야 합니다.
루비 구현은 번체 중국어를 위한 주음부호(보포모포) 루비를 지원해야 합니다.
루비 구현은 표 형식 콘텐츠 모델을 지원해야 합니다. 즉, 루비 콘텐츠를
rb rb rt rt에 가까운 시퀀스로 배열할 수 있어야
합니다.
루비 구현은 HTML의 rb 요소처럼 루비 기본 텍스트에 명시적 요소를 사용할
수 있도록
해야 합니다.
루비 구현은 주석이 기본 텍스트의 한쪽 또는 양쪽에 표시될 수 있도록 해야 합니다.
HTML의 루비 마크업은 중국어, 일본어, 한국어 및 몽골어 요구사항을 위해 특별히 설계되었으며 일반적인 주석 메커니즘으로 사용해서는 안 됩니다.
줄 높이는 영어 문자보다 높은 문자를 수용할 수 있어야 합니다.
상자 크기는 번역 시 텍스트가 확장되는 것을 수용할 수 있어야 합니다.
줄 바꿈은 비라틴 문자에 필요한 특별 규칙을 고려해야 합니다.
여러 비라틴 문자 체계에서는 단순히 단어 사이의 공백에서 텍스트를 줄 바꿈하지 않습니다. 준수해야 하는 추가 규칙이 있습니다. 예를 들면 다음과 같습니다.
추가 배경 정보는 CSS 텍스트 레벨 3 명세를 참조하십시오. 필요한 경우 이 튜토리얼에서 추가 예제를 확인할 수 있습니다.
표현용 마크업인 b, i 또는 u는 문자 체계 간에
상호 운용되지 않으며 현지화에 불필요한 문제를 일으킬 수 있으므로 사용하지 않는 것이
좋습니다. 또한 일부 문자 체계에는 굵게 표시, 기울임꼴 등과 관련이 없고 매우 다른 강조
방식이 고유하게 존재합니다.
HTML의 경우에는 레거시 문제가 있었지만 명세에 그러한 문제가 없다면 스타일을 사용하여 텍스트 표현을 결정하고 모든 마크업이나 태그는 일반적인 의미론적 접근 방식을 허용하도록 하는 것이 권장됩니다.
b 및 i 태그와 관련된 문제에 대한 설명은 <b> 및
<i> 요소 사용하기를 참조하십시오.
이 목록에는 이 절의 요구사항만 포함되어 있으며 자체 검토에 사용할 수 있습니다. 명세와 관련된 모든 요구사항에 대해 해당 줄의 첫 번째 체크박스를 선택하십시오. 명세가 요구사항을 충족하면 두 번째 체크박스를 선택하십시오. 그런 다음 "GitHub용 마크다운 만들기" 버튼을 클릭하고 결과를 GitHub 이슈 목록에 복사하십시오. 자세한 내용을 참조하십시오.
로캘의 영향을 받는 값 사용하기
시간 사용하기
개인 이름 사용하기
숫자 사용하기
양식 설계하기
사용자 입력(TBD)
예제 만들기(TBD)
현지화
언어와 문화적 기본 설정을 지원하는 소프트웨어 시스템을 국제화되었다
고 합니다.
국제화된 시스템은 사용자 기본 설정을 바탕으로 언어 또는 문화별 처리를 제공하기 위해 API를
사용합니다. 이러한 사용자 기본 설정을 일반적으로 로캘
이라고 합니다. 일반적인
국제화 용어에 대한 자세한 내용은 언어 태그와 로캘 식별자
[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"
}
…달력 및 날짜 체계를 정의할 때 서력기원 이전의 날짜를 허용하거나 적어도 가장 일반적인 범위 밖의 날짜를 처리하는 방법을 정의하십시오.
시간 또는 날짜 데이터 유형을 정의할 때 시간대 또는 UTC와의 관계가 항상 정의되도록 하십시오.
날짜와 시간 데이터 유형에서 윤초를 허용하십시오.
윤초는 분의 초 값 범위가 0부터 60까지 허용될 때 가끔 발생합니다. 즉, 해당 분에는 61초가 있습니다.
날짜와 시간 값을 설명할 때 일관된 용어를 사용하십시오. 시간대와 독립적인 값에는 '부동' 시간을 사용하십시오.
시간대의 정의와 시간대 오프셋을 구분하십시오.
시간대를 식별하려면 IANA 시간대 ID를 사용하십시오. 오프셋이나 LTO를 시간대 대신 사용하지 마십시오.
시간대를 식별하려면 별도의 필드를 사용하십시오.
"주"에 대한 규칙을 정의할 때 문화별 규칙을 적용할 수 있도록 하십시오.
예를 들어 주말이 항상 토요일과 일요일인 것은 아니며 한 주의 첫날도 항상 일요일이나 월요일인 것은 아닙니다.
연중 주 번호에 대한 규칙을 정의할 때 문화별 규칙을 적용할 수 있도록 하십시오.
그레고리력 이외의 달력을 허용하는 경우 "월" 필드가 13(undecimber)까지 갈 수 있다는 점에 유의하십시오.
개인 이름을 사용하는 애플리케이션을 웹 양식, 데이터베이스, 온톨로지 등으로 만드는 개발자는 다른 나라에서 이름이 얼마나 다를 수 있는지 모르는 경우가 많습니다. 외국 사용자의 이름에 지나치게 많은 가정을 적용하여 양식이나 데이터베이스를 구축합니다. 이 절에서는 전 세계의 개인 이름을 처리하기 위한 지침을 제공합니다.
이름과 성을 별도로 저장하거나 접근해야 하는지 실제로 필요한지 확인하십시오.
전 세계의 개인 이름의 분리할 것인가, 분리하지 않을 것인가?
전 세계의 개인 이름의 차이점의 예.
전 세계의 이름은 구성과 구성 요소의 순서가 크게 다릅니다. 전 세계의 개인 이름을 참조하십시오. 예를 들어 사람의 이름을 데이터베이스에 저장하기 위해 더 작은 부분으로 나눈 다음 나중에 다시 가져오려고 하면 특히 이름을 재구성해야 하는 경우 어려움이 발생할 수 있습니다. 이러한 어려움에는 사람 이름의 어떤 부분이 어떤 데이터베이스 필드에 속하는지 이해하는 문제, 특히 이름 부분 수가 데이터베이스 필드보다 많거나 적은 경우와 실제 사용을 위해 데이터베이스에서 이름을 가져올 때 이름 부분의 순서를 처리하는 문제가 포함됩니다.
다양한 배경의 사람 이름을 받는 양식이나 데이터베이스를 설계한다면 개인 이름과 가족 이름 같은 항목에 별도 필드가 정말 필요한지 자문해야 합니다. 이는 데이터를 어떻게 사용해야 하는지에 따라 달라지지만 가능한 경우 사용자가 제공한 전체 이름을 그대로 사용하는 것이 더 간단합니다.
이름 길이에 제한을 두지 마십시오. 제한해야 한다면 긴 문자열을 수용하십시오.
전 세계의 개인 이름의 분리할 것인가, 분리하지 않을 것인가?
전 세계의 개인 이름의 차이점의 예.
일부 문화권의 이름은 자신의 이름보다 훨씬 길 수 있다는 점에 유의하십시오. 긴 이름을 입력할 수 있도록 필드를 충분히 길게 만드십시오. 또한 이름이 두 글자 이상일 것이라고 가정하지 마십시오.
특히 길이를 바이트 단위로 계산하지 마십시오. 4.2 '문자열' 정의 선택하기를 참조하십시오. UTF-8의 네 글자 일본어 이름이 4바이트 안에 들어갈 것이라고 가정하지 마십시오. 실제로는 12바이트가 필요할 가능성이 높습니다.
이 절의 지침은 저장이나 표시를 위해 사람의 이름을 분리해야 한다고 결정한 경우에 적용됩니다.
'이름'과 '성'을 순서를 나타내는 표현으로 표시하지 마십시오. '개인 이름' 및 '가족 이름' 같은 대안을 고려하십시오.
전 세계의 개인 이름의 이름을 분리하는 전략.
전 세계의 개인 이름의 차이점의 예.
'첫 번째'와 '마지막'이라는 용어는 일반적으로 가족 이름 다음에 개인 이름을 쓰는 사람에게 혼란을 줄 수 있습니다. 미국 사용자를 대상으로 하는 양식에서는 이러한 용어를 사용할 수 있다고 생각할 수 있지만 양식은 결국 미국 안팎에서 다른 문화적 배경을 가진 사람이 사용할 수 있습니다.
또한 아이슬란드 사람처럼 실제로 가족 이름이 없고 개인 이름과 부칭을 사용하는 일부 문화에서는 여전히 문제가 된다는 점에 유의하십시오. 개인 이름과 부칭을 참조하십시오. 그러나 고도로 현지화된 맞춤화가 아니라면 이는 일반적인 해결책으로 할 수 있는 최선일 수 있습니다.
전체 이름 필드 외에도 특정 용도에 필요한 이름의 일부를 사용자가 제공할 수 있는 추가 필드를 하나 이상 두는 것이 적절한지 고려하십시오.
전 세계의 개인 이름의 이름을 분리하는 전략.
전 세계의 개인 이름의 차이점의 예.
누군가 연락할 때 어떻게 불리기를 원하는지 사용자에게 별도로 물을 수 있도록 하십시오.
전 세계의 개인 이름의 이름을 분리하는 전략.
전 세계의 개인 이름의 차이점의 예.
예를 들어 이름 목록을 알파벳순으로 정렬하거나 연락할 때 부르기 위해 이름의 일부를 식별해야 할 수 있습니다.
이 추가 필드는 긴 이름 구성 요소 목록에서 적절한 이름을 찾고 별명을 처리하는 데도 유용합니다. 예를 들어 태국에서는 사람을 부를 때 별명을 흔히 사용합니다.
사람을 직접 부르거나 지칭하기 위해 이름의 일부를 사용하려는 경우 별도 필드를 선택할 수도 있습니다. 예를 들어 소셜 미디어 앱에서 "David의 연락처"라고 표시하거나 상단에 이름이 포함된 이메일을 보내려는 경우입니다. 여기서는 이름 구문으로 인한 문제뿐 아니라 격식에 관한 전 세계의 서로 다른 기대도 고려해야 합니다. 낯선 사람이 개인 이름으로 부르는 것을 모두가 좋아하는 것은 아닙니다. 예를 들어 프로필을 설정할 때 그 사람을 어떻게 부르기를 원하는지 별도로 묻는 것이 더 적절할 수 있습니다.
사람의 이름 일부를 별도로 수집하는 경우 각 항목에 관련된 모든 정보를 담을 수 있도록 하십시오.
전 세계의 개인 이름의 이름을 분리하는 전략.
전 세계의 개인 이름의 차이점의 예.
예를 들어 사용자가 이름을 제공하는 순서가 '개인 이름' 다음 '가족 이름'일 것이라고 가정하지 마십시오. 여러 단어로 구성된 이름에서 어떤 부분이 이러한 범주에 들어가고 어떤 부분이 아버지의 이름, 마을 이름, 씨족 이름 등 완전히 다른 것과 관련되는지조차 식별하기 어려울 수 있습니다.
예를 들어 암시된 “n” 최적화를 사용하는 v-card와 h-card 방식은 중국어 이름에서 어려움을 겪을 수 있습니다. 입력 양식은 필요한 데이터를 수집할 수 있도록 사용자에게 이름을 지정하는 방법을 최대한 명확하게 설명해야 합니다.
실제로 한 글자로 된 이름을 가진 사람이 있습니다. 양식 유효성 검사기가 이름 입력을 거부하고 전체 이름을 입력하라고 요구하면 이러한 사람에게 문제가 발생할 수 있습니다. 사람들이 이니셜을 사용하지 않도록 권장하려면 양식 제출을 차단하는 대신 경고 메시지로 표시하는 것이 좋습니다.
인도 남부 일부, 말레이시아 및 인도네시아 같은 문화권에는 부칭 없이 개인 이름만으로 구성된 이름을 가진 사람이 많습니다. 가족 이름을 요구하면 사용자가 양식을 통과하기 위해 가족 이름 필드에 "." 또는 "Mr." 같은 무의미한 데이터를 입력하는 등 이러한 문화권에서 상당한 문제가 발생할 수 있습니다.
사용자가 이름에 하이픈, 아포스트로피 등의 구두점을 사용할 수 있도록 하고 해당 문자에 가능한 대체 코드 포인트를 고려하십시오.
전 세계의 개인 이름의 기타 사항.
전 세계의 개인 이름의 차이점의 예.
이를 통해 Dina Asher-Smith 및 Christopher O'Connell 같은 사람의 이름을 올바르게
처리할 수 있습니다. 아포스트로피는 'U+0027 APOSTROPHE,
ʼU+02BC MODIFIER LETTER APOSTROPHE 또는
’U+2019 RIGHT SINGLE QUOTATION MARK로 나타날 수 있습니다.
하이픈은 -U+002D HYPHEN-MINUS, ‐U+2010 HYPHEN 또는 일본에서 ゠U+30A0 KATAKANA-HIRAGANA DOUBLE HYPHEN을 사용하여
표현할 수 있습니다.
'McNamara' 같은 일부 이름에는 첫 글자가 아닌 곳에 대문자가 포함되며 'van der Waals' 같은 다른 이름에는 대문자로 시작하지 않는 단어가 포함됩니다. 양식은 사용자가 입력한 대소문자를 유지해야 하며 이러한 이름의 각 단어 첫 글자에 항상 대문자만 사용하도록 강제해서는 안 됩니다.
이를 통해 Gabriel García Márquez의 가족 이름인 García Márquez나 José María Olazábal의 개인 이름인 José María를 올바르게 수집할 수 있습니다. 후자의 가족 이름은 Olazábal입니다.
같은 가족의 구성원이 동일한 가족 이름을 공유한다고 가정하는 것은 잘못된 일입니다. 서구에서는 결혼 후에도 자신의 이름을 유지하는 사람이 증가하고 있으며 중국처럼 이것이 일반적인 방식인 문화도 있습니다. 일부 국가에서는 아내가 남편의 이름을 따를 수도 있고 따르지 않을 수도 있습니다.
히스패닉 이름의 경우 가족 중 자녀만 동일한 가족 이름을 가지며 부모와는 다를 수 있습니다. Manuel Pérez Quiñones의 아펠리도(Pérez Quiñones)는 아버지의 아펠리도가 Pérez Rodríguez이고 어머니의 아펠리도가 Quiñones Alamo였기 때문에 만들어졌습니다. 이후 그는 아펠리도가 Padilla Falto인 여성과 교제했습니다. 결혼 후 그녀의 아펠리도는 Padilla de Pérez가 되었습니다. 그들의 자녀는 Pérez Padilla라고 불렸으며 이러한 방식이 이어집니다.
양식에서는 '결혼 전 성'이나 'née'보다 '이전 이름'을 묻는 것이 더 적절할 수 있습니다.
전 세계의 개인 이름의 기타 사항.
전 세계의 개인 이름의 차이점의 예.
이름 채택이 남편에서 아내로만 이루어진다고 단순히 가정해서도 안 됩니다. 때로는 남성이 결혼하면서 아내의 이름을 사용합니다. 이러한 경우 양식에서 '결혼 전 성'이나 'née'보다 '이전 이름'이라고 표시하는 것이 더 적절할 수 있습니다.
이름을 라틴 문자와 고유 문자로 모두 저장해야 할 수 있습니다. 이 경우 사용자에게 고유 문자 형식과 라틴 문자 전용 형식의 이름을 별도 항목으로 제출하도록 요청해야 합니다.
전 세계의 개인 이름의 문자 지원에 대한 영향.
전 세계의 개인 이름의 차이점의 예.
여러 필드가 필요한지는 사람의 이름을 수집하는 목적과 사용 방법에 따라 어느 정도 달라집니다.
예를 들어 일본어 사용자는 표의문자 형식 대신 또는 이에 더하여 일본어 음절 문자로 된 음역을 제공해야 할 수 있습니다. 이 필드는 일본어 이름을 정렬하는 데 사용되며 이름을 보는 사람이 발음을 확인하는 데도 사용됩니다.
실명 사용을 강제할 때 일반적이지 않거나 예상하지 못한 이름을 차단하지 마십시오.
이름이 개발자의 예상과 일치하지 않아 서비스를 사용하지 못한 사람의 예를 찾는 것은 어렵지 않습니다. 실명 사용을 강제하려는 경우 사용자의 이름이 드물거나 예상하지 못한 구조인 경우 실제 이름을 검증할 수 있는 메커니즘을 허용해야 합니다.
사람의 이름이 포함된 예제를 사용하는 표준 및 표준 관련 문서에서는 전 세계 독자를 반영하도록 다양한 이름을 사용하십시오. 특정 지역의 이름에 편중되지 않도록 하십시오.
여러 명세는 이야기의 전달력을 높이기 위해 개인 이름을 사용하는 사용자 스토리나 사용 사례 같은 예제를 제공합니다. 일부 그룹에는 일관성을 어느 정도 제공하기 위해 보안 명세에서 "Alice"와 "Bob"이라는 이름을 사용하는 것 같은 관행도 있습니다. 시스템과 서비스를 구축할 때 포용성은 중요한 목표여야 하므로 예제를 만들 때 전 세계의 다양한 이름을 사용하도록 권장합니다. 이는 기술을 통해 전 세계 사용자 공동체를 표현하도록 보장하고 명세가 전 세계 사용자에게 더 관련성 있게 보이도록 합니다.
유럽에서 유래한 몇 개의 이름만 선택하지 말고 세계 여러 지역의 사람을 나타내는 이름을 선택하십시오. 비ASCII 문자가 포함된 이름을 선택하면 구현자에게 유니코드 지원과 기타 국제화 고려사항이 사용자에게 적용된다는 점을 상기시키는 데 도움이 될 수 있습니다.
어떤 이름 모음도 문화 및 성별 관련 문제를 처리할 때 완전히 중립적일 수 없습니다. 명세 작성자가 더욱 포용적인 예제를 만드는 데 도움이 되도록 이 문서는 여러 문화에서 가져온 이름 모음을 제공합니다. 이러한 이름은 대략 지역별로 구성되며 일반적으로 국가 또는 언어를 나타냅니다. 이러한 지역 안에서도 개인 이름을 처리하는 영향과 관행이 매우 다양하다는 점에 유의하십시오. 많은 이름은 특정 성별에 국한되지 않지만 명세 작성자가 예제를 작성하는 데 도움이 되도록 문화적 성별 연관성에 따라서도 나뉩니다.
영어 예제에 다른 문화권의 개인 이름을 삽입하는 방식은 전 세계에서 이름을 문화적으로 사용하는 방식이 매우 다르다는 점의 영향도 받습니다. 예를 들어 일부 문화에서는 개인 이름 외에 부칭 또는 모칭을 사용하기를 기대하거나 더 격식 있는 이름을 선호합니다. 예를 들어 비격식적인 "Albrecht"보다 "Herr Dürer"를 사용합니다.
중국인은 가족 이름을 함께 포함하지 않고 개인 이름만 사용하는 경우가 거의 없습니다. 중국어로 예제를 작성할 때 "예시 이름" 대신 路人甲 같은 표현을 볼 수 있습니다. 이는 한자의 천간 서수를 사용한 '사람 A'라는 뜻입니다. 미리 정의된 카운터 스타일을 참조하십시오. 이름을 예제에 사용하는 경우 가족 이름과 개인 이름을 모두 포함합니다. 중국어에서는 가족 이름이 개인 이름보다 앞에 온다는 점에 유의하십시오.
일본어에는 격식 수준과 관련된 복잡한 선택이 있습니다. 매우 비격식적인 상황에서는 개인
이름으로 부를 수도 있지만(Hiroshi) 일반적으로는 무례하게 부르는
경우가 아니라면 -san 또는 -sama 같은 호칭이나 접미사가
포함된 가족 이름으로 부릅니다. 예: Tanaka-san. 선배나 매우 존경받는
사람에게는 senpai 또는 sensei, 잘 모르는 사람에게는 shi
같은 다른 접미사나 호칭도 사용합니다. 따라서 영어 예제에서 Hiroki가 ...을
설정하려 한다고 가정합니다.라고 쓸 수 있지만 문화적으로는 Tanaka-san이
...을 설정하려 한다고 가정합니다.라고 쓰는 것이 더 적절할 수 있습니다.
다음 표는 국제화 작업 그룹에서 작성했습니다. 추가 또는 수정에 대한 기여와 제안을 환영합니다.
이 이름 모음의 목적은 일반적으로 영어 사용자를 대상으로 작성하는 명세 작성자를 돕는 것입니다. 이 모음은 주로 개인 이름으로 구성되며 필요한 경우 라틴 문자로 음역됩니다. 이러한 문화권에서 이름을 실제로 사용하는 방식과 다르더라도 이름은 비격식적으로 표시됩니다. 예를 들어 "Ms. Jones" 대신 "Alice"를 사용합니다. 명세를 번역할 때는 대상 독자에게 적합하게 조정해야 합니다.
비라틴 문자를 사용하는 언어나 문화권에서 이름을 가져온 경우 이름이 라틴 문자로 제한되지 않는다는 점을 상기시키고 비라틴 문자 예제를 포함하려는 경우를 위해 비라틴 문자 표현도 제공합니다.
헤더 행의 △ 또는 ▽ 화살표를 클릭하여 이 표를 정렬할 수 있습니다.
| 이름 △▽ | 고유 문자 △▽ | 성별 △▽ | 지역 및 참고 △▽ | 언어 △▽ |
|---|---|---|---|---|
| Akamu | m | 오세아니아; 폴리네시아; 하와이어 이름 | haw | |
| Alinta | f | 오세아니아; 오스트레일리아 원주민 이름 | nys | |
| Amélie | f | 유럽; 프랑스 | fr | |
| An | 杏 | f | 동아시아; 일본 | ja |
| Aoi | 葵; 蒼; 碧 | f, m | 동아시아; 일본 | ja |
| Aroha | f | 오세아니아; 마오리 | mi | |
| Åsa | f | 유럽; 스웨덴 | sv | |
| Asahi | 朝陽 | m | 동아시아; 일본 | ja |
| Atlahua | m | 라틴아메리카; 나와틀어 이름 | nah | |
| Beata | f | 유럽; 여러 국가 | it, de, pl, sv, etc. | |
| Chanda | चंदा | f | 남아시아; 산스크리트어에서 유래 | sa |
| Chirapathi | சிரபதி | f | 남아시아; 타밀어 | ta |
| Citlali | f | 라틴아메리카; 나와틀어 | nah | |
| Coen | m | 유럽; 네덜란드; 오세아니아의 오스트레일리아 원주민 이름 또는 히브리어 이름이기도 함 | nl, he, nys | |
| Daisho | 大翔 | m | 동아시아; 일본 | ja |
| Dara | f | 서아시아; 유럽; 튀르키예 | tr | |
| Eva | Е́ва | f | 유럽; 러시아 | ru |
| Faheem | فهيم | m | 서아시아; 아랍어 | ar |
| Fátima | فَاطِمَة | f | 서아시아; 아랍어; 여러 유럽 문화권에서 라틴 문자로도 사용됨 | ar |
| Genet | ገነት | f | 아프리카; 에티오피아 | am |
| Haruto | 陽翔 | m | 동아시아; 일본 | ja |
| Haukea | f | 오세아니아; 폴리네시아; 하와이어 이름 | haw | |
| Himari | 陽葵 | f | 동아시아; 일본 | ja |
| Hina | 陽菜 | f | 동아시아; 일본 | ja |
| Hīnano | m | 오세아니아; 폴리네시아; 타히티어 | ty | |
| Hua | 李华 | m | 동아시아; 중국 | zh-Hans |
| Iakopo | m | 오세아니아; 사모아 | sm | |
| Ilango | இளங்கோ | m | 남아시아; 타밀어 | ta |
| Irepani | m | 라틴아메리카; 푸레페차어 | tsz | |
| Işık | f | 서아시아; 유럽; 튀르키예 | tr | |
| Işıtan | m | 서아시아; 유럽; 튀르키예 | tr | |
| Itsuki | 樹 | m | 동아시아; 일본 | ja |
| Jarra, Jarrah, Cerrah | جراح | m | 서아시아; 아랍어 | ar, tr |
| Jean-François | m | 유럽; 프랑스어 | fr | |
| João | m | 라틴아메리카; 브라질 | pt-BR | |
| Júlía | f | 유럽; 아이슬란드 | is | |
| Kai | f, m | 오세아니아; 오스트레일리아; 여러 언어에 나타나며 일반적인 예제로 적합함 | aus, sm | |
| Khaliun | f, m | 동아시아; 몽골 | mn | |
| Kylie | f | 오세아니아; 오스트레일리아 원주민 이름 | aus | |
| Lani | f | 오세아니아; 필리핀 | fil | |
| Lei | 李雷 | m | 동아시아; 중국 | zh-Hans |
| Livia | f | 유럽, 라틴아메리카 | es | |
| Lowanna | f | 오세아니아; 오스트레일리아 원주민 | aus | |
| Lucas | m | 라틴아메리카 | es | |
| Maevarau | m | 오세아니아; 사모아 | sm | |
| Mahmut | m | 서아시아; 유럽; 튀르키예 | tr | |
| Martina | f | 라틴아메리카 | es | |
| Mei | 芽依 (ja); 梅
(zh) |
f | 동아시아; 중국; 일본 | ja, zh |
| Minato | 湊 | m | 동아시아; 일본 | ja |
| Mio | 澪 | f | 동아시아; 일본 | ja |
| Miriam | מרים | f | 서아시아; 히브리어 | he |
| Müge | f | 서아시아; 유럽; 튀르키예 | tr | |
| Muhammad | محمد | m | 서아시아; 아랍어; 여러 변형과 언어가 있음 | ar |
| Ngatemi | f | 오세아니아; 인도네시아 | id, ms | |
| Onosaʻi | f | 오세아니아; 사모아 | sm | |
| Potira | f | 라틴아메리카; 브라질; 원주민 이름 | gn | |
| Qiàn | 倩 | f | 동아시아; 중국 | zh-Hans |
| Rattiya | รัตติยา | f | 동남아시아; 태국 | th |
| Ren | 蓮 | m | 동아시아; 일본 | ja |
| Rin | 凛 | f | 동아시아; 일본 | ja |
| Ritthichai | ฤทธิชัย | m | 동남아시아; 태국 | th |
| Santiago | m | 라틴아메리카 | es | |
| Senthil | செந்தில் | m | 남아시아; 타밀어 | ta |
| Sione | m | 오세아니아; 통가 | to | |
| Slobodan | Слободан | m | 유럽; 세르비아어 | sr |
| Sofia | f | 유럽; 라틴아메리카 | es | |
| Tahnee | f | 오세아니아; 오스트레일리아 원주민 | aus | |
| Tamizhachi | தமிழச்சி | f | 남아시아; 타밀어 | ta |
| Temuera | m | 오세아니아; 폴리네시아 | sm | |
| Thị Anh | f | 동남아시아; 베트남 | vi-VN | |
| Tuulikki | f | 유럽; 핀란드 | fi | |
| Uriel | אוּרִיאֵל | m | 서아시아; 히브리어 | he |
| Văn Hoa | m | 동남아시아; 베트남 | vi-VN | |
| Vasa | m | 오세아니아; 사모아; 유럽; Vasilije/Василије의 축약형 | sm, hr, sr | |
| Vassilios | Βασίλειος | m | 유럽; 그리스어 | el |
| Voula | Βούλα | f | 유럽; 그리스어 | el |
| Wafaa | وفاء | f | 서아시아; 아랍어 | ar |
| Wissam | وسام | m | 서아시아; 아랍어 | ar |
| Xiaoxia | 晓霞 | f | 동아시아; 중국 | zh-Hans |
| Xóchitl | f | 라틴아메리카; 나와틀어 | nah | |
| Yevdokia | Евдокия | f | 유럽; 러시아 | ru |
| Yevgeny | Евгений | m | 유럽; 러시아 | ru |
| Zafirah | زفره | f | 서아시아; 아랍어 | ar |
사용자가 입력한 숫자 값을 파싱할 때 숫자 모양 변환(비ASCII 숫자)을 허용하십시오.
표시할 숫자 값을 형식화할 때 비ASCII 숫자 사용(숫자 모양 변환)을 포함하여 문화에 맞는 표시를 허용하십시오.
번호 매기기 목록을 만드는 경우처럼 사용자에게 표시하기 위해 항목에 순차적으로 레이블을 자동 지정하는 기능을 정의할 때는 여러 계산/목록 체계나 스타일뿐 아니라 레이블의 현지화된 표시도 허용하십시오.
이에 대한 예제는 CSS 카운터 스타일 [css-counter-styles-3]과 특히 함께 제공되는 미리 정의된 카운터 스타일 [predefined-counter-styles]에서 찾을 수 있습니다.
이메일 필드 유효성 검사를 정의할 때 EAI(smtputf8) 이름을 허용하십시오.
현지화 [LTLI]를 통해 사용자는 자신이 선택한 언어와 로캘로 소프트웨어를 사용할 수 있습니다. 프로토콜과 문서 형식 명세는 최종 사용자가 기대하는 언어와 형식을 제공하는 방법을 고려해야 합니다.
현지화된 메시지를 제공하지 않더라도 자연어 데이터 값을 올바르게 표시하려면 언어와 기본 방향이 필요합니다. 여기에는 API나 프로토콜에서 사람이 읽을 수 있는 모든 오류 메시지 또는 기타 내부 메시지가 포함됩니다. [STRING-META]도 참조하십시오.
특정 API나 프로토콜에서 정의하는 오류 메시지를 포함한 모든 자연어 필드 또는 메시지는 사용자가 선호하는 로캘로 현지화하거나 해당 언어를 사용할 수 없는 경우 적절한 대체 언어 또는 기본값으로 제공해야 합니다.
명세는 API나 프로토콜의 메시지 또는 오류에 특정 기본 언어를 정의할 수 있습니다.
명세는 가능한 모든 로캘 또는 사용 가능한 모든 로캘로 메시지를 반환하도록 요구할 필요가 없습니다. 최종 사용자의 고객 경험을 현지화할 수 있도록 하는 것으로 충분합니다. 구현은 지원할 언어나 로캘을 선택할 수 있습니다.
프로토콜, API 및 문서 형식은 때때로 서비스에서 호출자에게 사람이 읽을 수 있는 오류나 예외 메시지를 문자열 형식으로 전달하는 필드를 제공합니다. 일반적으로 위에서 설명한 것처럼 사람이 읽을 수 있는 메시지나 콘텐츠를 전달하는 모든 자연어 텍스트에는 언어 및 방향 메타데이터가 연결되어야 합니다. 이 메타데이터가 없으면 텍스트 처리나 표시가 손상될 수 있습니다.
명세 작성자가 오류나 예외 메시지를 제공하는 목적은 소프트웨어 개발자에게 디버깅 정보를 전달하는 것인 경우가 많습니다. 명세 작성자는 때때로 오류나 예외 메시지가 최종 사용자에게 표시되지 않으며 소프트웨어 개발자는 이러한 메시지가 현지화되지 않거나 특정 언어, 일반적으로 영어로 표시되는 것을 선호할 것이라고 가정하거나 오류 메시지 현지화가 장벽이 되는 다른 "실용적인 이유"가 있다고 가정합니다. 예를 들어 오류 메시지 자체가 문제를 충분히 설명하지 못하기 때문에 개발자가 일반적으로 불명확한 오류 텍스트로 웹을 검색하는 것이 더 쉽다는 이야기가 있습니다. 이 텍스트를 검색하면 개발자가 선호하는 언어로 더 유용한 결과가 나올 수 있습니다.
오류 메시지는 메시지이며 기계가 아닌 사람을 위한 것입니다. 여러 경우 오류 메시지는 무엇이 잘못되었는지에 관한 모든 추가 정보를 포함하며 때로는 호출자가 문제를 해결하는 방법을 전달할 다른 방법이 없기 때문에 실제 최종 사용자에게 메시지를 표시해야 합니다. 예: "신용카드가 만료되었습니다.", "값 10484977이 너무 큽니다."(소수점을 빼먹음) 등. 이러한 유형의 메시지를 현지화하는 것은 실제로 바람직하며 일부 애플리케이션에서는 의무일 수도 있습니다.
API와 프로토콜은 오류에 언어와 독립적인 식별자를 제공해야 합니다.
예를 들어 익숙한 404 같은 HTTP 결과 코드는 사용자가 받은 오류를
전달하거나 번역을 조회하는 데 도움이 됩니다.
자연어 오류 메시지 필드를 제공하는 경우 선택 사항이어야 하며 언어 및 방향 메타데이터를 포함해야 합니다.
자연어 오류 메시지 필드를 제공하는 경우 가능하면 요청에 대해 협상된 사용자 인터페이스 언어와 일치해야 합니다.
다음은 이전 발행 이후의 실질적인 변경 사항을 요약한 것이지만, 이 자료는 개발이 진행됨에 따라 여전히 크게 변경될 수 있습니다. 그렇다고 이 문서를 사용하지 않아야 하는 것은 아닙니다. 현재 포함된 내용도 유용하며 부족한 점은 보고하거나 논의할 수 있습니다.
자세한 내용은 GitHub 커밋 기록을 참조하십시오.
권장 사항을 위해 이전 검토 내용을 검토하는 데 도움을 준 Addison Phillips에게 감사드립니다.
검토나 이슈를 통해 기여한 다른 사람은 다음과 같습니다. Steve Atkin, Andrew Cunningham, Martin Dürst, Asmus Freytag, John Klensin, Tomer Mahlin, Chaals McCathieNevile, Florian Rivoal, Najib Tounsi. 로캘에 중립적인 표현에 관한 일부 자료는 [DWBP]에서 수정하여 사용했습니다.
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: