программирование

Форматы и проблемы с типом и кодировкой контента

Dmitry Vasiliev 17:12, 2008 5 14

Думаю пока еще никто не заметил, но я сделал сохранение пользовательской информации, что бы не было необходимости вводить ее при написании последующих комментариев к новостям. Я решил, что для хранения такой информации лучше всего подходит формат vCard и в итоге заинтересовался двумя последними версиями этого стандарта: 2.1 и 3.0.

Оказалось, что в последней версии (3.0) разработчики почему-то решили отказаться от параметра CHARSET и вынесли тип и кодировку карты наружу. Таким образом вместо:

BEGIN:VCARD
VERSION:2.1
FN;ENCODING=8BIT;CHARSET=UTF-8:Дмитрий Васильев
END:VCARD

Получается (упрощенно):

Content-Type: text/directory; profile="vcard"; charset=utf-8

BEGIN:VCARD
VERSION:3.0
FN:Дмитрий Васильев
END:VCARD

Мне кажется, что CHARSET для каждого поля более удобен и делает карточку более целостной без всякой дополнительной информации. Конечно внешнее указание типа и кодировки может быть удобно когда пересылается сразу несколько карточек, но думаю хорошим компромиссом было бы введение одного, единственного параметра CHARSET в каждой карте (а не для каждого параметра), например так:

BEGIN:VCARD
CHARSET:UTF-8
FN:Дмитрий Васильев
END:VCARD

В итоге, большинство все еще пользуется стандартом версии 2.1, а кто-то просто, используя 3-ю версию, самостоятельно добавляет для нужных полей параметр CHARSET и мы получаем несоответствующие стандарту документы, к тому же поддерживаемые разработчиками ПО. Я думаю это ошибка разработчиков стандарта и они должны были больше внимания уделить этой проблеме при выпуске новой версии.

К сожалению проблема типов и кодировок данных очень часто встречается, особенно для зарубежных разработчиков стандарт которых потом используется по всему миру, вот несколько хорошо известных примеров:

  • Первые протоколы ICQ не передавали никакой информации о кодировке, или типе. Позже при подключении добавили опцию, что клиент работает с UTF-8, но проблема осталась в offline режиме и для русскоязычных клиентов кодировка по умолчанию стоит в CP1251.
  • RSS хотя и не имеет проблем с кодировками (являясь XML протоколом) никак не обозначает тип контента, что может добавить разработчикам использующим его всяких сложностей. Плюс к этому здесь целая куча стандартов называющих себя RSS и меняющих только номер версии. На мой взгляд Atom является более удачным и более четким протоколом.

В целом хочется, что бы разработчики стандартов более четко думали о возможных будущих проблемах с их детищем, тем более о такой широко известной проблеме, как проблема типов и кодировки данных.

Add comment

Name:
Email: (Never will be published.)
Web site:
Comment: (Paragraphs divided by empty lines, line breaks and links will be automatically formatted.)