Life & IT Alignement

Aller au contenu | Aller au menu | Aller à la recherche

Tag - Java

Fil des billets - Fil des commentaires

jeudi 28 avril 2011

Formulaire UTF-8

Par Nicolas Chapin le jeudi 28 avril 2011, 20:06 - Dev

Dans un formulaire HTML, à moins de le forcer via l'attribut accept-charset de la balise form, le navigateur envoit les données dans le même charset que la page. Du coup si la page est en UTF-8 les données sont envoyées en UTF-8. Ce qui après tout est le but. Encore faut-il que le serveur d'application sache lire les données, je pense notamment à Tomcat & JBoss.

Dans le cas d'un GET. Le fameux paramètre URIEncoding=UTF-8, permet de s'en tirer et d'interpréter correctement les données en URL. Lors du POST d'un formulaire url-encoded, le navigateur ne précise pas le charset et les données sont dans le corps. Du coup le serveur d'application ne sachant pas quoi faire tombe dans son comportement par défaut. Dans le cas de JBoss, il décode les données du formulaire en ISO-8859-1. Et là, c'est le drame.

Une petite astuce à faire au niveau d'Apache, il suffit de surcharger l'en-tête du type de contenu:

SetEnvIf Content-Type "application/x-www-form-urlencoded" utf8_form=true
RequestHeader set Content-Type "application/x-www-form-urlencoded; charset=UTF-8" env=utf8_form

Et voilà, plus de problème, JBoss interprète correctement le charset.

un commentaire

mercredi 13 septembre 2006

Du bon choix d'un langage

Par Nicolas Chapin le mercredi 13 septembre 2006, 13:49 - Technologie

Joel Spolsky a lancé un gros troll sur les performances de Ruby et s'est attiré plusieurs réponses cinglantes:

  1. Sur la différence entre efficacité et montée en charge.
  2. Sur la possibilité d'optimiser la VML de Ruby.
  3. Sur le fait que Ryby n'est pas fait pour les performances CPU.

Le dernier point développé est à mon avis le plus important et je l'avais déjà vu, il me semble, dans les essais de Paul Graham.

  1. Dans l'écriture d'un logiciel, ce qui coûte le plus cher, ce n'est pas les cycles processeurs mais les cycles développeurs. Donc il est extrêmement utile d'avoir des outils qui favorisent grandement les performances des développeurs comme Ruby.
  2. 90% du code n'a rien à voir avec les performances, c'est juste de l'enrobage pour faire fonctionner tout le bastringue.
  3. Sur les 10% restant 90% peut être optimisé par des méthodes algorithmiques (pour un classique voir l'optimisation du calcul de la suite de fibonnaci).
  4. Sur le 1% restant, les langages de haut niveau offre généralement (sinon ils sont inutiles) de pouvoir utiliser des systèmes de plus bas niveau (C ou ligne de commande). Pour améliorer les fonctions qui sont gourmandes en calcul, il suffit donc de les implémenter en C voir en assembleur si on tient vraiement à faire de l'optimisation de bourrin. C'est ce que font Yahoo, Amazon, Google et les autres avec des frameworks de présentation web Java, PHP, PERL et des bibilothèques optimisées en C++.

Donc moralité de l'histoire:

  1. Ne pas chercher à optimiser tout de suite, mais à développer les fonctionnalités.
  2. Utiliser le langage le plus productif pour les développements et non le plus performant pour le processeur.
  3. Une fois identifié les goulots d'étranglement, les optimiser en les codants dans un langage performant ce qui se résume à du C ou du C++, voir de l'assembleur pour les brutes.

aucun commentaire