Loading...
MySQL 9.5 Reference Manual 9.5의 12.9.5 The utf16 Character Set (UTF-16 Unicode Encoding)의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
utf16 문자 집합은 supplementary 문자 인코딩을 가능하게 하는 확장이 포함된 ucs2 문자 집합입니다:
BMP 문자의 경우, utf16과 ucs2는 동일한 저장 특성을 가집니다: 동일한 코드 값, 동일한 인코딩, 동일한 길이입니다.
supplementary 문자의 경우, utf16은 32비트를 사용하여 문자를 표현하기 위한 특별한 시퀀스를 사용합니다. 이를 “surrogate” 메커니즘이라고 합니다.
0xffff보다 큰 숫자의 경우, 10비트를 취해 0xd800에 더한 뒤 첫 번째 16-bit 워드에 넣고, 다른 10비트를 취해 0xdc00에 더한 뒤 다음 16-bit 워드에 넣습니다.
결과적으로 모든 supplementary 문자는 32비트가 필요하며, 처음 16비트는 0xd800에서 0xdbff 사이의 숫자이고, 마지막 16비트는 0xdc00에서 0xdfff 사이의 숫자입니다.
예시는 Unicode 4.0 문서의 Section 15.5 Surrogates Area에 있습니다.
utf16은 surrogate를 지원하고 ucs2는 지원하지 않기 때문에, utf16에만 적용되는 유효성 검사 규칙이 있습니다: top surrogate만 bottom surrogate 없이 삽입할 수 없고, 또는 그 반대도 허용되지 않습니다. 예를 들면 다음과 같습니다:
1INSERT INTO t (ucs2_column) VALUES (0xd800); /* legal */ 2INSERT INTO t (utf16_column)VALUES (0xd800); /* illegal */
기술적으로는 유효하지만 진정한 Unicode가 아닌 문자(즉, Unicode에서 “unassigned code points”, “private use” 문자, 또는 0xffff와 같은 “illegals”로 간주되는 문자)에 대해서는 유효성 검사가 없습니다.
예를 들어, U+F8FF는 Apple Logo이므로, 다음은 허용됩니다:
1INSERT INTO t (utf16_column)VALUES (0xf8ff); /* legal */
이러한 문자는 모든 사람에게 동일한 의미를 갖는다고 기대할 수 없습니다.
MySQL은 최악의 경우(하나의 문자가 네 바이트를 필요로 하는 경우)를 허용해야 하므로, utf16 컬럼이나 인덱스의 최대 길이는 ucs2 컬럼이나 인덱스의 최대 길이의 절반에 불과합니다.
예를 들어, MEMORY 테이블 인덱스 키의 최대 길이는 3072바이트이므로, 다음 statement들은 ucs2와 utf16 컬럼에 대해 허용되는 가장 긴 인덱스를 가진 테이블을 생성합니다:
1CREATE TABLE tf (s1 VARCHAR(1536) CHARACTER SET ucs2) ENGINE=MEMORY; 2CREATE INDEX i ON tf (s1); 3CREATE TABLE tg (s1 VARCHAR(768) CHARACTER SET utf16) ENGINE=MEMORY; 4CREATE INDEX i ON tg (s1);
12.9.4 The ucs2 Character Set (UCS-2 Unicode Encoding)
12.9.6 The utf16le Character Set (UTF-16LE Unicode Encoding)