Najlepsze rozwiązania dotyczące tworzenia aplikacji gotowych do użycia na świecie

W tej sekcji opisano najlepsze rozwiązania, które należy zastosować podczas tworzenia aplikacji gotowych do użycia na świecie.

Najlepsze rozwiązania dotyczące globalizacji

1. Utwórz aplikację w formacie Unicode wewnętrznie.

2. Użyj klas obsługujących kulturę udostępnianych przez System.Globalization przestrzeń nazw, aby manipulować danymi i formatować je.

   • Do sortowania użyj klasy SortKey i klasy CompareInfo.
   • W przypadku porównań ciągów użyj CompareInfo klasy .
   • W przypadku formatowania daty i godziny użyj DateTimeFormatInfo klasy .
   • W przypadku formatowania liczbowego użyj NumberFormatInfo klasy .
   • W przypadku kalendarzy gregoriańskich i innych niż gregoriański użyj Calendar klasy lub jednej z określonych implementacji kalendarza.

3. Użyj ustawień właściwości kultury udostępnianych przez klasę System.Globalization.CultureInfo w odpowiednich sytuacjach. CultureInfo.CurrentCulture Użyj właściwości do formatowania zadań, takich jak data i godzina lub formatowanie liczbowe. Użyj właściwości CultureInfo.CurrentUICulture , aby pobrać zasoby. Należy pamiętać, że właściwości CurrentCulture i CurrentUICulture można ustawić osobno dla każdego wątku.

4. Umożliwia aplikacji odczytywanie i zapisywanie danych do i z różnych kodowań przy użyciu klas kodowania w System.Text przestrzeni nazw. Nie zakładaj danych ASCII. Załóżmy, że znaki międzynarodowe będą dostarczane w dowolnym miejscu, w jakim użytkownik może wprowadzić tekst. Na przykład aplikacja powinna akceptować znaki międzynarodowe w nazwach serwerów, katalogach, nazwach plików, nazwach użytkowników i adresach URL.

5. Podczas korzystania z klasy UTF8Encoding ze względów bezpieczeństwa należy użyć funkcji wykrywania błędów oferowanej przez tę klasę. Aby włączyć funkcję wykrywania błędów, utwórz wystąpienie klasy przy użyciu konstruktora, który przyjmuje throwOnInvalidBytes parametr i ustaw wartość tego parametru na true.

6. Jeśli to możliwe, obsłuż ciągi jako całe ciągi, a nie jako serię pojedynczych znaków. Jest to szczególnie ważne podczas sortowania lub wyszukiwania podłańcuchów. Zapobiegnie to problemom związanym z analizowaniem połączonych znaków. Możesz również pracować z jednostkami tekstu, a nie pojedynczymi znakami przy użyciu System.Globalization.StringInfo klasy .

7. Wyświetlaj tekst przy użyciu klas udostępnianych przez System.Drawing przestrzeń nazw.

8. Aby zapewnić spójność w różnych systemach operacyjnych, nie zezwalaj na zastępowanie ustawień użytkownika przez CultureInfo. Użyj konstruktora CultureInfo, który akceptuje parametr useUserOverride i ustaw go na wartość false.

9. Przetestuj funkcje aplikacji w międzynarodowych wersjach systemu operacyjnego przy użyciu danych międzynarodowych.

10. Jeśli decyzja dotycząca zabezpieczeń jest oparta na wyniku operacji porównywania ciągów znaków lub zmiany wielkości liter, użyj operacji ciągowych niewrażliwych na ustawienia regionalne. Ta praktyka gwarantuje, że wynik nie ma wpływu na wartość CultureInfo.CurrentCulture. Zobacz sekcję "Porównania ciągów, które używają bieżącej kultury" w Najlepsze praktyki dotyczące używania ciągów, aby zapoznać się z przykładem, który pokazuje, jak porównania ciągów wrażliwych na kulturę mogą generować niespójne wyniki.

11. W przypadku każdego elementu używanego do wymiany (na przykład pola w dokumencie JSON w wywołaniu interfejsu API) lub magazynowania należy użyć CultureInfo; dodatkowo należy jawnie określić format dwukierunkowy (taki jak "O""o" specyfikator formatu daty i godziny). Chociaż ciągi formatu dla niezmiennej kultury są stabilne i mało prawdopodobne do zmiany, określenie jawnego ciągu formatu pomaga wyjaśnić intencję kodu.

    • W przypadku elementów daty/godziny należy wziąć pod uwagę porady i obserwacje autora Noda Time Jon Skeet, który dzieli się cennymi szczegółowymi informacjami. Aby uzyskać więcej informacji, zobacz Jon Skeet: Storing UTC nie jest złotym środkiem.

