유니코드 및 HTML

Unicode and HTML
HTML
비교

HTML(HyperText Markup Language)을 사용하여 작성된 웹 페이지는 유니코드 범용 문자 집합으로 대표되는 다국어 텍스트를 포함할 수 있다.유니코드와 HTML의 관계의 핵심은 HTML 문서에 존재할 수 있는 문자 집합을 정의하고 그들에게 숫자를 할당하는 "문서 문자 집합"과 주어진 문서를 바이트의 순서로 인코딩하는 데 사용되는 "외부 문자 인코딩" 또는 "charset" 사이의 관계다.

초기 HTML 2.0 표준인 RFC 1866에서 문서 문자 세트는 ISO-8859-1로 정의되었다.RFC 2070에 의해 ISO 10646(기본적으로 유니코드에 해당)까지 확장되었다.언어가 다르거나 플랫폼이 다른 문서마다 다르지 않다.외부 문자 인코딩은 문서 작성자(또는 작성자가 문서를 작성하기 위해 사용하는 소프트웨어)에 의해 선택되며, 문서 문자 집합의 문자로 문서 맵을 저장 및/또는 전송하는 데 사용되는 바이트를 결정한다.선택한 외부 문자 인코딩에 없는 문자는 문자 도면요소 참조로 나타낼 수 있다.

유니코드와 HTML의 관계는 많은 컴퓨터 전문가, 문서 작성자, 웹 사용자 모두에게 어려운 주제인 경향이 있다.다른 자연 언어와 쓰기 시스템에서 웹 페이지에 텍스트를 정확하게 표현하는 것은 문자 인코딩, 마크업 언어 구문, 글꼴, 웹 브라우저별 지원 수준 등의 세부사항으로 인해 복잡하다.

HTML 문서 문자

웹 페이지는 일반적으로 HTML 또는 XHTML 문서들이다.두 가지 유형의 문서는 모두 컴퓨터 저장 시스템과 네트워크에서 나타나는 방식과는 무관하게 기본적인 수준의 문자로 구성된다.

HTML 문서는 유니코드 문자의 배열이다.보다 구체적으로 HTML 4.0 문서는 HTML 문서 문자 집합의 문자들로 구성되어야 한다: 각 문자에서 음이 아닌 고유한 정수 코드 포인트가 할당되는 문자 레퍼토리.이 세트는 HTML 4.0 DTD에 정의되어 있어 유효한 HTML 문서를 생성할 수 있는 구문(문자의 허용 가능한 순서)도 설정한다.HTML 4.0에 대한 HTML 문서 문자 집합은 유니코드와 ISO/IEC 10646: 유니버설 문자 집합(UCS)에서 공동으로 정의한 문자의 대부분(전부는 아니지만)으로 구성된다.

HTML 문서와 마찬가지로 XHTML 문서도 유니코드 문자의 시퀀스다.그러나 XHTML 문서는 XML 문서로, 명시적인 "문서 문자" 추상화 계층은 없지만 그럼에도 불구하고 유니코드/UCS 문자 정의의 대부분(전부는 아님)을 포함하는 허용 문자의 유사한 정의에 의존한다.HTML과 XHTML/XML이 사용하는 세트는 약간 다르지만, 이러한 차이는 일반적인 문서 작성자에게 거의 영향을 미치지 않는다.

문서가 HTML이든 XHTML이든 상관없이 파일 시스템에 저장되거나 네트워크를 통해 전송될 때 문서의 문자는 특정 문자 인코딩에 따라 비트옥텟(바이트)의 시퀀스로 인코딩된다.이 인코딩은 UTF-8과 같이 유니코드 문자를 직접 인코딩할 수 있는 유니코드 변환 포맷이거나, 윈도-1252와 같은 기존 인코딩일 수 있다.그러나 모든 유니코드 문자를 지원하지 않는 인코딩을 사용할 경우에도 인코딩된 문서는 숫자 문자 참조를 사용할 수 있다.예를 들어,☺(iii)는 유니코드 문자 집합에서 웃는 얼굴 문자를 나타내기 위해 사용된다.

