具有高utf-8代码点的MySQL比较问题

时间:2014-10-06 22:47:39

标签: mysql utf-8

我看到MySQL的奇怪行为和非常高的UTF-8代码点。

一些例子( - > \ u {1f48f}或\ u {1f48e}或其他任何球场)

SELECT name, '', name = '', '' = '', name = '' from payees where id = 4178417368;
+------+------+-------------+-----------+-----------+
| name |    | name = '' | '' = '' | name = '' |
+------+------+-------------+-----------+-----------+
|      |  | 1           | 0         | 1         |
+------+------+-------------+-----------+-----------+
1 rows in set (0.04 sec)

请注意,等式已变为不可传递:name等于空字符串,name等于随机字符,但随机字符不等于空字符串。

当然,这是一个相当旧的MySQL 5.1.68版本。有没有人知道在一般的MySQL 5.1或5.x的新版本中仍然如此?

1 个答案:

答案 0 :(得分:0)

MySQL utf8 characterset仅支持Basic Multilingual Plane(BMP)中的字符。它不支持补充平面中的任何字符。

参考:http://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8.html

MySQL 5.5.x引入了一个支持4字节编码的 utf8mb4 字符集; utf8 字符组的行为保持不变。

http://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb4.html


根据您发布的内容,该行的name列中存储的值看起来是零长度字符串。 (您可以使用LENGTH(名称),CHAR_LENGTH(名称),HEX(名称)函数来更好地了解实际存储的内容。

name列与空字符串以及不受支持的字符的相等比较看起来应该返回1。

但两个文字的比较结果为0,我并没有真正期待。那里没有涉及列字符集,因此它将成为客户端字符集。我很想在该文字上使用LENGTH,CHAR_LENGTH和HEX函数。

这些文字的比较结果要么是1)记录的行为(记录在某处),要么是2)未定义的行为,MySQL可以做任何事情,或3)它是一个bug(即行为偏离)来自记录的行为。)