Вы еще свободно владеете Юникодом?

Question

Почти 5 лет назад Джоэл Спольский написал эту статью, "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)".

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

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

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

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

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

Обновление: См. Также this related question, также заданный в StackOverflow ранее.

Answer 1

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

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

• http://www.tbray.org/ongoing/When/200x/2003/04/06/Unicode
• http://www.tbray.org/ongoing/When/200x/2003/04/26/UTF

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

.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() :(