Unterschiede zwischen en_US.utf8 und en

Ich hatte eine schreckliche Zeit damit, zsh dazu zu bringen, gut mit Debian Jessie zu spielen, und bin zu dem Schluss gekommen, dass meine Probleme alle vom Gebietsschema meines Systems herrühren. Laufen locale, verstehe ich

LANG=en_US.utf8
LANGUAGE=
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

/etc/default/localeenthält jedoch LANG=en_US.UTF-8wie /etc/environment, und meine /etc/locale.genDatei hat nur en_US.UTF-8 UTF-8unkommentiert.

Warum localemeldet sich etwas (subtil) anders als scheinbar jede andere Option auf meinem System, und
Wie konfiguriere (behebe) ich Dinge, um "en_US.UTF-8" für jede LC-Option zu geben, wenn ich sie ausführe locale?

environment-variables utf-8 locale

— Connor Glosser
quelle

Der 'richtige' Name ist UTF-8. Linux glibc normalisiert jedoch intern den Codierungsnamen, indem es ihn in Kleinbuchstaben konvertiert und die meisten Sonderzeichen entfernt, sodass beide Varianten funktionieren (solange sie nicht auf BSD-Systeme übertragen werden).

Meistens .utf8stammt das Suffix in $ LANG von GNOME. afaik, dies wurde in 3.18 behoben.

Aber wie oben gesagt, beide utf8und UTF-8funktionieren unter Linux glibc gleich - das Problem kommt von woanders her. Da Sie nicht geschrieben haben, wo das Problem liegt , finden Sie hier eine allgemeine Checkliste:

Zeigt locale -a(verfügbare Gebietsschemas) überhaupt eine der beiden Varianten an? Dh haben Sie erzeugt (mit locale-gen) dem locales nach locale.gen Bearbeitung?
Hat die Umgebung des Terminalemulators dieselben Gebietsschemaeinstellungen? Verwenden Sie cat /proc/$(pidof xterm)/environ | tr \\0 \\ndiese Option , um die Umgebung eines anderen Prozesses zu überprüfen.

(Häufig versuchen Benutzer, Gebietsschema-Envvars aus ihren ~/.bashrcoder ähnlichen Dateien festzulegen , aber Umgebungsvariablen verbreiten sich nicht "nach oben", daher das Endergebnis.)
Was gibt printf '\xe2\x99\xa5'aus? Wenn ein Kästchen oder ein Fragezeichen angezeigt wird, bedeutet dies, dass die Schriftart nicht das erforderliche Zeichen enthält. Wenn drei Garbage-Zeichen angezeigt werden, bedeutet dies, dass Ihr Terminal nicht über das richtige $ LANG verfügt (oder UTF-8 einfach nicht unterstützt).

— user1686
quelle

Ahh ok! Vielen Dank! Das beleuchtet die Dinge für mich ein bisschen mehr. Das Problem, das dies auslöste, war ein Problem mit zsh, das Box-Zeichen nicht richtig renderte. Ich sehe stattdessen nur eine massive Folge von Ersatzzeichen. Beim Ausführen werden locale -anur die Kleinbuchstabenvarianten angezeigt, auch nachdem alles explizit neu generiert wurde. Der Terminalemulator hat die Einstellungen, die ich erwarten würde (dh en_US.UTF-8), und die Ausgabe von printf zeigt mir ein kleines Herz.

— Connor Glosser

Das klingt eher so, als ob die Quelle dieser Box-Zeichen-Zeichen nicht UTF-8-codiert ist (vielleicht wurde Ihr ~ / .zshrc in cp437 gespeichert?). Testen Sie den Terminal-Emulator direkt mit printf '┌┘'und printf '\xe2\x94\x8c\xe2\x94\x98\n'oder cateiner Demo-Datei .

— user1686

Ich habe versucht, mein ~ / .zshrc zu entfernen und die entsprechenden Optionen ( prompt adam2 8bit) direkt an der Eingabeaufforderung festzulegen , um Probleme mit der Codierung einer Einstellungsdatei zu vermeiden, aber ich habe immer noch das gleiche Problem. Was besonders seltsam ist, weil catdie Demo-Datei perfekt gerendert wurde - sogar die Box-Zeichen am Ende der Datei!

— Connor Glosser

Unterschiede zwischen en_US.utf8 und en_US.UTF-8?