0

データベースを循環させようとしていますが、MD5でメールアドレスをハッシュ化しています。これは私が使用して疲れたコードです：

update Recipients set MD5Email = CONVERT(VARCHAR(MAX), HASHBYTES( 'md5', NonMd5.EmailAddress ), 2)
from 
 Recipients INNER JOIN Recipients as NonMd5
on 
 Recipients.Id = NonMd5.Id

私もこれを試しましたが、同じ結果になりました。

update Recipients set MD5Email = CONVERT(VARCHAR(MAX), HASHBYTES( 'md5', Recipients.EmailAddress ), 2)
    from 
     Recipients

NonMd5.EmailAddressをハードコードされた文字列に置き換えると、正しく計算されます。何が悪いのかわかりません。

これは私のテーブルです：

CREATE TABLE [dbo].[Recipients] (
[Id] uniqueidentifier NOT NULL DEFAULT (newid()) ,
[EmailAddress] nvarchar(MAX) COLLATE Latin1_General_CI_AS NULL ,
[IsProcessed] bit NOT NULL ,
[MD5Email] nvarchar(80) COLLATE Latin1_General_CI_AS NULL ,
CONSTRAINT [PK__Recipien__3214EC0703317E3D] PRIMARY KEY ([Id])
)
ON [PRIMARY]
TEXTIMAGE_ON [PRIMARY]
GO

アップデート：

メールアドレスをtest@test.comに設定すると、次のようになります。 4767DCA4A82B295C59D18097EE7B4070

上記のコードで直接値として実行すると、これが私の結果です。

b642b4217b34b1e8d3bd915fc65c4452
4

1 に答える 1

1

ちょうどどうですか：

UPDATE dbo.Recipients 
  SET MD5Email = CONVERT(NVARCHAR(80), HASHBYTES('MD5', EmailAddress), 2);

つまり、MD5 で SHA やその他のアルゴリズムを検討する必要があり、ハッシュ出力を文字列として保存するべきではありません。varbinary を使用してください。

ここに私が得る結果があります：

SQLフィドル

今、あなたが見逃していると私が思う非常に重要な違いがあります。あなたは現在、電子メール アドレスを次のように保存していますNVARCHAR(MAX)- なぜあなたが Unicode を使用しているのかわかりません (世界のほとんどのサーバーはまだ 2 バイト文字をサポートしていません) MAX。ただし、これらを比較してください。

SELECT CONVERT(NVARCHAR(80), HASHBYTES('MD5', 'test@test.com'), 2);

SELECT CONVERT(NVARCHAR(80), HASHBYTES('MD5', N'test@test.com'), 2);
----------- this N is very important ---------^

現在の SMTP 標準を考えると、列はおそらく320 文字 (ドメイン名に 255 文字、ローカル部分に 64 文字、および @ 記号) にする必要がありMAXます (4000 文字を超える電子メール アドレスを持っている人はいません。10 億文字は気にしないでください)。 ）。そして、NVARCHAR本当に Unicode 電子メール アドレスをサポートする必要がある場合にのみ必要になります。Unicode 電子メール アドレスは、私が言ったように、今日のほとんどのメール サーバーで認識されていません。データ型を変更すると、テストと一致することがわかります。にとどまる場合はNVARCHAR、リンゴとリンゴを比較する必要があるため、テストを実行するときは、ハードコードされた値の前に . を必ず付けてくださいN。

于 2013-03-04T19:15:26.903 に答える