UTF-8 или UTF-16 или UTF-32 или UCS-2

Question

Я проектирую новую CMS, но хочу разработать ее так, чтобы она отвечала всем моим будущим потребностям, таким как многоязычный контент, поэтому я подумал, что Unicode (UTF-8) - лучшее решение

Но после некоторого поиска я получил этоarticle

http://msdn.microsoft.com/en-us/library/bb330962%28SQL.90%29.aspx#intlftrql2005_topic2

Так что я теперь запутался, что использовать сейчас UTF-8 / UTF-16 / UTF-32 / UCS-2

, что лучше для многоязычного контента и производительности и т. Д.

PS: я использую Asp.net и c # и SqlServer 2005

Заранее спасибо

Answer 1

Так что я теперь запутался, что использовать сейчас UTF-8 / UTF-16 / UTF-32 / UCS-2

, что лучше для многоязычного контента и производительности и т. Д.

UCS-2 устарел: он больше не может представлять каждый символ Юникода.UTF-8, UTF-16 и UTF-32 могут все.Но почему есть три разных способа кодирования одних и тех же символов?

Потому что в старые времена программисты делали два больших предположения о строках.

1. То, что строки состоят из 8-битных единиц кода.
2. Этот 1 символ = 1 единица кода.

Проблема для многоязычного текста (или даже для одноязычного текста, если этот язык оказался китайским, японским или корейским), заключается в том, чтоэти два допущения в совокупности ограничивают вас до 256 символов.Если вам нужно представить более, чем это, вам нужно отбросить одно из предположений.

Если оставить предположение № 1 и отказаться от предположения № 2, вы получите variable-width (или многобайтовая ) кодировка .На сегодняшний день наиболее популярным кодированием переменной ширины является UTF-8.

Предположение об отбрасывании # 1 и сохранение предположения # 2 дает вам кодирование широких символов .Unicode и UCS-2 были изначально разработаны для использования 16-битного кодирования с фиксированной шириной, что позволило бы получить 65 536 символов.Первые пользователи Unicode, такие как Sun (для Java) и Microsoft (для NT), использовали UCS-2.

Однако спустя несколько лет стало понятно, что даже , что не было 'Это достаточно для всех, поэтому диапазон кодов Unicode был расширен.Теперь, если вам нужна кодировка фиксированной ширины, вы должны использовать UTF-32.

Но Sun и Microsoft написали огромные API-интерфейсы, основанные на 16-битных символах, и не были в восторге от переписывания их для 32-немного.К счастью, по-прежнему существовал блок из 2048 неназначенных символов из исходной 65,536-символьной «Базовой многоязычной плоскости», которую можно было назначить в качестве «суррогатов» для использования в парах для представления дополнительных символов: формы кодирования UTF-16.К сожалению, UTF-16 не соответствует ни из двух исходных допущений: он не-8-битный и переменной ширины.

В итоге:

ИспользованиеUTF-8, когда важно предположение о 8-битных единицах кода.

Это относится к:

• Имена файлов и связанные вызовы ОС в системах Unix, в которых установленытрадиция допускает кодирование переменной ширины, но не может принимать '\x00 байтов в строках и, следовательно, не может использовать UTF-16 или UTF-32.На самом деле UTF-8 изначально был предназначен для ОС на базе Unix (Plan 9).
• Протоколы связи, разработанные на основе потоков октетов.
• Все, что требует двоичногосовместимость с US-ASCII, но не дает специальной обработки значениям байта выше 127.

Используйте UTF-32, когда важно допущение кодирования с фиксированной шириной.

Это полезно, когда вы заботитесь о свойствах символов в отличие от их кодировки, таких как эквиваленты Unicode для функций ctypes.h, таких как isalpha, isdigit, toupper,и т. д.

Используйте UTF-16, когда ни одно из предположений не является столь важным, но ваша платформа использовала UCS-2.

Вы пишете для Windows или для.NET Framework предназначен для этого?Для Java?Тогда UTF-16 - ваш тип строки по умолчанию;может также использовать его.

Поскольку вы используете C #, все ваши строки будут закодированы в UTF-16.ASP.NET будет кодировать фактические HTML-страницы в UTF-8, но это делается негласно, и вам не нужно об этом заботиться.

Соображения о размере

Для трех форм кодирования UTF требуетсяразличные объемы памяти для представления символа:

• Символам от U + 0000 до U + 007F (ASCII) требуется 1 байт в UTF-8, 2 байта в UTF-16 или 4 байта в UTF-32.
• Символы от U + 0080 до U + 07FF (символы IPA, греческий, кириллица, армянский, иврит, арабский, сирийский, тхана, нко) требуют 2 байта в UTF-8, 2 байта в UTF-16 или 4 байта вUTF-32.
• Символы от U + 0800 до U + FFFF (остальная часть BMP, в основном для азиатских языков) требуют 3 байта в UTF-8, 2 байта в UTF-16 или 4 байта в UTF-32.
• Символы U + 10000 до U + 10FFFF требуют 4 байта во всех трех формах кодирования.

Таким образом, если вы хотите сэкономить место, используйте UTF-8, если вашсимволы в основном ASCII или UTF-16, если ваши символы в основном азиатские.

Answer 2

Это не проблема, потому что вы говорите:

