asp.net - 服务器与开发环境上的 Unicode 字符串比较和 CType 差异

Question

对于这个冗长的问题，提前表示歉意。

我们继承了一个用 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 版本和服务包，验证了我们的 SQL 服务器是相同的，并且所有排序规则设置在服务器和数据库级别上都匹配，验证了我们的环境之间所有已部署的代码匹配，并尽了最大努力来确定我们的原因注意到下面的差异。我们还验证了两个站点都在相同的 .NET 框架版本和基本 AppPool 设置下运行。

一些差异是:

此遗留应用程序在许多地方使用 VB.NET CType 方法将最终的字符串转换为整数。例如，CType(strData, Integer)。在所有开发和测试环境中，这都工作正常，但在生产中，我们在该行上遇到异常，并有条不紊地将其转换为 Int32.Parse(strData, Integer)。我们很困惑为什么这行代码的环境不同。如果它不会在任何开发人员计算机或我们的测试环境中引起异常，那么我们可能会寻找什么来在生产中强制执行此约束？抛出的异常是“从“3”到整数的无效转换”，这是有道理的，但我们不明白什么会导致某些环境允许此转换而其他环境抛出异常。

环境之间更重要的区别在于 Unicode 字符串的比较。我们有很多地方可以比较中文或其他基于亚洲字符的语言的字符串。我们知道这些字符串是相等的，并且都是从数据库中的同一点加载的。除了不幸的生产环境之外，这些比较在所有环境中都很好(并且结果为真)。我们尝试了多种比较方法(“=”、与 InvariantCulture 比较等)，但仍然无法使我们的匹配字符串匹配。我们已经确认服务器安装了东亚语言，并且在控制服务器时可以正确看到它们。如果我们有一个以中文单词作为值的 ASP.NET 下拉列表，并且我们将 cboDropdown.SelectedValue 设置为同一个中文单词的精确匹配，则下拉列表无法识别此匹配。所有这些比较和 unicode 比较的使用在所有其他环境中都可以正常工作。

我知道这是一个很长的问题，但有谁知道什么设置或环境差异会导致我们的应用程序在一个环境中表现如此不同，而在其他环境中运行得非常有效？为什么相同的字符串比较会有如此大的差异？

Answer 1

语言还取决于操作系统。特别是中文unicode系统Simplified chinese 。如果你想使用unicode Languages。我建议不要只使用像 VS 那样使用 system.text.encoding.unicode 进行推广的“a”unicode 系统使用语言表Language table喜欢

System.Text.Encoding.GetEncoding(936)

也许对这种情况也可能感兴趣 Encoding MSDN和 Supported code pages

问候