Globaliseringsproblemer i ASP og ASP.NET

Tegnsett og kodesider

Vi vet alle at tegnene på dataskjermen bare er en serie byte. Byteserien kan opprettes og tolkes på en rekke måter. Hvis tolkningen bruker en koding som er forskjellig fra kodingen som bytematrisen ble opprettet med, vises tolkningen som søppel. Tegnsett (tegnsett) er kodingsformater som vanligvis brukes av nettlesere. Codepage-egenskapen, som er mer aktuell for konverteringer på serversiden, er bare en konverteringstabell som angir hvordan tegn kodes.

Nettlesere koder skjemainnleggsdataene i henhold til gjeldende tegnsett. Hvis det gjeldende tegnsettet er "windows-1256", kodes byteoverføringen til serveren også som "windows-1256".

Når ASP tolkes, bygges ikke skjema- og spørringsstrengsamlingene før de refereres til i kode. Når de bygges, transformeres strengdataene til Unicode i henhold til gjeldende kodeside. (Som standard behandler både ASP og ASP.NET innhold ved hjelp av Unicode-format). Det er svært viktig at du angir riktig kodeside før du refererer til samlingene. Ellers vil ikke Unicode-representasjonen i minnet være riktig.

Hvis du vil angi en kodeside, bruker du Session.Codepage eller Response.Codepage. Response.Codepage er bare tilgjengelig i Microsoft Internet Information Services (IIS) 5.1 eller nyere versjoner. Hvis du vil ha informasjon om heltallsverdiene (som tilsvarer tegnsettet) som vi ville angitt disse egenskapene til, kan du gå til følgende Microsoft-webområde:

Gjenkjenning
av tegnsetthttp://msdn2.microsoft.com/en-us/library/Aa752010.aspxHvis du for eksempel vil angi kodesiden for arabisk språk, bruker du følgende kode:

Session.Codepage = 1256

Response.Codepage påvirker bare gjeldende svar. Session.Codepage vil imidlertid påvirke alle svarene fra gjeldende bruker. Når kodesiden angis ved hjelp av én av disse egenskapene og skjema- og spørringsstrengsamlingene bygges, fører denne endringen i gjeldende kodeside til at Response.Write-metoden transformerer Unicode i minnet til gjeldende kodeside. Hvis du vil ha mer informasjon om dette emnet, kan du gå til følgende MSDN-webområde:

Hvis du angir tegntabellen for strengkonverteringer (ASP)http://msdn2.microsoft.com/en-us/library/ms525789.aspxBunnlinjen når det gjelder problemer relatert til tegnsett og kodesider, er det at klienttegnet og serverkodesiden skal samsvare.

Godta språk

Hvis en ASP-utvikler ønsker å vite hvilke språk en bruker har angitt i nettleseren sin, kan utvikleren bruke Request.ServerVariables ("HTTP_ACCEPT_LANGUAGE")-variabelen til å finne listen over språk som brukeren ønsker å lese svaret i (for eksempel engelsk, tysk eller indisk) og rekkefølgen av preferanser som brukeren ønsker å se disse språkene i. I ASP.NET finnes lignende informasjon i Request.UserLanguages-egenskapen som en matrise.
Hvis du vil ha mer informasjon om hvordan du bruker denne informasjonen i ASP-kode, klikker du følgende artikkelnummer for å vise artikkelen i Microsoft Knowledge Base:

229690 Slik angir du ID for nasjonal innstilling for ASP i henhold til språkinnstillingene i nettleseren
 

Vise tegnsett med flere byte i Internet Explorer

Det eneste kodingsformatet som kan vise et multi-byte-tegnsett, er Unicode (UTF-8). Med UTF-8 kan vi vise kyrillisk, indisk og japansk på samme side. Hvis vi ikke bruker UTF-8, kan vi bare vise ett av disse språkene om gangen. Bruk egenskapen Response.CharSet til å angi charset for nettleseren.

Statiske tegn med flere byte på en side

