Поделиться через

Рекомендации по разработке международных приложений

  • Статья

В этом разделе описаны рекомендации по разработке международных приложений.

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

  1. Используйте Юникод в качестве внутреннего стандарта приложения.

  2. Для управления данными и их форматирования необходимо использовать классы, учитывающие язык и регион, которые представлены в пространстве имен System.Globalization.

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

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

  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", описатель формата даты и времени). Хотя строки формата для инвариантного языка и региональных параметров стабильны и вряд ли изменятся, указание явной строки форматирования помогает уточнить намерение кода.

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

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

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

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

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

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

  5. Следует избегать неоднозначных конструкций, например "Empty Folder", в которых строки могут быть переведены различным образом в зависимости от грамматической роли их составляющих. Например, слово "empty" может быть как глаголом "очистить", так и прилагательным "пустая", что может привести к различным переводам такой фразы на такие языки, как французский или итальянский.

  6. Не следует использовать в приложении изображения и значки, содержащие текст. При их локализации могут возникнуть трудности.

  7. Следует выделять достаточно памяти на случай увеличения длины строк в интерфейсе пользователя. В некоторых языках длина фраз может увеличиться на 50–75 процентов по сравнению с другими языками.

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

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

  10. Следует систематизировать создаваемое приложение с учетом возможности профессиональной локализации (перевода).

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

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

Совет

Ниже приведены рекомендации для приложений ASP платформа .NET Framework. Сведения о приложениях ASP.NET Core см. в разделе "Глобализация и локализация" в ASP.NET Core.

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

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

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

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

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

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

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

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

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

Рекомендации для надежного тестирования

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

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

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

См. также