Рекомендации по разработке приложений, готовых для мирового использования

В этом разделе описаны наилучшие практики разработки приложений, готовых к работе в международной среде.

Рекомендации по глобализации

1. Сделайте ваше приложение поддерживающим Юникод на внутреннем уровне.

2. Используйте классы, адаптированные к культурным особенностям, предоставляемые пространством имен System.Globalization, для манипуляции и форматирования данных.

   • Для сортировки используйте SortKey класс и CompareInfo класс.
   • Для сравнения строк используйте CompareInfo класс.
   • Для форматирования даты и времени используйте DateTimeFormatInfo класс.
   • Для форматирования числовых данных используйте класс NumberFormatInfo.
   • Для григорианских и не григорианских календарей используйте Calendar класс или одну из конкретных реализаций календаря.

3. Используйте настройки свойства культуры, которые предоставляет класс System.Globalization.CultureInfo, в подходящих случаях. CultureInfo.CurrentCulture Используйте свойство для задач форматирования, таких как дата и время или числовое форматирование. Используйте свойство CultureInfo.CurrentUICulture для получения ресурсов. Обратите внимание, что CurrentCultureCurrentUICulture свойства можно задать для каждого потока.

4. Позволяет приложению считывать и записывать данные из различных кодировок с помощью классов кодирования в System.Text пространстве имен. Не предполагайте данные ASCII. Предположим, что международные символы будут предоставлены в любом месте, где пользователь может вводить текст. Например, приложение должно принимать международные символы в именах серверов, каталогах, именах файлов, именах пользователей и URL-адресах.

5. При использовании UTF8Encoding класса по соображениям безопасности используйте функцию обнаружения ошибок, предлагаемую этим классом. Чтобы включить функцию обнаружения ошибок, создайте экземпляр класса с помощью конструктора, который принимает throwOnInvalidBytes параметр и задайте значение этого параметра true.

6. По возможности обработайте строки как целые строки вместо ряда отдельных символов. Это особенно важно при сортировке или поиске подстрок. Это позволит предотвратить проблемы, связанные с синтаксического анализа объединенных символов. Вы также можете работать с единицами текста, а не с одними символами с помощью System.Globalization.StringInfo класса.

7. Отображайте текст, используя классы, предоставленные пространством имен System.Drawing.

8. Для согласованности между различными операционными системами не допускайте переопределения пользовательских настроек CultureInfo. CultureInfo Используйте конструктор, который принимает useUserOverride параметр и задает для него значениеfalse.

9. Протестируйте функциональные возможности приложения в международных версиях операционной системы с помощью международных данных.

10. Если решение безопасности основано на результате операции сравнения строк или изменения регистра, используйте операцию со строками, не зависящими от культурных параметров. Эта практика гарантирует, что результат не влияет на значение CultureInfo.CurrentCulture. См. раздел "Сравнение строк, которые используют текущий язык и региональные параметры" в разделе "Рекомендации по использованию строк " для примера, демонстрирующего, как сравнение строк с учетом языка и региональных параметров может привести к несогласованным результатам.

11. Для любого элемента, используемого для обмена (например, поля в документе JSON в вызове API) или хранения, используйте CultureInfo этот параметр; кроме того, следует явно указать формат полного цикла (например, "O""o", формат даты и времени). Хотя строки формата для инвариантной культуры стабильны и вряд ли изменятся, указание конкретной строки формата помогает прояснить намерение вашего кода.

    • Для элементов даты и времени учитывайте советы и наблюдения автора Noda Time Джона Скита, который делится ценными аналитическими сведениями. Дополнительные сведения см. в статье Джон Скит: Storing UTC не является универсальным решением.

12. Данные глобализации не стабильны, и вы должны написать приложение и его тесты с учетом этого. Он обновляется несколько раз в год через каналы операционной системы хоста на всех поддерживаемых платформах. Обычно эти данные не распределяются с средой выполнения.

Рекомендации по локализации

1. Переместите все локализуемые ресурсы в отдельные DLL, предназначенные только для ресурсов. Локализуемые ресурсы включают элементы пользовательского интерфейса, такие как строки, сообщения об ошибках, диалоговые окна, меню и внедренные ресурсы объектов.

2. Не следует жестко кодировать строки или ресурсы пользовательского интерфейса.

3. Не помещайте ресурсы, которые не подлежат локализации, в DLL-библиотеки, предназначенные только для ресурсов. Это путает переводчиков.

4. Не используйте составные строки, созданные во время выполнения из сцепленных фраз. Составные строки трудно локализовать, так как они часто предполагают английский грамматический порядок, который не применяется ко всем языкам.

5. Избегайте неоднозначных конструкций, таких как "Пустая папка", где строки можно преобразовать по-разному в зависимости от грамматических ролей строковых компонентов. Например, "пустой" может быть либо глаголом, либо прилагательным, что может привести к различным переводам на таких языках, как итальянский или французский.

6. Избегайте использования изображений и значков, содержащих текст в приложении. Они дороги для локализации.

7. Оставьте достаточно пространства для увеличения длины строк в пользовательском интерфейсе. На некоторых языках фразы могут требовать 50-75 процентов больше места, чем они нуждаются в других языках.

