Dela via

Metodtips för utveckling av program som är redo för världen

  • Artikel

I det här avsnittet beskrivs de metodtips som ska följas när du utvecklar program som är redo för världen.

Metodtips för globalisering

  1. Gör programmet till Unicode internt.

  2. Använd de kulturmedvetna klasser som tillhandahålls av System.Globalization namnområdet för att manipulera och formatera data.

    • Använd klassen och klassen för CompareInfo sorteringSortKey.
    • Använd klassen för CompareInfo strängjämförelser.
    • Använd klassen för datum- och tidsformatering DateTimeFormatInfo .
    • Använd klassen för numerisk formatering NumberFormatInfo .
    • För gregorianska och icke-gregorianska kalendrar använder du Calendar klassen eller någon av de specifika kalenderimplementeringarna.

  3. Använd kulturegenskapsinställningarna System.Globalization.CultureInfo som tillhandahålls av klassen i lämpliga situationer. Använd egenskapen CultureInfo.CurrentCulture för att formatera uppgifter, till exempel datum och tid eller numerisk formatering. Använd egenskapen CultureInfo.CurrentUICulture för att hämta resurser. Observera att CurrentCulture egenskaperna och CurrentUICulture kan anges per tråd.

  4. Gör så att programmet kan läsa och skriva data till och från en mängd olika kodningar med hjälp av kodningsklasserna i System.Text namnområdet. Anta inte ASCII-data. Anta att internationella tecken kommer att anges var som helst där en användare kan ange text. Programmet bör till exempel acceptera internationella tecken i servernamn, kataloger, filnamn, användarnamn och URL:er.

  5. När du använder UTF8Encoding klassen använder du av säkerhetsskäl funktionen för felidentifiering som erbjuds av den här klassen. Om du vill aktivera funktionen för felidentifiering skapar du en instans av klassen med konstruktorn som tar en throwOnInvalidBytes parameter och anger värdet för den här parametern till true.

  6. När det är möjligt kan du hantera strängar som hela strängar i stället för som en serie enskilda tecken. Detta är särskilt viktigt när du sorterar eller söker efter delsträngar. Detta förhindrar problem som är associerade med parsning av kombinerade tecken. Du kan också arbeta med textenheter i stället för enkla tecken med hjälp System.Globalization.StringInfo av klassen .

  7. Visa text med hjälp av de klasser som tillhandahålls av System.Drawing namnområdet.

  8. Tillåt inte att användarinställningarna åsidosätter CultureInfoför konsekvens mellan operativsystem. CultureInfo Använd konstruktorn som accepterar en useUserOverride parameter och ange den till false.

  9. Testa dina programfunktioner på internationella operativsystemversioner med hjälp av internationella data.

  10. Om ett säkerhetsbeslut baseras på resultatet av en strängjämförelse eller skiftlägesändringsåtgärd använder du en kulturokänslig strängåtgärd. Den här metoden säkerställer att resultatet inte påverkas av värdet för CultureInfo.CurrentCulture. Se avsnittet "Strängjämförelser som använder den aktuella kulturen" i Metodtips för att använda strängar för ett exempel som visar hur kulturkänsliga strängjämförelser kan ge inkonsekventa resultat.

  11. För alla element som används för utbyte (till exempel ett fält i ett JSON-dokument i ett API-anrop) eller lagring använder CultureInfodu . Dessutom bör du uttryckligen ange ett tur och retur-format (till exempel "O""o" , datum-tidsformatsspecificeraren). Även om formatsträngarna för den invarianta kulturen är stabila och sannolikt inte kommer att ändras, hjälper det att klargöra avsikten med koden genom att ange en explicit formatsträng.

  12. Globaliseringsdata är inte stabila och du bör skriva ditt program och dess tester med detta i åtanke. Den uppdateras flera gånger om året via värdoperativsystemkanaler på alla plattformar som stöds. Dessa data distribueras vanligtvis inte med körningen.

Metodtips för lokalisering

  1. Flytta alla resurser som kan lokaliseras till separata DLL:er för endast resurser. Lokala resurser omfattar användargränssnittselement, till exempel strängar, felmeddelanden, dialogrutor, menyer och inbäddade objektresurser.

  2. Hårdkoda inte strängar eller användargränssnittsresurser.

  3. Placera inte icke-localizable resurser i de endast resursbaserade DLL:erna. Detta förvirrar översättare.

  4. Använd inte sammansatta strängar som skapas vid körning från sammanfogade fraser. Sammansatta strängar är svåra att lokalisera eftersom de ofta förutsätter en engelsk grammatisk ordning som inte gäller för alla språk.

  5. Undvik tvetydiga konstruktioner som "Tom mapp" där strängarna kan översättas på olika sätt beroende på strängkomponenternas grammatiska roller. Till exempel kan "tom" vara antingen ett verb eller ett adjektiv, vilket kan leda till olika översättningar på språk som italienska eller franska.

  6. Undvik att använda bilder och ikoner som innehåller text i ditt program. De är dyra att lokalisera.

  7. Tillåt gott om utrymme för längden på strängar att expandera i användargränssnittet. På vissa språk kan fraser kräva 50–75 procent mer utrymme än de behöver på andra språk.

  8. System.Resources.ResourceManager Använd klassen för att hämta resurser baserat på kultur.

  9. Använd Visual Studio för att skapa dialogrutor för Windows-formulär så att de kan lokaliseras med hjälp av Resursredigeraren för Windows Forms (Winres.exe). Koda inte dialogrutor för Windows Forms för hand.

  10. Ordna professionell lokalisering (översättning).

  11. En fullständig beskrivning av hur du skapar och lokaliserar resurser finns i Resurser i .NET-appar.

