【问题标题】:SELECT Hüsby returns the 'wrong' output HusbySELECT Hüsby 返回“错误”输出 Husby
【发布时间】:2021-09-03 23:07:27
【问题描述】:

在同一个数据库中,我运行查询并得到一个正确和一个错误的结果。

正确

SELECT Ort FROM `stammdaten` WHERE `Ort` = 'Husby';
    
Ort 
Husby   
Husby   

错误

SELECT Ort FROM stammdaten WHERE Ort = 'Hüsby';

Ort
Husby
Husby

数据库:utf8mb4_unicode_ci

表:utf8mb4_unicode_ci

字段:utf8mb4_unicode_ci

有没有人知道我还能更改或检查什么?

【问题讨论】:

  • correctwrong有什么区别(结果好像是一样的)?期望什么?
  • @Luuk 第二个查询对u 有区分,但它返回的值没有。
  • 是的,但那是因为整理顺序中的_ci

标签: mysql utf-8 utf8mb4


【解决方案1】:

你可以使用 BINARY 来比较

CREATE TABLE stammdaten (Ort varchar(10)) CHARACTER SET UTF8MB4 COLLATE Utf8mb4_unicode_ci
INSERT INTO stammdaten VALUES('Husby')
SELECT Ort FROM stammdaten WHERE BINARY Ort = BINARY 'Hüsby';
|奥尔特 | | :-- |

db小提琴here

【讨论】:

  • 为什么要强制使用完全不同的数据类型而不是为查询设置不同的排序规则?
  • 在这些情况下转换为二进制是标准程序。更改排序规则会带来很多麻烦,我也怀疑它会减慢查询速度
【解决方案2】:

您可以查看文档,因为一切都按预期工作:

  • 10.3.1 Collation Naming Conventions:“排序规则后缀表示排序规则是区分大小写、区分重音、区分假名(或它们的某种组合)还是二进制。”该表显示了后缀 @987654326 @ 至少代表“case insensitive”。
  • "对于不指定区分重音的非二进制排序规则名称,由区分大小写决定。如果排序规则名称不包含_ai_as,则名称中的_ci 暗示_ai而名称中的_cs 暗示_as”因此,排序规则utf8mb4_unicode_ci也不区分重音
  • 如果您想要重音敏感度,但同时要大小写不敏感,请按照10.2 Character Sets and Collations in MySQL 选择utf8mb4_0900_as_ci
  • 盲目地将列和/或文字转换为BINARY 类型与应用utf8mb4_bin 排序规则不同,因为它通常具有更多限制。见10.8.5 The binary Collation Compared to _bin Collations

需要理解Unicode(ü vs ),需要理解大小写不敏感规则(ß vs SS),需要理解重音不敏感(Café vs cafè )。否则,您最终会存储无法正确查找或过滤的数据,因为您选择了错误的排序规则。了解排序也是一个方面(ü 是在u 之后还是在ö 之后排序?),尽管很少有人感兴趣。

【讨论】:

    猜你喜欢
    • 2020-12-20
    • 2013-07-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多