Discussion :

[clavier12AZQSWX]

bonjour,

note au modérateur : bonjour, je ne savais pas où parler de la norme iCal dans le forum, donc j'ai choisi ici ce forum . Ce serait bien qu'il y ait un sous-forum dédié aux normes et conventions... Libre à vous de déplacer le sujet ailleurs.

j'ai des fichiers iCal (donc extension .ics) que je génère qui contiennent des warning quand je les teste :

Line length should not be longer than 75 characters near line # 20Reference: RFC 5545 3.1. Content Lines

https://icalendar.org/iCalendar-RFC-...ent-lines.html

L'erreur provient du fait que je décris avec trop de lettre un event!

Je trouve étonnant qu'en 2025 de limiter une description à 75 caractères! est-ce normal ?

Le format iCal est-il encore tenu à jour et évolue-t-il encore ? y-a-t-il un changelog de la norme iCal ?

cette norme iCal est-elle encore populaire ou a-t-elle était remplacée par une autre pour la gestion des calendriers partagés par fichiers ?

bonnne journée

[CosmoKnacki]

Chaque ligne est limitée à 75 octets (et pas 75 caractères) en excluant le CRLF. Cela ne veut pas dire que la valeur d'une propriété est limitée à 75 octets, car une valeur peut s'étendre sur plusieurs lignes (en ajoutant un espace en début de ligne) tel que décrit dans la section 3.1 de la RFC5545

For example, the line:

Code txt :

Sélectionner tout - Visualiser dans une fenêtre à part

DESCRIPTION:This is a long description that exists on a long line.

Can be represented as:

Code txt :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
DESCRIPTION:This is a lo
 ng description
  that exists on a long line.

D'une manière générale, il ne faut pas se laisser éberluer par un message d'erreur ou un warning, car bien souvent son message guide facilement vers la solution.

[clavier12AZQSWX]

merci beaucoup.
je n'avais pas compris que la limite était par ligne et non par contenu entier !
je suppose donc que c'est un choix ergonomique/cosmétique pour les applis qui affichent les infos cal dans une zone petite (info-bulle, ptit écran...etc).

[CosmoKnacki]

je suppose donc que c'est un choix ergonomique/cosmétique pour les applis qui affichent les infos cal dans une zone petite (info-bulle, ptit écran...etc).

Je ne crois pas car lorsqu'un client affiche les valeurs, il est censé les avoir "reconstruites" au préalable (en supprimant les \r\n suivis d'un espace), libre ensuite à lui de passer à la ligne pour rester dans une zone d'affichage (avec une coupure intelligente si possible ou un ascenseur) , mais afficher en l'état semble peu probable (coupures en plein milieu d'un mot, passage à la ligne et ajout d'espace non-significatif, c'est pas très "human readable").

Après, il est possible que cette limite à 75 octets ait été choisie à l'époque pour la visualisation du code sur un terminal à 80 colonnes. La première RFC date de 1998, époque où le DOS 6.22 (avec les terminaux UNIX) est présent sur tous les postes et où des applications sont encore développées pour lui. Donc on peut visualiser et éditer ce code avec un mode texte de 80 colonnes. En plus à l'époque tous le monde utilisait des jeux de caractères (donc les caractères ne nécessitaient qu'un octet).