Metodtips för globalisering för ASP.NET och andra serverprogram

Dricks

Följande metodtips gäller för ASP.NET Framework-appar. Information om ASP.NET Core-appar finns i Globalisering och lokalisering i ASP.NET Core.

  1. Ange uttryckligen CurrentUICulture egenskaperna och CurrentCulture i ditt program. Förlita dig inte på standardvärden.

  2. Observera att ASP.NET program är hanterade program och därför kan använda samma klasser som andra hanterade program för att hämta, visa och manipulera information baserat på kultur.

  3. Tänk på att du kan ange följande tre typer av kodningar i ASP.NET:

    • requestEncoding anger den kodning som tas emot från klientens webbläsare.
    • responseEncoding anger kodningen som ska skickas till klientwebbläsaren. I de flesta fall bör den här kodningen vara densamma som den som angetts för requestEncoding.
    • fileEncoding anger standardkodning för .aspx, .asmx och .asax-filparsing.

  4. Ange värdena för attributen requestEncoding, responseEncoding, fileEncoding, cultureoch uiCulture på följande tre platser i ett ASP.NET program:

    • I globaliseringsavsnittet i en Web.config-fil . Den här filen är extern för ASP.NET-programmet. Mer information finns i globaliseringselementet>.<
    • I ett siddirektiv. Observera att när ett program finns på en sida har filen redan lästs. Därför är det för sent att ange fileEncoding och requestEncoding. Endast uiCulture, cultureoch responseEncoding kan anges i ett siddirektiv.
    • Programmatiskt i programkod. Den här inställningen kan variera per begäran. Precis som med ett siddirektiv är det för sent att ange fileEncoding och requestEncodingnär programmets kod har nåtts. Endast uiCulture, cultureoch responseEncoding kan anges i programkoden.

  5. Observera att uiCulture-värdet kan anges till webbläsarens acceptera språk.

  6. För program som distribueras kan du tillåta uppdateringar utan stilleståndstid (till exempel Azure Container Apps) eller liknande som du måste planera för situationer där det kan finnas flera instanser av programmet med olika formatregler eller andra kulturdata, mest relevanta tidszonsregler.

    • Om programdistributionen innehåller en databas ska du komma ihåg att databasen har egna globaliseringsregler. I de flesta fall bör du undvika att utföra globaliseringsrelaterade funktioner i databasen.
    • Om programdistributionen innehåller ett klientprogram eller en webbklientdel med hjälp av klientglobaliseringsresurser antar du att klientresurserna skiljer sig från de resurser som är tillgängliga för servern. Överväg att uteslutande utföra globaliseringsfunktioner på klienten.

Rekommendationer för robust testning

  1. Om du vill göra beroenden mer explicita och testa potentiellt enklare och parallelliserbara bör du överväga att uttryckligen skicka kulturreleventiska inställningar, till exempel CultureInfo parametrar, till metoder som utför formatering och TimeZoneInfo till metoder som fungerar med datum och tider. Du bör också använda TimeProvider eller en liknande typ när du hämtar tiden.

  2. För de flesta tester bör du inte uttryckligen verifiera de exakta utdata från en viss formateringsåtgärd eller den exakta förskjutningen av en tidszon. Formatering och tidszonsdata kan ändras när som helst och kan variera mellan två annars identiska instanser av ett operativsystem (och potentiellt olika processer på samma dator). Om du förlitar dig på ett exakt värde blir testerna spröda.

    • I allmänhet räcker det att verifiera att vissa utdata har tagits emot (till exempel icke-tomma strängar vid formatering).
    • För vissa dataelement och format kan validering av att data parsas till indatavärdet användas i stället (avrundning). Försiktighet måste iakttas i fall där fält tas bort (till exempel år för vissa datumrelaterade fält) eller värdet trunkeras eller avrundas (till exempel för flyttalsutdata).
    • Om du har explicita krav för att verifiera alla lokaliserade formatutdata bör du överväga att skapa och använda en anpassad kultur under testkonfigurationen. I de flesta enkla fall kan detta göras genom att instansiera ett CultureInfo objekt med konstruktorn new CultureInfo(..) och ange DateTimeFormat egenskaperna och NumberFormat . För mer komplicerade fall kan du åsidosätta ytterligare egenskaper genom att underklassa typen. Det finns potentiella ytterligare fördelar med detta, till exempel att aktivera pseudolokalisering med resursfiler.
    • Om du har explicita krav för att verifiera resultatet av alla datum/tid-åtgärder bör du överväga att skapa och använda en anpassad TimeZoneInfo instans under testkonfigurationen. Det finns potentiella ytterligare fördelar med detta, till exempel att aktivera stabil testning av vissa gränsfall (till exempel ändringar i DST-regler).

Se även