TSQL中SqlParameters异常：非法值还是排序规则问题？

这个问题我之前碰到过类似的情况，核心矛盾大概率出在字符编码/数据类型的不匹配上，咱们一步步拆解来看：

1. 先理清直接SQL与参数化查询的本质差异 #

你直接执行SELECT * FROM MyTable WHERE MyCol='01««01'能查到数据，说明不带N前缀的字符串常量和MyCol列的存储编码是完全匹配的。但参数化查询用了N'01««01'（Unicode字符串），这里就可能触发类型不匹配的问题：

• 如果MyCol是varchar（非Unicode）类型，参数用nvarchar会触发隐式类型转换：SQL Server会把MyCol的varchar值转换成nvarchar来和参数比较，这个转换过程极容易出现编码偏差；
• 如果MyCol是nvarchar类型，那要确认你参数里的N'01««01'和列中存储的字符二进制是否完全一致。

2. 验证字符的实际编码 #

你提到的«字符是关键突破口：

• ASCII 171对应的是左双角引号（«），varchar下二进制是0xAB；
• ASCII 174对应的是注册商标符号（®），二进制是0xAE；
• Unicode下的«，二进制是0xAB00（UTF-16LE编码，nvarchar的存储格式）。

你可以执行这几个语句做对比验证：

-- 查看直接查询中字符串的二进制（varchar格式）
SELECT CONVERT(varbinary(max), '01««01') AS VarcharBinary;

-- 查看参数化中字符串的二进制（nvarchar格式）
SELECT CONVERT(varbinary(max), N'01««01') AS NvarcharBinary;

-- 查看表中实际存储的二进制值
SELECT CONVERT(varbinary(max), MyCol) AS ColumnBinary FROM MyTable WHERE MyCol='01««01';

如果ColumnBinary和VarcharBinary一致，但和NvarcharBinary不同，那说明MyCol是varchar类型，参数化用nvarchar就会导致不匹配。

3. 针对性解决方案 #

情况1：MyCol是varchar类型 #

修改参数化查询，把参数类型改成varchar，同时参数值去掉N前缀：

EXEC executesql 
    'SELECT * FROM MyTable WHERE MyCol=@p1',
    N'@p1 varchar(6)', -- 注意这里第二个参数必须是nvarchar，所以带N前缀
    @p1='01««01'; -- 参数值是varchar，不带N

这样参数和列的类型、编码完全匹配，就能正常查到数据。

情况2：MyCol是nvarchar类型 #

如果列是Unicode类型，先确认ColumnBinary和NvarcharBinary是否一致：

• 如果不一致，说明你输入的«和表中存储的不是同一个字符（比如可能是视觉相似的Unicode异体字符），需要先获取表中字符的Unicode值，再构造参数：

  -- 查看表中目标字符的Unicode值
  SELECT UNICODE(SUBSTRING(MyCol, 3, 1)) AS CharUnicode FROM MyTable WHERE MyCol='01««01';
  -- 用该Unicode值构造精准参数
  DECLARE @p1 nvarchar(6) = '01' + NCHAR(171) + NCHAR(171) + '01';
  EXEC executesql 'SELECT * FROM MyTable WHERE MyCol=@p1',N'@p1 nvarchar(6)',@p1=@p1;
  

4. 关于排序规则的补充说明 #

你尝试的排序规则调整没用，是因为编码不匹配的优先级高于排序规则。排序规则只影响字符的比较逻辑（比如大小写、重音是否敏感），但如果两个字符的二进制编码本身就不一样，再怎么指定排序规则也不会匹配。

内容的提问来源于stack exchange，提问作者Simon Woods