!엔죠라이프 블로그

제너스디알엠(Janus DRM)은 마이크로소프트(MS)가 개발한 차세대 디지털저작권관리(DRM) 솔루션이다. 공식 명칭은 ‘윈도 미디어 DRM 10 포 포터블 디바이스(Windows Media DRM 10 for Portable Devices)’다.

제너스디알엠은 MS DRM으로 보호된 음악이나 동영상을 휴대형 기기에서 재생해주는 기술이다. 휴대형 MP3플레이어 외에도 PMP, 셋톱박스, 휴대폰 등 다양한 기기에 적용되며 현재 아이리버, 델, 크리에이티브 등과 같은 업체들이 제너스디알엠 탑재 제품을 시판 중이다. 또 미국의 냅스터투고(Napster To Go) 서비스가 제너스디알엠을 이용해 한 달에 14.5달러를 지불하고 음악을 임대하는 정액제 다운로드 서비스를 실시 중이다.
제너스디알엠은 MS가 주창하는 ‘플레이 포 슈어(play for sure)’의 핵심을 이루고 있다. 제너스디알엠은 기간이나 횟수를 제한하는 복합 콘텐츠 서비스 모델, 하나의 라이선스로 복수의 콘텐츠 라이선스를 관리하는 라이선스 체이닝, 재생 횟수에 따라 정산하는 미터링, 복수 라이선스를 자동갱신하는 라이선스 싱크 등의 다양한 기능을 지원한다.

