Blog de David MASCLET

Détecter et corriger les fuites mémoire java

Masclet — Mon, 01 Mar 2010 09:16:00 +0100

Ceux qui ont déjà développé en C, puis en Java auront probablement apprécié la gestion de la mémoire par la JVM. En effet, Java masque la complexité de la gestion de la mémoire aux développeurs. Cette tache est déléguée au garbage Collector. Cependant même si cette gestion est dite 'automatique', cela ne permet pas de faire n'importe quoi. Que ce soit en C, Java, ou un autre langage, la mémoire est une ressource limitée ! En java lorsque la JVM n'a plus assez de mémoire pour s'exécuter, elle génère une Erreur java.lang.OutOfMemoryError.

Plusieurs cas sont alors possible :

Soit vous n'avez pas alloué assez de mémoire à la JVM
Soit votre code a ce qu'on appelle un fuite mémoire

Si vous êtes dans le premier cas, les choses se résolvent assez facilement : il vous suffit d'allouer plus de mémoire grâce aux paramètres -Xmx, -Xms et -XX:PermSize (ou de modifier le code pour qu'il gaspille moins de mémoire). Dans le deuxième cas vous allez devoir trouver où se situe la fuite mémoire. Si vous avez utilisé des logiciels pour vous y aider, vous avez peut être été perdu par toutes les possibilités qu'ils offrent et par la profusion d'informations qu'il fournissent.

Le but de ce billet est d'expliquer comment détecter et corriger les fuites mémoires avec Eclipse Memory Analyser Tool un outil gratuit et très utile qui aide vraiment à trouver les fuites mémoires. Nous allons voir comment extraire les informations pertinentes, les comprendre, et trouver les responsables des fuites mémoire en ayant une approche pragmatique. Je vous propose de nous appuyer sur du code simple (disponible en fichier attaché à ce billet) générant une fuite mémoire.

La gestion de la mémoire en Java

La JVM dispose de plusieurs zones mémoire distinctes :

La pile (ou heap), est l'espace mémoire où tous les objets et tableaux sont stockés. Lorsque la JVM démarre, la pile est initialisée à la valeur spécifiée par -Xms et elle grandira dynamiquement quand les objets seront crées, jusqu'à ce qu'elle atteigne sa taille maximale spécifiée par le paramètre -Xmx. Si la taille maximale est atteinte, et que plus de mémoire est nécessaire, la JVM générera une java.lang.OutOfMemoryError: Java heap space.
Permgen space : il s'agit de l'espace mémoire qui est alloué pour le chargement des classes (pas les objets). A la différence de la pile, la taille de cette région est fixe et ne varie plus après le démarrage de la JVM. Pour la JVM de Sun, la taille par défaut du permGen space est de 64M. Vous pouvez changer cette valeur grâce au paramètre -XX:PermSize. Rappelons tout de même que les options commençant par XX ne sont pas des paramètres HotSpot stables et que leurs compatibilités dépendent du vendeur et de la version de la JVM. Si la mémoire du permgen est insuffisante une java.lang.OutOfMemoryError: PermGen space sera renvoyée
il existe un troisième type d'erreurs : les erreurs natives. Elles apparaissent lorsque le système hôte ne peut plus fournir de mémoire (plus assez de place en mémoire vive, ou plus assez de swap). Dans ce cas la JVM génère une Erreur java.lang.OutOfMemoryError: request <size> bytes for <reason>.

Cas des champs statiques : Les champs statiques ne peuvent être garbage collectés tant que la classe qui les référence est chargée. il ne peuvent être garbage collectés que lorsque le class loader qui est responsable du chargement de la classe est lui même garbage collecté.

Chaque instance de classe a une taille en mémoire, cette taille appelée "Shallow Heap" est constituée de types primitifs (int, char, ...). Une instance peut avoir également des références sur d'autres objets qui ont eux même une taille. Les objets ainsi liés entre eux constituent un graphe.

Tous les graphes disposent d'une racine d'attache, ces racines peuvent être, par exemple, des threads ou des class loaders qui tiennent des références sur les attributs statiques. Ces racines se nomment en anglais des "GC root". Toutes les instances en mémoire finissent par être attachées à une racine, si ce n'est pas le cas, le Garbage Collector peut supprimer ces instances du graphe, et libérer de la mémoire.

Les références peuvent être de plusieurs types. Il y avait les références fortes "StrongReference" et depuis java 5 il existe des références dites douces "SoftReference" : L'objet est référencé, mais si la JVM a besoin de mémoire, elle peut libérer cet objet. On trouve également les références légères "WeakReference": L'objet restera en mémoire, tant qu'il existe une référence forte ou douce sur lui. enfin il existe des PhantomReference : les objets peuvent être supprimés de la mémoire si aucune référence forte, douce, ou légère existe sur cette objet.

Empreinte de la mémoire (Heap dump)

Afin de permettre des diagnostiques et de voir ce que contient la mémoire de la JVM, il est possible de générer une "empreinte de la mémoire" qui correspond à tous les objets chargés à un instant précis. Ces empreintes sont plus connus sous le nom de "Heap dump".

Ces dumps contiennent :

Tous les objets : champs, références, et objet primitifs.
Toutes les classes : Class loader, super Class, champs statiques

En revanche il ne contient pas les informations sur qui et où sont crées les objets, ni quels sont les objets qui ont déjà été garbage collectés.

Il existe différentes méthodes pour générer ces dumps. Soit en spécifiant les options -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/dump.hprof au lancement de la JVM afin qu'un dump soit généré lorsqu'une java.lang.OutOfMemoryError survient. Notez toutefois que comme toutes les options commençant par XX, elles sont dépendantes du vendeur de JVM. La deuxième solution est de faire un dump à la demande, à l'aide du JDK 6 et de JConsole. les dumps à la demande sont utiles, par exemples, après des benchs.

Voici la procédure :

Lancez JConsole situé dans le répertoire "bin" de la JVM
Sélectionnez le processus Java pour lequel vous voulez faire le dump. Vérifiez sur l'onglet "VM summary" que c'est bien le bon processus.
Rendez vous sur l'onglet Mbeans
Sélectionnez l'item com.sun.management / hotspot diagnostic / operation / dumpheap
Spécifiez le chemin complet du fichier où vous voulez stocker le dump dans le premier champs de saisie (laissez le deuxième champs à true). Les dumps ont souvent l'extension hprof, et MAT ne verra pas le fichier s'il n'a pas la bonne extension.
Validez en cliquant sur le bouton "dumpHeap". Cela figera l'exécution de la JVM (donc à éviter en production), exécutera un garbage collector, et générera un fichier binaire avec le contenu de la mémoire.

Qu'est ce qu'une fuite mémoire

Une fuite mémoire est une dérive non contrôlée de l'utilisation de la mémoire. elle est souvent due à un objet qui garde des références à une multitude d'autres, ce qui empêche le garbage collector de les enlever de la mémoire. Cette dernière grandit alors de plus en plus et finit par saturer.

Pour comprendre une fuite mémoire il faut connaitre quelques termes (en anglais):

Dominator tree : Liste des plus gros objets et de qui les référencent.
Leak suspect : Objet ayant une grosse taille dans le dominator tree.
Accumulation point : Gros objet référençant beaucoup d'autres petits objets

Voici un représentation graphique des termes évoqués ci dessus :

Shallow Heap et retained Heap : il s'agit de la taille que prend un objet sur la pile. "shallow heap" représente la taille des éléments de l'objet sans inclure les objets qu'il référence, tandis que "retained Heap" les prend en compte : elle représente la taille qui sera libéré si cet objet est garbage collecté. Voici un exemple pour mieux comprendre :

Ci dessous ce trouve la représentation interne d'une string que j'ai pu obtenir avec le mode debug d'Eclipse :

On voit qu'une string est représentée par trois entiers : count, hash, et offset, qui représente la shallow heap, ainsi qu'une référence "value" à un tableau de char . count, hash, offset et value représente la retained heap car le char sera également garbage collecté si la string l'est aussi.

Eclipse Memory Analyser Tool

Il existe déjà des outils permettant d'analyser les dumps, mais ils sont soit difficiles d'approche comme jhat (Java Heap Analysis Tool) et jmap soit il sont payants comme Jprofiler.

Eclipse a développé un outil permettant d'analyser les heap dumps. Cela permet d'aider à trouver où se situent les fuites mémoires et de détecter les gaspillages et améliorations possibles de l'utilisation de la mémoire. L'outil ne se contente pas de vous analyser la mémoire, il cherche également où peuvent se situer les fuites ainsi que les optimisations. c'est là le point fort de cet outil.

MAT peut être installé en tant que plugin dans Eclipse, ce qui a l'avantage de pouvoir regarder le code en même temps que de regarder le dump, ou en tant que client lourd (RCP) à part entière, des scripts sont alors disponibles en plus du plugins. Peu importe votre choix, vous pouvez vous rendre sur cette page pour le télécharger.

Utilisation de MAT avec un code d'exemple

Je vous propose de tester MAT avec du code simple (disponible en fichier attaché à ce billet) générant une fuite mémoire. Le code représentera plusieurs objets métiers : une entreprise, des salariés, et des adresses, ainsi qu'une classe permettant de générer quelques instances de ces objets et une HashMap statique servant de cache pour les objets Entreprise. Enfin une fois tous ces objets chargés, je provoquerai une fuite mémoire en remplissant un tableau avec des Double. Je dis bien "provoquerai", car à la différence des Exceptions, les Errors sont générées par la JVM et non par le code : si je fais

throw new OutOfMemoryError();

et que je spécifie les options HeapDumpOnOutOfMemoryError le dump ne sera pas généré.

je lance donc la classe Application avec les options -XX:+HeapDumpOnOutOfMemoryError -Xms5m -Xmx10m -XX:MaxPermSize=256m.

En l'absence de HeapDumpPath, c'est un fichier avec le PID qui sera généré, l'avantage étant qu'un nouveau fichier de dump sera généré à chaque java.lang.OutOfMemoryError (il ne sera pas écrasé puisque le nom sera différent à chaque fois)

Le lancement du programme me donne la sortie suivante :

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid2331.hprof ...
Heap dump file created [13486084 bytes in 0.401 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at java.util.ArrayList.ensureCapacity(ArrayList.java:169)
        at java.util.ArrayList.add(ArrayList.java:351)
        at com.demo.mat.OutOfMemoryHelper.addDouble(OutOfMemoryHelper.java:18)
        at com.demo.mat.OutOfMemoryHelper.throwOutOfMemoryError(OutOfMemoryHelper.java:13)
        at com.demo.mat.Application.main(Application.java:74)

Il ne reste plus qu'a analyser le dump. vous pouvez l'ouvrir directement en lançant MAT, puis en allant dans File->Open Heap Dump et en sélectionnant le fichier java_pid2331.hprof. (seuls les fichiers .hprof apparaitrons). MAT générera alors plusieurs indexes et un rapport HTML. Les indexes permettent de naviguer plus rapidement car le format hprof n'est pas très exploitable en l'état. Cette génération n'aura lieu qu'une seul fois et lorsque vous rouvrirez ce dump, Mat utilisera les fichier déjà générés.

Dans notre cas le fichier sera de 10 méga octets (environ taille du Xmx), mais si vous voulez analyser de gros fichiers je vous conseille d'utiliser la ligne de commande:

./MemoryAnalyzer -consolelog -application org.eclipse.mat.api.parse java_pid2331.hprof

car MAT a des fois du mal à les digérer. L'ouverture par MAT sera alors plus rapide et facile.

Prise en main de l'outil

Le rapport donne une première vue avec

les informations sur la taille du dump (8.7M) et le nombre de classe chargées (360)
un camembert représentant les plus gros objets en mémoire. En passant votre souris sur chaque partie du camembert, vous pouvez avoir des informations sur les attributs (références et champs natifs) de l'objet dans la colonne de gauche 'attributes'

Différentes actions menant vers différentes vues du dump :

Un histogramme : qui affiche une représentation de l'utilisation mémoire par classes (nombre d'objets instanciés par classe, ainsi que leurs tailles 'shallow' et 'retained'). Vous pouvez d'ailleurs voir que le nombre de char est sensiblement le même que le nombre de String ;)
Un dominator tree (voir définition ci dessus) : présente non plus une vue par classes mais par objets
Une vue graphique des objets du dominator tree groupés selon différents critères : class loaders, packages, classes. Le dominator tree travaille, si on ne spécifie pas de groupage, au niveau objet
Une liste des classes chargées plusieurs fois par différents class loader.

Les parties les plus intéressantes du rapport et les plus exploitables directement sont sans aucun doute les deux rapports suivants:

