유니코드와 HTML

HTML로 작성된 웹 페이지는 유니코드 범용 문자 집합으로 표현된 다국어 텍스트를 포함할 수 있다. 유니코드와 HTML의 관계에서 핵심은 HTML 문서에 포함될 수 있는 문자 집합을 정의하고 번호를 할당하는 "문서 문자 집합"과 주어진 문서를 일련의 바이트로 인코딩하는 데 사용되는 "외부 문자 인코딩" 또는 "문자 집합" 간의 관계이다.

RFC 1866의 초기 HTML 2.0 표준에서 문서 문자 집합은 ISO-8859-1로 정의되었다 (이후 HTML 표준은 Windows-1252 인코딩을 기본으로 한다). 이는 2070에 의해 ISO 10646(기본적으로 유니코드와 동등하다)으로 확장되었다. 이는 다른 언어의 문서나 다른 플랫폼에서 생성된 문서 간에 다르지 않다. 외부 문자 인코딩은 문서 작성자(또는 작성자가 문서를 생성하는 데 사용하는 소프트웨어)가 선택하며, 문서 저장 및 전송에 사용되는 바이트가 문서 문자 집합의 문자에 어떻게 매핑되는지 결정한다. 선택된 외부 문자 인코딩에 없는 문자는 문자 엔티티 참조로 표현될 수 있다.

유니코드와 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과 같이 모든 유니코드 문자를 직접 인코딩할 수 있는 유니코드 변환 형식이거나, Windows-1252와 같이 인코딩할 수 없는 레거시 인코딩일 수 있다. 그러나 모든 유니코드 문자를 지원하지 않는 인코딩을 사용하는 경우에도 인코딩된 문서는 수치 문자 참조를 사용할 수 있다. 예를 들어, ☺ (☺)는 유니코드 문자 집합의 웃는 얼굴 문자를 나타내는 데 사용된다.

숫자 문자 참조에 의존하지 않고 모든 유니코드 문자를 지원하려면 웹 페이지에 모든 유니코드를 포함하는 인코딩이 있어야 한다. 가장 인기 있는 것은 UTF-8이며, 영어 글자, 숫자 및 기타 일반적인 문자 같은 ASCII 문자는 ASCII에 대해 변경되지 않은 상태로 유지된다. 이렇게 하면 HTML 코드(
및 등)가 ASCII와 비교하여 변경되지 않는다. ASCII 범위를 벗어나는 문자는 2~4바이트로 저장된다. 또한 대부분의 문자가 다양한 엔디언으로 2바이트로 저장되는 UTF-16을 사용할 수도 있는데, 이는 최신 브라우저에서 지원되지만 덜 일반적으로 사용된다.

 이 부분의 본문은 수치 문자 참조입니다.

레거시 인코딩의 한계를 해결하기 위해 HTML은 수치 문자 참조를 사용하여 HTML 문서 내에 전체 유니코드의 문자를 표현할 수 있도록 설계되었다. 이는 표현되는 문자의 유니코드 코드 포인트를 명시적으로 나타내는 문자 시퀀스이다. 문자 참조는 &#N;의 형식을 가지며, 여기서 N은 유니코드 코드 포인트의 10진수이거나, 16진수인 경우 x를 접두사로 붙여야 한다. 숫자 문자 참조를 구성하는 문자는 인터넷에서 사용하도록 승인된 모든 인코딩에서 보편적으로 표현할 수 있다.

이 맥락에서 16진수 지원은 비교적 최근에 도입되었으므로, 오래된 브라우저는 16진수 숫자로 참조된 문자를 표시하는 데 문제가 있을 수 있지만, 어쨌든 코드 포인트 255 이상의 유니코드 문자를 표시하는 데 문제가 있을 가능성이 높다. 오래된 브라우저와의 더 나은 호환성을 보장하기 위해 16진수 코드 포인트를 10진수 값으로 변환하는 것이 여전히 일반적인 관행이다(예: 合 대신 合).

 이 부분의 본문은 문자 참조입니다.

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

문자 엔티티는 &EntityName; 형식의 엔티티 참조를 사용하여 HTML 문서에 포함될 수 있으며, 여기서 EntityName은 엔티티의 이름이다. 예를 들어, —는 — 또는 —와 유사하게 U+2014를 나타내는데, 이는 사용된 문자 인코딩에 해당 문자가 포함되어 있지 않더라도 em dash 문자 "—"를 나타낸다.

