Dans Ruby sur Rails 3 (utilisant actuellement la version bêta 4)), je vois que lorsque vous utilisez le form_tag
ou form_for
aides il y a un champ caché nommé _snowman
avec la valeur de ☃ ( nicode \x9731).
Alors, à quoi ça sert?
Ceci est là pour supporter Internet Explorer 5 et l'encourager à utiliser TF-8 pour ses formulaires.
Le message de validation vu ici le détaille comme suit:
Corrigez plusieurs problèmes connus d'encodage Web:
- Spécifiez accept-charset sur tous les formulaires. Tous les navigateurs récents, ainsi que IE5 +, utiliseront l'encodage spécifié pour les paramètres de formulaire.
- Malheureusement, IE5 + ne regardera pas accept-charset si au moins un caractère dans les valeurs du formulaire ne figure pas dans le jeu de caractères de la page. Puisque l'utilisateur peut remplacer la valeur par défaut
charset (qui Rails est défini sur UTF-8), nous fournissons une entrée masquée contenant un caractère unicode, forçant IE à regarder le accept-charset.- Maintenant que la grande majorité des entrées Web est UTF-8, nous définissons les paramètres entrants sur UTF-8. Ceci éliminera de nombreux cas d’encodages incompatibles entre ASCII-8BIT et
UTF-8.- Vous pouvez en toute sécurité ignorer les paramètres [: _ bonhomme de neige]
En bref, vous pouvez ignorer ce paramètre en toute sécurité.
Cependant, je ne suis pas sûr de savoir pourquoi nous prenons en charge d'anciennes technologies telles qu'Internet Explorer 5. Cela semble être une décision très peu ruby sur Rails si vous me demandez.
Ce paramètre a été ajouté aux formulaires afin de forcer Internet Explorer (5, 6, 7 et 8) à coder ses paramètres en tant que code Unicode.
Plus précisément, ce bogue peut être déclenché si l'utilisateur bascule le codage du navigateur sur Latin-1. Pour comprendre pourquoi un utilisateur décide de faire quelque chose qui semble si fou, consultez cette recherche sur Google . Une fois que l'utilisateur a placé le site Web en mode Latin-1, s'il utilise des caractères pouvant être compris à la fois en Latin-1 et en Unicode (par exemple, é ou ç, noms communs), Internet Explorer les encodera en latin. -1.
Cela signifie que si un utilisateur recherche "Ché Guevara", le message sera mal interprété côté serveur. Dans Ruby 1.9, cela entraînera une erreur de codage lorsque le texte fera inévitablement son chemin dans le moteur des expressions régulières. Dans Ruby 1.8, cela entraînera des résultats erronés pour l'utilisateur.
En créant un paramètre qui ne peut être compris que par IE en tant que caractère unicode, nous forçons IE à regarder l'attribut accept-charset, qui lui indique ensuite de coder tous les caractères au format UTF- 8, même ceux qui peuvent être encodés en latin-1.
Gardez à l'esprit que dans Ruby 1.8, il est extrêmement simple de placer des données Latin-1 dans votre base de données UTF-8 (car rien dans toute la pile vérifie que les octets que l'utilisateur a envoyés à un moment donné sont des caractères UTF-8 valides). Par conséquent, il est extrêmement courant que les applications Ruby (et les applications PHP, etc.) présentent ce bogue adressé à l'utilisateur. Il est donc extrêmement courant que les utilisateurs essaient de modifier l'encodage en tant que mesure palliative.
Cela étant dit, lorsque j'ai écrit ce correctif, je n'avais pas réalisé que le nom du paramètre apparaîtrait jamais dans un emplacement où se trouvent les utilisateurs (cela s'applique aux formulaires utilisant l'action GET, tels que les formulaires de recherche). Dans ce cas, nous renommerons ce paramètre en _e
Et utiliserons un caractère unicode plus inoffensif.