Aanbevolen procedures voor het ontwikkelen van toepassingen die gereed zijn voor de wereld

In deze sectie worden de best practices beschreven die moeten worden gevolgd bij het ontwikkelen van toepassingen die klaar zijn voor de wereld.

Best practices voor globalisatie

1. Zorg ervoor dat uw toepassing Unicode intern is.

2. Gebruik de cultuurbewuste klassen van de System.Globalization naamruimte om gegevens te bewerken en op te maken.

   • Gebruik de SortKey klas en de CompareInfo klasse voor het sorteren.
   • Gebruik de CompareInfo klasse voor tekenreeksvergelijkingen.
   • Gebruik de DateTimeFormatInfo klasse voor datum- en tijdopmaak.
   • Gebruik de NumberFormatInfo klasse voor numerieke opmaak.
   • Gebruik voor Gregoriaanse en niet-Gregoriaanse kalenders de Calendar klasse of een van de specifieke kalender-implementaties.

3. Gebruik de instellingen voor cultuureigenschappen die door de System.Globalization.CultureInfo klasse worden geleverd in de juiste situaties. Gebruik de eigenschap voor het CultureInfo.CurrentCulture opmaken van taken, zoals datum en tijd of numerieke opmaak. Gebruik de CultureInfo.CurrentUICulture eigenschap om resources op te halen. Houd er rekening mee dat de CurrentCulture en CurrentUICulture eigenschappen per thread kunnen worden ingesteld.

4. Ervoor zorgen dat uw toepassing gegevens van en naar verschillende coderingen kan lezen en schrijven met behulp van de coderingsklassen in de System.Text naamruimte. Ga niet uit van ASCII-gegevens. Stel dat er internationale tekens worden opgegeven waar een gebruiker tekst kan invoeren. De toepassing moet bijvoorbeeld internationale tekens accepteren in servernamen, mappen, bestandsnamen, gebruikersnamen en URL's.

5. Wanneer u de UTF8Encoding klasse gebruikt, gebruikt u om veiligheidsredenen de functie voor foutdetectie die door deze klasse wordt aangeboden. Als u de functie voor foutdetectie wilt inschakelen, maakt u een exemplaar van de klasse met behulp van de constructor die een throwOnInvalidBytes parameter gebruikt en stelt u de waarde van deze parameter in op true.

6. Als dat mogelijk is, kunt u tekenreeksen verwerken als hele tekenreeksen in plaats van als een reeks afzonderlijke tekens. Dit is vooral belangrijk bij het sorteren of zoeken naar subtekenreeksen. Hiermee voorkomt u problemen die zijn gekoppeld aan het parseren van gecombineerde tekens. U kunt ook met teksteenheden werken in plaats van één teken met behulp van de System.Globalization.StringInfo klasse.

7. Tekst weergeven met behulp van de klassen die worden geleverd door de System.Drawing naamruimte.

8. Voor consistentie tussen besturingssystemen is het niet toegestaan dat gebruikersinstellingen worden overschreven CultureInfo. Gebruik de CultureInfo constructor die een useUserOverride parameter accepteert en stel deze in op false.

9. Test uw toepassingsfunctionaliteit op internationale besturingssysteemversies met behulp van internationale gegevens.

10. Als een beveiligingsbeslissing is gebaseerd op het resultaat van een tekenreeksvergelijkings- of casewijzigingsbewerking, gebruikt u een tekenreeksbewerking die niet gevoelig is voor cultuur. Deze procedure zorgt ervoor dat het resultaat niet wordt beïnvloed door de waarde van CultureInfo.CurrentCulture. Zie de sectie 'Tekenreeksvergelijkingen die gebruikmaken van de huidige cultuur' van best practices voor het gebruik van tekenreeksen voor een voorbeeld waarin wordt getoond hoe cultuurgevoelige tekenreeksvergelijkingen inconsistente resultaten kunnen opleveren.

11. Voor elk element dat wordt gebruikt voor uitwisseling (bijvoorbeeld een veld in een JSON-document in een API-aanroep) of opslag, gebruikt u de CultureInfo; daarnaast moet u expliciet een roundtrip-indeling opgeven (zoals de "O""o" datum-tijdnotatieaanduiding). Hoewel de notatietekenreeksen voor de invariante cultuur stabiel en onwaarschijnlijk zijn gewijzigd, helpt het opgeven van een expliciete notatietekenreeks om de intentie van uw code te verduidelijken.

    • Bekijk voor datum-/tijdelementen het advies en de waarnemingen van Noda Time auteur Jon Skeet, die waardevolle inzichten deelt. Zie Jon Skeet: Opslaan van UTC is geen zilveren opsommingsteken voor meer informatie.

12. Globalisatiegegevens zijn niet stabiel en u moet uw toepassing en de bijbehorende tests schrijven met dit in gedachten. Het wordt meerdere keren per jaar bijgewerkt via hostbesturingssystemen op alle ondersteunde platforms. Deze gegevens worden doorgaans niet gedistribueerd met de runtime.

Best practices voor lokalisatie

1. Verplaats alle lokaliseerbare resources naar afzonderlijke DLL's met alleen resources. Lokaliseerbare resources omvatten elementen van de gebruikersinterface, zoals tekenreeksen, foutberichten, dialoogvensters, menu's en ingesloten objectresources.

2. Codeer geen tekenreeksen of resources van de gebruikersinterface.

3. Plaats niet niet-lokaliseerbare resources niet in de dll's met alleen resources. Dit verwar vertalers.

4. Gebruik geen samengestelde tekenreeksen die tijdens runtime zijn gebouwd op basis van samengevoegde woordgroepen. Samengestelde tekenreeksen zijn moeilijk te lokaliseren omdat ze vaak uitgaan van een Engelse grammaticale volgorde die niet van toepassing is op alle talen.

5. Vermijd dubbelzinnige constructies zoals 'Lege map' waar de tekenreeksen verschillend kunnen worden vertaald, afhankelijk van de grammaticale rollen van de tekenreeksonderdelen. 'leeg' kan bijvoorbeeld een werkwoord of een bijvoeglijk naamwoord zijn, wat kan leiden tot verschillende vertalingen in talen zoals Italiaans of Frans.

6. Vermijd het gebruik van afbeeldingen en pictogrammen die tekst bevatten in uw toepassing. Ze zijn duur om te lokaliseren.

7. Laat voldoende ruimte voor de lengte van tekenreeksen uitvouwen in de gebruikersinterface. In sommige talen kunnen woordgroepen 50-75 procent meer ruimte vereisen dan ze nodig hebben in andere talen.

8. Gebruik de System.Resources.ResourceManager klasse om resources op te halen op basis van cultuur.

9. Gebruik Visual Studio om dialoogvensters voor Windows Forms te maken, zodat deze kunnen worden gelokaliseerd met behulp van de Windows Forms Resource Editor (Winres.exe). Codeer dialoogvensters van Windows Forms niet handmatig.

10. Regelen voor professionele lokalisatie (vertaling).

11. Zie Resources in .NET-apps voor een volledige beschrijving van het maken en lokaliseren van resources.

Best practices voor globalisatie voor ASP.NET en andere servertoepassingen

Tip

De volgende aanbevolen procedures zijn bedoeld voor ASP.NET Framework-apps. Zie Globalisatie en lokalisatie in ASP.NET Core-apps voor ASP.NET Core.

1. Stel de CurrentUICulture en CurrentCulture eigenschappen in uw toepassing expliciet in. Vertrouw niet op standaardwaarden.

2. Houd er rekening mee dat ASP.NET toepassingen beheerde toepassingen zijn en daarom dezelfde klassen kunnen gebruiken als andere beheerde toepassingen voor het ophalen, weergeven en bewerken van informatie op basis van cultuur.

3. Houd er rekening mee dat u de volgende drie typen coderingen in ASP.NET kunt opgeven:

   • requestEncoding hiermee geeft u de codering die is ontvangen van de browser van de client.
   • responseEncoding geeft de codering op die naar de clientbrowser moet worden verzonden. In de meeste gevallen moet deze codering hetzelfde zijn als die requestEncodingvoor .
   • fileEncoding geeft de standaardcodering op voor .aspx, .asmx en .asax-bestand parseren.

4. Geef de waarden op voor de requestEncodingkenmerken , responseEncoding, en uiCulturefileEncodingculturekenmerken op de volgende drie plaatsen in een ASP.NET-toepassing:

   • In de sectie Globalisatie van een Web.config-bestand . Dit bestand is extern voor de ASP.NET-toepassing. Zie globalisatie-element voor meer informatie<.>
   • In een pagina-instructie. Wanneer een toepassing zich op een pagina bevindt, is het bestand al gelezen. Daarom is het te laat om fileEncoding en requestEncoding op te geven. Alleen uiCulture, cultureen responseEncoding kan worden opgegeven in een pagina-instructie.
   • Programmatisch in toepassingscode. Deze instelling kan per aanvraag verschillen. Net als bij een pagina-instructie is het te laat om de code van de toepassing op te geven fileEncoding en requestEncoding. Alleen uiCulture, cultureen responseEncoding kan worden opgegeven in de toepassingscode.

5. Houd er rekening mee dat de waarde uiCulture kan worden ingesteld op de taal voor accepteren van de browser.

6. Voor toepassingen die worden gedistribueerd, moet u updates zonder downtime toestaan (bijvoorbeeld Azure Container Apps), of vergelijkbaar, plannen voor situaties waarin er mogelijk meerdere exemplaren van de toepassing zijn met verschillende indelingsregels of andere cultuurgegevens, die het meest relevant zijn voor tijdzoneregels.

   • Als uw toepassingsimplementatie een database bevat, moet u er rekening mee houden dat de database zijn eigen globalisatieregels heeft. In de meeste gevallen moet u voorkomen dat u eventuele globalisatiefuncties in de database uitvoert.
   • Als uw toepassingsimplementatie een clienttoepassing of webfront-end bevat met behulp van clientglobalisatiebronnen, wordt ervan uitgegaan dat de clientbronnen verschillen van de resources die beschikbaar zijn voor uw server. Overweeg exclusief globalisatiefuncties uit te voeren op de client.

Aanbevelingen voor robuuste tests

1. Als u afhankelijkheden explicieter wilt maken en mogelijk eenvoudiger en parallelliseerbaar wilt maken, moet u overwegen om instellingen die relevant zijn voor cultuur, zoals CultureInfo parameters, expliciet door te geven aan methoden die opmaak uitvoeren en TimeZoneInfo methoden die werken met datums en tijden. U moet ook of een vergelijkbaar type gebruiken TimeProvider bij het ophalen van de tijd.

2. Voor de meeste tests moet u de exacte uitvoer van een bepaalde opmaakbewerking of de exacte verschuiving van een tijdzone niet expliciet valideren. Opmaak- en tijdzonegegevens kunnen op elk gewenst moment veranderen en kunnen verschillen tussen twee anders identieke exemplaren van een besturingssysteem (en mogelijk verschillende processen op dezelfde computer). Als u vertrouwt op een exacte waarde, worden tests broos.

   • Over het algemeen is het valideren van de ontvangen uitvoer voldoende (bijvoorbeeld niet-lege tekenreeksen bij het opmaken).
   • Voor sommige gegevenselementen en indelingen moet u valideren dat de gegevens worden geparseerd naar de invoerwaarde in plaats daarvan (roundtripping). Er moet rekening worden gehouden met gevallen waarin velden worden verwijderd (bijvoorbeeld jaar voor bepaalde datumgerelateerde velden) of de waarde afgekapt of afgerond (bijvoorbeeld voor uitvoer van drijvende komma).
   • Als u expliciete vereisten hebt om alle gelokaliseerde indelingsuitvoer te valideren, kunt u overwegen een aangepaste cultuur te maken en te gebruiken tijdens het instellen van de test. In de meeste eenvoudige gevallen kunt u dit doen door een CultureInfo object te instantiëren met de constructor new CultureInfo(..) en de DateTimeFormat eigenschappen in NumberFormat te stellen. Voor complexere gevallen kunt u met subklassen van het type aanvullende eigenschappen overschrijven. Er zijn mogelijk extra voordelen voor dit, zoals het inschakelen van pseudolokalisatie met resourcebestanden.
   • Als u expliciete vereisten hebt om de resultaten van alle datum-/tijdbewerkingen te valideren, kunt u een aangepast exemplaar TimeZoneInfo maken en gebruiken tijdens de testinstallatie. Er zijn mogelijk extra voordelen, zoals het inschakelen van stabiele tests van bepaalde edge-gevallen (bijvoorbeeld wijzigingen in DST-regels).

Zie ook

• Globalisatie en lokalisatie
• Resources in .NET-apps