我通常將所有區域設定為“C”。我已經習慣了。我喜歡ls按照過去幾十年來習慣的方式對事情進行排序。
LANG=C因此，想像一下當我設定時我的驚訝和沮喪.bashrc，現在當我登入時，沒有視窗管理器。
這可以修復嗎？
更新：有可能LC_ALL=C。兩者之一正在打破它。 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
與受區域設定影響的系統相關的功能之一是文字編碼、或「字元集」或「代碼頁」－取自 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-位元編碼。
如果您的發行版將「C.UTF-8」補丁套用至 libc，請使用它：
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。如果您選擇第三個選項，請注意直接查看 $LANG 而不是調用的錯誤程序nl_langinfo(代碼集)正如他們應該做的那樣。