Es kann einige Auswirkungen geben, da sie sich in Sortierreihenfolgen, Beziehungen zwischen Groß- und Kleinbuchstaben, Sortierreihenfolgen, Tausendertrennzeichen, Standardwährungssymbol und mehr unterscheiden.
C.utf8 =POSIX-standardkonformes Standardgebietsschema. Es sind nur strikte ASCII-Zeichen gültig, die erweitert wurden, um die grundlegende Verwendung von UTF-8
zu ermöglichenen_US.utf8 =UTF-8-Gebietsschema für amerikanisches Englisch.
Ich bin mir zwar nicht sicher, auf welche spezifischen Auswirkungen Sie stoßen könnten, aber ich glaube, Sie können das Gebietsschema und die Codierung bei Bedarf in Ihrer Anwendung festlegen.
Hier sind einige Gründe, warum ich LC_TIME=C.UTF-8 hinzugefügt habe in /etc/default/locale , falls es jemandem hilft:
Es bietet eine 24-Stunden-Uhr anstelle von AM/PM in Firefox für HTML5 input type=time (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time) und verwendet a datepicker im Format DD/MM/YYYY statt MM/DD/YYYY für HTML5 input type=date (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date).
Es ermöglicht die Verwendung des internationalen Datumsformats JJJJ-MM-TT (ISO 8601) mit einer 24-Stunden-Uhr beim Beantworten von E-Mails in Thunberbird.
Bisher war dies mit LC_TIME=en_DK.UTF-8 möglich (http://kb.mozillazine.org/Date_display_format), aber es gibt derzeit einen Fehler und es funktioniert nicht mehr (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c155).
Edit:Jetzt noch die LC_TIME=C.UTF-8 Workaround funktioniert nicht für Thunberbird (https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c197), aber mindestens en_IE.UTF-8 bietet das europäische Datumsformat TT/MM/JJJJ anstelle von MM/TT/JJJJ.
Im Allgemeinen C ist für Computer, en_US ist für Menschen in den USA, die Englisch sprechen (und andere Menschen, die das gleiche Verhalten wünschen).
Die für Computer bedeutet, dass die Zeichenfolgen irgendwann standardisierter sind (aber immer noch in Englisch), sodass eine Ausgabe eines Programms von einem anderen Programm gelesen werden kann. Mit en_US , Streicher könnten verbessert werden, alphabetische Reihenfolge könnte verbessert werden (vielleicht durch neue Regeln der Chicagoer Stilregeln usw.). Also benutzerfreundlicher, aber möglicherweise weniger stabil. Hinweis:Gebietsschemas dienen nicht nur der Übersetzung von Zeichenfolgen, sondern auch der Sortierung (alphabetische Reihenfolge, Zahlen (z. B. Tausendertrennzeichen), Währung (ich denke, es ist sicher vorherzusagen, dass $ und 2 Dezimalstellen übrig bleiben), Monaten, Wochentagen usw.
In Ihrem Fall ist es nur die UTF-8-Version beider Gebietsschemata.
Im Allgemeinen sollte es keine Rolle spielen. Normalerweise bevorzuge ich en_US.UTF-8, aber normalerweise spielt es keine Rolle, und in Ihrem Fall (Server-App) sollten nur Protokoll- und Fehlermeldungen geändert werden (wenn Sie locale.setlocale() verwenden . Sie sollten Client-Gebietsschemas in Ihrer App handhaben. Programme, die von anderen Programmen lesen, sollten C setzen vor dem Öffnen der Pfeife, also sollte es eigentlich egal sein.
Wie Sie sehen, spielt es wahrscheinlich keine Rolle. Sie können auch POSIX verwenden Gebietsschema, auch in Debian definieren. Die Liste der installierten Locales erhalten Sie mit locale -a .
Hinweis:Die Mikrooptimierung schreibt C vor /C.UTF-8 Gebietsschema:keine Übersetzung von Dateien (gettext ) und einfache Regeln zur Sortierung und Zahlenformatierung, aber dies sollte nur auf der Serverseite sichtbar sein.