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

Question

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 4

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

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

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