ls私は通常、すべてのロケール設定を「C」に設定します。これは私が慣れている方法です。過去数十年間慣れ親しんできた方法で物事を整理するのが好きです。
LANG=Cですから、私が自分のパソコンを立ち上げて.bashrcログインしたときにウィンドウ マネージャーが存在しないことにどれほど驚き、落胆したか想像してみてください。
これは修正可能ですか?
アップデート：そうかもしれませんLC_ALL=C。2つのうちの1つが壊れています。 LC_COLLATE=Cいくつかのことは修正されますが、他のことは修正されません。
-E
Linux xxxx 3.10.0-957.10.1.el7.x86_64 #1 SMP Mon Mar 18 15:06:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
答え1
ロケール設定の影響を受けるシステム関連の機能の1つは、テキストエンコーディング、または「文字セット」、または「コードページ」 – LC_CTYPE パラメータから取得されます。多くの場合、テキスト エンコーディングは仕様によって指定されますが (例: D-Bus プロトコル文字列は常に UTF-8 です)、エンコーディングが指定されておらず、現在のシステム ロケールから取得する必要がある場所も多数あります。
特に、ファイル名多くの場合、現在のロケールのテキスト エンコーディングに従って表示されます。たとえば、Python 3 で記述されたプログラムは、プログラムが別の指定を忘れた場合、現在のロケール エンコーディングを使用します。
'C'ロケールは7ビットASCIIテキストエンコーディング（ANSI_X3.4-1968）を意味しており、多くのプログラム（一般的にCで書かれたもの）がこれを任意の8ビット値を許可すると解釈する一方で、より厳密な解釈をするプログラムも多くあることが問題の一部である可能性があります。拒否する127 を超える値 (つまり、非 ASCII) は無効です。ファイル名、構成パラメータ、またはその他のテキスト ファイルによってデコード エラーが発生している可能性があります。
実際、この時点では、ASCII テキスト エンコーディングを指定するロケールでの動作を完全に拒否するプログラムさえあります。その中には UTF-8 を明示的に必要とするもの (gnome-terminal など) もあれば、8 ビット エンコーディングを必要とするものもあります。
ディストリビューションが libc に「C.UTF-8」パッチを適用する場合は、それを使用します。
LANG=C.UTF-8
そうでない場合は、次のいずれかを使用します。
LANG=en_US.UTF-8 LC_TIME=C LC_COLLATE=C LC_MESSAGES=C
言語=C LC_CTYPE=en_US.UTF-8
（現在の環境変数に応じてどのコードページが有効になっているかを確認するには、次のコマンドを実行しますlocale charmap。どちらの場合もUTF-8と表示されます。3番目のオプションを選択した場合は、$LANGを直接参照して呼び出すのではなく、バグのあるプログラムに注意してください。nl_langinfo(コードセット)そうあるべきです。