创建新数据库时,我必须设置排序规则类型或设置其默认值....
但实际上我需要知道什么是Kanatype Sensitive(KS)和宽度敏感的手段,它以我所知,例如区分大小写,这些字母对大小写敏感,对于Kanatype敏感和宽度敏感？
WPF*_*bie 35
两者都与排序有关,通常你不会选择这两个选项.这是微软的描述.
Kanatype敏感
区分两种日本假名字符:平假名和片假名.
如果未选择此选项,则SQL Server会将Hiragana和Katakana字符视为排序目的相同
宽度敏感
当表示为双字节字符时,区分单字节字符和相同字符.
如果未选择此选项,则SQL Server会将同一字符的单字节和双字节表示视为排序目的相同.
小智 14
Kanatype不敏感性使得日文文本的排序更加直观,并且通常应该始终启用,除非您有理由不这样做.
通常,如果您要存储任何需要排序的日文文本,您可能希望使用Kanatype不敏感.你为什么要这样？因为它使日语的排序更直观.
在英语中,由于我们只有一个书写系统,因此很容易通过算法对事物进行排序.我们只需按字符代码(按字母顺序排列)对字符进行排序,我们就完成了.但是,在日语中,因为有多种方法可以写出等效的声音,所以排序可能会有点棘手.平假名和片假名字母被分成单独的Unicode块,因此当我们尝试使用"Kanatype敏感度"进行排序时,我们最终会得到不完全直观的结果.
想象一下,您有一个要排序的名称列表:
{"ピカチュウ","さとし","マリオ","まちだ","はるか"}
列表的罗马化等价物是:
{"Pikachu","Satoshi","Mario","Machida","Haruka"}
当排序kanatype敏感时,您将得到以下结果:
{"さとし","はるか","まちだ","ピカチュウ","マリオ"}
{"Satoshi","Haruka","Machida","皮卡丘","马里奥"}
当排序kanatype不敏感时,你会得到这个结果:
{"さとし","はるか","ピカチュウ","まちだ","マリオ"}
{"Satoshi","Haruka","皮卡丘","町田","马里奥"}
对于日语使用者来说,第二种类型更加直观,因为结果实际上是按照发音而不是基于字符集进行排序的."まちだ"和"マリオ"都以相同的语音声音开始,但是因为一个使用平假名"ma"而另一个使用片假名"ma",所以当启用kanatype灵敏度时它们被分开.对于kanatype不敏感,列表可以正确排序,以便尽管写入系统存在差异,但两个单词在列表中彼此相邻.
对英语的一个很好的比喻是区分大小写.想象一下,如果你想为字典排序一个单词列表,其中一些是专有名词,而另一些则不是:
{"New York","new","jet","Japan","squirm","SQL"}
如果我们忽略了大写和小写字母代表相同字母并且只是基于字符代码排序的事实,我们会得到这样的结果:
{"日本","纽约","SQL","喷气机","新","蠕动"}
像这样排序的字典几乎没有用,特别是如果我们想要在不知道它是以大写还是小写字母开头的情况下查找单词.在用最后一个部分检查所有其他单词之前,我们必须检查字典的第一部分是否包含所有专有名词.
如果我们运行不区分大小写的排序,尽管有单独的字符代码,但将"A"和"a"视为同一个字母.我们会得到一个更直观的结果:
{"Japan","jet","new","New York","squirm","SQL"}
因此,一般情况下,除非您有特殊原因,否则应始终禁用kanatype灵敏度.电话簿查找将是kanatype敏感的.请注意,在日语中还有一个额外的字符类型,即汉字,您还需要使用它.汉字很难排序,因为几乎总有多种方法可以阅读每个汉字,而汉字则没有真正的"字母"顺序.大多数用于日本人的表单通常有两个名称字段:通常写出的用户名,以及用片假名完全写出的用户名.这不仅让人们知道如何正确地发出一个名字,这个名字可能只是简单地用汉字写成,但它允许软件按明确的片假名字段进行排序,使得排序kanatype不敏感.
有关更多信息,我绝对建议您查看这篇优秀文章,该文章解释了日语排序问题比我更好.
参考:https://japanese.stackexchange.com/questions/29612/what-do-you-need-kanatype-sensitivity-for