전체 목록은 XML 및 HTML 문자 엔티티 참조 목록을 참조하라.

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

문서가 MIME 메시지 또는 HTTP 응답과 같이 MIME 콘텐츠 유형을 사용하는 전송을 통해 전송될 때, 메시지는 Content-Type: text/html; charset=UTF-8과 같은 Content-Type 헤더를 통해 인코딩을 알릴 수 있다. 다른 외부 인코딩 선언 방법도 허용되지만 거의 사용되지 않는다. 문서가 유니코드 인코딩을 사용하는 경우, 인코딩 정보는 바이트 순서 표식(BOM)의 형태로도 존재할 수 있다. 마지막으로, 인코딩은 HTML 구문을 통해 선언될 수 있다. text/html 직렬화의 경우, 페이지가 ASCII의 확장(예: UTF-8, 따라서 UTF-16을 사용하지 않는 경우)으로 인코딩되어 있는 한, <meta http-equiv="content-type" content="text/html; charset=UTF-8"> 또는 (HTML5부터) <meta charset="UTF-8">과 같은 meta 요소가 사용될 수 있다. XML로 직렬화된 HTML 페이지의 경우, 선언 옵션은 인코딩 기본값(XML 문서의 경우 UTF-8)에 의존하거나 XML 인코딩 선언을 사용하는 것이다. 메타 속성은 XML로 제공되는 HTML에서 아무런 역할도 하지 않는다.

인코딩 기본값은 외부 또는 내부 인코딩 선언이 없고 바이트 순서 표식도 없을 때 적용된다. XML로 제공되는 HTML 페이지의 인코딩 기본값은 UTF-8이어야 하지만, 일반 웹 페이지(즉, text/html로 직렬화된 HTML 페이지)의 인코딩 기본값은 브라우저의 로컬라이제이션에 따라 달라진다. 서유럽 언어용으로 주로 설정된 시스템의 경우 일반적으로 Windows-1252가 된다. 키릴 자모 로케일의 경우 기본값은 일반적으로 Windows-1251이다. 레거시 다중 바이트 문자 인코딩이 널리 사용되는 지역의 브라우저의 경우 어떤 형태의 자동 감지가 적용될 가능성이 있다.

프로그래밍 언어와 운영체제의 8비트 텍스트 표현 유산과 사용자에게 인코딩의 미묘한 차이를 이해해야 하는 부담을 피하려는 바람 때문에, HTML 작성자가 사용하는 많은 텍스트 편집기는 파일을 디스크에 저장할 때 인코딩 선택을 제공할 수 없거나 제공하지 않으려 하며, 심지어 매우 제한된 범위 이상의 문자 입력을 허용하지 않는 경우도 많다. 결과적으로 많은 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 또는 0xEFBBBF를 찾아 문서를 각각 UTF-32, UTF-16 또는 UTF-8로 인코딩된 것으로 식별하기만 하면 된다. 이러한 인코딩에는 추가 메타데이터 메커니즘이 필요하지 않다. 바이트 순서 표식이 처리 애플리케이션에 필요한 모든 정보를 포함하고 있기 때문이다. 대부분의 경우 바이트 순서 표식 문자는 다른 문자와는 별도로 편집 애플리케이션에 의해 처리되므로, 작성자가 잘못된 인코딩을 나타내기 위해 바이트 순서 표식을 제거하거나 변경할 위험은 거의 없다(인코딩이 영어/라틴어 스크립트로 선언될 때 발생할 수 있는 일). 문서에 바이트 순서 표식이 없는 경우, HTML 문서의 첫 번째 공백이 아닌 인쇄 가능한 문자가 "<"(U+003C)이어야 한다는 사실을 사용하여 UTF-8/UTF-16/UTF-32 인코딩을 결정할 수 있다.

많은 HTML 문서가 부정확한 인코딩 정보 또는 전혀 인코딩 정보 없이 제공된다. 이러한 경우 인코딩을 결정하기 위해 많은 브라우저는 사용자가 목록에서 인코딩 이름을 수동으로 선택할 수 있도록 한다. 또한 BOM의 경우와 XML로 제공되는 HTML의 경우 수동 재정의에 협력하거나 – 반대하여 작동하는 인코딩 자동 감지 알고리즘을 사용할 수도 있다.