Я использую Asp.net и c #, а SqlServer 2005

SqlServer использует UTF-16 в некоторых местах(ntext, nvarchar, nchar) и UTF-8 в нескольких XML-ориентированных местах, без каких-либо странных действий.

C # использует UTF-16 во всех своих строках, с инструментами для кодирования, когда дело доходит дос потоками и файлами, которые выводят нас на ...

ASP.NET по умолчанию использует UTF-8, и трудно представить себе время, когда это не удачный выбор (даже с азиатскими языкамитекстовое сжатие таких языков в сочетании с тем фактом, что имена и символы, имеющие особое значение в HTML, CSS, javascript, большинстве приложений XML и других потоках, которые вы будете отправлять, находятся в диапазоне от U + 0000 до U + 007F, что дает преимуществоUTF-16 по сравнению с UTF-8 в этом диапазоне менее значим, чем с обычным текстом азиатских языков).

Разговор между UTF-16 SqlServer и C # и UTF-8, который ASP.NET делает вчтение и письмо,Это сделано для вас с настройками по умолчанию, но так как это один бит, который вы можете легко изменить, поэтому мой ответ будет использовать UTF-8.На самом деле вы будете использовать комбинацию -8 и -16, но вы не заметите большую часть времени (заметили ли вы, что вы уже это делаете).

SQL Server немногоменьше прощения, хотя бы потому, что во многих устаревших примерах текст, ожидаемый для потребления человеком, помещается в поля varchar, text или char.Используйте их исключительно для кодов (например, все коды стран ISO находятся в диапазоне char (2), так что nchar (2) будет просто тратить пространство), и только nvarchar, ntext и nchar для вещей, которые люди, а не машины будут читать и писать.

Answer 3

Прежде всего, забудьте о UCS-2: он устарел. Он содержит только подмножество символов Unicode. Забудьте и о UTF-32: он очень большой и очень избыточный. Это не полезно для передачи данных.

На веб-страницах наиболее экономичным является UTF-8, если большинство языков, с которыми вы работаете, являются западными (латинский, кириллица, греческий и т. Д.). Но если пропускная способность и время загрузки не являются проблемой, вы также можете использовать UTF-16. Просто убедитесь, что вы всегда знаете, в каком формате находятся данные, когда обрабатываете byte[]. И не пытайтесь конвертировать в устаревшие 8-битные наборы символов, такие как ISO-8859 или Windows-1252, потому что в этом случае вы потеряете данные.

В коде C # ваши string объекты будут внутренне находиться в UTF-16, и вы ничего не можете с этим поделать. Таким образом, ваши обычные строковые операции (например, Substring()) не зависят от выбранного вами формата вывода. Можно утверждать, что это повышает производительность при кодировании в формате UTF-16, но оно того не стоит, если вы собираетесь передавать его через Интернет, где стоимость передачи большего UTF-16 превышает крошечный выигрыш при обработке *. 1008 *

В SQL Server вы должны использовать nvarchar(...).

Answer 4

UTF-8 или UTF-16 являются хорошими вариантами.Они оба предоставляют вам доступ ко всему диапазону кодовых точек Unicode без использования 4 байтов для каждого символа.

На ваш выбор будет влиять язык, который вы используете, и его поддержка этих форматов.Я считаю, UTF-8 лучше всего работает с ASP.NET, но это будет зависеть от того, что вы делаете.

UTF-8 часто является хорошим выбором в целом, потому что он хорошо работает скод, который ожидает только ASCII, тогда как UTF-16 нет.Это также самый эффективный способ представления контента, состоящий в основном из нашего английского алфавита, но при этом позволяющий при необходимости использовать полный репертуар Unicode.Хорошей причиной для выбора UTF-16 было бы, если бы ваш язык / фреймворк использовал его изначально или если вы собираетесь использовать в основном символы, отсутствующие в ASCII, например азиатские языки.

Answer 5

Увы, я думаю, проблема в том (как он заявляет в начале), что у него есть SQL Server 2005, который, если я прав, все еще использует UCS2, поскольку он кодирует N-типы данных (NVARCHAR и со)

Возможно, ему придется смириться с ограничением, которое приносит или обновить до более новой версии SQL Server. Как правило, то, что вы увидите, если начнете создавать дамп UTF-16, то есть стандартный юникод, используемый в .NET, так это то, что, как указано, некоторые символы будут потеряны и заменены на? отметки в таблицах базы данных.

Answer 6

Краткое примечание: в принципе все может быть представлено в кодировке Unicode . UTF-8 - это всего лишь одна кодировка , способная представлять все символы в этом наборе.

UCS-2 больше не подходит для использования. Он не может содержать символы за пределами U + FFFF.

Какая из оставшихся трех зависит от того, какие операции вы хотите выполнить над текстом. UTF-8 (обычно не всегда!) Будет занимать меньше места на диске, представляющем те же данные, и является строгим расширенным набором ASCII, поэтому он может уменьшить объем необходимого транскодирования. Однако вы не можете проиндексировать вашу строку или найти ее длину в постоянном времени.

UTF-32 позволяет вам найти длину строки и индексировать ее за постоянное время. Это не расширенный набор ASCII, как UTF-8. Это также требует, чтобы у вас было 4 байта на кодовую точку, но эй, дисковое пространство дешево.