Вы свободно владеете Unicode?

Почти 5 лет назад Джоэл Спольский написал эту статью, "Абсолютный минимум Каждый разработчик программного обеспечения Абсолютно, положительно должен знать об Unicode и наборах символов (без отговорок! )" .

Как и многие, я внимательно его прочитал, понимая, что настало время, чтобы справиться с этой "заменой для ASCII". К сожалению, через 5 лет я чувствую, что вернулся в несколько вредных привычек в этой области. У вас есть?

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

Так что для моей пользы (и я верю многим другим) могу ли я получить информацию от людей о следующем:

Как "пережить" ASCII раз и навсегда
Фундаментальное руководство при работе с Unicode.
Рекомендуемые (последние) книги и веб-сайты в Unicode (для разработчиков).
Текущее состояние Юникода (через 5 лет после статьи Джоэлса)
Будущие направления.

Я должен признать, что у меня есть фон .NET, и поэтому также будем рады получить информацию о Unicode в .NET framework. Конечно, это не должно останавливать никого, у кого есть другие предпосылки от комментариев.

Обновление: см. этот связанный вопрос, также заданный ранее в StackOverflow.

Ответ 1

Поскольку я читал статью Джоэля и некоторые другие статьи I18n, я всегда внимательно следил за кодировкой моего персонажа; И это действительно работает, если вы делаете это последовательно. Если вы работаете в компании, где стандартно использовать UTF-8, и все это знают/делают это, он будет работать.

Вот некоторые интересные статьи (помимо статьи Джоэля) по теме:

Цитата из первой статьи; Советы по использованию Unicode:

Объявите Unicode, не сражайтесь с ним; это, вероятно, правильная вещь, и если бы это было не так, вы, вероятно, должны были бы все равно.
Внутри вашего программного обеспечения храните текст как UTF-8 или UTF-16; то есть выбрать один из двух и придерживаться его.
Обмен данными с внешним миром с использованием XML по возможности; это создает целую кучу потенциальных проблем.
Попробуйте сделать свое приложение на основе браузера, а не писать собственный клиент; браузеры очень хорошо справляются с текстами мира.
Если вы используете код другой библиотеки (и, конечно же, вы), предположите, что его обработка Юникодом сломана, пока не будет доказано, что она правильная.
Если вы выполняете поиск, попробуйте передать проблемы с лингвистикой и характером для тех, кто их понимает.
Пойдите в Amazon или где-нибудь и купите последнюю версию печатного стандарта Unicode; он содержит довольно хорошо все, что вам нужно знать.
Проведите некоторое время, прокручивая веб-сайт Юникода и узнавая, как работают кодовые диаграммы.
Если вам понадобится серьезная работа с азиатскими языками, купите книгу О'Рейли по этому вопросу Кен Лунде.
Если у вас есть Macintosh, выбери и возьмите инструмент проверки шрифта Lord Pixel Unicode. Полностью прохладно.
Если вам действительно нужно будет спуститься и загрязниться данными, посетите одну из двухгодичных конференций Unicode. Все эксперты идут, и если вы не знаете, что вам нужно знать, вы сможете найти там кого-то, кто знает.

Ответ 2

Я потратил некоторое время на работу с программным обеспечением для поисковых систем. Вы не поверили бы, сколько веб-сайтов обслуживает контент с заголовками HTTP или метатегами, которые касаются кодирования страниц. Часто вы даже получите документ, который содержит как символы ISO-8859, так и символы UTF-8.

После того, как вы столкнулись с несколькими подобными проблемами, вы начинаете воспринимать правильную кодировку символов, которые вы создаете, действительно серьезно.

Ответ 3

В .NET Framework используется стандартная кодировка Windows для хранения строк, которая, как оказалось, является UTF-16. Если вы не укажете кодировку при использовании большинства текстовых классов ввода-вывода, вы будете писать UTF-8 без спецификации и читать, сначала проверяя спецификацию, затем предполагая UTF-8 (я точно знаю StreamReader и StreamWriter вести себя таким образом.) Это довольно безопасно для "немых" текстовых редакторов, которые не понимают спецификацию, но вроде грубой для более умных, которые могли бы отображать UTF-8 или ситуацию, когда вы на самом деле пишете символы вне стандарта ASCII.

Обычно это невидимо, но может занять голову интересным способом. Вчера я работал с тем, кто использовал сериализацию XML для сериализации объекта в строку с помощью StringWriter, и он не мог понять, почему кодировка всегда была UTF-16. Поскольку строка в памяти будет UTF-16, и это принудительно используется .NET, это единственное, что может сделать структура XML-сериализации.

Итак, когда я пишу что-то, что является не просто средством отбрасывания, я указываю кодировку UTF-8 с спецификацией. Технически в .NET вы всегда будете случайно осведомлены о Unicode, но только если ваш пользователь знает, как определить вашу кодировку как UTF-8.

Это заставляет меня плакать немного каждый раз, когда я вижу, что кто-то спрашивает: "Как мне получить байты строки?" и в предлагаемом решении используется Encoding.ASCII.GetBytes(): (

Ответ 4

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

Даже делать что-то простое, как расщепление слов или строк нижнего индекса, становится жестким, если вы хотите сделать это "способом Unicode".

И если вы хотите сделать это "способом Unicode", вам понадобится очень хорошая библиотека. Этот материал невероятно сложный.