text/html로 직렬화된 HTML 문서의 경우, 수동 재정의는 모든 문서에 적용될 수 있거나 선언 및 바이트 패턴을 통해 인코딩을 확인할 수 없는 문서에만 적용될 수 있다. 수동 재정의가 존재하고 널리 사용된다는 사실은 웹에서 정확한 인코딩 선언의 채택을 방해한다. 따라서 문제는 지속될 가능성이 높다. 그러나 인터넷 익스플로러, 크롬 및 사파리의 경우, XML 및 text/html 직렬화 모두에서 페이지에 BOM이 포함되어 있으면 인코딩 재정의를 허용하지 않는다.^[2]

선호되는 XML 레이블인 application/xhtml+xml로 직렬화된 HTML 문서의 경우, 수동 인코딩 재정의는 허용되지 않는다. 이러한 XML 문서의 인코딩을 재정의하는 것은 문서가 XML이 아니게 된다는 것을 의미한다. XML 문서의 경우 감지 가능한 오류가 있는 인코딩 선언을 갖는 것은 치명적인 오류이기 때문이다. 현재 파이어폭스와 같은 Gecko 브라우저는 이 규칙을 준수하지만, 웹킷 브라우저(크롬/사파리)와 같이 HTML을 XML로 지원하는 대부분의 다른 일반 브라우저는^[3] XHTML 문서의 인코딩을 수동으로 재정의할 수 있도록 허용한다.

많은 브라우저는 전체 유니코드 레퍼토리의 작은 하위 집합만 표시할 수 있다. 다음은 브라우저가 다양한 유니코드 코드 포인트를 표시하는 방법이다.

모질라 파이어폭스, 오페라, 사파리 및 인터넷 익스플로러(버전 7부터)와 같은 일부 웹 브라우저는 페이지의 각 개별 문자를 표시할 글꼴을 지능적으로 선택하여 다국어 웹 페이지를 표시할 수 있다. 적절한 글꼴이 운영체제에 존재하는 한, 어떤 유니코드 영역의 조합이든 올바르게 표시할 것이다.

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

위 표의 룬 문자 페후의 변형인 고딕 문자 파이후와 같이 기본 다국어 평면 밖의 문자를 표시하려면 일부 시스템(예: Windows 2000)에서는 설정을 수동으로 조정해야 한다.

구글의 웹 인덱스 내부 데이터에 따르면, 2007년 12월에 UTF-8 유니코드 인코딩은 웹 페이지에서 가장 자주 사용되는 인코딩이 되었으며, ASCII (미국) 및 8859-1/1252 (서유럽)를 모두 넘어섰다.^[4]

• 위키백과에서 특수 문자를 사용하는 도움말 파일
• HTML의 문자 인코딩
• 유니코드 문자 참조 (위키책)

• Unicode in XML and other Markup Languages - a W3C & Unicode Consortium joint publication that describes issues and provides guidelines relating to Unicode in markup languages
• Latin-1, "Special", and Mathematical, Greek and Symbolic named character entity definitions for HTML 4.01
• UnicodeMap.org - Browse Unicode characters, ranges, and other information
• SIL's freeware fonts, editors and documentation
• Alan Wood’s Unicode Resources - Unicode fonts and information.
• http://www.phon.ucl.ac.uk/home/wells/ipa-unicode.htm The International Phonetic Alphabet in Unicode
• http://www.alanwood.net/unicode/cjk_compatibility_ideographs.html CJK Compatibility Ideographs
• http://www.unicode.org/charts/ Unicode character charts; hexadecimal numbers only; PDF files showing all characters independent of browser capabilities
• Table of Unicode characters from 1 to 65535 보관됨 2007-11-03 - 웨이백 머신 - shows how they look in one's browser
• Web tool that converts "special" characters (such as Chinese characters) to Unicode numeric character references
• Multi-lingual web pages and Unicode - how to fix display problems
• w3.org via web.archive.org - Original HTML5 Citation Reference saved via Wayback Machine