HTML의 문자 인코딩

HTML 하이퍼텍스트 마크업 언어(HTML)는 1991년부터 사용되었지만, 1997년 12월의 HTML 4.0은 문자를 합리적으로 완전하게 처리한 최초의 표준화된 버전이다. HTML 문서에 7비트 ASCII 범위를 벗어나는 특수 문자가 포함될 때 고려할 두 가지 목표는 정보의 인티그리티와 범용 브라우저 표시이다.
# 문서의 문자 인코딩 지정
문서에서 사용되는 문자 인코딩을 지정하는 두 가지 일반적인 방법이 있다. 첫째, 웹 서버는 하이퍼텍스트 전송 프로토콜(HTTP)의 `Content-Type` 헤더에 문자 인코딩 또는 "`charset`"을 포함할 수 있으며, 일반적으로 다음과 같이 표시된다. Content-Type: text/html; charset=utf-8 이 방법은 HTTP 서버가 콘텐츠 협상에 따라 문서의 인코딩을 변경할 수 있는 편리한 방법을 제공한다. 특정 HTTP 서버 소프트웨어는 이를 수행할 수 있으며, 예를 들어 Apache는 `mod_charset_lite` 모듈을 통해 가능하다.title = Apache Module mod_charset_lite 둘째, 문서 자체 내에 선언을 포함할 수 있다. HTML의 경우 문서 상단 근처의 `head` 요소 안에 이 정보를 포함할 수 있다. HTML5는 다음과 같은 구문도 정확히 동일한 의미로 허용한다. XHTML 문서는 세 번째 옵션으로 XML 선언을 통해 문자 인코딩을 표현할 수 있으며, 다음과 같다. 이 두 번째 접근 방식에서는 선언이 파싱되기 전까지 문자 인코딩을 알 수 없기 때문에, 선언 자체까지 문서에 사용된 문자 인코딩을 아는 데 문제가 있다. 문자 인코딩이 ASCII 확장인 경우 선언 자체까지의 내용은 순수 ASCII여야 하며 올바르게 작동한다. UTF-16BE 및 UTF-16LE와 같이 ASCII 확장이 아닌(즉, ASCII의 상위 집합이 아닌) 문자 인코딩의 경우, 웹 브라우저와 같은 HTML 프로세서는 휴리스틱을 사용하여 일부 경우에 선언을 파싱할 수 있어야 한다.
## 인코딩 감지 알고리즘
HTML5부터 권장되는 문자 집합은 UTF-8이다. 문서의 문자 인코딩을 결정하기 위해 여러 입력 소스를 기반으로 하는 "인코딩 스니핑 알고리즘"이 사양에 정의되어 있다: # 명시적인 사용자 지시 # 문서의 첫 1024바이트 내의 명시적인 메타 태그 # 문서의 처음 3바이트 내의 바이트 순서 표식 (BOM) # HTTP Content-Type 또는 기타 전송 계층 정보 # 특정 바이트 값 시퀀스 또는 범위를 찾기 위한 문서 바이트 분석,title = HTML5 prescan a byte stream to determine its encoding 및 기타 잠정적인 감지 메커니즘. 인쇄 가능한 ASCII 범위(32~126) 밖의 문자는 보통 잘못 표시된다. 이는 영어 사용자를 위한 몇 가지 문제를 야기하지만, 다른 언어는 정기적으로—어떤 경우에는 항상—그 범위를 벗어나는 문자를 필요로 한다. 중국어, 일본어, 한국어(한중일 문자) 언어 환경에서는 여러 가지 다른 멀티바이트 인코딩이 사용되고 있어 자동 감지도 자주 사용된다. 마지막으로, 브라우저는 보통 사용자가 잘못된 문자 집합 레이블을 수동으로 재정의할 수 있도록 허용한다. 다국어 웹사이트와 비서구권 언어 웹사이트에서 모든 언어에 동일한 인코딩을 사용할 수 있도록 UTF-8을 사용하는 것이 점점 더 일반화되고 있다. 모든 언어에 사용할 수 있는 UTF-16 또는 UTF-32는 바이트 지향 ASCII 상위 집합 인코딩을 가정하는 프로그래밍 언어에서 처리하기 어렵고, HTML 문서의 경우와 같이 ASCII 문자의 빈도가 높은 텍스트에는 효율성이 떨어지기 때문에 널리 사용되지 않는다. 페이지가 성공적으로 표시되는 것이 반드시 인코딩이 올바르게 지정되었음을 나타내는 것은 아니다. 페이지 작성자와 독자 모두 특정 플랫폼별 문자 인코딩을 가정하고 서버가 식별 정보를 보내지 않으면, 독자는 작성자가 의도한 대로 페이지를 볼 수 있지만, 다른 플랫폼이나 다른 모국어를 사용하는 다른 독자는 의도한 대로 페이지를 볼 수 없다.
# 허용되는 인코딩
최근 HTML 표준(현재 WHATWG HTML Living Standard, 그리고 이전에 경쟁했던 W3C HTML 5.0 및 5.1)에서 참조되는 WHATWG Encoding Standard는 브라우저가 지원해야 하는 인코딩 목록을 지정한다. HTML 표준은 다른 인코딩의 지원을 금지한다.publisher=W3Cpublisher=W3Cpublisher=WHATWG Encoding Standard는 또한 새로운 형식, 새로운 프로토콜(기존 형식이 사용되는 경우에도), 새로운 문서 작성자는 UTF-8만을 사용해야 한다고 규정한다. UTF-8 외에 다음 인코딩은 Encoding Standard를 참조하여 HTML 표준 자체에 명시적으로 나열되어 있다. author-link=안느 판 케스터렌Notelist 다음 추가 인코딩은 Encoding Standard에 나열되어 있으며, 따라서 해당 인코딩에 대한 지원도 필요하다.url=https://encoding.spec.whatwg.org/#names-and-labels * 코드 페이지 866 * ISO-8859-3 * ISO-8859-4 * ISO-8859-5 * ISO-8859-6 * Iurl=https://encoding.spec.whatwg.org/#ref-for-iso-8859-8%E2%91%A0 * ISO-8859-10 * ISO-8859-13 * ISO-8859-14 * ISO-8859-15 * ISO-8859-16 * KOI8-R * KOI8-U / KOI8-RUwork=W3C Bugzilla 0x93–9F 위치에서는 KOI8-U를 따른다. * Mac OS Roman * Windows-1253 * Mac OS Cyrillic * GBKauthor-link=안느 판 케스터렌 * EUC-JPauthor-link=안느 판 케스터렌 Notelist 다음 인코딩은 금지된 인코딩의 명시적인 예시로 나열되어 있다. * CESU-8 * UTF-7 * BOCU-1 * SCSU * EBCDIC * UTF-32 또한 이 표준은 "교체(replacement)" 디코더를 정의하는데, 이는 특정 인코딩으로 레이블이 지정된 모든 콘텐츠를 교체 문자(�)로 매핑하여 전혀 처리하지 않는다. 이는 악의적인 콘텐츠를 숨기기 위해 클라이언트와 서버 간에 지원되는 인코딩의 차이를 악용할 수 있는 공격(예: 사이트 간 스크립팅)을 방지하기 위함이다.title=14.1: replacement ISO-2022-JP 및 UTF-16에도 동일한 보안 문제가 적용되며, 이들도 ASCII 바이트 시퀀스가 다르게 해석될 수 있지만, 이들은 배포된 콘텐츠에서 비교적 더 자주 사용되기 때문에 이러한 접근 방식은 이들에게는 실현 가능하다고 여겨지지 않았다.title=2: Security background 다음 인코딩은 이러한 처리를 받는다.url=https://encoding.spec.whatwg.org/#ref-for-replacement%E2%91%A1 * ISO-2022-KR * ISO-2022-CN * ISO-2022-CN-EXT * HZ-GB-2312
# 문자 참조
원시 문자 인코딩 외에도 문자는 숫자 문자 참조(십진법 또는 십육진법) 또는 문자 엔티티 참조와 같은 문자 참조로도 인코딩될 수 있다. 문자 엔티티 참조는 때때로 명명된 엔티티 또는 HTML의 HTML 엔티티라고도 불린다. HTML의 문자 참조 사용은 SGML에서 유래한다.
## HTML 문자 참조
HTML의 숫자 문자 참조는 유니버설 문자 집합/유니코드의 코드 포인트로 문자를 참조하며, 형식은 다음과 같다. :`&#nnnn;` 또는 :`&#xhhhh;` 여기서 nnnn은 십진법 형식의 코드 포인트이고, hhhh는 십육진법 형식의 코드 포인트이다. XML 문서에서는 x는 소문자여야 한다. nnnn 또는 hhhh는 몇 자리든 될 수 있으며 선행 0을 포함할 수 있다. hhhh는 대소문자가 혼합될 수 있지만, 대문자가 일반적인 스타일이다. HTML 문서를 수신하는 웹 브라우저 또는 이메일 클라이언트, 또는 HTML 문서를 작성하는 문서 편집기가 모든 HTML 문자를 렌더링할 수 있는 것은 아니다. 대부분의 최신 소프트웨어는 사용자의 언어에 대한 대부분 또는 모든 문자를 표시할 수 있으며, 렌더링할 수 없는 문자에 대해서는 상자 또는 기타 명확한 표시를 그린다. 0에서 127까지의 코드, 즉 원래의 7비트 ASCII 표준 세트는 대부분의 문자를 문자 참조 없이 사용할 수 있다. 160에서 255까지의 코드는 모두 문자 엔티티 이름을 사용하여 생성할 수 있다. 더 높은 번호의 코드 중 일부만이 엔티티 이름을 사용하여 생성될 수 있지만, 모든 코드는 십진수 문자 참조로 생성할 수 있다. 문자 엔티티 참조는 `&name;` 형식도 가질 수 있으며, 여기서 name은 대소문자를 구분하는 영숫자 문자열이다. 예를 들어, "λ"는 HTML 문서에서 `&lambda;`로도 인코딩될 수 있다. `&lt;`, `&gt;`, `&quot;` 및 `&amp;` 문자 엔티티 참조는 HTML 및 SGML에서 미리 정의되어 있다. 이는 ``, `"` 및 `&`이 이미 마크업을 구분하는 데 사용되기 때문이다. 이는 HTML5 이전에는 XML의 `&apos;` (') 엔티티를 포함하지 않았다. 모든 명명된 HTML 문자 엔티티 참조와 도입된 버전 목록은 XML 및 HTML 문자 엔티티 참조 목록을 참조하라. HTML 문자 참조를 불필요하게 사용하면 HTML 가독성이 크게 떨어질 수 있다. 웹 페이지의 문자 인코딩이 적절하게 선택되면, HTML 문자 참조는 일반적으로 위에서 언급한 마크업 구분 문자 및 몇 가지 특수 문자(또는 UTF-8과 같은 기본 유니코드 인코딩이 사용되는 경우 전혀 필요하지 않음)에만 필요하다. 잘못된 HTML 엔티티 이스케이프는 또한 사이트 간 스크립팅과 같은 주입 공격에 대한 보안 취약점을 열 수 있다. HTML 속성이 인용되지 않은 상태로 남아 있으면, 가장 중요한 공백(예: 공백 및 탭)과 같은 특정 문자는 엔티티를 사용하여 이스케이프되어야 한다. HTML과 관련된 다른 언어는 문자를 이스케이프하는 자체 방법이 있다.
## XML 문자 참조
다양한 문자 엔티티 참조가 있는 기존 HTML과 달리, XML에는 미리 정의된 문자 엔티티 참조가 5개뿐이다. 이는 특정 맥락에서 마크업에 민감한 문자를 이스케이프하는 데 사용된다. {| class="wikitable" | `&amp;` ||align="center"| & || 앰퍼샌드 || U+0026 |- | `&lt;` ||align="center"| || 초과 기호 || U+003E |- | `&quot;` ||align="center"| " || 인용 부호 || U+0022 |- | `&apos;` ||align="center"| ' || 아포스트로피 || U+0027 |} 다른 모든 문자 엔티티 참조는 사용되기 전에 정의되어야 한다. 예를 들어, XML 문서에서 `&eacute;`(é, 유니코드 U+00E9인 아쿠트 악센트가 있는 라틴 소문자 E를 나타냄)를 사용하면 엔티티가 이미 정의되지 않은 경우 오류가 발생한다. XML은 또한 십육진수 숫자 참조의 `x`가 소문자여야 한다. 예를 들어 `&#XA1b` 대신 `&#xA1b`여야 한다. XML 애플리케이션인 XHTML은 XML의 미리 정의된 엔티티와 함께 HTML 엔티티 세트를 지원한다.