| 5 HTML 문서 표현 | |
| 이전순서 | 다음순서 | 목록 | 엘레멘트 | 애트리뷰트 | 색인 | 원문 |
여기서는 문서가 컴퓨터와 인터넷에서 어떻게 표현되는가를 알아본다.
문서 글자 세트에서는 HTML 문서에 포함 될 수 있는 글자를 발췌하는 문제를 다룬다. 글자에는 라틴어(Latin) "A", 시릴어(Cyrillic) "I", 중국어 "水" 글자 등이 있다.
글자 엔코딩 항목에서는 이들 글자가 화일이나 인터넷을 통해 송신되면, 어떻게 표현(represented)되는가를 다뤘다. 어떤 글자 엔코딩은 직접 할 수 없는 경우가 있기 때문에, 제작자가 문서에 포함시키는 모든 글자를 표현하기 위하서 HTML은 글자 참조라는 기능을 제공한다.
인간 언어들에는 대단히 많은 글자들이 있고, 그 글자들의 표현 방식도 여러가지가 있으므로, 전 세계의 사용도구들이 이해 할 수 있도록 적당한 배려가 있어야 한다.
원거리에 널리 통용되기 위하여 HTML를 포함 한 각 SGML은 적용 할 문서 글자 세트(document character set)를 지정 할 필요가 있다.
HTML 문서를 포함 한 각 SGML 문서는 레파토리에 있는 글자들이 연속 된 것이다. 컴퓨터 시스템은 각 글자를 코드에서의 글자 위치로 인식한다. 예를 들면 ASCII(아스키) 글자 세트에서 코드에서의 글자 위치 65, 66과 67은 각각 글자 'A', 'B', 와 'C'를 나다낸다.
ASCII 글자 세트는 웹과 같은 전 세계적인 정보 시스템에서는 충분하지 못하므로 HTML은 세계적 세트 글자(UCS: Universal Character Set[ISO10646])라는 훨신 더 완전한 글자 세트를 사용한다. 이 표준은 전 세계에서 사용되는 수 천 글자의 레파토리(repertoire)를 갖는다.
이 [ISO10646]에서 정의 된 글자 세트는 Unicode[UNICODE]에 맞게 글자 별로 정의되어있다. 이 두 표준은 때때로 새로운 글자를 추가하면서 업데이트되는데 해당 웹 싸이트에서 조회 할 수 있다. 현재의 규격에서 ISO-10646은 유니코드(Unicode)와 같은 문서 글자 세트를 의미하지만, 유니코드 규격에는 양방향 텍스트 기능도 조회한다.
그러나 문서 글자 세트는 화일이나 네트워그 송신에서 일련의 바이트들을 엔코딩하는 사용도구에서는, HTML 문서를 바르게 표현하는데 충분하지 못하다. 사용도구는 문서 글자 흐름을 바이트 흐름으로 변환하는 글자 엔코딩도 이해 해야한다.
이 규격에서 글자 엔코딩(character encoding)으로 불리우는 것이 타 규격에서 다른 이름으로 알려져 있기도 하여 혼동을 일으킬 수도 있다. 그러나 그 개념은 인터넷에서 거의 같다. 또 한 프로토콜 헤더(protocol header), 애트리뷰트와 파라메터도 글자 엔코딩 "charset"이라는 같은 이름을 사용하고, [IANA] 등록(registry)에서 가져 온 값도 그렇다. 완전 한 목록은 [CHARSETS] 참조하라.
"charset" 파라메터는 글자 엔코딩을 지정하는 것으로, 일련의 바이트 흐름을 일련의 글자 흐름으로 변환 하는 한가지 방법이다. 물론 이 변환은 웹의 작용에 적합한데, 서버들은 일련의 바이트 흐름으로 사용도구에게 HTML 문서를 보내고, 사용도구들은 이것을 일련의 문자 흐름으로 해석한다. 그 변환 방법은 단순한 일 대 일 통신에서 부터 복잡한 스위칭 방식/기능(switching scheme or algorithm) 까지 있다.
[ISO10646]와 같이 문자가 많으면, 단순한 한-글자당-한-바이트 엔코딩 기술로는 글자 레파토리(repertoire)로 문자열을 처리하는 데 한계가 있다. [ISO10646]에는 UCS-4와 같은 몇 가지 다른 엔코딩 방식이 전체 글자 세트에 추가되어 있다.
문서 작성기와 같은 편집기들은 선택 된 글자 엔코딩 방식으로 HTML 문서를 엔코딩하며, 그 선택은 소프트웨어에 사용 된 방법에 따라 크게 좌우된다. 이들 도구들은 서류에 포함 된 대부분의 글자를 포함하는 어떤 편리한 엔코딩 방법도 채용 할 수 있는데, 이는 올바른 엔코딩되었다는 전제에서 그렇다. 간혹 나타나는 이 엔코딩에 포함되지 않는 글자는 여전히 글자 참조를 적용 할 수 있다. 이들은 글자 엔코딩을 참조하지 않고 항상 문서 글자 세트를 참조한다.
서버와 프록시(proxy)들은 사용도구의 요청에 따라 글자 엔코딩을 변경 할 수 있는데, 이를 트랜스 코딩(transcoding)이라 한다. [RFC2068], HTTP 헤더 요청에 따라 받아 들이는 글자 세트, 항목 14.2를 참조하라. 서버와 프록시(proxy)들은 모든 문서 글자 세트를 커버하는 글자 엔코딩을 제공해야 하는 것은 아니다.
웹에서 보편적으로 사용되는 글자 엔코딩은 다음 사항을 포함한다.
이 규격에서 사용도구가 어떤 글자 엔코딩을 사용 해야한다는 강제성은 없다.
규격에 부합하는 사용도구는 어떤 글자 엔코딩를 사용하던 Unicode에 맞도록 모든 글자를 배치하여야 히며 최소한 그렇게 작동야여야 한다.
HTML 문장이 UTF-16(charset=UTF-16)로 송신 될 때, [ISO10646 항목 6.3]와 [UNICODE C3절 페이지 3-1]에 따라, 문장은 네트워크 바이트 순서(큰 endian, 높은 순서 바이트 먼저)로 송신되어야 한다.
또 한 적절히 표현되는 기회를 극대화하기 위하여 UTF-16로 송신되는 문서는 항상 너비 없는 줄바꿈 글자가 아닌 공간 글자(ZERO-WIDTH NON-BREAKING SPACE: 16진수 FEFF: 바이트 순서 표시(BOM: Byte Order Mark))로 시작할 것을 권하다. 이 바이트가 예약되어 있으면, 이 16진수 FFFE로 지정하면 다른 글자로 지정되지 않은 글자 임이 확실하다. 사용도구는 그래서 문장의 첫번째 바이트를 16진수 FFFE로 받으면, 나머지 부분의 문장을 위한 바이트들을 준비해야 한다는 것을 알게된다.
IANA에 ISO-10646-UTF-1로 등록 된 [ISO10646]의 변환 양식 UTF-1은 사용되지 않아야 한다. ISO 8859-8과 양방향 기능에 대한 추가 정보는 양방향성과 글자 엔코딩을 참조하라.
서버는 문서를 사용하는데 적용 할 글자 엔코딩을 어떻게 결정하는가? 일부 서버들은 문서의 맨 앞쪽 몇 바이트들을 점검하거나, 또는 알고 있는 화일과 엔코딩 데이터베이스에 맞는가를 점검한다. 많은 오늘날 서버들은 글자 설정에서 과거 서버에서 보다 웹 관리자에게 좋은 관리 능력을 제공한다. 웹 관리자는 가급적 "charset" 파라메터를 사용하여, 이들 기능에 잘못 된 "charset" 파라메터 값이 지정되지 않도록 하여야 한다.
사용도구는 어떤 글자 엔코딩을 사용 했는가를 어떻게 알아내나? 서버가 이 정보를 제공하여야 한다. 가장 직접적으로 서버가 사용도구에게 문서의 글자 엔코딩 방식을 알려주는 방법은 HTTP 프로토콜(protocol) 의 "Content-Type"(컨텐트 타입) 헤더에 "charset" 파라메터를 사용하는 것이다([RFC2068] 3.4와 14.18 참조).
HTTP 헤더에 EUC-JP로 글자 엔코딩을 지정한 예제:
Content-Type: text/html; charset=EUC-JP
text/html 정의에서 규격에 부합성 항목을 참조하라.
HTTP 프로토콜(protocol: [RFC2068] 항목 3.7.1)에서는 "Content-Type" 헤더에 "charset" 파라메터가 없을 때 디폴트로 ISO-8859-1 글자 엔코딩을 사용한다고 언급되어있다. 실제로는 일부 서버들에서는 "charset" 파라메터를 허용하지 않고, 다른 일부 서버에서는 파라메터를 설정하는 것을 허용하자 않기 때문에 사용 할 수 없다. 따라서 사용도구는 "charset" 파라메터에 어떤 디폴트 값을 가정하지 말아야 한다.
서버에 알려 주거나 구성의 한계를 설정하기 위하여, HTML 문서는 META 엘레멘트를 사용하여 사용도구에게 문서의 글자 엔코딩 정보를 확실히 지명적으로 제공 할 수 있다.
예를 들어, 현재 문서의 글자 엔코딩을 "EUC-JP"로 지정하기 위해서 다음의 META 선언을 한다.
<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
META 선언에서 글자 엔코딩은 그 선언이 ASCII 글자 자체을 표시하는 ASCII 값 바이트 일 경우에 한정하여(최소한 META 엘레멘트 해석이 끝 날 때까지) 사용 할 수 있다. HEAD 엘레멘트에서 META 선언은 가급적 일찍하여야 한다.
HTTP 프로토콜이나 META 엘레멘트에서 문서의 글자 엔코딩 정보를 제공하지 못 할 경우를 위해, 또한 HTML은 몇가지 엘레멘트에서 charset 애트리뷰트를 제공한다. 제작자는 이 기능들을 조합하여, 사용자가 문서를 읽을 때, 사용도구가 글자 엔코딩을 인식 할 수 있는 기회를 크게 향상 시킨다.
HTML 규격에 부합하는 사용도구는 문서의 글자 엔코딩을 결정 할 때, 다음 요약한 위로부터의 우선 순위를 따라야한다.
이 우선 순위 목록에 추가적으로 사용도구는 사용자 설정를 사용 할 수 있다. 예를 들어, 많은 사용도구들은 일본어 문장에서 사용되는 다양 한 엔코딩을 구별하기 위하여 계통 체계(heuristics)를 사용한다. 또한 어떤 사용도구들은 다른 지정이 없을 때 적용하도록, 사용자가 정의하는 자체 디폴트 글자 엔코딩을 갖는 경우도 있다.
사용도구는 틀린 "charset" 정보를 사용자가 덮어 씌우(override)는 기능을 제공 할 수 있다. 그러나 사용도구가 그러한 기능을 제공한다면, 틀린 "charset" 파라메터를 갖는 웹 페이지를 만들지 않도록, 문서 편집에서는 제공하지 말고, 브라우징에 만 제공하여야 한다.
주석: 만일 특수한 목적을 위하여 [ISO10646] 이외의 글자를 사용 할 필요가 있을 때는, 그 글자가 현재와 미래의 표준 버전 글자들과 충돌하지 않도록, 별도의 영역이 지정하여야 한다. 그러나, 통용성 때문에, 그렇게 하지 않을 것을 강하게 추천한다.
주어진 글자 엔코딩으로 문서 글자 세트의 모든 글자를 표현하지 못 할 수 있다. 이런 엔코딩, 또는 하드웨어나 소프트웨어의 설정이 사용자가 일부 문서 글자를 직접 입력 할 수 없을 경우, 제작자는 SGML 글자 참조를 사용 할 수 있다. 글자 참조는, 글자 엔코딩의 영향을 받지 않는 기능으로, 문서 글자 세트로 부터 어떠 글자도 입력하게 하기 위한 것이다.
HTML에서 글자 참조는 다음 두가지 형태로 할 수 있다.
코멘트(comment)안에서 글자 참조는 의미가 없으며 단순한 참고사항이다.
주석: HTML은 인리인(inline) 이미지로 글자 데이터를 표시하는 다른 방법을 제공한다.
주석: SGML에서 글자 참조 제일 끝 ";"의 어떤 경우에는(예: 줄 바꿈 혹은 태그 바로 전) 생략 할 수 있다. 어떤 다른(예: 단어 중간) 경우에는 생략 될 수 없다. 이 글자를 필요로하는 사용도구에서 문제 발생을 피하기 위해 항상 ";"를 사용 할 것을 권한다.
숫자 참조는 문서 글자 세트에서 글자의 코드 위치를 나타낸다. 숫자 참조는 다음 두가지의 형태가 될 수 있다.
몇가지 숫자 참조의 예제:
설정 된 언어나 브라우저에 따라 16 진수 글자 번호, 특정 글자 번호를 표현하지 못하는 경우가 있다.
주석: [ISO8879]에 16진수는 정의되어 있지 않으나 [WEBSGML]의 기술에 따르면 새로운 개정판에는 포함 될 것으로 보인다. 일반적으로 글자 표준이 16진수로 표현되므로 이 변환은 매우 유용 할 것이다.
제작자가 문서 글자 세트에서 글자 참조하는 더 직관적인 방법을 위하여, HTML은 글자 엔티티(entity) 참조 세트를 제공한다. 글자 엔티티 참조는 제작자가 코드 위치를 기억하지 않고 상징적인 이름을 사용하였다. 예를 들어, 글자 엔티티 참조 å은 소문자 "å"이며, 하나의 원(a ring;)을 "å"으로 표시하므로 å을 기억하기보다 쉽다.
HTML 4는 문서 글자 세트의 모든 글자를 글자 엔티티 참조로 정의하지는 않았다. 예를 들어 글자 엔티티 참조에서는 시릴어(Cyrillic) 대문자 "I"는 정의하지 않았다. HTML 4에 정의되어있는 글자 참조 목록 전부를 참조하라.
글자 엔티티(entity) 참조는 대소문자 구별하여 사용된다. 그래서 Å(Å)은 å(å)과 다르다.
다음 네가지 글자 엔티티 참조들은 자주 사용는 특수글자로 특수하게 지정하였다.
제작자가 문장에서 "<" 글자를 사용 할 때는 "<"(ASCII 10진수 60)을 사용하여야 만 시작태그의 구분자(delimiter)와 구별 할 수 있다. 마찬가지로 제작자가 문장에서 ">" 대신에 ">"(ASCII 10진수 62)를 사용하여, 따옴표 속의 애트리뷰트 값에서 종료태그 구분자로 잘못 해석 할 수 있는 과거의 사용도구에서 문제를 일으키지 않는다.
제작자는 "&" 대신 "&"(ASCII 10진수 38)를 사용하여 엔티티 참조의 시작 구분자와의 혼동을 피할 수 있다. 또한 CDATA 애트리뷰트 값 속에서도 이 글자 참조가 허용되기 때문에, 애트리뷰트 값에서도 "&"를 사용하여야 한다.
일부 제작자는 따옴표(") 대신에 글자 엔티티 참조 """를 사용한다. 그 이유는 " 글자가 애트리뷰트 값을 표현 할 때 사용되기 때문이다.
사용도구는 문서의 모든 글자를 의미있게 표현하는 것이 가능하지 않을 수 있다. 예를 들어, 사용도구에 적당한 폰트가 없어, 사용도구의 자체 글자 엔코딩으로 표현 될 수 없는 글자 값이 될 수 있기 때문이다.
이런 경우는 쓸 수 있는 방법이 많기 때문에, 이 문서에 어떤 지시 지항을 포함시키지 않았다. 표현 할 수 없는 글자는, 그 용도에 따라, 그 적용 프로그램에 의하지 않고, 자체의 디스플레이 시스템에 의해 처리 될 수 있다. 특정 스크립트나 언어의 필요에 맞추는 등 더 고도의 기능이 없다면, 사용도구들은 다음과 같은 기능을 가질 것을 권한다.
| 이전순서 | 다음순서 | 목록 | 엘레멘트 | 애트리뷰트 | 색인 | 원문 |
이 문서(http://trio.co.kr/webrefer/html/charset.html)는 자유로이 연결 사용이 가능함.