【发布时间】：2011-02-05 02:47:39
【问题描述】：
假设您要将用户偏好的语言环境存储在数据库中，您将使用哪个值？
en_US 或 en-US
它们是两个标准，但您更喜欢将哪一个用作您自己的应用程序的一部分？
更新：似乎很多网站都使用破折号而不是下划线，例如
http://zh.wikipedia.org/zh-tw http://www.google.com.hk/search?hl=zh-TW
【问题讨论】：
标签： java localization locale
【发布时间】：2011-02-05 02:47:39
【问题描述】：
我很确定“-”是标准。如果您在某处看到“_”，则可能是某些人想出的使其成为有效标识符的东西。
为了正确起见，我个人会选择“-”。
【讨论】：
-
是的，“-”是标准，即使我使用Java，我也会遵循标准。 (w3.org/TR/html401/struct/dirlang.html)
-
@Howard 嗯，每次实例化
Locale对象时，您都需要en_US格式的语言环境名称。 （对于货币格式、日期格式等）以en-US格式存储数据并在每次需要使用存储的数据时用下划线替换破折号绝对工作，但它可能更明智（当然更简单）以应用程序实际使用的格式存储语言环境名称... -
@dkarp 使用 Locale#toLanguageTag() 和 Locale#forLanguageTag() 可以解决问题（不过在 JDK 1.7 中）。
-
仅供参考，在我的基于 Spring 的 Web 应用程序 en_US 中，它的开发人员正在使用它，正如 dkarp 在他的帖子中提到的那样......
-
我在python中使用
{% set currency = "USD" %}{% set format = "en_US" %}试图找出它是否正确。
如果您使用 Java，不妨使用Java locale format (en_US)。
BCP 47 文档实际上确实指定了en-US 格式，它与 Java 风格的语言环境名称一样常见，甚至更常见。但在实践中，您会看到很多带有下划线的表格。例如，Java 和 most POSIX-type platforms 都使用下划线作为语言/地区分隔符。
因此，任何一种选择都不会出错。但鉴于您使用 Java 编写并且可能针对 Unix 平台，en_US 可能是要走的路。
【讨论】：
-
是的，但他的问题上有一个
java标签。如果您愿意，请查看我的答案中的链接... -
嗯，好吧，至少您对 *nix 平台是正确的。忘记那些了。
-
@Matti 您对 BCP 47 文档（我指出）完全正确，但对于提问者的需要，Java 风格的语言环境格式可能更合适。
-
如图所示，有很多变体，但官方标准是下划线。当调用具有不同约定的框架时，您会遇到需要知道需要转换的编码器的“错误”。建议使用您调用的框架的约定。当您调用另一个框架时，请提供执行转换的“代理”。为什么？它消除了知道被调用框架使用不同约定的需要。贡献者只会“看到”一种约定，使用该约定会避免这种做法。
-
Java 不支持解析该格式，只是将其转储出来，并且 javadoc 将其描述为用于调试目的，而不是用于符合标准的存储。
在 Java 7 中，有一个新方法 Locale.forLanguageTag(String)，它假定连字符作为分隔符。我认为这是规范的。
查看Locale 的文档了解更多信息。
【讨论】：
zh_CN。 This 是一本非常有用的读物。
【讨论】：
-
是的，对不起，因为文章不见了，所以投了反对票。
-
@ebruchez 而不是投反对票，您可以发表评论，我可以更新链接或删除答案。这是一个2岁半的答案。不过还是谢谢你。
-
如果链接断开，它应该被否决，你不是说吗？不能保证你会回来编辑它。现在重新投票。
-
澄清一下：否决票不是对您最初的评论或您的能力的批评，而是关于该特定点的答案的价值。如果不立即投反对票，我将不得不 1. 添加评论 2. 给自己添加一个提醒，如果没有得到解决，以后对答案投反对票。并且已经有 1 条评论指出链接不正确。
我认为en-US 根本不是 Java 的标准。 （如果你在某个地方看到它，你可以添加一个链接）。
所以只需使用en_US。
【讨论】：
-
如图所示，有很多变体，但官方标准是下划线。当调用具有不同约定的框架时，您会遇到需要知道需要转换的编码器的“错误”。建议使用您调用的框架的约定。当您调用另一个框架时，请提供执行转换的“代理”。为什么？它消除了知道被调用框架使用不同约定的需要。贡献者只会“看到”一种约定，使用该约定可以避免错误。