문자 부호화

숫자 문자 참조에 의존하지 않고 모든 유니코드 문자를 지원하려면 웹 페이지에 모든 유니코드를 포함하는 인코딩이 있어야 한다.가장 인기 있는 문자는 UTF-8로 영어 문자, 숫자 및 기타 일반적인 문자와 같은 ASCII 문자가 ASCII에 대해 변경되지 않고 보존된다.이는 HTML 코드(예: <br>, </div>)를 ASCII에 비해 변경하지 않게 만든다.ASCII 범위를 벗어난 문자는 2-4바이트로 저장된다.대부분의 문자가 다양한 엔디안성으로 2바이트로 저장되는 UTF-16도 사용할 수 있는데, 현대 브라우저에서는 지원되지만 일반적으로는 덜 사용된다.

숫자 문자 참조

주요 기사:숫자 문자 참조

레거시 인코딩의 한계를 극복하기 위해 HTML은 숫자 문자 참조, 즉 표현 중인 문자의 유니코드 코드 포인트를 명시적으로 철자하는 문자 시퀀스를 이용하여 HTML 문서 내에서 유니코드 전체의 문자를 나타낼 수 있도록 설계되었다.문자 참조가 형식을 취함N;, whereN유니코드 코드 포인트에 대한 소수점 또는 16진수 숫자 중 하나이며, 이 경우 앞에 다음이 붙어야 한다.x숫자 문자 참조를 구성하는 문자는 인터넷에서 사용하도록 승인된 모든 인코딩에서 보편적으로 표현할 수 있다.

이 맥락에서 16진법에 대한 지원은 더 최근의 것이기 때문에 오래된 브라우저는 16진법으로 참조된 문자를 표시하는 데 문제가 있을 수 있지만, 어쨌든 그들은 코드 포인트 255 이상의 유니코드 문자를 표시하는 데 문제가 있을 것이다.이전 브라우저와의 호환성을 높이기 위해 16진수 코드 포인트를 10진수 값으로 변환하는 것이 여전히 일반적인 관행이다(예:&#21512;대신에&#x5408;).

명명된 문자 도면요소

주 기사: 문자 도면요소 참조

HTML 4에서는 특정 문자 인코딩에서 찾을 수 없거나 일부 컨텍스트에서 마크업(예: 꺾쇠괄호 및 따옴표)에 민감한 문자에 대해 252개의 명명된 문자 엔티티로 구성된 표준 집합이 있다.유니코드 문자는 숫자 코드 포인트로 참조할 수 있지만, 일부 HTML 문서 작성자는 암호성이 낮고 초기 브라우저에서 더 잘 지원되었기 때문에 가능한 경우 이러한 명명된 엔티티를 대신 사용하는 것을 선호한다.

문자 도면요소는 도면요소 참조를 사용하여 HTML 문서에 포함될 수 있으며, 이 형식은 다음과 같다.EntityName;, whereEntityName엔티티 이름.예를 들어,&mdash;, 매우 비슷하다.&#8212;또는&#x2014;는 U+2014: 사용된 문자 인코딩에 해당 문자가 포함되어 있지 않더라도 em dash 문자 "-"를 나타낸다.

전체 목록은 XML 및 HTML 문자 도면요소 참조 목록을 참조하십시오.

문자 인코딩 결정

HTML을 올바르게 처리하기 위해서, 웹 브라우저는 어떤 유니코드 문자가 HTML 문서의 인코딩된 형태로 표시되는지 확인해야 한다.이를 위해 웹브라우저는 어떤 인코딩이 사용됐는지 알아야 한다.

인코딩 정보

문서가 MIME 메시지 또는 HTTP 응답과 같은 MIME 내용 유형을 사용하는 전송을 통해 전송되는 경우, 메시지는 다음과 같은 내용 유형 헤더를 통해 인코딩을 신호할 수 있다.Content-Type: text/html; charset=UTF-8. 인코딩을 선언하는 다른 외부 수단은 허용되지만 거의 사용되지 않는다.문서가 유니코드 인코딩을 사용하는 경우, 인코딩 정보는 바이트 순서 표시의 형태로도 존재할 수 있다.마지막으로, 인코딩은 HTML 구문을 통해 선언될 수 있다.를 위해text/html그 다음, 페이지가 ASCII의 확장으로 인코딩되는 한(예: UTF-8, 따라서 페이지가 UTF-16을 사용하고 있지 않다면), ameta원소, like<meta http-equiv="content-type" content="text/html; charset=UTF-8">또는 (HTML5로 시작)<meta charset="UTF-8">사용할 수 있다.XML로 일련화된 HTML 페이지의 경우, 선언 선택사항은 인코딩 기본값(XML 문서의 경우 UTF-8)에 의존하거나 XML 인코딩 선언을 사용하는 것이다.메타 속성은 XML로 사용되는 HTML에서 어떤 역할도 하지 않는다.

기본 인코딩

인코딩 기본값은 외부 또는 내부 인코딩 선언이 없고 바이트 순서 표시가 없을 때 적용된다.XML로 사용되는 HTML 페이지의 인코딩 디폴트는 UTF-8이어야 하지만, 일반 웹 페이지의 인코딩 디폴트(즉: 다음으로 일련화된 HTML 페이지의 경우)는text/html)는 브라우저의 로컬리제이션에 따라 달라진다.주로 서유럽 언어에 대해 설정된 시스템의 경우 일반적으로 윈도-1252가 될 것이다.키릴 문자 로케일의 경우 기본값은 일반적으로 Windows-1251이다.레거시 멀티바이트 문자 인코딩이 성행하는 위치의 브라우저의 경우, 어떤 형태의 자동 검출이 적용될 가능성이 높다.

