17 Les formulaires

17.1 Introduction aux formulaire

Un formulaire HTML est une partie du document constitu�e d'un contenu normal, d'un balisage, d'�l�ments sp�ciaux appel�s commandes (cases � cocher, boutons radio, menus, etc.) et de labels sur ces commandes. L'utilisateur ��remplit�� g�n�ralement le formulaire en modifiant ses commandes (en saisissant un texte, en s�lectionnant les articles d'un menu, etc.), avant de soumettre le formulaire � un agent pour son traitement (par exemple, � un serveur Web, � un serveur de courrier, etc.).

 <FORM action="http://unsite.com/prog/ajoutermembre" method="post">
    <P>
    <LABEL for="prenom">Prénom : </LABEL>
              <INPUT type="text" id="prenom"><BR>
    <LABEL for="nom">Nom : </LABEL>
              <INPUT type="text" id="nom"><BR>
    <LABEL for="email">e-mail : </LABEL>
              <INPUT type="text" id="email"><BR>
    <INPUT type="radio" name="genre" value="homme"> Homme<BR>
    <INPUT type="radio" name="genre" value="femme"> Femme<BR>
    <INPUT type="submit" value="Envoyer"> <INPUT type="reset">
    </P>
 </FORM>

17.2 Les commandes

Les utilisateurs interagissent avec les formulaires au moyen de commandes nomm�es.

Le ��nom de commande�� d'une commande est donn� par son attribut name. La port�e de l'attribut name d'une commande au sein d'un �l�ment FORM est cet �l�ment FORM.

Chaque command poss�de � la fois une valeur initiale et une valeur courante, les deux sont des cha�nes de caract�res. Veuillez consulter la d�finition de chaque commande pour des pr�cisions sur la valeur initiale et les �ventuelles contraintes sur les valeurs impos�es par la commande. En g�n�ral, la ��valeur initiale�� d'une commande peut �tre sp�cifi�e avec l'attribut value de l'�l�ment de commande. Cependant, la valeur initiale d'un �l�ment TEXTAREA est donn�e par son contenu et la valeur initiale d'un �l�ment OBJECT dans un formulaire est d�termin�e par l'impl�mentation de l'objet (i.e., elle n'est pas pr�cis�e par cette sp�cification).

La ��valeur courante�� d'une commande est d'abord �gale � la valeur initiale. Par la suite, la valeur courante de la commande peut �tre modifi�e par les actions de l'utilisateur et par les scripts.

La valeur initiale d'une commande ne change pas. Ainsi, quand un formulaire est r�initialis�, chacune des valeurs courantes des commandes reprend sa valeur initiale. Si la commande n'a pas de valeur initiale, alors l'effet de la r�initialisation du formulaire sur cette commande n'est pas d�fini.

Lors de la soumission du formulaire pour son traitement, le nom et la valeur courante de certaines commandes sont accoupl�s et ces couples sont soumis avec le formulaire. On appelle ces commandes, pour lesquelles des couples nom/valeur sont soumis, des commandes r�ussies [ndt. successful controls].

17.2.1 Les types de commande

HTML d�fini les types de commande suivants�:

Les boutons

Les auteurs peuvent cr�er trois types de boutons�:

• les boutons de soumission : quand il est actionn�, le bouton de soumission soumet le formulaire. Un formulaire peut contenir plusieurs boutons de soumission�;
• les boutons de r�initialisation : quand il est actionn�, le bouton de r�initialisation remet toutes les commandes � leur valeur initiale�;
• les boutons poussoirs : les boutons poussoirs n'ont pas de comportement par d�faut. Chaque bouton poussoir peut avoir des scripts c�t� client qui sont associ�s aux attributs d'�v�nement de l'�l�ment. Quand un �v�nement se produit (par exemple, l'utilisateur presse le bouton, le rel�che, etc.), le script associ� est d�clench�.

  Les auteurs devraient sp�cifier le langage du script du bouton poussoir au moyen d'une d�claration de script par d�faut (avec l'�l�ment META).

Les auteurs cr�ent des boutons avec les �l�ments BUTTON ou INPUT. Veuillez consulter leurs d�finitions respectives pour des pr�cisions sur la sp�cification des divers types de bouton.

Remarque : Les auteurs devraient remarquer que l'�l�ment BUTTON offre des possibilit�s de restitution plus �tendues que celles de l'�l�ment INPUT.

Les cases � cocher

Les cases � cocher (et les boutons ��radio��) sont des interrupteurs marche/arr�t qui peuvent �tre actionn�s par l'utilisateur. L'interrupteur est sur ��marche�� quand l'attribut checked de l'�l�ment de commande est sp�cifi�. Lors de la soumission du formulaire, seules les commandes de cases � cocher sur ��marche�� peuvent devenir des commandes r�ussies.

Dans un formulaire, plusieurs cases � cocher peuvent partager le m�me nom de commande. Ainsi, par exemple, les cases � cocher permettent aux utilisateurs de s�lectionner plusieurs valeurs pour la m�me propri�t�. On utilise l'�l�ment INPUT pour cr�er une commande de case � cocher.

Les boutons ��radio��

Les boutons ��radio�� sont analogues aux cases � cocher, � la diff�rence que, quand plusieurs boutons partage le m�me nom de commande, alors ils s'excluent mutuellement�: quand l'un est mis sur ��marche��, tous les autres avec le m�me nom se mettent sur ��arr�t��. On utilise l'�l�ment INPUT pour cr�er une commande de bouton radio.

Si aucun des boutons radio, dans un jeu partageant le m�me nom de commande, n'est en position ��marche��, alors le comportement de l'agent utilisateur, pour le choix de la commande qui est initialement sur ��marche��, n'est pas d�fini. Remarque : Comme les impl�mentations existantes g�rent diversement ce cas, la sp�cification courante se d�marque du document RFC1866 ([RFC1866] section 8.1.2.4), qui d�clare�:

� tout instant, un seul bouton radio exactement parmi ceux dans un jeu est press�. Si aucun des �l�ments dans un jeu de boutons radio ne sp�cifie un attribut "CHECKED", alors l'agent utilisateur doit activer initialement le premier des boutons radio du jeu en question.

En raison des diff�rences d'interpr�tation entre les agents utilisateurs, les auteurs devraient s'assurer qu'un des boutons radio dans un jeu soit mis initialement sur ��marche��.

Les menus

Les menus proposent des options aux utilisateurs parmi lesquelles faire un choix. L'�l�ment SELECT cr�e un menu, en conjonction avec les �l�ments OPTGROUP et OPTION.

La saisie de texte

Les auteurs peuvent cr�er deux types de commande qui permettent aux utilisateurs la saisie d'un texte. L'�l�ment INPUT cr�e une commande pour une saisie sur une seule ligne et l'�l�ment TEXTAREA cr�e une commande pour une saisie sur plusieurs lignes. Dans les deux cas, le texte saisi devient la valeur courante de la commande.

