MySQL 5.6 한글메뉴얼

10.1.14.1 Unicode 캐릭터 세트

MySQL 5.6는 다음 Unicode 문자 세트를 지원합니다.

ucs2 . 문자 당 16 비트를 사용하는 Unicode 캐릭터 세트의 UCS-2 인코딩.
utf16 . Unicode 캐릭터 세트의 UTF-16 인코딩. ucs2 와 비슷하지만, 보조 문자 용 확장 기능이 있습니다.
utf16le . Unicode 캐릭터 세트의 UTF-16LE 인코딩. utf16 와 비슷하지만 빅 엔디안가 아닌 리틀 엔디안입니다.
utf32 . 문자마다 32 비트를 사용하는 Unicode 캐릭터 세트의 UTF-32 인코딩.
utf8 . 문자마다 1에서 3 바이트를 사용하는 Unicode 캐릭터 세트의 UTF-8 인코딩.
utf8mb4 . 문자마다 1에서 4 바이트를 사용하는 Unicode 캐릭터 세트의 UTF-8 인코딩.

ucs2 및 utf8 은 Basic Multilingual Plane (BMP) 문자를 지원합니다. utf8mb4 , utf16 , utf16le 및 utf32 은 BMP와 보조 문자를 지원합니다. utf16le 는 MySQL 5.6.1에서 추가되었습니다.

이러한 문자 세트를 사용하면 약 650 언어로 텍스트를 저장할 수 있습니다. 이 섹션에서는 Unicode 캐릭터 세트마다 사용 가능한 데이터 정렬을 보여 그들을 구별하는 특성에 대해 설명합니다. 문자 세트의 일반 정보는 섹션 10.1.10 "Unicode 지원" 을 참조하십시오.

유사한 일련의 데이터 정렬을 대부분의 Unicode 문자 세트로 사용할 수 있습니다. 이들은 다음 목록에 표시됩니다. 여기서 xxx 는 문자 집합 이름을 나타냅니다. 예를 들어, xxx _danish_ci 덴마크어 데이터 정렬을 나타내고, 구체적으로는 ucs2_danish_ci , utf16_danish_ci , utf32_danish_ci , utf8_danish_ci 및 utf8mb4_danish_ci 의 이름을 구성합니다.

utf16le 대한 데이터 정렬의 지원은 더욱 제한됩니다. 사용 가능한 유일한 데이터 정렬은 utf16le_general_ci 과 utf16le_bin 입니다. 이들은 utf16_general_ci 과 utf16_bin 와 비슷합니다.

이 섹션에서는 후술하는 바와 같이, Unicode 데이터 정렬 이름은 데이터 정렬을 기반으로하는 Unicode 데이터 정렬 알고리즘의 버전을 나타내는 버전 번호도 포함될 수 있습니다 (예를 들어 xxx _unicode_520_ci ). 이러한 데이터 정렬의 경우 해당 utf8 데이터 정렬 utf8mb3 별칭은 없습니다. 섹션 10.1.10.6 "utf8mb3 문자 세트 (utf8의 별칭)" 를 참조하십시오.

xxx _bin
xxx _croatian_ci
xxx _czech_ci
xxx _danish_ci
xxx _esperanto_ci
xxx _estonian_ci
xxx _general_ci (기본)
xxx _german2_ci
xxx _general_mysql500_ci
xxx _hungarian_ci
xxx _icelandic_ci
xxx _latvian_ci
xxx _lithuanian_ci
xxx _persian_ci
xxx _polish_ci
xxx _roman_ci
xxx _romanian_ci
xxx _sinhala_ci
xxx _slovak_ci
xxx _slovenian_ci
xxx _spanish_ci
xxx _spanish2_ci
xxx _swedish_ci
xxx _turkish_ci
xxx _unicode_ci
xxx _vietnamese_ci

