• 首页
  • vue
  • TypeScript
  • JavaScript
  • scss
  • css3
  • html5
  • php
  • MySQL
  • redis
  • jQuery
  • MySQL中文,日文和韩文字符集

    A.11.1。

    MySQL中提供哪些CJK字符集?

    CJK字符集的列表可能会因您的MySQL版本而异。例如,gb18030MySQL 5.7.4之前不支持字符集。但是,由于适用语言的名称显示在表中DESCRIPTION每个条目的列INFORMATION_SCHEMA.CHARACTER_SETS中,因此您可以使用此查询获取所有非Unicode CJK字符集的当前列表:

    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	|
    +--------------------	+---------------------------------	+
    

    (有关更多信息,请参见“ INFORMATION_SCHEMA CHARACTER_SETS表”。)

    MySQL支持的三个变种 GB(国嘉Biaozhun,或国家标准,或简体中国)字符集这是在人民共和国的中国官方:gb2312gbk,和(从MySQL 5.7.4的)gb18030

    有时人们尝试在gbk字符中插入字符gb2312,而且大部分时间gbk都是有效的,因为是的超集gb2312。但是最终他们尝试插入一个稀有的汉字,但它不起作用。(有关示例,请参见Bug#16072)。

    在此,我们尝试参考官方文件来明确说明gb2312或中哪些字符是合法的gbk。在报告gb2312或发现gbk错误之前,请检查以下参考:

    • MySQL gbk字符集实际上是“ Microsoft代码页936 ”。这与gbk字符A1A4(中间点),A1AA(破折号)A6E0-A6F5,和的官方名称不同A8BB-A8C0
    • 有关gbk/ Unicode映射的列表,请参见 http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT。

    也可以将CJK字符存储在Unicode字符集中,尽管可用的排序规则可能无法完全按照您的期望对字符进行排序:

    • utf8ucs2字符集支持从Unicode基本多文种平面(BMP)中的字符。这些字符的代码点值介于U+0000和之间U+FFFF
    • utf8mb4utf16utf16le,和utf32字符集支持摆在外面的BMP BMP字符,以及增补字符。补充字符的代码点值介于U+10000和之间U+10FFFF

    用于Unicode字符集的排序规则确定对字符集中的字符进行排序(即区分)的能力:

    • 基于Unicode归类算法(UCA)4.0.0的归类仅区分BMP字符。
    • 基于UCA 5.2.0或9.0.0的归类区分BMP和补充字符。
    • 非UCA归类可能无法区分所有Unicode字符。例如,utf8mb4默认排序规则为utf8mb4_general_ci,仅区分BMP字符。

    而且,区分字符与按照给定CJK语言的约定对字符进行排序是不同的。当前,MySQL只有一个特定于CJK的UCA归类gb18030_unicode_520_ci(要求使用非Unicode gb18030字符集)。

    有关Unicode归类及其区分属性(包括补充字符的归类属性)的信息,请参见“ Unicode字符集”。

    A.11.2。

    我已将CJK字符插入表格中。为什么SELECT将它们显示为“?””字符?

    此问题通常是由于MySQL中的设置与应用程序或操作系统的设置不匹配。以下是纠正这些类型问题的一些常用步骤:

    • 确定您使用的是哪个MySQL版本

      使用语句SELECT VERSION();来确定这一点。

    • 确保数据库实际上正在使用所需的字符集

      人们经常认为客户端字符集总是与服务器字符集或用于显示目的的字符集相同。但是,这两个都是错误的假设。您可以通过检查以下结果来确定,或者更好的是,使用以下语句:SHOW CREATE TABLE tablename

      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;
      
    • 确定不正确显示的一个或多个字符的十六进制值

      您可以使用以下查询column_name为表中的列获取此信息table_name

      SELECT HEX(column_name)
      FROM table_name;
      

      3F?字符的编码;这意味着?该字符实际上存储在该列中。发生这种情况最常见的原因是将特定字符从客户字符集转换为目标字符集时遇到了问题。

    • 确保往返是可能的。当选择literal(或_introducer hexadecimal-value)时,是否得到literal结果

      例如,日语片假名字符Peペ')存在于所有CJK字符集中,并且具有代码点值(十六进制编码)0x30da。要测试此字符的往返行程,请使用以下查询:

      SELECT 'ペ' AS `ペ`;         /* or SELECT _ucs2 0x30da; */
      

      如果结果也不相同,则往返失败。

      有关此类故障的错误报告,我们可能会要求您跟进SELECT HEX('ペ');。然后我们可以确定客户端编码是否正确。

    • 确保问题出在浏览器或其他应用程序上,而不是MySQL上

      使用mysql客户端程序完成此任务。如果mysql正确显示字符,但您的应用程序不能正确显示,则可能是由于系统设置引起的。

      要确定设置,请使用以下SHOW VARIABLES语句,其输出应类似于此处显示的内容:

      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/	|
      +--------------------------	+----------------------------------------	+
      

      这些是utf8连接到西部服务器(latin1是西欧字符集)的面向国际客户(注意使用Unicode)的典型字符集设置。

      尽管Unicode(通常是utf8 Unix上的变体,而ucs2在Windows上是变体)比拉丁文更可取,但是通常不是您的操作系统实用程序最能支持的。许多Windows用户发现Microsoft字符集(例如cp932日语Windows)是合适的。

      如果你无法控制的服务器设置,你不知道什么设置你的底层计算机应用,尝试改变,以一个共同的字符集的国家,你是(euckr=韩国;gb18030gb2312gbk=中国人民共和国;big5=台;sjisujiscp932,或eucjpms=日;ucs2utf8=任意位置)。通常,仅需要更改客户端以及连接和结果设置。的SET NAMES。语句一次更改所有三个。例如:

      SET NAMES 'big5';
      

      设置正确后,您可以通过编辑my.cnf或将其永久设置my.ini。例如,您可以添加如下所示的行:

      [mysqld]
      character-set-server=big5
      [client]
      default-character-set=big5
      

      您的应用程序中使用的API配置设置也可能存在问题;请参阅为什么我的GUI前端或浏览器无法正确显示CJK字符...?了解更多信息。

    A.11.3。

    使用Big5中文字符集时应该注意哪些问题?

    MySQL支持在香港和台湾(中华民国)常见的Big5字符集。big5实际上,MySQL 字符集是Microsoft代码页950,它与原始big5字符集非常相似。

    提出了添加HKSCS扩展的功能请求。需要此扩展程序的人可能会发现感兴趣的Bug#13577的建议补丁。

    A.11.4。

    为什么日语字符集转换失败?

    MySQL的支持sjisujiscp932,和eucjpms字符集,以及为Unicode。通常需要在字符集之间进行转换。例如,可能有Unix服务器(通常带有sjisujis)和Windows客户端(通常带有cp932)。

    在下面的转换表中,ucs2列表示源极,并且sjiscp932ujis,和eucjpms列代表目的地;即,最后的4列提供了十六进制结果,当我们使用CONVERT(ucs2)或我们分配一个ucs2包含该值到一个柱sjiscp932ujis,或eucjpms柱。

    角色名字ucs2jicp932吉斯eucjpms
    残破的酒吧00A63楼3楼8FA2C33楼
    全断条FFE43楼FA553楼8FA2
    日元符号00A53楼3楼203楼
    全日元符号FFE5818F818FA1EF3楼
    瓷砖007E7E7E7E7E
    概述203E3楼3楼203楼
    单杠2015年815C815CA1BDA1BD
    EM DASH2014年3楼3楼3楼3楼
    反向实线005C815F5C5C5C
    全屏宽度””FF3C3楼815F3楼A1C0
    波浪冲刺301C81603楼A1C13楼
    全幅潮汐FF5E3楼81603楼A1C1
    垂直双线2016年81613楼A1C23楼
    平行22253楼81613楼A1C2
    减号2212817C3楼A1DD3楼
    完整的连字符减号FF0D3楼817C3楼A1DD
    百分号00A281913楼A1F13楼
    全分符号FFE03楼81913楼A1F1
    英镑符号00A381923楼A1F23楼
    全磅符号FFE13楼81923楼A1F2
    不签名00AC81CA3楼A2CC3楼
    完全不签名FFE23楼81CA3楼A2CC

    现在考虑表的以下部分。

    ucs2jicp932
    不签名00AC81CA3楼
    完全不签名FFE23楼81CA

    这意味着MySQL将NOT SIGN(Unicode U+00AC)转换为sjis代码点0x81CAcp932代码点3F。(3F是问号(“?”。这是无法执行转换时始终使用的。)

    A.11.5。

    要将SJIS转换81CAcp932怎么办?

    我们的回答是:“?”。这样做有很多弊端,许多人更喜欢“宽松”转换,因此81CA(NOT SIGN)in sjis成为81CA(FULLWIDTH NOT SIGN)in cp932

    A.11.6。

    MySQL如何代表Yen(¥)符号?

    会出现一个问题,因为某些版本的日文字符集(包括sjiseuc)治疗5C作为反向固相线(\也被称为反斜线),而其他人把它当作日元符号(¥)。

    MySQL仅遵循JIS(日本工业标准)标准描述的一种版本。在MySQL中,5C始终是反向solidus(\

    A.11.7。

    在MySQL中使用韩文字符集时,应该注意哪些问题?

    从理论上讲,虽然存在euckr(扩展Unix代码韩国)字符集的多个版本,但仅注意到了一个问题。我们使用EUC-KR 的“ ASCII ”变体(其中代码点0x5c为REVERSE SOLIDUS)\,而不是EUC-KR 的“ KS-Roman ”变体(其中代码点0x5cWON SIGN))。这意味着您无法将Unicode转换U+20A9euckr

    mysql> SELECT
               CONVERT('₩' USING euckr) AS euckr,
               HEX(CONVERT('₩' USING euckr)) AS hexeuckr;
    +-------	+----------	+
    | euckr	| hexeuckr	|
    +-------	+----------	+
    | ?	| 3F	|
    +-------	+----------	+
    

    A.11.8。

    为什么会收到不正确的字符串值错误消息?

    要解决此问题,请创建一个包含一个Unicode(ucs2)列和一个中文(gb2312)列的表。

    mysql> CREATE TABLE ch
           (ucs2 CHAR(3) CHARACTER SET ucs2,
           gb2312 CHAR(3) CHARACTER SET gb2312);
    

    在非严格SQL模式下,尝试将稀有字符放在两列中。

    mysql> SET sql_mode = '';
    mysql> INSERT INTO ch VALUES ('A汌B','A汌B');
    Query OK, 1 row affected, 1 warning (0.00 sec)
    

    INSERT产生一个警告。使用以下语句参见它是什么:

    mysql> SHOW WARNINGS\G
    *************************** 1. row***************************
      Level: Warning
       Code: 1366
    Message: Incorrect string value: '\xE6\xB1\x8CB' for column 'gb2312' at row 1
    

    因此,这仅是关于该gb2312列的警告。

    mysql> SELECT ucs2,HEX(ucs2),gb2312,HEX(gb2312) FROM ch;
    +-------	+--------------	+--------	+-------------	+
    | ucs2	| HEX(ucs2)	| gb2312	| HEX(gb2312)	|
    +-------	+--------------	+--------	+-------------	+
    | A汌B	| 00416C4C0042	| A?B	| 413F42	|
    +-------	+--------------	+--------	+-------------	+
    

    这里有几件事需要解释:

    1. 如前所述,该字符不在gb2312字符集中。
    2. 如果您使用的是旧版本的MySQL,则可能会看到不同的消息。
    3. 发生警告而非错误是因为MySQL未设置为使用严格的SQL模式。在非严格模式下,MySQL会尽力做到最好,而不是放弃。在严格的SQL模式下,不正确的字符串值消息是作为错误而不是警告出现的,并且INSERT失败。

    A.11.9。

    为什么我的GUI前端或浏览器在使用Access,PHP或其他API的应用程序中无法正确显示CJK字符?

    使用mysql客户端获得与服务器的直接连接,然后在此处尝试相同的查询。如果mysql正确响应,则可能是您的应用程序接口需要初始化。使用mysql告诉您该语句使用什么字符集或哪个字符集SHOW VARIABLES LIKE 'char%';。如果使用Access,则很可能与连接器/ ODBC连接。在这种情况下,应检查“配置连接器/ ODBC”。例如,如果使用big5,则输入SET NAMES 'big5'。(在这种情况下,不需要;字符。)如果使用的是ASP,则可能需要添加SET NAMES在代码中。这是过去有效的示例:

    <%
    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
    %>
    

    以几乎相同的方式,如果使用latin1连接器/ NET 以外的任何字符集,则必须在连接字符串中指定字符集。有关更多信息,请参见连接器/ NET连接。

    如果您使用的是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'");
    ?>
    

    在这种情况下,我们使用的SET NAMES改变character_set_clientcharacter_set_connection以及character_set_results

    PHP应用程序中经常遇到的另一个问题与浏览器所做的假设有关。有时添加或更改<meta>标签就足以解决问题:例如,确保用户代理将页面内容解释为UTF-8,包括<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><head>HTML页面的部分中。

    如果使用的是Connector / J,请参阅使用字符集和Unicode。

    A.11.10。

    我已经升级到MySQL 8.0。如何在字符集方面恢复到MySQL 4.0中的行为?

    在MySQL版本4.0中,服务器和客户端都有一个“全局”字符集,服务器管理员决定使用哪个字符。从MySQL版本4.1开始,此更改。现在会发生什么是“握手”,如在“连接字符集和校对”:

    客户端连接时,它将客户端想要使用的字符集的名称发送到服务器。服务器使用的名称,设置character_set_clientcharacter_set_resultscharacter_set_connection系统变量。实际上,服务器SET NAMES使用字符集名称执行操作。

    这样做的结果是,你不能开始控制客户端字符集的mysqld--character-set-server=utf8。但是,某些亚洲客户更喜欢MySQL 4.0的行为。为了保持这种行为,我们添加了一个mysqld开关,--character-set-client-handshake可以使用来关闭它--skip-character-set-client-handshake。如果启动mysqld的使用--skip-character-set-client-handshake,那么,当客户端连接,它向服务器发送的字符集,它希望使用的名称。但是,服务器将忽略来自客户端的此请求

    举例来说,假设您喜欢的服务器字符集是latin1。进一步假设客户端使用,utf8因为这是客户端操作系统支持的。使用latin1默认字符集启动服务器:

    mysqld --character-set-server=latin1
    

    然后使用默认字符集启动客户端utf8

    mysql --default-character-set=utf8
    

    通过参见以下命令的输出可以看到结果设置SHOW VARIABLES

    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/	|
    +--------------------------	+----------------------------------------	+
    

    现在停止客户端,并使用mysqladmin停止服务器。然后再次启动服务器,但是这次告诉它跳过握手,如下所示:

    mysqld --character-set-server=utf8 --skip-character-set-client-handshake
    

    utf8再次使用默认字符集启动客户端,然后显示结果设置:

    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/	|
    +--------------------------	+----------------------------------------	+
    

    通过比较与的不同结果SHOW VARIABLES,您可以看到,如果使用了该--skip-character-set-client-handshake选项,则服务器将忽略客户端的初始设置。

    A.11.11。

    为什么有些LIKEFULLTEXT搜索与CJK字符失败?

    对于LIKE搜索,二进制字符串列类型(例如BINARY和)存在一个非常简单的问题,BLOB我们必须知道字符的结尾。对于多字节字符集,不同的字符可能具有不同的八位位组长度。例如,在中utf8A需要一个字节,但需要三个字节,如下所示:

    +-------------------------+---------------------------+
    | OCTET_LENGTH(_utf8 'A') | OCTET_LENGTH(_utf8 'ペ') |
    +-------------------------+---------------------------+
    |                       1 |                         3 |
    +-------------------------+---------------------------+
    

    如果我们不知道字符串中的第一个字符在哪里结束,那么我们就不知道第二个字符在哪里开始,在这种情况下,甚至是非常简单的搜索(例如LIKE '_A%'失败)。解决方案是使用定义为具有正确的CJK字符集的非二进制字符串列类型。例如:mycol TEXT CHARACTER SET sjis。或者,在比较之前转换为CJK字符集。

    这就是MySQL无法允许不存在的字符编码的原因之一。如果不严格拒绝不良输入,则无法知道字符在哪里结束。

    对于FULLTEXT搜索,我们必须知道单词的开始和结束位置。对于西方语言,这几乎不是问题,因为其中大多数(如果不是全部)都使用易于识别的单词边界:空格字符。但是,亚洲写作通常不是这种情况。我们可以使用任意的中间量度,例如假设所有汉字都代表单词,或者(对于日语)取决于语法结尾从片假名到平假名的变化。但是,唯一确定的解决方案需要一个全面的单词列表,这意味着我们必须在服务器中为支持的每种亚洲语言提供一个词典。这根本不可行。

    A.11.12。

    我如何知道X所有字符集中是否都可用字符?

    大多数简体中文和基本非半角日语假名字符都出现在所有CJK字符集中。以下存储过程接受UCS-2 Unicode字符,将其转换为其他字符集,并以十六进制显示结果。

    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 ;
    

    输入可以是任何单个ucs2字符,也可以是该字符的代码值(十六进制表示)。例如,从Unicode的ucs2编码和名称列表(http://www.unicode.org/Public/UNIDATA/UnicodeData.txt)中,我们知道片假名字符Pe出现在所有CJK字符集中,并且其代码值为X'30DA'。如果我们将此值用作的参数p_convert(),则结果如下所示:

    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	|
    +------	+--------	+------	+-------	+---------	+-------	+--------	+------	+------	+------	+
    

    由于列值都不是3F(即问号字符?),因此我们知道每次转换都有效。

    A.11.13。

    为什么CJK字符串在Unicode中排序不正确?(一世)

    从MySQL 8.0开始,可以使用utf8mb4字符集和utf8mb4_ja_0900_as_cs排序规则解决在旧MySQL版本中发生的CJK排序问题。

    A.11.14。

    为什么CJK字符串在Unicode中排序不正确?(二)

    从MySQL 8.0开始,可以使用utf8mb4字符集和utf8mb4_ja_0900_as_cs排序规则解决在旧MySQL版本中发生的CJK排序问题。

    A.11.15。

    为什么我的补充字符被MySQL拒绝?

    补充字符位于Unicode Basic Multilingual Plane / Plane 0之外。BMP字符的代码点值介于U+0000和之间U+FFFF。补充字符的代码点值介于U+10000和之间U+10FFFF

    要存储补充字符,必须使用允许它们的字符集:

    • utf8ucs2字符集仅支持BMP字符。

      utf8字符集只允许UTF-8一种需要占用三个字节字符。这导致了诸如在Bug#12600中发现的报告,我们将其拒绝为“不是bug ”。使用时utf8,MySQL在遇到无法理解的字节时必须截断输入字符串。否则,未知错误的多字节字符有多长时间。

      一种可能的解决方法是使用ucs2而不是utf8,在这种情况下,“坏”字符将更改为问号。但是,不会发生截断。您也可以将数据类型更改为BLOBBINARY,不执行有效性检查。

    • utf8mb4utf16utf16le,和utf32字符集支持BMP字符,以及在BMP之外增补字符。

    A.11.16。

    如果“ CJK ”是“ CJKV ”?

    否。术语“ CJKV ”(日文,日文,韩文,越南文)是指包含汉字(原为中文)的越南字符集。MySQL支持使用西方字符的现代越南语脚本,但不支持使用汉字的老式越南语脚本。

    从MySQL 5.6开始,存在越南语Unicode字符集的排序规则,如“ Unicode字符集”中所述。

    A.11.17。

    MySQL是否允许在数据库和表名中使用CJK字符?

    是。

    A.11.18。

    在哪里可以找到MySQL手册翻译成中文,日文和韩文的信息?

    可以从https://dev.mysql.com/doc/下载MySQL 5.6手册的日语翻译。

    A.11.19。

    在MySQL的哪里可以获得CJK和相关问题的帮助?

    提供以下资源:

    • 可以在https://wikis.oracle.com/display/mysql/List+of+MySQL+User+Groups中找到MySQL用户组的列表。
    • 在http://tinyurl.com/y6xcuf上参见与字符集问题有关的功能请求。
    • 访问MySQL 字符集,排序规则,Unicode论坛。 http://forums.mysql.com/还提供了外语论坛。

    上篇:NDB群集

    下篇:连接器和API