Forum Linux.mandriva Lettres accentuées

Posté par  (site web personnel) .
Étiquettes :
0
28
fév.
2006
Salut,

Nous avons écrit une application Java avec Eclipse utilisant SWT. Au début, nous utilisions RedHat 9, ensuite nous sommes passés à Debian Sarge. L'application compilée fonctionne correctement sous ces deux distributions ainsi que sous MS Windows.

Le problème est arrivé quand nous l'avons installée sous Mandrake 10.1 et Mandriva 2006: les lettres accentuées ne s'affichent pas correctement.

Il serait contraignant de changer de distribution juste pour ça, alors quelqu'un a une idée pour régler ce problème ?

Merci d'avance.

  • # Pb de locale ?

    Posté par  . Évalué à 2.

    Sûrement un problème de locale. Regarde et compare les différentes configurations...

  • # re Lettres accentuées

    Posté par  . Évalué à 1.

    que donne la commande locale et que trouve t'on dans /etc/sysconfig/i18n

    sous debian par exemple par défaut on a LANG=fr_FR@euro

    a voir ce que l'on a dans mandriva

    • [^] # Re: re Lettres accentuées

      Posté par  (site web personnel) . Évalué à 1.

      la commande locale donne LANG=fr_FR
      dans /etc/sysconfig/i18n il y a (entre autres) : LANGUAGE=fr_FR:fr
      pas de @euro... mais est-ce bien le problème ?
      et comment faire pour changer ça en fr_FR@euro ?

      GNU's Not Unix / LINUX Is Not Unix Xernel

    • [^] # Re: re Lettres accentuées

      Posté par  (site web personnel) . Évalué à 1.

      voici le contenu de i18n :

      SYSFONTACM=iso15
      LANGUAGE=fr_FR:fr
      LC_ADDRESS=fr_FR
      LC_COLLATE=fr_FR
      LC_NAME=fr_FR
      LC_NUMERIC=fr_FR
      LC_MEASUREMENT=fr_FR
      LC_TIME=fr_FR
      LANG=fr_FR
      LC_IDENTIFICATION=fr_FR
      LC_MESSAGES=fr_FR
      LC_CTYPE=fr_FR
      LC_TELEPHONE=fr_FR
      LC_MONETARY=fr_FR
      LC_PAPER=fr_FR
      SYSFONT=lat0-16

      je n'y comprends rien... si quelqu'un trouve ça utile...

      GNU's Not Unix / LINUX Is Not Unix Xernel

    • [^] # Re: re Lettres accentuées

      Posté par  (site web personnel) . Évalué à 1.

      on vient d'essayer l'application sous Ubuntu Live : il y a aussi un problème avec les lettres accentuées !!
      Dans Ubuntu Live il n'y a pas de /etc/sysconfig/i18n la commande locale donne :
      LANG=fr_FR.UTF-8
      Que faut-il faire alors ?

      GNU's Not Unix / LINUX Is Not Unix Xernel

  • # Problème réglé !

    Posté par  (site web personnel) . Évalué à 1.

    J'y ai passé des heures mais j'ai enfin trouvé le problème !

    C'était bien utf8 ! En fait, il ne fallait pas activer unicode et ça avait été fait à l'installation de Mandriva.
    En le désactivant le problème s'est partiellement réglé : les données provenant de l'extérieur du programme (d'une base de données FireBird) apparaissaient normalement, mais les lettres accentuées de l'interface restaient problématiques.

    C'était tout simplement parce que l'application avait entre temps été recompilée pendant que utf8 était activé ! C'est en examinant les chaînes de caractères à l'intérieur des fichiers .class et en les comparant avec ceux que j'avais sur un autre PC sous Windows que j'ai compris.

    En recompilant les fichiers cette fois sans utf8, tout est rentré dans l'ordre.

    Merci quand même à tous ceux qui ont essayé de m'aider (sur ce forum, sur #linuxfr et sur #mandrivafr).

    GNU's Not Unix / LINUX Is Not Unix Xernel

    • [^] # Re: Problème réglé !

      Posté par  (site web personnel) . Évalué à 3.

      !?

      En java le source ne peut et doit contenir que des caractères ISO-8859-1. Pour "coder" le reste il faut utiliser l'escape unicode (native2ascii). C'est pour cela que j'ai beaucoup de mal à croire que recompiler avec une locale différent fasse une différence ! Et d'ailleurs le contenu des fichiers de classe est lui même standardisé sur UTF-16. La seule possibilité que j'entrevoie est que lors de la copie de tes fichiers source entre une machine en ISO-8859-1 et une en UTF-8, un transcodage ait été effectué entre ces deux codages par le programme ayant effectué la copie.

      Maintenant par contre si ton logiciel est utilisé sous une locale différente, et qu'il contient du code dépendant de la locale de la JVM (c'est mal d'ailleurs) là tu auras un problème. Même si maintenant ton logiciel fonctionne, ce n'est pas dit que tu n'aies pas d'autres problèmes à l'avenir, autant bien faire dès le début... En théorie les méthodes java qui se servent de la locale de la JVM sont deprecated et doivent être remplacées, par exemple pour le codage des URLs :

      http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLEncoder.(...)

    • [^] # Re: Problème réglé !

      Posté par  (site web personnel) . Évalué à 3.

      C'était bien utf8 ! En fait, il ne fallait pas activer unicode et ça avait été fait à l'installation de Mandriva.
      En le désactivant le problème s'est partiellement réglé : les données provenant de l'extérieur du programme (d'une base de données FireBird) apparaissaient normalement,

      Ceci diagnostique un autre problème : quel que soit la locale utilisée par ta plateforme, tu ne dois pas être impacté dans le transfert des données de la base, il n'y a aucune raison que ce soit le cas. La base de donnée utilise un charset bien défini (enfin je ne connais pas FireBird mais si ce n'est pas le cas il faut en utiliser une autre !) et les données en Java ont toujours un charset bien défini (par exemple lorsqu'on crée une chaine de caracteres a partir d'un flot d'octets on doit dire quel charset est utilisé - on n'est pas *strictement* obligé de le faire en fait, on peut utiliser une autre méthode utilisant la locale de la JVM mais c'est très dangereux car ça mène exactement au genre de problème que tu as).

      Tu as un problème à l'extraction des données de ta base. Si tu utilises JDBC, tu dois utiliser le paramètre "charSet=" et lui donner le charset utilisé par la base de données. En general il est prudent d'utiliser UTF-8 dans la base pour ne pas avoir de problème si un jour tu souhaites mettre dans ta base des langues hors de l'europe de l'ouest. Tu n'auras ensuite aucun problème quelle que soit la locale de la JVM (donc du système).

      • [^] # Merci

        Posté par  (site web personnel) . Évalué à 1.

        Merci d'avoir pris le temps de lire et surtout de me donner tes précieux conseils...

        En effet, je me souviens maintenant que je n'ai pas donné d'importance au charset à la création de la base de données firebird (j'ai laissé "NONE" par défaut). En voyant que ça marchait sans problème, je n'ai pas prévu que j'aurais des ennuis plus tard.

        Je tâcherai de faire plus attention à l'avenir et je prendrai en compte tes remarques.

        Quant à la re-compilation, j'ai vérifié (en regardant les dates des fichiers) que la première compilation qui m'a donné les .class problématiques datait d'après la recopie sous Mandriva. Après avoir "enlevé" utf-8 la recompilation m'a donné des fichiers .class différents, avec des caractères encodés "correctement" et qui s'affichent normalement à l'exécution.
        Je crois avoir vu une option dans Eclipse pour changer l'encodage, mais je ne sais plus où... je vais re-chercher pour voir si ça peut changer le résultat (pour mieux comprendre surtout).

        GNU's Not Unix / LINUX Is Not Unix Xernel

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.