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

对于这个冗长的问题，我先表示歉意

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

其中一些差异是：

这个遗留应用程序在许多地方使用VB.NET CType方法将最终的字符串转换为整数。例如，CType（strData，Integer）。在所有的开发和测试环境中，这都可以正常工作，但在生产环境中，我们会在这一行中遇到异常，并且会有系统地将其转换为Int32.Parse（strData，Integer）。我们对这一行代码在环境中的差异感到困惑。如果它不会在任何开发人员的机器上或在我们的测试环境中导致异常，那么我们会寻找什么来在生产中强制执行此约束？抛出的异常是“从“3”到整数的无效转换”，这是有道理的，但我们不知道是什么导致某些环境允许此转换，而其他环境允许抛出异常

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

---

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

语言也取决于操作系统。特别是中文unicode系统。如果你想使用unicode . 我建议不要像VS那样只使用“a”unicode系统，而是使用

system.text.encoding.unicode

使用语言表，如

也许这也会对这个案子感兴趣

---

关于

我的直觉反应是调查machine.config文件，看看是否有更严格的政策正在执行。

System.Text.Encoding.GetEncoding(936)