La s�lection d'un fichier

Ce type de commande permet � l'utilisateur de s�lectionner un fichier de sorte que son contenu puisse �tre soumis avec le formulaire. On utilise l'�l�ment INPUT pour cr�er une commande de s�lection de fichier.

Les commandes cach�es

Les auteurs peuvent cr�er des commandes qui ne sont pas restitu�es mais dont les valeurs sont soumises avec le formulaire. Les auteurs utilisent en g�n�ral ce type de commande pour enregistrer les informations entre les �changes client/serveur, qui seraient perdues sinon du fait de la nature apatride du protocole HTTP (voir le document [RFC2616]). On utilise l'�l�ment INPUT pour cr�er une commande cach�e.

Les commandes d'objets

Les auteurs peuvent ins�rer des objets g�n�riques dans les formulaires de telle sorte que les valeurs qui leur sont associ�es soient soumises en m�me temps que les autres commandes. On utilise l'�l�ment OBJECT pour cr�er une commande d'objet.

Les �l�ments utilis�s pour cr�er les commandes apparaissent g�n�ralement dans un �l�ment FORM, mais ils peuvent aussi appara�tre en dehors de la d�claration de l'�l�ment FORM quand on les utilise pour construire des interfaces utilisateurs. Ceci est abord� dans la section sur les �v�nements intrins�ques. Remarquez que les commandes en dehors d'un formulaire ne peuvent pas �tre des commandes r�ussies.

17.3 L'�l�ment FORM

<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- formulaire interactif -->
<!ATTLIST FORM
  %attrs;                              -- %coreattrs, %i18n, %events --
  action      %URI;          #REQUIRED -- gestionnaire de formulaire c�t� serveur --
  method      (GET|POST)     GET       -- m�thode HTTP utilis�e
                                          pour soumettre le formulaire --
  enctype     %ContentType;  "application/x-www-form-urlencoded"
  accept      %ContentTypes; #IMPLIED  -- liste de types MIME pour le
                                          chargement des fichiers --
  name        CDATA          #IMPLIED  -- nom du formulaire pour les scripts --
  onsubmit    %Script;       #IMPLIED  -- le formulaire a �t� soumis --
  onreset     %Script;       #IMPLIED  -- le formulaire a �t� r�initialis� --
  accept-charset %Charsets;  #IMPLIED  -- liste des jeux de caract�res reconnus --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

L'�l�ment FORM agit comme conteneur pour les commandes. Il sp�cifie�:

• la disposition du formulaire (donn�e par le contenu de l'�l�ment)�;
• le programme qui va manipuler le formulaire rempli puis soumis (l'attribut action). Le programme r�cepteur doit �tre capable d'analyser les couples nom/valeur afin de les utiliser�;
• la m�thode selon laquelle les donn�es de l'utilisateur seront envoy�es au serveur (l'attribut method)�;
• l'encodage de caract�res qui doit �tre accept� par le serveur pour manipuler ce formulaire (l'attribut accept-charset). Les agents utilisateurs peuvent avertir l'utilisateur de la valeur de l'attribut accept-charset et/ou emp�cher que celui-ci n'entre des caract�res non reconnus.

Un formulaire peut contenir un texte et un balisage (paragraphes, listes, etc.) en plus des commandes de formulaire.

 <FORM action="http://unsite.com/prog/ajoutermembre" method="post">
 ...contenu du formulaire...
 </FORM>

Veuillez consulter la section traitant de la soumission du formulaire pour des renseignements sur la mani�re dont les agents utilisateurs doivent pr�parer les donn�es de formulaire pour les serveurs et sur la mani�re dont les agents utilisateurs devraient interpr�ter les r�ponses pr�visibles.

17.4 L'�l�ment INPUT

<!ENTITY % InputType
  "(TEXT | PASSWORD | CHECKBOX |
    RADIO | SUBMIT | RESET |
    FILE | HIDDEN | IMAGE | BUTTON)"
   >


<!ELEMENT INPUT - O EMPTY              -- commande de formulaire -->
<!ATTLIST INPUT
  %attrs;                              -- %coreattrs, %i18n, %events --
  type        %InputType;    TEXT      -- le type de la commande --
  name        CDATA          #IMPLIED  -- soumis en tant que partie du formulaire --
  value       CDATA          #IMPLIED  -- pour les boutons radio et les cases � cocher --
  checked     (checked)      #IMPLIED  -- pour les boutons radio et les cases � cocher --
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  readonly    (readonly)     #IMPLIED  -- pour les types text et passwd --
  size        CDATA          #IMPLIED  -- propre � chaque type de champs --
  maxlength   NUMBER         #IMPLIED  -- caract�res maxi pour les champs textuels --
  src         %URI;          #IMPLIED  -- pour les champs et les images --
  alt         CDATA          #IMPLIED  -- br�ve description --
  usemap      %URI;          #IMPLIED  -- utiliser une image cliquable c�t� client --
  ismap       (ismap)        #IMPLIED  -- utiliser une image cliquable c�t� serveur --
  tabindex    NUMBER         #IMPLIED  -- position dans l'ordre de tabulation --
  accesskey   %Character;    #IMPLIED  -- touche de caract�re pour accessibilit� --
  onfocus     %Script;       #IMPLIED  -- l'�l�ment a l'attention --
  onblur      %Script;       #IMPLIED  -- l'�l�ment perd l'attention --
  onselect    %Script;       #IMPLIED  -- un texte est s�lectionn� --
  onchange    %Script;       #IMPLIED  -- la valeur de l'�l�ment a chang� --
  accept      %ContentTypes; #IMPLIED  -- liste des types MIME pour l'envoi d'un fichier --
  >

Balise ouvrante : obligatoire, balise fermante : interdite

17.4.1 Les types de commande cr��s par l'�l�ment INPUT

Le type de commande d�fini par l'�l�ment INPUT est fonction de la valeur de l'attribut type�:

text

Cr�e une commande de saisie de texte sur une seule ligne.

password

Comme pour la valeur "text", mais le texte saisi est restitu� de mani�re � dissimuler les caract�res (par exemple, une succession de caract�res ast�risques ��*��). Ce type de commande est souvent employ� pour les entr�es sensibles comme les mots de passe. Remarquez que la valeur courante est le texte saisi par l'utilisateur, non le texte restitu� par l'agent utilisateur.

Remarque : Les d�veloppeurs d'applications devraient remarquer que ce m�canisme n'offre qu'une protection l�g�re. Bien qu'il soit masqu� par l'agent utilisateur aux yeux d'un �ventuel observateur, le mot de passe est transmis au serveur en texte clair et peut �tre lu par quiconque ayant un acc�s granulaire au r�seau.

