Блог

Заранее извините за затянутый вопрос.

Мы унаследовали большой ASP.NET приложение, написанное на ASP.NET это сильно локализовано на несколько языков. В разных точках нашего приложения у нас есть код на стороне сервера (в VB.NET ), который сравнивает две строки, которые потенциально находятся в юникоде.

Мы заметили ряд различий между приложением, которое отлично работает в нашей среде тестирования и разработки, но вызывает проблемы в нашей производственной среде. Все среды — .NET 4.0 SP1 и SQL 2008 R2. Среды действительно различаются по ОС (работает в Win 2008 Svr, IIS 7, но не в Win 2003 Svr, IIS 6). Мы сравнили .СЕТЕВЫЕ версии и пакеты обновления в этих средах подтвердили, что наши SQL-серверы идентичны и все параметры сортировки совпадают на уровне сервера и базы данных, проверили соответствие всего развернутого кода в наших средах и сделали все возможное, чтобы иным образом определить, почему мы замечаем разницу ниже. Мы также убедились, что оба сайта работают под одной и той же версией .NET Framework и базовыми настройками AppPool.

Некоторые из различий заключаются в:

Это устаревшее приложение использует VB.NET Метод CType в ряде мест для преобразования того, что в конечном итоге является строкой, в целое число. Например, CType(strData, целое число). Во всех средах разработки и тестирования это работает нормально, но в рабочей среде мы получаем исключения в этой строке и методично преобразуем ее в Int32.Parse(strData, Integer). Мы не понимаем, почему разница в средах с этой строкой кода. Если это не вызывает исключения ни на одном компьютере разработчика или в нашей тестовой среде, на что мы могли бы обратить внимание, чтобы обеспечить соблюдение этого ограничения в рабочей среде? Генерируемое исключение представляет собой «Недопустимое приведение от «3» к целому числу», что имеет смысл, но мы не понимаем, что может привести к тому, что некоторые среды разрешат это приведение, а другие выдадут исключение.

Значительно более важное различие между средами заключается в сравнении строк Unicode. У нас есть несколько мест, где мы сравниваем строки на китайском или других азиатских языках, основанных на символах. Мы знаем, что эти строки равны, и обе загружены из одной и той же точки в базе данных. Эти сравнения хороши (и приводят к true) во всех средах, кроме злополучной production. Мы перепробовали несколько способов сравнения («=», Compare w / InvariantCulture и т.д.) И все еще не можем привести наши соответствующие строки в соответствие. Мы подтвердили, что на сервере установлены восточноазиатские языки, и мы можем видеть их правильно при управлении сервером. Если у нас есть ASP.NET выпадающий список с китайским словом в качестве значения, и мы устанавливаем cboDropdown.Выбрано значение, точно совпадающее с тем же китайским словом, выпадающий список не распознает это совпадение. Все эти сравнения и использование сравнений в юникоде отлично работают во всех других средах.

Я знаю, что это длинный вопрос, но есть ли у кого-нибудь идеи о том, какие настройки или различия в среде могут привести к тому, что наше приложение будет вести себя по-разному в одной среде, в то время как в других оно работает очень эффективно? Почему сравнение одних и тех же строк может так сильно отличаться?

Языки зависят также от операционной системы. особенно китайская система Unicode, упрощающая китайский. Если вы хотите использовать языки в Юникоде. Я рекомендую не просто использовать систему «a» Unicode, как это продвигает VS, system.text.encoding.unicode Используйте языковую таблицу Language table, подобную

 System.Text.Encoding.GetEncoding(936)
  

Возможно, это также может быть интересно в этом случае, кодируя MSDN и поддерживаемые кодовые страницы

С уважением