Hvis du vil vise tegn med flere byte som er lagret direkte på siden, må vi først lagre siden med spesifikk koding. UTF-8 vil være best, men en bestemt kodeside (som samsvarer med tegnenes kodeside) vil også fungere.

Det hjelper ikke å lagre en ASP-fil ved hjelp av Microsoft Visual InterDev her, siden Visual InterDev bare kan lagre på engelsk eller unicode for ANSI. Alle ASP-sider som lagres som Unicode, støttes ikke av ASP.

I Microsoft Visual Studio .NET kan du lagre en fil i en hvilken som helst koding. Det finnes to måter å gjøre dette på. Standardmåten er å lagre filen ved hjelp av gjeldende kodeside for brukeren. En ekstra måte å lagre en fil med en koding på, er som følger:
Klikk Lagre fil som på Fil-menyen.
Klikk rullegardinpilen på
Lagre-knappen i dialogboksenLagre fil som. Når du klikker pilen, er
alternativeneLagre og Lagre med koding. Når du klikker
Lagre med koding, vises dialogboksen Avanserte lagringsalternativer der du kan velge hvilken type koding du vil bruke, fra en liste over kodesidene som er installert på datamaskinen.


Obs! Dette endrer kodingen for lagringsoperasjonen, men bare for én gang. Neste lagring settes tilbake til standardinnstillingen.

Hvis du vil endre standard kodeside, klikker du Avanserte lagringsalternativer på
Fil-menyen . I dialogboksen Avanserte lagringsalternativer kan du angi standardkoding for lagringsoperasjoner til ønsket kodeside.

Disse metodene er relatert til hvordan filen lagres på disken. Hvis du vil kontrollere utdataene for ASP, som vi allerede har diskutert, må vi imidlertid angi egenskapene Session.CodePage og Response.CharSet. Med IIS 5.1 og nyere versjoner kan vi også bruke Response.CodePage-egenskapen.

Standard CODEPAGE på server

Standard nasjonale innstillinger og standard tegntabell for siden avhenger av registerinnstillingene for . STANDARDbruker. Vi kan finne den internasjonale nøkkelen på register hive HKEY_USERS\.DEFAULT\Control Panel\International. Vi kan også endre virkemåten til den nasjonale innstillingen som velges av IIS.

Hvis den påloggede brukeren har samme nasjonale innstilling angitt som nøkkelen ovenfor eller systemstandarden, har brukerinnstillingen prioritet.

Eksempel: Standard nasjonal innstilling har datoformat angitt som 11.1.2004, mens den påloggede brukeren (med samme nasjonale innstilling) har datoformatet som 01.01.2004. Innstillingen 11/1/2004 trer i kraft for ASP.

(For ASP.NET kan dette variere. I noen installasjoner har ASPNET-brukeren sin egen profil som vises under HKEY_USERS når den lastes inn. I andre vil den bruke . STANDARDprofil. Vi kan også bruke attributtet for kodeside i <%@ %> deklarasjon. Dette bør brukes når filen lagres med en annen koding, for eksempel kodeside 932 (japansk)).

Problemer med kodeside kontra problemer med skriftkonvertering: hvilken er hvilken?

Noen ganger kan det hende du ser et spørsmålstegn (?) eller en boks der et tegn skal vises.

Kodingsendringer for kjøretid

I Application_BeginRequest-hendelsen kan vi endre verdien av requestEncoding og få den til å tre i kraft før forespørselen behandles. For svaret er Page_PreRender-hendelsen siste sjanse til å endre kodingen av utdataene. Vær også oppmerksom på at Response.Write legger tegn i denne bufferen så snart vi kaller det, så pass på at du har riktig koding angitt før du bruker Response.Write.

Opprinnelige data er ikke Unicode: Hvordan få Internet Explorer til å tolke tegnsett med flere byte?

Vi kan også få ASP.NET til å oppføre seg som ASP hvis det er nødvendig. For at dette skal skje, må vi angi responseEncoding og requestEncoding til windows-1252 (en mer fullstendig koding enn iso-8859-1), og bruke Response.Charset-egenskapen til å vise teksten riktig. Dette fungerer fordi windows-1252 er et enkelt bytekodingsoppsett, og endrer ikke byte som legges til i bufferen. Derfor sendes dobbelbyte-tegn som en serie med enkeltbyte. Vi kan deretter fortelle Internet Explorer hvordan du tolker byte ved hjelp av Response.Charset-egenskapen. Dette scenarioet kan være nødvendig hvis de opprinnelige dataene ikke er lagret som Unicode eller UTF-8, for eksempel en returverdi fra et COM-objekt, eller hvis dataene er lagret i Microsoft SQL Server i et ikke-N-felt (for eksempel varchar).

SQL Server og ASP.NET globaliseringsproblemer

INSERT INTO MusicAlbum (Album_ID, [Year], Name, Artist_ID, Company_ID) VALUES (12345, 2005, N'Abida', 4653, 403)
Or:
Dim t As String = "INSERT INTO MusicAlbum(Album_ID, [Year], Name, Artist_ID, Company_ID) VALUES (12345, 2005, N'" & TextBox1.Text & "', 4653, 403)"

System.Globalization-navneområde

Dette navneområdet er kjernen i globalisering og lokalisering i .NET Framework. Hovedklassen som brukes i dette navneområdet, er CultureInfo-klassen. Den inneholder kulturspesifikk informasjon, for eksempel dato/klokkeslett-format, tallformater, sammenligningsinformasjon og tekstinformasjon. Hvis du vil ha mer informasjon om CultureInfo-klassen, kan du gå til følgende MSDN-webområde:

http://msdn2.microsoft.com/en-us/library/system.globalization.cultureinfo(vs.71).aspxCultureInfo

Nøytrale kulturer kontra spesifikke kulturer

En nøytral kultur er en kultur som er knyttet til et språk, men ikke et bestemt land/område. En bestemt kultur er knyttet både til et språk og et bestemt land/område.

Et eksempel: "DE" (nøytral kultur) er for det tyske språket, men "de-AT" (spesifikk kultur) er for det tyske språket som det snakkes i Østerrike. Nøytrale kulturer kan ikke brukes til formatering.

Gjeldende tråd og kulturbevissthet om .NET Framework klasser

Alle klasser og metoder i det .NET Framework biblioteket der vi forventer at utdataene skal være kulturavhengige, har to innebygde virkemåter:

• De lar oss angi kulturkoden mens vi oppgir argumentene, slik at utdataene er basert på den angitte kulturen. Dette er valgfritt.

• Hvis dette går tapt (vanligvis er det det), er klassene intelligente nok til å holde en kontroll på Thread.CurrentThread.CurrentCulture-egenskapen og fungere i henhold til dette.

Vi kan endre denne egenskapens verdi med kode som ligner på følgende:

    Dim ci As CultureInfo
        ci = New CultureInfo("de-AT")
        Thread.CurrentThread.CurrentCulture = ci

I dette kodeeksemplet representerer «de» det tyske språket, og «AT» representerer Østerrike. Så i dette tilfellet datetime.now(). ToString-metoden returnerer datoen og klokkeslettet i et format som tilsvarer måten dato og klokkeslett uttrykkes på tysk i Østerrike.

Rammeverket sikrer (som følger) at CurrentCulture-egenskapen alltid er initialisert:

1. Uansett hva det er satt til programmatisk.

2. I tilfelle den ikke er eksplisitt angitt av programmereren, velges egenskapen fra konfigurasjonsfilene (<globalisering> merke).

3. Hvis egenskapen mangler der, er det kulturen som webserveren kjører på. Dette er vanligvis den nøytrale kulturen som tilsvarer operativsystemets språk.

Ressursfiler

Alle RESX-, .resource-filer og -filer som har build action-attributtet satt til Embedded Resource som legges til i et ASP.NET-prosjekt i Visual Studio .NET, kompileres og bygges inn automatisk i programsamlingen som en del av manifestet. Dette kan også gjøres manuelt ved hjelp av verktøyet Ressursfilgenerator (RESGEN) via en Visual Studio .NET-ledetekst. Hvis du vil ha mer informasjon, kan du gå til følgende MSDN-webområde:

