Problème de charset en ligne de commande après installation

Bonjour à tous,

Je viens de faire une installation de Debian 5.0.5 sur un petit serveur dedié et pour la première fois j’ai des problèmes de charset, c’est à dire que les messages de la console comportent des caractères de ce style :

[quote]Paramétrage de libmagick10
Sélection du paquet libthai0 précédemment désélectionné.
Dépaquetage de libthai0 (à partir de …/libthai0_0.1.9-4+lenny1_i386.deb) …[/quote]

J’ai alors effectué deux dpkg-reconfigure locales successif, d’abord en choisissant fr_FR@euro par défaut, puis ensuite en choisissant fr_FR@UTF8 (quelque chose dans ce genre), mais rien n’y fait.

Sauriez-vous ce que je peux faire d’autre ?

D’avance merci !

c’est que tu as une différence de charset entre la locale et ta console (ou ton émulateur de terminal).

comme tu as fait, tu as

pour configurer la locale du système, mais ça définit quel encodage utiliser, pas quel encodage interpréter ;-).

Tu peux aussi le faire sans dpkg :

vim /etc/locale.gen # décommenter celle qui t'intéresse locale-gen

pour changer l’affichage de la console (la vraie, si tu as un accès physique à l’écran)

Sans dpkg :

vim /etc/default/console-setup # mettre le bon CHARMAP /etc/init.d/console-setup restart

Si tu as un problème lorsque tu accèdes dans un émulateur de terminal (xterm par ex.), en local ou à distance (via ssh), alors c’est du coté de l’émulateur de terminal qu’il faut voir à corriger ça, gnome-terminal comme beaucoup d’autres propose un menu pour ça.

sinon tu peux utiliser luit (paquet x11-utils), lui ouvre un shell et fait les correspondances (quand il peut).
Par exemple, si ta machine distante affiche en ISO 8859-1 et que ton terminal est en UTF-8 :

Attention, l’exemple précédent t’ouvre un sous-shell, si tu fais su puis luit, ou ssh puis luit, il te faudra sortir deux fois.

Et voir le man de luit pour le reste

[code]# extrait
EXAMPLES
The most typical use of luit is to adapt an instance of XTerm to the locale’s encoding. Current versions of XTerm invoke luit automatically when
it is needed. If you are using an older release of XTerm, or a different terminal emulator, you may invoke luit manually:

          $ xterm -u8 -e luit

   If you are running in a UTF-8 locale but need to access a remote machine that doesn't support UTF-8, luit can adapt the remote output to your ter‐
   minal:

          $ LC_ALL=fr_FR luit ssh legacy-machine

   Luit  is also useful with applications that hard-wire an encoding that is different from the one normally used on the system or want to use legacy
   escape sequences for multilingual output.  In particular, versions of Emacs that do not speak UTF-8 well can use luit for multilingual output:

          $ luit -encoding 'ISO 8859-1' emacs -nw[/code]

Si tu as des fichiers qui étaient nommés avec un ancien encodage, tu peux utiliser convmv pour les convertir, voir le man de luit (et être très prudent).

[code]# extrait
OPTIONS
-f ENCODING
specify the current encoding of the filename(s) from which should be converted

   -t ENCODING
       specify the encoding to which the filename(s) should be converted

   -i  interactive mode (ask y/n for each action)

   -r  recursively go through directories

   --notest
       Needed to actually rename the files. By default convmv will just print what it wants to do.[/code]

Il vaut mieux que toute ton système soit cohérent avec le même encodage (messages, noms de fichiers, console…) sinon tu risque d’avoir des surprises :wink: sachant qu’il ne suffit pas que l’encodage soit le même sur la même machine, puisque si tu essaie d’accéder depuis une autre machine (via ssh par exemple) tu auras aussi des surprises si ça diffère entre le client et le serveur :confused: et alors luit est ton ami.

Un grand merci pour ton aide, ma console est au point !!!

Avec un petit résolu (coche verte) ce serait encore mieux! :006