MySQL은 http://www.unicode.org/reports/tr10/ 에서 설명하고있는 Unicode 데이터 정렬 알고리즘 (UCA)에 따라 xxx _unicode_ci 데이터 정렬을 구현합니다. 데이터 정렬은 버전 4.0.0 UCA 체중 키 ( http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt )를 사용합니다. 현재 xxx _unicode_ci 데이터 정렬은 Unicode 데이터 정렬 알고리즘을 일부만 지원합니다. 반면 아직 지원되지 않는 문자도 있습니다. 또한 결합 마크는 완전히 지원되지 않습니다. 이것은 주로, 베트남어, 요 루바 어, 나바호 어 같은 일부 작은 언어에 영향을줍니다. 조합 된 문자는 문자열 비교에서는 단일 Unicode 문자로 기록 된 동일한 문자와는 다른 것으로 간주 두 문자는 길이가 다른 것으로 간주됩니다 (예를 들어, CHAR_LENGTH() 함수에서 반환 된 것이나, 결과 세트의 메타 데이터에있어서의 것).

xxx _unicode_ci 의 순서 부가 각 언어에서 제대로 작동하지 않는 경우에만 MySQL은 언어 별 Unicode 데이터 정렬을 구현합니다. 언어 별 데이터 정렬은 UCA 기반입니다. 이러한 추가 언어 조정 규칙을 사용하여 xxx _unicode_ci 에서 파생됩니다.

