Почему .NET Framework StreamReader/Writer по умолчанию использует кодировку UTF8?

Я просто смотрю на конструкторы для StreamReader/Writer и отмечаю, что он использует UTF8 по умолчанию. Кто-нибудь знает, почему это так? Я бы предположил, что было бы безопаснее использовать Unicode по умолчанию.


person Quibblesome    schedule 13.05.2009    source источник


Ответы (4)


UTF-8 будет работать с любым документом ASCII и, как правило, более компактен, чем UTF-16, но по-прежнему охватывает весь Unicode. Я бы сказал, что UTF-8 гораздо более распространен, чем UTF-16. Это также значение по умолчанию для XML (когда не указана ни спецификация, ни явная кодировка).

Как вы думаете, почему по умолчанию лучше использовать UTF-16? (Вот что такое Encoding.Unicode.)

РЕДАКТИРОВАТЬ: я подозреваю, что вы не совсем понимаете, что может обрабатывать UTF-8. Эта страница довольно ясно описывает это, включая то, как кодируется любой конкретный символ Unicode. Это кодировка с переменной шириной, но она охватывает весь Юникод.

person Jon Skeet    schedule 13.05.2009
comment
Я бы предположил, что (поправьте меня, поскольку я ошибаюсь;)) поскольку .NET изначально использует UTF16 для строк, будут сценарии (возможно, в разных культурах), где он пытается вывести символ, который UTF8 не может обработать. - person Quibblesome; 13.05.2009
comment
@Quarrelsome UTF-8 — это кодировка символов переменной длины, которая может представлять любой символ из стандарта Unicode. Он просто будет использовать больше октетов (8-битных байтов), до 4 из них. - person Anton Gogolev; 13.05.2009

UTF8 является Unicode, точнее, одним из типов кодировки Unicode.

Что еще более важно, он обратно совместим с ASCII, а также является стандартным по умолчанию для XML и HTML.

person blowdart    schedule 13.05.2009

«Юникод» — это название стандарта, поэтому такой кодировки, как «Юникод», не существует. Скорее, есть два метода отображения: UTF и UCS.

Что касается части «почему», UTF-8 имеет максимальную совместимость с ASCII.

person Anton Gogolev    schedule 13.05.2009
comment
Что ж, в среде .NET кодировка UTF-16 называется Unicode. (Свойство Encoding.Unicode.) Это не помогает устранить путаницу. ;) - person Guffa; 13.05.2009

Как уже говорили все остальные, UTF-8 является стандартом кодирования в Unicode. UTF-8 использует переменное количество байтов для кодирования всех существующих символов Юникода.

Все символы ASCII представлены как есть, так что файлы ASCII теперь можно читать без лишних хлопот. Как только для байта в потоке установлен 8-й бит (самый старший бит,> 127), это запускает считыватель, чтобы объединить его со следующим байтом, пока он не станет ‹128. Комбинация считается за 1 символ.

В LATIN-1 (ANSII) есть символы, которые кодируются двумя символами: например, é кодируется как e и ´. Следовательно, длина ('é') равна 2.

Windows использует внутреннюю кодировку UTF-16, что ограничивает количество кодируемых символов до 64 КБ, что ни в коем случае не является всеми символами Unicde. UTF-32 пока позволяет использовать все символы, но также искусственно ограничен. И оба не совместимы с ASCII снизу вверх, так как имеют начальные нули:

A = ASCII h41 = UTF-8 h41 = UTF-16 h0041 = UTF-32 h00000041

Существуют также кодировки с прямым и обратным порядком байтов:

A = UTF-16 big endian h0041 = UTF-16 little endian h4100

Представьте, что вы используете кодировку UTF16 или UTF32 для сохранения ваших файлов. Они будут (для текстовых файлов) вдвое или вчетверо больше по размеру по сравнению с ASCII и UTF-8 (UTF-8, если используются только символы ascii). UTF-8 не только позволяет использовать все символы стандарта Unicode даже для будущих улучшений, но и эффективно экономит место.

Обычно первые два байта файла, спецификация или маркер порядка байтов, говорят вам, какой стандарт кодирования используется. Если опустить, XML и StreamRedaer используют UTF-8, как вы выяснили. Это опять-таки имеет смысл, так как файлы ASCII не имеют спецификации и поэтому в большинстве случаев читаются корректно. Это может быть не так для файлов, использующих всю LATIN-1.

person Ralph M. Rickenbach    schedule 13.05.2009