5. Formulaires

Les formulaires étant un des seuls moyens d'obtenir des données de l'utilisateur, il est naturel de s'attendre à y trouver du texte en n'importe quelle langue. Bien que ce soit principalement un sujet d'interface-utilisateur, quelques considérations au niveau HTML sont utiles pour conseiller et promouvoir l'interopérabilité.

Pour assurer la pleine interopérabilité, il est nécessaire que l'agent-usager (et l'utilisateur) ait une indication du (ou des) codage de caractères que le serveur fournissant un formulaire saura accepter à la réception du formulaire rempli. Cette indication est fournie par le nouvel attribut ACCEPT-CHARSET des éléments INPUT et TEXTAREA, calqué sur l'en-tête HTTP Accept-Charset (voir [HTTP-1.1]), qui contient une liste de jeux de caractères, séparés par des espaces et/ou des virgules, acceptables par le serveur. Un agent-usager pourrait informer l'utilisateur du contenu de cet attribut, ou l'empêcher de saisir des caractères hors des répertoires des dits jeux de caractères.

NOTE — la liste de jeux de caractères doit être interprétée comme une liste OU-EXCLUSIF ; le serveur annonce que, pour chaque partie d'une entité multipartite, il peut accepter UN SEUL codage de caractères parmi la liste. Le client peut transcoder au besoin pour satisfaire le serveur.

NOTE — la valeur implicite de l'attribut ACCEPT-CHARSET d'un élément INPUT ou TEXTAREA est la valeur réservée UNKNOWN. On pourra interpréter cette valeur comme celle du codage de caractères utilisé par le document contenant cet élément.

Le mécanisme de soumission de formulaires d'HTML 2.0, fondé sur le type de contenu application/x-www-form-urlencoded, est pauvre en ce qui concerne l'internationalisation. En fait, les URL étant limités à l'ASCII, le mécanisme est inadéquat même pour du texte ISO-8859-1. La section 2.2 du [RFC1738] précise que des octets peuvent être codés selon la notation %HH, mais le texte d'un formulaire est composé de caractères, et non pas d'octets. Sans définition du codage de caractères, la notation %HH n'a pas de sens.

La meilleure solution est d'utiliser le type de contenu multipart/form-data, décrit dans le [RFC1867], avec la méthode POST de soumission de formulaires. Ce mécanisme emballe chaque paire nom-valeur dans une partie d'un corps multipartite MIME qui est transmis comme entité HTTP ; chaque partie peut être étiquetée avec un Content-Type approprié, y compris si nécessaire un paramètre charset qui spécifie le codage de caractères. Les changements à la DTD nécessaires pour cette méthode de soumission de formulaires ont été incorporés dans la DTD de ce document.

Une solution moins satisfaisante est d'ajouter un paramètre charset à l'étiquette de type de contenu application/x-www-form-urlencoded transmis avec une soumission de formulaire de type POST ; il est alors entendu que le codage URL du [RFC1738] est appliqué en sus du codage de caractères, en tant que Content-Transfer-Encoding implicite.

Il est regrettable que les fureteurs actuels ne permettent aux signets de préciser la méthode POST, ce qui devrait être corrigé. La méthode GET pourrait aussi être utilisée avec les données du formulaire comme entité plutôt que codé dans l'URL. Rien dans le protocole ne semble l'interdire, mais aucune réalisation ne semble exister à l'heure actuelle.

La manière dont l'agent-usager détermine le codage du texte saisi par l'utilisateur est hors du domaine d'application de ce document.

NOTE — les concepteurs de formulaires et de leurs scripts de support devrait être au courant d'un important problème potentiel : lorsque la valeur implicite d'un champ (l'attribut VALUE) est retournée à la soumission (l'utilisateur n'ayant pas modifié cette valeur), il n'y a aucune garantie que la séquence d'octets sera identique à celle du document source, mais seulement comme un codage valide mais peut-être différent de la même séquence d'éléments de texte. Ceci peut se produire même si le codage du document contenant le formulaire et celui utilisé pour sa soumission sont identiques.

Il peut y avoir des différences quand le codage permet qu'une séquence de caractères soit représentée par plusieurs séquences d'octets, et aussi quand une séquence composite (un caractère de base suivi de caractères combinatoires) peut être représentée soit par une autre séquence composite équivalente, soit par un caractère précomposé. Par exemple, la séquence UCS-2 00EA+0323 (LETTRE MINUSCULE LATINE E ACCENT CIRCONFLEXE + DIACRITIQUE POINT SOUSCRIT) peut devenir 1EC7 (LETTRE MINUSCULE LATINE E ACCENT CIRCONFLEXE ET POINT SOUSCRIT), 0065+0302+0323 (LETTRE MINUSCULE LATINE E + DIACRITIQUE ACCENT CIRCONFLEXE + DIACRITIQUE POINT SOUSCRIT), ou d'autres séquences composites équivalentes.