Question

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

一些例子（ - ＆gt; \ 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的新版本中仍然如此？

Answer 1

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（即行为偏离）来自记录的行为。）

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

1 个答案: