我看到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的新版本中仍然如此?
答案 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(即行为偏离)来自记录的行为。)