http://msdn2.microsoft.com/en-us/library/ccec7sz1(vs.71).aspxDette er et generelt konsept som er aktuelt når vi trenger å administrere programressurser som ikke er relatert til globaliseringen. Men når vi implementerer globalisering, bør vi bruke satellittsamlinger.

Satellittsamlinger

Satellittsamlinger kan brukes i et ASP.NET prosjekt når du kontrollerer at følgende er oppfylt:

1. Alle elementene i brukergrensesnittet i alle aspx-filer må være utstyrt med ID- og runat=serverattributter.

2. Vi oppretter separate RESX-filer. Hver av dem må samsvare med hver kultur vi ønsker at programmet vårt skal støtte.

3. Vi må bestemme et vanlig fornavn for alle disse filene for ex. "Strenger".

4. Vi gir navn til de separate RESX-filene med følgende navnekonvensjon commonfirstname. languagecode-regioncode.resx (for eksempel: Strings.de-AT.resx, Strings.en-GB.resx ).

5. Vi bør ha ressursfilen
   commonfirstname.resx (Strings.resx) som har alle strengene slik vi ønsker vist i standardtilfellet.

6. Skriv kode for å oppdage brukerens kultur og angi thread.CurrentThread.CurrentUICulture-egenskapen slik at den samsvarer med den.

7. Skriv kode for å laste inn ressursene ved hjelp av ResourceManager-klassen.

8. Skriv kode for å trekke ut strenger fra det innlastede objektet, og tilordne dem til elementer i brukergrensesnittet.

Når du har utført disse trinnene, kompilerer Visual Studio.NET Strings.resx og bygger den inn i programsamlingen (MyGlobalizationTestProjectName.dll). For alle andre RESX-filer vil det imidlertid generere separate DLL-filer som ikke har kjørbar kode, men bare ressursdata. Disse kalles faktisk satellittsamlinger. Visual Studio .NET plasserer også disse i mappestruktur som ligner på følgende: MyGlobalizationTestProjectName
|------- bin
|------en-US

MyGlobalizationTestProjectName.resources.dll |------ja-JP

MyGlobalizationTestProjectName.resources.dll |------de-AT
MyGlobalizationTestProjectName.resources.dll

Forskjellen mellom CurrentCulture og CurrentUICulture

Selv om metodene for klasser i system.globaliseringsnavneområdet avhenger av Thread.CurrentThread.CurrentCulture-egenskapen for å gi utdataene, avhenger ResourceManager-klassen som laster ressurssamlingen, av thread.CurrentThread.CurrentUICulture-egenskapen for å laste inn riktig satellittsamling. Følgende er et eksempel på C#-kode:

using System.Globalization;
using System.Threading;
using System.Resources;

//Load resources. 
protected ResourceManager gStrings = new ResourceManager("MyGlobalizationTestProjectName.strings", typeof(MyTestWebFormName).Assembly);

// Get the user's preferred language.
string sLang = Request.UserLanguages[0];
// Set the thread's culture for formatting, comparisons, etc.   
Thread.CurrentThread.CurrentCulture =  CultureInfo.CreateSpecificCulture(sLang);
// Set the thread's UICulture to load resources
// from satellite assembly.
Thread.CurrentThread.CurrentUICulture = new CultureInfo(sLang);

private void Page_Load(object sender, System.EventArgs e) 

{ 

 if (!IsPostBack)  

 {      
// Get strings from resource file and assign to UI elements.
head1.InnerHtml = gStrings.GetString("satellite.head1");
p1.InnerHtml = gStrings.GetString("satellite.p1");
sp1.InnerHtml = gStrings.GetString("satellite.sp1");
sp2.InnerHtml = gStrings.GetString("satellite.sp2");
butOK.Text = gStrings.GetString("satellite.butOK");
butCancel.Value = gStrings.GetString("satellite.butCancel");
   }

 }

Rekkefølgen ASP.NET velger satellittsamlinger i:

