Questions tagged «collation»

排序规则是一组规则，这些规则确定如何对数据进行排序和比较以比较字符集中的字符。

1
忽略“哪里”的口音
在我们的数据库中，我们有关于caron / hatschek的多个条目。现在，当我们的用户搜索不带caron / hatschek的条目时，他们希望找到这些条目。我将通过一个简单的示例来说明这一点： 在我们的数据库中，我们有条目（带有姓名的联系方式） Millière 所以这个名字在这个人居住的国家是正确的。 在我们的国家/地区，caron / hatschek没有任何字符，因此我们的用户搜索Milliere。没有结果，è显然不匹配e。 我不知道这到底是怎么实现的é，è，ê还有更多可供选择（而这仅是字母一个例子e......）。 （另一种方法会容易得多，因为我可以简单地将所有字母替换为用caron / hatschek替换为基本字母。显然，我们的用户确实希望数据库中使用正确的名称版本，而不是残缺的名称。）
2
为什么非数字喜欢[0-9]？
我的服务器的默认排序规则是Latin1_General_CI_AS，由以下查询确定： SELECT SERVERPROPERTY('Collation') AS Collation; 我很惊讶地发现，通过这种归类，我可以使用谓词匹配字符串中的非数字字符LIKE '[0-9]'。 为什么在默认排序规则中会发生这种情况？我想不出一个有用的例子。我知道我可以使用二进制排序规则来解决此问题，但这似乎是实现默认排序规则的一种奇怪方法。 过滤数字会产生非数字字符 我可以通过创建包含所有可能的单字节字符值的列并使用数字匹配谓词过滤值来演示此行为。 以下语句创建一个临时表，该表具有256行，在当前代码页中的每个代码点对应一个： WITH P0(_) AS (SELECT 0 UNION ALL SELECT 0), P1(_) AS (SELECT 0 FROM P0 AS L CROSS JOIN P0 AS R), P2(_) AS (SELECT 0 FROM P1 AS L CROSS JOIN P1 AS R), P3(_) AS (SELECT 0 …
2
将character_set_client的值设置为utf8mb4
我正在尝试将我的数据库转换为utf8mb4遵循本指南。我已经设定： [client] default-character-set=utf8mb4 [mysql] default-character-set=utf8mb4 [mysqld] init-connect='SET NAMES utf8mb4' collation_server=utf8mb4_unicode_ci character_set_server=utf8mb4 skip-character-set-client-handshake 但价值character_set_client并character_set_results仍然不会改变utf8mb4。 mysql> SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%'; +--------------------------+--------------------+ | Variable_name | Value | +--------------------------+--------------------+ | character_set_client | utf8 | | character_set_connection | utf8mb4 | | character_set_database | utf8mb4 | | character_set_filesystem | binary …
12 mysql  collation  utf-8 
1
N'Șc'使用Latin1_General_CI_AS排序规则将N'C'的重复密钥视为
我有一个带有唯一键的表，该键包括一NVARCHAR(50)列（是否正确，但在那里）。因此，当尝试插入Șc或C（与插入顺序无关）时，由于排序规则问题，它在第二个插入处中断。这是错误： （受影响的1行）消息2601，级别14，状态1，行16无法在具有唯一索引'IX_TestT'的对象'dbo.testT'中插入重复的键行。重复的键值为（C）。 选择返回： 数据库默认排序规则为Latin1_General_CI_AS。花了一些时间研究如何解决该问题，而又没有太大改变现有的结构，但是找不到找到工作的方法。尝试了不同的排序规则和组合，一切都失败了。阅读（此处和此处）有关字符扩展等方面的信息，但仍然受阻。这是我用来复制问题的示例代码，可以随时进行修改并提出可以帮助解决此问题的任何建议。 CREATE TABLE testT ( [Default_Collation] [NVARCHAR] (50) COLLATE DATABASE_DEFAULT, [Latin1_General_CI_AS] [NVARCHAR] (50) COLLATE Latin1_General_CI_AS, [Latin1_General_CI_AI] [NVARCHAR] (50) COLLATE Latin1_General_CI_AI, [SQL_Collation] [NVARCHAR] (50) COLLATE SQL_Latin1_General_CP1_CI_AS); CREATE UNIQUE CLUSTERED INDEX [IX_TestT] ON [dbo].[testT] ([Default_Collation]) ON [PRIMARY] GO INSERT INTO testT SELECT N'Șc', --COLLATE Latin1_General_CI_AS N'Șc', --COLLATE Latin1_General_CI_AS N'Șc', …
4
为什么在单个数据库中混合列排序规则被认为是不好的？
有两个原因促使我问这个问题： tSQLt当存在具有非默认归类的列时 ，T-SQL测试框架tSQLt认为它是“高严重性”问题。测试的作者指出以下内容： 我不建议每个字符串列都应具有与数据库默认排序规则匹配的排序规则。相反，我建议，如果有所不同，应该有充分的理由。 但是，如上所述，失败测试的严重性被认为是很高的。 Octopus Deploy 在配置Octopus Deploy Server时，在OctopusServer-instance初始化期间，安装失败并出现致命错误。与错误消息相关的文章没有解释为什么这样做是必需的，而只是指出，从（包括）Octopus 3.8版开始，它将成为将来部署的要求。 作为附带说明，RedGate的CI工具包DLM自动化套件支持具有多种排序规则的部署，而不会产生任何抱怨。 对我而言，将所有列排序规则保留为数据库默认值的建议似乎更像是准则或最佳实践。为什么有些人将其视为如此严重的错误？
3
将某些阿拉伯字符视为相同
在阿拉伯语中，我们有ا（alef）和أ（带有hamza的alef）之类的字符。 用户可以互换地编写它们，而我们想互换地进行搜索。SQL Server将它们视为单独的字符。如何使SQL将它们视为相同字符？ 我曾想在插入时用ا（alef）替换所有أ（alef用hamza），但是我们有很多阿拉伯语的替代品，而不仅仅是ا（alef）和أ（带有hamza的alef）。 我尝试过Arabic_CI_AS，Arabic_CI_AI但这不能解决问题。 这是重新生成问题的脚本： CREATE TABLE [dbo].[TestTable] ( [ArabicChars] [nvarchar](50) NOT NULL, CONSTRAINT [PK_TestTable] PRIMARY KEY CLUSTERED ( [ArabicChars] ASC ) ) ON [PRIMARY]; INSERT INTO TestTable values (N'احمد'); INSERT INTO TestTable values (N'أحمد'); SELECT * FROM TestTable WHERE ArabicChars like N'ا%'; 结果是： ArabicChars احمد (1 row(s) affected) …
1
ORDER BY和字母和数字混合字符串的比较
我们需要对值进行报告，这些值通常是数字和字母的混合字符串，需要“自然”排序。诸如“ P7B18”或“ P12B3”之类的东西。@字符串主要是字母序列，然后是数字交替。但是，这些段的数量和每个段的长度可能会有所不同。 我们希望这些数字部分按数字顺序排序。显然，如果我直接使用来处理这些字符串值ORDER BY，则“ P12B3”将出现在“ P7B18”之前，因为“ P1”早于“ P7”，但是我想反过来，因为“ P7”自然会在前面“ P12”。 我还希望能够进行范围比较，例如@bin < 'P13S6'此类。我不必处理浮点数或负数；这些严格来说是我们要处理的非负整数。字符串长度和段数可能是任意的，没有固定的上限。 在我们的案例中，字符串大小写并不重要，尽管如果有一种方法可以按排序规则识别的方式执行此操作，那么其他人可能会觉得有用。所有这一切中最丑陋的部分是我希望能够在WHERE子句中同时进行排序和范围过滤。 如果我在C＃中执行此操作，那将是一个非常简单的任务：进行一些解析以将alpha与数字分离，实现IComparable，基本上就可以完成。当然，至少就我所知，SQL Server似乎没有提供任何类似的功能。 有人知道有什么好办法可以使这项工作吗？是否有一些鲜为人知的功能来创建实现IComparable的自定义CLR类型，并使它的行为符合预期？我也不反对愚蠢的XML技巧（另请参阅：列表串联），并且服务器上也提供了CLR regex匹配/提取/替换包装器功能。 编辑： 作为一个更详细的示例，我希望数据表现出这样的效果。 SELECT bin FROM bins ORDER BY bin bin -------------------- M7R16L P8RF6JJ P16B5 PR7S19 PR7S19L S2F3 S12F0 例如，将字符串分成所有字母或所有数字的记号，并分别按字母或数字对它们进行排序，最左边的记号是最重要的排序术语。就像我提到的那样，如果实现IComparable，.NET无疑是小菜一碟，但是我不知道如何（或是否）可以在SQL Server中实现这种功能。在使用它的10年左右的时间里，这肯定不是我遇到过的事情。
3
触发更改创建时的数据库排序规则
我正在尝试创建一个触发器，以更改数据库创建时的排序规则，但是如何捕获触发器中要使用的数据库名称？ USE master GO CREATE TRIGGER trg_DDL_ChangeCOllationDatabase ON ALL SERVER FOR CREATE_DATABASE AS declare @databasename varchar(200) set @databasename =db_name() ALTER DATABASE @databasename COLLATE xxxxxxxxxxxxxxxxxxx GO 显然，这是行不通的。
2
将Unicode转换为非Unicode /将NVARCHAR转换为VARCHAR时自动翻译
Unicode代码点9619是一个称为“深色阴影”的字符：▓（http://unicode-table.com/en/search/?q=9619）。 使用SQL_Latin1_General_CP1_CI_AS归类和1252代码页，我希望将Unicode字符转换/转换为非Unicode数据类型将导致出现问号（?），因为代码页1252似乎不包含此字符，并且这似乎是SQL Server的无法进行转换时的行为。 所以我的问题是：为什么SQL Server将此字符转换为ASCII代码166，即“管道，竖线损坏”：¦？ SELECT NCHAR(9619), CAST(NCHAR(9619) AS CHAR(1)), ASCII(CAST(NCHAR(9619) AS CHAR(1)))
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.