checkbox

Cr�e une case � cocher.

radio

Cr�e un bouton ��radio��.

submit

Cr�e un bouton de soumission.

image

Cr�e un bouton de soumission graphique. La valeur de l'attribut src sp�cifie l'URI de l'image qui va d�corer le bouton. Pour des questions d'accessibilit�, les auteurs devraient fournir un texte de remplacement pour l'image au moyen de l'attribut alt.

Quand un dispositif de pointage est employ� pour cliquer sur l'image, le formulaire est soumis et les coordonn�es du clic sont pass�es au serveur. La coordonn�e ��x�� se mesure en pixels � partir de la gauche de l'image et la coordonn�e ��y�� en pixels � partir du haut de l'image. Les donn�es soumises comprennent les valeurs nom.x=valeur-de-x et nom.y=valeur-de-y, dans lesquelles le ��nom�� est la valeur de l'attribut name, et ��valeur-de-x�� et ��valeur-de-y�� sont les valeurs des coordonn�es ��x�� et ��y�� respectivement.

Si le serveur entreprend diverses actions en fonction de l'endroit cliqu�, l'utilisateur d'un navigateur non-graphique sera d�savantag�. Pour cette raison, les auteurs devraient consid�rer ces approches alternatives�:

• Utiliser plusieurs bouton de soumission (chacun avec sa propre image) au lieu d'un seul bouton de soumission graphique. Les auteurs peuvent employer les feuilles de style pour contr�ler le positionnement de ces boutons�;
• Utiliser une image cliquable c�t� client en m�me temps que des scripts.

reset

Cr�e un bouton de r�initialisation.

button

Cr�e un bouton poussoir. Les agents utilisateurs devraient utiliser la valeur de l'attribut value comme intitul� du bouton.

hidden

Cr�e une commande cach�e.

file

Cr�e une commande de s�lection de fichier. Les agents utilisateurs peuvent utiliser la valeur de l'attribut value comme nom de fichier initial.

17.4.2 Exemples de formulaires contenant des commandes INPUT

 <FORM action="http://unsite.com/prog/ajoutermembre" method="post">
    <P>
    Prénom : <INPUT type="text" name="prenom"><BR>
    Nom : <INPUT type="text" name="nom"><BR>
    E-mail: <INPUT type="text" name="email"><BR>
    <INPUT type="radio" name="genre" value="homme"> Homme<BR>
    <INPUT type="radio" name="genre" value="femme"> Femme<BR>
    <INPUT type="submit" value="Envoyer"> <INPUT type="reset">
    </P>
 </FORM>

<HEAD>
<META http-equiv="Content-Script-Type" content="text/javascript">
</HEAD>
<BODY>
 <FORM action="..." method="post">
    <P>
    <INPUT type="button" value="Cliquez moi" onclick="verifier()">
 </FORM>
</BODY>

<FORM action="http://server.dom/cgi/gestion"
    enctype="multipart/form-data"
    method="post">
 <P>
 Quel est votre nom ? <INPUT type="text" name="nom_expediteur">
 Quels sont les fichiers à envoyer ? <INPUT type="file" name="nom_des_fichiers">
 </P>
</FORM>

17.5 L'�l�ment BUTTON

<!ELEMENT BUTTON - -
     (%flow;)* -(A|%formctrl;|FORM|FIELDSET)
     -- bouton poussoir -->
<!ATTLIST BUTTON
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED
  value       CDATA          #IMPLIED  -- envoy� au serveur � la soumission --
  type        (button|submit|reset) submit -- � utiliser comme bouton de formulaire --
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  tabindex    NUMBER         #IMPLIED  -- position dans l'ordre de tabulation --
  accesskey   %Character;    #IMPLIED  -- touche de caract�re pour l'accessibilit� --
  onfocus     %Script;       #IMPLIED  -- l'�l�ment a l'attention --
  onblur      %Script;       #IMPLIED  -- l'�l�ment perd l'attention --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

Les boutons cr��s par l'�l�ment BUTTON fonctionnent exactement comme ceux cr��s avec l'�l�ment INPUT, mais ils offrent des possibilit�s de restitution plus vari�es�: l'�l�ment BUTTON peut avoir un contenu. Par exemple, un �l�ment BUTTON qui contient une image fonctionne de la m�me fa�on et peut avoir le m�me aspect qu'un �l�ment INPUT dont l'attribut type a la valeur "image", sauf que le type d'�l�ment BUTTON admet un contenu.

Les agents utilisateurs visuels peuvent restituer les boutons BUTTON en relief et avec un mouvement de haut en bas quand on les clique, tandis qu'ils peuvent restituer les boutons INPUT comme des images ��plates��.

 <FORM action="http://unsite.com/prog/ajoutermembre" method="post">
    <P>
    Prénom : <INPUT type="text" name="prenom"><BR>
    Nom : <INPUT type="text" name="nom"><BR>
    E-mail: <INPUT type="text" name="email"><BR>
    <INPUT type="radio" name="genre" value="homme"> Homme<BR>
    <INPUT type="radio" name="genre" value="femme"> Femme<BR>
    <BUTTON name="submit" value="envoyer" type="submit">
    Envoyer<IMG src="/icons/c-bon.gif" alt=""></BUTTON>
    <BUTTON name="reset" type="reset">
    Effacer<IMG src="/icons/c-pas-bon.gif" alt=""></BUTTON>
    </P>
 </FORM>

Les auteurs doivent se rappeler de fournir un texte de remplacement pour l'�l�ment IMG.

Il est ill�gal d'associer une image cliquable � un �l�ment IMG apparaissant en contenu d'un �l�ment BUTTON.

<BUTTON>
<IMG src="foo.gif" usemap="...">
</BUTTON>

17.6 Les �l�ments SELECT, OPTGROUP et OPTION

<!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- s�lecteur d'option -->
<!ATTLIST SELECT
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED  -- nom du champs --
  size        NUMBER         #IMPLIED  -- rang�es visibles --
  multiple    (multiple)     #IMPLIED  -- une seule s�lection par d�faut --
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  tabindex    NUMBER         #IMPLIED  -- position dans l'ordre de tabulation --
  onfocus     %Script;       #IMPLIED  -- l'�l�ment a l'attention --
  onblur      %Script;       #IMPLIED  -- l'�l�ment perd l'attention --
  onchange    %Script;       #IMPLIED  -- la valeur de l'�l�ment a chang� --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

L'�l�ment SELECT cr�e un menu. Chaque option offerte par le menu est repr�sent�e par un �l�ment OPTION. L'�l�ment SELECT doit contenir au moins un �l�ment OPTION.