인코딩 추세

프로그래밍 언어와 운영체제의 8비트 텍스트 표현에 대한 유산과 인코딩의 뉘앙스를 이해해야 하는 필요성으로 인해 HTML 작성자들이 사용하는 많은 텍스트 편집기들은 디스크에 파일을 저장할 때 인코딩 선택권을 제공할 수 없거나 원하지 않으며 종종 c의 입력조차 허용하지 않는다.극히 한정된 범위를 넘는 해프닝결과적으로, 많은 HTML 작성자들은 인코딩 문제를 알지 못하며 그들의 문서가 실제로 어떤 인코딩을 사용하는지 전혀 알지 못할 수 있다.인코딩 선언이 실제 인코딩의 변화(실제로 부정확할 수 있는 라벨일 뿐)에 영향을 미친다는 믿음과 같은 오해도 편집자의 이런 태도에 대한 이유다.같은 방향으로 기여하는 또 다른 요인은 UTF-8의 도착으로, 이는 다른 인코딩의 필요성을 크게 감소시키고 따라서 현대 편집자는 HTML5 규격에서 권장한 대로 [1]UTF-8에 디폴트하는 경향이 있다.

바이트 순서 표시/유니코드 스니핑

HTML(콘텐츠 타입의 "text/html"과 컨텐츠/타입의 "application/xhtml+xml")의 일련화 모두에 대해, 바이트 순서 표시(BOM)는 HTML 문서 내에서 인코딩 정보를 전송하는 효과적인 방법이다.UTF-8의 경우, BOM은 선택 사항이지만 UTF-16과 UTF-32 인코딩의 경우 필수 사항이다.(참고: BOM이 없는 UTF-16과 UTF-32는 서로 다른 이름으로 공식적으로 알려져 있으며, 서로 다른 인코딩이기 때문에 어떤 형태의 인코딩 선언이 필요하다(UTF-16BE, UTF-16LE, UTF-32LE 및 UTF-32BE 참조).BOM 문자(U+FEFF)의 사용은 인코딩이 자동으로 모든 처리 응용프로그램에 자신을 선언한다는 것을 의미한다.애플리케이션 처리 시 초기 0x0000FEFF, 0xFEFF 또는 0xEFB만 검색하면 됨문서를 각각 UTF-32, UTF-16 또는 UTF-8로 식별하기 위한 바이트 스트림의 BBF.바이트 순서 표시는 응용 프로그램 처리에 필요한 모든 정보를 포함하므로 이러한 인코딩에는 추가 메타데이터 메커니즘이 필요하지 않다.대부분의 경우 바이트 순서 마크 문자는 다른 문자와 별도로 애플리케이션을 편집하여 처리하므로 작성자가 잘못된 인코딩을 표시하기 위해 바이트 순서 마크를 제거하거나 변경할 위험이 거의 없다(영어/라틴어로 인코딩을 선언할 때 발생할 수 있음).문서에 바이트 순서 표시가 없는 경우, HTML 문서의 첫 번째 빈칸이 아닌 인쇄 가능한 문자가 "<<> (U+003C)로 되어 있다는 사실은 UTF-8/UTF-16/UTF-32 인코딩을 결정하는 데 사용될 수 있다.

인코딩 재정의 중

많은 HTML 문서는 부정확한 인코딩 정보와 함께 제공되거나 인코딩 정보가 전혀 제공되지 않는다.이러한 경우에 인코딩을 결정하기 위해, 많은 브라우저들은 사용자가 목록에서 인코딩 이름을 수동으로 선택할 수 있도록 한다.또한 그들은 수동 오버라이드에 대해 BOM의 경우 및 XML로 사용되는 HTML과 함께 또는 함께 작동하는 인코딩 자동 감지 알고리즘을 사용할 수 있다.

다음과 같은 HTML 문서의 경우text/html일련화된 수동 재정의가 모든 문서 또는 선언 및/또는 바이트 패턴을 검토하여 인코딩을 확인할 수 없는 문서에만 적용될 수 있다.수동 오버라이드가 존재하고 널리 사용된다는 사실은 웹 상에서 정확한 인코딩 선언의 채택을 방해하기 때문에 문제가 지속될 가능성이 높다.그러나 Internet Explorer, Chrome 및 Safari(XML 및 Xafari용)는 XML 및text/html일련화 — 페이지에 BOM이 포함될 때마다 인코딩을 재정의하지 마십시오.[2]

기본 XML 레이블로 일련화된 HTML 문서의 경우:application/xhtml+xml, 수동 인코딩 재정의는 허용되지 않는다.이러한 XML 문서의 인코딩을 재정의하는 것은 XML 문서가 탐지 가능한 오류가 있는 인코딩 선언을 갖는 것은 치명적인 오류이기 때문에 XML 문서가 XML이 되지 않는 것을 의미한다.현재 Firefox와 같은 Gecko 브라우저는 이 규칙을 따르지만, Webkit 브라우저(Chrome/Safari)와 같이 HTML을 XML로 지원하는 다른 일반적인 브라우저의 대부분은 XHTML 문서의 인코딩을 수동으로 오버라이드할 수 있다.

웹 브라우저 지원

많은 브라우저들은 전체 유니코드 레퍼토리의 작은 부분집합만 표시할 수 있다.브라우저에서 다양한 유니코드 코드 포인트를 표시하는 방법은 다음과 같다.

유니코드 문자에 대한 웹 브라우저 지원 예
캐릭터 HTML 문자 참조 유니코드명 브라우저에 표시되는 내용
U+0041 &#65;또는&#x41; 라틴 대문자 A A
U+00DF &#223;또는&#xDF; 라틴어 작은 글자 샤프 S ß
U+00FE &#254;또는&#xFE; 라틴어 작은 글자 손 þ
U+0394 &#916;또는&#x394; 그리스 대문자 델타 Δ
U+017D &#381;또는&#x17D; 라틴 대문자 Z와 하체크어 Ž
U+0419 &#1049;또는&#x419; 키릴 문자 단축 I Й
U+05E7 &#1511;또는&#x5E7; 히브리 문자 Qof ק
U+0645 &#1605;또는&#x645; 아랍 문자 밈 م
U+0E57 &#3671;또는&#xE57; 태국어 숫자를 매기다 7 ๗
U+1250 &#4688;또는&#x1250; Geez 음절 ቐ
U+3042 &#12354;또는&#x3042; 히라가나 문자 A(일본어) あ
U+53F6 &#21494;또는&#x53F6; CJK 통합 한자-53F6(간체 중국어 "잎") 叶
U+8449 &#33865;또는&#x8449; CJK 통합 한자-8449(중국 전통 "잎") 葉
U+B5AB &#46507;또는&#xB5AB; 한글 음절 Tteolp(한국어 "쌍티컷 어 리을비업") 떫
U+16A0 &#5792;또는&#x16A0; 루니 문자 페후 ᚠ
U+0D37 &#3383;또는&#x0D37; 말라얄람 문자 ഷ (ṣha) ഷ
U+1F602 &#128514;또는&#x1F602; 기쁨의 눈물을 머금은 얼굴 😂
위의 모든 문자를 표시하려면 Code2000과 같은 하나 이상의 다국어 글꼴을 설치해야 할 수 있다.

Mozilla Firefox, Opera, Safari 및 Internet Explorer(버전 7부터)와 같은 일부 웹 브라우저에서는 페이지에 각 개별 문자를 표시할 글꼴을 지능적으로 선택하여 다국어 웹 페이지를 표시할 수 있다.운영 체제에 적절한 글꼴이 있는 한 유니코드 블록의 조합을 올바르게 표시할 것이다.

Netscape Navigator 4.77 및 Internet Explorer 6과 같은 이전 브라우저는 페이지의 문자 인코딩과 관련된 현재 글꼴에서만 지원되는 텍스트만 표시할 수 있으며, 숫자 문자 참조가 유니코드 코드 포인트에 대한 참조가 아니라 현재 문자 인코딩 내의 코드 값에 대한 참조로 잘못 해석될 수 있다.이러한 브라우저를 사용하는 경우 컴퓨터에 이러한 글꼴이 모두 있거나 브라우저가 동일한 페이지에서 사용 가능한 모든 글꼴을 사용할 수 있을 가능성은 낮다.결과적으로, 브라우저는 위의 예제에 있는 텍스트의 일부를 표시할 수 있지만, 텍스트가 올바르게 표시되지 않을 것이다.그러나 표준에 따라 인코딩되기 때문에 준수하고 사용할 수 있는 문자가 있는 모든 시스템에서 올바르게 표시된다.또한 명명된 엔티티 참조에 사용할 수 있도록 이름이 지정된 문자는 다른 문자보다 더 일반적으로 사용할 수 있을 가능성이 높다.

위의 표에 있는 런닉 문자 fehu의 변형인 고딕 문자 faihu와 같은 기본 다국어 평면 외부에 문자를 표시하기 위해 일부 시스템(Windows 2000과 같은)은 설정을 수동으로 조정할 필요가 있다.

사용 빈도

구글 웹지수의 내부 데이터에 따르면 2007년 12월 UTF-8 유니코드 인코딩은 ASCII(미국)와 8859-1/1252(서유럽어)를 모두 제치고 웹페이지에서 가장 많이 사용되는 인코딩이 됐다.[4]

참고 항목

참조

  1. ^ Ian Hickson (2011). "HTML5". Retrieved 17 September 2011. Authors are encouraged to use UTF-8. Conformance checkers may advise authors against using legacy encodings. [RFC3629] Authoring tools should default to using UTF-8 for newly created documents. [RFC3629]
  2. ^ Bug 12897 - 일부 파서에서는 UTF-8 BOM이 HTTP charset 속성을 능가한다(Encoding snipping 알고리즘).
  3. ^ Bug 66189 - XML 파서가 탐지 가능한 모든 인코딩 오류에 대해 치명적 오류를 내보내지 않음
  4. ^ 마크 데이비스:Unicode 5.1 공식 Google 블로그로 이동, 2008년 5월 5일

외부 링크