*UTF-8은 무엇인가?
UCS와 Unicode는 무엇보다도 단시 문자에 정수 숫자를 할당한 코드 테이블일
뿐이다. 이러한 문자들의 순서를 어떻게 할 것인가? 또는 이 문자들의 정수 값을
어떻게 바이 트 순서로 표현할 것인가에 대해서는 여러가지 방법이 존재한다.
Unicode 문자열을 저장하는 확실한 표현방법은 2 또는 4 바이트 순서로 표현하는
두가 지 방법이 존재한다. 이러한 표현방법의 공식적인 이름은 UCS-2와
UCS-4이다. 그리고, 특별히 확정지을 필요없없지만, Bigendian 표현방법을
따른다.(작은 수가 먼저 나온다.) ASCII와 Latin-1 화일은 ASCII 바이트의 첫번째
0×00 바이트 부터 삽입함으로 해서 UCS-2 포맷으로 간단하게 변환시킬 수 있다.
만약 UCS-4 화일을 사용하기를 원한다면, ASCII 바이트를 삽입하기 전에 세개의
0×00 바이트를 모든 코드에 삽입해야 한다.
Unix에서 UCS-2나 UCS-4를 사용하기 위해서는 매우 심각한 문제가 발생된다. UCS
표현방법을 사용하는 문자열은 화일 이름이나 C 라이브러리의 함수 매개 변수에서
‘?’이나 ‘/’과 같이 특별한 의미를 가지는 많은 wide character를 가질 수 있다.
그리고, UNIX 도구들의 대부분은 ASCII 파일이고, 중요한 변화없이 16 비트
워드를 한 문자로 읽을 수가 없다. 이러한 이유는 UCS-2는 화일 이름이나 텍스트
화일, 환경변수에서 적절한 Unicodei의 외부 표현방법이 아니기 때문이다.
ISO 10646-1에 정의된 UTF-8 Annex R 과 RFC 2279표현 방법은 이러한 문제점을
가지고 있지 않다. UTF-8은 Unix와 같은 운영체제에서 Unicode를 사용하는데
확실한 방법 이다.
UTF-8은 다음과 같은 성질을 가지고 있다:
UCS 문자 U+0000 부터 U+007F(ASCII)들은 0×00 부터 0x7F 바이트 까지로 간단하게
표현된다(ASCII 호환성). 이 것의 의미는 7-bit ASCII 문자들을 화일과
문자열들도 ASCII와 UTF-8양 코드 집합에서 모두 같은 방식의 표현 방법을
사용한다는 것이다.
모든 UCS 문자 >U+007F들은 대부분 특정 비트 집합인, 몇 바이트의 시퀀스로 표현
된다. 그러므로 ASCII 바이트(0×00-0x7F)는 어떤 다른 문자집합의 부분으로
나타낼 수 있다.
ASCII 문자가 아닌 것을 표현하는 다중 바이트 집합의 첫번째 바이트는 항상 0xC0
부타 0XFD이고, 이 부분은 이 문자 뒤에 얼마나 많은 바이트가 존재할지를 가르킨
다. 다중 바이트 집합에서 모든 다음 바이트의 범위는 0×80부터 0xBF이다. 이것은
쉬운 재매칭을 가능케 하고, 표현의 안정성을 얻어 낼 수 있으며, missing bytes
에 대해 완벽성을 기해준다.(쩝 번역 이상!!)
모두 231개의 UCS 코드가 표현 가능하다.
UTF-8로 표현된 문자들은 이론적으로 6바이트가 될 수 있다. 그러나, 16 비트 BMP
문자들은 단지 3 바이트이면 된다.
Bigendian UCS-4 바이트 문자열의 정렬방법은 정해져 있다.
0xFE와 0xFF 바이트는 UTF-8에서는 사용되지 않는다.
다음의 바이트 순서는 문자를 표현하는데 사용된다. 다음의 순서는 Unicode의
문자수에 의존적으로 사용된다:
U-00000000 – U-0000007F: 0xxxxxxx
U-00000080 – U-000007FF: 110xxxxx 10xxxxxx
U-00000800 – U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 – U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 – U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 – U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
10xxxxxx
xxx로 표현되어 있는 비트들은 바이너리 표현에서 문자 코드 수의 비트 로
표현된다. 가장 오른쪽의 x 비트는 least-significant(??) 비트이다. 가장 짧게
표현 가능한 다중 바이트 표현은 각 문자가 사용하는 코드 숫자의 표현이다. 다중
바이트 표현에서 가장 중요한 것은, 첫번째 바이트에서 1비트로 표현되어 있는
코드의 의미는 전체 코드가 표현할 수 있는 바이트의 갯수와 같다는 점이다.
Examples: Unicode 문자 U+00A9 = 1010 1001 (copyright sign) 은 UTF-8에서는
다음과 같이 표현된다.
11000010 10101001 = 0xC2 0xA9
그리고 Unicode 문자 U+2260 = 0010 0010 0110 0000 (not equal to)은 다음 과
같이 표현된다:
11100010 10001001 10100000 = 0xE2 0×89 0xA0
이 표현 방법의 공식 이름은 UTF-8이고 이 약어의 정확한 이름은 UCS
Transformation Format이다. 그리고, 이 이름은 utf8이다 UTF_8과 같이 다른
방법으 로 문서나 그외의 다른 방법으로 표현하지 않기를 권한다.
UTF-8 표현을 다루는 개발자들을 위한 중요한 노트: 안전을 위해, 좋은 UTF-8
복호기(decoder)는 문자를 encode 하기 위해 필요한 크기 이상의 UTF-8 문자열은
받아들여서는 안된다. 예를 들어, 문자 U+000Ai (line feed)는 꼭 0x0A의
영역에서 UTF-8 코드를 받아들여야 하고, 아래와 같은 5개와 같이 보다 긴 형식은
받아 들여서는 안된다:
0xc0 0x8A
0xe0 0×80 0x8A
0xf0 0×80 0×80 0x8A
0xf8 0×80 0×80 0×80 0x8A
0xfc 0×80 0×80 0×80 0×80 0x8A
임의의 목적 코드보다 큰 UTF-8 문자은 encoding하는데 필요한 가장 작은 코드
부분만 을 사용하는 UTF-8 하부 문자열 테스트에서는 그냥 통과될 수 있다.
필요이상으로 큰 모든 UTF-8 문자는 다음과 같은 바이트 패턴을 가지고 시작된다:
1100000x (10xxxxxx)
11100000 100xxxxx (10xxxxxx)
11110000 1000xxxx (10xxxxxx 10xxxxxx)
11111000 10000xxx (10xxxxxx 10xxxxxx 10xxxxxx)
11111100 100000xx (10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx)