Loading...
MySQL 9.5 Reference Manual 9.5의 12.10.1 Unicode Character Sets의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
이 섹션에서는 Unicode 문자 집합에 대해 사용 가능한 collation과 그것들을 구분하는 속성에 대해 설명합니다. Unicode에 대한 일반적인 정보는 Section 12.9, “Unicode Support”를 참조하십시오.
MySQL은 여러 Unicode 문자 집합을 지원합니다:
utf8mb4: Unicode 문자 집합의 UTF-8 인코딩으로, 문자당 1에서 4바이트를 사용합니다.
utf8mb3: Unicode 문자 집합의 UTF-8 인코딩으로, 문자당 1에서 3바이트를 사용합니다. 이 문자 집합은 deprecated 상태입니다. 대신
utf8mb4를 사용하십시오.
utf8: utf8mb3의 deprecated alias입니다.
대신 utf8mb4를 사용하십시오.
참고
utf8은 향후 릴리스에서
utf8mb4의 alias가 될 것으로 예상됩니다.
ucs2: Unicode 문자 집합의 UCS-2 인코딩으로, 문자당 2바이트를 사용합니다. Deprecated 상태이며,
향후 MySQL 버전에서 이 문자 집합에 대한 지원이 제거될 것으로 예상됩니다.
utf16: Unicode 문자 집합의 UTF-16 인코딩으로, 문자당 2 또는 4바이트를 사용합니다.
ucs2와 유사하지만 supplementary 문자에 대한 확장이 있습니다.
utf16le: Unicode 문자 집합의 UTF-16LE 인코딩입니다.
utf16과 유사하지만 big-endian이 아닌 little-endian입니다.
utf32: Unicode 문자 집합의 UTF-32 인코딩으로, 문자당 4바이트를 사용합니다.
참고
utf8mb3 문자 집합은 deprecated 상태이며,
향후 MySQL 릴리스에서 제거될 것으로 예상됩니다.
대신 utf8mb4를 사용하십시오.
utf8은 현재
utf8mb3의 alias이지만, 이는 deprecated 상태이며,
이후에 utf8은
utf8mb4를 참조하도록 변경될 것으로 예상됩니다.
Information Schema 테이블의 컬럼과 SQL SHOW
문 출력에서 utf8 대신
utf8mb3가 표시됩니다.
utf8의 의미에 대한 모호함을 피하려면,
문자 집합을 참조할 때 명시적으로
utf8mb4를 지정하는 것을 고려하십시오.
utf8mb4, utf16,
utf16le, 그리고 utf32는
Basic Multilingual Plane (BMP) 문자와 BMP 밖에 위치한 supplementary 문자를 지원합니다.
utf8mb3와 ucs2는 BMP 문자만 지원합니다.
대부분의 Unicode 문자 집합에는 일반 collation(이름에 _general이 포함되거나
언어 지정자가 없는 경우), binary collation(이름에
_bin이 포함됨), 그리고 여러 개의
언어별 collation(언어 지정자가 포함됨)이 있습니다.
예를 들어, utf8mb4의 경우
utf8mb4_general_ci와
utf8mb4_bin이 일반 collation과 binary collation이며,
utf8mb4_danish_ci는
언어별 collation 중 하나입니다.
대부분의 문자 집합에는 하나의 binary collation만 있습니다.
utf8mb4는 예외적으로 두 개를 가집니다:
utf8mb4_bin과
utf8mb4_0900_bin입니다. 이 두 binary collation은
정렬 순서는 같지만 pad 속성과 collating weight 특성으로 구분됩니다. 자세한 내용은
Collation Pad Attributes 및
Character Collating Weights를 참조하십시오.
utf16le에 대한 collation 지원은 제한적입니다.
사용 가능한 collation은
utf16le_general_ci와
utf16le_bin뿐입니다. 이들은
utf16_general_ci와
utf16_bin과 유사합니다.
MySQL은
Unicode Collation Algorithm (UCA)에 따라
xxx_unicode_ci
collation을 구현합니다. UCA는
http://www.unicode.org/reports/tr10/에 설명되어 있습니다.
이 collation은 version-4.0.0 UCA weight key를 사용합니다:
http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt.
xxx_unicode_ci
collation은 Unicode Collation Algorithm을 부분적으로만 지원합니다.
일부 문자는 지원되지 않으며, combining mark는 완전히 지원되지 않습니다.
이는 베트남어, Yoruba, Navajo와 같은 언어에 영향을 줍니다.
문자열 비교에서, 결합 문자(combined character)는 동일한 문자를 단일 Unicode 문자로 쓴 것과는 다른 것으로 간주되며,
두 문자는 길이도 다르게 취급됩니다(예를 들어,
CHAR_LENGTH() 함수가 반환하는 값이나
결과 집합 메타데이터에서).
UCA 4.0.0보다 높은 버전의 UCA를 기반으로 하는 Unicode collation은 collation 이름에 버전을 포함합니다. 예:
utf8mb4_unicode_520_ci는 UCA
5.2.0 weight key
( http://www.unicode.org/Public/UCA/5.2.0/allkeys.txt)를 기반으로 합니다.
utf8mb4_0900_ai_ci는 UCA
9.0.0 weight key
( http://www.unicode.org/Public/UCA/9.0.0/allkeys.txt)를 기반으로 합니다.
LOWER() 및
UPPER() 함수는
인수의 collation에 따라 대소문자 변환(case folding)을 수행합니다.
대문자와 소문자 버전이 Unicode 4.0.0보다 높은 버전에서만 정의된 문자는,
인수 collation이 충분히 높은 UCA 버전을 사용할 때에만
이 함수들에 의해 변환됩니다.
UCA 9.0.0 이상을 기반으로 하는 collation은
UCA 9.0.0 이전 버전을 기반으로 하는 collation보다 빠릅니다.
또한 pad 속성이 NO PAD이며,
UCA 9.0.0 이전 버전을 기반으로 하는 collation에서 사용되는
PAD SPACE와 대조됩니다.
nonbinary 문자열 비교에서,
NO PAD collation은 문자열 끝의 공백을
다른 문자와 동일하게 취급합니다(자세한 내용은
Trailing Space Handling in Comparisons 참조).
collation의 pad 속성을 확인하려면,
PAD_ATTRIBUTE 컬럼을 가진
INFORMATION_SCHEMA COLLATIONS 테이블을 사용하십시오. 예:
1mysql> SELECT COLLATION_NAME, PAD_ATTRIBUTE 2 FROM INFORMATION_SCHEMA.COLLATIONS 3 WHERE CHARACTER_SET_NAME = 'utf8mb4'; 4+----------------------------+---------------+ 5| COLLATION_NAME | PAD_ATTRIBUTE | 6+----------------------------+---------------+ 7| utf8mb4_general_ci | PAD SPACE | 8| utf8mb4_bin | PAD SPACE | 9| utf8mb4_unicode_ci | PAD SPACE | 10| utf8mb4_icelandic_ci | PAD SPACE | 11... 12| utf8mb4_0900_ai_ci | NO PAD | 13| utf8mb4_de_pb_0900_ai_ci | NO PAD | 14| utf8mb4_is_0900_ai_ci | NO PAD | 15... 16| utf8mb4_ja_0900_as_cs | NO PAD | 17| utf8mb4_ja_0900_as_cs_ks | NO PAD | 18| utf8mb4_0900_as_ci | NO PAD | 19| utf8mb4_ru_0900_ai_ci | NO PAD | 20| utf8mb4_ru_0900_as_cs | NO PAD | 21| utf8mb4_zh_0900_as_cs | NO PAD | 22| utf8mb4_0900_bin | NO PAD | 23+----------------------------+---------------+
NO PAD collation을 가진
nonbinary 문자열 값(CHAR, VARCHAR,
TEXT)의 비교는,
trailing space와 관련하여 다른 collation과 다르게 동작합니다.
예를 들어, 'a'와
'a '는 동일한 문자열이 아닌, 서로 다른 문자열로 비교됩니다.
이는 utf8mb4의 binary collation을 사용해 확인할 수 있습니다.
utf8mb4_bin의 pad 속성은
PAD SPACE인 반면,
utf8mb4_0900_bin의 pad 속성은
NO PAD입니다. 결과적으로,
utf8mb4_0900_bin이 관련된 연산에서는
trailing space가 추가되지 않으며,
trailing space를 가진 문자열이 관련되는 비교 결과는
이 두 collation에서 서로 다를 수 있습니다:
1mysql> CREATE TABLE t1 (c CHAR(10) COLLATE utf8mb4_bin); 2Query OK, 0 rows affected (0.03 sec) 3 4mysql> INSERT INTO t1 VALUES('a'); 5Query OK, 1 row affected (0.01 sec) 6 7mysql> SELECT * FROM t1 WHERE c = 'a '; 8+------+ 9| c | 10+------+ 11| a | 12+------+ 131 row in set (0.00 sec) 14 15mysql> ALTER TABLE t1 MODIFY c CHAR(10) COLLATE utf8mb4_0900_bin; 16Query OK, 0 rows affected (0.02 sec) 17Records: 0 Duplicates: 0 Warnings: 0 18 19mysql> SELECT * FROM t1 WHERE c = 'a '; 20Empty set (0.00 sec)
MySQL은 Unicode Collation Algorithm (UCA)에만 기반한 정렬이 특정 언어에 적절하지 않을 경우, 언어별 Unicode collation을 구현합니다. 언어별 collation은 UCA 기반이며, 여기에 언어별 tailoring rule이 추가됩니다. 이러한 rule의 예는 이 섹션 뒤에 나옵니다.
특정 언어 정렬에 대한 질문이 있을 경우, http://unicode.org에서 제공하는 Common Locale Data Repository (CLDR) collation 차트를 http://www.unicode.org/cldr/charts/30/collation/index.html에서 참조하십시오.
예를 들어, 비언어별
utf8mb4_0900_ai_ci와 언어별
utf8mb4_LOCALE_0900_ai_ci
Unicode collation은 각각 다음 특성을 가집니다:
collation은 UCA 9.0.0 및 CLDR v30을 기반으로 하며,
accent-insensitive이고 case-insensitive입니다.
이러한 특성은 collation 이름의
_0900,
_ai, _ci로 표시됩니다.
예외:
utf8mb4_la_0900_ai_ci는 CLDR에 기반하지 않습니다.
이는 Classical Latin이 CLDR에 정의되어 있지 않기 때문입니다.
collation은 [U+0, U+10FFFF] 범위의 모든 문자에 대해 동작합니다.
collation이 언어별이 아닌 경우, 모든 문자(보조 문자 포함)를 기본 순서(default order)로 정렬합니다(아래에 설명됨). collation이 언어별인 경우, 해당 언어의 문자는 언어별 규칙에 따라 올바르게 정렬하고, 해당 언어에 속하지 않는 문자는 기본 순서로 정렬합니다.
기본적으로, collation은 DUCET 테이블 (Default Unicode Collation Element Table)에 코드 포인트가 나열된 문자에 대해, 테이블에 할당된 weight 값을 사용하여 정렬합니다. collation은 DUCET 테이블에 코드 포인트가 나열되지 않은 문자에 대해서는, UCA에 따라 구성된 implicit weight 값을 사용하여 정렬합니다.
비언어별 collation에서는, contraction sequence의 문자를 별개의 문자로 취급합니다. 언어별 collation에서는, contraction이 문자 정렬 순서를 변경할 수 있습니다.
다음 표에 표시된 locale 코드 또는 언어 이름이 collation 이름에 포함된 경우, 해당 collation은 언어별 collation입니다. Unicode 문자 집합에는 이들 언어 중 하나 이상에 대한 collation이 포함될 수 있습니다.
Table 12.3 Unicode Collation Language Specifiers
| Language | Language Specifier |
|---|---|
| Bosnian | bs |
| Bulgarian | bg |
| Chinese | zh |
| Classical Latin | la or roman |
| Croatian | hr or croatian |
| Czech | cs or czech |
| Danish | da or danish |
| Esperanto | eo or esperanto |
| Estonian | et or estonian |
| Galician | gl |
| German phone book order | de_pb or german2 |
| Hungarian | hu or hungarian |
| Icelandic | is or icelandic |
| Japanese | ja |
| Latvian | lv or latvian |
| Lithuanian | lt or lithuanian |
| Mongolian | mn |
| Norwegian / Bokmål | nb |
| Norwegian / Nynorsk | nn |
| Persian | persian |
| Polish | pl or polish |
| Romanian | ro or romanian |
| Russian | ru |
| Serbian | sr |
| Sinhala | sinhala |
| Slovak | sk or slovak |
| Slovenian | sl or slovenian |
| Modern Spanish | es or spanish |
| Traditional Spanish | es_trad or spanish2 |
| Swedish | sv or swedish |
| Turkish | tr or turkish |
| Vietnamese | vi or vietnamese |
| Language | Language Specifier |
|---|
MySQL은 다음과 같은 Bulgarian collation을 제공합니다:
utf8mb4_bg_0900_ai_ci와
utf8mb4_bg_0900_as_cs.
Croatian collation은 다음 Croatian 문자에 대해 tailoring 되어 있습니다:
Č, Ć,
Dž, Đ,
Lj, Nj,
Š, Ž.
MySQL은 Serbian에 대해
utf8mb4_sr_latn_0900_ai_ci와
utf8mb4_sr_latn_0900_as_cs collation을 제공하며,
Bosnian에 대해서는
utf8mb4_bs_0900_ai_ci와
utf8mb4_bs_0900_as_cs collation을 제공합니다.
이는 해당 언어들이 Latin alphabet으로 쓰이는 경우에 해당합니다.
MySQL은 Norwegian의 두 주요 변종 모두에 대해 collation을 제공합니다.
Bokmål의 경우,
utf8mb4_nb_0900_ai_ci와
utf8mb4_nb_0900_as_cs를 사용할 수 있으며,
Nynorsk의 경우 MySQL은
utf8mb4_nn_0900_ai_ci와
utf8mb4_nn_0900_as_cs를 제공합니다.
Japanese의 경우, utf8mb4 문자 집합에는
utf8mb4_ja_0900_as_cs와
utf8mb4_ja_0900_as_cs_ks collation이 포함됩니다.
두 collation 모두 accent-sensitive이고 case-sensitive입니다.
utf8mb4_ja_0900_as_cs_ks는 또한
kana-sensitive이며 Katakana 문자를
Hiragana 문자와 구분하지만,
utf8mb4_ja_0900_as_cs는 정렬 시
Katakana와 Hiragana 문자를 동일하게 취급합니다.
Japanese collation이 필요하지만 kana sensitivity는 필요하지 않은 애플리케이션은
더 나은 정렬 성능을 위해
utf8mb4_ja_0900_as_cs를 사용할 수 있습니다.
utf8mb4_ja_0900_as_cs는 정렬에
3개의 weight level을 사용하고,
utf8mb4_ja_0900_as_cs_ks는 4개를 사용합니다.
accent-insensitive한 Classical Latin collation에서는,
I와 J가
동일하게 비교되고,
U와 V가
동일하게 비교됩니다.
I와 J, 그리고
U와 V는
base letter level에서 동일하게 비교됩니다.
즉, J는
accented I로 간주되며,
U는 accented V로 간주됩니다.
MySQL은 Cyrillic 문자로 쓰이는 Mongolian 언어에 대해
utf8mb4_mn_cyrl_0900_ai_ci와
utf8mb4_mn_cyrl_0900_as_cs collation을 제공합니다.
Spanish collation은 modern Spanish와 traditional Spanish 모두에 대해 제공됩니다.
두 경우 모두에서 ñ (n-tilde)는
n과 o 사이의
별도의 문자입니다. 추가로, traditional Spanish에서는
ch가 c와 d 사이의
별도의 문자이고,
ll이 l과 m 사이의
별도의 문자입니다.
Traditional Spanish collation은 Asturian과 Galician에도 사용할 수 있습니다.
MySQL은 또한 Galician에 대해
utf8mb4_gl_0900_ai_ci와
utf8mb4_gl_0900_as_cs collation을 제공합니다.
(이들은 각각
utf8mb4_es_0900_ai_ci와
utf8mb4_es_0900_as_cs와 동일한 collation입니다.)
Swedish collation에는 Swedish 규칙이 포함됩니다. 예를 들어, Swedish에서는 다음 관계가 성립하며, 이는 German이나 French 사용자가 기대하는 것과는 다릅니다:
1Ü = Y < Ö
어떤 Unicode 문자 집합에 대해서든,
xxx_general_ci
collation을 사용하여 수행되는 연산은
xxx_unicode_ci
collation을 사용하는 연산보다 빠릅니다.
예를 들어, utf8mb4_general_ci collation에 대한 비교는
utf8mb4_unicode_ci에 대한 비교보다 빠르지만,
정확성은 약간 떨어집니다.
그 이유는
utf8mb4_unicode_ci가 expansion과 같은 매핑을 지원하기 때문입니다.
즉, 하나의 문자가 다른 문자들의 조합과 동일하게 비교될 수 있습니다.
예를 들어, German 및 일부 다른 언어에서는
ß가 ss와 동일합니다.
utf8mb4_unicode_ci는 또한
contraction 및 ignorable 문자를 지원합니다.
utf8mb4_general_ci는
expansion, contraction 또는 ignorable 문자를 지원하지 않는
legacy collation입니다.
이 collation은 문자 간에 1:1 비교만 수행할 수 있습니다.
이를 더 자세히 설명하기 위해,
다음 동치는
utf8mb4_general_ci와
utf8mb4_unicode_ci 모두에서 성립합니다(이것이 비교나 검색에 미치는 영향에 대해서는
Section 12.8.6, “Examples of the Effect of Collation”을 참조하십시오):
1Ä = A 2Ö = O 3Ü = U
두 collation 사이의 차이점은
utf8mb4_general_ci에서는 다음이 참이라는 점입니다:
1ß = s
반면,
German DIN-1 ordering(사전 순서라고도 함)을 지원하는
utf8mb4_unicode_ci에서는 다음이 참입니다:
1ß = ss
MySQL은
utf8mb4_unicode_ci를 사용한 정렬이
특정 언어에 적절하지 않을 경우,
언어별 Unicode collation을 구현합니다.
예를 들어,
utf8mb4_unicode_ci는
German dictionary order와 French에서 잘 동작하므로,
특별한 utf8mb4 collation을 만들 필요가 없습니다.
utf8mb4_general_ci 역시
German과 French 모두에 대해 만족스러우나,
예외적으로 ß가
ss가 아닌 s와 동일하다는 점이 있습니다.
이 점이 애플리케이션에 수용 가능하다면,
더 빠르기 때문에
utf8mb4_general_ci를 사용해야 합니다.
이 점이 수용 가능하지 않다면(예를 들어, German dictionary order가 필요한 경우),
더 정확하기 때문에
utf8mb4_unicode_ci를 사용해야 합니다.
German DIN-2 (전화번호부 순서) 정렬이 필요한 경우,
다음과 같은 문자 집합을 동일하게 비교하는
utf8mb4_german2_ci collation을 사용하십시오:
1Ä = Æ = AE 2Ö = Œ = OE 3Ü = UE 4ß = ss
utf8mb4_german2_ci는
latin1_german2_ci와 유사하지만,
후자는 Æ를 AE와,
또는 Œ를 OE와 동일하게 비교하지 않습니다.
German dictionary order에 대한
latin1_german_ci에 해당하는
utf8mb4_german_ci는 존재하지 않습니다.
이는 utf8mb4_general_ci로 충분하기 때문입니다.
문자의 collating weight는 다음과 같이 결정됩니다:
_bin (binary) collation을 제외한 모든 Unicode collation에 대해,
MySQL은 테이블 lookup을 수행하여 문자의 collating weight를 찾습니다.
utf8mb4_0900_bin을 제외한 _bin collation의 경우,
weight는 코드 포인트를 기반으로 하며, 필요에 따라 앞에 0 바이트를 추가할 수 있습니다.
utf8mb4_0900_bin의 경우,
weight는 utf8mb4 인코딩 바이트입니다.
정렬 순서는 utf8mb4_bin과 동일하지만
훨씬 더 빠릅니다.
collating weight는
WEIGHT_STRING() 함수를 사용하여 표시할 수 있습니다.
(Section 14.8, “String Functions and Operators” 참조.)
collation이 weight lookup 테이블을 사용하지만,
문자가 테이블에 없는 경우(예: “새로운” 문자인 경우),
collating weight 결정은 더 복잡해집니다:
일반 collation(xxx_general_ci)의
BMP 문자에 대해서는,
weight가 코드 포인트입니다.
UCA collation(예:
xxx_unicode_ci
및 언어별 collation)의 BMP 문자에 대해서는,
다음 알고리즘이 적용됩니다:
1if (code >= 0x3400 && code <= 0x4DB5) 2 base= 0xFB80; /* CJK Ideograph Extension */ 3else if (code >= 0x4E00 && code <= 0x9FA5) 4 base= 0xFB40; /* CJK Ideograph */ 5else 6 base= 0xFBC0; /* All other characters */ 7aaaa= base + (code >> 15); 8bbbb= (code & 0x7FFF) | 0x8000;
결과는
aaaa 다음에
bbbb가 오는 두 개의 collating element 시퀀스입니다. 예:
1mysql> SELECT HEX(WEIGHT_STRING(_ucs2 0x04CF COLLATE ucs2_unicode_ci)); 2+----------------------------------------------------------+ 3| HEX(WEIGHT_STRING(_ucs2 0x04CF COLLATE ucs2_unicode_ci)) | 4+----------------------------------------------------------+ 5| FBC084CF | 6+----------------------------------------------------------+
따라서, U+04cf CYRILLIC SMALL LETTER PALOCHKA (ӏ)는
모든 UCA 4.0.0 collation에서
U+04c0 CYRILLIC LETTER PALOCHKA
(Ӏ)보다 큽니다.
UCA 5.2.0 collation에서는 모든 palochka가 함께 정렬됩니다.
0xfffd REPLACEMENT CHARACTER에 대한 weight입니다.
UCA 4.0.0 collation의 supplementary 문자에 대해서는,
collating weight가 0xfffd입니다.
즉, MySQL에서 supplementary 문자는 서로 모두 동일하며,
대부분의 BMP 문자보다 큽니다.Deseret 문자와
COUNT(DISTINCT)를 사용한 예:
1CREATE TABLE t (s1 VARCHAR(5) CHARACTER SET utf32 COLLATE utf32_unicode_ci); 2INSERT INTO t VALUES (0xfffd); /* REPLACEMENT CHARACTER */ 3INSERT INTO t VALUES (0x010412); /* DESERET CAPITAL LETTER BEE */ 4INSERT INTO t VALUES (0x010413); /* DESERET CAPITAL LETTER TEE */ 5SELECT COUNT(DISTINCT s1) FROM t;
결과는 2입니다. 이는 MySQL의
xxx_unicode_ci
collation에서 replacement 문자의 weight가
0x0dc6인 반면,
Deseret Bee와 Deseret Tee는 모두 weight가
0xfffd이기 때문입니다.
(utf32_general_ci collation을 사용했다면,
세 문자의 weight가 모두
0xfffd이므로 결과는 1이 됩니다.)
Cuneiform 문자와
WEIGHT_STRING()을 사용한 예:
1/* 2The four characters in the INSERT string are 300000041 # LATIN CAPITAL LETTER A 40001218F # CUNEIFORM SIGN KAB 5000121A7 # CUNEIFORM SIGN KISH 600000042 # LATIN CAPITAL LETTER B 7*/ 8CREATE TABLE t (s1 CHAR(4) CHARACTER SET utf32 COLLATE utf32_unicode_ci); 9INSERT INTO t VALUES (0x000000410001218f000121a700000042); 10SELECT HEX(WEIGHT_STRING(s1)) FROM t;
결과는 다음과 같습니다:
10E33 FFFD FFFD 0E4A
0E33과 0E4A는
UCA
4.0.0에 있는 primary weight이며,
FFFD는 KAB 및 KISH에 대한 weight입니다.
모든 supplementary 문자가 서로 동일하다는 규칙은 최적은 아니지만 문제가 발생할 것으로 예상되지는 않습니다. 이러한 문자는 매우 드물기 때문에, 여러 문자로 구성된 문자열이 오로지 supplementary 문자로만 이루어지는 경우는 매우 드뭅니다.
일본에서는 supplementary 문자가 난해한 Kanji ideograph이므로, 일반 사용자는 이들이 어떤 순서로 정렬되는지에 대해 신경 쓰지 않습니다. 정말로 row를 MySQL 규칙에 따라 정렬하고, 그 다음으로 코드 포인트 값에 따라 정렬하고 싶다면, 이는 간단합니다:
1ORDER BY s1 COLLATE utf32_unicode_ci, s1 COLLATE utf32_bin
xxx_unicode_520_ci)의 경우,
supplementary 문자는 반드시 동일한 collating weight를 가지는 것은 아닙니다.
일부는 UCA allkeys.txt 파일에서 가져온 명시적인 weight를 가지며,
나머지는 다음 알고리즘에 따라 계산된 weight를 가집니다:1aaaa= base + (code >> 15); 2bbbb= (code & 0x7FFF) | 0x8000;
“문자의 코드 값에 따른 정렬”과
“문자의 binary representation에 따른 정렬” 사이에는
차이가 있으며, 이는 surrogate 때문에
utf16_bin에서만 나타납니다.
utf16의 binary collation인
utf16_bin이 “byte 단위”의 binary 비교라고 가정해 봅시다.
그렇다면, utf16_bin에서의 문자 순서는
utf8mb4_bin에서의 문자 순서와 다르게 됩니다.
예를 들어, 다음 표는 드문 문자 두 개를 보여줍니다.
첫 번째 문자는
E000-FFFF 범위에 있으므로,
surrogate보다 크지만 supplementary보다는 작습니다.
두 번째 문자는 supplementary입니다.
1Code point Character utf8mb4 utf16 2---------- --------- ------- ----- 30FF9D HALFWIDTH KATAKANA LETTER N EF BE 9D FF 9D 410384 UGARITIC LETTER DELTA F0 90 8E 84 D8 00 DF 84
표의 두 문자는 코드 포인트 값에 따라 정렬된 순서입니다.
0xff9d <
0x10384이기 때문입니다.
그리고 utf8mb4 값에 따라 정렬해도 순서가 같습니다.
0xef < 0xf0이기 때문입니다.
하지만 byte-by-byte 비교를 사용할 경우,
0xff >
0xd8이므로,
utf16 값에 따라 정렬하면 두 문자는 순서가 맞지 않습니다.
따라서 MySQL의 utf16_bin collation은
“byte 단위”가 아니라 “코드 포인트 단위”입니다.
MySQL이 utf16에서 supplementary-character 인코딩을 발견하면,
이를 문자의 코드 포인트 값으로 변환한 다음 비교합니다.
따라서, utf8mb4_bin과
utf16_bin의 정렬 순서는 동일합니다.
이는 UCS_BASIC collation에 대한 SQL:2008 표준 요구사항과 일치합니다:
“UCS_BASIC은 정렬이 문자열에 포함된 문자들의 Unicode scalar value에 의해서만 결정되는 collation이다.
이는 UCS 문자 레퍼토리에 적용 가능하다.
모든 문자 레퍼토리는 UCS 레퍼토리의 부분집합이므로,
UCS_BASIC collation은 잠재적으로 모든 문자 집합에 적용 가능하다.
NOTE 11: 문자의 Unicode scalar value는
부호 없는 정수로 취급되는 코드 포인트이다.”
문자 집합이 ucs2인 경우,
비교는 byte-by-byte이지만,
어차피 ucs2 문자열에는 surrogate가 포함되지 않아야 합니다.
xxx_general_mysql500_ci
collation은 원래의
xxx_general_ci
collation에 대한 pre-5.1.24 ordering을 보존하며,
MySQL 5.1.24 이전에 생성된 테이블의 업그레이드를 가능하게 합니다(Bug #27877).
12.10 Supported Character Sets and Collations
12.10.2 West European Character Sets