L'�l�ment OPTGROUP permet aux auteurs le regroupement logique des options. Cela est particuli�rement utile quand l'utilisateur doit effectuer un choix � partir d'une longue liste d'options�; les groupes d'options apparent�es sont plus facile � comprendre et � se rem�morer qu'une seule longue liste d'options. Dans HTML�4 tous les �l�ments OPTGROUP doivent �tre sp�cifi�s directement dans un �l�ment SELECT (i.e., les groupes ne peuvent pas �tre imbriqu�s).

17.6.1 Les options pr�s�lectionn�es

Z�ro ou plusieurs options peuvent �tre pr�s�lectionn�es pour l'utilisateur. Les agents utilisateurs devraient d�terminer les options qui sont pr�selectionn�es comme suit�:

• si aucun �l�ment OPTION ne poss�de un attribut selected, le comportement de l'agent utilisateur vis-�-vis du choix de l'option s�lectionn�e initiale est ind�fini. Remarque : �tant donn� que les impl�mentations existantes g�rent ce cas diversement, la sp�cification courante se d�marque du document RFC1866 ([RFC1866] section 8.1.3), qui d�clare�:

  La premi�re option est s�lectionn�e � l'initialisation, � moins que l'attribut SELECTED ne soit pr�sent sur l'un des �l�ments <OPTION>.

  Comme le comportement des agents utilisateurs varie, les auteurs devraient s'assurer que chaque menu inclut un �l�ment OPTION pr�s�lectionn� par d�faut�;

• si un �l�ment OPTION poss�de un attribut selected, alors celui-ci devrait �tre pr�s�lectionn�;
• si l'�l�ment SELECT a un attribut multiple sp�cifi� et plusieurs �l�ments OPTION avec l'attribut selected sp�cifi�, alors ceux-ci devraient tous �tre pr�s�lectionn�s�;
• il s'agit d'une erreur si plusieurs �l�ments OPTION ont un attribut selected alors que l'attribut multiple n'est pas sp�cifi� sur l'�l�ment SELECT. Les agents utilisateurs peuvent varier dans la prise en charge de cette erreur, mais ils ne devraient pas pr�s�lectionner plus d'une option.

<!ELEMENT OPTGROUP - - (OPTION)+ -- regroupement d'option -->
<!ATTLIST OPTGROUP
  %attrs;                              -- %coreattrs, %i18n, %events --
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  label       %Text;         #REQUIRED -- � utiliser dans les menus hi�rarchiques --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

