Ад Unicode (в Windows) [закрыто]

В его нынешнем виде , этот вопрос не подходит для нашего формата вопросов и ответов. Мы ожидаем, что ответы будут подтверждены фактами, ссылками или опытом, но этот вопрос, скорее всего, потребует дебатов, аргументов, опросов или расширенного обсуждения. Если вы считаете, что этот вопрос можно улучшить и, возможно, снова открыть, посетите справочный центр , чтобы получить рекомендации.

Закрыт 8 лет назад .

Сегодня я проснулся и почувствовал, что что-то ужасно не так с моим кодом и каждой библиотекой, которую я когда-либо использовал, и я думаю, что был прав ... (или укажите, пожалуйста, где мои рассуждения ошибочны)

Давайте начнем на десять или два года назад, все в мире было хорошо. Я говорил со своим соседом, и он говорил на том же языке: просто на английском. Мне, моему соседу и Windows казалось очевидным хранить нашу строку в 8-битных char s, потому что все символы, которые мы использовали, могли быть сохранены в доступных комбинациях 2 ^ 8 = 256.

Затем чудо Быть Интернет пришел и позволил мне поговорить с некоторыми друзьями в Европе (у которых не было времени учить английский). Это стало трудным с нашим форматом char , количество используемых символов легко превысило 256, поэтому в нашем крайне упрощенном видении мы решили использовать 16-битные wchar_t s. Что-то под названием юникод UCS-2. Он имеет 2 ^ 16 = 65 536 доступных комбинаций, и этого должно быть достаточно для каждого языка в мире! Убедившись в своей правоте, мы даже добавили 16-битные функции Windows API W , такие как MessageBoxW и CreateWindowW . Мы убедили каждого программиста в своей религии и отговорили использовать злые 8-битные аналоги ( MessageBoxA и CreateWindowA ) и автоматически сопоставили вызов MessageBox с MessageBoxW путем определения _UNICODE в наших сборках. Поэтому мы также должны использовать функции wcs вместо старых функций str (например, strlen теперь должно быть wcslen , либо использовать автоматически mapped _tcslen ).

Потом дела пошли плохо, оказалось, что в мире есть и другие люди, которые использовали даже более странные символы (без обид, чем наш): японцы, китайцы и т. д. например, китайский язык содержит более 70 000 различных символов. Произошло много ругательств, и у нас появился новый тип юникода: UTF-16. Он также использует 16-битный тип данных, но для некоторых символов требуется два 16-битных значения (называемые суррогатной парой ). Это означает, что мы не можем использовать индексы для этих 16-битных строк (например, theString [4] может не возвращать 5-й символ). Для исправления Windows API было решено, что все функции W теперь должны поддерживать формат UTF-16, это было простое решение, поскольку все старые строки UCS-2 также были действительными строками UTF-16. Однако, поскольку мы смелые программисты, теперь мы используем функции wcs . К сожалению, эти функции не учитывают суррогатные данные и по-прежнему соответствуют формату UCS-2 ...

Тем временем на темном чердаке была разработана еще одна более компактная форма Unicode: UTF-8. Используя 8-битный тип данных, большинство западных языков может быть сохранено в одном 8-битном значении, как в старые времена. Когда сохраняется более экзотический глиф, используются несколько 8-битных значений, для большинства европейских языков 2 будет достаточно. Однако он может расширить до 4 из этих значений, по существу создавая 32-битный тип хранилища. Так же, как это толстый брат UTF-16, мы не можем использовать индексы для этих строк. Из-за более компактного формата UTF-8 теперь широко используется повсюду в Интернете, поскольку он экономит полосу пропускания.

Хорошо, вы справились с моей длинной рецензией :) Теперь у меня есть несколько вопросов / интересных моментов:

Хорошо, я вполне доволен использованием UTF-8 для хранения. Когда я читаю файл (с диска или HTTP-ответа), я обнаруживаю UTF-8 подпись «\ xEF \ xBB \ xBF» и пропускаю содержимое через MultiByteToWideChar , что оставляет мне строку UTF-16. Я могу использовать это с функциями API W , без проблем. Но теперь я хочу изменить строку, заменить некоторые символы и т. Д. Старые добрые wcs функции больше не годятся, какие основные строковые функции поддерживают UTF-16? Или есть какая-то великолепная библиотека, о которой я не знаю? Edit: Кажется, ICU - довольно хорошее решение. Я также обнаружил, что функции wcs не совсем бесполезны, вы можете, например, все еще использовать wcsstr для поиска, по сути, он просто сравнивает wchar_t s. Единственная проблема - длина строки.
У вас нет ощущения, что была допущена уродливая ошибка, когда мы были вынуждены использовать 16-битные несовершенные W функции. Разве проблема не должна была быть обнаружена на гораздо более раннем этапе и позволить всем исходным функциям API принимать строки UTF-8 и включать соответствующие процедуры обработки строк? Или это уже возможно, и я ужасно ошибаюсь? Edit: Может быть, это был глупый вопрос, ретроспективный взгляд действительно прекрасен, сейчас бесполезно кого-то принижать;)
Для быстрого доступа индекса к символам мы должны хранить строки в 32-битных значениях. Это обычное дело? (Я слышу, как вы думаете: а затем мы сталкиваемся с внеземным языком, требующим большего количества комбинаций, и все начинается снова ...) Кажется, обратная сторона этого подхода заключается в том, что мы должны преобразовывать строку обратно в UTF-16 каждый раз, когда мы делаем вызовы Windows API. Правка: просто процитирую Альфа П. Штайнбаха один символ на индекс - безнадежная мечта , теперь я это понимаю. Одна вещь, которую я полностью упустил, - это диакритические знаки . Я также считаю, что это хорошо - обрабатывать в собственной кодировке ОС (для Windows UTF-16). Хотя UTF-8 был бы лучшим выбором, мы сейчас застряли с UTF-16, нет смысла конвертировать туда и обратно между вашим кодом и API. Как предлагается ниже, я сам буду отслеживать части строки по указателям, а не по количеству символов.

Думаю, вы заслужили себе чашку прекрасного чая, пытаясь справиться с этим длинным вопросом, дайте ответ, прежде чем отвечать;)

Изменить: я принимаю тот факт, что мой вопрос закрыт, это было бы лучше для сообщения в блоге, но опять же, я не веду блог. Я думаю, что эта кодировка символов очень важна и должна стать следующей темой в любой книге по программированию после простого примера hello world! Размещение его здесь привлекает внимание многих экспертов, эти люди не читают случайные блоги, и я очень дорожу их мнением. Так что спасибо всем за участие.

задан the_source 12 August 2011 в 15:26

0 ответов

Другие вопросы по тегам:

c++ winapi utf-8 utf-16 ucs2

Ад Unicode (в Windows) [закрыто]

0 ответов

Похожие вопросы: