Вы свободно владеете Unicode? - PullRequest
Новая
       45

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

12 голосов
/ 12 сентября 2008

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

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

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

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

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

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

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

Ответы [ 4 ]

9 голосов
/ 12 сентября 2008

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

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

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

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

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

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

3 голосов
/ 12 сентября 2008

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

2 голосов
/ 12 сентября 2008

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

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

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

...