python - 有哪些策略可确保在所有区域设置中正确处理所有区域设置感知操作？

Question

出于某种需要，我在开发软件时将我的语言环境设置为“C”或“en_US”。很难使用不同的语言环境，因为我只会说一种语言，甚至连流利程度都差得远。

因此，我经常忽略不同区域设置可能带来的行为差异。不出所料，忽略这些差异有时会导致错误，只有某些不幸的用户使用不同的区域设置才能发现这些错误。在特别糟糕的情况下，该用户甚至可能不会与我共享一种语言，这使得错误报告过程成为一个具有挑战性的过程。而且，重要的是，我的很多软件都是库的形式；虽然几乎没有一个设置区域设置，但它可以与另一个库结合使用，或者在确实设置区域设置的应用程序中使用 - 生成我自己从未体验过的行为。

更具体一点，我想到的错误类型不是缺少文本本地化或代码中使用这些本地化的错误。相反，我指的是当使用该 API 的代码没有预料到这种更改的可能性(例如，在土耳其语言环境中，toupper 不会将“i”更改为“I”——对于试图与另一台主机通信特定网络协议(protocol)的网络服务器而言，这可能是一个问题)。

我维护的软件中的此类错误的一些示例:

• AttributeError in a Turkish locale
• imap relies on a C locale for date formatting
• Fix for locale-dependant date formatting in imap and conch

过去，我用来处理这个问题的一种方法是编写回归测试，将语言环境显式更改为已知代码不起作用的语言环境，运行代码，验证正确的行为，然后恢复原始状态语言环境。这工作得很好，但只有在有人报告错误之后，它才覆盖代码库的一小部分区域。

另一种似乎可行的方法是设置持续集成系统 (CIS)，以便在具有不同区域设置的环境中运行全套测试。这在某种程度上改善了这种情况，通过在一个备用语言环境中提供与测试套件通常提供的覆盖范围一样多的覆盖范围。另一个缺点是有很多很多地方，每个地方都可能导致不同的问题。在实践中，一个语言环境可能只有十几种不同的方式来破坏程序，但是拥有数十种额外的测试配置会增加资源负担(特别是对于一个已经通过在不同平台上针对不同库进行测试来扩展其资源限制的项目版本等)。

我想到的另一种方法是使用(可能首先创建)一个新的语言环境，它在各个方面都与“C”语言环境完全不同——有不同的大小写映射，使用不同的千位分隔符，格式日期不同等。此语言环境可以与一个额外的 CIS 配置一起使用，并希望依靠它来捕获代码中可能由任何语言环境触发的任何错误。

这样的测试区域是否已经存在？这种测试语言环境兼容性的想法是否存在缺陷？

人们还采用了哪些其他语言环境测试方法？

我主要对 POSIX 语言环境感兴趣，因为这些是我所知道的。但是，我知道 Windows 也有一些类似的功能，因此额外的信息(可能包含有关这些功能如何工作的更多背景信息)也可能有用。

Answer 1

我将审核您的代码是否错误使用了 toupper 等函数。在 C 语言环境模型下，此类函数应被视为仅对语言环境语言的自然语言文本进行操作。对于任何处理潜在多语言文本的应用程序，这意味着诸如 tolower 之类的函数 根本不应该使用。

如果您的目标是 POSIX，由于 uselocale 函数，您有更多的灵 active ，这使得在单个线程中临时覆盖区域设置成为可能(即不会弄乱全局状态你的程序)。然后，您可以全局保留 C 语言环境，并使用 tolower 等用于 ASCII/面向机器的文本(如配置文件等)，并且仅 uselocale 用于用户选择的语言环境使用来自所述语言环境的自然语言文本。

否则(如果您需要更高级的话，也许即使那样)，我认为最好的解决方案是完全放弃像 tolower 这样的功能，并为配置文本等编写您自己的 ASCII 版本，并为自然语言文本使用强大的 Unicode 感知库。

我尚未触及的一个棘手问题是与 snprintf 和 strtod 等函数相关的小数点分隔符。在某些语言环境中将其更改为 , 而不是 . 可能会破坏您使用 C 库解析文件的能力。我的首选解决方案是永远不要设置 LC_NUMERIC 语言环境。 (而且我是一名数学家，所以我倾向于认为数字应该是通用的，不受文化习俗的约束。)根据您的应用程序，真正需要的唯一区域设置类别可能只是 LC_CTYPE、 LC_COLLATE 和 LC_MESSAGES。 LC_MONETARY 和 LC_TIME 也经常有用。