Liste des 'leak suspects', c'est à dire que l'outil vous suggère où peuvent se situer les responsables de fuites mémoires.
Une liste des objets gaspillant la mémoire (e.g : ArrayList surdimensionnées ayant beaucoup d'éléments vides) avec des suggestions d'optimisations de l'utilisation mémoire (à ne pas confondre avec le rapports des fuites mémoires.)

Voyons vue par vue, les choses que nous pouvons faire : Dans toutes les vues vous avez la possibilité de voir ce que contient l'objet sélectionné dans l'onglet "attributes".

Il est possible de calculer la taille de la 'retained heap' via l'icône représentant un calculatrice.

Vous pouvez ainsi trier les objets par 'retained heap' pour identifier les 'leak supect'. Vous pouvez aussi les filtrés en rentrant des expressions régulières juste en dessous des libellés de colonnes (e.g : "regex" en dessous de 'Class Name'). Attention pour les regexp, elles sont sensibles à la casse.

Une action qui révèle souvent des informations intéressantes, consiste à grouper les objets. Si vous les groupez par classe, vous pouvez par exemple obtenir le nombre d'objets et le pourcentage de la mémoire totale qu'occupe les objets de cette classe. Cela permet d'identifier les points d'accumulation plus facilement lorsque la fuite mémoire ne concerne pas un seul gros objet (ce qui n'est pas notre cas) mais une multitude d'objets de la même classe. Par défaut, la distribution de l'occupation de la mémoire ce fait par objet, en les groupant, les shallow / retained heap sont alors additionnés, laissant souvent voir une répartition inégale de l'utilisation de la mémoire selon les classes (en savoir plus). Vous pouvez aussi les grouper par class loader, ce qui peut se révéler intéressant pour des webapps, Tomcat, par exemple, utilise des class loader differents : webappClassLoader et un SystemClassLoader (en savoir plus). OSGI (voir l'article publié précédemment) utilise aussi beaucoup de class loader différents

Explication des menus

Lorsque vous cliquez droit sur les objets du dominator tree ou sur les classes de l'histogramme, vous obtenez un menu vous permettant d'avoir des informations sur l'élément sélectionné :

List objects=>with outgoing references: objets référencés par l'élément sélectionné. Si on additionne la taille de ces objets, on obtient la retained size.
List objects=>with incomming references : objets qui référencent l'élément sélectionné.

La liste des objets est contextuelle à l'élément sélectionné : si les objets sont groupés par classe, ou que l'élément est une classe, une ligne par objet de cette classe sera affichée, si l'élément est un objet, alors seuls les objets concernés par cet objet (référencé par / qui référence) seront affichés

List class => by outgoing references : les classes des objets référencés par l'élément.
List class => by Incoming references : Les classes des objets qui ont une référence sur l'élément

La liste des classes affichée est également contextuelle. Exemple pour outgoing référence : si l'élément sélectionné est une classe, alors la liste de toutes les classes référencées par tous les objets de cette classe sera listée, si l'élément est un objet, seule la liste des classes référencées par cet objet sera affichée.

Path to GC root => Affiche les chemins des objets qui référence cet objet jusqu'à leur élément racine (un peu comme les incomming objects mais moins en profondeur car s'arrête lorsque l'on arrive au sommet de la pile du thread auquel appartient l'élément). Il est possible via les sous menus de filtrer selon les weak / soft / hard références. ce qui peut être utile lorsque vous utilisez des caches d'objets avec des références soft, car vous pouvez uniquement inspecter l'élément en tenant compte ou pas du cache. Ce menu n'est applicable que pour un objet pas pour classe.

Merge Path to GC root : affiche le chemin le plus court parmi les références racines pour chaque instance de la classe ou de l'objet sélectionné

Java basics permet d'avoir des renseignements divers sur l'objet (e.g : chercher une String). Depuis la version 0.8, il est possible d'analyser les stacktraces. Ces informations sont disponibles via le menu java basics=>threads stacks

Java collections sert plus à détecter les gaspillages de mémoire. il permet par exemple d'avoir le ratio de remplissage d'un tableau.

Leak identification=> Component Report : permet d'avoir des informations sur la mémoire occupée par cette objet : taille que l'objet ou que les objets d'une classe occupent dans la pile, leurs soft et leurs hard références,

Leak identification=> Top consumer : les plus gros éléments regroupés et triés selon différents critères : Objet, Classe, Class loader, Package. il permet d'avoir une répartition des objets par classe (e.g : trouver quels sont les plus gros objets de la classe Salariés). ce menu est utile lorsque vous l'appliquez sur une classe, car il montre quels sont les plus gros objets de cette classe et leurs répartitions

Immediate dominator : Donne les classes des objets qui font que l'élément est gardé en mémoire (e.g : les immediate dominators de char sont bien souvent des String). Il est souvent utile de filtrer les classes des package com.sun.* et java.* car on peut supposer que la fuite ne vienne pas de là. Dans l'exemple ci dessous, pour les immediate dominator de char, si on considère la ligne concernant Entreprise : La première colonne donne le nombre d'objets de la classe listée (1), la deuxième donne le nombre d'objets référencés par cette classe (3) (un objet Entreprise référence 3 char correspondant aux trois commentaires).

Show retained set : donne le nombre d'objets que référence l'élément, groupés par classe. le retained set représente les objets qui seront libérés si l'élément est garbage collecté. Pour un objet Entreprise, il contient 3 char, 3 Strings et une Entreprise (les trois commentaires+ la class ). vous pouvez filtrer le retained set par le ou les noms des champs. On peut alors se demander "Pourquoi les objets "raison social", "salariés" ne sont pas dans la retained set alors qu'on les voit si on liste les outgoing objects de Entreprise. La réponse est que ces objets ne seront pas libérés si Entreprise disparait. Pour le prouver faites un incomming référence sur les objet de Entreprise : les commentaires ne sont uniquement référencés par Entreprise, alors que raison social par exemple est également référencé comme clé pour la Hashmap de cacheEntreprise. De même pour "raison social" qui est une constante car déclarée dans le code, alors que les 3 commentaires sont générés au runtime.

Savoir lire les graphes

Lorsque l'on est devant un graphe, il est important de savoir le lire. prenons l'exemple pour des 'outgoing références' :

La classe Entreprise à des référence vers 4 objets de type String qui se nomme 'commentaire', 'commentaire2', commentaire3, et 'raison social'. et une ArrayList qui se nome salarié. si l'un des objet avait une valeur null, il n'aurait pas été listé.

Voyons maintenant comment lire des 'incoming références' :

L'objet entreprise (je dis bien objet et pas classe) est référencé par :

Le champs 'entreprise' de 3 objets de type Salarié,
Le thread lui même , correspondant à la déclaration de la variable (Entreprise entreprise = new Entreprise() )
Le champs 'value' d'une HashMap, correspondant à la HashMap de cache nommée entreprise et appartenant à la classe CacheEntreprise .

Lorsque l'on analyse des dumps mémoire, il est fortement conseillé de connaitre la représentation interne des objets Map, Collections, String, etc. Cela permet de mieux naviguer. Une HashMap est par exemple constitué d'un tableau de hashMapEntry, lui même constitué de champs key, value, et hash. Si vous voulez explorer un objet, allez sur l'onglet 'attributes', cliquez droit, puis sélectionnez 'Go into' :

Les rapports de fuites mémoires

Entrons maintenant dans le vif du sujet. Le rapport proposant des responsables des fuites mémoires. Comment cela fonctionne ? En fait l'outil analyse le dump et recherche les 'Leak suspects', Il commence par chercher les points d'accumulation en analysant les écarts significatifs dans la retained size entre deux objets du graphe, puis remonte les 'incomming references', prend le plus court chemin, et en déduit le suspect.

Un rapport HTML comprenant plusieurs sections est alors généré :

les points d'accumulation : donnent les informations sur la taille et le type d'objets, le thread incriminé, et le nombre d'objets contenus.

Le rapport génère aussi une liste de mots clés permettant de le googliser ou de les taper dans un bug tracker. L'idée est à mon sens excellente : Lorsque vous créez le bug, vous y ajoutez ces mots clés, et une personne qui désire retrouver ce bug ou voir si une résolution a déjà été trouvée, tape ces mots clés, retrouve le bug et une potentielle résolution éprouvée.

Deux questions se posent alors :

Qui garde une référence à cet objet ?
Pourquoi l'objet est si gros et que contient il ?

Pour la première question on va chercher quel est le plus court chemin du GC root jusqu'à l'objet du point d'accumulation :

Le graphe ce lit 'ligne du haut' est contenu par 'ligne du dessous'. Dans l'exemple ci dessus : le tableau d'objet est référencé par le thread (Chemin le plus court) et par une ArrayList

Pour la deuxième question MAT nous donne un aperçu des objets référencés par le point d'accumulation. Cela permet en général d'avoir une idée plus précise de la cause de la fuite.

Le rapport fournit également une répartition des objets référencé par le point d'accumulation par classes. Dans notre cas, le tableau d'objet ne contient que des Double, ce qui laisse à penser qu'une méthode remplit le tableau.

Une autre information intéressante est l'environnement d'exécution. Dans quel contexte a eu lieu le dump. Cela à une importance quand vous utilisez -XX:HeapDumpOnOutOfMemoryError . Les informations importantes sont entre autres :

Les propriétés de la JVM (Xms, Xmx). Peut être un mauvais dimensionnement de la mémoire ?
Le nombre de threads et leurs tailles permettent de voir si un seul thread est incriminé, et dans ce cas, selon la nature de traitement qu'à le thread, vous pouvez plus cibler la fuite (exemple : un thread de purge d'un cache)
L'histogramme des classes peut également donner des informations sur la cause. S'il existe un grand nombre d'objets appartenant à un classe d'un de vos package, il est probable (pas à 100%, mais vous disposez déjà d'une piste) que la fuite est causée par du code vous appartenant.

Informations sur les threads

MAT fournit des informations sur le context d'exécution des threads. il inspecte les variables threadLocal et selon ce qu'il y trouve, nous donne des informations supplémentaires. exemple :

s'il trouve des objets sur des requêtes HTTP il inspectera l'objet et en extraira les headers, URL, status code, etc.
s'il trouve des connections JDBC, il extraira les resultsets, query,...on peut par exemple voir qu'il manque un clause where, ce qui fait que beaucoup trop d'objets sont rapatriés, et cause une trop grande consommation mémoire
s'il trouve des contexts OSGI, il explorera leurs contenus.

Voici deux exemples : le premier pour un thread exécutant une requête SQL :

le deuxième pour un thread exécutant une requête soap :

On peut légitimement se poser la question "comment sont déterminer ces informations ? " en fait si le suspect est un thread, il explore son nom (exemple "HTTP-processor" pour un thread Tomcat, "RMI TCP Connection(8)-127.0.0.1 pour un connecteur jmx, "Timer-3" pour un timerThread), il inspecte les variables threadLocal et selon ce qu'il y trouve nous donne des informations supplémentaires. Ce système d'exploration est basé sur un système de plugins, vous pouvez donc en créer vous même selon vos besoins

OQL ou Object Query Language

Pour permetre de rechercher des objets facilement, vous pouvez les rechercher avec une syntaxe SQL like. Exemple :

select e.nom from com.demo.mat.Entreprise e

Vous pouvez utiliser des clauses WHERE, des UNION, des projections (avg, min, max,...). vraiment très pratique pour trouver, compter, avoir des statistiques sur des objets en particulier. (en savoir plus)

Voilà pour la théorie :) j'espère que vous maitrisez les différents concepts de l'outil et que vous savez désormais aller chercher les informations pertinentes.

Le prochain post sera basé sur un cas concret et expliquera comment j'ai résolu une fuite mémoire sur Gisgraphy, en 15 minutes à l'aide de MAT.

Nouveau look aux idées larges !

Masclet — Sat, 27 Feb 2010 15:56:00 +0100

Le blog à désormais un nouveau look. oh... pas très très différent. Je suis juste partie du thème précédent et j'ai changé le style pour l'adapter aux styles des billets : c'est-à-dire des articles techniques.

En effet en regardant les statistiques des résolutions d'écran des utilisateurs, J'ai remarqué que personne n'était en 800*600, alors que le thème était optimisé pour une résolution 800*600. J'ai donc augmenté la largeur de la colonne centrale en diminuant les marges de chaque coté, attribué plus de place à la colonne de contenu, et diminué la colonne avec les rubriques, qui me semblait moins importantes que le contenu. A mon sens, le texte est beaucoup plus lisible. Pour les zone de code, j'ai également opté pour une couleur jaune, plus sympathique que le gris. Faites moi part de vos impressions, et des éventuels problèmes rencontrés.

Tester du code en ligne

Masclet — Thu, 04 Feb 2010 15:35:00 +0100

Certains connaissent peut être pastebin qui permet d'envoyer du code à quelqu'un (ou d'un PC à l'autre ;) ) en générant une shortURL. Il existe des sites qui vont plus loin en permettant de tester du code directement en ligne : http://codepad.org/. il suffit de copier / coller votre code, et le site vous le compile et vous l'interprète. c'est le cas de codepad

Il supporte les langages suivants :

C
C++
D
Haskell
Lua
OCaml
PHP
Perl
Plain Text
Python
Ruby
Scheme
Tcl

Vous pouvez mettre votre code "privé", ce qui est pratique, car j'ai déjà retrouvé du code, que je ne voulais pas partager publiquement, indexé par Google, après l'avoir envoyé via pastebin)

