Une histoire d'encodage et d'accès SSH

Une histoire d'encodage et d'accès SSH - Divers - Linux et OS Alternatifs

Marsh Posté le 04-10-2007 à 23:24:09    

Hello les gens !
 
J'ai un petit souci d'encodage via SSH sur ma Debian Etch !
 
Mon serv est config comme ça :

Code :
  1. Sullivan:~# locale
  2. LANG=fr_FR.UTF-8
  3. LC_CTYPE="fr_FR.UTF-8"
  4. LC_NUMERIC="fr_FR.UTF-8"
  5. LC_TIME="fr_FR.UTF-8"
  6. LC_COLLATE="fr_FR.UTF-8"
  7. LC_MONETARY="fr_FR.UTF-8"
  8. LC_MESSAGES="fr_FR.UTF-8"
  9. LC_PAPER="fr_FR.UTF-8"
  10. LC_NAME="fr_FR.UTF-8"
  11. LC_ADDRESS="fr_FR.UTF-8"
  12. LC_TELEPHONE="fr_FR.UTF-8"
  13. LC_MEASUREMENT="fr_FR.UTF-8"
  14. LC_IDENTIFICATION="fr_FR.UTF-8"
  15. LC_ALL=
  16. Sullivan:~# cat /etc/locale.gen
  17. fr_FR@euro ISO-8859-15
  19. fr_FR.UTF-8 UTF-8


J'utilise Putty pour avoir l'accès SSH à mon serv.
 
Quand je lance Putty configuré par défaut (en ISO 8859-15 donc), et que je lance le gestionnaire aptitude, les caractères accentués sont remplacés par des signes cabalistiques, mais les traits sont normaux :
http://images3.image-hotel.info/ri03zx0f4i.png
 
Quand je lance Putty configuré en UTF-8 et que je lance le gestionnaire aptitude, les caractères accentués sont affichés correctement, mais les traits sont remplacés par les caractères l q k m x etc...
http://images3.image-hotel.info/wcv3cthm1j.png
 
Alors deux questions se posent :
1) Est-ce que c'est possible de forcer le client SSH à utiliser un jeu de caractères via une config du serveur SSH ?
2) Est-ce que c'est possible d'avoir à la fois les traits ET les caractères accentués affichés correctement ?
 
Merci d'avance ! :jap:

Reply

Marsh Posté le 04-10-2007 à 23:24:09   

Reply

Marsh Posté le 07-10-2007 à 02:04:03    

Personne n'a déjà rencontré ce genre de souci :??:

Reply

Marsh Posté le 07-10-2007 à 11:26:06    

J'ai le même problème avec ncmpc... Jamais pu le résoudre, donc [:drapal]

Reply

Marsh Posté le 07-10-2007 à 11:30:34    

Quand j'avais passer mon système en utf8 j'avais lancer un utilitaire debian pour convertir mes fichiers. Je pense que ca doit etre pareil pour tous les fichiers notament dans le /usr/share.
 
vous l'avez fait ?


---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 07-10-2007 à 11:33:58    

Depuis le début je suis en utf-8 pour ma part... à priori, dixit un pote, ce serait un problème connu de ncurses :/ M'enfin, ça fait un moment que c'est comme ça, c'est bizarre que cela n'ait pas été résolu encore...

Reply

Marsh Posté le 07-10-2007 à 12:09:05    

Citation :

Line-drawing characters come out as x's and q's
The x's and q's correspond to a table (from terminfo/termcap) which tells ncurses how to map the "alternate" character set to the terminal's set of graphic characters. The reference for this table comes from the vt100. If the unmapped characters appear, then the terminal emulator does not recognize the escape sequence for switching between normal and alternate fonts that is given in the terminfo description.
 