<!ELEMENT OPTION - O (#PCDATA)         -- option s�lectionnable -->
<!ATTLIST OPTION
  %attrs;                              -- %coreattrs, %i18n, %events --
  selected    (selected)     #IMPLIED
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  label       %Text;         #IMPLIED  -- � utiliser dans les menus hi�rarchiques --
  value       CDATA          #IMPLIED  -- le contenu de l'�l�ment par d�faut --
  >

Balise ouvrante : obligatoire, balise fermante : optionnelle

Lors de la restitution de l'option d'un menu, l'agent utilisateur devrait utiliser la valeur de l'attribut label de l'�l�ment OPTION comme intitul� pour l'option. Si cet attribut n'est pas sp�cifi�, l'agent utilisateur devrait utiliser le contenu de l'�l�ment OPTION.

L'attribut label de l'�l�ment OPTGROUP sp�cifie l'intitul� d'un groupe d'options.

<FORM action="http://unsite.com/prog/choisir_composant" method="post">
   <P>
   <SELECT multiple size="4" name="selection_composant">
      <OPTION selected value="composant_1_a">Composant_1</OPTION>
      <OPTION selected value="composant_1_b">Composant_2</OPTION>
      <OPTION>Composant_3</OPTION>
      <OPTION>Composant_4</OPTION>
      <OPTION>Composant_5</OPTION>
      <OPTION>Composant_6</OPTION>
      <OPTION>Composant_7</OPTION>
   </SELECT>
   <INPUT type="submit" value="Envoyer"><INPUT type="reset">
   </P>
</FORM>

<FORM action="http://unsite.com/prog/unprogramme" method="post">
 <P>
 <SELECT name="ComOS">
     <OPTION selected label="aucun" value="aucun">Aucun</OPTION>
     <OPTGROUP label="PortMaster 3">
       <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 avec ComOS 3.7.1</OPTION>
       <OPTION label="3.7" value="pm3_3.7">PortMaster 3 avec ComOS 3.7</OPTION>
       <OPTION label="3.5" value="pm3_3.5">PortMaster 3 avec ComOS 3.5</OPTION>
     </OPTGROUP>
     <OPTGROUP label="PortMaster 2">
       <OPTION label="3.7" value="pm2_3.7">PortMaster 2 avec ComOS 3.7</OPTION>
       <OPTION label="3.5" value="pm2_3.5">PortMaster 2 avec ComOS 3.5</OPTION>
     </OPTGROUP>
     <OPTGROUP label="IRX">
       <OPTION label="3.7R" value="IRX_3.7R">IRX avec ComOS 3.7R</OPTION>
       <OPTION label="3.5R" value="IRX_3.5R">IRX avec ComOS 3.5R</OPTION>
     </OPTGROUP>
 </SELECT>
</FORM>

  Aucun
  PortMaster 3
      3.7.1
      3.7
      3.5
  PortMaster 2
      3.7
      3.5
  IRX
      3.7R
      3.5R

17.7 L'�l�ment TEXTAREA

<!ELEMENT TEXTAREA - - (#PCDATA)       -- multi-line text field -->
<!ATTLIST TEXTAREA
  %attrs;                              -- %coreattrs, %i18n, %events --
  name        CDATA          #IMPLIED
  rows        NUMBER         #REQUIRED
  cols        NUMBER         #REQUIRED
  disabled    (disabled)     #IMPLIED  -- indisponible dans ce contexte --
  readonly    (readonly)     #IMPLIED
  tabindex    NUMBER         #IMPLIED  -- position dans l'ordre de tabulation --
  accesskey   %Character;    #IMPLIED  -- touche de caract�re pour l'accessibilit� --
  onfocus     %Script;       #IMPLIED  -- l'�l�ment a l'attention --
  onblur      %Script;       #IMPLIED  -- l'�l�ment perd l'attention --
  onselect    %Script;       #IMPLIED  -- some text was selected --
  onchange    %Script;       #IMPLIED  -- la valeur de l'�l�ment a chang� --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

L'�l�ment TEXTAREA cr�e une commande de saisie de texte multilignes. Les agents utilisateurs devraient utiliser le contenu de cet �l�ment comme valeur initiale et restituer initialement ce texte.

<FORM action="http://unsite.com/prog/lecture-texte" method="post">
   <P>
   <TEXTAREA name="le_texte" rows="20" cols="80">
   Première ligne de texte initial.
   Seconde ligne de texte initial.
   </TEXTAREA>
   <INPUT type="submit" value="Envoyer"><INPUT type="reset">
   </P>
</FORM>

17.8 L'�l�ment ISINDEX

L'�l�ment ISINDEX est d�conseill�. Cet �l�ment cr�e une commande de saisie d'un texte sur une seule ligne. Les auteurs devraient utiliser l'�l�ment INPUT pour cr�er des commandes de saisie de texte.

Voir le DTD transitoire pour sa d�finition formelle.

L'�l�ment ISINDEX cr�e une commande de saisie de texte sur une seule ligne, qui admet un nombre quelconque de caract�res. Les agents utilisateurs peuvent utiliser la valeur de l'attribut prompt comme titre pour l'invite.

<ISINDEX prompt="Saisissez le mot à rechercher : ">

<FORM action="..." method="post">
<P>Saisissez le mot à rechercher : <INPUT type="text"></P>
</FORM>

17.9 Les labels

Quelques commandes de formulaire ont des labels qui leur sont automatiquement associ�s (les boutons poussoirs) tandis que la plupart d'entre elles en sont d�pourvues (les champs de texte, les cases � cocher et les boutons radio ainsi que les menus).

Pour celles des commandes qui ont un label implicite, les agents utilisateurs devraient utiliser la valeur de l'attribut value comme cha�ne pour le label.

On utilise l'�l�ment LABEL pour sp�cifier les labels des commandes qui n'ont pas de labels implicites.

17.9.1 L'�l�ment LABEL

<!ELEMENT LABEL - - (%inline;)* -(LABEL) -- texte du label d'un champs de texte -->
<!ATTLIST LABEL
  %attrs;                              -- %coreattrs, %i18n, %events --
  for         IDREF          #IMPLIED  -- correspond � la valeur ID du champs --
  accesskey   %Character;    #IMPLIED  -- touche de caract�re pour l'accessibilit� --
  onfocus     %Script;       #IMPLIED  -- l'�l�ment a l'attention --
  onblur      %Script;       #IMPLIED  -- l'�l�ment perd l'attention --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

L'�l�ment LABEL peut s'utiliser pour attacher des informations aux commandes. Chaque �l�ment LABEL est associ� � exactement une commande de formulaire.

L'attribut for associe explicitement un label � une autre commande�: la valeur de l'attribut for doit �tre la m�me que celle de l'attribut id de l'�l�ment de commande associ�. On peut associer plusieurs �l�ments LABEL � la m�me commande en cr�ant plusieurs r�f�rences via l'attribut for.

<FORM action="..." method="post">
<TABLE>
  <TR>
    <TD><LABEL for="label_prenom">Prénom</LABEL>
    <TD><INPUT type="text" name="prenom" id="label_prenom">
  <TR>
    <TD><LABEL for="label_nom">Nom</LABEL>
    <TD><INPUT type="text" name="nom" id="label_nom">
</TABLE>
</FORM>

 <FORM action="http://unsite.com/prog/ajoutermembre" method="post">
    <P>
    <LABEL for="label_prenom">Prénom : </LABEL>
              <INPUT type="text" id="label_prenom"><BR>
    <LABEL for="label_nom">Nom : </LABEL>
              <INPUT type="text" id="label_nom"><BR>
    <LABEL for="label_email">E-mail : </LABEL>
              <INPUT type="text" id="label_email"><BR>
    <INPUT type="radio" name="genre" value="homme"> Homme<BR>
    <INPUT type="radio" name="genre" value="femme"> Femme<BR>
    <INPUT type="submit" value="Envoyer"> <INPUT type="reset">
    </P>
 </FORM>

Pour associer implicitement un label � une autre commmande, l'�l�ment de commande doit se trouver � l'int�rieur de l'�l�ment LABEL. Auquel cas, cet �l�ment LABEL ne peut contenir qu'un seul �l�ment de commande. Le label en question peut se placer avant ou apr�s la commande associ�e.

<FORM action="..." method="post">
<P>
<LABEL>
   Prénom
   <INPUT type="text" name="prenom">
</LABEL>
<LABEL>
   <INPUT type="text" name="nom">
   Nom
</LABEL>
</P>
</FORM>

Quand un �l�ment LABEL re�oit l'attention, celui-ci communique cette attention � la commande qui lui est associ�e. Voir la section ci-dessous sur les cl�s d'acc�s pour des exemples.

Les agents utilisateurs peuvent restituer les labels de nombreuses fa�ons (par exemple, visuellement, lus par des synth�tiseurs de parole, etc.).

17.10 Le rajout d'une structure aux formulaires : les �l�ments FIELDSET et LEGEND

<!ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*) -- form control group -->
<!ATTLIST FIELDSET
  %attrs;                              -- %coreattrs, %i18n, %events --
  >

<!ELEMENT LEGEND - - (%inline;)*       -- fieldset legend -->

<!ATTLIST LEGEND
  %attrs;                              -- %coreattrs, %i18n, %events --
  accesskey   %Character;    #IMPLIED  -- touche de caract�re pour l'accessibilit� --
  >

Balise ouvrante : obligatoire, balise fermante : obligatoire

L'�l�ment FIELDSET perment aux auteurs de regrouper th�matiquement les commandes et les labels apparent�s. Le regroupement des commandes rend leur compr�hension plus ais�e aux utilisateurs, tout en facilitant la navigation par tabulation pour les agents utilisateurs visuels et la navigation vocale pour les agents utilisateurs vocaux. La bonne utilisation de cet �l�ment rend les documents plus accessibles.

L'�l�ment LEGEND permet aux auteurs d'assigner une l�gende � un �l�ment FIELDSET. La l�gende renforce l'accessibilit� quand l'�l�ment FIELDSET est restitu�e de mani�re non-visuelle.

<FORM action="..." method="post">
 <P>
 <FIELDSET>
  <LEGEND>Informations personnelles</LEGEND>
  Nom : <INPUT name="personnel_nom" type="text" tabindex="1">
  Prénom : <INPUT name="personnel_prenom" type="text" tabindex="2">
  Adresse : <INPUT name="personnel_adresse" type="text" tabindex="3">
  <em>...autres informations personnelles...</em>
 </FIELDSET>
 <FIELDSET>
  <LEGEND>Historique médical</LEGEND>
  <INPUT name="historique_maladie"
         type="checkbox"
         value="variole" tabindex="20"> Variole
  <INPUT name="historique_maladie"
         type="checkbox"
         value="oreillons" tabindex="21"> Oreillons
  <INPUT name="historique_maladie"
         type="checkbox"
         value="vertiges" tabindex="22"> Vertiges
  <INPUT name="historique_maladie"
         type="checkbox"
         value="eternuements" tabindex="23"> Éternuements
  <em>...autres épisodes médicaux...</em>
 </FIELDSET>
 <FIELDSET>
  <LEGEND>Traitement courant</LEGEND>
  Suivez-vous actuellement un traitement ?
  <INPUT name="traitement_actuel"
         type="radio"
         value="oui" tabindex="35">Oui
  <INPUT name="traitement_actuel"
         type="radio"
         value="non" tabindex="35">Non

  Si vous prenez des médicaments, veuillez les
  inscrire dans l'espace ci-dessous :
  <TEXTAREA name="medication_courante"
            rows="20" cols="50"
            tabindex="40">
  </TEXTAREA>
 </FIELDSET>
</FORM>

17.11 Donner l'attention � un �l�ment

Dans un document HTML, un �l�ment doit recevoir l'attention [ndt. focus] par le biais de l'utilisateur afin de devenir actif et de remplir sa fonction. Par exemple, les utilisateurs doivent activer le lien sp�cifi� par l'�l�ment A pour suivre le lien en question. De la m�me mani�re, les utilisateurs doivent donner l'attention � l'�l�ment TEXTAREA pour y saisir un texte.

Il y a plusieurs fa�ons de donner l'attention � un �l�ment�:

• en d�signant l'�l�ment avec un dispositif de pointage�;
• en navigant d'un �l�ment � l'autre au clavier. L'auteur du document peut d�finir un ordre de tabulation qui sp�cifie l'odre dans lequel les �l�ments vont recevoir l'attention quand l'utilisateur navigue au clavier dans le document (voir la navigation par tabulation). Une fois s�lectionn�, l'�l�ment peut �tre activ� par une certaine combinaison de touches�;
• en s�lectionnant l'�l�ment au moyen d'une cl� d'acc�s (appell�e aussi parfois ��raccourci-clavier�� ou ��touche rapide��).

17.11.1 La navigation par tabulation

L'ordre de tabulation d�finit l'ordre dans lequel les �l�ments vont recevoir l'attention lorsque l'utilisateur navigue au clavier. L'ordre de tabulation peut comprendre les �l�ments imbriqu�s dans d'autres �l�ments.

Les �l�ments qui re�oivent l'attention devraient �tre parcourus par les agents utilisateurs en fonction des r�gles suivantes�:

1. Ceux des �l�ments qui reconnaissent l'attribut tabindex et lui assignent une valeur positive sont parcourus en premier. La navigation proc�de � partir de l'�l�ment avec la plus petite valeur pour l'attribut tabindex vers l'�l�ment avec la valeur la plus �lev�e. Les valeurs ne se suivent pas forc�ment ni doivent commencer � une valeur particuli�re. Les �l�ments dont les valeurs de l'attribut tabindex sont identiques devraient �tre parcourus dans l'ordre de leur apparition dans le flux de caract�re�;
2. Ceux des �l�ments qui ne reconnaissent pas l'attribut tabindex, ou bien le reconnaissent et lui assigne une valeur de "0", sont parcourus ensuite. Ces �l�ments sont parcourus dans l'ordre de leur apparition dans le flux de caract�res�;
3. Les �l�ments qui sont inactifs ne participent pas dans l'ordre de tabulation.

Les �l�ments suivants reconnaissent l'attribut tabindex�: A, AREA, BUTTON, INPUT, OBJECT, SELECT, et TEXTAREA.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>Un document avec FORM</TITLE>
</HEAD>
<BODY>
...un texte...
<P>Aller sur le
<A tabindex="10" href="http://www.w3.org/">site Web du W3C.</A>
...suite du texte...
<BUTTON type="button" name="base_de_donnees"
           tabindex="1" onclick="base_de_donnees()">
Obtenir la base de données courante.
</BUTTON>
...suite du texte...
<FORM action="..." method="post">
<P>
<INPUT tabindex="1" type="text" name="champs1">
<INPUT tabindex="2" type="text" name="champs2">
<INPUT tabindex="3" type="submit" name="submit">
</P>
</FORM>
</BODY>
</HTML>

17.11.2 Les cl�s d'acc�s

La pression de la cl� d'acc�s assign�e � un �l�ment lui donne l'attention. L'action qui survient quand l'�l�ment re�oit l'attention est fonction de l'�l�ment. Par exemple, quand l'utilisateur active un lien d�fini par l'�l�ment A, l'agent utilisateur suit en g�n�ral le lien. Quand l'utilisateur active un bouton radio, l'agent utilisateur change la valeur du bouton radio. Quand l'utilisateur active un champs de texte, la saisie devient possible, etc.

Les �l�ments suivants reconnaissent l'attribut accesskey�: A, AREA, BUTTON, INPUT, LABEL et LEGEND, ainsi que TEXTAREA.

<FORM action="..." method="post">
<P>
<LABEL for="label_utilisateur" accesskey="U">
User Name
</LABEL>
<INPUT type="text" name="utilisateur" id="label_utilisateur">
</P>
</FORM>

<P><A accesskey="T"
      rel="contents"
      href="http://quelquepart.com/specification/table_des_matieres.html">
    Table des matières</A>

L'invocation des cl�s d'acc�s est fonction du syst�me sous-jacent. Par exemple, sur les machines faisant tourner le syst�me MS Windows, on devra en g�n�ral presser la touche ��alt�� en plus de la cl� d'acc�s. Sur les syst�mes Apple, ce sera la touche ��cmd�� qu'il faudra appuyer en plus de la cl� d'acc�s.

La restitution des cl�s d'acc�s est fonction de l'agent utilisateur. Nous recommandons aux auteurs d'inclure la cl� d'acc�s dans le texte du label ou partout o� la cl� d'acc�s doit s'appliquer. Les agents utilisateurs devraient restituer la valeur d'une cl� d'acc�s de sorte � mettre en �vidence son r�le et � la distinguer des autres caract�res (par exemple, en la soulignant).

17.12 Les commandes inactives et en lecture seule

Dans les situations pour lesquelles les entr�es de l'utilisateur sont soit ind�sirables, soit hors de propos, il importe de pouvoir rendre une commande inactive ou de la restituer en lecture seule. Par exemple, on peut vouloir que le bouton de soumission d'un formulaire reste inactif tant que l'utilisateur n'a pas entr� certaines donn�es obligatoires. De la m�me mani�re, l'auteur peut vouloir inclure un bout de texte en lecture seule, qui doit �tre soumis comme valeur en m�me temps que le formulaire. Les sections suivantes d�crivent les commandes inactives et celles en lecture seule.

17.12.1 Les commandes inactives

Quand il est pr�sent, l'attribut disabled produit l'effet suivant sur un �l�ment�:

• les commandes inactives ne re�oivent pas l'attention�;
• les commandes inactives sont saut�es au cours d'une navigation par tabulation�;
• les commandes inactives ne peuvent pas r�ussir.

Les �l�ments suivants reconnaissent l'attribut disabled�: BUTTON, INPUT, OPTGROUP, OPTION, SELECT, et TEXTAREA.

Cet attribut est h�rit� mais les d�clarations locales surclassent la valeur h�rit�e.

La mani�re dont les �l�ments inactifs sont restitut�s est fonction de l'agent utilisateur. Par exemple, certains agents utilisateurs restituent en ��gris頻 les articles de menu, les labels de bouton, etc. qui sont inactifs.

<INPUT disabled name="fred" value="stone">

17.12.2 Les commandes en lecture seule

L'attribut readonly sp�cifie si la commande peut �tre modifi�e ou non par l'utilisateur.

Quand il est pr�sent, l'attribut readonly produit les effets suivants sur l'�l�ment�:

• les �l�ments en lecture seule re�oivent l'attention mais les utilisateurs ne peuvent pas les modifier�;
• les �l�ments en lecture seule sont inclus dans la navigation par tabulation�;
• les �l�ments en lecture seule peuvent r�ussir.

Les �l�ments suivants reconnaissent l'attribut readonly�: INPUT et TEXTAREA.

La mani�re dont les �l�ments en lecture seule sont restitu�s est fonction de l'agent utilisateur.

17.13 La soumission du formulaire

Les sections suivantes expliquent la mani�re dont les agents utilisateurs soumettent les donn�es de formulaire aux agents de traitement des formulaires.

17.13.1 La m�thode de soumission du formulaire

L'attribut method de l'�l�ment FORM sp�cifie la m�thode HTTP employ�e pour envoyer le formulaire � l'agent de traitement. Cet attribut admet deux valeurs�:

• get : avec la m�thode HTTP "get", l'ensemble des donn�s de formulaire est rajout� � l'URI sp�cifi� par l'attribut action (avec un caract�re point d'interrogation ��?�� comme s�parateur) et ce nouvel URI est envoy� � l'agent de traitement�;
• post : avec la m�thode HTTP "post", l'ensemble des donn�s de formulaire est inclus dans le corps du formulaire et envoy� � l'agent de traitement.

