【问题标题】:Consequences of setting `LC_ALL=C.UTF-8` and `LANG=C.UTF-8`设置 `LC_ALL=C.UTF-8` 和 `LANG=C.UTF-8` 的后果
【发布时间】:2019-08-30 05:22:43
【问题描述】:

为了修复 the bug 并快速打包 Python 应用程序,我准备添加以下代码:

# I don't know what I am doing
export LC_ALL=C.UTF-8
export LANG=C.UTF-8

lot of text 似乎解释了 LC_ALL=C 的作用(但不是 LC_ALL=C.UTF-8LANG=C.UTF-8)和 big text 解释了错误和 Python 行为。但它们都不适合我的小脑袋。通常我喜欢把脑袋绕在血腥的技术细节上,但最近是time pressure makes me rather ignorant

我只想知道This system supports the C.UTF-8 locale这句话是什么意思,如果我设置这些变量切换到它会发生什么? (我猜是通过设置那些环境变量来实现的)

【问题讨论】:

  • 在 Python 3 中,sys.std* 的编码是在运行时通过一些涉及 env 变量(如 LC_ALL)的启发式方法设置的。如果我正确理解您的情况,您可以通过检查 locale.getpreferredencoding() 的值来检查这是否有效。它应该类似于“UTF-8”。
  • 注意:您应该检查您的语言环境是否支持 C-UTF8。现在它已经过时了,C 在许多系统中都是 UTF8。在某些系统上,语言环境是“UTF8”,而在某些系统上是“UTF-8”(python 支持这两种语法,但不支持语言环境实用程序。locale -a 显示您安装了哪个本地环境。UTF-8 语言环境会破坏很多实用程序有非 UTF-8 文本(所以无效序列)

标签: utf-8 environment


【解决方案1】:

“C”语言环境关闭所有国际化,状态/错误消息为英文,字符和字节之间没有区别,按原始字节值排序。未定义 ASCII 范围外字节的含义。

对于完全使用字节工作的程序来说,这几乎可以正常工作,它可以读取这些字节,处理它们并再次输出它们,而无需关心 0x80-0xFF 范围内的字节值究竟意味着什么。

但是它给 python3 的“将所有内容转换为 unicode”方法带来了很大的问题。如果您不知道 0x80-0xFF 范围内的字节值是什么意思,那么您就无法正确地将它们转换为 Unicode。 Python3 决定在这种情况下引发错误,而不是做出可能不正确的假设。

不过,在广泛分布的脚本中使用语言区域设置也是有问题的。第一个问题是您不能确定任何特定语言的区域设置将出现在您的脚本将运行的每个系统上。其次,特定于语言的语言环境可能具有脚本编写者认为不受欢迎的其他设置。

C.UTF-8 保留了 C 语言环境的大部分特征,但指定了 UTF-8 编码。

【讨论】:

    猜你喜欢
    • 2019-09-04
    • 1970-01-01
    • 2016-03-15
    • 2010-09-25
    • 2023-01-26
    • 2021-06-20
    • 2013-05-06
    • 2015-08-09
    • 1970-01-01
    相关资源
    最近更新 更多