Dans la même lignée, il existe des sites plus spécialisés pour tester les interactions HTML<=>Javascript : http://jsbin.com/. Son utilisation est triviale : vous avez le code javascript à gauche et le code HTML à droite.

Le site va beaucoup plus loin que pastebin, d'une part, car il est spécialisé dans un langage, mais aussi parce qu' il offre la possibilité :

De sauvegarder votre code.
D'inclure des librairies connues, comme Prototype, Jquery, Mootools, Dojo et de choisir parmi différentes versions
De générer une short URL de votre code (exemple : http://jsbin.com/ilomu3)
De modifier un code existant en cliquant sur ''Edit using JS Bin" en haut à droite (j'avoue c'est pas flagrant :) ).
De gérer plusieurs versions d'un même code

L'avantage est qu'il permet de tester du code avant de mettre à jour un librairie (exemple : passer de Prototype 1.6.03 à 1.6.1.0), de vous faire la main sur des librairies, ou de partager du code entre collègues.

iPad nano

Masclet — Mon, 01 Feb 2010 11:25:00 +0100

Pour faire suite à mon post Stratégie d'Apple vs stratégie Google, je vous propose une image qui m'a fait bien rire

Sinon, je vous conseille la lecture de ce billet sur l'ipad et son effet d'annonce manqué

Tester le javascript : JSUnit, JSmock, Jstester (partie 2)

Masclet — Tue, 26 Jan 2010 13:16:00 +0100

Après le billet consacré à JsUnit et celui qui expliquait comment mocker une requête Ajax, nous allons maintenant voir comment mocker en javascript. Pour cela je vous propose une courte présentation de JsMock. Les exemples de code sont en annexe de ce billet.

Pour montrer les capacités de JsMock, rien de tel que des exemples de code. Nous allons donc reprendre le code du premier billet (vous pouvez télécharger les sources en annexe du premier billet)

Installation

La première chose à faire est de télécharger JsMock et de l'ajouter dans le répertoire JsUnit (ou ailleurs, mais le tout est d'être cohérent lors de la déclaration dans le fichier HTML) , puis de l'importer à partir de notre fichier de tests SimpleCodeTest :

<script language="JavaScript" type="text/javascript" src="../jsmock.js"></script>

Exemple de code à mocker

Pour comprendre les mocks il vaux mieux faire interagir deux objets entre eux : cela permet de tester un objet et d'en mocker un autre. Ajoutons donc un objet ConfigParameter et définissons en une instance dans MyObjectToTest :

function ConfigParameter() {
        this.getAlertMessage = function(){
                return "alertMessage";
        }

        this.setParam = function(Aname, Avalue) {
                //this[name]=value
        }
}

function MyObjectToTest(){
        this.configParameter = new ConfigParameter();

        var message = "Not defined yet!";
        
        this.setMessage = function(messageParam){
                message = messageParam
        }

        this.getMessage = function(){
                return message;
        }

        this.getAlertMessage = function(){
               return this.configParameter.getAlertMessage();
        }

        this.setConfigValue = function(){
                this.configParameter.setParam("MyName", "MyValue");
        }

}

Mocker des valeurs de retour

Voici un exemple où nous allons mocker le retour de getAlertMessage :

function testMockReturnedValue() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Mock
        mockControl = new MockControl();
        mockConfig = mockControl.createMock(ConfigParameter);
        mockConfig.expects().getAlertMessage().andReturn("mock Alert Message");

        MyObj.configParameter = mockConfig;

        // Assert
        assertEquals("mock Alert Message", MyObj.getAlertMessage());
        
        mockControl.verify();
}

Vous remarquerez qu'à la différence de EasyMock en Java, il n'est pas nécessaire d'appeler la méthode replay()

La méthode vérify permet de vérifier que les méthodes mockées sont bien appelées le bon nombre de fois : si une méthode non défini par votre mock est appelée le test ne passera pas, en revanche vous pourriez avoir défini le comportement d'une méthode mais que cette dernière ne soit jamais appelée, dans ce cas, si vous n'appelez pas la méthode verify, le test passera mais vous ne saurez pas que la méthode n'a pas été appelée).

mocker des fonctions

Il est possible de simuler les comportement (le corps de la méthode) d'une fonction grâce à la méthode andStub :

function testStubFunction() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Mock
        mockControl = new MockControl();
        mockConfig = mockControl.createMock(ConfigParameter);
        mockConfig.expects().getAlertMessage().andStub(
                 function() { 
                        return "test";
                 } 
        );

        MyObj.configParameter = mockConfig;

        // Assert
        assertEquals("test", MyObj.getAlertMessage());
}

Simuler des exceptions

Il est également possible de simuler des exceptions avec la méthode andThrow :

function testThrow() {
        exception = false ;
        // Actor
        MyObj = new MyObjectToTest();
        
        // Mock
        mockControl = new MockControl();
        mockConfig = mockControl.createMock(ConfigParameter);
        mockConfig.expects().getAlertMessage().andThrow("Error !");

        MyObj.configParameter = mockConfig;

        try {   
        MyObj.getAlertMessage();
        } catch (e){
          exception = true;
        }

        assertEquals(true, exception);
}

Mocker des fonctions avec paramètres

Pour mocker une fonction avec des paramètres, vous avez deux possibilités : soit vous spécifiez le type des paramètres lors de la définition du mock, dans le cas où seul le type des paramètres vous importe. Pour cela utiliser TypeOf.isA()

function testFunctionWithTypedParameters() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Mock
        mockControl = new MockControl();
        mockConfig = mockControl.createMock(ConfigParameter);
        mockConfig.expects().setParam(TypeOf.isA(String),TypeOf.isA(String));

        MyObj.configParameter = mockConfig;


        MyObj.setConfigValue();

        mockControl.verify();
}

soit vous spécifiez la valeur des paramètres, si vous voulez vérifier que la fonction est appelée avec les bonnes valeurs :

function testFunctionWithParameters() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Mock
        mockControl = new MockControl();
        
        mockConfig = mockControl.createMock(ConfigParameter);
        mockConfig.expects().setParam("MyName", "MyValue");

        MyObj.configParameter = mockConfig;
        MyObj.setConfigValue();

        mockControl.verify();
}

J'espère que cela vous à donner envie de l'utiliser, car le Javascript est de plus en plus présent dans les applications web et les tests permettent de mieux découpler votre code et de le rendre plus robuste.

La troisième et dernière partie traitera de JsTester qui permet de tester du javascript coté serveur (JsUnit dispose d'une partie serveur mais elle n'est là que pour piloter les tests, il faut toujours avoir un navigateur). nous verrons ses avantages et ses inconvénients et comment l'intégrer avec Maven et JUnit.

Configurer et utiliser Google bot comme outil de tests

Masclet — Mon, 18 Jan 2010 14:16:00 +0100

Lorsque l'on parle de Google bot, on pense souvent à "référencement", mais il existe une autre utilisation : les tests. Je ne parle pas de tests fonctionnels ou unitaires mais de tests pour améliorer la qualité de votre site, comme les tests de liens morts, de pages indisponibles, d'erreurs HTTP etc.

Il y a quelques semaines, je postais plusieurs billets sur comment gérer un serveur de download :

Mais cette configuration peut poser des problèmes pour les bots des moteurs de recherches. C'est pourquoi je voudrais expliquer comment mieux configurer les serveurs pour faciliter le travail des bots.

Utiliser les bots comme outils de tests

Le rôle premier d'un bot est bien sur d'indexer votre site, mais il en existe un autre qui consiste à l'utiliser pour tester et améliorer vos pages :

La procédure est la suivante :

Vous faites une sitemap avec toutes les pages de votre site. Ayant plusieurs millions de pages, j'ai préféré, pour ma part, faire un générateur de sitemaps personnel en Python. Il permet de générer plusieurs fichiers sitemaps (la taille et le nombre d'URLs par fichier étant limités) et un fichier sitemap d'index contenant toutes les URLs des fichiers sitemaps générés.
Puis vous soumettez à Google le fichier d'index.

Rien ne vous empêche de soumettre des pages dont vous voulez qu'elles génèrent une erreur. exemple : http://monsite.com/private/ qui est censé générer une erreur 403.

Vous pouvez ainsi voir des informations sur le passage de Google bot, comme le nombre de kilo-octets téléchargés, le temps de réponse moyen, et le nombre de pages explorées par jour, sur cette page et consulter les pages en erreurs (timeout, erreur HTTP, pages inaccessible, pages contenant des liens morts, etc), sur cette page. Merci Google :)

Autoriser les bots à indexer votre site

Lors de mon billet sur mod_evasive, j'évoquais le moyen de limiter un site à un nombre de requêtes défini. Il faut toutefois préciser que mod_evasive ne peut (à ma connaissance) pas ce configurer par vhost : c'est donc tous les vhosts de votre Apache qui seront limités. Si comme pour Gisgraphy, vous disposez d'un vhost pour le download et d'un autre pour le site web, et que vous limitez le nombre de requêtes du serveur de download, vous limitez le nombre de requêtes du site web également.

Si vous avez créé un fichier sitemap afin de mieux référencer votre site, se pose alors le problème des bots : si vous disposez de beaucoup d'URLs à indexer (9 millions pour Gisgraphy), lors du passage d'un bot, votre site peux détecter une attaque et renvoyer une erreur HTTP 403.

Plusieurs solutions sont possibles :

Modifier la vitesse d'exploration dans la configuration des outils pour webmasters, afin de limiter le nombre de pages indexées par jour.
Installer deux serveurs Apache : Si vous ne disposez que d'une seule machine, il vous faut mettre le serveur de download sur un port particulier, ou dans le cas contraire, avoir deux serveurs séparés.
Ajouter la liste des adresses IP des bots à la White liste de mod_evasive :

DOSWhiteList 127.0.0.1
DOSWhiteList 66.249.64.*
DOSWhiteList 66.249.65.*
DOSWhiteList 66.249.66.*
DOSWhiteList 66.249.71.*

La liste des IP ci dessus n'est donnée qu'a titre d'exemple, car la liste des IP des bots change tout le temps. Vous pouvez utiliser * pour remplacer jusqu'a 3 octets. (Sinon essayez avec un hostname comme 'googlebot.com', mais je n'ai pas testé)

Ajouter un robots.txt

Si vous avez limité le nombre de requêtes simultanées avec mod_bandwith, vous ne voulez peut être pas qu'un bot vous prenne un téléchargement au détriment d'un utilisateur ou que votre bande passante soit diminuée. Il vous faut alors ajouter un fichier robots.txt :

User-agent: *
Disallow: /

En faisant cela, vous ne permettez pas aux bots de télécharger les fichiers et de les indexer. Dans mon cas il s'agit de fichiers ZIP ou TAR et leurs indexations n'ont pas d'importance pour moi, mais il peut en être autrement pour d'autres types de fichiers, car Google n'indexe pas que du HTML, il indexe aussi, les PDF, document Word, Excel, texte, images, etc. Dans ce cas vous devez mettre des règles de gestion plus fines et ne permettre l'indexation, que de certains fichiers. Notez que dans l'exemple ci dessus, '*' est une valeur particulière et que ni Disallow ni User-agent ne supporte les expressions régulières. Pour vous aider, un outil est disponible dans les outils pour webmasters afin de générer un fichier robots.txt et un autre pour le tester

Voir ce que Google bot voit

Si vous avez des règles d'affichage de votre site un peu complexes, comme une différenciation de l'affichage selon le User-Agent, ou que vous géolocalisez d'après l'adresse IP, il peut être intéressant de savoir comment Google bot voit votre site. Il existe un outil qui se situe dans la console des outils pour webmasters. Il est actuellement sous la rubrique labs, car en test.

Je déconseille fortement d'utiliser cette outil pour faire un rendu particulier afin de tromper Google, car c'est le meilleur moyen de se faire exclure du moteur de recherche.

je conclurai par dire qu'utiliser Google bot pour tester votre site n'est pas illégal du tout, bien au contraire, les outils mis à votre disposition sont justement là pour vous aider à améliorer la qualité de votre site.

Tester le javascript : JSUnit, JSmock, Jstester (partie 1)

Masclet — Fri, 08 Jan 2010 10:59:00 +0100

Beaucoup de développeurs Java sont familiers avec Junit, EasyMock,... ces librairies qui permettent de tester du code Java afin de rendre les programmes plus robustes. Javascript dispose également de frameworks équivalents. Avec l'apparition du Web 2.0, le Javascript et l'Ajax sont de plus en plus présents dans nos applications (j'avais d'ailleurs poster un billet sur comment mocker une requête Ajax,il y a quelques mois) et représente une part non négligeable de code.

Si vous utilisez GWT, qui permet d'écrire à partir de code écrit en Java, de générer une application en HTML / javascript, vous n'avez pas de problème pour tester votre code, puisque Junit suffit. En revanche, si vous avez du code javascript à tester, il existe des librairies qui permettent de simplifier les tests. Je vous propose de voir comment tester du Javascript au moyen de ces 3 frameworks :

JsUnit : Qui fournit des mécanismes d'assertions et d'exécutions de tests.
JsMock : Permet de simuler des comportements pour des objets Javascript,tout comme EasyMock le fait
JsTester : Permet d'executer du code Javascript en java grâce à Rhino.

les exemples de code sont disponibles en annexe de ce billet

Commençons par JsUnit.

Installation

Vous pouvez le télécharger sur le site de JsUnit. Une fois télécharger décompresser le. JsUnit dispose d'une partie serveur que nous ne verrons pas ici (peut être dans un autre billet) et d'une partie cliente. Pour lancer la partie cliente, il faut ouvrir la page testRunner.html,qui se trouve à la racine du dossier que vous avez décompressé, dans un navigateur :

Cette page vous permet de lancer un fichier contenant des tests écrits en Javascript et de vous afficher le résultat de l'exécution.

Si vous ne désirez pas installer JsUnit vous pouvez exécuter le testRunner sur le site de jsUnit

Utilisation

Je vous propose de tester un code très simple avec un objet MyObjectToTest disposant d'une variable privée, d'un getter et d'un setter:

function MyObjectToTest(){
        var message = "Not defined yet!";
        
        this.setMessage = function(messageParam){
                message = messageParam
        }

        this.getMessage = function(){
                return message;
        }

}       
/*example of use
MyObj = new MyObjectToTest();
alert(MyObj.getMessage());//Not defined yet!
MyObj.setMessage("This is it");
alert(MyObj.getMessage() );//This is it
*/

Créons un répertoire "testMe" dans le dossier de JsUnit et sauvegardons le contenu dans un fichier "simpleCode.js"

Ecrivons ensuite un fichier "SimpleCodeTest.html", contenant plusieurs cas de tests

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>test de SimpleCode.html</title>

</head>

<body>
<script language="JavaScript" type="text/javascript" src="../app/jsUnitCore.js"></script>
<script language="JavaScript" type="text/javascript" src="./simpleCode.js"></script>
<script language="JavaScript" type="text/javascript">
function setUp(){
        //nothing to do
}
function tearDown(){
        //nothing special
}

function testMessageShouldBePrivate() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Action
        
        // Assert
        assertEquals("undefined", typeof MyObj.message);
        assertUndefined(MyObj.message);
}