On devrait employer la m�thode "get" quand le formulaire est idempotent (i.e., ne produit aucun effet secondaires). Nombre de recherches dans les bases de donn�es n'ont pas d'effets secondaires visibles et font des applications id�ales pour la m�thode "get".

Si le service associ� au traitement d'un formulaire entra�ne des effets secondaires (par exemple, si le formulaire modifie une base de donn�es ou l'abonnement � un service), on devrait alors employer la m�thode "post".

17.13.2 Les commandes r�ussies

Une commande r�ussie est ��valable�� pour une soumission. Toute les commandes r�ussies ont leur nom de commande accoupl� � leur valeur courante et font partie du jeu des donn�es du formulaire qui est soumis. Une commande r�ussie doit �tre d�finie dans un �l�ment FORM et doit avoir un nom de commande.

Cependant :

• les commandes qui sont inactives ne peuvent pas r�ussir�;
• si le formulaire contient plusieurs boutons de soumission, seul le bouton de soumission actif r�ussira�;
• toutes les cases � cocher sur ��marche�� peuvent r�ussir�;
• pour les boutons radio qui partagent la m�me valeur d'attribut name, seul le bouton radio sur ��marche�� peut r�ussir�;
• pour les menus, le nom de commande est donn� par l'�l�ment SELECT et les valeurs sont fournies par les �l�ments OPTION. Seules les options s�lectionn�es peuvent r�ussir. Quand aucune option n'est s�lectionn�e, la commande ne r�ussit pas et ni le nom ni aucune valeur ne sont soumis au serveur avec le formulaire�;
• la valeur courante d'une s�lection de fichier est une liste d'un ou plusieurs noms de fichiers. Lors de la soumission du formulaire, le contenu de chaque fichier est soumis avec le restant des donn�es du formulaire. Les contenus des fichiers sont conditionn�s en fonction du type de contenu du formulaire�;
• la valeur courante d'une commande d'objet est d�termin�e par l'impl�mentatin de l'objet.