8. Используйте класс System.Resources.ResourceManager для получения ресурсов на основе культуры.

9. Используйте Visual Studio для создания диалоговых окон Windows Forms, чтобы их можно было локализовать с помощью редактора ресурсов Windows Forms (Winres.exe). Не кодируйте диалоговые окна Windows Forms вручную.

10. Организация профессиональной локализации (перевода).

11. Полное описание создания и локализации ресурсов см. в разделе "Ресурсы" в приложениях .NET.

Рекомендации по глобализации для ASP.NET и других серверных приложений

1. Явно задайте свойства CurrentUICulture и CurrentCulture в вашем приложении. Не следует опираться на значения по умолчанию.

2. Обратите внимание, что приложения ASP.NET являются приложениями с управляемым кодом и поэтому могут использовать те же классы, что и другие приложения с управляемым кодом для получения, отображения и управления информацией на основе культуры.

3. Помните, что в ASP.NET можно указать следующие три типа кодировки:

   • requestEncoding указывает кодировку, полученную из браузера клиента.
   • responseEncoding задает кодировку для отправки в клиентский браузер. В большинстве случаев эта кодировка должна совпадать с указанной для requestEncoding.
   • fileEncoding задает кодировку по умолчанию для синтаксического анализа файлов .aspx, .asmx, и .asax.

4. Укажите значения для атрибутов requestEncoding, responseEncoding, fileEncoding, culture и uiCulture в следующих трех местах в приложении ASP.NET.

   • В разделе глобализации файла Web.config . Этот файл является внешним для приложения ASP.NET. Для получения дополнительной информации см. элемент <глобализации>.
   • В директиве страницы. Обратите внимание, что, когда приложение находится на странице, файл уже считывается. Поэтому слишком поздно указать fileEncoding и requestEncoding. Только uiCulture, cultureи responseEncoding может быть указан в директиве страницы.
   • Программно в коде приложения. Настройка может меняться для каждого запроса. Как в случае с директивой страницы, к моменту, когда код приложения достигнут, уже слишком поздно указывать fileEncoding и requestEncoding. Только uiCulture, culture и responseEncoding можно указать в коде приложения.

5. Обратите внимание, что для параметра uiCulture можно задать язык принятия браузера.

6. Для распределенных приложений обеспечьте возможность обновлений без простоя (например, для приложений Azure Container Apps), или аналогичных решений, и спланируйте ситуации, в которых может существовать несколько экземпляров приложения с различными правилами форматирования или другими культурными данными, самыми значимыми из которых являются правила часовых поясов.

   • Если развертывание приложения включает базу данных, помните, что база данных будет иметь собственные правила глобализации. В большинстве случаев следует избегать выполнения любых функций, связанных с глобализацией в базе данных.
   • Если развертывание приложения включает клиентское приложение или веб-интерфейс с помощью ресурсов глобализации клиента, предположим, что клиентские ресурсы отличаются от ресурсов, доступных вашему серверу. Рассмотрите возможность исключительно выполнения функций глобализации на клиенте.

Рекомендации по надежному тестированию

1. Чтобы сделать зависимости более явными, а тестирование — потенциально более простым и параллельным, следует учитывать явную передачу параметров, связанных с языковыми и региональными настройками, таким как CultureInfo параметры методам, которые выполняют форматирование, а также TimeZoneInfo методам, которые работают с датами и временем. При извлечении времени также следует использовать TimeProvider или аналогичный тип.

2. Для большинства тестов не следует явно проверять точные выходные данные заданной операции форматирования или точное смещение часового пояса. Форматирование и данные часового пояса могут изменяться в любое время и могут отличаться между двумя идентичными экземплярами операционной системы (и потенциально разными процессами на одном компьютере). Использование точного значения делает тесты хрупкими.

   • Как правило, проверка того, что некоторые выходные данные были получены, будет достаточно (например, непустые строки при форматировании).
   • Для некоторых элементов и форматов данных вместо этого может быть использована валидация, чтобы удостовериться, что разбор данных соответствует входному значению (обратимость преобразований). Необходимо учитывать случаи, когда поля удаляются (например, год для некоторых полей, связанных с датой), или значение усечено или округлено (например, для выходных данных с плавающей запятой).
   • Если у вас есть явные требования для проверки всех локализованных выходных данных формата, следует рассмотреть возможность создания и использования пользовательской культуры во время настройки теста. В большинстве простых случаев это можно сделать, создав CultureInfo экземпляр объекта с его конструктором new CultureInfo(..) и установив свойства DateTimeFormat и NumberFormat. В более сложных случаях подкласс типа позволяет переопределить дополнительные свойства. Это может привести к появлению потенциальных дополнительных преимуществ, таких как включение псевдолокализации с файлами ресурсов.
   • Если у вас есть явные требования для проверки результатов всех операций даты и времени, следует рассмотреть возможность создания и использования пользовательского TimeZoneInfo экземпляра во время настройки теста. Это может привести к дополнительным преимуществам, таким как включение стабильного тестирования определенных пограничных вариантов (например, изменений в правилах DST).

См. также

• Глобализация и локализация
• Ресурсы в приложениях .NET