вы должны использовать NVARCHAR в любое время вы должны хранить несколько языков. Я считаю, что вы должны использовать его для азиатских языков, но не цитируйте меня на этом.

вот проблема, если вы возьмете русский язык, например, и сохраните его в varchar, вы будете в порядке, пока вы определяете правильную кодовую страницу. Но предположим, что вы используете английскую sql-установку по умолчанию, тогда русские символы не будут обрабатываться правильно. Если вы используете NVARCHAR (), они будут обработаны правильно.

Edit

хорошо, позвольте мне процитировать MSDN и maybee я был конкретным, но вы не хотите хранить более одной кодовой страницы в столбце varcar, в то время как вы можете вы не должны

когда вы имеете дело с текстовыми данными, которая хранится в char, varchar в, varchar (max), или тип текстовых данных, самое важное ограничение для рассмотрения это только информация из одного кодовая страница может быть проверена с помощью система. (Вы можете хранить данные от несколько кодовых страниц, но это не так рекомендуемый.) Точная кодовая страница используется для проверки и хранения данных зависит о сопоставлении столбцов. Если параметры сортировки на уровне столбцов не было определены параметры сортировки базы данных предназначенный. Чтобы определить кодовую страницу что используется для данного столбца можно использовать свойство COLLATIONPROPERTY функции, как показано в следующем примеры кода:

вот еще:

в этом примере иллюстрирует тот факт, что много локалей, как грузинский и Хинди, не имеют кодовых страниц, так как они параметры сортировки только в Юникоде. Те параметры сортировки не подходят для столбцы, использующие char, varchar или тип текстовых данных

Так что грузинский или хинди действительно нужно хранить как nvarchar. Арабский язык также является проблемой:

еще одна проблема, с которой вы можете столкнуться невозможность хранения данных, когда нет все персонажи, которых вы хотите поддержка содержится в коде страница. Во многих случаях, Windows считает конкретная кодовая страница должна быть " лучшей подогнать" страницы кодекса, то есть никакой гарантии, что вы можете положиться на кодовая страница для обработки всего текста; это просто лучший из доступных. Один примером этого является арабский шрифт: он поддерживает широкий спектр языков, в том числе белуджи, берберы, фарси, Кашмирский, Казахский, Киргизский, Пушту, Синдхи, уйгур, урду и многое другое. Все эти языки имеют дополнительные иероглифы, кроме тех, что на арабском языке язык, определенный в коде Windows страница 1256. Если вы попытаетесь сохранить эти дополнительные символы в столбец без Юникода, который имеет арабский язык параметры сортировки, символы являются превращается в вопросительные знаки.

Что-то, что нужно иметь в виду, когда вы используете Unicode, хотя вы можете хранить разные языки в одном столбце, вы можете сортировать только с помощью одной сортировки. Есть языки, которые используют латинские символы, но не вроде как и другие латинские языки. Акценты-хороший пример этого, я не могу вспомнить пример, но был восточноевропейский язык, чей Y не сортировался, как английский Y. тогда есть испанский ch, который испанские пользователи expet сортируются после h.

в целом со всеми проблемами, с которыми вам приходится иметь дело при работе с интернационализацией. Это мое мнение, что проще просто использовать символы Юникода с самого начала, избежать дополнительных преобразований и взять пробел. Отсюда и мое заявление ранее.

греческий должен был бы UTF-8 на N типов столбцов: αβγ;)

Джош говорит: "....Что-то, что нужно иметь в виду, когда вы используете Unicode, хотя вы можете хранить разные языки в одном столбце, вы можете сортировать только с помощью одной сортировки. Есть некоторые языки, которые используют латинские символы, но не сортируются, как другие латинские языки. Акценты-хороший пример этого, я не могу вспомнить пример, но был восточноевропейский язык, чей Y не сортировался, как английский Y. тогда есть испанский ch, который испанские пользователи expet будут отсортированы после h."

Я носитель испанского языка и "ch" - это не буква, а два "c" и "h", а испанский алфавит похож: abcdefghijklmn ñ opqrstuvwxyz Мы не ожидаем "ч" после "ч", но " я" Алфавит такой же, как и в английском языке, за исключением-или в HTML "&ntilde ;"

Алекс

TL; DR;
Unicode - (nchar, nvarchar и ntext)
Не-Юникод - (char, varchar и text).

от MSDN

параметры сортировки в SQL Server обеспечивают правила сортировки, регистр и акцент свойства чувствительности для ваших данных. Параметры сортировки, которые используются с символьные типы данных, такие как char и varchar диктовать кодовую страницу и соответствующие символы, которые могут быть представлены для сведения тип.

предполагая, что вы используете параметры сортировки SQL по умолчанию SQL_Latin1_General_CP1_CI_AS затем следующий скрипт должен вывести все символы, которые вы можете разместить в VARCHAR поскольку он использует один байт для хранения одного символа (256 всего) если вы не видите его в списке напечатать - нужно NVARCHAR.

declare @i int = 0;
while (@i < 256)
begin
print cast(@i as varchar(3)) + '  '+  char(@i)  collate SQL_Latin1_General_CP1_CI_AS 
print cast(@i as varchar(3)) + '  '+ char(@i)  collate Japanese_90_CI_AS  
set @i = @i+1;
end

если вы измените параметры сортировки, скажем, на японский, вы заметите, что все странные европейские буквы превратились в нормальные, а некоторые символы-в ? метки.

Unicode-это стандарт для сопоставления кодовых точек с символами. Потому что он предназначен для покрытия всех символов всех языков мир, нет необходимости в разных кодовых страницах для обработки разных набор символов. Если вы храните символьные данные, которые отражают несколько языки, всегда используйте типы данных Unicode (nchar, nvarchar и ntext) вместо типов данных, отличных от Юникода (char, varchar и text).

в противном случае ваша сортировка будет идти странный.