12. Dane globalizacji nie są stabilne i należy napisać aplikację i jej testy, mając to na uwadze. Jest on aktualizowany kilka razy w roku za pośrednictwem kanałów systemu operacyjnego hosta na wszystkich obsługiwanych platformach. Te dane zwykle nie są dystrybuowane ze środowiskiem uruchomieniowym.

Najlepsze rozwiązania dotyczące lokalizacji

1. Przenieś wszystkie zasoby lokalizowalne do oddzielnych bibliotek DLL przeznaczonych wyłącznie dla zasobów. Zasoby lokalizowalne obejmują elementy interfejsu użytkownika, takie jak ciągi, komunikaty o błędach, okna dialogowe, menu i zasoby obiektów osadzonych.

2. Nie należy kodować ciągów twardych ani zasobów interfejsu użytkownika.

3. Nie umieszczaj zasobów, które są niepodlegające lokalizacji, w bibliotekach DLL przeznaczonych wyłącznie dla zasobów. To dezorientuje tłumaczy.

4. Nie używaj ciągów złożonych utworzonych w czasie wykonywania z połączonych fraz. Ciągi złożone są trudne do zlokalizowania, ponieważ często zakładają one angielski porządek gramatyczny, który nie ma zastosowania do wszystkich języków.

5. Unikaj niejednoznacznych konstrukcji, takich jak "Pusty folder", gdzie ciągi mogą być tłumaczone inaczej w zależności od ról gramatycznych składników ciągu. Na przykład "pusty" może być czasownikiem lub przymiotnikiem, co może prowadzić do różnych tłumaczeń w językach, takich jak włoski lub francuski.

6. Unikaj używania obrazów i ikon zawierających tekst w aplikacji. Są one kosztowne do lokalizowania.

7. Umożliwia dużą ilość miejsca na rozwinięcie długości ciągów w interfejsie użytkownika. W niektórych językach frazy mogą wymagać 50–75 procent więcej miejsca niż w innych językach.

8. Użyj klasy System.Resources.ResourceManager , aby pobrać zasoby na podstawie kultury.

9. Użyj programu Visual Studio , aby utworzyć okna dialogowe formularzy systemu Windows, aby można je było lokalizować przy użyciu Edytora zasobów formularzy systemu Windows (Winres.exe). Nie koduj okien dialogowych Windows Forms ręcznie.

10. Zorganizuj profesjonalną lokalizację (tłumaczenie).

11. Aby uzyskać pełny opis tworzenia i lokalizowania zasobów, zobacz Zasoby w aplikacjach platformy .NET.

Najlepsze rozwiązania dotyczące globalizacji dla ASP.NET i innych aplikacji serwerowych

1. Jawnie ustaw właściwości CurrentUICulture i CurrentCulture w swojej aplikacji. Nie należy polegać na wartościach domyślnych.

2. Należy pamiętać, że aplikacje ASP.NET są aplikacjami zarządzanymi i dlatego mogą używać tych samych klas co inne aplikacje zarządzane do pobierania, wyświetlania i manipulowania informacjami na podstawie kultury.

3. Należy pamiętać, że można określić następujące trzy typy kodowań w ASP.NET:

   • requestEncoding określa kodowanie odebrane z przeglądarki klienta.
   • responseEncoding określa kodowanie do wysyłania do przeglądarki klienta. W większości sytuacji kodowanie powinno być takie samo jak określone dla elementu requestEncoding.
   • fileEncoding określa domyślne kodowanie plików do analizy .aspx, .asmx i .asax.