4.0.0 이상 UCA 버전을 기반으로 데이터 정렬은 데이터 정렬 이름에 버전이 포함되어 있습니다. 따라서 xxx _unicode_520_ci 데이터 정렬은 UCA 5.2.0 체중 키 ( http://www.unicode.org/Public/UCA/5.2.0/allkeys.txt )에 근거합니다.

LOWER() 및 UPPER() 는 인수의 데이터 정렬에 따라 대소 문자 변환을 수행합니다. 4.0.0보다 최신 Unicode 버전에서만 대문자 버전과 소문자 버전이있는 캐릭터는 새로운 UCA 버전을 사용하는 데이터 정렬이 인수에있는 경우에만이 기능에 의해 변환됩니다.

Unicode 캐릭터 세트의 경우, xxx _general_ci 데이터 정렬을 사용하여 수행하는 연산은 xxx _unicode_ci 데이터 정렬보다 빠릅니다. 예를 들어, utf8_general_ci 데이터 정렬의 비교는 utf8_unicode_ci 의 비교보다 빠르지 만 정확도가 조금 낮아집니다. 그 이유는 utf8_unicode_ci 는 문자가 다른 문자의 조합에 동일한 것으로 간주 확장 형식 등의 매핑을 지원하고 있기 때문입니다. 예를 들어, 독일어와 다른 몇 가지 언어에서는 ' ß '는' ss '와 같습니다. utf8_unicode_ci 단축 형식과 무시 가능한 문자도 지원합니다. utf8_general_ci 는 확장 형식 단축 형식 무시 가능한 문자를 지원하지 않는 기존의 데이터 정렬입니다. 문자간에 일대일 비교 밖에 없습니다.

또한 설명하기 위해 다음의 등식은 utf8_general_ci 및 utf8_unicode_ci 모두로 구성되어 있습니다 (비교 또는 검색 할 때이 효과에 대해서는 섹션 10.1.7.8 "데이터 정렬의 효과의 예" 를 참조 하십시오).

 Ä = A
 Ö = O
 Ü = U

데이터 정렬 간의 차이는 다음 식을 utf8_general_ci 에 해당하는 점입니다.

 ß = s

한편, 다음의 식 독일어 DIN-1 순서 (사전 순서라고도합니다)를 지원하는 utf8_unicode_ci 에 적용됩니다.

 ß = ss

MySQL이 utf8 캐릭터 셋에 대한 언어 별 데이터 정렬을 실행하는 것은 utf8_unicode_ci 의한 순서화가 언어에 대해 잘 작동하지 않을 때뿐입니다. 예를 들어, utf8_unicode_ci 는 독일어 사전 순서와 프랑스어는 제대로 작동하기 때문에 특별한 utf8 데이터 정렬을 만들 필요가 없습니다.

utf8_general_ci 도, 독일어와 프랑스어 모두에게 충분하지만 " ß "가" s "와 같고, ' ss '같지 않은 점이 다릅니다. 이 응용 프로그램에서 허용되는 경우 utf8_general_ci 쪽이 빠르기 때문에 여기를 사용해야합니다. 이것이 허용되지 않는 경우 (예를 들어, 독일어 사전 순서가 필요한 경우)은 utf8_unicode_ci 쪽이 더 정확한 때문에, 이쪽을 사용하십시오.

독일의 DIN-2 (전화 번호부) 순서가 필요한 경우 utf8_german2_ci 데이터 정렬을 사용하십시오. 이것은 다음의 문자 세트를 동일한 것으로 간주합니다.

 Ä = Æ = AE
 Ö = Œ = OE
 Ü = UE
 ß = ss

utf8_german2_ci 은 latin1_german2_ci 와 비슷하지만, 후자는 " Æ "을" AE "에 또는" Œ "을" OE 」에 동일한 것으로 간주하지 않습니다. utf8_general_ci 로 충분하므로, 독일어 사전 순서를위한 latin1_german_ci 에 대응하는 utf8_german_ci 는 없습니다.

xxx _swedish_ci 는 스웨덴어 규칙이 포함됩니다. 예를 들어, 스웨덴어로는 독일어와 프랑스어를 사용하는 사용자는 예기치 않은 같은 다음의 관계가 있습니다.

 Ü = Y <Ö

xxx _spanish_ci 및 xxx _spanish2_ci 데이터 정렬은 각각 현대의 스페인 전통 스페인어로 대응하고 있습니다. 두 데이터 정렬도 " ñ "(n 물결표)는" n "과" o "사이의 독립적 인 문자입니다. 또한 전통적인 스페인의 경우 " ch "는" c "와" d "사이의 독립적 인 문자이며," ll "는" l "와" m "사이의 독립적 인 캐릭터입니다 .

xxx _spanish2_ci 데이터 정렬은 아스 투리 아어 및 가리시아로도 사용할 수 있습니다.

xxx _danich_ci 데이터 정렬은 노르웨이어로도 사용할 수 있습니다.

xxx _roman_ci 데이터 정렬은 I 와 J 는 동일하다고 간주 U 와 V 는 동일한 것으로 간주됩니다.

xxx _croatian_ci 데이터 정렬은 Č , Ć , Dž , Đ , Lj , Nj , Š , Ž 의 크로아티아어 문자를 조정합니다.

"바이너리"( xxx _bin ) 데이터 정렬을 제외한 모든 Unicode 데이터 정렬에 대해 MySQL은 문자의 조합 가중치를 찾도록 테이블 조회를 수행합니다. 이 가중치는 WEIGHT_STRING() 함수를 사용하여 볼 수 있습니다. ( 섹션 12.5 "문자열 함수" 를 참조하십시오.) 문자가 테이블에없는 경우 (예를 들어, "새로운"문자이기 때문에), 조합 가중 판정이 더 복잡해집니다.

일반적인 데이터 정렬 ( xxx _general_ci )에서 BMP 문자의 경우 가중치 = 코드 포인트.

UCA 데이터 정렬 (예 : xxx _unicode_ci 와 언어 별 데이터 정렬)에서 BMP 문자의 경우, 다음의 알고리즘이 적용됩니다.

 if (code> = 0x3400 && code <= 0x4DB5)
   base = 0xFB80; / * CJK Ideograph Extension * /
 else if (code> = 0x4E00 && code <= 0x9FA5)
   base = 0xFB40; / * CJK Ideograph * /
 else
   base = 0xFBC0; / * All other characters * /
 aaaa = base + (code >> 15);
 bbbb = (code & 0x7FFF) | 0x8000;

결과는 aaaa 에 bbbb 이 이어졌다 두 조합 요소의 순서입니다. 예 :

 mysql> SELECT HEX(WEIGHT_STRING(_ucs2 0x04CF COLLATE ucs2_unicode_ci));
 + ------------------------------------------------- --------- +
 | HEX (WEIGHT_STRING (_ucs2 0x04CF COLLATE ucs2_unicode_ci)) |
 + ------------------------------------------------- --------- +
 | FBC084CF |
 + ------------------------------------------------- --------- +

따라서 U+04cf CYRILLIC SMALL LETTER PALOCHKA 모든 UCA 4.0.0 데이터 정렬에서 U+04c0 CYRILLIC LETTER PALOCHKA 보다 커집니다. UCA 5.2.0 데이터 정렬은 모든 palochka 함께 정렬됩니다.

일반적인 데이터 정렬의 보조 문자의 경우 가중치는 0xfffd REPLACEMENT CHARACTER 무게입니다. UCA 4.0.0 데이터 정렬의 보조 문자의 경우, 조합 가중!는 0xfffd 입니다. 즉, MySQL은 모든 보조 문자는 서로 동일하고, 거의 모든 BMP 문자보다 커집니다.

데자렛토 문자와 COUNT(DISTINCT) 를 사용한 예 :
```
 CREATE TABLE t (s1 VARCHAR (5) CHARACTER SET utf32 COLLATE utf32_unicode_ci);
 INSERT INTO t VALUES (0xfffd); / * REPLACEMENT CHARACTER * /
 INSERT INTO t VALUES (0x010412); / * DESERET CAPITAL LETTER BEE * /
 INSERT INTO t VALUES (0x010413); / * DESERET CAPITAL LETTER TEE * /
 SELECT COUNT (DISTINCT s1) FROM t;
```
결과는 2입니다. 이것은 MySQL xxx _unicode_ci 데이터 정렬에서 대체 문자는 0x0dc6 의 무게를 가지고 있지만 데자렛토 B와 데자렛토 T는 모두 0xfffd 가중치를 가지기 때문입니다. ( utf32_general_ci 데이터 정렬이 대신 사용 된 경우,이 데이터 정렬은 모든 3자가 0xfffd 가중치를 가지므로, 결과는 1이됩니다.)

설형 문자와 WEIGHT_STRING() 를 사용한 예 :
```
 / *
 The four characters in the INSERT string are
 00000041 # LATIN CAPITAL LETTER A
 0001218F # CUNEIFORM SIGN KAB
 000121A7 # CUNEIFORM SIGN KISH
 00000042 # LATIN CAPITAL LETTER B
 * /
 CREATE TABLE t (s1 CHAR (4) CHARACTER SET utf32 COLLATE utf32_unicode_ci);
 INSERT INTO t VALUES (0x000000410001218f000121a700000042);
 SELECT HEX (WEIGHT_STRING (s1)) FROM t;
```
결과는 다음과 같습니다.
```
 0E33 FFFD FFFD 0E4A
```
0E33 과 0E4A 는 UCA 4.0.0 주요 무게입니다. FFFD 은 KAB의 무게이며, KISH 무게이기도합니다.

모든 보조 문자가 서로 동일하다는 규칙은 최적이 없지만, 문제를 일으키는 것으로는 생각되지 않습니다. 이러한 문자는 매우 드물고, 멀티 문자 문자열 전체가 보조 문자로 구성되는 것은 매우 드문 경우입니다. 일본에서는 보조 문자는 모호한 한자 표의 문자이기 때문에 일반 사용자는 어느쪽으로도 그 순서를 상관하지 않습니다. 사실, MySQL의 규칙에 따라 행을 정렬하고 이차적으로 코드 포인트 값으로 정렬 할 경우 다음과 같이하는 것이 간단합니다.
```
 ORDER BY s1 COLLATE utf32_unicode_ci, s1 COLLATE utf32_bin
```
4.0.0 이상 UCA 버전에 따라 보조 문자의 경우 (예 : xxx _unicode_520_ci ) 반드시 모든 보조 문자가 동일한 데이터 정렬 가중치를 갖지는 않습니다. 일부는 UCA allkeys.txt 파일의 명시적인 중량감이 있습니다. 그렇지이 알고리즘에서 계산 된 가중치가 있습니다.
```
 aaaa = base + (code >> 15);
 bbbb = (code & 0x7FFF) | 0x8000;
```

utf16_bin 데이터 정렬

"문자의 코드 값에 따른 순서 부」와 「문자의 이진 표현에 의한 순서 지정"고 사이에는 차이가 있습니다. 이것은 대리 위해 utf16_bin 에서만 나타나는 차이입니다.

utf16_bin ( utf16 의 이진 데이터 정렬)이 "문자마다 '대신'바이트마다"이진 비교이었다고합니다. 이 경우 utf16_bin 에서 문자의 순서는 utf8_bin 의 순서와는 다릅니다. 예를 들어, 다음 표는 두 가지 특이한 문자가 표시되어 있습니다. 첫 번째 문자는 E000 - FFFF 범위에 있기 때문에 대리보다 크지 만, 보조 문자보다 작습니다. 두 번째 문자는 보조 문자입니다.

 Code point Character utf8 utf16
 ---------- --------- ---- -----
 0FF9D HALFWIDTH KATAKANA LETTER N EF BE 9D FF 9D
 10384 UGARITIC LETTER DELTA F0 90 8E 84 D8 00 DF 84

표 2 개의 문자는 0xff9d < 0x10384 이기 때문에, 코드 포인트 값에 의한 순서입니다. 또한 0xef < 0xf0 이므로 utf8 값에 의한 순서입니다. 그러나 0xff > 0xd8 이므로 바이트별로 비교를 사용하는 경우, utf16 값에 의한 순서로는되지 않습니다.

따라서 MySQL의 utf16_bin 데이터 정렬은 '바이트마다 "이되지 않습니다. "코드 포인트에 의한 '순서입니다. MySQL은 utf16 에서 보조 문자 인코딩을 인식하면 문자 코드 포인트 값으로 변환 한 후 비교합니다. 따라서 utf8_bin 과 utf16_bin 의 순서 부는 동일합니다. 이것은 UCS_BASIC 데이터 정렬 SQL : 2008 표준의 요구 사항과 일치합니다. "UCS_BASIC 정렬 된 문자열의 문자의 Unicode 스칼라 값에 따라 순서 전체가 결정되는 데이터 정렬입니다. 이것은 UCS 문자 레퍼토리에 적용 할 수 있습니다. 모든 문자 레퍼토리는 UCS 레퍼토리의 부분 집합이므로, UCS_BASIC 데이터 정렬은 모든 문자 세트에 적용 할 수 있습니다. 노트 11 : 문자의 Unicode 스칼라 값은 부호없는 정수로 취급되는 코드 포인트입니다. "

문자 집합이 ucs2 이면 비교는 바이트마다되지만, 어쨌든도 ucs2 문자열에는 대리를 포함하지 마십시오.

MySQL 5.6.5에서 xxx _general_mysql500_ci 데이터 정렬이 추가되었습니다. 이들은 원래 xxx _general_ci 데이터 정렬 5.1.24 이전의 순서를 유지하고 MySQL 5.1.24 이전에 생성 된 테이블의 업그레이드를 허용합니다. 자세한 내용은 섹션 2.11.3 "테이블 또는 인덱스 재구성이 필요한지 확인" 및 섹션 2.11.4 "테이블 또는 인덱스를 다시 만들거나 복구" 를 참조하십시오.

MySQL에서의 Unicode 데이터 정렬에 대한 자세한 내용은 Collation-Charts.Org ( utf8 )를 참조하십시오.