提前抱歉这个冗长的问题。
我们继承了一个用ASP.NET编写的大型ASP.NET应用程序，该应用程序大量本地化为多种语言。在我们的应用程序的各个点上，我们有服务器端代码（在VB.NET中），它比较两个可能是unicode的字符串。
我们注意到在我们的测试和开发环境中运行良好但在我们的生产环境中导致问题的应用程序之间存在许多差异。所有环境都是.NET 4.0 SP1和SQL 2008 R2。这些环境在操作系统上有所不同（适用于Win 2008 Svr，IIS 7，但不适用于Win 2003 Svr，IIS 6）。我们比较了这些环境中的.NET版本和Service Pack，验证了我们的SQL服务器是否完全相同，所有整理设置在服务器和数据库级别匹配，验证了我们环境之间所有已部署的代码匹配，并尽力确定我们为什么这样做注意到下面的区别。我们还验证了这两个站点都在相同的.NET框架版本和基本的AppPool设置下运行。
有些不同之处是：
这个遗留应用程序在许多地方使用VB.NET CType方法将最终的字符串转换为整数。例如，CType（strData，Integer）。在所有开发和测试环境中，这都可以正常工作，但在生产中我们在这一行上获得异常，并有条不紊地将其转换为Int32.Parse（strData，Integer）。我们很困惑为什么环境与这行代码的区别。如果它不会在任何开发人员机器或我们的测试环境中导致异常，那么我们可能会在生产中强制执行此约束？引发的异常是“从3”到“整数”的“无效转换”，这是有道理的但我们不明白是什么会导致某些环境允许此转换和其他人抛出异常。
环境之间明显更重要的区别在于Unicode字符串的比较。我们有很多地方比较中文或其他亚洲字符语言的字符串。我们知道这些字符串是相同的，并且都是从数据库中的同一点加载的。除命运多产的生产外，这些比较在所有环境中都很好（并且结果是真实的）。我们已经尝试了许多比较方法（“=”，比较w / InvariantCulture等），仍然无法获得匹配的匹配字符串。我们已确认服务器已安装东亚语言，我们可以在控制服务器时正确查看它们。如果我们有一个带有中文单词的ASP.NET下拉列表，并且我们将cboDropdown.SelectedValue设置为相同中文单词的完全匹配，则下拉列表无法识别此匹配项。所有这些比较和unicode比较的使用在所有其他环境中都能正常工作。
我知道这是一个很长的问题，但是有没有人知道什么设置或环境差异会导致我们的应用程序在一个环境中表现得如此不同而在其他环境中运行非常有效？为什么相同的字符串比较差异如此之大？
答案 0 :(得分：0)
语言也取决于操作系统。尤其是中文unicode系统Simplified chinese。如果你想使用unicode Languages
。我建议不要只使用VS这样的“a”unicode系统system.text.encoding.unicode
使用语言表Language table，如
System.Text.Encoding.GetEncoding(936)
在这种情况下Encoding MSDN和Supported code pages
也许也会引起人们的兴趣此致