Connexion depuis un PC Windows 7 via SSH à un serveur Ubuntu en utilisant PuTTY , j'obtiens des erreurs d'écran:
C'est à dire. il:
Je me suis connecté au même serveur Ubuntu avec un terminal et SHH à partir d'un Mac OS X et je ne fais pas de brouillage d'écran (c'est-à-dire que tout semble et fonctionne correctement). J'ai déjà essayé de jouer avec les paramètres de police dans PuTTY, en le changeant de Courier New en Consolas mais sans chance.
Ma question est donc:
Comment configurer PuTTY pour afficher correctement les caractères spéciaux et non les lignes d'écran à double tracé/écrasement?
Vous avez presque certainement défini le mauvais jeu de caractères dans vos paramètres PuTTY .
Vérifiez le jeu de caractères sur le système distant en exécutant la commande:
locale
Cela devrait renvoyer quelque chose comme:
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
Vérifiez donc vos paramètres PuTTY sous Traduction et assurez-vous que vous disposez de UTF-8
défini comme jeu de caractères.
Vous devrez peut-être également modifier le paramètre de dessin au trait, mais ce n'est probablement pas probable.
J'ai eu un problème avec le programme aptitude
de Debian même si j'avais UTF-8 comme jeu de caractères. Ce qui a fonctionné pour moi a été de définir la 'Connexion> Données>' Chaîne de type terminal 'sur' PuTTY 'au lieu de' xterm '- apparemment PuTTY ignore la séquence de caractères pour passer en mode dessin: http: // www .chiark.greenend.org.uk/~ sgtatham/PuTTY/wishlist/utf8-plus-vt100.html
De plus, si UTF-8 n'est pas correctement configuré, vous pouvez l'exécuter en tant que mc -ac .
Crédits: http://blog.acsystem.sk/linux/midnight-commander-utf8-line-drawing-characters-problem
Les deux facteurs de base sont Window/Translation UTF-8 dans PuTTY et les paramètres régionaux sous Linux, comme indiqué ici et dans de nombreux autres endroits.
De plus, il peut être utile dans PuTTY de définir la chaîne Connexion/Données/Type de terminal sur PuTTY , et/ou sous Linux vers export NCURSES_NO_UTF8_ACS=1
. Ces deux sont également mentionnés à plusieurs endroits.
Mais: vous pouvez toujours obtenir des blocs pour certains caractères car les polices par défaut comme Courier et Lucida Console n'ont pas tous les caractères Unicode. Téléchargez et installez http://dejavu-fonts.org/wiki/Download , et définissez PuTTY pour l'utiliser.
Cette dernière astuce m'a été nécessaire pour que noping
(recommandé!) Affiche tous les caractères graphiques.
Après 15 ans, je me suis énervé une fois de plus et j'ai cherché sur Google à nouveau, j'ai trouvé cela, j'ai choisi
modifier les paramètres → fenêtre → traduction → jeu de caractères à distance → "utiliser l'encodage des polices"
et cela l'a corrigé.
Dans mon cas (Ubuntu 14.04), le problème était dû à l'absence
UsePAM yes
l'entrée dans/etc/ssh/sshd_config en tant que configuration pam /etc/pam.d/sshd est responsable par défaut du chargement de/etc/default/locale dans l'environnement des utilisateurs.
Pour tous les pauvres vieux VMS qui se retrouvent ici:
PuTTY → Fenêtre → Traduction → Jeu de caractères à distance → DEC-MCS
travaillé pour moi.
Je cherchais de nombreuses solutions pour cela lors de l'utilisation de la machine Docker (à la fois locale et sur les machines configurées par l'administrateur système). Dans mon PuTTY, tout allait bien (j'avais UTF-8
), J'utilisais également un autre client SSH et j'avais exactement le même problème.
Fonctionnement:
mc -ac
résolvait le problème (mais pas complètement) et je cherchais une solution complète.
Après avoir lu de nombreuses suggestions, j'ai finalement trouvé celle qui a résolu mon problème.
Dans le terminal lorsque vous exécutez:
locale
vérifiez les paramètres régionaux que vous avez définis. J'avais par défaut C
locale.
Pour vérifier tous les paramètres régionaux installés, exécutez locale -a
J'ai par exemple:
C
C.UTF-8
POSIX
par défaut.
La solution exporte la variable LANG
avec C.UTF-8
locale comme ceci:
export LANG="C.UTF-8"
Vous pouvez évidemment l'ajouter dans .bashrc
pour qu'il soit automatiquement défini dans votre profil.
J'ai dû définir, sur la page Fenêtre → Traduction, le jeu de caractères:
ISO-8859-1: 1998 (Latin-1, Europe de l'Ouest)
Ensuite, et seulement à ce moment-là, les caractères de tracé de ligne sont apparus correctement.
Une autre raison liée au pam peut affecter les hôtes avec l'authentification powerbroker/pbis/similar.
grep /etc/pam.d pour l'occurrence "lsass":
grep -r lsass /etc/pam.d
si vous voyez dans la sortie quelque chose comme:
/etc/pam.d/common-session:session sufficient pam_lsass.so
alors c'est probablement la cause première du problème. La solution rapide consiste à remplacer "suffisant" par "facultatif" à côté du module pam_lsass pour qu'il ressemble à ceci:
/etc/pam.d/common-session:session optional pam_lsass.so
/etc/pam.d/common-session (ou tout autre fichier avec une entrée similaire - il pourrait y en avoir peu) est probablement inclus par /etc/pam.d/sshd avant le chargement de pam_env, donc si le traitement des modules pam est terminé avant d'arriver à pam_env, le fichier/etc/default/locale n'est pas chargé dans l'environnement utilisateur et vous avez des caractères tronqués.
Comme mentionné dans de nombreuses réponses:
PuTTY> Fenêtre> Traduction> Jeu de caractères distant> UTF8
est la solution.
Mais n'oubliez pas d'aller dans Session> Paramètres par défaut et appuyez sur Enregistrer . Aucun message ne sera affiché pour confirmer le succès, mais ce sera en effet la valeur par défaut:
L'exécution de mc de cette façon (définissez locale sur fr) fonctionne pour moi:
$ LC_ALL=en mc
ce qui a fonctionné pour moi a été "Connexion, Données, Chaîne de type terminal = ansi" plus "Fenêtre, Traduction, Jeu de caractères distant = Utiliser l'encodage des polices" puis set TERM=ansi
du côté unix.
PS. N'oubliez pas de désactiver les guillemets intelligents si vous êtes obligé d'utiliser MS-Word.
Mon problème était que PuTTY est configuré en UTF-8 mais le système distant est un ISO-8859-1
europe de l'Ouest, j'ai donc changé cela sur PuTTY et tout a bien fonctionné.