Есть ли способ обнаружить символы Unicode в столбце nvarchar
Столбец ввода не был реализован достаточно хорошо, чтобы ограничить символы электронной почты римскими буквами ... поэтому французские и испанские символы с диакритическими знаками попали в базу данных, но отклоняются удаленными почтовыми серверами. Есть ли простой SQL-тест?
Я пытался
where email <> try_cast(try_cast(email as varchar) as nvarchar)
Хотя в какой-то мере это, кажется, сработало, оно также кажется немного агрессивным, поскольку нашло больше совпадений, чем нет.
Ответы 3
Вы можете попробовать это:
where email like '%[^a-zA-Z0-9.@-_]%'
Вы не устанавливаете размер для varchar или nvarchar, поэтому он использует длину по умолчанию, которая, я думаю, 30. Получить адрес электронной почты более 30 символов несложно. Измените на try_cast (try_cast (email as varchar (300)) as nvarchar (300)) или что-то в этом роде.
Однако вы понимаете, что символы с диакритическими знаками, китайские, японские, арабские, хинди и другие символы теперь являются действительными адресами электронной почты? Не все серверы были обновлены для их обработки, правда, но это не значит, что это не настоящий адрес.
это полезно знать, но пока это проблема.
Вы можете попробовать
where email collate SQL_Latin1_General_CP437_BIN
<> cast(email as varchar(max)) collate SQL_Latin1_General_CP437_BIN
(Вы можете изменить varchar(max) на любую длину email, хотя он также будет работать как varchar(max).)
Если вы не используете принудительную двоичную сортировку, безопасную для Unicode, тогда она может использовать любую сортировку базы данных, которая может не работать для nchar(0x2014) (- U + 2014 EM DASH, который может быть преобразован в char(0x97) с помощью SQL_Latin1_General_CP1_CI_AS), как один из примеров .
Это также будет учитывать обратные кавычки, пробелы, табуляции, символы новой строки, любые управляющие символы, а также! "# $% & '/:; <=>? {|} ~ как Unicode.