ICalendar
iCalendar — формат файлу, який дозволяє інтернет користувачам поширювати в різній спосіб календарні події такі, як запрошення на зустріч, завдання та інше, що мають відбутися у певний час. Формат незалежний від транспортного протоколу, яким передаються дані. Наприклад, певні події можуть бути відправлені email повідомленням, а всі файли календаря можуть розповсюджуватись та редагуватись користувачами через WebDAV сервер або SyncML. Часто для розповсюдження індивідуальних iCalendar даних про власні плани використовуються прості веб-сервери, які підтримують лише HTTP протокол. Автори також можуть вбудовувати iCalendar дані безпосередньо в веб-сторінки, використовуючи hCalendar, який є мікроформатом представлення iCalendar в нотації HTML.
Розширення файлу: |
. |
---|---|
MIME-тип: |
text/calendar |
Тип формату: | Формат поширення даних Календаря |
Стандарт(и): |
RFC 5545 (Оновлений в: RFC 5546, RFC 6868, RFC 7529) |
iCalendar використовується й підтримується великою кількістю ПЗ, наприклад, такими: Google Calendar, Apple Calendar (раніше iCal), IBM Lotus Notes, Yahoo! Calendar, Novell Evolution, eM Client, додаток Lightning для Mozilla Thunderbird й SeaMonkey та частково Microsoft Outlook, Novell GroupWise. ПЗ, що підтримують цей формат, можуть підтверджувати відправвителю про прийняття, відхилення або пропонувати інший час для запропонованої події. Формат описано в стандарті RFC 5545.
Історія та властивості
iCalendar був розроблений робочою групою з планування та керування календарями IETF під головуванням Anik Ganguly з Open Text Corporation та Frank Dawson з Lotus Development Corporation та Derik Stenerson з Microsoft Corporation. iCalendar в значній мірі ґрунтується на vCalendar, який був раніше спроектований Internet Mail Consortium (IMC).
iCalendar файли даних це прості текстові файли, що мають розширення .ics
або .ifb
. Зазвичай останнє розширення надається файлам, що містять тільки дані про доступність. На поточний час діє стандарт RFC 5545, який замінив в серпні 2009 попередній RFC 2445.
iCalendar дані мають MIME тип text/calendar
.
В iCalendar зазвичай використовують кодування символів UTF-8. В разі використання іншого набору символів, його назву вказують в параметрі charset
MIME типу, за умови якщо протокол передачі підтримує формат MIME, наприклад, такі як Email або HTTP.
Кожна стрічка має закінчуватись символами CR+LF. Довжина кожної стрічки не повинна перевищувати 75 октетів (байт). Якщо довжина перевищує, то частина продовжується на наступній стрічці, яка повинна починатись із пропуска або символу табуляції.
Позначення нового рядка безпосередньо в даних кодується як /n
або /N
(в байтовому визначенні як 5C 6E або 5C 4E для UTF-8)
Обмеження та перспективи
iCalendar спроектований для передачі даних про заплановані події. Він не описує, що робити з даними далі. наприклад, підтвердити участь в запрошені та обмеження в наданні відповіді. Відповідно, проектант ПЗ має самотужки вирішувати як надалі обробляти ці дані.
Хоча метою формату було забезпечити через стандартизацію вільний обмін календарними даними, незалежно від ПЗ, насправді, вона (мета) досягнута лише для базових функцій. Розширені, такі як Журнал (VJOURNAL) не підтримуються або VTODO реалізовані з відхиленням від стандарту, що створює проблеми сумісності.
Основні об'єкти
Головні елементи в iCalendar є об'єкти керування календарем та плануванням, вони об'єднують інформацію про заплановані події. Декілька об'єктів можуть бути об'єднані у VCALENDAR
разом. Перша стрічка повинна починатись із BEGIN:VCALENDAR
, остання повинна закінчуватись END:VCALENDAR
. Друга стрічка має починатись із VERSION:2.0
та вказує версію iCalendar формату. Для сумісності можуть вказувати формат VERSION:1.0
, проте, з часом, оновлене ПЗ може відхилити підтримку старої розмітки VCALENDAR
Надалі може йти опис календаря, пропрієтарні, оголошення зони часу. Надалі і до кінця календаря йде стрічка з подій. У свою чергу події VEVENT
можуть бути доповенними об'єктами про заплановані дії, інформацією про вільний час, нагадування, описом подій, гео-координатами подій, адресою.
Підтримка
Не дивлячись на досить високу деталізацію офіційних RFC, Деякі ПЗ (Google calendar) у боротьбі за першість у планування не оновлюють ресурси які представлені як посилання URL зі сторонніх ресурсів, інші підтримують, але лише лімітоване коло правил.