Si une commande n'a pas de valeur courante au moment de la soumission du formulaire, les agents utilisateurs ne sont pas oblig�s de la traiter comme une commande r�ussie.

De surcro�t, les agents utilisateurs ne devraient pas consid�rer les commandes suivantes comme �tant r�ussies�:

• les boutons de r�initialisation�;
• les �l�ments OBJECT dont l'attribut declare n'est pas sp�cifi�.

Les commandes cach�es et les commandes qui ne sont pas restitu�es en raison de l'effet d'une feuille de style peuvent quand m�me r�ussir. Par exemple�:

<FORM action="..." method="post">
<P>
<INPUT type="password" style="display:none"
          name="mot_de_passe_invisible"
          value="mon_mot_de_passe">
</FORM>

17.13.3 Le traitement des donn�es du formulaire

Quand l'utilisateur soumet le formulaire (par exemple, en activant un bouton de soumission), l'agent utilisateur le traite de la mani�re suivante.

Premi�re �tape : identifier les commandes r�ussies�

Deuxi�me �tape : construire le jeu des donn�es du formulaire�

Le jeu des donn�es du formulaire est la s�quence des couples nom de commande/valeur courante construite � partir des commandes r�ussies.

Troisi�me �tape : coder le jeu des donn�es du formulaire�

Le jeu des donn�es du formulaire est alors cod� en fonction du type de contenu sp�cifi� par l'attribut enctype de l'�l�ment FORM.

Quatri�me �tape : soumettre le jeu des donn�es du formulaire cod��

Enfin, les donn�es cod�es sont envoy�es � l'agent de traitement d�sign� par l'attribut action, en utilisant le protocole sp�cifi� par l'attribut method.

Cette sp�cification ne d�finit pas toutes les m�thodes de soumissions valides ni les types de contenu qui peuvent �tre utilis�s avec les formulaires. Cependant, les agents utilisateur HTML�4 doivent ob�ir aux conventions �tablies dans les cas suivants�s:

• si la valeur de l'attribut method est "get" et la valeur de l'attribut action est un URI HTTP, alors l'agent utilisateur prend la valeur de l'attribut action, lui rajoute un caract�re ��?�� et enfin le jeu des donn�es du formulaire, cod� en utilisant le type de contenu "application/x-www-form-urlencoded". L'agent utilisateur traverse alors le lien vers cet URI. Dans ce sc�nario, les donn�es du formulaire se limitent aux codes ASCII�;
• si la valeur de l'attribut method est "post" et la valeur de l'attribut action est un URI HTTP, alors l'agent utilisateur conduit une transaction HTTP "post" en utilisant la valeur de l'attribut action et un message cr�� en fonction du type de contenu sp�cifi� par l'attribut enctype.

Pour toute autre valeur de l'attribut action ou method, le comportement n'est pas sp�cifi�.

