Бегло говорят на Вас Unicode уже?
Развертывание в ответе @ goodside:
В некоторых случаях вам может понадобиться наложить строку с нулями (например, коды fips или другие числовые факторы). В OSX / Linux:
> sprintf("%05s", "104")
[1] "00104"
Но поскольку sprintf() вызывает команду C sprintf() ОС, обсуждаемую здесь здесь , в Windows 7 вы получаете другой результат:
> sprintf("%05s", "104")
[1] " 104"
Итак, на машинах Windows работа вокруг:
> sprintf("%05d", as.numeric("104"))
[1] "00104"
4 ответа
Так как я прочитал статью Joel и некоторые другие статьи I18n, я всегда пристально следил к своей кодировке символов; И это на самом деле работает, если Вы последовательно делаете это. Если Вы будете работать в компании, где это стандартно для использования UTF-8, и все знают, что это / делает это, это будет работать.
Здесь некоторые интересные статьи (помимо статьи Joel) на предмете:
- http://www.tbray.org/ongoing/When/200x/2003/04/06/Unicode
- http://www.tbray.org/ongoing/When/200x/2003/04/26/UTF
Кавычка от первой статьи; Подсказки для использования Unicode:
- Unicode объятия, не боритесь с ним; это - вероятно, правильный поступок, и если бы это не было, то Вы, вероятно, имели бы к во всяком случае.
- В Вашем программном обеспечении сохраните текст как UTF-8 или UTF-16; то есть выберите один из двух и палки с ним.
- Данные обмена с внешним миром с помощью XML каждый раз, когда возможный; это заставляет целый набор из потенциальных проблем уйти.
- Попытайтесь подать свою заявку, на базе браузера, а не записать Вашему собственному клиенту; браузеры становятся действительно довольно хорошими в контакте с текстами мира.
- Если Вы используете чужой код библиотеки (и конечно Вы), предположите, что его обработка Unicode повреждается до оказавшаяся корректный.
- При выполнении поиска попытайтесь передать лингвистические и обрабатывающие символ проблемы кому-то, кто понимает их.
- Уйдите в Amazon или куда-нибудь и купите последний пересмотр печатного стандарта Unicode; это содержит вполне прилично все, что необходимо знать.
- Проведите некоторое время, вводя по абсолютному адресу вокруг веб-сайта Unicode и учась, как кодовые таблицы работают.
- Если Вы оказываетесь перед необходимостью делать какую-либо серьезную работу с азиатскими языками, пойдите, покупают книгу O'Reilly по предмету Ken Lunde.
- Если Вы имеете Macintosh, выбегаете и захватываете инструмент Unicode Font Inspection лорда Pixel. Полностью прохладный.
- Если Вы действительно оказываетесь перед необходимостью спускаться и грязный с данными, пойдите, посещают один из два раза в год конференции по Unicode. Все эксперты идут и если Вы не будете знать то, что необходимо знать, то Вы сможете найти кого-то там, кто знает.
Я потратил некоторое время, работая с программным обеспечением поисковой системы - Вы не будете верить, сколько веб-сайтов подает содержание с HTTP-заголовками или метатегами, которые лгут о кодировании страниц. Часто, Вы даже получите документ, который содержит и символы ISO 8859 и символы UTF-8.
После того как Вы боролись через несколько из тех видов проблем, Вы начинаете брать надлежащую кодировку символов данных, которые Вы производите действительно серьезно.
Эмпирическое правило: если Вы никогда munge или взгляд в строке и вместо этого не будете рассматривать его строго как блоб данных, то Вы будете очень более обеспечены.
Даже делая что-то столь же простое, как разделение слов или печатающих строчными литерами строк становится жестким, если Вы хотите сделать это "Unicode путь".
И если Вы захотите сделать это "Unicode путь", то Вам будет нужна ужасно хорошая библиотека. Этот материал невероятно сложен.
Платформа.NET использует кодировку по умолчанию Windows для хранения строк, который оказывается UTF-16. Если Вы не укажете кодирование при использовании большей части текста классы ввода-вывода то Вы запишете UTF-8 без BOM и чтения первой проверкой BOM, затем принимающий UTF-8 (я знаю наверняка StreamReader и StreamWriter ведите себя этот путь.) Это довольно безопасно для "немых" текстовых редакторов, которые не поймут BOM, но довольно грязный для более умных, которые могли отобразить UTF-8 или ситуацию, где Вы на самом деле пишете символы вне стандартного диапазона ASCII.
Обычно это невидимо, но это может возникнуть интересными способами. Вчера я работал с кем-то, кто использовал сериализацию XML для сериализации объекта к строке с помощью a StringWriter, и он не мог выяснить, почему кодированием всегда был UTF-16. Так как строка в памяти будет UTF-16, и это осуществляется.NET, это - единственная вещь, которую могла сделать платформа сериализации XML.
Так, когда я пишу что-то, что не является просто одноразовым инструментом, я указываю кодировку UTF-8 с BOM. Технически в.NET Вы всегда будете случайно знающим Unicode, но только если Ваш пользователь знает для обнаружения кодирования UTF-8.
Это заставляет меня кричать немного каждого раза, когда я вижу, что кто-то спрашивает, "Как я получаю байты строки?" и использование предложенного решения Encoding.ASCII.GetBytes() :(