CultureInfo类提供了两种创建方式：
MSDN文档确实略有不同，提到构造函数的一些“Windows文化”。但这真的很重要吗？
我应该更喜欢两个中的一个吗？
注意：如果重要的话，我使用的是.NET 3.5版本，我想这样使用它：
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(culture);
Thread.CurrentThread.CurrentUICulture = new CultureInfo(culture);
无法创建文化信息时，工厂方法具有后备。
因此，如果您使用像'en-XX'这样的特定文化，则无法创建文化信息实例，将抛出异常并使用中性文化'en'重试将成功。
低于工厂方法的source
public static CultureInfo CreateSpecificCulture(string name)
{
CultureInfo info;
try
{
info = new CultureInfo(name);
}
catch (ArgumentException)
{
info = null;
for (int i = 0; i < name.Length; i++)
{
if ('-' == name[i])
{
try
{
info = new CultureInfo(name.Substring(0, i));
break;
}
catch (ArgumentException)
{
throw;
}
}
}
if (info == null)
{
throw;
}
}
if (!info.IsNeutralCulture)
{
return info;
}
return new CultureInfo(info.m_cultureData.SSPECIFICCULTURE);
}
所以我更喜欢工厂方法。
这个线程得到了回答，但我发现了CreateSpecificCulture API的一个独特发现，有时可能不那么明显。所以我认为这个帖子对我的发现很合适。我花了几天时间考虑分享我的经验，如果它可以为其他人节省几个小时或几天。
在传递API时，只传递文化名称，如pt（用于葡萄牙语）或de（用于德语），此API返回与语言环境相对应的特定区域性，该区域性称为该区域性的默认区域设置。现在这个地方可能不会那么明显，就像我被困住的地方一样。对于德国人来说，de-DE看起来很明显，这在德国是德语。对于意大利人来说，it-IT看起来很明显，意大利语是意大利语。
同样，pt-PT在葡萄牙语中看起来很明显。不幸的是，这种情况并非如此。基于不确定究竟是什么原因（可能是人口，原籍国，国家语言等），有一种全球标准化，当您尝试从文化ID创建特定文化时，将根据该标准化确定给定文化的默认区域设置。 （在这种情况下pt）。 Microsoft已在以下链接中记录了整个列表：
http://msdn.microsoft.com/en-us/goglobal/bb896001.aspx
如果您想知道哪个是给定文化或语言的默认国家/地区语言环境，只需匹配上述链接中的最后一列（语言名称缩写）代码。
对于葡萄牙语，不变文化“葡萄牙语”的语言名称缩写与作为PTB的“葡萄牙语（巴西）”匹配。葡萄牙语（葡萄牙）有不同的代码PTG。因此，在这种情况下，葡萄牙语（巴西）是葡萄牙语的默认语言环境。
如果您的应用程序逻辑或要求以任何方式依赖于此API的此行为，则必须谨慎。这种行为在基于Web的应用程序中变得更加重要，因为市场中的所有浏览器也遵循这些准则，并在您查看多语言网站的本地化版本时在http请求标头中发送适当的信息。
我仍然在寻找原因，但这背后的因素是将特定国家设置为任何文化的默认语言环境，这在葡萄牙语中听起来并不那么明显。欢迎任何信息或评论。
工厂方法和构造之间还有另一个明显的区别：构造函数提供了一个额外的可选布尔值，其默认设置为true。
如果你真的需要一个>“plain”<cultureinfo，你需要将这个布尔设置为false，因为：如果你要求一个特定的文化（例如de-DE）没有“布尔设置为假”，你将永远得到一个文化-setting，可能有意想不到的设置，具体取决于用户如何通过Control-Panel更改此文化。
工厂方法不支持这个布尔!!!
关于何时需要此布尔值的最后两个想法是：
plain de-DE - 文化，以确保，特殊的控制面板设置不会干扰。