5. Champ d'En-tête Content-Type (Content-Type Header Field)
Le but du champ Content-Type est de décrire les données contenues dans le corps suffisamment complètement pour que l'agent utilisateur récepteur (User Agent) puisse choisir un agent ou un mécanisme approprié pour présenter les données à l'utilisateur, ou autrement traiter les données de manière appropriée. La valeur de ce champ est appelée type de média (Media Type).
NOTE HISTORIQUE : Le champ d'en-tête Content-Type a été défini pour la première fois dans la RFC 1049. La RFC 1049 utilisait une syntaxe plus simple et moins puissante, mais qui est largement compatible avec le mécanisme donné ici.
Le champ d'en-tête Content-Type spécifie la nature des données dans le corps d'une entité en donnant des identifiants de type de média et de sous-type, et en fournissant des informations auxiliaires qui peuvent être requises pour certains types de médias. Après les noms de type de média et de sous-type, le reste du champ d'en-tête est simplement un ensemble de paramètres, spécifiés en notation attribute=value. L'ordre des paramètres n'est pas significatif.
En général, le type de média de niveau supérieur est utilisé pour déclarer le type général de données, tandis que le sous-type spécifie un format spécifique pour ce type de données. Ainsi, un type de média « image/xyz » suffit à indiquer à un agent utilisateur que les données sont une image, même si l'agent utilisateur n'a aucune connaissance du format d'image spécifique « xyz ». De telles informations peuvent être utilisées, par exemple, pour décider s'il faut ou non montrer à un utilisateur les données brutes d'un sous-type non reconnu - une telle action pourrait être raisonnable pour des sous-types non reconnus de texte, mais pas pour des sous-types non reconnus d'image ou d'audio. Pour cette raison, les sous-types enregistrés de texte, d'image, d'audio et de vidéo ne devraient pas (should not) contenir d'informations incorporées qui sont réellement d'un type différent. De tels formats composés devraient être représentés en utilisant les types « multipart » ou « application ».
Les paramètres sont des modificateurs du sous-type de média, et en tant que tels ne modifient pas fondamentalement la nature du contenu. L'ensemble des paramètres significatifs dépend du type de média et du sous-type. La plupart des paramètres sont associés à un seul sous-type spécifique. Cependant, un type de média de niveau supérieur donné peut définir des paramètres qui sont applicables à n'importe quel sous-type de ce type. Les paramètres peuvent être requis par leur type de contenu ou sous-type définissant ou ils peuvent être optionnels. Les implémentations MIME doivent (must) ignorer tous les paramètres dont elles ne reconnaissent pas les noms.
Par exemple, le paramètre « charset » est applicable à n'importe quel sous-type de « text », tandis que le paramètre « boundary » est requis pour n'importe quel sous-type du type de média « multipart ».
Il n'y a AUCUN (NO) paramètre globalement significatif qui s'applique à tous les types de médias. Les mécanismes qui pourraient être considérés comme globaux dans MIME sont mieux traités dans le modèle MIME en définissant des champs d'en-tête Content-* supplémentaires.
Un ensemble initial de sept types de médias de niveau supérieur est défini dans la RFC 2046. Cinq d'entre eux sont des types discrets (Discrete Types) dont le contenu est opaque en ce qui concerne le traitement MIME. Les deux restants sont des types composites (Composite Types) dont le contenu nécessite un traitement MIME supplémentaire.
Cet ensemble de types de médias de niveau supérieur est destiné à être substantiellement complet. On s'attend à ce que les ajouts à l'ensemble plus large de types supportés puissent généralement être accomplis par la création de nouveaux sous-types de ces types initiaux. À l'avenir, d'autres types de niveau supérieur ne peuvent être définis que par une extension de type standards-track à cette norme. Si un autre type de niveau supérieur doit être utilisé pour une raison quelconque, il doit (must) recevoir un nom commençant par « X- » pour indiquer son statut non standard et pour éviter un conflit potentiel avec un nom officiel futur.
5.1. Syntaxe du Champ d'En-tête Content-Type (Syntax of the Content-Type Header Field)
Dans la notation BNF augmentée de la RFC 822, une valeur de champ d'en-tête Content-Type est définie comme suit :
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.
type := discrete-type / composite-type
discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token
composite-type := "message" / "multipart" / extension-token
extension-token := ietf-token / x-token
ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
subtype := extension-token / iana-token
iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
5.2. Valeurs par Défaut de Content-Type (Content-Type Defaults)
Si un champ d'en-tête Content-Type n'est pas présent dans une entité, le Content-Type par défaut dépend du contexte :
- Au niveau supérieur d'un message MIME, la valeur par défaut est
text/plain; charset=us-ascii - Dans une partie de corps d'une entité multipartite, le Content-Type par défaut est
text/plain; charset=us-ascii - Dans une entité "message/rfc822", le Content-Type par défaut est
text/plain; charset=us-ascii
Points Clés :
- Format Content-Type :
type/subtype; parameter=value - Le type et le sous-type sont insensibles à la casse
- Les noms de paramètres sont insensibles à la casse, mais les valeurs sont généralement sensibles à la casse
- Valeur par défaut :
text/plain; charset=us-ascii
Sept Types de Médias de Niveau Supérieur :
Types Discrets (Discrete Types)
- text : Données textuelles
- image : Données d'image
- audio : Données audio
- video : Données vidéo
- application : Données d'application
Types Composites (Composite Types)
- message : Message encapsulé
- multipart : Multiples parties