RFC: 2083
Statut : Proposition
Retour à l'index des normes : INDEX FRANCAIS
Sur des systèmes où il est habituel que l'extension ait une signification particulière, l'extension ".png" est recommandé pour les fichiers PNG. Le suffixe ".png" en minuscule sera préféré si les noms de fichiers sont sensibles à la casse.
L'Internet Assigned Numbers Authority (IANA) a enregistré le type MIME "image/png" comme type officiel de média des fichiers PNG pour Internet [RFC-2045, RFC- 2048]. Par principe de robustesse, les décodeurs seront enjoints de prendre en compte le type provisoire "image/x-png" utilisé avant l'enregistrement officiel du type définitif.
Sur un système Apple Macintosh, les conventions suivantes sont proposées :
PNG est un format strictement statique et destiné à enregistrer une image unique. Cependant, il peut être nécessaire d'enregistrer plusieurs images dans un fichier; par exemple, pour récupérer le contenu de certains fichiers GIF. Dans le futur, un format multi-image basé sur le format PNG sera défini. Mais il s'agira d'un format à part entière qui aura une autre signature. Les applications PNG seront libres de supporter ce format multi-images ou non. Cf. Motivations :Pourquoi ne pas implémenter ces fonctions? (Section 12.3).
Un fichier ou un flux PNG est composé d'un ensemble de blocs explicitement nommés. Les blocs tels qu'ils sont définis jusqu'ici peuvent contenir à peu près n'importe quoi, y compris le code d'un virus. Mais il n'y a pas de risque que ce code puisse être exécuté sur l'ordinateur destinataire comme conséquence du décodage de l'image PNG.
Le risque que pourrait constituer l'apparition de nouveaux types de blocs ne peut être évalué ici. Le groupe de maintenance effectuera une recherche sur ces aspects de sécurité chaque fois qu'un bloc public sera soumis à enregistrement. Le risque émanent de blocs inconnus ou privés est quasiment nul, dans la mesure où ces blocs sont ignorés, et au pire copiés dans un autre fichier PNG.
Les blocs tEXt et zTXt comportent des informations pouvant être affichées en mode texte. Il est possible que, si le décodeur affiche ce texte sans prendre la peine de filtrer les caractères de contrôle et en particulier le caractère ESC (escape), certains systèmes ou terminaux se comportent étrangement. Nous recommandons que les décodeurs filtrent les caractères de contrôle ou d'échappement avant d'afficher ces textes; Cf. Recommandations pour les Décodeurs: Traitement des blocs texte (Section 10.11).
Comme la longueur de chaque bloc peut être déterminée dès le début du bloc, et qu'il dispose à sa fin un CRC, la protection contre des erreurs dans les données et contre des blocs illégaux qui seraient susceptibles de faire "déborder" les tampons du décodeur est excellente. De plus, la signature en tête de PNG permet de détecter très rapidement les fautes ou incompatibilités de transmission.
Un décodeur acceptant des erreurs de CRC pourra laisser passer des données corrompues. La seule conséquence de cette corruption, si elle n'intervient que dans les blocs IDAT, est l'affichage de pixels erronés. Des aberrations bien plus sérieuses peuvent survenir si le CRC du bloc IHDR n'est pas correctement vérifié et les valeurs de hauteur et de largeur d'image sont erronés. Cf. Recommandations pour les Décodeurs: Correction d'erreur (Section 10.1).
Un décodeur écrit avec peu d'attention sera facilement sujet à une saturation des tampons d'image, dans la mesure où les blocs peuvent être très longs, jusqu'à (2^31)-1 octets. Des décodeurs correctement écrits géreront ces tailles de bloc sans aucune difficulté.
8.5. Considérations en matière de sécurité
Attention :Les chapitres 9 et 10 traitant des recommandations pour l'implémentation des décodeurs et encodeurs ne sont pas encore disponibles.