function testMessageShouldHaveADefaultValue() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Action
        
        // Assert
        assertEquals("Not defined yet!", MyObj.getMessage());
}


function testGetAndSetMessageShouldGetAndSet() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Action
        MyObj.setMessage("This is it");                       

        // Assert
        assertEquals("This is it", MyObj.getMessage());
}

</script>
</body>
</html>

Comme vous pouvez le constater JsUnit dispose de plusieurs points communs avec JUnit :

Les tests doivent commencer par test, suivi d'une majuscule, afin que la méthode soit détectée.
Des mécanismes permettant de faire des assertions sont fournis.
Il y a la possibilité de définir des méthodes qui seront appelés avant ( setUp() ) et après chaque test ( tearDown() ). Noter que le nom et la casse ont une importance.

Des assertion spécifiques au Javascript sont également disponibles : assertUndefined, assertNotUndefined, assertNaN,...

Déroulons maintenant notre test :

Ouvrons la page testRunner.html dans un navigateur
Sélectionnons le fichier SimpleCodeTest.html
Cliquons sur "Run"

Vous verrez alors : Runs: 3 Errors: 0 Failures: 0 et la fameuse "barre verte" prouvant que votre code est conforme aux tests.

Voyons maintenant avec un test qui échoue. Ajoutons ce cas de test :

function testThatFail() {
        // Actor
        MyObj = new MyObjectToTest();
        
        // Action
        MyObj.setMessage("this is not it");                   

        // Assert
        assertEquals("This is it", MyObj.getMessage());
}

En re-exécutant les tests vous aurez : Runs: 4 Errors: 0 Failures: 1 , une "barre rouge", et "testThatFail" dans la liste des tests échoués. en cliquant dessus, vous aurez la stacktrace d'exécution.

Problèmes courants et solutions

Pour des raisons que j'ignore il peux arriver qu'en local, le fichier de test ne soit pas trouvé, il faut alors appeler l'URL de testRunner.html avec le paramètre testpage :

http://path/to/jsunit//testRunner.html?testpage=/path/to/jsunit/testMe/simpleCodeTest.html

Sur Firefox, si la version est supérieure ou égale à 3.0 des soucis dus à la politique de sécurité peuvent subvenir. il faut alors taper about:config dans la barre d'adresse et mettre la valeur de security.fileuri.strict_origin_policy a false en cliquant dessus. Redémarrer FireFox, et recommencer le test.

Utilisation avancée

Vous pouvez définir un suite de tests (aka : testSuite) grâce aux méthodes addTestPage(filename) et addTestSuite(aTestSuite)

Des fonction de logging sont fournies :


function warn(message, [value])
function inform(message, [value]) (equivalent to function info(message, [value]))
function debug(message, [value])

Vous pouvez définir des timeouts d'exécution des tests sur la page du testRunner.html

Vous pouvez définir vos propres paramètres pour l'exécution de vos tests (e.g : myTests.html?mode=0, ou myTests.html?mode=1.). Plus d'infos

Si vous voulez exécuter vos tests à partir d'un outil d'intégration continue ou avec des outils comme maven, ant, ou buildr, une version serveur est fournies (personnellement, je la trouve lourde d'utilisation)

Lors du prochain post, nous verrons comment mocker les objets javascript et simuler le DOM HTML

Google goggle

Masclet — Mon, 04 Jan 2010 15:23:00 +0100

Il y a de cela quelques temps, Google lançait image labeler afin d'améliorer la recherche d'images Google. Tout laisse à penser que ce service a bien fonctionné, car Google expérimente Google goggle, un service disponible à partir d'android 1.6+, et qui permet de prendre une photo ou une vidéo et Google détectera de quoi il s'agit et lancer une recherche à partir de ce qu'il a détecté. Le geotagging devient quasi obsolète.

Le nom n'est pas choisi au hasard, au départ Google aurait du s'appeler Goggle, en référence au nombre gogol de Edward Kasner, mais une erreur de saisie a fait que Google s'appelle Google et non Goggle. c'est donc un moyen d'utiliser son nom initial.

Si vous ne voyez pas trop ce qu'est Goggle, voici un exemple d'utilisation :

Vous photographié la tour Eiffel avec votre Google phone et il détecte automatiquement la tour Eiffel, et vous lance une recherche sur le mot 'tour Eiffel', vous pouvez donc avoir l'année de construction, les horaires d'ouvertures, et bien d'autres choses.

Vous pouvez photographier des millions de choses en photos et en vidéos, et Google vous détectera de quoi il s'agit et vous lancera une recherche sur ce que vous photographiez

La couverture d'un livre, pour en connaitre l'auteur
Des cartes de visites.
Des œuvres d'art, comme des tableaux ou des statues.
Des cafés.
Des couvertures de livres.
Des étiquettes de bouteilles de vins.
Des logos de marques.
Les codes barres

Pour certaines informations, Google se base sur les coordonnées GPS, mais pas pour toutes (étiquettes de vins).

Je ne sais pas si cela fonctionne avec les visages mais je ne pense pas que Google s'aventurerait sur ce terrain, même s'il est actuellement possible de rechercher des visages en spécifiant imgtype=face dans la recherche avancée d'image (exemple)

Google se lance aussi dans la réalité augmentée. Pour ceux qui ne savent pas de quoi il s'agit, la réalité augmentée permet de filmer quelque chose et de voir ce que l'on film avec un modèle 3D en surimpression. Cette vidéo vous donnera un aperçu avec le livre dokéo. Imaginez aussi les dérives : vous pouvez déplacer votre téléphone dans la rue, filmer des maisons et avoir le nom des personnes ou le numéros de téléphones en couplant votre recherche aux Pages jaunes / Pages blanches. Dérives...? euh...

Stratégie d'Apple vs stratégie Google

Masclet — Mon, 04 Jan 2010 14:44:00 +0100

Après la folie commerciale de fin d'année je voudrais bloguer sur les différentes stratégies des sociétés dites "innovantes". je sais dors et déjà que je vais me faire des ennemis et que cette article ne fera pas l'unanimité, mais peu importe, ce post trouvera aussi des personnes allant dans le même sens que moi :)

C'est demain que sort le téléphone de Google : le Nexus One. Ceux qui me connaissent savent que je suis un fervent défenseur de Google. Ce n'est pas que j'aime tout ce qu'ils font (je n'aime pas chrome, par exemple), mais je trouve que leurs produits tapent souvent juste et fort. Et si certains sont frileux d'utiliser des applications et services d'une firme, il est vrai, un peu "big brother", on saluera tout de même leur stratégie qui leur a permis d'être le moteur de recherche utilisé par 90% des internautes et de sortir des produits innovant comme, Google Maps et Google documents, GWT, etc.

Je m'étonne encore de leur modèle économique basé sur la publicité. Pour mémoire, ce même modèle a causé, entre autre, la chute de la bulle internet. De très grosses sociétés (e.g : AOL) ont revu leur business modèle, en passant la publicité de "source de revenus" à "complément d'activité" ;). La stratégie de Google est de sortir des produits les plus complets possible, en sachant très bien ce qu'il amélioreront à la prochaine version, mais en visant un niveau de base déjà très élevé pour un effet "WHAOOOUU". Je voudrais (entre autre) comparer la différence de stratégie d'Apple et de Google pour leur téléphone pour montrer comment Apple est vraiment une société reine dans le marketing :

Je trouve qu'Apple est une société innovante avec des dirigeants visionnaires, et l'informatique n'aurait pas le visage qu'il a en 2010, sans Steve Jobs, mais l'engouement pour l'iphone, montre que Apple (peut être encore plus que Google) maitrise parfaitement ses produits et dispose d'une stratégie parfaite : il sorte un produit révolutionnaire (l'iphone), et tout le monde s'extasie, à juste titre, devant un téléphone portable permettant enfin de surfer sur internet correctement.

Apple sont vraiment très fort, car malgré certaines limitations, ils ont su être premier sur le marché des smart phone, comme sur celui des lecteur MP3. Souvent copié, jamais égalé, l'iphone reste le seul à pouvoir offrir un surf sur téléphone mobile digne de ce nom. Personne n'y était arrivé ! Chapeau bas ! on ne voit dans l'Iphone que ce qu'il apporte et pas ces limitations. pareil pour l'Ipod (pour rappel, l'Ipod, à ses début, ne pouvez même pas lire les MP3)

