Loading...
MySQL 9.5 Reference Manual 9.5의 A.11 MySQL 9.5 FAQ: MySQL Chinese, Japanese, and Korean Character Sets의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
이 FAQ 모음은 CJK(Chinese-Japanese-Korean) 이슈와 관련하여 MySQL Support 및 Development 그룹이 처리해 온 많은 문의로부터 도출된 것입니다.
A.11.1. MySQL에서 사용 가능한 CJK character set에는 어떤 것들이 있습니까?
A.11.2. table에 CJK 문자를 insert했습니다. 왜 SELECT가 그것들을 “?” 문자로 표시합니까?
A.11.3. Big5 Chinese character set을 사용할 때 어떤 문제를 알고 있어야 합니까?
A.11.4. 왜 Japanese character set 변환이 실패합니까?
A.11.5. SJIS 81CA를 cp932로 변환하려면 어떻게 해야 합니까?
A.11.6. MySQL은 Yen (¥) 기호를 어떻게 표현합니까?
A.11.7. MySQL에서 Korean character set을 사용할 때 어떤 이슈를 알고 있어야 합니까?
A.11.8. 왜 Incorrect string value error message가 발생합니까?
A.11.9. 왜 Access, PHP, 또는 다른 API를 사용하는 application에서 GUI front end나 browser가 CJK 문자를 잘못 표시합니까?
A.11.10. MySQL 9.5로 upgrade했습니다. character set과 관련하여 MySQL 4.0과 같은 동작으로 되돌리려면 어떻게 해야 합니까?
A.11.11. 왜 일부 LIKE 및 FULLTEXT CJK 문자 검색이 실패합니까?
A.11.12. character X가 모든 character set에 사용 가능한지 어떻게 알 수 있습니까?
A.11.13. 왜 CJK string이 Unicode에서 잘못 정렬됩니까? (I)
A.11.14. 왜 CJK string이 Unicode에서 잘못 정렬됩니까? (II)
A.11.15. 왜 MySQL이 supplementary character를 거부합니까?
A.11.16. “CJK”가 “CJKV”가 되어야 합니까?
A.11.17. MySQL에서 database 및 table 이름에 CJK 문자를 사용할 수 있습니까?
A.11.18. MySQL Manual의 Chinese, Japanese, Korean 번역은 어디에서 찾을 수 있습니까?
A.11.19. MySQL에서 CJK 및 관련 이슈에 대한 도움은 어디에서 얻을 수 있습니까?
| A.11.1. | MySQL에서 사용 가능한 CJK character set에는 어떤 것들이 있습니까? |
CJK character set 목록은 사용하는 MySQL 버전에 따라 달라질 수 있습니다. 예를 들어, gb18030 character set은 MySQL 5.7.4 이전 버전에서는 지원되지 않습니다. 그러나, 각 엔트리에 대해 해당 언어 이름이 INFORMATION_SCHEMA.CHARACTER_SETS 테이블의 DESCRIPTION 컬럼에 나타나기 때문에, 다음 쿼리를 사용하여 유니코드가 아닌 모든 CJK character set의 최신 목록을 얻을 수 있습니다:<br><br>```sql | |
| mysql> SELECT CHARACTER_SET_NAME, DESCRIPTION |
FROM INFORMATION_SCHEMA.CHARACTER_SETS
WHERE DESCRIPTION LIKE '%Chin%'
OR DESCRIPTION LIKE '%Japanese%'
OR DESCRIPTION LIKE '%Korean%'
ORDER BY CHARACTER_SET_NAME;
+--------------------+---------------------------------+
| CHARACTER_SET_NAME | DESCRIPTION |
+--------------------+---------------------------------+
| big5 | Big5 Traditional Chinese |
| cp932 | SJIS for Windows Japanese |
| eucjpms | UJIS for Windows Japanese |
| euckr | EUC-KR Korean |
| gb18030 | China National Standard GB18030 |
| gb2312 | GB2312 Simplified Chinese |
| gbk | GBK Simplified Chinese |
| sjis | Shift-JIS Japanese |
| ujis | EUC-JP Japanese |
+--------------------+---------------------------------+
<br>(자세한 내용은 [Section 28.3.4, “The INFORMATION\_SCHEMA CHARACTER\_SETS Table”](https://dev.mysql.com/doc/refman/9.5/en/information-schema-character-sets-table.html "28.3.4 The INFORMATION_SCHEMA CHARACTER_SETS Table")를 참조하십시오.)<br><br>MySQL은 중화인민공화국에서 공식적으로 사용하는 GB(_Guojia_ _Biaozhun_, 또는 _National_ _Standard_, 또는 _Simplified Chinese_) character set의 세 가지 변형인 `gb2312`, `gbk`, 그리고 (MySQL 5.7.4부터) `gb18030`을 지원합니다.<br><br>때때로 사람들은 `gbk` 문자를 `gb2312`에 insert하려고 시도하며, 대부분의 경우에는 동작합니다. 왜냐하면 `gbk`는 `gb2312`의 슈퍼셋이기 때문입니다. 그러나 결국에는 더 드문 Chinese 문자를 insert하려고 할 때 동작하지 않습니다. (예시는 Bug #16072를 참조하십시오.)<br><br>여기에서는 공식 문서를 참조하여 `gb2312` 또는 `gbk`에서 정확히 어떤 문자가 적법한지 명확히 하려고 합니다. `gb2312` 또는 `gbk` 버그를 report하기 전에 이 reference를 확인해 보십시오:<br>- MySQL `gbk` character set은 실제로 “Microsoft code page 936”입니다. 이는 공식 `gbk`와 문자 `A1A4` (middle dot), `A1AA` (em dash), `A6E0-A6F5`, `A8BB-A8C0`에서 다릅니다.<br><br>- `gbk`/유니코드 매핑 목록은 [http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT](http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT)를 참조하십시오.<br><br>CJK 문자를 유니코드 character set에 저장하는 것도 가능하지만, 사용 가능한 collation이 기대하는 방식대로 문자를 정렬하지 않을 수 있습니다:<br>- `utf8` 및 `ucs2` character set은 유니코드 Basic Multilingual Plane (BMP)의 문자를 지원합니다. 이 문자들의 코드 포인트 값은 `U+0000`에서 `U+FFFF` 사이입니다.<br><br>- `utf8mb4`, `utf16`, `utf16le`, `utf32` character set은 BMP 문자뿐만 아니라 BMP 밖에 있는 supplementary character도 지원합니다. supplementary character의 코드 포인트 값은 `U+10000`에서 `U+10FFFF` 사이입니다.<br><br>유니코드 character set에 대해 사용되는 collation은 해당 셋에서 문자를 정렬(즉, 구분)하는 능력을 결정합니다:<br>- Unicode Collation Algorithm (UCA) 4.0.0 기반 collation은 BMP 문자만 구분합니다.<br><br>- UCA 5.2.0 또는 9.0.0 기반 collation은 BMP 문자와 supplementary character를 구분합니다.<br><br>- Non-UCA collation은 모든 유니코드 문자를 구분하지 못할 수 있습니다. 예를 들어, `utf8mb4`의 기본 collation은 `utf8mb4_general_ci`이며, BMP 문자만 구분합니다.<br><br>또한 문자를 구분한다는 것은 특정 CJK 언어의 관례에 따라 문자를 정렬한다는 것과 동일하지는 않습니다. 현재 MySQL은 CJK 전용 UCA collation을 하나만 가지고 있으며, 이는 non-유니코드 character set인 `gb18030`을 사용해야 하는 `gb18030_unicode_520_ci`입니다.<br><br>유니코드 collation과 그 구분 속성, 특히 supplementary character에 대한 collation 속성에 대한 정보는 [Section 12.10.1, “Unicode Character Sets”](https://dev.mysql.com/doc/refman/9.5/en/charset-unicode-sets.html "12.10.1 Unicode Character Sets")를 참조하십시오. | | **A.11.2.** | table에 CJK 문자를 insert했습니다. 왜<br>[`SELECT`](https://dev.mysql.com/doc/refman/9.5/en/select.html "15.2.13 SELECT Statement")가 그것들을 “?” 문자로 표시합니까? | | | 이 문제는 일반적으로 MySQL의 설정이 application 프로그램 또는 운영 체제의 설정과 일치하지 않기 때문에 발생합니다. 이러한 유형의 이슈를 수정하기 위한 일반적인 단계는 다음과 같습니다:<br>- _사용 중인 MySQL 버전을 반드시 확인하십시오_.<br><br>이를 확인하려면 `SELECT VERSION();` 문을 사용하십시오.<br><br>- _database가 실제로 원하는 character set을 사용하고 있는지 확인하십시오_.<br><br>사람들은 클라이언트 character set이 항상 서버 character set이나 화면 표시 용도로 사용되는 character set과 같다고 생각하는 경우가 많습니다. 그러나 둘 다 잘못된 가정입니다. `SHOW CREATE TABLE tablename`의 결과를 확인하거나, 더 나은 방법으로는 다음 문을 사용하여 확인할 수 있습니다:<br><br>sql
SELECT character_set_name, collation_name
FROM information_schema.columns
WHERE table_schema = your_database_name
AND table_name = your_table_name
AND column_name = your_column_name;
<br>- _올바르게 표시되지 않는 문자 또는 문자들의 16진수 값을 확인하십시오_.<br><br>이 정보는 테이블 _`table_name`_의 컬럼 _`column_name`_에 대해 다음 쿼리를 사용하여 얻을 수 있습니다:<br><br>sql
SELECT HEX(column_name)
FROM table_name;
<br>`3F`는 `?` 문자의 인코딩입니다. 이는 컬럼에 실제로 저장된 문자가 `?`임을 의미합니다. 이는 대부분 클라이언트 character set에서 대상 character set으로 특정 문자를 변환하는 문제 때문에 발생합니다.<br><br>- _round trip이 가능한지 확인하십시오. `literal` (또는 `_introducer hexadecimal-value`)를 select할 때, 결과로 `literal`을 얻습니까?_<br><br>예를 들어, Japanese Katakana 문자 _Pe_ (`ペ'`)는 모든 CJK character set에 존재하며, 코드 포인트 값(16진수 코딩)은 `0x30da`입니다. 이 문자의 round trip을 테스트하려면 다음 쿼리를 사용하십시오:<br><br>sql
SELECT 'ペ' AS ペ; /* or SELECT _ucs2 0x30da; */
<br>결과가 역시 `ペ`가 아니라면 round trip이 실패한 것입니다.<br><br>이러한 실패에 대한 버그 report의 경우, 후속으로 `SELECT HEX('ペ');`를 실행해 달라고 요청할 수 있습니다. 그러면 클라이언트 인코딩이 올바른지 판단할 수 있습니다.<br><br>- _문제가 MySQL이 아니라 브라우저 또는 다른 application에 있지 않은지 확인하십시오_.<br><br>이 작업을 수행하려면 [**mysql**](https://dev.mysql.com/doc/refman/9.5/en/mysql.html "6.5.1 mysql — The MySQL Command-Line Client") 클라이언트 프로그램을 사용하십시오. [**mysql**](https://dev.mysql.com/doc/refman/9.5/en/mysql.html "6.5.1 mysql — The MySQL Command-Line Client")이 문자를 올바르게 표시하지만 application이 그렇지 않다면, 문제는 아마도 시스템 설정 때문일 것입니다.<br><br>설정을 확인하려면 [`SHOW VARIABLES`](https://dev.mysql.com/doc/refman/9.5/en/show-variables.html "15.7.7.42 SHOW VARIABLES Statement") 문을 사용하십시오. 그 출력은 다음과 유사해야 합니다:<br><br>sql
mysql> SHOW VARIABLES LIKE 'char%';
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
<br>이는 국제화 지향 클라이언트(서버에 `latin1`이라는 Western Europe character set으로 연결되어 있음을 주목하십시오)에 일반적인 character set 설정입니다(`utf8` 유니코드 사용).<br><br>유니코드(보통 Unix에서는 `utf8` 변종, Windows에서는 `ucs2` 변종)가 Latin보다 바람직하지만, 운영 체제 유틸리티가 가장 잘 지원하는 것은 아닌 경우가 많습니다. 많은 Windows 사용자는 Japanese Windows의 경우 `cp932`와 같은 Microsoft character set이 적합하다고 판단합니다.<br><br>서버 설정을 제어할 수 없고, 그 아래의 컴퓨터가 어떤 설정을 사용하는지 전혀 모를 경우, 자신이 있는 국가에서 일반적으로 사용하는 character set으로 변경해 보십시오 (`euckr` = Korea; `gb18030`, `gb2312` 또는 `gbk` = People's Republic of China; `big5` = Taiwan; `sjis`, `ujis`, `cp932`, `eucjpms` = Japan; `ucs2` 또는 `utf8` = 어느 곳이든). 보통 클라이언트, connection, results 설정만 변경하면 됩니다. [`SET NAMES`](https://dev.mysql.com/doc/refman/9.5/en/set-names.html "15.7.6.3 SET NAMES Statement") 문은 이 세 가지를 한 번에 변경합니다. 예를 들어:<br><br>sql
SET NAMES 'big5';
<br>설정이 올바르면 `my.cnf` 또는 `my.ini`를 편집하여 이를 영구적으로 만들 수 있습니다. 예를 들어 다음과 같은 라인을 추가할 수 있습니다:<br><br>ini
[mysqld]
character-set-server=big5
[client]
default-character-set=big5
| **A.11.3.** | Big5 Chinese character set을 사용할 때 어떤 문제를 알고 있어야 합니까? |
| | MySQL은 Hong Kong과 Taiwan(Republic of China)에서 일반적인 Big5 character set을 지원합니다. MySQL `big5` character set은 실제로 Microsoft code page 950이며, 이는 원래의 `big5` character set과 매우 유사합니다.<br><br>`HKSCS` 확장을 추가하는 기능 요청이 접수된 상태입니다. 이 확장이 필요한 사람들은 Bug #13577에 대한 제안된 패치에 관심을 가질 수 있습니다. |
| **A.11.4.** | 왜 Japanese character set 변환이 실패합니까? |
| | MySQL은 `sjis`, `ujis`, `cp932`, `eucjpms` character set과 유니코드를 지원합니다. 일반적인 필요는 character set 간의 변환입니다. 예를 들어, Unix 서버(일반적으로 `sjis` 또는 `ujis`)와 Windows 클라이언트(일반적으로 `cp932`)가 있을 수 있습니다.<br><br>다음 변환 테이블에서 `ucs2` 컬럼은 source를 나타내고, `sjis`, `cp932`, `ujis`, `eucjpms` 컬럼은 destination을 나타냅니다. 즉, 마지막 네 컬럼은 [`CONVERT(ucs2)`](https://dev.mysql.com/doc/refman/9.5/en/cast-functions.html#function_convert)를 사용하거나 해당 값을 포함하는 `ucs2` 컬럼을 `sjis`, `cp932`, `ujis`, `eucjpms` 컬럼에 assign할 때의 16진수 결과를 제공합니다. |
| Character Name | ucs2 | sjis | cp932 | ujis | eucjpms |
| --- | --- | --- | --- | --- | --- |
| BROKEN BAR | 00A6 | 3F | 3F | 8FA2C3 | 3F |
| FULLWIDTH BROKEN BAR | FFE4 | 3F | FA55 | 3F | 8FA2 |
| YEN SIGN | 00A5 | 3F | 3F | 20 | 3F |
| FULLWIDTH YEN SIGN | FFE5 | 818F | 818F | A1EF | 3F |
| TILDE | 007E | 7E | 7E | 7E | 7E |
| OVERLINE | 203E | 3F | 3F | 20 | 3F |
| HORIZONTAL BAR | 2015 | 815C | 815C | A1BD | A1BD |
| EM DASH | 2014 | 3F | 3F | 3F | 3F |
| REVERSE SOLIDUS | 005C | 815F | 5C | 5C | 5C |
| FULLWIDTH REVERSE SOLIDUS | FF3C | 3F | 815F | 3F | A1C0 |
| WAVE DASH | 301C | 8160 | 3F | A1C1 | 3F |
| FULLWIDTH TILDE | FF5E | 3F | 8160 | 3F | A1C1 |
| DOUBLE VERTICAL LINE | 2016 | 8161 | 3F | A1C2 | 3F |
| PARALLEL TO | 2225 | 3F | 8161 | 3F | A1C2 |
| MINUS SIGN | 2212 | 817C | 3F | A1DD | 3F |
| FULLWIDTH HYPHEN-MINUS | FF0D | 3F | 817C | 3F | A1DD |
| CENT SIGN | 00A2 | 8191 | 3F | A1F1 | 3F |
| FULLWIDTH CENT SIGN | FFE0 | 3F | 8191 | 3F | A1F1 |
| POUND SIGN | 00A3 | 8192 | 3F | A1F2 | 3F |
| FULLWIDTH POUND SIGN | FFE1 | 3F | 8192 | 3F | A1F2 |
| NOT SIGN | 00AC | 81CA | 3F | A2CC | 3F |
| FULLWIDTH NOT SIGN | FFE2 | 3F | 81CA | 3F | A2CC |
| Character Name | ucs2 | sjis | cp932 | ujis | eucjpms |
| --- | --- | --- | --- | --- | --- |
이제 테이블의 다음 부분을 살펴보십시오.
| | ucs2 | sjis | cp932 |
| --- | --- | --- | --- |
| NOT SIGN | 00AC | 81CA | 3F |
| FULLWIDTH NOT SIGN | FFE2 | 3F | 81CA |
이는 MySQL이 `NOT SIGN` (Unicode `U+00AC`)을 `sjis` 코드 포인트 `0x81CA`로, `cp932` 코드 포인트 `3F`로 변환한다는 것을 의미합니다. (`3F`는 물음표(“?”)입니다. 변환을 수행할 수 없을 때 항상 사용되는 값입니다.) |
| **A.11.5.** | SJIS<br>`81CA`를 `cp932`로 변환하려면 어떻게 해야 합니까? |
| | 우리의 답변은 “?”입니다. 이에 단점이 있으며, 많은 사람들은 `sjis`의 `81CA (NOT SIGN)`이 `cp932`의 `81CA (FULLWIDTH NOT SIGN)`이 되도록 하는 “loose” 변환을 선호할 것입니다. |
| **A.11.6.** | MySQL은 Yen (`¥`) 기호를 어떻게 표현합니까? |
| | 일부 버전의 Japanese character set(`sjis`와 `euc` 모두)이 `5C`를 reverse solidus(`\`, backslash라고도 함)로 처리하는 반면, 다른 버전은 이를 yen sign(`¥`)으로 처리하기 때문에 문제가 발생합니다.<br><br>MySQL은 JIS(Japanese Industrial Standards) 표준 설명의 한 가지 버전만 따릅니다. MySQL에서 _`5C`는 항상 reverse solidus_ _(`\`)_입니다. |
| **A.11.7.** | MySQL에서 Korean character set을 사용할 때 어떤 이슈를 알고 있어야 합니까? |
| | 이론적으로는 `euckr`(Extended Unix Code Korea) character set에 여러 버전이 있었지만, 한 가지 문제만 보고되었습니다. 우리는 코드 포인트 `0x5c`가 REVERSE SOLIDUS(즉, `\`)인 EUC-KR의 “ASCII” 변종을 사용하며, 코드 포인트 `0x5c`가 `WON SIGN` (`₩`)인 “KS-Roman” 변종은 사용하지 않습니다. 이는 유니코드 `U+20A9`를 `euckr`로 변환할 수 없음을 의미합니다:<br><br>```sql
mysql> SELECT
CONVERT('₩' USING euckr) AS euckr,
HEX(CONVERT('₩' USING euckr)) AS hexeuckr;
+-------+----------+
| euckr | hexeuckr |
+-------+----------+
| ? | 3F |
+-------+----------+
``` |
| **A.11.8.** | 왜 Incorrect string value error<br>message가 발생합니까? |
| | 문제를 확인하려면 하나의 유니코드(`ucs2`) 컬럼과 하나의 Chinese(`gb2312`) 컬럼을 가진 테이블을 생성하십시오.<br><br>```sql
mysql> CREATE TABLE ch
(ucs2 CHAR(3) CHARACTER SET ucs2,
gb2312 CHAR(3) CHARACTER SET gb2312);
```<br>nonstrict SQL mode에서 드문 문자 `汌`을 두 컬럼 모두에 넣어 보십시오.<br><br>```sql
mysql> SET sql_mode = '';
mysql> INSERT INTO ch VALUES ('A汌B','A汌B');
Query OK, 1 row affected, 1 warning (0.00 sec)
```<br>[`INSERT`](https://dev.mysql.com/doc/refman/9.5/en/insert.html "15.2.7 INSERT Statement")는 warning을 발생시킵니다. 다음 문을 사용하여 이것이 무엇인지 확인하십시오:<br><br>```sql
mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
Level: Warning
Code: 1366
Message: Incorrect string value: '\xE6\xB1\x8CB' for column 'gb2312' at row 1
```<br>따라서 이는 `gb2312` 컬럼에만 관련된 warning입니다.<br><br>```sql
mysql> SELECT ucs2,HEX(ucs2),gb2312,HEX(gb2312) FROM ch;
+-------+--------------+--------+-------------+
| ucs2 | HEX(ucs2) | gb2312 | HEX(gb2312) |
+-------+--------------+--------+-------------+
| A汌B | 00416C4C0042 | A?B | 413F42 |
+-------+--------------+--------+-------------+
```<br>여기에는 여러 가지 설명이 필요합니다:<br>1. `汌` 문자는 앞에서 설명한 것처럼 `gb2312` character set에 없습니다.<br><br>2. 오래된 버전의 MySQL을 사용하는 경우, 다른 메시지를 볼 수 있습니다.<br><br>3. MySQL이 strict SQL mode를 사용하도록 설정되어 있지 않기 때문에 error가 아닌 warning이 발생합니다. nonstrict mode에서 MySQL은 포기하기보다는 가능한 한 최선을 다해 맞추려고 합니다. strict SQL mode에서는 Incorrect string value 메시지가 warning이 아닌 error로 발생하며, [`INSERT`](https://dev.mysql.com/doc/refman/9.5/en/insert.html "15.2.7 INSERT Statement")가 실패합니다. |
| **A.11.9.** | 왜 Access, PHP, 또는 다른 API를 사용하는 application에서 GUI front end나 browser가 CJK 문자를 잘못 표시합니까? |
| | [**mysql**](https://dev.mysql.com/doc/refman/9.5/en/mysql.html "6.5.1 mysql — The MySQL Command-Line Client") 클라이언트를 사용하여 서버에 직접 연결한 후, 동일한 쿼리를 거기서 실행해 보십시오. [**mysql**](https://dev.mysql.com/doc/refman/9.5/en/mysql.html "6.5.1 mysql — The MySQL Command-Line Client")이 올바르게 응답한다면, 문제는 application 인터페이스에 초기화가 필요하기 때문일 수 있습니다. [**mysql**](https://dev.mysql.com/doc/refman/9.5/en/mysql.html "6.5.1 mysql — The MySQL Command-Line Client")을 사용하여 `SHOW VARIABLES LIKE 'char%';` 문으로 어떤 character set을 사용하는지 확인하십시오. Access를 사용하고 있다면, Connector/ODBC로 연결되고 있을 가능성이 큽니다. 이 경우 [Configuring Connector/ODBC](https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-configuration.html)를 확인해야 합니다. 예를 들어 `big5`를 사용하는 경우, `SET NAMES 'big5'`를 입력해야 합니다(이 경우 `;` 문자는 필요하지 않습니다). ASP를 사용하는 경우, 코드에 [`SET NAMES`](https://dev.mysql.com/doc/refman/9.5/en/set-names.html "15.7.6.3 SET NAMES Statement")를 추가해야 할 수도 있습니다. 다음은 과거에 동작했던 예입니다:<br><br>```none
<%
Session.CodePage=0
Dim strConnection
Dim Conn
strConnection="driver={MySQL ODBC 3.51 Driver};server=server;uid=username;" \
& "pwd=password;database=database;stmt=SET NAMES 'big5';"
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open strConnection
%>
```<br>`latin1` 이외의 character set을 Connector/NET과 함께 사용하는 경우에도 마찬가지로, connection string에서 character set을 지정해야 합니다. 자세한 내용은 [Connector/NET Connections](https://dev.mysql.com/doc/connector-net/en/connector-net-connections.html)를 참조하십시오.<br><br>PHP를 사용하는 경우 다음을 시도해 보십시오:<br><br>```php
<?php
$link = new mysqli($host, $usr, $pwd, $db);
if( mysqli_connect_errno() )
{
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$link->query("SET NAMES 'utf8'");
?>
```<br>이 경우 [`SET NAMES`](https://dev.mysql.com/doc/refman/9.5/en/set-names.html "15.7.6.3 SET NAMES Statement")를 사용하여 [`character_set_client`](https://dev.mysql.com/doc/refman/9.5/en/server-system-variables.html#sysvar_character_set_client), [`character_set_connection`](https://dev.mysql.com/doc/refman/9.5/en/server-system-variables.html#sysvar_character_set_connection), [`character_set_results`](https://dev.mysql.com/doc/refman/9.5/en/server-system-variables.html#sysvar_character_set_results)를 변경했습니다.<br><br>PHP application에서 자주 발생하는 또 다른 이슈는 브라우저가 하는 가정과 관련이 있습니다. 때로는 `<meta>` 태그를 추가하거나 변경하는 것만으로 문제가 해결되기도 합니다. 예를 들어, user agent가 페이지 content를 `UTF-8`로 해석하도록 하려면 HTML 페이지의 `<head>` 섹션에 `<meta http-equiv="Content-Type" content="text/html; charset=utf-8">`을 포함하십시오.<br><br>Connector/J를 사용하는 경우 [Using Character Sets and Unicode](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-charsets.html)를 참조하십시오. |
| **A.11.10.** | MySQL 9.5로 upgrade했습니다. character set과 관련하여 MySQL 4.0과 같은 동작으로 되돌리려면 어떻게 해야 합니까? |
| | MySQL 버전 4.0에서는 서버와 클라이언트 모두에 대해 “global” character set이 하나였으며, 사용할 character set 결정은 서버 관리자가 내렸습니다. MySQL 버전 4.1부터는 이것이 변경되었습니다. 지금은 [Section 12.4, “Connection Character Sets and Collations”](https://dev.mysql.com/doc/refman/9.5/en/charset-connection.html "12.4 Connection Character Sets and Collations")에 설명된 대로 “handshake”가 이루어집니다:<br>> 클라이언트가 연결되면 사용하려는 character set의 이름을 서버로 전송합니다. 서버는 이 이름을 사용하여<br>> [`character_set_client`](https://dev.mysql.com/doc/refman/9.5/en/server-system-variables.html#sysvar_character_set_client),<br>> [`character_set_results`](https://dev.mysql.com/doc/refman/9.5/en/server-system-variables.html#sysvar_character_set_results),<br>> [`character_set_connection`](https://dev.mysql.com/doc/refman/9.5/en/server-system-variables.html#sysvar_character_set_connection)<br>> 시스템 변수를 설정합니다. 실제로 서버는 해당 character set 이름을 사용하여 [`SET NAMES`](https://dev.mysql.com/doc/refman/9.5/en/set-names.html "15.7.6.3 SET NAMES Statement") 연산을 수행합니다.<br>이로 인해 [**mysqld**](https://dev.mysql.com/doc/refman/9.5/en/mysqld.html "6.3.1 mysqld — The MySQL Server")를 [`--character-set-server=utf8`](https://dev.mysql.com/doc/refman/9.5/en/server-system-variables.html#sysvar_character_set_server)로 시작해서 클라이언트 character set을 제어할 수 없게 되었습니다. 그러나 일부 Asian 고객은 MySQL 4.0 동작을 선호합니다. 이러한 동작을 유지할 수 있도록 [**mysqld**](https://dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_character-set-client-handshake) 스위치인 [`--character-set-client-handshake`](https://dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_character-set-client-handshake)를 추가했으며, 이는 [`--skip-character-set-client-handshake`](https://dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_character-set-client-handshake)로 끌 수 있습니다. [**mysqld**](https://dev.mysql.com/doc/refman/9.5/en/mysqld.html "6.3.1 mysqld — The MySQL Server")를 [`--skip-character-set-client-handshake`](https://dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_character-set-client-handshake)로 시작하면, 클라이언트가 연결될 때 사용하려는 character set의 이름을 서버로 전송하지만, _서버는 클라이언트의 이 요청을 무시합니다_.<br><br>예를 들어 선호하는 서버 character set이 `latin1`이라고 가정해 보겠습니다. 또한 클라이언트는 운영 체제가 지원하는 character set이기 때문에 `utf8`을 사용한다고 가정합니다. 서버를 기본 character set `latin1`으로 시작합니다:<br><br>```terminal
mysqld --character-set-server=latin1
```<br>그런 다음 클라이언트를 기본 character set `utf8`로 시작합니다:<br><br>```terminal
mysql --default-character-set=utf8
```<br>그 결과 설정은 [`SHOW VARIABLES`](https://dev.mysql.com/doc/refman/9.5/en/show-variables.html "15.7.7.42 SHOW VARIABLES Statement") 출력에서 확인할 수 있습니다:<br><br>```sql
mysql> SHOW VARIABLES LIKE 'char%';
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
```<br>이제 클라이언트를 중지하고, [**mysqladmin**](https://dev.mysql.com/doc/refman/9.5/en/mysqladmin.html "6.5.2 mysqladmin — A MySQL Server Administration Program")을 사용하여 서버를 중지합니다. 그런 다음 서버를 다시 시작하되, 이번에는 다음과 같이 handshake를 건너뛰도록 합니다:<br><br>```terminal
mysqld --character-set-server=utf8 --skip-character-set-client-handshake
```<br>다시 기본 character set `utf8`으로 클라이언트를 시작한 후, 결과 설정을 표시합니다:<br><br>```sql
mysql> SHOW VARIABLES LIKE 'char%';
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
```<br>[`SHOW VARIABLES`](https://dev.mysql.com/doc/refman/9.5/en/show-variables.html "15.7.7.42 SHOW VARIABLES Statement")의 서로 다른 결과를 비교해 보면, [`--skip-character-set-client-handshake`](https://dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_character-set-client-handshake) 옵션이 사용될 때 서버가 클라이언트의 초기 설정을 무시한다는 것을 알 수 있습니다. |
| **A.11.11.** | 왜 일부 [`LIKE`](https://dev.mysql.com/doc/refman/9.5/en/string-comparison-functions.html#operator_like) 및<br>`FULLTEXT` CJK 문자 검색이 실패합니까? |
| | [`LIKE`](https://dev.mysql.com/doc/refman/9.5/en/string-comparison-functions.html#operator_like) 검색의 경우, [`BINARY`](https://dev.mysql.com/doc/refman/9.5/en/binary-varbinary.html "13.3.3 The BINARY and VARBINARY Types") 및 [`BLOB`](https://dev.mysql.com/doc/refman/9.5/en/blob.html "13.3.4 The BLOB and TEXT Types")과 같은 binary 문자열 컬럼 타입에는 매우 단순한 문제가 있습니다. 즉, 문자 경계를 알아야 합니다. 멀티바이트 character set에서는 다른 문자들이 서로 다른 옥텟 길이를 가질 수 있습니다. 예를 들어 `utf8`에서는 `A`는 1바이트가 필요하지만, `ペ`는 다음과 같이 3바이트가 필요합니다:<br><br>```none
+-------------------------+---------------------------+
| OCTET_LENGTH(_utf8 'A') | OCTET_LENGTH(_utf8 'ペ') |
+-------------------------+---------------------------+
| 1 | 3 |
+-------------------------+---------------------------+
```<br>문자열에서 첫 번째 문자가 끝나는 위치를 모르면, 두 번째 문자가 시작되는 위치를 알 수 없습니다. 이 경우 [`LIKE '_A%'`](https://dev.mysql.com/doc/refman/9.5/en/string-comparison-functions.html#operator_like)와 같은 매우 단순한 검색조차 실패합니다.<br>해결책은 적절한 CJK character set을 사용하도록 정의된 nonbinary 문자열 컬럼 타입을 사용하는 것입니다. 예: `mycol TEXT CHARACTER SET sjis`. 또는 비교하기 전에 CJK character set으로 변환하십시오.<br><br>이것이 MySQL이 존재하지 않는 문자 인코딩을 허용할 수 없는 이유 중 하나입니다. 잘못된 입력을 엄격하게 거부하지 않으면 문자 경계를 알 방법이 없습니다.<br><br>`FULLTEXT` 검색의 경우, 단어의 시작과 끝을 알아야 합니다. Western 언어에서는 대부분(또는 전부)이 space 문자를 쉽게 식별 가능한 단어 경계로 사용하므로, 이는 거의 문제가 되지 않습니다. 그러나 Asian writing에서는 보통 그렇지 않습니다. 우리는 모든 Han 문자가 단어를 나타낸다고 가정하거나, (Japanese의 경우) 문법적 어미로 인해 Katakana에서 Hiragana로의 변경에 의존하는 것과 같은 임의의 절충을 사용할 수도 있습니다. 그러나 확실한 해결책은 포괄적인 단어 목록이 필요하며, 이는 지원되는 각 Asian 언어에 대해 서버에 사전을 포함해야 함을 의미합니다. 이는 현실적으로 불가능합니다. |
| **A.11.12.** | character _`X`_가<br>모든 character set에 사용 가능한지 어떻게 알 수 있습니까? |
| | 대부분의 Simplified Chinese 문자와 기본 nonhalfwidth Japanese Kana 문자는 모든 CJK character set에 나타납니다. 다음 저장 프로시저는 `UCS-2` 유니코드 문자를 받아 다른 character set으로 변환하고, 그 결과를 16진수로 표시합니다.<br><br>```sql
DELIMITER //
CREATE PROCEDURE p_convert(ucs2_char CHAR(1) CHARACTER SET ucs2)
BEGIN
CREATE TABLE tj
(ucs2 CHAR(1) character set ucs2,
utf8 CHAR(1) character set utf8,
big5 CHAR(1) character set big5,
cp932 CHAR(1) character set cp932,
eucjpms CHAR(1) character set eucjpms,
euckr CHAR(1) character set euckr,
gb2312 CHAR(1) character set gb2312,
gbk CHAR(1) character set gbk,
sjis CHAR(1) character set sjis,
ujis CHAR(1) character set ujis);
INSERT INTO tj (ucs2) VALUES (ucs2_char);
UPDATE tj SET utf8=ucs2,
big5=ucs2,
cp932=ucs2,
eucjpms=ucs2,
euckr=ucs2,
gb2312=ucs2,
gbk=ucs2,
sjis=ucs2,
ujis=ucs2;
/* If there are conversion problems, UPDATE produces warnings. */
SELECT hex(ucs2) AS ucs2,
hex(utf8) AS utf8,
hex(big5) AS big5,
hex(cp932) AS cp932,
hex(eucjpms) AS eucjpms,
hex(euckr) AS euckr,
hex(gb2312) AS gb2312,
hex(gbk) AS gbk,
hex(sjis) AS sjis,
hex(ujis) AS ujis
FROM tj;
DROP TABLE tj;
END//
DELIMITER ;
```<br>input은 아무 `ucs2` 단일 문자이거나, 해당 문자의 코드 값(16진수 표현)일 수 있습니다. 예를 들어 유니코드의 `ucs2` 인코딩 및 이름 목록([http://www.unicode.org/Public/UNIDATA/UnicodeData.txt](http://www.unicode.org/Public/UNIDATA/UnicodeData.txt))에서 Katakana 문자 _Pe_가 모든 CJK character set에 나타나며, 그 코드 값이 `X'30DA'`라는 것을 알 수 있습니다. 이 값을 `p_convert()`의 인자로 사용하면 결과는 다음과 같습니다:<br><br>```sql
mysql> CALL p_convert(X'30DA');
+------+--------+------+-------+---------+-------+--------+------+------+------+
| ucs2 | utf8 | big5 | cp932 | eucjpms | euckr | gb2312 | gbk | sjis | ujis |
+------+--------+------+-------+---------+-------+--------+------+------+------+
| 30DA | E3839A | C772 | 8379 | A5DA | ABDA | A5DA | A5DA | 8379 | A5DA |
+------+--------+------+-------+---------+-------+--------+------+------+------+
```<br>어떤 컬럼 값도 `3F`(즉, 물음표 문자 `?`)가 아니므로, 모든 변환이 성공했음을 알 수 있습니다. |
| **A.11.13.** | 왜 CJK string이 Unicode에서 잘못 정렬됩니까? (I) |
| | 이전 MySQL 버전에서 발생하던 CJK 정렬 문제는 MySQL 8.0부터 `utf8mb4` character set과 `utf8mb4_ja_0900_as_cs` collation을 사용함으로써 해결할 수 있습니다. |
| **A.11.14.** | 왜 CJK string이 Unicode에서 잘못 정렬됩니까? (II) |
| | 이전 MySQL 버전에서 발생하던 CJK 정렬 문제는 MySQL 8.0부터 `utf8mb4` character set과 `utf8mb4_ja_0900_as_cs` collation을 사용함으로써 해결할 수 있습니다. |
| **A.11.15.** | 왜 MySQL이 supplementary character를 거부합니까? |
| | supplementary character는 유니코드 _Basic_ _Multilingual Plane / Plane 0_ 밖에 위치합니다. BMP 문자는 코드 포인트 값이 `U+0000`에서 `U+FFFF` 사이이고, supplementary character는 코드 포인트 값이 `U+10000`에서 `U+10FFFF` 사이입니다.<br><br>supplementary character를 저장하려면 이를 허용하는 character set을 사용해야 합니다:<br>- `utf8` 및 `ucs2` character set은 BMP 문자만 지원합니다.<br><br>`utf8` character set은 최대 3바이트까지 사용하는 `UTF-8` 문자만 허용합니다. 이는 Bug #12600에서 볼 수 있는 보고를 초래했으며, 우리는 이를 “not a bug”로 기각했습니다. `utf8`에서 MySQL은 이해할 수 없는 바이트를 만나면 입력 문자열을 잘라내야 합니다. 그렇지 않으면 잘못된 멀티바이트 문자가 얼마나 긴지 알 수 없습니다.<br><br>하나의 가능한 workaround는 `utf8` 대신 `ucs2`를 사용하는 것이며, 이 경우 “잘못된” 문자는 물음표로 변경됩니다. 그러나 잘림은 발생하지 않습니다. 또한 데이터 타입을 [`BLOB`](https://dev.mysql.com/doc/refman/9.5/en/blob.html "13.3.4 The BLOB and TEXT Types") 또는 [`BINARY`](https://dev.mysql.com/doc/refman/9.5/en/binary-varbinary.html "13.3.3 The BINARY and VARBINARY Types")로 변경할 수도 있으며, 이들은 유효성 검사를 수행하지 않습니다.<br><br>- `utf8mb4`, `utf16`, `utf16le`, `utf32` character set은 BMP 문자와 BMP 밖의 supplementary character를 모두 지원합니다. |
| **A.11.16.** | “CJK”가 “CJKV”가 되어야 합니까? |
| | 아닙니다. “CJKV”(Chinese Japanese Korean Vietnamese)라는 용어는 Han(원래 Chinese) 문자를 포함하는 Vietnamese character set을 가리킵니다. MySQL은 Western 문자로 된 modern Vietnamese script를 지원하지만, Han 문자를 사용하는 old Vietnamese script는 지원하지 않습니다.<br><br>MySQL 5.6부터는 유니코드 character set에 대한 Vietnamese collation이 있으며, 이에 대해서는 [Section 12.10.1, “Unicode Character Sets”](https://dev.mysql.com/doc/refman/9.5/en/charset-unicode-sets.html "12.10.1 Unicode Character Sets")에 설명되어 있습니다. |
| **A.11.17.** | MySQL에서 database 및<br>table 이름에 CJK 문자를 사용할 수 있습니까? |
| | 예. |
| **A.11.18.** | MySQL Manual의 Chinese,<br>Japanese, Korean 번역은 어디에서 찾을 수 있습니까? |
| | MySQL 5.6 manual의 Japanese translation은 [https://dev.mysql.com/doc/](https://dev.mysql.com/doc/)에서 다운로드할 수 있습니다. |
| **A.11.19.** | MySQL에서 CJK 및 관련 이슈에 대한 도움은 어디에서 얻을 수 있습니까? |
| | 다음 resource를 사용할 수 있습니다:<br>- MySQL user group 목록은 [https://wikis.oracle.com/display/mysql/List+of+MySQL+User+Groups](https://wikis.oracle.com/display/mysql/List+of+MySQL+User+Groups)에서 찾을 수 있습니다.<br><br>- character set 이슈와 관련된 기능 요청은 [http://tinyurl.com/y6xcuf](http://tinyurl.com/y6xcuf)에서 볼 수 있습니다.<br><br>- MySQL [Character Sets, Collation, Unicode Forum](https://forums.mysql.com/list.php?103)을 방문하십시오. [http://forums.mysql.com/](http://forums.mysql.com/)에서는 외국어 forum도 제공합니다. |
A.10 MySQL 9.5 FAQ: NDB Cluster
A.12 MySQL 9.5 FAQ: Connectors & APIs