Les agents utilisateurs devraient restituer les r�ponses des transactions HTTP "get" et "post".

17.13.4 Les types de contenu du formulaire

L'attribut enctype de l'�l�ment FORM sp�cifie le type de contenu utilis� pour coder le jeu des donn�es du formulaire en vue de sa soumission au serveur. Les agents utilisateurs doivent reconna�tre les types de contenu list�s ci-dessous. Le comportement pour d'autres types de contenu n'est pas sp�cifi�.

Veuillez consulter �galement la section sur l'�chappement [ndt. escaping] des esperluettes dans les valeurs d'attribut des URI.

"application/x-www-form-urlencoded" �

C'est le type de contenu par d�faut. Les formulaires soumis avec ce type de contenu doivent �tre cod�s commes suit�:

1. Les noms de commandes et les valeurs sont �chapp�es. Les caract�res ��espace�� sont remplac�s par des caract�res plus ��+�� puis les caract�res r�serv�s sont �chapp�s comme d�crit dans le document [RFC1738], section 2.2�: Les caract�res non-alphanum�riques sont remplac�s par une s�quence de la forme ��%HH��, un caract�re pourcentage et deux chiffres hexad�cimaux qui repr�sentent le code ASCII du caract�re en question. Les sauts de ligne sont repr�sent�s par des couples de caract�res "CR LF" (i.e., "%0D%0A")�;
2. Les couples nom/valeur des commandes sont list�s selon leur ordre d'apparition dans le document. Le nom est s�par� de la valeur par un caract�re �gal ��=��, et les couples nom/valeur sont s�par�s les uns des autres par des caract�res esperluettes ��&��.

"multipart/form-data" �

Le type de contenu "application/x-www-form-urlencoded" est inefficace pour l'envoi de grandes quantit�s de donn�es binaires ou de texte contenant des caract�res non-ASCII. C'est le type de contenu "multipart/form-data" qui devrait �tre utilis� pour la soumission de formulaires contenant des fichiers, des donn�es non-ASCII et des donn�es binaires.

Le contenu "multipart/form-data" observe les r�gles de tous les flux de donn�es MIME en plusieurs parties, comme indiqu� dans le document [RFC2045]. La d�finition du type "multipart/form-data" est disponible dans les registres de l'[IANA].

Un message "multipart/form-data" contient une succession de parties, chacune d'elles repr�sentant une commande r�ussie. Les parties sont envoy�es � l'agent de traitement dans le m�me ordre selon lequel les commandes correspondantes apparaissent dans le flux du document. Les bornes de ces parties ne devraient pas survenir au milieu des donn�es� cette sp�cification ne d�finit pas la fa�on dont cela est fait.

Comme pour tous les types MIME en plusieurs parties, chaque partie poss�de en option un en-t�te ��Content-Type�� dont la valeur par d�faut est "text/plain". Les agents utilisateurs devraient produire l'en-t�te ��Content-Type��, accompagn� d'un param�tre "charset".

Chaque partie est cens�e contenir�:

1. un en-t�te ��Content-Disposition�� dont la valeur est "form-data"�;
2. un attribut name sp�cifiant le nom de commande de la commande correspondante. Les noms de commande, qui sont cod�s originellement dans des jeux de caract�res non-ASCII, peuvent �tre cod� � l'aide de la m�thode indiqu�e dans le document [RFC2045].

Ainsi, par exemple, pour une commande nomm�e "macommande", la partie correspondante serait sp�cifi�e par�:

Content-Disposition: form-data; name="macommande"

Comme pour toutes les transmissions MIME, on utilise les caract�res "CR LF" (i.e., "%0D%0A") pour s�parer les lignes de donn�es.

Chaque partie peut �tre cod�e et l'en-t�te ��Content-Transfer-Encoding�� peut �tre fourni, si la valeur de cette partie n'est pas conforme � l'encodage par d�faut (7BIT) (voir le document [RFC2045], section 6)

Si le contenu d'un fichier est soumis avec un formulaire, l'entr�e du fichier devrait �tre identifi�e par le type de contenu ad�quat (par exemple, "application/octet-stream"). Si plusieurs fichiers doivent �tre retourn�s en r�sultat d'une seule entr�e de formulaire, ils devraient �tre retourn�s comme type "multipart/mixed" imbriqu� dans le "multipart/form-data".

L'agent utilisateur devrait essayer de fournir un nom de fichier pour chaque fichier soumis. Le nom du fichier peut �tre sp�cifi� avec le param�tre "filename" dans un en-t�te 'Content-Disposition: form-data' ou, au cas o� il y aurait plusieurs fichiers, dans un en-t�te 'Content-Disposition: file' de la sous-partie. Si le nom de fichier du syst�me d'exploitation du client n'est pas en US-ASCII, le nom de fichier pourrait �tre approxim� ou cod� en utilisant la m�thode d�crite dans le document [RFC2045]. Cela est commode pour les cas o�, par exemple, les fichiers t�l�charg�s vers le serveur pourraient contenir des r�f�rences les uns vers les autres (par exemple, un fichier TeX et sa description de style auxilliaire ".sty").

L'exemple suivant illustre le codage "multipart/form-data". Supposons le formulaire suivant�:

 <FORM action="http://server.com/cgi/gestion"
       enctype="multipart/form-data"
       method="post">
   <P>
   Quel est votre nom ? <INPUT type="text" name="nom_soumis"><BR>
   Quels sont les fichiers à envoyer ? <INPUT type="file" name="fichiers"><BR>
   <INPUT type="submit" value="Envoyer"> <INPUT type="reset">
 </FORM>

Si l'utilisateur saisit "Martin" dans la commande de texte et s�lectionne le fichier textuel "fichier1.txt", l'agent utilisateur pourrait envoyer en retour les donn�es suivantes�:

   Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="nom_soumis"

   Martin
   --AaB03x
   Content-Disposition: form-data; name="fichiers"; filename="fichier1.txt"
   Content-Type: text/plain

   ... contenu de fichier1.txt ...
   --AaB03x--

Si l'utilisateur avait s�lectionn� un second fichier (image) "fichier2.gif", l'agent utilisateur pourrait assembler les parties comme suit�:

   Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="nom_soumis"

   Martin
   --AaB03x
   Content-Disposition: form-data; name="fichiers"
   Content-Type: multipart/mixed; boundary=BbC04y

   --BbC04y
   Content-Disposition: file; filename="fichier1.txt"
   Content-Type: text/plain

   ... contenu de fichier1.txt ...

   --BbC04y
   Content-Disposition: file; filename="fichier2.gif"
   Content-Type: image/gif
   Content-Transfer-Encoding: binary

   ...contenu de fichier2.gif...

                        errata-10
   --BbC04y--
   --AaB03x--