【问题标题】:When should I specify CurrentCulture or InvariantCulture and when should I leave it unspecified?什么时候应该指定 CurrentCulture 或 InvariantCulture,什么时候应该不指定它?
【发布时间】:2011-03-14 23:14:36
【问题描述】:

指定 CurrentCulture 或 InvariantCulture 而根本不指定文化的最佳做法是什么?

根据我的阅读,例如,如果您要进行序列化,则需要 InvariantCulture 作为指定数据值的规范表示的一种方式。这是基于文化的字符串操作的相对较小百分比。

我发现它很长,很冗长,而且很丑,每次我都指定它,比如说:

var greeting = string.Format(CultureInfo.CurrentCulture, "Hello ", userName); 

但是,我的团队最近启用了 FxCop,现在一直在推动在任何地方都使用 CultureInfo。结合简洁性、可读性和功能性的最佳技术是什么?

一些不错的阅读材料:

【问题讨论】:

    标签: c# globalization culture cultureinfo currentculture


    【解决方案1】:

    这里有一个内在的权衡。

    当您在程序内部执行任何操作时,至少需要指定 CultureInfo 以使用 InvariantCulture。例如,将其与序列化一起使用会强制数据表示始终相同,因此您不必担心内部数据格式的国际化问题。

    话虽如此,在任何地方指定它都有一些优势 - 主要是在强制您确保正确处理它方面。内部程序工作与 UI 工作需要指定不同的文化(前提是您想要正确本地化您的应用程序)。因此,复杂的程序往往需要在任何地方都指定这一点,因为保留“默认”充其量是危险的,并且随着时间的推移往往会引入错误。

    但是,正如您所注意到的,指定这一点往往会增加代码的大小,并可能降低可读性。这导致了权衡 - 通过更短的代码实现可读性和可维护性与通过在任何地方都更加明确来进行适当的国际化和本地化以及可维护性。

    在我看来,这里没有“正确”的答案——这实际上取决于您的应用程序。如果您的应用程序完全是关于演示的,并且没有进行大量数据操作,尤其是没有任何类型的自我管理文件存储,那么设置当前文化(和 ui 文化)一次可能就可以了。我发现更复杂的应用程序往往不能以这种方式正常工作,但是,在这种情况下,FxCop 建议在任何地方指定它似乎更有吸引力。

    【讨论】:

    • @Reed Copsey:我还发现将它作为 FxCop 反射添加到任何地方都会产生错误——我曾多次看到指定了错误区域性选项的实例。这显然只是一个教育问题,但是当像 FxCop 这样的东西告诉你做某事但你不一定明白为什么时,这种情况很常见。
    • @Scott:是的。但是编程中的一切都是这种情况——如果你要使用它,你需要理解它,否则它会咬你的。进行本地化的唯一明智方法是在第一次编写代码时考虑它 - 对已完成的产品进行本地化是最糟糕的工作之一,而且比从一开始就考虑成本要高出一个数量级。
    • 我不同意。我会把文化放在我班级的所有 ToString() 中吗?我认为逻辑和对象应该不了解文化。
    • 顺便说一句,绕过 FXCop 警告并保持代码可读性的一种方法是编写自己的包装方法来隐藏 CultureInfo。即编写一个始终使用 UI 文化的 FormatStringForUI()。这会清理您的代码,并为程序员提供更简单、更清晰的选择:(例如 UI 或序列化?)(@onof: 完全是 :-)
    • @onof:我通常有一项服务来提供文化,并在那里指定它。然而,这里真的是一个规模问题——非常大的、国际化的项目需要非常小心才能使文化“正确”——将其放在任何地方往往会有所帮助。
    【解决方案2】:

    默认值已经是由 Windows 初始化的当前区域性。因此,明确使用 CultureInfo.CurrentCulture 只是浪费时间。任何体面的序列化格式(包括二进制序列化和 XML 序列化)都会以文化不变的方式序列化 DateTime。

    使用非默认文化是非常危险的。线程将始终以 Windows 指定的默认区域性启动,并由用户在安装 Windows 时配置。 .NET 始终启动线程池线程,您将面临在该线程中获得与主线程不同的文化的风险。这可能会导致各种微妙的问题。就像突然不再排序的 SortedList 一样。

    【讨论】:

      猜你喜欢
      • 2014-01-20
      • 2011-03-14
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-07-16
      • 2010-09-11
      相关资源
      最近更新 更多