[Résolu] Problème d'encodage de caractères

Support Debian
#1

Bonjour,

je suis nouveau dans le monde linux et je suis confronté à un problème que je n’arrive pas à résoudre.

Notre machine de production a grillé récemment et notre hébergeur a remplacé disque dur, carte mère + cpu. La version de debian installée est la suivante:

$uname -a 2.6.16.18-likl
Le problème est qu’en mode console (seul mode par lequel je peux accéder à la machine), je ne peux pas taper les accents (é,è,à,ù,ê,…). De plus, cette machine nous sert à faire tourner une application sous Tomcat et tous les documents pdf comportant des accents dans leur nom ne peuvent être ouverts à distance. J’ai fait quelques recherches et j’en ai conclu qu’il fallait reconfigurer les locales. Lorsque je fais un locale j’obtiens:

$locale LANG= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL=
Ensuite, j’ai fait

$locale charmap ANSI_X3.4-1968
Donc là je me dis normal que les accents ne soient pas gérés…

Ensuite, j’ai tenté

#dpkg-reconfigure locales Puis, j'ai choisi fr_FR@euro ISO-8859-15 puis fr_FR@euro
Mais cela n’a rien changé, en refaisant un locale et un locale charmap, j’obtiens la même chose que précédemment…

Si je vais voir les fichiers de configuration, tout semble correct…

[code]less /etc/environment
$LANGUAGE=“fr_FR:fr:en_GB:en”

LANG=fr_FR@euro[/code]

$less /etc/default/locale LANG=fr_FR@euro

$less /etc/locale.gen fr_FR@euro ISO-8859-15

J’ai également rebooté la machine même si normalement ce n’est pas utile mais encore une fois le problème est toujours présent.

Donc, voilà je ne sais plus quoi faire… Je pense que la prochaine étape sera de mettre dans .bashrc, un export LANG=fr_FR@euro mais je ne sais pas si ça suffira. Si quelqu’un pouvait m’expliquer ce que j’ai raté parce que là j’avoue ne pas comprendre.

#2

Personellement je n’ai pas de problèmes et je suis en UTF-8
A essayer (ce serait le prochain standard) mais certains ont eu des problèmes avec des bases de données (lettres accentuées mal reconnues)

#3

Quand tu dis que tu n’arrives pas à tapper les accents, rien ne s’affiche?
loadkeys fr
ensuite dpkg-reconfigure locales
. et choisis tous les fr_FR (ISO-8859-1, ISO-8859-15, UTF-8)
. Ensuite pour la langue du système choisis UTF-8
. Clique OK

Il t’affiche bien les messages generating… trois fois?

Puis relance locale pour verifier

#4

En fait quand je tape sur “é”, rien ne s’affiche alors que si je tape sur & ou sur " ou sur ’ (les touches directement voisines du “é”), là le caractère s’affiche.

Qu’est ce que ça change de sélectionner tous les fr_FR dans dpkg-reconfigure?
Pourquoi choisir UTF-8 pour la langue du système?

J’essaierai cette manip ce soir car le serveur est en prod et même s’il y a quelques pbs liés aux accents ils sont minimes par rapport au reste de l’application donc je ne peux pas me permettre de faire une bêtise maintenant.

Enfin, je ne pense pas que cela changera quoi que ce soit car à priori le système ne prend pas en compte les modifications puisque locale affiche uniquement POSIX malgré un dpkg-reconfigure locales, enfin je verrai bien. Si quelqu’un a déjà eu le même problème, je suis preneur pour toutes les pistes possibles.

#5

[quote=“mouadib72”]En fait quand je tape sur “é”, rien ne s’affiche alors que si je tape sur & ou sur " ou sur ’ (les touches directement voisines du “é”), là le caractère s’affiche.

Qu’est ce que ça change de sélectionner tous les fr_FR dans dpkg-reconfigure?
Pourquoi choisir UTF-8 pour la langue du système?
[/quote]
C’est une habitude. En théorie le nouveau standard c’est UTF-8 (la prochaine debian stable sera de base en UTF-8) Mais certains programmes ou fichiers de données ne sont toujours pas en UTF8 donc il est preferable d’avoir les autres fr_FR

Je comprends

[quote]
Enfin, je ne pense pas que cela changera quoi que ce soit car à priori le système ne prend pas en compte les modifications puisque locale affiche uniquement POSIX malgré un dpkg-reconfigure locales, enfin je verrai bien. Si quelqu’un a déjà eu le même problème, je suis preneur pour toutes les pistes possibles.[/quote]
Tu trouvera des centaines de personnes avec ce problème. C’est pas évident.
Si il reste sur POSIX c’est peut etre que ces locales ne sont pas installées. C’est pas normal, je crois qu’elle viennenet avec le paquet locales justement.
En prenant juste ton problème de console (tomcat c’est autre chose), il y a trois choses qui peuvent intervenir:
Le mapping du clavier : loadkeys
La locale : locale
La police : consolechars

