Condividi tramite


Procedure consigliate per lo sviluppo di applicazioni pronte per il mondo

Questa sezione descrive le procedure consigliate da seguire quando si sviluppano applicazioni pronte per il mondo.

Procedure consigliate per la globalizzazione

  1. Fai in modo che la tua applicazione sia Unicode a livello interno.

  2. Usare le classi consapevoli della cultura fornite dallo System.Globalization spazio dei nomi per gestire e formattare i dati.

    • Per l'ordinamento, usare la SortKey classe e la CompareInfo classe .
    • Per i confronti di stringhe, usare la CompareInfo classe .
    • Per la formattazione di data e ora, usare la DateTimeFormatInfo classe .
    • Per la formattazione numerica, usare la NumberFormatInfo classe .
    • Per i calendari gregoriani e non gregoriani, usare la Calendar classe o una delle implementazioni di calendario specifiche.
  3. Utilizzare le proprietà delle impostazioni cultura fornite dalla classe System.Globalization.CultureInfo nelle situazioni appropriate. Utilizzare la CultureInfo.CurrentCulture proprietà per la formattazione delle attività, ad esempio data e ora o formattazione numerica. Utilizzare la CultureInfo.CurrentUICulture proprietà per recuperare le risorse. Si noti che le CurrentCulture proprietà e CurrentUICulture possono essere impostate per ogni thread.

  4. Permetti all'applicazione di leggere e scrivere dati da e verso un'ampia gamma di codifiche usando le classi di codifica nello spazio dei nomi di System.Text. Non presupporre dati ASCII. Si supponga che vengano forniti caratteri internazionali ovunque un utente possa immettere testo. Ad esempio, l'applicazione deve accettare caratteri internazionali nei nomi dei server, nelle directory, nei nomi di file, nei nomi utente e negli URL.

  5. Quando si usa la UTF8Encoding classe , per motivi di sicurezza, usare la funzionalità di rilevamento degli errori offerta da questa classe. Per attivare la funzionalità di rilevamento degli errori, creare un'istanza della classe usando il costruttore che accetta un throwOnInvalidBytes parametro e impostare il valore di questo parametro su true.

  6. Quando possibile, gestire le stringhe come intere stringhe anziché come una serie di singoli caratteri. Ciò è particolarmente importante durante l'ordinamento o la ricerca di sottostringhe. In questo modo si evitano problemi associati all'analisi dei caratteri combinati. È anche possibile usare unità di testo anziché singoli caratteri usando la System.Globalization.StringInfo classe .

  7. Visualizzare il testo usando le classi fornite dal namespace System.Drawing.

  8. Per coerenza tra sistemi operativi, non consentire alle impostazioni utente di eseguire l'override di CultureInfo. Usare il CultureInfo costruttore che accetta un useUserOverride parametro e impostarlo su false.

  9. Testare la funzionalità dell'applicazione nelle versioni internazionali del sistema operativo usando i dati internazionali.

  10. Se una decisione di sicurezza si basa sul risultato di un confronto di stringhe o di un'operazione di modifica delle maiuscole/minuscole, usare un'operazione di stringa insensibile alle impostazioni culturali. Questa procedura garantisce che il risultato non sia influenzato dal valore di CultureInfo.CurrentCulture. Vedere la sezione "Confronti di stringhe che usano la cultura corrente" delle procedure consigliate per l'uso delle stringhe per un esempio che mostra come i confronti di stringhe sensibili alla cultura possano produrre risultati incoerenti.

  11. Per qualsiasi elemento usato per l'interscambio (ad esempio, un campo in un documento JSON in una chiamata API) o l'archiviazione, usare CultureInfo. È inoltre necessario specificare in modo esplicito un formato di round trip (ad esempio, l'identificatore"O""o" di formato data/ora). Sebbene le stringhe di formato per la cultura invariante siano stabili e poco inclini a cambiare, specificare una stringa di formato esplicita aiuta a chiarire l'intento del codice.

  12. I dati di globalizzazione non sono stabili ed è necessario scrivere l'applicazione e i relativi test tenendo presente questo aspetto. Viene aggiornato più volte all'anno tramite canali del sistema operativo host in tutte le piattaforme supportate. Questi dati in genere non vengono distribuiti con il runtime.

Procedure consigliate per la localizzazione

  1. Spostare tutte le risorse da localizzare in DLL separate contenenti solo risorse. Le risorse localizzabili includono elementi dell'interfaccia utente, ad esempio stringhe, messaggi di errore, finestre di dialogo, menu e risorse degli oggetti incorporati.

  2. Non incorporare stringhe o risorse dell'interfaccia utente nel codice.

  3. Non inserire risorse non localizzabili nelle DLL che contengono solo risorse. Questo confonde i traduttori.

  4. Non usare stringhe composite compilate in fase di esecuzione da frasi concatenate. Le stringhe composte sono difficili da localizzare perché spesso presuppongono un ordine grammaticale inglese che non si applica a tutte le lingue.

  5. Evitare costrutti ambigui, ad esempio "Cartella vuota", in cui le stringhe possono essere tradotte in modo diverso a seconda dei ruoli grammaticali dei componenti stringa. Ad esempio, "vuoto" può essere un verbo o un aggettivo, che può portare a traduzioni diverse in lingue come italiano o francese.

  6. Evitare di usare immagini e icone che contengono testo nell'applicazione. Sono costosi da localizzare.

  7. Concedi abbastanza spazio affinché le stringhe possano espandersi nell'interfaccia utente. In alcune lingue, le frasi possono richiedere più spazio del 50-75% rispetto a quelle necessarie in altre lingue.

  8. Usare la System.Resources.ResourceManager classe per recuperare le risorse in base alla cultura.

  9. Usa Visual Studio per creare finestre di dialogo di Windows Forms in modo che possano essere localizzate usando l'Editor risorse Windows Forms (Winres.exe). Non codificare le finestre di dialogo di Windows Form a mano.

  10. Organizza la localizzazione professionale (traduzione).

  11. Per una descrizione completa della creazione e della localizzazione delle risorse, vedere Risorse nelle app .NET.

Procedure consigliate per la globalizzazione per ASP.NET e altre applicazioni server

Suggerimento

Le procedure consigliate seguenti sono per le app di ASP.NET Framework. Per le app core ASP.NET, vedere Globalizzazione e localizzazione in ASP.NET Core.

  1. Impostare esplicitamente le proprietà CurrentUICulture e CurrentCulture nella tua applicazione. Non basarsi sulle impostazioni predefinite.

  2. Si noti che le applicazioni ASP.NET sono applicazioni gestite e pertanto possono usare le stesse classi di altre applicazioni gestite per recuperare, visualizzare e modificare le informazioni in base alle impostazioni culturali.

  3. Tenere presente che è possibile specificare i tre tipi di codifica seguenti in ASP.NET:

    • requestEncoding specifica la codifica ricevuta dal browser del client.
    • responseEncoding specifica la codifica da inviare al browser client. Nella maggior parte dei casi, questa codifica deve essere uguale a quella specificata per requestEncoding.
    • fileEncoding specifica la codifica predefinita per l'analisi dei file .aspx, asmx e asax .
  4. Specifica i valori per gli attributi requestEncoding, responseEncoding, fileEncoding, culture e uiCulture nei seguenti tre punti all'interno di un'applicazione ASP.NET.

    • Nella sezione globalizzazione di un fileWeb.config. Questo file è esterno all'applicazione ASP.NET. Per altre informazioni, vedere <Elemento globalizzazione>.
    • In una direttiva di pagina. Si noti che, quando un'applicazione si trova in una pagina, il file è già stato letto. Pertanto, è troppo tardi per specificare fileEncoding e requestEncoding. Solo uiCulture, culturee responseEncoding possono essere specificati in una direttiva di pagina.
    • Programmaticamente, nel codice dell'applicazione. Questa impostazione può variare in base alla richiesta. Come per una direttiva di pagina, quando viene raggiunto il codice dell'applicazione, è troppo tardi per specificare fileEncoding e requestEncoding. Solo uiCulture, culturee responseEncoding possono essere specificati nel codice dell'applicazione.
  5. Si noti che il valore uiCulture può essere impostato sulla lingua accettata dal browser.

  6. Per le applicazioni distribuite, come quelle che consentono aggiornamenti senza tempi di inattività (ad esempio, Azure Container Apps) o simili, è necessario pianificare situazioni in cui possono essere presenti più istanze dell'applicazione con regole di formato diverse o altri dati relativi alle impostazioni cultura, più rilevanti le regole del fuso orario.

    • Se la distribuzione dell'applicazione include un database, tenere presente che il database avrà regole di globalizzazione proprie. Nella maggior parte dei casi è consigliabile evitare di eseguire funzioni correlate alla globalizzazione nel database.
    • Se la distribuzione dell'applicazione include un'applicazione client o un front-end Web usando risorse di globalizzazione client, si supponga che le risorse client differiscano dalle risorse disponibili per il server. Considerare l'esecuzione esclusiva di funzioni di globalizzazione nel client.

Suggerimenti per test affidabili

  1. Per rendere le dipendenze più esplicite e rendere quindi il testing potenzialmente più semplice e parallelizzabile, è consigliabile passare in modo esplicito impostazioni pertinenti alla cultura, come parametri, ai metodi che eseguono la formattazione e ai metodi che operano con date e tempi. È anche consigliabile usare TimeProvider o un tipo simile durante il recupero dell'ora.

  2. Per la maggior parte dei test, non è consigliabile convalidare in modo esplicito l'output esatto di una determinata operazione di formattazione o l'offset esatto di un fuso orario. La formattazione e i dati del fuso orario possono cambiare in qualsiasi momento e possono variare tra due istanze altrimenti identiche di un sistema operativo (e processi potenzialmente diversi nello stesso computer). L'affidamento su un valore esatto rende i test fragili.

    • In genere, la convalida che alcuni output sono stati ricevuti sarà sufficiente (ad esempio, stringhe non vuote durante la formattazione).
    • Per alcuni elementi e formati di dati, è possibile convalidare che i dati vengano analizzati fino al valore di input tramite round-tripping. È necessario prestare attenzione ai casi in cui i campi vengono eliminati (ad esempio, anno per alcuni campi correlati alla data) o il valore troncato o arrotondato (ad esempio per l'output a virgola mobile).
    • Se si hanno requisiti espliciti per convalidare tutto l'output del formato localizzato, è consigliabile creare e usare una cultura personalizzata durante la configurazione dei test. Per la maggior parte dei casi semplici, questa operazione può essere eseguita creando un'istanza di un CultureInfo oggetto con il relativo costruttore new CultureInfo(..) e impostando le DateTimeFormat proprietà e NumberFormat . Per casi più complessi, la sottoclassazione del tipo consente l'override di proprietà aggiuntive. Esistono potenziali vantaggi aggiuntivi, ad esempio l'abilitazione della pseudolocalizzazione con i file di risorse.
    • Se sono presenti requisiti espliciti per convalidare i risultati di tutte le operazioni di data/ora, è consigliabile creare e usare un'istanza personalizzata TimeZoneInfo durante l'installazione del test. Esistono potenziali vantaggi aggiuntivi a questo scopo, ad esempio l'abilitazione di test stabili di determinati casi limite(ad esempio, modifiche alle regole DST).

Vedere anche