HTML 유니코드의 UCS와 UTF
페이지 정보
본문
* ISO 10646(UCS=Universal Character Set) = Unicode
유니코드는 31비트 문자세트이다. 그러나 현재 계획상으로는 21비트 안에서 모두 표현된다. 또한 과학자들을 위한 특수한 문자를 제외한 각 세계 각 국가의 문자들은 하위 16비트의 영역 안에 정의되어 있다. 이를 BMP(Basic Multilingual Plane)이라고 한다.
유니코드도 모든 글자를 하나의 코드만으로 표현하는 것은 아니다. 즉, 두 개 이상의 유니코드 문자 코드가 조합되어 하나의 문자를 정의하는 경우도 있다. (MBCS와 유사하다.)
유니코드는 매우 복잡한 체계이기 때문에 구현의 단계를 나누어서 필요한 만큼만 구현하도록 하였다. 1단계 구현 레벨에서는 조합 코드까지 지원하지 않아도 된다. 2단계 이상을 지원하는 고급 응용프로그램에서는 조합 코드도 사용할 수 있다. 3단계는 최종 단계로서 수학적 표현도 지원하는 것이다. 보통의 국제화된 응용프로그램은 2단계로 충분하다.
유니코드 문자 코드는 "U-0000007F"와 같이 "U-"를 붙여서 표현한다. 최대 U-7FFFFFFF까지 정의될 수 있다. 하위 16비트까지만 표현할 때는 "U+007F"와 같이 "U+"를 붙여서 표현한다. U+0000부터 U+7FFF까지 정의되어 있다.
* ISO-2022
유니코드 이전에는 문자 코드를 1바이트 단위로 저장하였다. 예를 들어 US-ASCII 문자 세트는 8비트 범위 안에서만 표현되기 때문에 1바이트인 char 데이터형에 온전히 저장할 수 있다. 하지만, 한글과 일본어 등은 8비트 범위 안에서 표현하지 못하기 때문에 ISO-2022의 규정에 따라서 두 개의 이상의 바이트에 나누어 넣는 방식을 사용한다.
이 표준은 1바이트 문자열 안에서 8비트보다 큰 문자 세트를 표현하기 위해서 제정된 것이다. 즉, 흔히 알고 있는 대로 바이트의 최상위 비트가 1일 경우에는 그 뒤의 바이트와 합하여 하나의 글자를 나타낸다는 것을 정의하고 있다. (또한 합쳐지는 모든 바이트의 최상위 비트도 1이어야 한다. MS의 이른바 확장 완성형은 이런 규정을 무시하고 있지만...)
이 표준은 두개 혹은 그 이상의 바이트를 합칠 수 있도록 허용하고 있으나 대부분은 두 개의 바이트만을 조합하고 있다. 이와 같이 하나의 글자를 표현할 때 여러 바이트가 조합될 수 있는 문자 세트를 MBCS(Multi-Byte Character Set)이라고 부른다. US-ASCII 처럼 1바이트만으로 표현되는 경우는 SBCS(Single Byte Character Set)이라고 한다.
* UCS-2와 UCS-4
유니코드를 메모리나 파일에 기록하는 방법에 대해서 표현할 때는 UCS-2, UCS-4 등으로 나누어진다. UCS-2는 16비트 정수를 사용하여 유니코드 31비트 문자세트 중에서 16비트 이하의 부분만을 표현하고 UCS-4는 32비트 정수를 사용하여 31비트의 모든 유니코드 영역을 표현한다.
또한 유니코드가 정수에 저장될 때 메모리나 디스크에 배치되는 바이트 순서에 따라 little endian과 big endian으로 구분한다. 또, 시스템 자체의 endian 규칙에 부합하면 internal, 아니면 swapped라고도 한다. 보통 메모리상에서는 시스템 내부적인(internal) endian으로 처리하다가 파일에 저장할 때는 필요에 따라 big endian이나 little endian으로 보정하여 저장하는 것이 일반적이다.
UCS-2, UCS-4는 유니코드를 저장하는 변수의 크기를 정의하였지만, 바이트 순서에 대해서 표준화하지 못하였다. 따라서 실제로는 UCS-2-LE, UCS-2-BE와 같이 여러 저장 방식이 혼재할 수 있는 문제점이 있다. 일반적으로 보자면 UCS-2를 파일에 저장할 때는 big endian을 많이 사용하지만, MS처럼 little endian으로 저장하는 소프트웨어 제작사도 있다. (ISO-2022와 같은 표준에서 big endian이라고 명시한 것과는 대조적이다.)
위와 같은 endian 이슈와 함께 대개의 파일 처리 프로그램 들이 바이트 단위로 동작하는 특성에 UCS는 잘 맞지 않았다. 즉, 파일을 인식할 때 이 파일이 UCS-2, UCS-4인지 US-ASCII 또는 ISO-2022인지 인식하고 각각의 경우를 구분해서 모두 다르게 구현해야 하는 문제가 생긴 것이다. cat과 같은 간단한 프로그램들 마저도 모두 다 다시 만들어야 한다면 그 비용은 너무나 클 것이다. 이런 이유로 유니코드를 사용하는 파일이 보다 널리 사용되기 위해서 여러가지 방법이 논의되기 시작하였다.
* UTF-8 (ISO 10646-1:2000 Annex D, RFC 3629)
UTF에 대한 논의의 결과물로 UTF-1, UTF-7 등을 거쳐 UTF-8이 제정되었다. 오늘날 유니코드를 파일에 저장하는 방식은 UTF-8이 가장 일반적이다. UTF-8은 MBCS(ISO-2022)와 비슷하지만 더욱 정교한 방법으로 31비트의 유니코드를 1~6개의 바이트에 나누어 저장하는 방식이다. 첫번째 바이트를 읽는 것 만으로 몇 개의 바이트로 구성된 것인지 알 수 있기 때문에 상당히 정교하다. 그리고 하위 16비트만 표현할 때는 최대 3바이트로 충분하다. UTF-8에서 상위 아스키 코드 영역은 1바이트로 표현될 수 있고 한글은 대개 3바이트를 차지한다.
마이크로소프트는 텍스트 파일의 맨 앞에 UCS-2/4 및 endian을 표시하는 BOM(Byte-Order Mark)라는 특정한 코드를 넣어서 구분하자고 주장하였으나 Unix와 같은 운영체제에는 잘 맞지 않는 방식이었다. Windows NT 4.0 이후로 MS는 UCS-2 형식의 파일을 기본적으로 사용할 수 있었으나 그리 많이 이용되지는 않았고, 최근에 UTF-8이 널리 사용되면서 MS도 UTF-8을 기본적으로 지원하고 있다.
UTF-8은 바이트 단위로 읽혀질 수 있기 때문에 기존의 ISO-2022을 기준으로 작성된 응용프로그램들과 호환성이 높다. 예컨데 UCS-2 문자열은 unsigned short 배열에 저장되어야 하지만, UTF-8 문자열은 기존의 응용프로그램 처럼 char 배열에 저장될 수 있다.
* UTF-16 (ISO 10646-1 Annex Q, RFC 2781)
UTF-8은 UTF-8과 는 다른 관점에서 생긴 것으로서 UCS-2 문자열 안에 유니코드의 21비트 영역의 문자를 표현하기 위해서 도입된 것이다. UCS-2는 U+D8000~U+DFFF 영역을 정의하고 있지 않은데, UTF-16은 이 영역을 응용하여 두 개의 UCS-2 코드를 조합함으로써 16비트 위의 21비트까지 표현할 수 있도록 하였다. 즉, UTF-16이란 UCS-2의 확장이라고 할 수 있다. UTF-16 문자열을 입력 받을 때 보통의 UCS-2 응용프로그램은 이 영역의 코드를 무시하거나 오류를 내겠지만 UTF-16 응용프로그램은 제대로 21비트의 모든 유니코드를 인식할 수 있게 된다.
UTF-16도 UCS-2의 특성을 똑같이 가지고 있기 때문에 파일 저장을 위해서 사용되지는 않을 것이다. UTF-16은 UCS-2만을 지원하는 응용프로그램이 UCS-4로 확장하기 위해서 선택할 수 있는 방법이라고 할 수 있다. 현재 마이크로소프트 Windows 플랫폼은 UCS-2만을 지원하고 있는데, 앞으로 전체 유니코드를 지원하기 위해서 UCS-4로 바꾸기 보다는 UTF-16로 전환하는 것이 기존 소프트웨어와의 호환성을 유지하면서 확장하는 방안이라고 할 수 있다.
* UTF-32
UTF-32는 앞의 UTF-8과 UTF-16과는 달리 UCS-4를 그대로 32비트 정수에 담는 것을 정의하고 있다. 즉, UCS-4와 똑같은 것이다. 하지만, UCS-4는 부분적으로 변화의 여지가 있고 논의가 진행되고 있다. (반면 UCS-2는 확정되어 있다.)
그래서 UTF-32는 변화하지 않는 21비트 영역만으로 한정해 놓았다. 즉, UTF-32는 21비트 그 이상의 부분은 사용하지 않도록 한정해 놓아서 UCS-4의 상위 부분이 변화하는데 따른 혼란을 피한 것이다. 소프트웨어의 입장에서는 아직 UCS-4를 사용할 수는 없다 (고정된 것이 아니므로), 대신 당분간은 UTF-32를 사용해야 한다. 앞으로 21비트 이상의 부분이 확정이 되면 새로운 UTF가 나오겠지만, 그런 날이 과연 언제나 올런지 알 수 없다.
<출처> http://blueb.net/blog/123
유니코드는 31비트 문자세트이다. 그러나 현재 계획상으로는 21비트 안에서 모두 표현된다. 또한 과학자들을 위한 특수한 문자를 제외한 각 세계 각 국가의 문자들은 하위 16비트의 영역 안에 정의되어 있다. 이를 BMP(Basic Multilingual Plane)이라고 한다.
유니코드도 모든 글자를 하나의 코드만으로 표현하는 것은 아니다. 즉, 두 개 이상의 유니코드 문자 코드가 조합되어 하나의 문자를 정의하는 경우도 있다. (MBCS와 유사하다.)
유니코드는 매우 복잡한 체계이기 때문에 구현의 단계를 나누어서 필요한 만큼만 구현하도록 하였다. 1단계 구현 레벨에서는 조합 코드까지 지원하지 않아도 된다. 2단계 이상을 지원하는 고급 응용프로그램에서는 조합 코드도 사용할 수 있다. 3단계는 최종 단계로서 수학적 표현도 지원하는 것이다. 보통의 국제화된 응용프로그램은 2단계로 충분하다.
유니코드 문자 코드는 "U-0000007F"와 같이 "U-"를 붙여서 표현한다. 최대 U-7FFFFFFF까지 정의될 수 있다. 하위 16비트까지만 표현할 때는 "U+007F"와 같이 "U+"를 붙여서 표현한다. U+0000부터 U+7FFF까지 정의되어 있다.
* ISO-2022
유니코드 이전에는 문자 코드를 1바이트 단위로 저장하였다. 예를 들어 US-ASCII 문자 세트는 8비트 범위 안에서만 표현되기 때문에 1바이트인 char 데이터형에 온전히 저장할 수 있다. 하지만, 한글과 일본어 등은 8비트 범위 안에서 표현하지 못하기 때문에 ISO-2022의 규정에 따라서 두 개의 이상의 바이트에 나누어 넣는 방식을 사용한다.
이 표준은 1바이트 문자열 안에서 8비트보다 큰 문자 세트를 표현하기 위해서 제정된 것이다. 즉, 흔히 알고 있는 대로 바이트의 최상위 비트가 1일 경우에는 그 뒤의 바이트와 합하여 하나의 글자를 나타낸다는 것을 정의하고 있다. (또한 합쳐지는 모든 바이트의 최상위 비트도 1이어야 한다. MS의 이른바 확장 완성형은 이런 규정을 무시하고 있지만...)
이 표준은 두개 혹은 그 이상의 바이트를 합칠 수 있도록 허용하고 있으나 대부분은 두 개의 바이트만을 조합하고 있다. 이와 같이 하나의 글자를 표현할 때 여러 바이트가 조합될 수 있는 문자 세트를 MBCS(Multi-Byte Character Set)이라고 부른다. US-ASCII 처럼 1바이트만으로 표현되는 경우는 SBCS(Single Byte Character Set)이라고 한다.
* UCS-2와 UCS-4
유니코드를 메모리나 파일에 기록하는 방법에 대해서 표현할 때는 UCS-2, UCS-4 등으로 나누어진다. UCS-2는 16비트 정수를 사용하여 유니코드 31비트 문자세트 중에서 16비트 이하의 부분만을 표현하고 UCS-4는 32비트 정수를 사용하여 31비트의 모든 유니코드 영역을 표현한다.
또한 유니코드가 정수에 저장될 때 메모리나 디스크에 배치되는 바이트 순서에 따라 little endian과 big endian으로 구분한다. 또, 시스템 자체의 endian 규칙에 부합하면 internal, 아니면 swapped라고도 한다. 보통 메모리상에서는 시스템 내부적인(internal) endian으로 처리하다가 파일에 저장할 때는 필요에 따라 big endian이나 little endian으로 보정하여 저장하는 것이 일반적이다.
UCS-2, UCS-4는 유니코드를 저장하는 변수의 크기를 정의하였지만, 바이트 순서에 대해서 표준화하지 못하였다. 따라서 실제로는 UCS-2-LE, UCS-2-BE와 같이 여러 저장 방식이 혼재할 수 있는 문제점이 있다. 일반적으로 보자면 UCS-2를 파일에 저장할 때는 big endian을 많이 사용하지만, MS처럼 little endian으로 저장하는 소프트웨어 제작사도 있다. (ISO-2022와 같은 표준에서 big endian이라고 명시한 것과는 대조적이다.)
위와 같은 endian 이슈와 함께 대개의 파일 처리 프로그램 들이 바이트 단위로 동작하는 특성에 UCS는 잘 맞지 않았다. 즉, 파일을 인식할 때 이 파일이 UCS-2, UCS-4인지 US-ASCII 또는 ISO-2022인지 인식하고 각각의 경우를 구분해서 모두 다르게 구현해야 하는 문제가 생긴 것이다. cat과 같은 간단한 프로그램들 마저도 모두 다 다시 만들어야 한다면 그 비용은 너무나 클 것이다. 이런 이유로 유니코드를 사용하는 파일이 보다 널리 사용되기 위해서 여러가지 방법이 논의되기 시작하였다.
* UTF-8 (ISO 10646-1:2000 Annex D, RFC 3629)
UTF에 대한 논의의 결과물로 UTF-1, UTF-7 등을 거쳐 UTF-8이 제정되었다. 오늘날 유니코드를 파일에 저장하는 방식은 UTF-8이 가장 일반적이다. UTF-8은 MBCS(ISO-2022)와 비슷하지만 더욱 정교한 방법으로 31비트의 유니코드를 1~6개의 바이트에 나누어 저장하는 방식이다. 첫번째 바이트를 읽는 것 만으로 몇 개의 바이트로 구성된 것인지 알 수 있기 때문에 상당히 정교하다. 그리고 하위 16비트만 표현할 때는 최대 3바이트로 충분하다. UTF-8에서 상위 아스키 코드 영역은 1바이트로 표현될 수 있고 한글은 대개 3바이트를 차지한다.
마이크로소프트는 텍스트 파일의 맨 앞에 UCS-2/4 및 endian을 표시하는 BOM(Byte-Order Mark)라는 특정한 코드를 넣어서 구분하자고 주장하였으나 Unix와 같은 운영체제에는 잘 맞지 않는 방식이었다. Windows NT 4.0 이후로 MS는 UCS-2 형식의 파일을 기본적으로 사용할 수 있었으나 그리 많이 이용되지는 않았고, 최근에 UTF-8이 널리 사용되면서 MS도 UTF-8을 기본적으로 지원하고 있다.
UTF-8은 바이트 단위로 읽혀질 수 있기 때문에 기존의 ISO-2022을 기준으로 작성된 응용프로그램들과 호환성이 높다. 예컨데 UCS-2 문자열은 unsigned short 배열에 저장되어야 하지만, UTF-8 문자열은 기존의 응용프로그램 처럼 char 배열에 저장될 수 있다.
* UTF-16 (ISO 10646-1 Annex Q, RFC 2781)
UTF-8은 UTF-8과 는 다른 관점에서 생긴 것으로서 UCS-2 문자열 안에 유니코드의 21비트 영역의 문자를 표현하기 위해서 도입된 것이다. UCS-2는 U+D8000~U+DFFF 영역을 정의하고 있지 않은데, UTF-16은 이 영역을 응용하여 두 개의 UCS-2 코드를 조합함으로써 16비트 위의 21비트까지 표현할 수 있도록 하였다. 즉, UTF-16이란 UCS-2의 확장이라고 할 수 있다. UTF-16 문자열을 입력 받을 때 보통의 UCS-2 응용프로그램은 이 영역의 코드를 무시하거나 오류를 내겠지만 UTF-16 응용프로그램은 제대로 21비트의 모든 유니코드를 인식할 수 있게 된다.
UTF-16도 UCS-2의 특성을 똑같이 가지고 있기 때문에 파일 저장을 위해서 사용되지는 않을 것이다. UTF-16은 UCS-2만을 지원하는 응용프로그램이 UCS-4로 확장하기 위해서 선택할 수 있는 방법이라고 할 수 있다. 현재 마이크로소프트 Windows 플랫폼은 UCS-2만을 지원하고 있는데, 앞으로 전체 유니코드를 지원하기 위해서 UCS-4로 바꾸기 보다는 UTF-16로 전환하는 것이 기존 소프트웨어와의 호환성을 유지하면서 확장하는 방안이라고 할 수 있다.
* UTF-32
UTF-32는 앞의 UTF-8과 UTF-16과는 달리 UCS-4를 그대로 32비트 정수에 담는 것을 정의하고 있다. 즉, UCS-4와 똑같은 것이다. 하지만, UCS-4는 부분적으로 변화의 여지가 있고 논의가 진행되고 있다. (반면 UCS-2는 확정되어 있다.)
그래서 UTF-32는 변화하지 않는 21비트 영역만으로 한정해 놓았다. 즉, UTF-32는 21비트 그 이상의 부분은 사용하지 않도록 한정해 놓아서 UCS-4의 상위 부분이 변화하는데 따른 혼란을 피한 것이다. 소프트웨어의 입장에서는 아직 UCS-4를 사용할 수는 없다 (고정된 것이 아니므로), 대신 당분간은 UTF-32를 사용해야 한다. 앞으로 21비트 이상의 부분이 확정이 되면 새로운 UTF가 나오겠지만, 그런 날이 과연 언제나 올런지 알 수 없다.
<출처> http://blueb.net/blog/123
댓글목록
등록된 댓글이 없습니다.