il est fort a parier que pour iSlate (tablette tactile d'Apple), la guerre sera rude entre Google et Apple. Sauf que cette fois ci Google ne se laissera pas distancer, et à déjà pris les devant

Mais derrière l'engouement pour l'Iphone, on découvre aussi des limitations surprenantes, et là s'en suivent tout un tas de versions successives, comblant au goute à goute, les lacunes. A chaque fois l'iphone se vend de plus belle car les limitations des anciennes versions nous paraissent alors tellement limitantes, qu'il est necessaire de changer. Coluche disait : "Quand on pense qu’il suffirait que les gens n’achètent plus pour que ça ne se vende pas !". D'autres sociétés ou milieux fonctionnent aussi comme cela :

Le CD : Philips connaissait déjà le DVD, à la sortie du CD.

La Wii : Nintendo sort au compte goutes les accessoires, redonnant à chaque fois un regain d'enthousiasme pour la console (La balance board, le Wii motion plus)

La littérature : on sort le premier livre sur Harry Potter, puis le deuxième, puis le double coffret, puis le troisième tome, puis le coffret avec les 3 volumes, et ainsi de suite...jusqu'au septième volume. (à mon sens, acheter livre par livre a du sens, mais un coffret de deux livres sur une série de 7 a très peu d'intérêt, autant acheter les deux livres séparés : Un coffret sous entend une boite et un packaging qui deviendra obsolète à la sortie du prochain livre), ensuite viendront les coffrets complets, puis les collectors, les coffret anniversaire, puis les versions de poches (le Da Vinci Code n'est sorti que très tardivement en version de poche, et beaucoup l'ont acheté en double pour pouvoir l'emporter plus facilement). et au final ce sont toujours les même mots et la même histoire !

Il en va de même pour la musique : on ne compte plus les versions re-masterisés des chansons de Bob Marley, d'Elvis Presley, ou des Beatles qui n'apporte souvent qu'un autre support ou une pochette différente. Est il normal de repayer pour les droits d'auteurs lorsque nous achetons une œuvre artistique sur un support différent ? pourquoi ne pas payer que le support ?

L'Iphone de déroge pas à la règle : peu de choses changent à chaque nouvelles versions, choses qui nous paraissent alors indispensables d'avoir ?

L'Iphone est très fermé, et peut, par certain aspects faire penser à la position dominante de Microsoft, tant décriée. L'Iphone souffre de lacunes non négligeables :

L'iPhone ne sait lire que du MPEG4 / H264, ce qui force à ré-encoder les vidéos qui ne sont pas dans ce format.
Pour mettre des fichiers sur l'iphone il faut passer par de la synchronisation de fichiers, vous ne pouvez supprimer de l'iphone sans le supprimer du PC, et resynchroniser.
Le glisser déposer n'est pas possible
Le SDK n'est disponible que sous Mac! certains diront logiquel'iphone est basé sur un Mac OS, certes mais je pense qu'il est tout à fait possible techniquement de faire un SDK qui tourne sur linux, surtout que Mac OS est lui même basé sur linux.

La charte est très contraignante :

you may not modify, publish, transmit, participate in the transfer or sale of, reproduce, create derivative works based on, redistribute, perform, display, or in any way exploit any of the Site, Content or Services in whole or in part

you agree not to disclose, publish, or disseminate any Apple Confidential Information to anyone other than to other Registered iPhone Developers

Ceci explique pourquoi les tutoriauxet how to sont si peu nombreux.

Seul Safari est possible comme navigateur (certain s'offusque qu'Internet Explorer soit installé par défaut sur Windows, mais on peut au moins en installer d'autres)

L'iphone 3G, n'avait même pas de base la fonction MMS (un comble pour un téléphone),De base, pas de possibilité de transférer des SMS, d'avoir des modèles de SMS, pas d'accusé de reception, il a fallu attendre le 3GS

Pas de visio possible, le 3G est bridé en appareil photo, le 3GS dispose d'une caméra, mais sur la face opposée à l'écran.

Pas de flash sur l'appareil photo.

Pas de batterie interchangeable.

Pas de possibilité d'ajouter une carte mémoire : ce qui oblige à acheter un modèle disposant de beaucoup de mémoire.

Passage obligé par Itunes si on a pas "jailbreaké" son Iphone.

Cela confirme que les fonctions liées à la téléphonie n'ont pas été peaufinée mais que l'accent à été mis sur les fonctionnalités annexes

Je comprends tout à fait qu'une première version n'est pas une version finale et définitive (heureusement), mais les choix (cela n'engage que moi) d'Apple révèlent plus un choix stratégique plutôt qu'une limitation technique. Pour s'en convaincre, il suffit de comparer les fonctionnalités des téléphones au moment de la sortie de l'Iphone pour voir que qu'Apple s'est gardé un bonne marge de manœuvre. Beaucoup de choses auraient pu être mis dans l'Iphone 1ere version. En fait l'iphone est un mini ordinateur qui permet de téléphoner.

Je pense que les constructeurs ne s'y trompe pas et 90 % d'entre eux ont déjà adopté le SDK (Android) du Google phone qui est en java et non en Objective C. Steve Jobs a déclaré : "Nobody uses Java anymore". Pour rappel, Java est installé sur plus de 90% des ordinateurs personnels, est disponible sur quasi tous les téléphones portables un peu évolués, et fait partie du standard Blu-Ray (supporté par Apple). j'ai hâte de voir la prochaine version de l'Iphone et voir comment Apple va se positionner par rapport au Nexus One de Google : vont-il faire un pas de géant dans les fonctionnalités, ou alors sortir quelque chose d'innovant qui va encore une fois scotcher la planète. Affaire à suivre.

En tout cas ces stratégies stimulent la concurrence, et c'est souvent bon pour le consommateur :)

Différence entre un hard link et un lien symbolique

Masclet — Wed, 23 Dec 2009 11:39:00 +0100

Lorsque j'ai voulu faire un système de sauvegarde pour les données de mon serveur, j'ai voulu créer un dossier par date, mais je me suis vite rendu compte que cela allait prendre beaucoup de place. alors j'ai utilisé un hard link pour faire une sauvegarde incrémentale.

Hard link

Un hard link permet de faire un lien vers un autre répertoire mais dès que le contenu du lien change, un nouvel inode est crée.

Cela me permet d'avoir un dossier de sauvegarde où, lorsque je navigue à l'intérieur, j'ai tous les fichiers, mais au niveau du disque dur chaque dossier de sauvegarde d'une date d pointe vers le dossier de sauvegarde d-1. Seules les modifications de la date d sont stockées et prennent de la place sur le disque. Exemple :

Considérons un dossier le sauvegarde ci dessous :

=>Dossier 01_01
     =>Dossier D1
          Fichier F1
          Fichier F2

Lors de la sauvegarde du 02/01, je crée un hard link avec la commande cp et l'option -l plutôt que ln car ln ne peux être fait que sur un fichier pas sur un répertoire : cp -ral 01_01 02_01 :

=>Dossier 02_01
     =>Dossier D1
          Fichier F1
          Fichier F2

Les fichiers et 02_01 partagent les mêmes inodes que ceux de 01_01 :

ls -i 01_01/D1
     232177 F1
     232178 F2
ls -i 01_02/D1
     232177 F1
     232178 F2

A ce stade, la place sur mon disque dur reste inchangée. Maintenant supposons que le fichier F2 soit différent entre le 02/01 et le 01/01, dans ce cas le fait d'écraser le fichier F2 dans le dossier 02_01 va me créer physiquement un nouveau fichier (un nouvel inode). Seul le fichier F2 de 02_01 sera modifié et aura son propre inode, les autres fichiers pointent vers ceux du dossier 01_01 puisqu'ils sont inchangés. Par contre si D1 contenait des sous dossiers, deux dossiers seraient physiquement crées un dans 01_01 et un autre dans 02_01 car les hards links de répertoires ne sont pas possibles, en revanche les fichiers contenus dans les sous dossiers partageraient par défaut les mêmes inodes.

ls -i 01_01/D1
     232177 F1
     232178 F2
ls -i 01_02/D1
     232177 F1
     232179 F2

Il n'y aura pas de nouvel inode de crée si le fichier est renommé.

Pour utiliser des hard links avec rsync, j'ai donc utiliser la commande suivante :

date=`date "+%Y-%m-%dT%H:%M:%S"`
rsync -aP --delete --link-dest=$HOME/Backups/current /path/to/important_files $HOME/Backups/back-$date
rm -f $HOME/Backups/current
ln -s back-$date $HOME/Backups/current

En savoir plus sur comment réaliser des sauvegardes avec hard links et Rsync | An other link

Lien symbolique

Un lien symbolique ne prend pas plus de place qu'un hard link, mais la différence et que toutes modifications apportées à la cible d'un lien se répercute sur la source du lien, et inversement. Si j'utilise un lien symbolique plutôt qu'un hard link, mes sauvegardes des dates d seraient égales aux sauvegardes des dates d-1 et je n'aurais donc, qu'une sauvegarde, et non une sauvegarde par date.

On crée un lien symbolique avec la commande ln en passant le paramètre -s : ln -s source dest.

La limitation des liens est qu'ils doivent se faire sur une même partition pour partager les mêmes inodes.

En savoir plus sur la commande ln.

Mais qui a comité ça ?!

Masclet — Tue, 22 Dec 2009 10:12:00 +0100

Lorsque vous développez, Vous pouvez avoir envie de savoir qui a comité un bout de code, pas forcément parce qu'il vous parait mauvais (soyons constructif !), mais peut être pour comprendre certains choix, parce que vous trouvez le code particulièrement beau, ou simplement par curiosité. La plupart des outils de gestion de versions fournissent des moyens de le faire grâce à la commande blame. Même si la commande peut porter à confusion, ce post, n'est pas à placer dans la rubrique "délation" mais plutôt "travail en équipe" : )

Avec SVN; il vous suffit de faire un svn blame suivi du nom du fichier. Peut être par déontologie, plusieurs alias sont disponibles : praise, annotate, ann. Une mauvaise approche consiste à faire un svn log parce qu'avec cette commande, la granularité est le fichier, vous devez donc parcourir les logs et faire des diff afin de trouver qui a modifié le bout de code qui vous intéresse.

Vous pouvez consulter la doc de SVN blame pour plus d'informations.

Avec GIT, la même commande git blame permet de faire la même chose que SVN blame (git annotate aussi, bien que présente pour assurer la compatibilité) mais GIT fournit beaucoup plus d'options :

La possibilité de spécifier les lignes de début et de fin pour lesquelles vous voulez voir les annotations.
De voir les modifications de façon incrémentale.
De savoir les lignes copiées à partir d'autres fichiers dans le même comit (utile dans le cas de refactoring)
De connaitre les lignes déplacées
...

Vous pouvez consulter la doc de GIT blame pour plus d'informations

La plupart des IDE permettent également de le faire. Dans le cas d'Eclipse : Clic droit=>Team=>Show annotations.

Améliorer les performances de like et recherche partielle de mots dans Postgres

Masclet — Mon, 21 Dec 2009 10:23:00 +0100

Lorsque j'ai voulu faire un système d'auto-complétion pour un champs de recherche sur une page web, j'ai pensé à utiliser un moteur de recherche fulltext, malheureusement, les recherches fulltext ne se font que sur des mots entiers. j'ai donc pensé à utiliser la fonction like de Postgres. Malheureusement, like n'utilisent les indexes, seulement si '%' est placé en fin de chaine, et cela ne correspondait pas à mon besoin. De plus il fallait absolument que les requêtes soit rapides, pour que l'auto-complétion soit utilisable. Après avoir écumé le web à la recherche d'une solution, et n'ayant rien trouvé de concluant, j'ai décidé de faire un peu de R & D et d'implémenter une solution maison qui utilise les indexes. L'astuce réside dans l'utilisation d'un algorithme Edge n-gram et d'une recherche fulltext qui, elle, utilise les indexes. Voici la solution pour utiliser les indexes dans les différents cas suivants :

tous les mots commençant par
tous les mots finissant par
tous les mots contenant

tous les mots commençant par

Pour commencer, j'ai crée un table de données city avec un champs name et je l'ai rempli avec 500 000 entrées. j'ai ensuite fait une recherche :

select name from city where name like 'par%';

La requête prend plusieurs secondes, et un explain m'indique un parcours séquentiel. Logique! me direz vous il n'y a pas d'indexes. Je crée donc un index et j'utilise la fonction lower() pour rendre mes requêtes insensibles à la casse:

CREATE INDEX city_name_idx ON city(lower("name"));

L'explain sur la requête select, me montre que l'index est bien utilisé.

tous les mots finissant par

essayons de trouver tout les mot finissant par 'par' :

select name from city where name like '%par';

L'index n'est pas utilisé. Afin qu'il le soit, une astuce consiste à inverser la chaine afin de pouvoir utiliser le '%' à la fin du mot recherché plutôt qu'au début. Voici une fonction plpgsql qui le fait :

CREATE OR REPLACE FUNCTION "public"."inverserchaine" (chaine text) RETURNS text AS
$body$
DECLARE
 i integer;
 resultat text = '';
BEGIN
 FOR i IN REVERSE length(chaine)..1 LOOP
  resultat:=resultat||substring(chaine from i for 1);
 END LOOP;
 return resultat;
END;
$body$
LANGUAGE 'plpgsql'  RETURNS NULL ON NULL INPUT SECURITY INVOKER IMMUTABLE;

créez ensuite un index :

CREATE INDEX cityreversename_idx ON city(inverserchaine("name") text_pattern_ops);

Il faudra que vos requêtes reflètent également cette inversion :

select name from city where name like inverserchaine('par')||'%'

L'opérateur || permet de concaténer le signe '%' à la chaine inversée. Le signe '%' est bien placé à la fin et donc l'index est utilisé, dixit explain. j'ai trouvé cette astuce sur cette page

tous les mots contenant

Maintenant attaquons nous aux choses sérieuses avec tous les mots contenant 'mot'. et la je n'ai rien trouvé de concluant sur le web.

select name from city where name like '%mot%';

Comme attendu, l'index n'est pas utilisé et la recherche prend plusieurs secondes. Mon astuce pour améliorer les performances, consiste à découper le texte en sous chaines représentant toutes les sous chaines le composant. Pour cela j'utilise un algorithme Edge n-grams que j'applique plusieurs fois. Un algorithme Edge n-grams, décompose un mot à partir du début, exemple pour 'paris' : "p" "pa" "par" "pari" "paris". J'applique donc cet algorithme plusieurs fois sur le mot, en enlevant, à chaque fois la première lettre. Pour 'Paris' j'applique l'algorithme sur Paris, aris, ris, is. j'obtiens ainsi, toutes les sous chaines de Paris

P, Pa, Par, Pari, Paris, ar, ari, aris, ri, ris, is

Ces sous chaînes correspondent à toutes les sous chaines que l'utilisateur pourra taper et pour lesquelles 'Paris' sera un résultat valide.

Il me suffit ensuite de mettre ces sous chaines dans un champs fulltext que je nomme 'name_splited' et qui est de type 'tsvector' (le type fulltext de Postgres) et de créer un index sur ce champs. Si je recherche 'ari', la recherche fulltext me renverra le bon résultat car 'ari fait partie des sous chaines découpées et indéxées'.

ALTER TABLE city ADD COLUMN name_splited tsvector;
CREATE INDEX citytextsearchvectorindex ON city USING gin(name_splited);

J'ai implémenté cet algorithme dans une fonction Java, mais elle pourrait être écrite en plpgsql. Faire la fonction plpgsql me permettrait de mettre un trigger. (si quelqu'un en a l'envie ou le besoin, il peut la poster, ou je le ferai peut être lors d'un prochain post).

public static final String getSubStrings(String originalString, char delimiter) {
        if (originalString == null) {
                return null;
        }
        //use hashset to remove duplicate
        String substring = null;
        StringBuffer sb = new StringBuffer();
        Set<String> set = new HashSet<String>();
        originalString = transformStringForFulltextIndexation(originalString);
        for (int i = 0; i < originalString.length(); i++) {
                for (int j = i + 1; j <= originalString.length(); j++) {
                        substring = originalString.substring(i, j);
                        if (!substring.endsWith(" ")) {//we have alredy add the entry the last loop
                                if (substring.startsWith(" ")) {//need to trim?
                                        substring = substring.substring(1);
                                }
                                if (substring.length() > 1) {//only index string that have length >=2
                                        set.add(substring.replace(" ", String.valueOf(delimiter)));
                                }
                        }
                }
        }
                for (String part : set) {
                sb.append(part).append(" ");
        }
        return sb.toString();
}

Comme vous pouvez le voir, je remplace les espaces par un autre caractère (delimiter), qui dans mon cas est '-'. Ceci s'explique par le fait qu'un champs ts_vector, découpe les textes en mots et indique leurs positions. Exemle pour "Saint jean"

select to_tsvector('saint jean')
"'jean':2 'saint':1"

Donc, si mon champs name contient des espaces, mes sous chaines vont contenir des espaces aussi. Par exemple 'aint je', comme sous chaine de 'saint jean'. C'est pourquoi je remplace les espaces par un autre caractère : la chaine 'aint je' deviendra 'aint-je' et sera indexée comme telle. Dans le cas contraire 'aint' et 'je' seront découpées en deux mots, alors que je veux indexer la chaine entière. Il me faut donc faire de même lors de la requête : si quelqu'un cherche "aint je" , il faut chercher "aint-je", j'aurais ainsi un format pivot, et la recherche fulltext matchera!

Il faut donc que je sauvegarde dans name_splited, le résultat de la fonction getSubStrings(), et mettre le résultat en lower case si je veux être insensible à la casse. Une requêtes pour l'auto complétion de "aint je" ressemblera à:

select name from city where this_.name_splited @@ to_tsquery('simple',lower('aint-j'))

@ @ correspond à l'opérateur fulltext de PostgreSQL, et la fonction lower() permet de rendre l'auto-complétion insensible à la casse. La requête sur 500 000 tuples met désormais 13 ms, utilise les indexes,et le résultat "saint Jean" fait partie des résultats. C'est gagné

Si vous voulez que votre recherche soit insensible aux accents et caractères spéciaux(comme c'est souvent le cas, pour que l'auto-complétion soit pertinente), je vous propose une fonctions Postgres que vous utiliserez aux mêmes endroits que vous utilisez la fonction lower :

CREATE OR REPLACE FUNCTION to_flat_text(text) RETURNS text AS
$body$
DECLARE
 chaine text;
BEGIN
chaine:=trim(lower($1));
 chaine:=replace(chaine,'-',' ');
 chaine:=translate(chaine,'âãäåāăąàèéêëēĕėęěìíîïìĩīĭóôõöōŏőðøùúûüũūŭůçñÿž',  'aaaaaaaaeeeeeeeeeiiiiiiiiooooooooouuuuuuuucnyz');
 chaine:=replace(chaine,'.',' ');
 chaine:=replace(chaine,'"',' ');
 chaine:=replace(chaine,';',' ');
 RETURN chaine;
END;
$body$
LANGUAGE 'plpgsql' RETURNS NULL ON NULL INPUT ;

A vous de l'adapter selon vos besoins.

La solution peut vous paraître alambiquée mais marche vraiment très bien. Je lai testée avec 28 millions de tuples, et l'auto-complétion est vraiment fluide. Si quelqu'un a une autres solution (Postgres only), je suis preneur :)

