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

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

Редактирование

хорошо позволило мне кавычка MSDN , и возможно я был к определенному, но Вы не хотите хранить более тогда одну кодовую страницу в varcar столбце, в то время как Вы можете, Вы не были должны

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

Вот является еще немного:

Этот пример иллюстрирует то, что много локалей, такой столь же грузинский и хинди, не имеют кодовых страниц, как они - сопоставления только для Unicode. Те сопоставления не подходят для столбцов, которые используют символ, varchar, или тип данных text

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

Другой проблемой, с которой Вы могли бы встретиться, является неспособность хранить данные если не все символы, которые Вы хотите поддерживать, содержатся в кодовой странице. Во многих случаях Windows полагает, что конкретная кодовая страница "лучшая пригодная" кодовая страница, что означает, что нет никакой гарантии, что можно полагаться на кодовую страницу для обработки всего текста; это - просто лучшее доступное. Примером этого является арабский сценарий: это поддерживает огромное количество языков, включая белуджа, бербера, фарси, кашмирца, казаха, киргиза, пушту, Sindhi, уйгурский язык, урду, и т.д. Все эти языки имеют дополнительные символы вне тех, которые на арабском языке, как определено в кодовой странице 1256 Windows. При попытке сохранить эти дополнительные символы в столбце не-Unicode, который имеет арабское сопоставление, символы преобразовываются в вопросительные знаки.

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

, В целом, со всеми проблемами необходимо иметь дело с при контакте с internalitionalization. Именно мое мнение легче просто использовать символы Unicode от запуска, избежать дополнительных преобразований и получить удар пространства. Следовательно мой оператор ранее.

Греческому языку был бы нужен UTF-8 на типах столбца N: О±ОІОі;)

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

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

Алекс