Når du har angitt trådens CurrentUICulture, velger ASP.NET automatisk ressursene som samsvarer, i følgende rekkefølge:

• Hvis en satellittsamling blir funnet med en samsvarende kultur, brukes ressursene fra samlingen.

• Hvis en satellittsamling blir funnet med en nøytral kultur som samsvarer med CurrentUICulture, brukes ressurser fra denne samlingen.

• Hvis det ikke blir funnet et treff for CurrentUICulture, brukes tilbakefallsressursene som er lagret i den kjørbare samlingen.

Obs! Dette er basert på den mer generelle tilbakefallsprosessen for ressurser. Hvis du vil ha mer informasjon, kan du gå til følgende MSDN-webområde:

http://msdn2.microsoft.com/en-us/library/sb6a8618(vs.71).aspx

Opprette satellittsamlinger manuelt:

Denne bruken av satellittsamlinger er der Visual Studio .NET oppretter selve samlingene. Visual Studio .NET gir imidlertid ikke sterke navn til satellittsamlinger som standard. Hvis du vil endre disse alternativene, må du opprette satellittsamlinger manuelt. Hvis du vil ha mer informasjon, kan du gå til følgende MSDN-webområde:

http://msdn2.microsoft.com/en-us/library/21a15yht(vs.71).aspx .

Ordliste

ANSI står for American National Standards Institute. I denne konteksten representerer den en bestemt kodeside for et bestemt språk/tegnsett. Refererer oftest til den engelske kodesiden (windows-1252).

ASCII A 1 byte (eller 7-biters) kodingsoppsett. Bare tegnene i området 0-127 er standardisert. Området 128-255 er utvidelser til ASCII og ikke en del av standarden. Et eksempel på dette er forskjellen mellom det øvre området i OEM ASCII-diagrammet og VB ASCII-diagrammet.

CharSet-innstilling som hovedsakelig brukes for Internet Explorer og nettlesere som forteller nettleseren hvordan tegndataene skal tolkes. Eksempel: Response.charSet = "iso-8859-1."

Kodeside En konverteringstabell som angir hvordan tegn kodes (brukes vanligvis for servere).

Globalisering globalisering er en prosess for utforming og oppretting av et program, slik at de unike kravene til kultur, område eller nasjonale/regionale og lingvistiske behov kan oppfylles. Det å utforme et program på en måte som kan lokaliseres senere, er med andre ord globalisering.

Språk for nasjonal innstilling/kultur og områdespesifikke formater/innstillinger, inkludert dato- og kalenderformater, tidsformater, valutaformater, casing, sortering og strengsammenligning, adresseformater, telefonnummerformater, papirstørrelser, måleenhet, skriveretning osv.

LocaleID (LCID) En DWORD-verdi som angir språkidentifikatoren og sorterings-ID-en. Den kan brukes til å angi de spesifikke områdeformatene for ex dato/klokkeslett osv. skal formateres i henhold til.

Localizability Ability of an application to present content for the demanded language/locale.

Lokaliseringslokalisering er prosessen med å oversette et brukergrensesnitt til bestemte språk og/eller nasjonale innstillinger.

Flerbyte-tegnsett Et tegnsett der tegnene består av to eller flere byte, for eksempel japansk. UTF-8 faller også under denne kategorien. (Unicode er teknisk sett i denne kategorien, men i Windows har den sin egen kategori.)

Unicode A 2-byte encoding scheme. Windows bruker Unicode internt. Alle API-er spesielt for Unicode er angitt av en W på slutten av funksjonsnavnet. Også kjent som bredt tegn; kan ikke brukes direkte fra webprogrammer.

UTF-8 A-tegnkoding der et tegn kan representeres med 1-6 byte. I Windows er området 1-3 byte. Støttes ikke under NT4 for webprogrammer.



Bredt tegnsett Et alias for Unicode. Også kjent som DBCS (dobbeltbyte-tegnsett), UCS-2, UTF-16.

Som alltid kan du gjerne sende inn ideer om emner du vil ta opp i fremtidige kolonner eller i kunnskapsbasen ved hjelp av Be om det-skjemaet.