Différence entre Bohr bug, Schrödinbug, Heisenbug, Mandelbug

Masclet — Fri, 18 Dec 2009 12:33:00 +0100

Pendant plusieurs années, j'ai travaillé dans une équipe QA (Quality Assurance), où mon rôle était de trouver les causes et de corriger les bugs que d'autres équipes avaient faits: il y avait les développeurs qui implémentaient les fonctionnalités, les testeurs / bêta-testeurs, et mon équipe qui prenait en charge les bugs un peu retords. J'avoue avoir eu des fois beaucoup de mal à reproduire certains bugs.

J'ai appris par expérience que certains bugs pouvaient apparaitre seulement dans des cas de tests et ne se seraient jamais reproduits dans une utilisation normale, d'autres n'apparaissent plus lorsqu'on tente de les observer. C'est là, la différence entre les Bohr bugs, Schrödinbugs, Heisenbugs, et Mandelbugs. Toutes ses catégories de bugs tirent leurs noms de physiciens. Voici les différences fondamentales :

Un Heisenbug, dont le nom est tiré de Werner_Heisenberg, est un bug dont les caractéristiques sont altérées lorsqu'on l'observe. L'affichage d'un log, l'ajout d'une sonde, le fait de faire tourner un débuggeur ou une console jmx, peut modifier le comportement de l'application qui fait que le bug ne se produit plus. La physique quantique suit également cette règle comme la célèbre expérience des fentes doubles d'Young

Un bohr bug, tire son nom de Niels_Bohr, et n'a en rien ses caractéristiques modifiées lorsqu'on l'observe, à la différence d'un heisenbug. C'est un bug dit 'classique'.

Un Schrödinbug, lui tire son nom de Erwin Schrödinger .C'est un bug qui n'apparait qu'après une utilisation inhabituelle du logiciel et qui ne serait pas apparu dans une utilisation classique par les utilisateurs. Ce bug est souvent déstabilisant car il apparait sans qu'aucune modification de code ne soit faite. C'est le bug, bien connu, du "oui mais ça marchait avant" :). C'est le cas, par exemple, lorsqu'un test, ou l'utilisation d'un trick mode met le logiciel dans un état instable. A l'inverse après un test, il peut arriver qu'un bug disparaisse, et là c'est le bug, "si je te jure quand je l'ai fais, ça marchait pas". Les Schrödinbugs, vous poussent à croire un peu plus les gens, et à ne pas les considérer comme des mythomanes :)

Un Mandelbug, en hommage à Benoit Mandelbrot, est par nature, le bug le plus difficile à reproduire car les étapes pour le reproduire sont tellement complexes qu'il semble se reproduire de façon aléatoire et chaotiques. Souvent le bug est reproductible, mais les étapes imposent des conditions qui ne sont pas toujours identifiées ou sur lesquelles nous n'avons pas la main. Les bugs concernant les threads, ou les bugs apparaissant selon une certaine charge du système sont souvent des mandelbugs. Ce bug engendre souvent des "can not reproduce".

Un bug peut être de plusieurs types à la fois, et si vous tombez sur un mandelbug-heisenbug, je vous souhaite bon courage :)

Il est amusant de constater que tous ces types de bugs tirent leur nom de scientifiques. Comme quoi la correction de bugs est vraiment une science !

Encoding et alphabets internationaux : comprendre et debugger (2e partie)

Masclet — Wed, 16 Dec 2009 17:42:00 +0100

Après le premier post où j'expliquais ce qu'était l'encoding, je vais, cette fois, aborder comment gérer l'encoding en Java. mon but étant de faire un article qui se veut complet, quitte à être un peu long. Je donnerai, à chaque fois des exemples de code pour illustrer. Sommaire :

Comment gérer et débugger les problèmes d'encoding en Java
La représentation interne des Strings en Java
Encoding du fichier source
Manipulation de Strings
Ecriture dans un fichier
Connaitre et modifier l'encoding de votre JVM
Comprendre ce qu'est input method et inputContext
Affichage dans un logiciel (navigateur,éditeur,...)
Comment gérer l'encoding dans un environnement Web (Apache, Tomcat, ModJK, framework MVC, base de données, navigateurs).