4. Określ wartości atrybutów requestEncoding, , responseEncodingfileEncoding, culturei uiCulture w następujących trzech miejscach w aplikacji ASP.NET:

   • W pliku Web.config w sekcji dotyczącej globalizacji. Ten plik jest zewnętrzny dla aplikacji ASP.NET. Aby uzyskać więcej informacji, zobacz <globalization> element.
   • W dyrektywie strony. Należy pamiętać, że gdy aplikacja znajduje się na stronie, plik został już odczytany. W związku z tym jest za późno, aby określić kodowanie pliku i kodowanie żądań. Tylko uiCulture, culturei responseEncoding można określić w dyrektywie page.
   • Programowo w kodzie aplikacji. To ustawienie może się różnić w zależności od żądania. Podobnie jak w przypadku dyrektywy page, po osiągnięciu kodu aplikacji jest za późno, aby określić fileEncoding i requestEncoding. W kodzie aplikacji można określić tylko uiCulture, culturei responseEncoding .

5. Należy pamiętać, że wartość uiCulture można ustawić na język akceptowania przez przeglądarkę.

6. W przypadku aplikacji, które są rozproszone, które umożliwiają aktualizacje bez przestojów (na przykład Azure Container Apps) lub podobne, musisz zaplanować sytuacje, w których może istnieć wiele wystąpień aplikacji z różnymi regułami formatu lub innymi danymi kultury, szczególnie pod kątem reguł stref czasowych.

   • Jeśli wdrożenie aplikacji obejmuje bazę danych, pamiętaj, że baza danych będzie miała własne reguły globalizacji. W większości przypadków należy unikać wykonywania wszelkich funkcji związanych z globalizacją w bazie danych.
   • Jeśli wdrożenie aplikacji obejmuje aplikację kliencką lub fronton internetowy przy użyciu zasobów globalizacji klienta, załóżmy, że zasoby klienckie różnią się od zasobów dostępnych dla serwera. Rozważ wykonywanie funkcji globalizacji wyłącznie po stronie klienta.

Zalecenia dotyczące niezawodnego testowania

1. Aby uczynić zależności bardziej widocznymi i testowanie potencjalnie łatwiejszym oraz równoległym, należy rozważyć jawne przekazanie ustawień związanych z kulturą, takich jak CultureInfo parametry, do metod, które wykonują formatowanie, oraz TimeZoneInfo do metod, które współpracują z datami i godzinami. Należy również użyć TimeProvider lub podobnego typu podczas pobierania czasu.

2. W przypadku większości testów nie należy jawnie weryfikować dokładnych danych wyjściowych danej operacji formatowania ani dokładnego przesunięcia strefy czasowej. Formatowanie i dane strefy czasowej mogą ulec zmianie w dowolnym momencie i mogą się różnić między dwoma inaczej identycznymi wystąpieniami systemu operacyjnego (i potencjalnie różnymi procesami na tym samym komputerze). Poleganie na dokładnej wartości sprawia, że testy są kruche.

   • Ogólnie rzecz biorąc, sprawdzanie, czy niektóre dane wyjściowe zostały odebrane, będzie wystarczające (na przykład niepuste ciągi podczas formatowania).
   • W przypadku niektórych elementów danych i formatów sprawdzanie poprawności analizowania danych do wartości wejściowej może zamiast tego być używane (zaokrąglanie). Należy zachować ostrożność w przypadkach, w których pola są pomijane (na przykład rok dla niektórych pól związanych z datą) lub wartość jest skrócona lub zaokrąglona (np. przy wyjściowych wartościach zmiennoprzecinkowych).
   • Jeśli masz wyraźne wymagania dotyczące weryfikowania wszystkich zlokalizowanych wyników formatowania, należy rozważyć utworzenie kultury niestandardowej i jej użycie podczas przygotowania testów. W większości prostych przypadków można to zrobić, tworząc obiekt CultureInfo za pomocą jego konstruktora new CultureInfo(..) i ustawiając właściwości DateTimeFormat oraz NumberFormat. W przypadku bardziej skomplikowanych przypadków podklasowanie typu umożliwia zastępowanie dodatkowych właściwości. Mogą istnieć dodatkowe korzyści, takie jak umożliwienie pseudolokalizacji za pomocą plików zasobów.
   • Jeśli masz jawne wymagania dotyczące weryfikowania wyników wszystkich operacji daty/godziny, należy rozważyć utworzenie i użycie wystąpienia niestandardowego TimeZoneInfo podczas konfigurowania testu. Istnieją potencjalne dodatkowe korzyści, takie jak umożliwienie stabilnego testowania niektórych przypadków brzegowych (na przykład zmiany reguł DST).

Zobacz także

• Globalizacja i lokalizacja
• Zasoby w aplikacjach .NET