Encryption SQL EncryptByKey/DecryptByKey将以英语保存的数据转换为非英语字符

我正在尝试使用加密来混淆SQL数据库中的列。我开始按照中所示的步骤进行操作，这很好，但不利于生产，因为它在未加密的列中显示我试图保持安全的数据

因此，我打算将EncryptByKey应用于SQL INSERT命令，如下所示：

INSERT INTO [myTable]
VALUES (foo, 'bar', EncryptByKey(Key_GUID('EncryptionKey'), 'fooBar'));
GO

执行此命令后检查结果时，我在包含加密数据值“fooBar”（我的加密数据列设置为varbinary（128）格式）的列中看到预期的varbinary gobbledygook字符串。但是，当我尝试解密数据时，因此：

SELECT [encryptedColumn],
    CONVERT(nvarchar, DecryptByKey(encryptedColumn)) 
    AS 'Decrypted Column'
    FROM [myTable];
GO

---

值“fooBar”以楔形文字形式返回，在“DecryptedColumn”中看起来像亚洲文字。这是什么原因造成的？我使用的是SQL Server 2008 R2和AES_256加密算法。

这是另一个关于为什么让计算机猜你在想什么是一个坏主意的对象课程

当我插入新行时

INSERT INTO [myTable]
VALUES (foo, 'bar', EncryptByKey(Key_GUID('EncryptionKey'), 'fooBar'));
GO

…我忽略了指定“fooBar”是什么类型的数据。SQL在填补空白时捅了一刀，所以在解密的时候，悲剧发生了。

添加如下所示的CONVERT语句：

INSERT INTO [myTable]
VALUES (foo, 'bar', EncryptByKey(Key_GUID('EncryptionKey'), CONVERT(nvarchar(50), 'fooBar')));
GO

---

消除此类猜测，并正确解密“fooBar”。在这种情况下，“fooBar”实际上是一个nvarchar。

你的帖子给了我解决这个问题的洞察力。您的方法确实有效，您也可以在字符串“foobar”的开头添加一个“N”，如下所示：

INSERT INTO [myTable]
VALUES (foo, 'bar', EncryptByKey(Key_GUID('EncryptionKey')
       ,CONVERT(nvarchar(50), N'fooBar')));
GO

对您执行相同的操作，而无需猜测convert语句需要多少字符。。。您不必嵌入convert语句