tous les exemples de code sont réunis dans une classe que j'ai appelé 'EncodingProblemsRepairKit', disponible en annexe à la fin du post. Le code n'est pas blindé (pas de tests, pas de vérification des paramètres d'entrée,etc) et n'est donné qu'a titre d'illustration et fournit quelques méthodes pour débugger plus facilement

Comment gérer et débugger les problèmes d'encoding en Java

Lorsque vous avez un problème d'encoding en Java, il vous faut trouver le ou les maillons qui 'cassent' l'encoding. Est-ce :

La lecture de la source d'entrée : la soumission d'un formulaire web, la saisie en ligne de commande, la lecture d'un fichier,...
L'écriture des données sur la sortie : l'affichage sur une page web, l'écriture dans un fichier, la sortie sur la console,...
Le logiciel que l'on utilise qui affiche mal le résultat : votre navigateur internet peut ne pas arriver à détecter l'encoding automatiquement, ou cette option est peut être désactivée, vos préférences définissent un encoding UTF-8 alors que le contenu est en ISO-8859-1,...

Cela ne veux pas dire que vous devez garder le même encoding, de bout en bout, pour les différentes étapes, mais que la lecture ou l'écriture des informations doivent être cohérentes : Vous ne pouvez lire des données en UTF-8 si ces dernières sont en ISO-8859-1, et vice versa. Cela parait évident, mais représente la majorité des problèmes d'encoding.

Plusieurs règles doivent être respectées lors de votre debug :

Les problèmes d'encoding sont dépendants de l'environnement (JVM, Système d'exploitation, locale système, LC_TYPE, etc), il ne faut pas crier victoire trop vite : un problème d'encoding résolu est un problème où la solution ne laisse pas de place au hasard ! et où des tests unitaires couvrent les différents environnements possibles !
Travaillez en hexadécimal, vous permet de comprendre la représentation 'brute'. Des méthodes utilitaires sont disponibles dans la classe EncodingProblemsRepairKit disponible en fichier joint à ce post
N'utilisez pas les méthodes qui utilisent l'encoding par défaut, cela rend votre code fragile à l'environnement d'exécution (nous allons y revenir en détails)

Pour comprendre comment débugger ces problèmes, il faut comprendre la différence entre travailler avec des octets (aka : byte / Byte) ou travailler avec des caractères Unicode représentés par la classe Character ou le type natif char. On peut par exemple connaitre le sens d'écriture d'un char (de droite à gauche ou de gauche à droite) en appelant getDirectionality(). Ce qui n'est évidemment pas possible avec un byte :)

En java, les Reader / Writer travaillent avec des caractères Unicode, alors que des InputStream / OutputStream travaillent avec des octets. Il est par exemple absurde de lire un fichier contenant une image avec un Reader, puisque son contenu est binaire. En revanche utiliser un InputStream a du sens. Un Inputstream va lire octet par octet sans ce soucier de l'encoding, tandis qu'un Reader va lire, caractère par caractère selon un algorithme défini par l'encoding. C'est pourquoi il n'est pas possible de spécifier l'encoding lors de la lecture dans un InputStream, alors que pour un Reader, on en a besoin pour connaitre la façon de lire les caractères :

Dans le code ci dessus, je crée un buffer où les octets vont être lus, un à un, donc, peu importe l'encoding.

InputStream stream = new FileInputStream(file);

Voici maintenant un bout de code où Je lis, caractère par caractère, dans le flux d'octets, en considérant que les caractères Unicode sont encodés en UTF-8 et je les place dans un tableau de char

InputStream stream = new FileInputStream(file);
Reader reader = new InputStreamReader(stream, "UTF-8");
char[] OneChar = new char[1];
reader.read(OneChar);

L'erreur classique, qui engendre des problèmes est de ne pas spécifier l'encoding, en effet :

 reader = new InputStreamReader(stream);

est tout à fait valide, et comme le stipule la javadoc, c'est l'encoding par défaut qui sera utilisé, c'est à dire celui de la JVM (voir plus bas, comment connaitre et modifier l'encoding de la JVM)

Il existe la même différence entre un Writer et un Outputstream :

OutputStream stream = new FileOutputStream(file);

Pour un writer :

OutputStream stream = new FileOutPutStream(file);
Writer writer = new OutputStreamWriter(stream, "UTF-8");
writer.write(CharArray);

Là aussi il faut TOUJOURS spécifier l'encoding même si le constructeur OutputStreamWriter(OutputStream out) existe, ne l'utilisez pas! Cela vous évitera des problèmes du style : sur ma machine, l'encoding est correct, mais en production, l'encoding comporte des caractères bizarres. C'est pour cela que je disais que l'encoding dépendait de la plateforme.

La représentation interne des Strings en Java

Les strings déclarées dans les fichiers sources Java sont compilées et encodées en UTF-8 (UTF-8 modifié, si on veux être rigoureux), et ce peu importe l'encodage du fichier source !. C'est très facilement vérifiable : créons une classe contenant la String suivante :

String maString ="ééééé";

Puis ouvrons le .class compilé, avec un éditeur hexadécimal : on verra (entre bien d'autres informations) 5 fois C3 A9. ce qui correspond à 5 'é' encodés en UTF-8. Recommençons l'opération en changeant l'encoding du fichier source : cela ne change rien, et nous aurions pu la déclarer en Unicode, cela aurait donné la même chose :

public static String maStringEnUnicode="\u00E9\u00E9\u00E9\u00E9\u00E9";

Mais attention, il ne faut pas confondre l'encoding des Strings compilées avec la représentation interne des Strings dans la JVM qui est un Integer de 16 bits non signé, pouvant soit représenté, un code Unicode allant de U+0000 à U+FFFF ou un caractére UTF-16.

Encoding du fichier source

Puisque les chaines de caractères sont encodées une fois compilées vous n'avez pas à vous soucier de l'encoding du fichier source. Vous évitez aussi le problème de lecture de flux (puisque la String n'est pas lue mais compilée).

Pour spécifier l'encoding du fichier source, vous devez spécifier l'option encoding au compilateur. Exemple pour un fichier source encodé en Shift_JIS (japonais) :

javac -encoding Shift_JIS MonFichier.java

Tous les IDE permettent également de spécifier l'encoding. Sinon des outils comme NativeToAscii permettent de convertir des fichiers en unicode/Latin1 afin d'être indépendant de l'encoding.

Manipulation de Strings

Maintenant que l'on connait la représentation interne des Strings, on peut se demander ce qui se passe lorsque l'on fait un getBytes sur une String, c'est-a-dire que l'on veuille convertir les chars de la string en octets. Quel sera l'encoding utilisé ? Si une String est mal encodée en sortie, c'est que vous n'avez peut être pas spécifié l'encoding lors de l'écriture de la chaine dans un Writer ou que vous avez fait un getBytes() sur la string sans spécifier l'encoding.

Si vous faites un getBytes sur une chaine, vous aurez un encoding égal à celui de la JVM, et ce n'est pas forcément ce que vous vouliez.

Voici un exemple de code pour le prouver. Créez un fichier avec ce contenu et executer le sur une machine dont l'encoding est UTF-16 :

public static void writeBytesToFile(String string,File file)throws IOException{
    FileOutputStream out = new FileOutputStream(file);
    System.out.println("will write '"+string+"' byte to "+file.getAbsolutePath());
    out.write(string.getBytes());
    out.flush();
    out.close();
}

writeBytesToFile("aé",File.createTempFile(EncodingProblemsRepairKit.class.getSimpleName(), ".txt"))

Vous remarquerez qu'on utilise un OutputStream et donc que nous sérialisons des octets, mais En ouvrant le fichier écrit, vous verrez le contenu suivant

FF FE 00 61 00 E9

Le BOM FE FF pour dire qu'il s'agit d'UTF-16 Big Endian. puis les lettre 'a' et 'é' en UTF-16

Si vous recommencez, mais que vous l'éxecutez sur une machine dont l'encoding est UTF-8, le fichier de sortie sera :

61 C3 A9

Pour être indépendant de l'encoding de la machine, n'utilisez pas getBytes() mais plutôt getBytes(String charset), Cela rendra votre code plus robuste.

Ecriture dans un fichier

Pour sérialiser dans un fichier il existe une classe FileWriter, mais Je déconseille fortement de l'utiliser. Explications :

public static void writeStringCharToFile(String string,File file)throws IOException{
    FileWriter out = new FileWriter(file);
    System.out.println("will write '"+string+"' char to "+file.getAbsolutePath());
    out.write(getStringAsChar(string));
    out.flush();
    out.close();
}

public static char[] getStringAsChar(String string){
      char[] charArray = new char[string.length()];
      string.getChars(0, string.length(),charArray , 0);
      return charArray;
  }


File tempFileChar = File.createTempFile(EncodingProblemsRepairKit.class.getSimpleName(), ".txt");
writeStringCharToFile("aé",tempFileChar);

En ouvrant le fichier vous constaterez que l'encoding à été choisi par la JVM selon l'environnement d'execution

Avec FileWriter, vous n'avez pas la possibilité de spécifier l'encoding. Alors on peut se poser la question "Puis-je sérialiser dans un fichier sans tenir compte de l'encoding de la machine ? ". La réponse se trouve dans la javadoc de FileWriter :

FILEWRITER : Convenience class for writing character files. The constructors of this class assume that the default character encoding and the default byte-buffer size are acceptable. To specify these values yourself, construct an OutputStreamWriter on a FileOutputStream. C'est pourquoi je déconseille de l'utiliser.

Il existe d'ailleurs une méthode qui renvoie l'encoding du fileWriter getEncoding(). Pour spécifier l'encoding, il faut écrire la chose suivante :

public static void writeStringCharToFile(String string,File file,String encoding)throws IOException{
    OutputStream stream = new FileOutputStream(file);
    OutputStreamWriter out = new OutputStreamWriter(stream,encoding);
    System.out.println("will write '"+string+"' char to "+file.getAbsolutePath()+" with encoding="+encoding);
    out.write(getStringAsChar(string));
    out.flush();
    out.close();
}

writeStringCharToFile("aé","UTF-8");

et le fichier contiendrait :

61 C3 A9.

CQFD! et ceci, peu importe l'encoding de la machine.

A propos de la méthode getEncoding(), voici une chose importante à savoir ;

If this instance was created with the OutputStreamWriter(OutputStream, String) constructor then the returned name, being unique for the encoding, may differ from the name passed to the constructor. This method may return null if the stream has been closed.

En d'autres termes, la méthode getEncoding() peut ne pas retourner la même valeur que celle spécifiée par le constructeur. Toujours bon à savoir !

Connaitre et modifier l'encoding de votre JVM

Au risque de me répéter, l'encoding par défaut dépend de l'environnement d'exécution, et par conséquent de la JVM. plusieurs propriétés affectent l'encoding et certaines sont dépendantes du vendeur de la JVM : pour Sun vous avez les options 'sun.jnu.encoding' et "file.encoding". Vous pouvez les modifier en les spécifiant en ligne de commande avec -Doption=valeur.

Mon but est de vous démontrer que même si file.encoding permet de spécifier l'encoding par défaut, ce n'est pas la bonne façon de le faire. Comme nous allons le voir cela dépend de la version et du vendeur de JVM, n'est pas modifiable au runtime, et n'est pas pris en compte par toutes les méthodes. Pour spécifier l'encoding par défaut, Sun recommande de modifier la locale système

A mon sens, la meilleure pratique est de ne pas utiliser l'encoding par défaut mais de le déclarer dans une variable, et de l'utiliser à chaque fois qu'un encoding par défaut doit être utilisé. Cela n'empêche pas d'utiliser quelque fois un encoding spécifique, quand ce dernier est déterminé au runtime (e.g : dans le header 'content-encoding' d'une requête HTTP). Cette technique à l'avantage d'avoir une gestion centralisée puisqu'il vous suffit de changer cette valeur (au runtime, ou à la compilation), et de ne pas être dépendant d'options de lancement ou du système d'exploitation sous-jacent, sur lequel vous n'avez pas toujours la main.

Commençons par voir comment modifier ces options au runtime :

public static void setJVMEncoding(String charset) {
        setSystemProperty("file.encoding", charset);
        setSystemProperty("sun.jnu.encoding", charset);
}

public static void setSystemProperty(String name, String value) {
        if (System.getProperty(name) == null || !System.getProperty(name).equals(value)) {
            System.out.println("change system property from " + System.getProperty(name) + " to " + value);
            System.setProperty(name, value);

            System.out.println("System property" + name + " is now : " + System.getProperty(name));
        } else {
            System.out.println(name + "=" + System.getProperty("file.encoding"));
        }
}

public static String UTF8_CHARSET="UTF-8";
setJVMEncoding(UTF8_CHARSET);

La variable qui permet de spécifier le charset est "file.encoding". Malheureusement, le charset utilisé par les Writer / Reader n'est pas celui renvoyé par Charset.getDefault(), changer @file.encoding@@ n'aura donc aucun effet. (le comportement serait différent avec la jvm 6.0, mais je n'ai pas vérifié). Démonstration :

public static void printCharsetandFileEncoding(){
    System.out.println("Default Charset for writer before change=" + getDefaultCharSet());
    System.out.println("Default Charset=" + Charset.defaultCharset());
    System.setProperty("file.encoding", "Latin-1");
    System.out.println("file.encoding=" + System.getProperty("file.encoding"));
    System.out.println("Default Charset=" + Charset.defaultCharset());
    System.out.println("Default Charset for writer after change=" + getDefaultCharSet());
}

private static String getDefaultCharSet() {
    OutputStreamWriter writer = new OutputStreamWriter(new ByteArrayOutputStream());
    String enc = writer.getEncoding();
    return enc;
}

L'éxecution de ce code vous donnera avec une JVM 5.0 et -Dfile.encoding=UTF-8 :

Default Charset for writer before change=UTF8
Default Charset=UTF-8
file.encoding=Latin-1
Default Charset=ISO-8859-1
Default Charset for writer after change=UTF8

En recommencant avec -Dfile.encoding=ISO-8859-1 :

Default Charset for writer before change=ISO8859_1
Default Charset=ISO-8859-1
file.encoding=Latin-1
Default Charset=ISO-8859-1
Default Charset for writer after change=ISO8859_1

L'encoding utilisé par les Writers utilise bien file.encoding, mais ne peux être changer au runtime. (en savoir plus sur les bugs de file.encoding).

file.encoding ne change rien non plus à l'encoding utilisé par défaut pour String.getBytes() si on le change au runtime : créons un fichier, encodé en UTF-8, avec ce code :

public static String stringToHexa(String string) {
    System.out.println("will get bytes for "+string+" without encoding");
    byte[] bytes =string.getBytes();
    String hexaStringSubstring="";
        for (int i =0; i< bytes.length; i++){
        byte x = bytes[i];
        int intValue = Byte.valueOf(x).intValue();
        String hexaString = intValue==0?"00":Integer.toHexString(intValue);
        hexaStringSubstring = hexaString.substring(hexaString.length()-2);
        System.out.println("Hexa is:=" + hexaStringSubstring);
        }
        return hexaStringSubstring;
}

 System.setProperty("file.encoding", "ISO-8859-1");
    stringToHexa(maString);
    System.setProperty("file.encoding", "UTF-16");
    stringToHexa(maString);

l'éxécution affichera :

will get bytes for aé without encoding
Hexa is:=61
Hexa is:=c3
Hexa is:=a9
will get bytes for aé without encoding
Hexa is:=61
Hexa is:=c3
Hexa is:=a9

La sortie prouve que l'encoding utilisé est UTF-8 : comme l'encoding du fichier source. En revanche si vous spécifiez l'option -Dfile.encoding=ISO-8859-1 au démarrage, sans changer l'encoding du fichier source (UTF-8) : la sortie sera différente :

will get bytes for aé without encoding
Hexa is:=61
Hexa is:=e9
will get bytes for aé without encoding
Hexa is:=61
Hexa is:=e9

file.encoding ne change rien lorsqu'il est changé au runtime mais est bien pris en compte au lancement de la JVM.

Si vous ne la spécifier pas, sa valeur sera déterminée par la locale du système d'exploitation, Changer la locale est la façon que Sun recommande pour changer l'encoding par défaut. depuis la jvm 1.4 de sun, vous pouvez spécifiez la locale avec les paramètres -Duser.language -Duser.country et -Duser.variant mais cela rend votre code dépendant de la version et du vendeur de la JVM. Pas top !

Voici un résumé :

file.encoding n'est pas la bonne façon de spécifier l'encoding par défaut, même si cela fonctionnera dans certains cas lorsqu'il est spécifié au lancement de la JVM.
La bonne façon de modifier l'encoding par défaut est de changer la locale.
Ne pas Utiliser filewriter dont l'exécution dépendra de la machine.
La meilleure pratique est de ne pas utilisé l'encoding par défaut, mais de le spécifier à chaque fois (Reader, Writer, getBytes, ...)
Changer file.encoding au runtime change la valeur de Charset.defaultCharset().
Changer file.encoding ne change rien à l'encoding par défaut réellement utilisé par les Writer / Reader
file.encoding est utilisé pour determiner l'encoding à utiliser par la méthode getBytes de la classe String quand aucun encoding est spécifié, mais ne sera pris en compte que s'il est spécifié au lancement avec l'option -D.

Tout ça peut vous paraitre un peu complexe, et je ne vous dirai pas le contraire, mais le tout, c'est de le savoir. Au fil du temps, cela deviendra un réflexe.

Spécifier l'encoding n'est pas tout, et pour éviter les UnsuportedEncodingException, vous pouvez vouloir connaitre les charsets supportés par votre JVM :

Charset.availableCharsets();

Cela correspond au charsets déclarés dans le package Charset.jar dans le dossier jre/lib/ de la JVM.

Pour en savoir plus, consultez la FAQ de Sun sur le sujet

Comprendre ce qu'est input method et inputContext

Si vous utilisez eclipse, lorsque vous cliquez droit dans un éditeur de texte, vous avez un menu qui se nomme 'Input Methods'. Plusieurs valeur sont disponibles : System, Simpl, cédille,Thai-Lao, vietnamine, etc. Les input Methods et inputcontext permettent à un utilisateur de pouvoir rentrer des milliers de caractères en utilisant que quelque touche du clavier. Une séquence de touches au clavier permet de saisir un caractère spécifique. Vous pouvez modifier l'inputContext utilisé grace à la methode selectInputMethod de la class InputContext. Ceci ne concerne que les caractères saisie par des éditeurs écrits en Java, et vous ne devez que très rarement y toucher.

affichage dans un logiciel (navigateur,éditeur,...)

La dernière cause, peut ne pas venir de votre code mais d'un mauvais affichage. Le plus simple pour diagnostiquer ce problème étant de visualiser le flux en Héxadécimal, ou de visualiser les trames (avec etherReal par exemple)

Pour ce qui est des polices d'affichage en java , vous devez éditer un fichier qui se nome font.properties qui permet d'associer les polices systèmes aux polices java ( en savoir plus ).

Pour ce qui est des navigateurs, ils choisissent l’encoding à utiliser selon des priorités :

Utilisateur — Si l’utilisateur choisit via son navigateur un encodage spécifique à utiliser c’est ce dernier qui sera utilisé et aucun autre
En-tête — En-tête envoyée par Apache. Si vous spécifiez une en-tête via Java/Tomcat/Jetty c’est cet encodage qui aura la priorité sur celui d’Apache
Balise META — Si aucune en-tête n’a été envoyée par le serveur c’est l’encoding spécifié dans la balise META qui sera utilisé (ou dans le prologue XML si présent)

Voila! félicitation, vous êtes arrivés à la fin de l'article, j'espère que cela vous servira et que vos efforts seront récompensés :)

Le troisième et dernier post portera sur les différentes couches qui rentrent en compte lors de la requête /réponse d'une requête HTTP, et comment spécifier l'encoding Apache, Tomcat, ModJK, framework MVC, base de données, navigateurs).

Encoding et alphabets internationaux : comprendre et debugger (1ere partie)

Masclet — Fri, 11 Dec 2009 12:22:00 +0100

Lors de l'affichage de pages avec des mots dans des alphabets différents il peux arriver que des problèmes d'affichages apparaissent avec des � et des Ã©

Dans le cas de Gisgraphy (exemple pour Pékin), j'ai voulu vérifier que tout s'affiche correctement et que ce qui est affiché correspond bien à l'équivalent ASCII.

Je me suis donc rendu sur cette page et j'ai testé 北京, ce qui m'a donne 'bei jing'.ouah ça marche! et mon navigateur affiche le japonais! essayons en arabe avec بكين , cela me donne "bkyn" qui se rapproche de Beijing et Pékin en phonétique, et là aussi ça s'affiche correctement.

Cela m'a donné l'idée d'un post pour démystifier l'encoding par une suite de questions-réponses. (Finalement je le ferai en deux posts car c'est un peu long, et je risque de perdre et décourager pas mal de lecteurs si je n'en fais qu'un). Le premier expliquera ce qu'est l'encoding :

Qu'est ce qu'Unicode ?
Qu'est-ce que l'encoding, le BOM, le Little et le Big Endian
Quel est le meilleur encoding ?
Comment fonctionne une police de caractère ?
Comment gérer les sens d'écriture différents (par exemple, l'arabe qui s'écrit de droite à gauche)

Le second expliquera comment résoudre les problèmes fréquents avec de cas concrets et des extraits de code :

Comment gérer l'encoding dans un environnement web en java (Java, Apache, Tomcat, ModJK, base de données, navigateurs)
Comment gérer et débugger des problèmes d'encoding en java

Après ces deux posts vous ne devriez plus jamais voir ça : � sur vos sites, ou si c'est le cas vous saurez comment résoudre le problème :)

Qu'est ce qu'Unicode

Unicode attribut à tout caractère, symbole, ponctuation de n’importe quel système d’écriture, de langue, ou d'alphabet, un nom et un identifiant numérique, quelle que soit la plate-forme informatique.

On représente un caractère Unicode par la lettre U suivi d'un '+' et d'un nombre en représentation hexadécimal. Exemple pour la lettre A : U+0041. Le nom 'Unicode' associé à la lettre A est 'LATIN CAPITAL LETTER A'. On remarquera qu'il s'agit de la lettre 'A' en majuscule et que son équivalent en minuscule est différent (U+0061 et 'LATIN SMALL LETTER A'). Une liste de tous les noms classés par ordre alphabétique est consultable ici

Qu'est-ce que l'encoding, le BOM, le Little et le Big endian

L'encoding est une façon binaire de représenter un caractère Unicode. Si on prend l'exemple d'un fichier, l'encoding permet de stocker de façon binaire les caractères Unicode.

Les codages sont nombreux : (UTF-8, UTF-16, UTF-32, ISO-8859, Windows-1252 ...) et souvent déclinés en plusieurs versions. Pour L’iso-latin, il en existe plusieurs versions :

ISO-8859-1 où certains caractères comme 'œ' ont tout simplement été oubliés, au même titre que le 'ÿ'. Si vous vendez des œufs à Haÿ-les-roses, votre site risque de souffrir de problèmes d'encoding s'il est en ISO-8859-1 (tout savoir sur cette sombre histoire)
ISO-8859-15 où le symbole euro € à été ajouté ainsi que œ et Ÿ.

Pour l'UTF-16, c'est la même chose, il existe :

UTF-16
UTF-16BE pour 'Big Endian'
UTF-16LE pour 'Little Endian'

Little Endian et big Endian correspondent au sens de lecture des octets. On peut prendre la même analogie qu'entre l'arabe qui se lit de droite à gauche, et l'anglais qui se lit de gauche à droite. Pour les ordinateurs c'est pareil, il faut leur indiquer quel est le sens de lecture. il n'y a pas de règle, le but étant de permettre au programme qui affichera les caractères, de connaitre le sens de lecture.

Pour Windows, à chaque région du monde correspond un codage:

Windows-1252 (connu sous le nom de ANSI ou CP1252) pour l'alphabet latin
Windows-1256 pour les pays arabes
Windows-1257 pour les pays baltes
...

Le cyrillique et le japonais ont aussi plusieurs versions, il existe deux versions du chinois,...L'encoding, c'est un peu la tour de babel de l'informatique

Cela vous parait abstrait? Prenons un exemple pour mieux comprendre : Ouvrons un éditeur de texte, créons un nouveau fichier et écrivons un simple 'é', puis sauvegardons. Avant de sauvegarder, il nous est demandé de spécifier l'encoding, choisissons UTF-8. et UTF-8.txt en nom de fichier. Recommençons l'opération avec ISO-8859-1,UTF-16, UTF-16BE et UTF-16LE.

Maintenant ouvrons les fichiers avec un éditeur hexadécimal, afin de voir comment ils ont été sauvegardés. Voici le contenu Hexadécimal de chaque fichier:

ISO-8859-1 : E9 0A
UTF-8.txt : C3 A9 0A
UTF-16.txt : FF FE E9 00 FF FE 0A 00
UTF-16BE.txt: 00 E9 00 0A
UTF-16LE.txt : E9 00 0A 00

On peux faire les observations suivantes :

Pour une même lettre, le fichier est enregistré différemment. C'est ça l'encoding !
Le caractère 0A est ajouté à la fin de chaque fichier pour en marquer la fin.
Tous les UTF-16 prennent plus de place que l'UTF-8 puisqu'ils sont stockés sur 16 bits
L'UTF-16 commence par FFFE, il s'agit du BOM ou byte order mark. Le BOM sert à spécifier le type d'endian utilisé. Lorsque vous sauvegardez un fichier en UTF-16 vous ne spécifiez pas s'il s'agit de Big Endian ou de Little Endian, à la différence des UTF-16BE et UTF-16-LE. Un BOM égal à FFFE signifie qu'il s'agit d'UTF-16 en Little Endian, et un BOM égal à FEFF signifie qu'il s'agit d'UTF-16 en Big Endian. J'en veux pour preuve que le caractère 'é' est représenté de la même façon (E9 00) en UTF-16LE qu'en UTF-16 avec le BOM FFFE, tandis que l'ordre des octets est inversé en Big Endian (00 E9)
L'UTF-16BE et l'UTF-16LE prennent moins de place car il ne faut pas spécifier l'endian via le BOM

Quel est le meilleur encodage

Par expérience je pense que l'UTF-8 est souvent le plus adapté (il permet de coder tout les caractères unicode, et son support est répandu), mais bien sur il n'y a pas de bonne ou mauvaise réponse, sinon on n'utiliserai que le meilleur et on jetterai les autres. Les avantages et les inconvénients résident dans la place qu'ils occupent et le traitement qu'il faut faire pour les afficher.

L’Unicode n’assigne pas un nombre d'octets prédéfini par caractère, on l’appelle "multi-octet" : Ainsi, chaque caractère peut occuper entre 1 et 6 octets en UTF-8, ce qui optimise la taille de stockage mais augmente la difficulté de traitement. l'UTF-16 code tout les caractères sur 2 * 16 bits (un pour spécifier l'endian, l'autre pour le caractère), ce qui prend plus de place mais minimise les traitements.

Enfin L'UTF-16BE et UTF-16LE occupe moins de place, mais comme on ne connait pas L'endian utilisé il faut le spécifier par un autre moyen : par exemple dans le charset mime type du protocole HTTP, l'attribut encoding d'un fichier XML, etc. S'il est impossible de spécifier le type d'endian, il faudra se rabattre sur de l'UTF-16 avec BOM ou espérer que le logiciel qui affichera l'unicode a un algorithme de détection de l'encoding performant...plutôt hasardeux.

Qu'est-ce qu'une police de caractère

Maintenant que l'on a compris comment L'Unicode est représenté en binaire, voyons comment il est affiché, cette représentation est appelée 'glyphe'. C'est le rôle des polices de caractères Unicode. Souvent on pense à tord, qu'a un caractères glyphe correspond un Unicode. C'est malheureusement faux et plus complexe : un glyphe peut être associé à un ou plusieurs caractères Unicode et il n'y a aucune bijection.

Exemple avec le glyphe ê qui il peux être représenté de plusieurs façons en Unicode :

Par le caractère unicode U+00EA (C3 AA en encoding UTF-8)
Soit en précédent la lettre e par un autre caractère Unicode stipulant que le caractère suivant aura un accent circonflexe.

le même glyphe sera affiché.

On dira du premier caractère qu’il est précomposé, du second que c’est une composition (deux caractères forment un seul glyphe composé de deux caractères Unicode)

Démonstration : Sachant que l'accent circonflexe en Unicode est égal à U+0302 et CC 82 en UTF-8.

J'ouvre un éditeur hexadécimal et met CC 82 65 C3 AA A0 CC 82 : COMBINING CIRCUMFLEX ACCENT 65 : LATIN SMALL LETTER E C3 AA : LATIN SMALL LETTER E WITH CIRCUMFLEX A0 : ferme le fichier je sauvegarde, puis j'ouvre le fichier avec GEdit : deux ê apparaissent. L'encoding a été détecté en UTF-8 par GEdit et c'est bien la preuve qu'un glyphe n'est pas associé qu'a un seul caractère Unicode

Comment gérer les sens d'écritures différents

En général les logiciels modernes le détectent automatiquement : si vous copier coller 'الرباط' dans différents logiciels, le sens d'écriture changera automatiquement :

Sous firefox ou internet explorer, si vous le copier-coller dans un champs de saisie puis que vous appuyez plusieurs fois sur la barre d'espace, vous verrez les espaces s'afficher à la gauche du texte : le sens de l'écriture a changé.
Sous Windows : Avec wordpad (Démarrer->executer->tapez wordpad, ne pas confondre avec Word). une liste déroulant affichera 'arabe' et en appuyant sur la flèche gauche du clavier, elle se déplacera à droite :) un peu troublant mais logique.
Sous Ubuntu / Linux : Avec GEdit c'est encore plus fort, le texte s'affichera directement à droite.

En aucun cas c'est à vous de gérer cette complexité, au pire, il faut le spécifier au logiciel qui affiche les glyphes, Unicode ne définit rien à ce sujet, il s'agit de l'affichage, pas de la représentation informatique.vous pouvez aller sur cette page pour écrire en différentes langues.

pour convertir d'Unicode en différents formats, j'ai trouvé cette page très intéressante : http://rishida.net/tools/conversion/

Le second expliquera comment résoudre les problèmes fréquents avec de cas concrets et des extraits de code :

Comment gérer l'encoding dans un environnement web en java (Java, Apache, Tomcat, ModJK, base de données, navigateurs)
Comment gérer et débugger des problèmes d'encoding en java