En tout cas, POSIX c’est pas bon, il faut deja regler ce problème.

Enfin de ce que j’en ai compris :slight_smile:
Un peu de doc :
opengroup.org/onlinepubs/009 … hap07.html

#6

Merci pour tes éclaircissements,

j’essaierai tout ça ce soir. Je vais faire des recherches pour voir si les locales sont réellement installées.

#7

Sinon, il y a un deuxiême gestionnaire de locales à utiliser, c’est belocs-locales-[bin|data].
Mais normalement, quand on installe proprement un noyau aussi récent qu’un 2.6.16, il me semble qu’il s’installe de lui même comme dépendance en remplacement de locales.
D’ou vient ton noyau ?

#8

Tiens je le connaissais pas cuila. Ca se chevauffe avec la libc6 ce truc, zarbi. Ca permet de compiler les locales pour qu’elles soient utilisables par la libc6 (localedef). Ensuite il faut lancer locales pour selectionner celles voulus.

C’est vrai que c’est bizarre ton histoire mouadib, ca devrait avoir été fait.

[quote]FILES
/usr/share/i18n/charmaps
Usual default charmap path.

   /usr/share/i18n/locales
          Usual default path for locale source files.

   /usr/share/i18n/repertoiremaps
          Usual default repertoire map path.

   /usr/lib/locale/locale-archive
          Usual default locale archive location.[/quote]

Chez moi c’est déja compilé (installé):

[code]root@debian# ll /usr/share/locale/fr
total 108
-rw-r–r-- 1 root root 6 2005-09-10 11:16 charset
-rw-r–r-- 1 root root 1694 2006-10-01 18:27 entry.desktop
-rw-r–r-- 1 root root 331 2005-09-10 11:16 flag.png
drwxr-xr-x 2 root root 65536 2006-10-31 13:15 LC_MESSAGES
drwxr-xr-x 2 root root 4096 2006-10-23 12:22 LC_TIME
-rw-r–r-- 1 root root 13133 2005-09-10 11:16 nbsp_gui_fr.txt
-rw-r–r-- 1 root root 601 2005-09-10 11:16 relecture_docs
-rw-r–r-- 1 root root 1054 2005-09-10 11:16 relecture_gui

[/code]

#9

Et par ailleurs : il n’y a pas une partie de l’info pour la sélection de locales qui est fournie par le client ssh ?
Je veux dire: le choix des locales dans un terminal ne dépend pas aussi un peu des variables transmises à la connection ?
(enfin ceci etant dit, je n’ai jamais rien compris à la localisation).

#10

En fait si tu lance ssh avec les options -vvvv (au moins ca) tu vois que le client ssh envoie certaines variables d’environnement dont les locales je crois.
Sinon moi non plus j’ai pas tout bien assimilé sur les locales.
Pourtant j’ai essayé hein! :slightly_smiling:

#11

Faut-il installer ce package car il ne semble pas présent sur ma machine… En tapant belocs-lo + tab rien ne se passe, j’en déduis qu’il n’est pas installé.

Mon hébergeur l’a installé (hébergeur: ikoula)…

#12

Ca c’est casse pied: ta machine est en prod, donc tu ne peux pas te permettre de tester.
Ce que j’aurais bien fait, c’est d’installer un 2.6.16-18 debian, pas pour l’utiliser, mais juste pour tirer les dépendances qui vont avec.
Peut être en simulant (apt-get -s install linux-image-2.6.16-18-686, par exemple), pour voir ce qu’il te propose d’installer ?
Mais bon.

#13

A priori, j’ai réussi à résoudre le problème en ajoutant simplement un
export LANG=fr_FR@euro dans le fichier .bashrc de la machine en production.

Ensuite, en me reconnectant en ssh et en saisissant

j’obtiens:

LANG=fr_FR@euro LC_CTYPE="fr_FR@euro" LC_NUMERIC="fr_FR@euro" LC_TIME="fr_FR@euro" LC_COLLATE="fr_FR@euro" LC_MONETARY="fr_FR@euro" LC_MESSAGES="fr_FR@euro" LC_PAPER="fr_FR@euro" LC_NAME="fr_FR@euro" LC_ADDRESS="fr_FR@euro" LC_TELEPHONE="fr_FR@euro" LC_MEASUREMENT="fr_FR@euro" LC_IDENTIFICATION="fr_FR@euro" LC_ALL=
Ce que je désirai.
Enfin, j’ai relancé Tomcat afin qu’il prenne en considération les nouvelles locales et j’arrive à accéder aux fichiers comportant des accents dans leurs noms.

J’avais été voir du côté du BUG330458 et ses dérivés et les propositions de solutions mais aucune n’a fonctionné (je n’ai pas mis à jour le module PAM).

Par contre le export a fonctionné donc voilà je marque le sujet comme résolu même si je n’aime pas la solution utilisée.