There are several cases of note:
 
    * Terminal emulators which use a different escape sequence or different range for mapping the resulting characters. For instance the so-called vt100-compatibles such as Linux console and Tera Term.
    * Terminal emulators which are locale-sensitive. Again, Linux console is a problem area when running in UTF-8 mode, since its nominal vt100-compatibility is further lessened by ignoring the escape sequences dealing with fonts. The screen utility also has the same problem; whether to make the implementation simple or to copy the Linux console, it ignores vt100-style font switching when the locale is a UTF-8 flavor.  
 
For the first case, you simply have to find the correct terminfo description. Fixing the latter is harder, since the damage is done outside ncurses. (Though one can easily make things compatible enough that this particular issue would never appear, that style of solution is not deemed proper by some coders).
 
The normal ncurses libraries support 8-bit characters. The ncurses library can also be configured (--enable-widec) to support wide-characters (for instance Unicode and the UTF-8 encoding). The corresponding wide-character ncursesw libraries are source-compatible with the normal applications. That is, applications must be compiled and linked against the ncursesw library.
 
The ncurses 5.3 release provides UTF-8 support. The special cases of Linux console and screen were addressed in development patches completed at the end of 2002.

http://invisible-island.net/ncurse [...] ne_drawing

Reply

Marsh Posté le 07-10-2007 à 12:14:10    

Bon, une solution qui fonctionne : http://christianlong.com/node/2

Reply

Marsh Posté le 07-10-2007 à 13:40:23    

wokay, c'est donc l'option suivante qu'il faut changer dans Putty :

 

Dans le menu 'Connection > Data', il faut passer l'option 'Terminal-type string' de xterm à linux

 

Merci RiderCrazy pour le lien !

  

Donc la question 2 est résolue !
Manque plus que la question 1 ! :d
1) Est-ce que c'est possible de forcer le client SSH à utiliser un jeu de caractères via une config du serveur SSH ?


Message édité par Ducktale le 07-10-2007 à 13:41:55
Reply

Marsh Posté le 03-11-2007 à 14:02:29    

up :d

Reply

Marsh Posté le 03-11-2007 à 14:45:05    

Ni le client, ni le serveur SSH ne sont au courant d'un quelconque police à utiliser.
 
C'est le terminal (bon en l'occurence avec Putty, Terminal et client SSH sont confondu, mais bon, ce que je veux dire c'est que coté client SSH il voit pas de police, il voit que des caractères).
 
Donc la réponse à ta question c'est non ;)


---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Reply

Marsh Posté le 03-11-2007 à 14:45:05   

Reply

Marsh Posté le 03-11-2007 à 17:29:14    

je parle bien de caractères, pas de police !

Reply

Marsh Posté le 03-11-2007 à 18:48:21    

Ah oui j'ai lu trop vite [:pingouino]
 
Mais bon la réponse reste la même, le protocole SSH ne fait pas de disctinction entre UTF-8 ou autre, c'est le système du serveur (sur lequel tu executes un shell ou une application) et l'application sur le client qui voient ça.
 
Pour bien comprendre, SSH est le tunnel entre ton terminal client (putty) et un shell (ou une application lancé dans ce shell) sur le serveur, qui eux sont configurés pour utiliser un codage des caractères ou un autre. Le protocole SSH lui il fait passer des octets (qui représentent des caractères) chiffrées sur le réseau, il s'arrète à ce niveau là, il ne cherche pas à savoir si ces octets sont des caractères en ISO ou en UTF-8, il ne cherche pas à les comprendre, il est une couche plus bas :)
 
C'est plus clair expliqué comme ça ?


---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Reply

Marsh Posté le 04-11-2007 à 03:10:06    

je connais à peu près le principe, pas de soucis ...
Mais le serv SSH aurait pu envoyer justement en début de connexion SSH (avec le certificat RSA par exemple), une séquence qui dise au terminal quel encodage est utilisé sur ce serveur !
Bon après, si tu me dis qu'il n'y a pas de tweak possible, je ne vais pas chercher plus loin ! ;)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed