Kanatype敏感KS和宽度敏感的含义是什么

Question

当创建新的数据库时，我不得不设置排序规则类型或设置其默认....罚款。

但实际上我需要知道Kanatype Sensitive（KS）和宽度敏感手段是什么，它对我而言是众所周知的，例如区分大小写意味着字母对大写和小写字母敏感，Kanatype Sensitive和width敏感？？

Answer 1

两者都与排序有关，通常你不会选择这两个选项。这里是微软的一个描述。 平假名和片假名：

Kanatype敏感

两种类型的日语假名字符之间进行区分。

如果未选择此选项，SQL Server认为平假名和 片假名字符为等于用于排序目的

宽度敏感

一个单字节字符与相同的字符之间进行区分当表示为双字节字符时，表示为 。

如果未选择此选项，SQL Server会将用于排序的单字节 和同一字符的双字节表示视为相同 。

Answer 2

一般来说，如果您要存储任何需要排序的日文文本，那么您可能希望使用Kanatype不敏感。你为什么要这样？因为它使得日语的排序更直观。

在英语中，由于我们只有一个书写系统，所以很容易在算法上对事物进行分类。我们只需按字符代码排序字符（已按字母顺序排列），我们就完成了。但在日语中，因为有多种方式可以写出相同的声音，排序可能会有点棘手。平假名和片假名字母被分成独立的Unicode块，所以当我们尝试用“Kanatype sensitivity”对事物进行排序时，最终得到的结果不完全直观。

想象一下，你有，你想排序的名单：

{ “ピカチュウ”， “さとし”， “マリオ”， “まちだ”， “はるか”} 的罗马拼音相当于名单：

{ “皮卡丘”， “智”， “马里奥”， “町田”， “春香”} 当分拣kanatype敏感，你会得到以下结果：

{ “さとし”，“はるか“，”まちだ“，”ピカチュウ“，”マリオ“} {”Satoshi“，”Haruka“，”Machida“，”Pikachu“，”Mario“} 当分拣kanatype不敏感，你会得到这样的结果，而不是：

{ “さとし”， “はるか”， “ピカチュウ”， “まちだ”， “マリオ”} { “智”， “春香”，“皮卡丘“，”Machida“，”Mario“} 对于日语的人来说，第二种更直观，因为结果实际上是按语音排序而不是基于字符集。“まちだ”和“マリオ”都以相同的语音开始，但是因为使用平假名“ma”而其他使用片假名“ma”，所以当启用了感叹号类型灵敏度时，它们是分开的。在kanatype不敏感的情况下，可以对列表进行适当的排序，以使这两个单词在列表中彼此相邻，尽管它们的写入系统不同。

英语语言的一个很好的比喻是区分大小写。想象一下，如果你想为字典排序一个单词列表，其中一些是专有名词，而另一些则不是：

{“New York”，“new”，“jet”，“Japan”，“squirm”， “SQL”} 如果我们忽略了大写和小写字母代表相同字母并基于字符代码进行排序的事实，我们会得到类似如下的结果：

{“Japan”，“New York”，“SQL “，”jet“，”new“，”squirm“} 这样排序的字典几乎不会有用，特别是如果我们想查找一个单词而不知道它是否以大写或小写字母开头。在检查包含所有其他单词的最后一部分之前，我们必须先检查字典的第一部分和所有专有名词。

如果我们运行不区分大小写的排序，即使使用单独的字符代码，也会将“A”和“a”视为相同的字母。我们会得到一个更直观的结果：

{“Japan”，“jet”，“new”，“New York”，“squirm”，“SQL”} 所以一般情况下，除非你有具体的原因不是，你应该始终禁用kanatype的敏感度。电话簿查询将是kanatype敏感的。请注意，在日语中还有一个额外的字符类型，日文汉字，您还需要处理。汉字更难以分类，因为几乎总是有多种方法来读取每个日文汉字，而没有真正的“汉字字母”顺序。面向日本人的大多数表格通常都有两个名称字段：用户名，因为它通常是写出来的，而用户名完全用片假名写出。这不仅让人们知道如何正确地读出一个名字，而这个名字可能仅仅用日文汉字写成，但它允许软件按照明确的片假名字段进行排序，从而使得排序kanatype不敏感。

欲了解更多信息，我绝对推荐查看这篇优秀的文章，这篇文章解释了用日语排序的问题比我更好。

TL; DR：Kanatype不敏感使得对日文文本进行排序更加直观，通常应该始终启用，除非您有理由不这样做。

参考：https://japanese.stackexchange.com/questions/29612/what-do-you-need-kanatype-sensitivity-for