WWW의 국제화와 한국화
1996/11/29
한국과학기술원 경영정보연구센터
정 주 원*
1. 서론
해외 교역 활성화에 따라, 다른 나라의 제품을 우리나라 시장에서 구입하거나 우리나라의 제품을 다른 나라에서 찾아 볼 수 있는 것은 그리 어렵지 않은 일이 되었다. 매스미디어의 발달은 각종 정보를 사람들에게 보다 많이 전파하고, 광고를 포함한 상품 정보의 전달도 그 중에 큰 몫을 차지하고 있다. 결국, 하나의 상품이 전세계적으로 널리 사용되는 경우를 종종 찾아 볼 수 있다.
특히 소프트웨어의 경우에는 하나의 프로그램이 전세계에서 널리 쓰이는 일이 자주 일어난다. 어느 나라에서나 IBM PC호환 컴퓨터에는 Microsoft사의 MS-DOS나 Windows 95가 탑재되고, 또한 그것이 당연시 된다. 흔히 인터넷 접속이라 말하는 웹 브라우져 는 Netscape사의 Netscape Navigator를 사용해야 하는 것으로 알려져 있고, 이것 이외의 웹 브라우져는 사용할 수 없다는 듯이 인식되어 있는 것이 사실이다.
하나의 소프트웨어가 전 세계에서 널리 쓰인다는 것은 소프트웨어 시장에서의 독점이라는 측면에서 보면 문제가 있는 일이지만, 몇몇 프로그래머의 노력만으로 전 세계의 사람들을 만족시킬 수 있으니 효율성의 측면에서 보면 매우 바람직한 일이다. 사실, 하나의 소프트웨어가 전세계적으로 쓰인다는 사실은 소프트웨어 시장의 독점과는 약간 거리가 있는 이야기이다. 왜냐하면 소프트웨어 분야는 매우 넓기 때문이다.
몇 년 전만해도 아니 심지어는 지금까지도, 외국에서 특히 미국에서 개발되었다는 좋은 소프트웨어를 우리나라에서 쓰려고 하다 보면 가장 먼저 문제가 되는 것이 '한글을 쓸 수 있는가' 라는 것이다. 아무리 좋은 소프트웨어라 하더라도 우리나라에서 한글을 못쓰면 실제적인 응용이 어려워진다. 본의 아니게 이름, 주소등을 영어로 적어야 하는 웃지 못할 일이 벌어지는 것이다.
이와 같은 문제는 비단 우리나라에만 있는 것이 아니다. 이웃 나라인 일본과 중국이 비슷한 문제에 봉착하며, 심지어는 대부분이 로마자를 쓰지만, 영어 알파벳 이외의 글자도 쓰는 유럽에서도 문제가 된다. 어쨌든 자신들이 실생활에서 사용하는 글자를 쓸 수 없게 되는 경우가 있는 것이다.
어찌 어찌하여 한글을 사용하는데 문제가 없는 프로그램을 구했다고 하자. 그러면 소프트웨어의 설명이나 메뉴 이름 등이 우리말로 되어있지 않다는 데에 아쉬움을 느끼게 된다. 영어를 잘 할 줄 모르는 사람이 모든 설명이 영어로 나오는 프로그램을 사용하다 보면 답답함에 탄식이 나온다. 게다가 날자는 왜 년/월/일 순이 아니고, 월/일/년 순인가? 월이 숫자로 나오면 그래도 양반이다. March, June, September 등 달이 영어로 나오면 이게 몇 월이더라 하고 한번 허공을 쳐다보게 된다. 컴퓨터 프로그램을 쓰다 보면 영어 못하고, 미국의 문화를 모르는 건 죄라는 느낌이 든다. 내가 서 있는 이 땅은 한국어를 쓰는 대한민국의 땅이거늘.
이와 같이 소프트웨어를 사용하면서 느끼는 답답함은 소프트웨어 자체를 우리가 개발하지 못한 탓도 있지만, 우리가 소프트웨어 제작자와 연락을 할 수 없거나 수정을 요구할 수 없기 때문에 나타나는 것이다. 그 당시에는 미국의 회사에게 시장 크기가 얼마 되지 않는 한국의 사용자들을 위해 한글을 쓸 수 있게 해 주고, 한글 메시지를 넣어 달라는 것은 아무래도 무리였던 것이다.
그러나, 지금은 하나의 소프트웨어가 전세계에서 사용되는 것이 보편적이 추세이며, 우리나라를 포함한 각국의 소프트웨어 시장의 크기가 무시할 수 없을 정도로 커졌다. 이에 따라 소프트웨어 개발 회사에서는 각국의 언어와 문화양식에 따라 자사의 프로그램을 고쳐야 했다. 대상이 되는 나라가 여러 나라이다 보니 새 버전의 프로그램이 나올 때마다 각각의 프로그램을 해당 국가에서 사용할 수 있는 형태로 만드는 것이 어려워졌다. 따라서, 각 국가의 언어와 문화적 특성을 띄는 부분을 따로 모아서 그 공통점을 찾아 구현하는 방식을 제안하기에 이르렀는데, 이것을 소프트웨어의 국제화(Internationalization)라 한다.
웹 브라우져에 있어서 국제화는 필수적이다. 왜냐하면, 기본적으로 웹 브라우져가 대상으로 하는 문서는 전세계를 접속하는 인터넷의 문서들이기 때문에 어떤 나라, 어떤 언어로 작성되어도 처리할 수 있는 능력을 필요로 한다. 또한, 웹 브라우져라는 프로그램이 전세계 어느 나라 사람이라 하더라도 편리한 인터넷 사용을 위하여 필요한 소프트웨어이기 때문이다. World-Wide Web이란 이름에서 World-wide란 말은 결코 과장도 장난도 아니다.
본 장에서는 웹 브라우져의 국제화에 필요한 요소들을 다룬다. 먼저 국제화와 현지화란 무엇인지, 그 개념은 무엇인지 살펴본다. 그리고, WWW의 기술적 측면에서 국제화 방향에 대하여 이야기하며, 웹 브라우져의 사용자 인터페이스로서 어떤 것들이 지원되어야 하는지에 대해서도 다룬다. 또한, 현지화의 하나인 '한국화'의 요건에 대해서도 다룬다.
2. 국제화와 현지화
전세계적으로 컴퓨터 보급이 늘어나자, 소프트웨어 시장도 그만큼 커졌다. 소프트웨어 시장이 자국 내에 한정되지 않고 외국까지 확대되자 다른 나라의 언어와 문화에 맞게 소프트웨어를 고치는 일이 쓸데없는 비용이 되는 경우가 많았다. 따라서, 프로그램 중에서 각국의 언어와 문화에 관한 부분을 따로 떼어 구현함으로써, 다른 나라의 문화와 언어에 맞도록 고치는 작업을 단순화 시키고자 하는 노력이 있게 되었다.
국제화란, 소프트웨어를 설계하고 구현할 때 프로그램의 논리적인 부분과 언어, 문화적인 부분을 서로 독립적으로 구현 함으로서, 같은 소프트웨어를 최소의 비용으로 다른 언어, 문화권용으로 바꾸기 쉽도록 설계하는 것이다. 극단적으로 말하자면 전 세계 어느 나라에서도 사용 가능한 프로그램으로 변경하기 쉽도록 만드는 작업을 말한다. 국제화는 영어로 Internationalization 혹은 Internationalisation이라고 하는데 줄여서 I18N이라고 한다. 이것은 I자와 N자 사이에 알파벳이 18자 있다는 의미로 축약해서 쓴 것이다.
현지화란 국제화한 프로그램을 어느 나라에 대해서, 그 나라의 언어·문화적 특성 부분을 실제로 구현하는 것을 말한다. 영어로는 localization, 줄여서 L10N이라고 한다. 여기서, 현지화를 위해 제공되는 자료 및 처리 기능을 로케일(locale)이라 한다.
이와 같이 국제화된 프로그램을 하나 짜 놓고, 이것을 자국용으로 현지화 하면 일단 국내 시장에 내 놓을 수 있다. 그 후 타국에도 같은 프로그램을 그 나라의 특성에 맞도록 팔려면, 그 나라용으로 현지화 하는 작업만으로 지금까지 개발한 프로그램을 그대로 사용할 수 있다는 개념이 국제화-현지화 개념이다.
2.1. 문화적 요소
그러면 국제화에서 따로 고려해야 할 언어·문화적 특징이란 무엇인가? 기존의 국제화 연구에서 알려진 몇 가지 사실들을 나열해 보자.
문자
한국에서 한국 사람이 쓰는 언어는 한국어이며 한국어는 한글이란 한국 고유의 문자로 나타낸다. 영어는 알파벳으로 나타내어지며, 대소문자 구별이 있다. 일본어는 히라가나와 카타카나, 그리고 한자로 나타낸다. 이와 같이 각 나라의 말에는 그것을 기록으로 표현하는 방식인 문자가 있다.
문자는 컴퓨터 상에서 어떠한 종류의 부호로 나타내어지는데 이것을 '부호화된 문자 집합', 영어로는 부호화된 문자 집합이라 한다. 영어는 아스키(ASCII) 코드라는 부호화된 문자 집합으로 표현되고, 한글은 KSC-5601 코드로 표현된다.
한글을 표현하는 데는 KSC-5601 완성형으로 나타내어질 수도 있고 조합형으로 나타내어 질 수도 있다. 따라서 하나의 문자 집합에는 여러 개의 부호화된 문자 집합이 있을 수 있다.
숫자 표현
우리나라에서는 오만 이천 구백 삼십 사 점 이 육을 52,934.26로 표기한다. 미국도 이와 같이 표기한다. 그러나, 모든 나라가 그런 것은 아니다. 독일이나 스웨덴과 같은 유럽의 몇몇 나라는 점과 쉼표를 바꾸어 쓴다. 즉, 52.934,26으로 표기한다. 스위스와 같은 나라에서는 자릿수 구분을 따옴표로 한다. 즉, 52'934.26으로 표기한다.
통화 (돈)
우리나라의 통화 표기는 ￦35,000.00과 같이 맨 앞에 원 기호(￦)를 쓰거나 맨 뒤에 '원' 이라는 말을 붙인다. 원 이하 단위는 점을 찍어 표시한다. 만약 음수의 금액을 표시할 때는 원 기호 앞에 음수 표시(-)를 한다. 그러나 이것 역시 나라마다 달라서 독일에서는 금액 뒤에 DM(독일 마르크)을 붙인다. 스위스는 금액 앞에 SFr. (스위스 프랑)을 붙이며, 음수의 금액일 경우 SFr. 기호 뒤에 음수 기호를 넣는다.
날짜와 시간
우리나라에서 날짜와 시간을 표시한다면, 1996년 11월 11일 금요일, 오후 11시 11분 11초 와 같이 년, 월, 일, 요일, 오전/오후, 시, 분, 초의 순서로 적는 것이 일반적이다. 미국의 경우는 Friday, November 11, 11:11:11 p.m. 1996과 같은 순으로 적는다. 월, 일, 년 순이다. 독일의 경우에는 Frietag, 11. November 1996, 11:11:11 Uhr와 같은 순으로 표현한다. 일, 월, 년 순이다.
어떤 나라의 경우에는 오전/오후의 12시간제가 아니라 24시간제이다. 우리 나라에서는 연도 표기를 할 때 서기 대신 단기를 쓰는 경우가 있다. 일본에서는 일본 나름대로의 연도 표기를 사용하고 있다. 아시아 권에서는 양력인 그레고리력 대신 그 나라의 음력을 사용하는 경우도 있다.
문자 진행 방향
우리나라의 글은 가로쓰기를 할 때 왼쪽에서 오른쪽으로 진행한다. 일본어나 중국어도 마찬가지이며, 한국어, 일본어, 중국어 등은 세로쓰기를 하는 경우도 있다. 세로 쓰기를 할 경우에는 위에서 아래, 그리고 오른쪽에서 왼쪽으로 진행한다.
그러나 아라비아어와 같은 중동 국가의 글은 오른쪽에서 왼쪽으로 진행하며, 영어의 경우에는 세로쓰기라는 것이 없다. 따라서 우리의 세로쓰기에 영어가 포함된다면 영어는 오른쪽으로 90도 회전한 형태로 표기되어야 한다.
정렬 순서
영어는 알파벳순으로 정렬되어야 한다. 모든 대문자가 모든 소문자보다 앞서야 한다면, ASCII코드로 부호화된 문서에 대해서는 숫자식 정렬과 다를 바 없다. 그러나, 기본 알파벳 이외의 글자들을 사용하는 독일어, 스웨덴어 등이나 액센트 표시가 섞여있는 프랑스어, 서반아어와 같은 경우에는 코드의 순서와 정렬 순서는 동일하지 않다.
한국과 중국 일본의 경우에 있어서도 이와 비슷한 일이 '한자'에서 일어난다. 각자 각국의 발음 순대로 정렬하여야 하기 때문에 유니코드와 같이 통일된 한자 부호화 방식을 사용할 경우 정렬은 별도로 구현하여야 한다.
문장 부호
우리나라 문장부호 규정에서는 마침표로서는 가로쓰기에서는 온점(.) 세로쓰기에서는 고리점(。)을 쓸 것을 권장하고 있다. 또한 인용 부호로써 큰따옴표(" "), 작은 따옴표 (' '), 겹낫표(『』), 낫표(「」) 등을 쓸 것을 권장하고 있다.
일본의 경우는 아예 마침표를 고리점으로 한정하고 있으며, 인용 부호로써 겹낫표와 낫표만을 사용한다. 프랑스어의 경우에는 인용 부호로서 겹각괄호(« »)를 사용하며, 독일어의 경우에는 높이 차이가 나는 따옴표를(„ ") 사용한다.
서반아어는 감탄문의 경우 처음에 느낌표를 뒤집은 부호(¡)로 시작, 느낌표(!)로 끝내며, 의문문의 경우 물음표를 뒤집은 부호(¿)로 시작, 물음표로 끝내는 것이 일반적이다.
Hyphenation
Hyphenation이란 말은 hyphen(-)을 다는 방법이란 뜻으로, 한 글자가 한 음절을 나타내는 우리나라 말에서는 별로 문제가 되지 않는 부분이다.
영어나 기타 서유럽 국가의 언어들은 긴 단어가 문서의 오른쪽 끝에 오면 단어를 적당히 잘라 뒤에 하이픈(hyphen)을 달아주어 잘려진 단어가 원래 한 단어였음을 나타낸다. 그러나 이런 언어들은 여러 개의 글자가 모여야 한 음절을 구성하는 까닭에 아무렇게 자르면 단어를 이해하기가 매우 힘들어 진다. 따라서 단어를 자를 때에는 어디어디에서만 자를 수 있다고 규정하고 있는데, 이를 hyphenation 규칙이라 한다. 영어 사전을 보면 표제어에 hy·phen·ation과 같이 hyphenation 규칙을 표시한다.
영어의 경우에는 철자 변화가 없지만 독일어와 같은 언어의 경우에는 hyphenation을 하면 철자가 변화한다. 예를 들어, Zucker라는 단어가 문장 끝에 걸려서 자를 수 밖에 없게 된다면 Zuk-ker와 같이 철자가 변한다.
입력 방식 및 자판 배열
각 나라의 언어와 문자가 다르다 보니 입력 방식도 다르고 그에 따른 자판 배열도 다르다. 영어의 경우에는 하나의 키 누름이 한 글자를 의미하지만 한글처럼 몇 개의 키 누름이 한 글자를 구성하는 경우도 있다.
우리나라에서도 한글의 입력 방식이 2벌식과 3벌식으로 나누어 지는 것처럼 한 나라 한 언어를 입력하는 방식도 차이가 있을 수 있다. 일본의 경우에는 하나의 키 누름이 하나의 카나 문자를 나타내는 카나 입력이 있는가 하면 일본어 발음을 영어로 입력하는 로마자 입력도 있다.
2.2. 다국어 환경
다국어 환경이란 하나의 환경 안에 여러 나라의 언어를 사용할 수 있는 환경을 말한다. 얼핏 생각하기에는 이와 같은 환경을 갖출 필요가 없을 것이라고 생각하기 쉽다. 그러나, 당장 당신의 외국어 교재를 살펴보라. 그것은 최소한 2개 국어를 동시에 나타내고 있다.
2개 국어를 동시에 나타낸다는 것은 화면에 두 개의 부호화된 문자 집합을 동시에 나타내는 것을 의미한다. 주관식 문제라도 풀 수 있으려면 최소한 같은 자판으로 2개 국어를 입력할 수 있어야 한다.
국제화가 이슈화 되기 전까지만 해도 이와 같은 부분은 전부 개발자의 몫이었다. 따라서, 교육용 소프트웨어나 워드 프로세서, 번역 환경 소프트웨어의 개발자들은 같은 문제를 서로 다른 방식으로 나름대로 풀어 왔었다.
국제화와 현지화는 각 나라 언어의 공통적인 부분과 특징적인 부분을 나누어 구현한다. 언어의 특징적인 부분을 따로 구현한다는 점에서 국제화-현지화는 다국어 환경 구축과 비슷한 절차를 밟는다. 현지화는 기본적으로 국제화 된 프로그램을 한 나라, 한 언어의 환경으로 만든다는 점에서 다국어 환경과는 다르다. 그러나, 두개 이상의 언어 환경이 공존 할 수 있도록 적절히 구현한다면 쉽게 다국어 환경을 구현할 수 있다.
2.3. 자동 번역 환경
자연언어 처리 기술이 발전하면서 어느 정도 간단한 문장에 대해서는 기계번역이 현실성을 가지게 되었다. 그러나, 입력된 문서가 어떤 언어로 되어 있는지, 입력 문서의 전체 문장이 전부 같은 언어인지 모른다면, 현재로서는 기계 번역이 어려운 실정이다. 또한 다국어 환경과 마찬가지로 두개 이상의 언어를 표시하고 입력할 수 있는 능력을 필요로 한다.
다국어 환경은 현재 처리하고 있는 문서의 언어와 국가 정보를 표시하는 것을 요구한다. 그렇지 않으면 한 문서 안에서 여러 언어를 구별하여 처리 할 수 없기 때문이다. 따라서, 이와 같은 요구 조건은 자동 기계 번역 환경 조성에도 도움을 준다.
기계 번역의 발전은 웹에 있어서 온라인 동시통역을 가능하게 할 수 있다.
검색 주제어가 한 언어의 단어로만 제한되지 않고 여러 나라의 언어로 번역되어 검색되는 다국적 검색도 가능해 진다. 물론, 모든 인터넷 문서에 언어 표기가 되어 있다는 전제 하에서 말이다.
2.4. 국제화의 구현
그러면, 실제로 언어·문화적인 특성은 어떤 식으로 구현되었는가? 현재 널리 알려져 있고 웹 브라우져의 기반이 되는 운영체제를 중심으로 알아보자<./p>
UNIX (POSIX)
UNIX의 표준 규정 중 하나라 할 수 있는 POSIX (Portable Operating System Interface)에서는 국제화 요소를 다음과 같이 6가지로 분류하고 이와 관련된 함수와 shell 환경 변수 등을 규정하였다. (POSIX는 후에 ISO-9945로 제정됨으로써 국제 표준으로 정착되었다.)
- LC_CTYPE : 부호화된 문자 집합
- LC_NUMERIC : 숫자 표현 방식
- LC_TIME : 날짜, 시간 표시 형식
- LC_COLLATE : 정렬 순서
- LC_MONETARY : 통화 표현 형식
- LC_MESSAGES : 소프트웨어의 메시지
또한, 기존의 8 비트 문자 집합을 확장한 EUC (Extended UNIX Code)를 사용, 각 나라의 부호화된 문자 집합을 수용할 수 있게 하였다.
X windows/Motif
X windows는 X11R5부터 국제화-현지화 개념이 도입되어 국제화 된 API를 제공하고 있다. X windows의 국제화 부분은 크게 입력 부분과 출력 부분 그리고 로케일 관리 부분으로 나뉜다.
입력 부분은 사용자의 자판 입력을 어떻게 인식해야 하는지 정할 수 있도록 되어 있다. 이 부분은 다시 XIM(X input method) 서버와 IM 라이브러리로 나뉘는데, XIM 서버는 키보드 입력을 해석하는 부분을 담당하고 IM 라이브러리는 응용 프로그램이 입력을 받아들이는 부분이다.
출력 부분은 주로 글자형인 폰트(font)를 어떻게 처리하는가에 집중되어 있다. 주로 해당하는 폰트를 찾고 설정하는 방법과 주어진 문자열을 어떤 폰트로 화면에 출력하는 방법에 대해서 규정하고 있다. 따라서, 해당 문자열의 부호화된 문자 집합을 표시할 수 있는 폰트를 선택하여 화면에 표시함으로써 각국의 언어를 표시할 수 있다.
로케일 관리 부분은 X window 가 탑재된 UNIX에 POSIX의 로케일 관련 함수가 없는 경우를 대비하여 만든 것이다.
MS-DOS/Windows
MS-DOS는 CONTRY.SYS라는 화일에 국가별 특성 정보라는 것을 저장하는데 이것은 현지화의 로케일 같은 개념이다. COUNTRY.SYS는 CONFIG.SYS에서 COUNTRY= 명령이나, NLSFUNC.EXE라는 프로그램을 통해 DOS로 읽혀진다. 문자 집합은 코드 페이지 (code page)라는 이름으로 구별되며, 코드 페이지 지정을 위해 CHCP와 같은 명령들이 준비되어 있다.
Windows 3.1/95/NT등은 제어판(Control Panel)의 국가별 설정(Country) 항목에서 국가별 특성 정보를 설정할 수 있도록 제공하고 있다. X windows의 입력 서버와 마찬가지로 Windows에서의 자판 입력 방식은 IME라는 것을 통해서 받도록 되어 있으며, 응용 프로그램은 단지 IME가 생성해준 부호화된 문자열만을 받는다. 따라서 2벌식 자판의 IME와 3벌식 자판의 IME를 제공하여 사용자의 입력이 2벌식이든 3벌식이던 응용 프로그램은 신경을 쓰지 않아도 된다.
Windows NT에서는 내부 코드로 유니코드를 사용함으로써 많은 국가의 부호화된 문자 집합을 지원한다.
3. 부호화된 문자 집합
국제화와 현지화에 있어서 무엇보다 먼저 해결해야 하는 문제는 각국의 언어를 그들이 사용하는 대로 어떻게 표현할 것인가, 각국의 언어를 나타내고자 한다면 어떤 부분이 공통 부분이고 어떤 부분이 구별해야 할 부분인가, 각국의 언어는 어떻게 구별해야 되는가 였다. 각국의 언어를 그들이 쓰는 그대로 컴퓨터에서 표현한다는 것은 각 언어의 알파벳을 어떻게 부호화 할 것이냐, 쉬운 말로 하면 각 글자를 어떻게 부호화(code)하고 그것들을 서로 어떻게 구분할 것이냐가 문제가 된다.
이것에 대한 방법으로는 여러 종류의 부호를 구분하기 위한 방법인 ISO-2022와 다국어 지원 자체를 목적으로 만들어진 Unicode, 글자의 단위를 1 octet이 아닌 2 또는 4 octet으로 한 ISO-10646 Universal Multiple-Octet Coded Character Set (UCS)등이 있다.
3.1. ISO-2022
ISO-2022의 원래 명칭은 "ISO 7-bit and 8-bit coded character sets - Code extension techniques"로서 7-bit 혹은 8-bit 환경에서 여러 종류의 부호(code)를 같이 사용하거나, 어떤 기계가 현재 입력되는 부호가 무엇인지를 구분하기 위한 방법을 마련해 놓은 것이다. 이것은 ISO-646 "ISO 7-bit coded character set for information interchange", ISO-4873 "8-bit code for information interchange - structure and rules for implementation"의 확장으로서 만들어진 것이다. ISO-2022 국제 표준은 KSC-5620 "정보교환용 부호의 확장법" 국내 표준으로 다시 제정되었다.
그림 1과 그림 2에 ISO-2022에서 사용하는 7-bit, 8-bit환경을 나타내었다. 각각의 문자(character)는 표의 행과 열로 표시하며 (예: 2/0 = SP) 그림에 나타나 있다시피 부호 체계를 크게 제어 문자 집합(control character set)과 그래픽 문자 집합(graphic character set)으로 나누어 생각한다. 특히 1/11 (7-bit 환경) 또는 01/11(8-bit 환경)은 ESC로 지정하며, 2/0 ,7/15, 02/0, 07/15도 각각 SP(space)와 DEL(delete)로 지정하여 다른 부호 집합 (code set)과 구분되어 사용된다.
ISO-2022의 대상이 되는 부호 체계는 2개의 제어 문자 집합과 4개의 그래픽 문자 집합에 지정(designate)될 수 있다. 2 바이트 이상이 한 글자를 이루는 다중 바이트 문자 집합(multiple-byte character set)도 ISO-2022의 대상이 된다. 그 형태를 그림 3에 나타내었으며, 각 이름의 의미는 다음과 같다.
- C0 집합 : 32개의 제어 문자 집합 (0,1열)
- C1 집합 : 32개의 추가 제어 문자 집합 (8-bit 환경에서는 8,9열)
- G0 집합 : 94개의 그래픽 문자 집합 (2~7열); 다중 바이트 문자 집합도 G0에 지정될 수 있다.
- G1, G2, G3 집합 : 94개의 추가 그래픽 문자 집합 (8-bit 환경에서는 G1이 10~15열); 다중 바이트 문자 집합도 G1, G2, G3에 지정될 수 있다.
3.2. ISO-10646과 Unicode
흔히 Unicode로 알려져 있는 ISO-10646 UCS (원명: ISO/IEC-10646:1993 Universal Multiple-Octet Coded Character Set, 이하 ISO-10646이라 칭한다.) 는 4바이트로 한 문자를 나타냄으로써 보다 일반적인 문자 처리가 가능한 문자 집합과 그 부호화를 정의한다.
Canonical form과 BMP
ISO-10646은 문자 집합의 보다 일반적인 적용을 위해서 canonical form이라는 개념을 사용한다. 각 문자는 문자들끼리 서로 구분되기 위해 4 옥텟 의 16진수 이름을 갖게 되는 데, 이것을 canonical form이라 한다. 각 문자는 실제로 사용되기 위해 canonical form으로부터 적당한 방법으로 부호화 될 수 있다.
이것은 ISO-2022와 같은 종전의 문자 표준이 코드 영역에 직접 문자를 대응함으로써 문자 체계 자체에 제약이 주어진 것과는 달리, canonical form으로 문자 집합을 정해 놓고 그 사용 환경에 따라 부호화 하는 방법을 바꿈으로써 코드 사용 환경이 바뀌더라도 문자 집합 자체는 변경되지 않도록 한 것이다.
Canonical form의 부호 영역이 그림 5에 나타나 있다.
한 문자는 4바이트의 이름을 가지며, 각 옥텟은 그룹, 평면, 행, 셀의 의미를 가진다. 이 중에서 특히 그룹 00, 평면 00인 부분을 BMP(Basic Multilingual Plane)라 부른다. 현재 ISO-10646에서 문자가 실제로 할당된 부분은 BMP 뿐이다.
BMP는 다시 4개의 영역으로 나누어 지는데 각 영역의 특징은 다음과 같다.
- A-zone: alphabetic and syllabic scripts together with various symbols
- I-zone: Chinese/Japanese/Korean (CJK) unified ideographs (unified East Asian ideographs)
- O-zone: reserved for future standardization
- R-zone: restricted use zone (private use characters, presentation forms, compatibility characters, etc.)
Canonical form은 그 자체로서 하나의 32-bit 부호화가 될 수 있는데 이것을 UCS-4라 한다. BMP역시 그 자체로서 16-bit 부호화가 될 수 있는데 이것을 UCS-2라 한다.
UCS Transformation format (UTF)
ISO-10646은 현재의 기술 상황을 고려하여 한 글자를 4-octet으로 표현하도록 하였다. 그러나 현재 환경은 한 글자를 한 바이트로 가정하고 있고, 또한 그 가정을 기반으로 한 표준들도 있는 상황이다. (대표적인 예 ISO-2022) 따라서, ISO-10646에서 규정한 문자 집합을 실제로 사용하려면 어느 정도의 변환이 필요하다. 이것은 UTF(UCS Transformation format)이라 한다.
현재 제정되었거나 제정되고 있는 UTF들은 다음과 같다.
UTF-1
ISO-2022에서 사용을 금하고 있는 C0, SPACE, DEL, C1 문자들을 사용하지 않도록 부호화 하는 방법이다. ISO/IEC-10646:1993의 Annex G로 포함되어 있다.
UTF-7
인터넷 메일과 같은 7 비트 ASCII 문자 전송을 원칙으로 하는 환경에서 사용하도록 고안되었다. 특히 US-ASCII에 해당하는 글자들은 변환을 해도 사람이 읽을 수 있도록 고안되었다. RFC-1642로 등록되어 있다.
UTF-8 (UCS Transformation Format 8-Bit Form)
이것은 FSS-UTF(File System Safe Universal Character Set Transformation Format)이라고도 불린다.
UNIX의 대표적인 화일 시스템인 UFS와 같은 화일 시스템에서, ISO-10646 문자 집합을 화일 이름 또는 화일의 내용으로 사용하려면 ASCII 코드로 봤을 때 NUL(0x00)문자나 slash(/)문자에 대한 처리가 필요하다. 또한 C언어의 문자열로서 사용하려면 중간에 NUL이나 backslash 문자가 포함되어서는 곤란하다. 이와 같은 문제를 해결한 것이 UTF-8이다.
이것은 ISO/IEC JTC1/SC2/WG2 N 1036 Amendment 2 to ISO/IEC 10646-1:1993 UCS Transformation Format 8 (UTF-8)으로 제출되어 ISO-10646의 다음 버전에서 Annex P에 포함될 예정이다.
UTF-16 (Transformation Format for 16 Planes of Group 00)
초기에는 UCS-2E(Extended UCS-2)라고 불렸다.
ISO-10646은 원칙적으로 4 옥텟이 한 글자이므로, 16비트를 한 글자로 잡는다 하더라도 ISO-10646의 문자 집합을 제대로 사용한다고 볼 수 없다. 따라서 BMP이외의 평면을 사용할 경우를 고려하여 고안한 것이 UTF-16이다.
현재 ISO/IEC JTC1/SC2/WG2 N 1035 Amendment 1 to ISO/IEC 10646-1:1993 Transformation Format for 16 Planes of Group 00 (UTF-16)로 제출되어 있다.
Unicode와 ISO-10646의 관계
ISO 10646은 국제표준기구 (ISO; International Standard Organization) 와 국제 전자 기술 위원회 (IEC; International Electrotechnical Commission) 의 산하 위원회인 ISO/IEC JTC 1 (Information Technology) SC 2 (Coded character sets) WG 2에서 제정 중이던 국제 표준이었다.
그에 비하여, Unicode는 Apple, Metaphor, RLG, Sun, Xerox등이 1989년에 결성하여 만든 Unicode Working Group에서 제정한 것으로, 컴퓨터에서 쉽게 지원해 줄 수 있는 다국어 지원을 목적으로 제정하던 업계 표준이었다.
1991년 Unicode Working Group은 Unicode, Inc.로 조직체계를 바꾸고, 지지부진하고 있는 ISO-10646의 다국어 부분을 Unicode사에서 제정하는 표준을 그대로 사용할 것을 국제표준기구에 제안하였다. 결국, ISO-10646의 BMP부분은 Unicode와 동일한 내용을 가질 것을 결의하였다.
간단히 말해서, ISO-10646중에서 UCS-2 BMP부분은 Unicode와 동일하다.
4. 한글 문자 집합
본 절에서는 95년 11월 현재까지 제안된 한글 부호화 체계를 정리 나열하고, 국제 표준인 ISO-2022, ISO-10646과의 관계를 설명한다.
4.1. KSC-5601
1987년 한국 공업진흥청에서 국가 표준으로 정한 코드로, 원래 명칭은 "KSC-5601 정보교환용 부호 (한글 및 한자)"이다. KSC-5601은 정보교환용 부호 기본 집합 (완성형) 과 보조 집합 (조합형), 그리고 n-byte형 7-bit코드를 규정한다. 여기서는 기본 집합에 대해서만 언급하겠다.
KSC-5601 정보교환용 부호의 부호 영역은 0xA1A1~0xFEFE로 ISO-2022를 만족한다. 0xA1A1~0xACFE에는 부호 및 일본/러시아 글자를 0xB0A1~0xC8FE에는 한글을 0xCAA1~0xFDFE까지는 한자를 배치하였다. 여기서 한글은 자주 쓰이는 2232자를 골라 가나다 순으로 배치하였고, 한자 역시 그러하였다. 2232자에 포함되지 않은 한글에 대해서는 '채움'(0xa4d4)으로 시작하여 초성,중성,종성에 해당하는 글자를 배치함으로써 나타나도록 하였다.
KSC-5601의 ISO-2022 지정(designate) sequence는 ESC 2/4 2/9 F로 F는 4/3이다. (ESC $ ) C) 7bit환경일 경우 호출(invoke)은 SO로 한다.(^N)
4.2. KSC-5657
KSC-5601로는 부족한 부호, 문자, 한글, 한자 등을 추가하기 위해서 제정되었다. KSC-5601과 혼용하여 쓰는 방법은 "KSC-5620 정보교환용 부호의 확장법" 즉 ISO-2022를 따른다. KSC-5657의 ISO-2022 지정 sequence는 ESC 2/4 2/9 F로 F는 제 1 확장 세트일 경우에는 4/5 (E), 제 2 확장 세트일 경우에는 4/6 (F)이다.
4.3. Microsoft의 통합형 한글
기존의 KSC-5601을 사용하면 2바이트로 표현 가능한 한글의 글자수가 2350자로 제한된다. KSC-5601을 기본 코드로 한 Microsoft사의 Windows 운영체제로는 이와 같은 한글 표현의 문제가 생긴다. 따라서, 2byte로 표현할 수 있는 한글의 수를 늘리면서, 기존의 KSC-5601을 기반으로 짜여졌던 프로그램도 그대로 사용할 수 있는 방안으로서 제시한 것이 Microsoft사의 통합형 한글 코드(초기에는 확장 완성형이란 이름으로 발표했음)이다.
그림 7에서 보다시피 확장 완성형은 기존의 KSC-5601 코드 영역을 그대로 두고 0x8141~0xC6FE에 해당하는 부분 중 KSC-5601에 포함되지 않는 부분에 KSC-5601로는 두 바이트로 표시할 수 없는 한글 문자들을 가나다순으로 배치하였다.
이것은 어떤 표준 규정과도 연관이 없다는 것이 특징으로, Microsoft사 자체 내에서 임시적으로 사용하기 위해 제정된 것으로 알려져 있다.
4.4. 첫가끝 코드
동국대의 변정용 교수는 '정음형', 부산대의 김경석 교수는 '첫가끝'이라고 부르는 이 코드는, 옛 한글과 현대 한글에서 나타날 수 있는 한글의 초성, 중성, 종성의 자모 요소를 한 글자(Unicode BMP의 경우 2 바이트)로 나타내도록 부호화하고, 이 자모들을 초성(첫소리), 중성(가운뎃소리), 종성(끝소리)의 순서대로 한글을 표현하는 방식이다.
초성, 중성, 종성의 자모를 부호화 했으므로 'ㅩ'이나 'ㆌ'과 같은 글자를 한 글자(자모)로 한다. 이 이외에 '초성 채움'과 '중성 채움'의 두 글자가 추가되어 초성 없는 중성과 받침 등의 글자 등도 표현할 수 있다. 받침이 없을 경우 종성은 나타내지 않으므로 '종성 채움'은 필요 없다.
이것은 ISO/IEC-10646:1993에 채택되어 제 24 장 Hangul syllable composition method에서 규정하고 있다.
4.5. 국제 문자 부호계 한글 (KSC-5700)
이것은 Unicode 2.0에서 추가된 한글 표현 방법으로, 조합될 수 있는 현대 한글 글자 모두를 가나다 순으로 정렬, 배치한 것이다. 현대 한글이 사용하는 자모는 초성 19자, 중성 21자, 종성 27자로, 조합 가능한 글자의 수는 19 x 21 x 28 (종성 없음 포함) = 11172자 이다.
이 코드의 조합 방법을 그림 8에 나타내었다.
이 코드의 조합 방법을 수식으로 나타내면 다음과 같다.
4.6. ISO-2022와의 관계
KSC-5601과 KSC-5657은 ISO-2022환경에서 사용할 수 있다. 다른 부호 체계에서KSC-5601부호 체계를 사용하려면 "ESC $ ) C"의 4자의 지정 문자열을 보내고 사용하면 되며, KSC-5657의 제 1 확장 세트는 "ESC $ ) E", 제 2 확장 세트는 "ESC $ ) F"의 지정 문자열을 보낸 후 사용하면 된다.
4.7. ISO-10646과의 관계
ISO/IEC-10646:1993에는 KSC-5601, 5657에서 사용하던 부호, 한글, 한자 등을 모두 포함되어 있다. 또한 첫가끝 한글 방식이 추가되어 있다.
KSC-5601에서 사용하던 부호와 문자는 BMP의 부호와 문자 부분에 포함되었으며,한자 부분도 한중일 통합 한자 부분인 "CJK Unified Ideographs" (u4E00~u9EFF)에 포함되었다. 한글 부분은 u3400부터 KSC-5601의 순서 그대로 배치되었다.
KSC-5636의 한글 부분은 KSC-5601 한글 부분의 배치가 끝나는 u3D2E부터 순서대로 배치되었다. KSC-5636 한글의 배치가 끝나는 u44B8부터는 앞의 두 한글 부분에 포함되지 않으면서 비교적 빈번히 사용되는 한글을 u4DFF까지 배치하였다.
첫가끝 한글의 요소인 한글 자모는 "Hangul Jamo"(u1100~u117F)에 배치되었으며, 그 조합 원리는 제 24 장에 설명되었다. 첫가끝 한글의 자모와는 다른 KSC-5601의 한글 자모 문자 (KSC-5601에서 0xA4A1~0xA4FF)는 "Hangul Compatibility Jamo" (u3131~u318E)에 배치되었다.
5. WWW 국제화 활동
anuel Tomas CARRASCO BENITEZ와 웹의 국제화에 관심 있었던 몇몇 사람들은 WWW 국제화에 관한 BOF(Birds of a feather; 관심 있는 사람들의 모임)를 1995년 4월 독일에서 열렸던 제 3회 국제 WWW 학술대회(International WWW Conference)에서 열고, WInter (Web Internationalization and Multilingualism) 페이지를 제작하기 시작한다.
같은 해 12월 미국 보스턴에서 열렸던 제 4 회 국제 WWW 학술대회에서 마찬가지로 BOF를 소집 WWW국제화에 대한 요구가 있음을 확인하고, 제5회 국제 WWW 학술대회에서는 Internationalization Workshop을 열기에 이른다.
WWW기술의 발전과 표준화에 노력하고 있는 WWW Consortium (이하 W3C)에서는 Internationalization Workshop이후 본격적으로 WWW의 국제화에 참여한다.
90년대 초반에 국제화-현지화의 문제를 논의하기 위해 기업체들이 모인 LISA(Localization Industry Standards Association)이 WWW 국제화에 참여하게 된다.
6. WWW의 국제화
6.1. HTTP
HTTP는 제정 초기부터 여러 나라말로 되어있는 문서에 대한 고려를 하는 등, 비교적 국제화를 위한 노력이 많이 진행되어 왔다. 현재 국제화와 관련된 부분은 content negotiation의 하나인 language negotiation 부분과 text/html MIME type에서 charset parameter을 사용하는 부분이다.
MIME text/html charset parameter
RFC-1866에서는 HTML의 MIME type을 text/html로 규정하고, 그의 argument로서 charset과 level이 올 수 있다고 정했다. charset의 값은 text/plain type에서 사용하는 것과 동일하다고 규정했다.
RFC-1945로 제정이 종료된 HTTP/1.0에서는 다음과 같은 charset을 선호하는 방향으로 text/* MIME type의 charset 사용을 허용하고 있다.
charset = "US-ASCII"
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
| token
또한, HTTP/1.0에서는 default 문자 집합을 ISO-8859-1로 규정함으로써, WWW Browser는 유럽 국가들의 언어를 표현 할 수 있어야 한다는 제약 조건을 갖게 되었다.
이 방법은 한 문서의 부호화를 한 부호 체계로 한정하기 때문에 Unicode나 ISO-2022-JP-2를 사용하지 않는 한 문서에 한 나라말만을 쓸 수 밖에 없다는 단점이 있다.
HTTP/1.1의 Accept-Language
HTTP는 클라이언트의 Request와 서버의 Response로 구성된다. 클라이언트의 Request중에서 Accept-Language라는 헤더가 있다. 이것에는 클라이언트가 해석 가능한 자연언어들의 목록을 실어서 보내게 되는데, 이 헤더를 받은 서버는 가능한 언어를 골라 Response의 Content-Language 헤더에 표시하여 보낸다. Accept-Language나 Content-Language 헤더에 들어가는 언어 표기법은 RFC-1766 "Tags for the Identification of Languages"을 따른다.
이 방식은 하나의 URL에 대해서 여러 언어로 작성된 문서를 준비할 수 있고 또한 client의 요구에 따라 문서의 언어를 선택 할 수 있는 반면, 실제로 그 문서가 어떤 문자 집합으로 부호화 되어 있는지를 나타내지 않는다는 면에서 이 방식 하나만으로 사용하기에는 문제가 있다.
HTTP/1.1의 300 Multiple Choices
같은 URL에 여러 종류의 객체가 존재할 경우가 있다. 예를 들면 서로 다른 나라 말로 쓰여져 있는 안내문일 경우 모두 / 이라는 URL로 불릴 수 있다.
HTTP/1.1에서는 요청받은 URL에 둘 이상의 객체가 존재하고, 클라이언트가 보내온Accept-XXX헤더로 결정이 안 날 경우 300 Multiple Choices로 반환하도록 규정하고 있다.
6.2. HTML
HTML의 기본 문자 집합
HTML의 표준이 95년 11월 RFC-1866이란 문서로 확정되었다. 이 문서에서는 HTML의 부호화된 문자 집합을 ISO-8859-1과 ISO-10646으로 규정하고 있다. 얼핏 보기에는 HTML이 ISO-10646으로 쓰여져야 한다고 규정하는 것 같다. 그러나, 이것은 단지 character repertoire를 ISO-10646으로 제한하고 있는 것으로 ISO-10646에 포함되지 않은 글자들은 표현할 수 없다고 규정하고 있을 뿐이다
HTML의 부호화된 문자 집합 명시
HTML에서는 문서가 어떤 부호화된 문자 집합으로 쓰여졌는지를 나타내지는 않는다. 그러나, HTTP의 Content-Type헤더를 META 태그로 지정해 줌으로써 부호화된 문자 집합을 지정해 줄 수 있다. 예를 들어, KSC-5601로 쓰여진 HTML문서에는 HEAD 부분에 다음과 같은 META 태그를 추가함으로써 이 문서가 KSC-5601로 쓰여져 있음을 나타낼 수 있다.
<META HTTP-EQUIV="Content-type" VALUE="text/html; charset=euc-kr">
HTML국제화
F. Yegau가 제출한 HTML 국제화 Internet Draft에는 SPAN, Q 등의 새로운 태그들과 LANG, DIR, ALIGN등의 새로운 속성이 추가되었다.[HTML-I18N]
LANG속성은 쓰여진 언어가 어떤 언어인가를 나타내는 것으로, RFC-1766의 규칙에 따라 표기된다. LANG은 P, IMG, FORM 태그 등에 붙어서 해당 부분이 어떤 언어인지를 표시한다. DIR 속성은 문장의 진행 방향을 나타내는 속성으로 기본값은 왼쪽에서 오른쪽을 의미하는 LTOR 이다. 아랍어와 같은 언어에서는 반대인 RTOL이 된다. ALIGN 속성은 원래 HTML 2.0에 포함되어 있던 속성이다. HTML국제화에서는 ALIGN의 값에 JUSTIFY를 추가하여, 우리나라 공문서와 같이 좌우가 나란한 정렬 방식을 지정할 수 있게 하였다.
SPAN태그는 HTML 국제화에서 추가된 속성들을 쓰기 위한 태그로 그 자체로는 의미가 없다. Q 태그는 인용 부호를 나타낸다. (2.1절 문장부호 참조)
한자의 발음 적기 - Ruby
Martin J. Dürst는 일본어의 후리카나(한자 위에 카나로 발음을 적어 한자의 일본어 발음을 적는 것)를 표현하기 위해 RUBY라는 속성을 제안하였다. [RUBY]
예를 들어 다나까(田中)를 표현한다면 다음과 같이 할 수 있다.
<SPAN RUBY="たなか">田中</SPAN>
이와 같이 표현된 내용은 다음과 같은 형태로 화면에 나타난다.
たなか
田中
Hyphenation
Peter Svanberg와 Olle Jarnefors는 TEX의 \discretionary 함수를 본떠서 HYPH 태그를 제안하였다. HYPH 태그의 형식은 <HYPH BEF= "before_linebreak_string" AFT= "after_linebreak_string" >no_linebreak_string </HYPH>으로 독일어와 같이 Hyphenation 이후 철자가 바뀌는 경우에도 처리할 수 있도록 하였다. 예를 들어 Zucker는
Zu<HYPH BEF="k-" AFT="k">ck</HYPH>er
와 같이 표현 할 수 있다. (2.1절 Hyphenation 참조)
6.3. URI
URL과 URI에는 문자 집합의 개념이 없다. 단지 US-ASCII에 해당하지 않는 글자는 '%' + hexadecimal code의 형태로 부호화된 형태로 전달 할 수 있을 뿐이다. 따라서 클라이언트에서는 한글을 의도하고 부호화 한 것을 서버에서는 일본어로 인식할 수 있다.
이러한 문제는 CGI에서 확실하게 나타난다. CGI의 입력으로 들어오는 문자열이 어떤 문자 집합인지 알 수 없으므로 잘 못 처리될 수 있다. POST를 통한 FORM의 입력에도 application/x-www-form-urlencoded IME type은 부호화 부분에서 동일한 처리를 하므로 의미가 없다.
따라서, CGI를 위한 FORM 입력은 RFC-1867 Form-based File Upload in HTML에서 제안한 multipart/form-data로 입력할 것을 권고하고 있다. multipart/form-data는 한 개 이상의 다른 MIME type을 포함시킬 수 있으므로 적당한 Content-Type과 charset parameter으로 입력할 수 있기 때문이다.
6.4. CSS
CSS는 Cascading Style Sheet의 약자로 HTML을 화면상에 어떻게 표시할 것인지 나타내는 formatting 정보를 나타내는 언어이다. HTML의 어떤 부분 혹은 class를 어떤 크기와 색깔의 어떤 폰트로 어떤 식으로 Layout을 만들어 내라는 식으로 나타낸다.
현재 CSS level 1 규격이 발표되어 있으나, 아직 국제화에 대한 고려는 되어있지 않다. 그러나 세로쓰기라던가 그 밖의 문화적인 Layout 형태에 대한 고려의 필요성을 느끼고 있는 상황이다.
6.5. Fonts
부호화된 문자 집합은 문자를 부호로서 기억하고 나타내지만, 실제로 사람의 눈이 문자를 인식하게 하는 것은 글자형, 즉 폰트이다. 현재로서는 Type 1과 같은 기존의 폰트 규격과 이름을 그대로 사용하고 있는 실정이다.
기존의 영어나 로마자 폰트들은 많은 종류가 개발되어 필요에 따라 선택할 수 있으나 우리나라와 같은 경우 폰트 이름조차 확실히 정해지지 않은 실정이다. 또한,한중일 세 나라의 언어는 한 폰트 안의 글자수를 많이 필요로 하는데, 이것 때문에 전송 방법이나 저장 방법에 대해서도 고려하려는 노력이 있다.
6.6. 부호화된 문자 집합
위의 HTML이나 HTTP에서 언급하였던 바와 같이 기본적으로는 ISO-8859-1을 기본 부호화된 문자 집합으로 하고, 몇 개의 별도 문자 집합을 사용할 수 있도록 하고 있다. 그러나 한 문장 안에서 여러 나라의 언어를 사용하려면, 현재로서는 ISO-10646에 UTF-8 혹은 UTF-7로 부호화된 형태로 사용하여야 한다.
참고 문헌
[HTML-I18N] Yergeau F., Nicol G., Adams G., and Duerst M., "Internationalization of the Hypertext Markup Language", Work in progress (draft-ietf-html-i18n-05.txt), 7 August 1996.
[HTTP1.1] Fielding, R., Gettys, J., Mogul, J. C., Frystyk, H., Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1", Work in progress (draft-ietf-http-v11-spec-07.txt), August 12, 1996
[ISO-2022] International Organization for Standardization (ISO), "Information processing -- ISO 7-bit and 8-bit coded character sets -- Code extension techniques", International Standard, 1986, Ref. No. ISO 2022-1986 (E).
[ISO-8859] International Organization for Standardization (ISO), "Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.", International Standard
[ISO-10646] International Organization for Standardization (ISO), "Information Technology--Universal ultiple-octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane", International Standrd, 1993, Ref No. ISO/IEC 10646-1:1993(E)
[RFC-1468] Murai, J., Crispin, ., and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC 1468, Keio University, Panda Programming, June 1993.
[RFC-1521] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
[RFC-1554] Ohta M., Handa K., "ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP", RFC 1554, Tokyo Institute of Technology, ETL, December 1993.
[RFC-1557] Chon K., Park H. Je, Choi U., "Korean Character Encoding for Internet Messages", RFC 1557, KAIST, KAIST, Solvit Chosun Media, December 1993
[RFC-1630] Berners-Lee T., "Universal Resource Identifiers in WWW", RFC 1630, CERN, June 1994.
[RFC-1641] D. Goldsmith, and . Davis, "Using Unicode with MIME", RFC 1641, Taligent, Inc., July 1994.
[RFC-1642] D. Goldsmith and . Davis, "UTF-7 -- A Mail-Safe Transformation Format of Unicode", RFC 1642, Taligent, Inc., July 1994.
[RFC-1738] Berners-Lee T., asinter L., and McCahill M., "Universal Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of innesota, December 1994.
[RFC-1766] Alvestrand H., "Tags for the Identification of Languages", RFC 1766, 03 February 1995.
[RFC-1866] Berners-Lee T., Connolly D., "Hypertext Markup Language - 2.0", RFC 1866, MIT/W3C, November 1995
[RFC-1945] T. Bernets-Lee, R.T. Fielding, and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC1866, MIT/LCS, UC Irvine, MIT/LCS, May 1996.
[RUBY] Duerst, M., "Ruby in the Hypertext Markup Language", Work in progress (draft-duerst-ruby-01.txt), University of Zurich, 30 August 1996
[UNICODE 1.1] "The Unicode Standard, Version 1.1": Version 1.0, Volume 1 (ISBN 0-201-56788-1), Version 1.0, Volume 2 (ISBN 0- 201-60845-6), and "Unicode Technical Report #4, The Unicode Standard, Version 1.1" (available from The Unicode Consortium, and soon to be published by Addison-Wesley).
[UTF-8] X/Open Company Ltd., "File System Safe UCS Transformation Format (FSS_UTF)", X/Open Preliminary Specification, Document Number: P316. This information also appears in Unicode Technical Report #4, and in a forthcoming annex to ISO/IEC 10646.