Globalisering problemer i ASP- og


ASP.NET-støtte stemme-kolonne


Vi inviterer deg til å sende dine ideer om emner som interesserer deg. Hvis du vil tilpasse denne kolonnen til dine behov, og problemer som du ønsker å se i fremtidige adressert Knowledge Base-artikler og støtte stemme-kolonner. Du kan sende dine ideer og tilbakemeldinger ved hjelp av skjemaet Ber For den . Det finnes også en kobling til skjemaet nederst i denne kolonnen.

Introduksjon


velkommen! Dette er Sukesh Khare med støtte for Microsoft ASP.NET-utviklere-gruppen. Dette er første gang jeg har skrevet en støtte stemme-kolonne. Jeg ser frem til å redigere flere slike kolonner i måneder fremover.

For denne månedens kolonne skal jeg diskutere problemer med globalisering i Active Server Pages (ASP) og ASP.NET, problemene vi står overfor i ASP, hvordan ting har endret seg i ASP.NET 1 x, og hva har skjedd med ASP.NET 2.0 globalisering foran.

Obs! Hvis du kommer over et ord du ikke forstår, kan du se under ordliste nederst i denne kolonnen.

Globalisering problemer i ASP

Det var ingen strukturerte støtte for utvikling av programmer for globale brukere før ASP.NET. Under den tidlige utviklingen av ASP spredt utviklere som selv finner bare støtte for globalisering i operativsystemer, lesere, ASPer og baksystemer. Men observert vi sjelden en automatisk tilkobling på tvers av disse programmene. Heldigvis Vi forstår begreper som for eksempel tegnsett, tegntabeller, leseren språk og skrifter som vi kan dra nytte av utviklingen av programmer for globale brukere.

Det vil være vanskelig å skille i kategorier som alle globalisering problemer med oss i ASP.NET har sett. I stedet vil jeg liste over en rekke konsepter som er knyttet til en rekke av disse problemene.

Tegn sett og tegntabeller

Vi vet alle at tegnene på våre dataskjerm er en serie byte. Byte-serien kan opprettes og tolkes på mange måter. Hvis tolkningen bruker en kode som er forskjellig fra kodingen som byte-matrise ble opprettet med, vises tolkningen som ugyldige. Tegnsett (charsets) er koding formatene som vanligvis brukes av weblesere. Codepage -egenskapen, som er mer tilgjengelig for serversiden konverteringer, er en konverteringstabell som angir hvordan tegn er kodet.

Lesere kode post skjemadata i henhold til gjeldende tegnsett. Hvis gjeldende tegnsett er "windows 1256", deretter kodes overføring byte serveren også som "windows-1256."

Når ASP tolkes, bygges ikke skjemaet og Querystring -samlingen før de blir referert til i kode. Når de er under bygging, transformeres dataene streng til Unicode i henhold til gjeldende codepage. (Som standard både ASP- og behandle innhold ved hjelp av Unicode-format). Det er svært viktig at du angir riktig kodesiden før refererer til samlingene; Hvis ikke, Unicode-representasjon i minnet ikke riktig.

Hvis du vil angi en tegntabell, bruker du Session.Codepage eller Response.Codepage. Response.Codepage er bare tilgjengelig i Microsoft Internet Information Services (IIS) 5.1 eller senere versjoner. Du finner informasjon om heltallsverdier (som samsvarer med tegnsettet) at vi setter disse egenskapene, kan du gå til følgende Microsoft-webområde:Hvis du for eksempel vil angi kodesiden for arabisk språk, kan du bruke følgende kode:
Session.Codepage = 1256
Response.Codepage påvirker bare gjeldende svar. Session.Codepage påvirker imidlertid alle svar som er gjort av gjeldende bruker. Når kodesiden som angis ved hjelp av ett av disse egenskapene, og skjemaet og Querystring -samlingen er bygget, forårsaker denne endringen i den gjeldende codepage Response.Write -metoden til å transformere Unicode i minnet til gjeldende tegntabell. Hvis du vil ha mer informasjon om dette emnet, kan du gå til følgende MSDN-webområde:
Angi kodeside for streng konverteringer (ASP)http://msdn2.microsoft.com/en-us/library/ms525789.aspx
Den totale når det gjelder problemer som er knyttet til charsets og tegntabeller er tegnsettet som klient og server codepage må samsvare.

Godta språk

Hvis en ASP-utvikler vil vite hvilket språk en bruker har satt i hans webleseren, kan utvikleren bruke Request.ServerVariables ("HTTP_ACCEPT_LANGUAGE") -variabelen til å finne listen over språk som brukeren ønsker å lese svaret, (for eksempel engelsk, tysk eller indiske) og prioritetsrekkefølge som brukeren vil se disse språkene i. I ASP.NET finnes lignende informasjon i egenskapen Request.UserLanguages som en matrise.
Hvis du vil ha mer informasjon om hvordan du bruker denne informasjonen i ASP-kode, kan du klikke følgende artikkelnummer for å vise artikkelen i Microsoft Knowledge Base:
229690 hvordan du angir ASP-ID for nasjonal innstilling per leserens Språkinnstillinger

Vise multibyte-tegn angir i Internet Explorer

Bare kodeformatet som kan vise et multibyte-tegnsett er Unicode (UTF-8). Vi kan vise kyrillisk, indiske og japansk med UTF-8, alle på samme side. Hvis vi ikke bruker UTF-8, kan vi bare vise ett av disse språkene om gangen. Hvis du vil angi tegnsettet i leseren, kan du bruke Response.CharSet -egenskapen.

Statisk multibyte-tegn på en side

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

Lagring av en ASP-fil ved hjelp av Microsoft Visual InterDev hjelpe ikke her, siden Visual InterDev kan bare lagre i engelske ANSI- eller Unicode. En ASP-side som er lagret som Unicode ikke støttes av ASP.

Du kan lagre en fil i en hvilken som helst kode i Microsoft Visual Studio .NET. Det er to måter å gjøre dette. Standarden er måten å lagre filen ved hjelp av gjeldende tegntabell for brukeren. En ekstra måte å lagre en fil med en koding er som følger:
Klikk Lagre somfil -menyen. I den
Lagre som -dialogboksen klikker du rullegardinpilen på den
Lagre -knappen. Når du klikker pilen, er alternativene
Lagre og Lagre med koding. Når du klikker
Lagre med koding, Avanserte lagre alternativer -dialogboksen vises der du kan velge hvilken type koding du vil bruke fra en liste over tegntabeller som er installert på datamaskinen.


Obs! Dette endrer koding for å lagre operasjonen, men er for bare én gang. Neste lagre settes tilbake til standard.

Hvis du vil endre standard tegntabell, klikker du Avanserte alternativer for Lagre på den
Fil -menyen. Du kan angi standardkoding for å lagre operasjoner til kodesiden som du velger i dialogboksen Avanserte alternativer for Lagre .

Disse metodene er relatert til hvordan filen er lagret på disken. Vi må imidlertid angi Session.CodePage og Response.CharSet -egenskaper for å kontrollere utdata for ASP, som allerede er omtalt. Med IIS 5.1 og senere versjoner, kan vi også bruke egenskapen Response.CodePage .

Standard tegntabell på serveren

Standard nasjonal innstilling og standard tegntabell for siden avhenger av registerinnstillingene for den. Standardbrukeren. Vi kan finne internasjonale nøkkelen i registerstrukturen HKEY_USERS\. DEFAULT\Control Panel\International. Vi kan også endre virkemåten for den nasjonale innstillingen som er valgt av IIS. Hvis du vil ha mer informasjon, kan du se delen "IIS 5.0" i følgende Knowledge Base-artikkel:
306044 virkemåte for dato/klokkeslett-formatet er forskjellig når det åpnes fra Active Server Pages

Hvis den påloggede brukeren har samme locale som nøkkelen ovenfor eller systemstandarden, forrang bruker innstillingen.

Eksempel: Standard nasjonal innstilling har sett format som 11.1.2004, samtidig som den påloggede brukeren (med de samme nasjonale) har datoformatet som 11/1/2004. 11/1/2004-innstillingen trer i kraft for ASP.

(For ASP.NET, dette kan variere. ASPNET brukeren har sin egen profil som vises under HKEY_USERS når den er lastet inn i enkelte installasjoner. I andre, vil den bruke den. Standardprofilen. Vi kan også bruke tegntabell-attributt i deklarasjonen < % @ % >. Dette bør brukes når filen er lagret med en annen koding deretter standard, for eksempel Kodeside 932 (japansk)).

CodePage problemer versus Konverteringsproblemer skrift: som er der?

Noen ganger kan det hende du ser et spørsmålstegn (?) eller en boks der et tegn skal vises.
CodePage Konverteringsproblemer
Når et tegn er erstattet med et spørsmålstegn (?), er dette en indikasjon på at det har oppstått et problem med codepage-konvertering. Spørsmålstegnet (?) er et standard tegn for codepage-konvertering, og i utgangspunktet betyr at operativsystemet ikke vet hvordan du håndterer tegnverdien og konvertere den. Tegnverdien erstatter den med et spørsmålstegn (?). Dette kan bety at tegnet har en ugyldig verdi for kodesiden eller at kodesiden som trengs for konvertering ikke er installert.
Konverteringsproblemer med skrift
Når et tegn erstattes av en boks, er dette en indikasjon på at det har oppstått et problem med skriften konvertering. Dette skjer på klientsiden når klienten ikke har riktige skriften installert for å vise dette tegnet på riktig måte. For eksempel når et tegn er fra den japanske tegnsettet, og klienten har ikke de japanske skriftene installert, det japanske tegnet vises som en boks.

Neste, jeg skal snakke om hvordan ting endret i ASP.NET 1.x, og hvordan disse endringene påvirker globalisering problemer i forbindelse med ASP.NET.

Globalisering problemer i ASP.NET 1.x:

Tre fine ble innført med ASP.NET:
  • < Globalisering >-koden i web.config-filen
    Koden < globalisering > tar oss bort fra de usammenhengende begrepene tegntabeller og charsets og lar oss kontrollere de fleste av variantene i ASP.NET.
  • System.Globalization-navneområde
    Globalisering-navneområdet gir oss programmatisk kraften til å håndtere globalisering.
  • Konseptet med ressursfiler er betydelig forbedret.
    Vi håndtere ikke ressursfiler i måten vi brukte til å i ASP. Ressursfilene blir nå, i form av XML-filer når vi utvikle og distribuere dem, og de finnes som setter sammen under kjøring.
Globalisering-Konfigurasjonskode:

To viktige innstillinger i koden er som følger:
<globalization             requestEncoding="utf-8" 
responseEncoding="utf-8" />
Andre mulige innstillinger-områder følger:
fileEncodingAngir standardkoding for aspx, .asmx og analyse av asax-filer. Unicode og UTF-8-filer som er lagret med byte order mark prefikset (med signatur) blir automatisk gjenkjent, uavhengig av verdien av fileEncoding.
KulturAngir standardkulturen for behandling av innkommende webforespørsler (tilgjengelig på metoder for klasser fra navneområdet for System.Globalization).
uiCultureAngir standardkulturen for behandling av ressurssøk som er avhengige ressurssøk (Satellittsamlinger).
Hvis du vil ha mer informasjon om kultur-strenger (verdier av kultur - og uiculture), kan du gå til følgende Microsoft-webområde:Disse innstillingene brukes av ASP.NET etter at svaret er fullført, og før forespørselen er overlatt til programmet. Bufferen som opprettes for å lagre utdataene for responseEncoding, er satt til denne kodingen. Alt som går inn i denne bufferen som skal kodes i henhold til innstillingen når den settes inn i bufferen.

For requestEncoding, kjøretid leser forespørselen, og tolk i samsvar med innstillingen i dette avsnittet. Dette er en innstilling som kan forårsake problemer, men. Tabellen nedenfor viser bit utformingen av en gyldig sekvens for UTF-8-byte.

Hvis tegnverdien faller i ASCII-7-biters som standard, endres ikke byteverdien. Hvis verdien er over 127, må den følge reglene nedenfor. Ledende sett med bits viser hvor mange tegn som er i sekvensen. Hver byte etter først må starte med den første biten settes til 1.

UTF-8-byte-oppsett:
ByteBITSrepresentasjon
170vvvvvvv
211110vvvvv 10vvvvvv
3161110vvvv 10vvvvvv 10vvvvvv
42111110vvv 10vvvvvv 10vvvvvv 10vvvvvv
Her er problemet. Hvis leseren koder forespørselen i henhold til en enkelt byte-koding (for eksempel iso-8859-1), vil ikke verdier over 127 være gyldig i henhold til oppsettet ovenfor. Når de leses inn i UTF-8-buffer, slippes ganske enkelt de ugyldige tegnene fra utdataene.

Runtime koding endringer

Vi kan endre verdien for requestEncoding og at den trer i kraft før forespørselen behandles i hendelsen Application_BeginRequest . Svaret er Page_PreRender -hendelsen siste sjanse til å endre koding for utdata. Også Husk Legg merke til at Response.Write plasseres tegn i denne bufferen som vi kaller det, så å angi den riktige koding før du bruker Response.Write.

Opprinnelige data er ikke Unicode: hvordan du likevel gjøre Internet Explorer tolker multibyte-charsets?

Vi kan også gjøre ASP.NET oppfører seg som ASP Hvis vi skal. Hvis du vil gjøre dette, må vi sette responseEncoding og requestEncoding til windows-1252 (en mer fullstendig koding enn iso-8859-1), og bruk Response.Charset -egenskapen til å vise tekst på riktig måte. Dette virker fordi windows-1252 kodeoppsettet som en enkelt byte, og endrer ikke alle byte som er lagt til bufferen. Dermed sendes dobbeltbyte-tegn som en serie med enkel byte. Vi kan deretter se Internet Explorer slik tolker byte ved hjelp av Response.Charset -egenskapen. Dette scenariet 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 en ikke-N-feltet (for eksempel varchar).

Problemer med SQL Server og ASP.NET globalisering

Unicode-inndata til SQL Server
Den beste måten å lagre data i SQL Server skal bruke Unicode. Når vi bruker INSERT, UPDATE og så videre, hvis det er enda en minst sjanse for Unicode-data, må vi legge til en N før verdien. Dette forteller databasen at verdien er Unicode. Et godt eksempel på dette er ADO-objekter. De gjør dette automatisk hvis vi bruker Recordset -objektet til å legge til nye poster.

Følgende er et eksempel:
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)"

Dato/klokkeslett for SQL Server
Vanligvis har vi fått kunnskapen om kultur og nasjonale innstillinger for dato og klokkeslett blir tolket i våre ASP.NET-program. Men mens du skyver og drar dato/klokkeslett-data til og fra eksterne kilder, risikerer vi misinterpreting dato/klokkeslett-formater. Dette er fordi vi ikke kan alltid garantere kultur og nasjonale innstillingene på den eksterne kilden skal være det samme som i vårt program. SQL Server kan dette løses ved hjelp av ' gjeldende språk' attributt i connectionstring av forbindelsen blir etablert til SQL-databasen. Vi kan gi samme språkinnstillingen i connectionstring som er kultur i vårt program. Dette beskytter oss fra risikoen for misinterpretation, fordi SQL Server godtar alltid og sender datatypen Dato/klokkeslett i samtykke med innstillingen nevnt ovenfor.

Navneområdet for System.Globalization

Dette navneområdet er kjernen av globalisering og lokalisering i .NET Framework. Viktigste klassen som brukes i dette navneområdet er CultureInfo -klasse. Den inneholder kultur-spesifikk 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:

Nøytral kulturer i forhold til spesifikke kulturer

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

Eksempel: "DE" (nøytrale kulturen) for tysk språk, men "de-AT" (bestemt kultur) er for det tyske språket som den er talte i Østerrike. Nøytral kulturer kan ikke brukes til formatering.

Gjeldende tråd og kultur forståelsen av .NET Framework-klasser

Alle klasser og metoder i .NET Framework-biblioteket der vi forventer utdataene skal kultur-avhengige har to innebygde virkemåter:
  • De la oss angi Kulturkode ved å angi argumentene slik at utdataene er basert på den angitte kulturen. Dette er valgfritt.
  • Hvis dette ble hoppet over (vanligvis er det), klassene er intelligent nok til å holde en sjekk på egenskapen Thread.CurrentThread.CurrentCulture og arbeid i henhold til som.
Vi kan endre verdien for denne egenskapen med kode som ligner på følgende:
    Dim ci As CultureInfo        ci = New CultureInfo("de-AT")
Thread.CurrentThread.CurrentCulture = ci
I dette kodeeksemplet "de" representerer tysk språk, og "AT" representerer Østerrike. Så i dette tilfellet DateTime.Now(). ToString -metoden returnere ville dato og klokkeslett i et format som tilsvarende måten datoen og klokkeslettet er uttrykt i det tyske språket i Østerrike.

Rammeverket sørger (slik) at egenskapen CurrentCulture er alltid initialisert:
  1. Uansett hva det er satt til et program.
  2. I tilfelle det ikke er eksplisitt angitt som programmereren, egenskapen plukkes fra konfigurasjonsfilene (< globalisering >-koden).
  3. Hvis egenskapen ikke finnes der, er det kulturen som Web-serveren kjører. Dette er vanligvis den nøytrale kulturen som samsvarer med språket for operativsystemet.

Ressursfiler

Alle RESX, .resource filer og filer som har Bygge Action -attributtet satt til Embedded ressurs som legges til en ASP.NET-prosjekt i Visual Studio .NET, er kompilert og automatisk innebygd i samlingen av programmet som en del av manifestet. Dette kan også gjøres manuelt ved hjelp av verktøyet ressurs fil Generator (RESGEN) via en ledetekst for Visual Studio .NET. Hvis du vil ha mer informasjon, kan du gå til følgende MSDN-webområde:Dette er et generelt begrep som brukes når vi skal behandle program-ressurser som er relatert til globalisering. Når vi er implementering av globalisering, bør vi bruke satellittsamlinger.

Satellittsamlinger

Satellittsamlinger kan brukes i et ASP.NET-prosjekt når du kontrollere at følgende betingelser er oppfylt:
  1. Alle brukergrensesnittet elementer i alle aspx-filer må være utstyrt med id og runat = server-attributter.
  2. Vi opprette separate RESX-filer. Hver av dem må samsvare med hver kultur vi ønsker vårt program for å støtte.
  3. Vi må bestemme et felles Fornavn for disse filene for eksempel 'Strenger'.
  4. Vi navngi separat RESX-filer med følgende naming convention commonfirstname. languagecode-regionkodeRESX (for eksempel: Strings.de-AT.resx, Strings.en-GB.resx).
  5. Vi skal ha ressursfilen
    commonfirstnameRESX (Strings.resx) som har alle strengene som vi vil vises i tilfelle standard.
  6. Skriv kode for å finne brukerens kultur og angi egenskapen Thread.CurrentThread.CurrentUICulture tilsvarende til den.
  7. Skriv kode for å laste inn ressursene ved å bruke ResourceManager -klasse.
  8. Skrive kode for å trekke ut tekststrenger fra det lastede objektet, og tilordne dem til elementer i brukergrensesnittet.
Når du har utført disse trinnene, vil Visual Studio.NET kompilere Strings.resx og bygge den inn i programsamlingen (MyGlobalizationTestProjectName.dll). For alle andre RESX-filer, vil det imidlertid generere separat DLL-filer som ikke har en kjørbar kode, men bare ressursdata. Disse faktisk kalles satellittsamlinger. Visual Studio .NET plasserer også disse i mappestrukturen 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

Mens metoder med klasser i System.Globalization -navneområdet avhenger av egenskapen Thread.CurrentThread.CurrentCulture til å gi sine utdata, ResourceManager -klassen som laster inn ressurs-samling, avhenger av egenskapen Thread.CurrentThread.CurrentUICulture for å laste inn den riktige Satellittsamlingen. 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");
}

}

Ordre som ASP.NET velger Satellittsamlinger:

Når du har angitt trådens CurrentUICulture, velge ASP.NET automatisk ressurser som samsvarer med, i følgende rekkefølge:
  • Hvis det finnes en satellitt-samling med en samsvarende kultur, brukes ressurser fra samlingen.
  • Hvis det finnes en satellitt-samling med en nøytral kultur som samsvarer med CurrentUICulture, brukes ressurser fra samlingen.
  • Hvis det ikke blir funnet et samsvar for CurrentUICulture, brukes "fallback" ressurser som er lagret i kjørbare samlingen.
Obs! Dette er basert på mer generelle ressursen "fallback"-prosessen. Hvis du vil ha mer informasjon, kan du gå til følgende MSDN-webområde:

Manuelt opprette Satellittsamlinger:

Denne Satellittsamlinger brukes der Visual Studio .NET oppretter samlingene seg selv. Visual Studio .NET ikke imidlertid sterkt navn 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:.

Hva har skjedd med ASP.NET 2.0 foran globalisering?

Utstrakt bruk av ASP.NET og hva slags problemer som vi vil se i forhold til globaliserings-funksjoner i ASP.NET 2.0 er fortsatt noen avstand foran. Det vil imidlertid være lurt å ta en kort titt på hvilken retning globaliserings-metodikken forfatternavnet for web-applikasjoner.

Globalisering-støtte i ASP.NET 2.0 har gjennomgått en radical endring og Web-utviklere har fått muligheten til å gjøre det så enkelt som det er for Windows-baserte programmer lokalisering av Web-applikasjoner. Følgende er en liste over funksjoner som er grunnlaget for globalisering-metodikken i ASP.NET 2.0:

Sterkt skrevet inn ressurser I kjernen av .NET Framework 2.0 utgaven er støtte for sterkt skrevet ressurser som gir utviklere med Intellisense og forenkler koden som kreves for å få tilgang til ressurser på kjøretidspunktet.

Administrerte ressurs Editor Visual Studio .NET 2.0 inkluderer en ny ressurs editor med bedre støtte for å opprette og administrere ressurspostene inkludert strenger, bilder, eksterne filer og andre komplekse typer.

Ressurs-generering for Web-skjemaer Windows Forms-utviklere har allerede fordelene med automatiske internasjonale. Visual Studio .NET 2005 støtter nå rask internasjonale ved automatisk generering av ressurser for Web-skjemaer, bruker kontrollene og hoveddokumenter.

Forbedret støtte for kjøring ResourceManager forekomster er administrert av kjøretiden og lettere tilgjengelig for Serverkoden gjennom mer tilgjengelige programmeringsgrensesnittene.

Uttrykk for lokalisering Moderne deklarativ uttrykk for Web-sider støtter tilordning ressurspostene for å kontrollere egenskaper, egenskaper for HTML eller statisk innholdsområder. Disse uttrykkene kan også utvides, som gir flere måter å styre prosessen med å legge lokalisert innhold i HTML-utdata.

Automatisk kultur-valg Behandle kultur valg for hver webforespørsel kan kobles automatisk til innstillinger for Web-leseren.

Ressurs-leverandøren modell En ny ressurs leverandøren modell kan utviklere vert ressurser i alternative datakilder, for eksempel flate filer og databasetabeller, mens programmeringsmodell for å få tilgang til disse ressursene forblir konsekvent.

Hvis du vil ha mer informasjon om globalisering-metodikken i ASP.NET 2.0, kan du gå til følgende MSDN-webområde:
ASP.NET 2.0 lokalisering funksjoner: En ny tilnærming til å lokalisere Web-applikasjoner
http://msdn2.microsoft.com/en-us/library/ms379546(VS.80).aspx

Konklusjon

Det er alt for nå om globalisering problemer i ASP- og ASP.NET. Jeg håper denne artikkelen vil hjelpe noen kunder som feilsøker sine globalisering problemer i ASP- og før de velge for å kontakte Microsoft Support. Jeg vil avslutte med følgende tenkte:

"Hvor som helst og når du utvikler, synes om millioner av mennesker som du kan gi over hele verden. Gjør dine løsninger klar for verden! Microsoft-verktøy og teknologier enklere internasjonale."

Vi vil oppdatere deg på nytt neste måned med en annen interessant emne.

Takk for din tid.
Hvis du vil ha mer informasjon om problemer med globalisering i ASP- og ASP.NET, kan du se følgende Microsoft-webområder:
Går Global: Lokalisering dynamisk Web Apps med IIS 5.0 og SQLServer
http://msdn.microsoft.com/msdnmag/issues/01/05/global/default.aspx
Går Global: Utforme ASP-baserte Web-området til å støtte globalisering
http://msdn.microsoft.com/msdnmag/issues/0700/localize/default.aspx
315616 hvordan du gjenkjenner et klientspråk i en Active Server Pages-side i IIS
http://support.microsoft.com/?id=315616
Ressurser og lokalisering ved hjelp av .NET Framework SDK
http://msdn2.microsoft.com/en-us/library/aa309421(VS.71).aspx
ASP.NET < globalisering > konfigurasjon element
http://msdn2.microsoft.com/en-us/library/hy4kkhe0(vs.71).aspx
Design og implementering retningslinjer for Web-klienter - globalisering og lokalisering
http://msdn2.microsoft.com/en-us/library/ms978628.aspx
Offisielle Microsoft-område – Global utvikling og databehandling Portal
http://msdn.microsoft.com/en-us/goglobal/bb688096
Arkitekturen for globalisering for ASP.NET
http://msdn2.microsoft.com/en-us/library/aa478974.aspx
Enterprise lokalisering Toolkit - For å utvikle lokalisert Microsoft ASP.NET-programmer
http://msdn2.microsoft.com/en-us/library/aa479334.aspx
Microsofts webområde for typografi
http://www.microsoft.com/typography/default.mspx
839861 A System.Resources.MissingManifestResourceException-unntak oppstår når du prøver å få tilgang til en lokalisert ressurs

Ordliste

ANSI Står for American National Standards Institute. Den representerer en bestemt codepage for et bestemt språk/tegnsett i denne konteksten. Oftest refererer til den engelske codepage (windows-1252).

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

CharSet Innstillingen brukes hovedsakelig for Internet Explorer og lesere som forteller webleseren hvordan du skal tolke tegndataene. Eksempel: Response.charSet = "iso-8859-1."

CODEPAGE Konverteringstabell som angir hvordan tegn er kodet (brukes vanligvis for servere).

Globalisering Globalisering er en prosess for å utforme og opprette et program slik at de spesifikke kravene på en kultur, region eller nasjonale og lingvistiske behov kan oppfylles. Med andre ord utforming av et program på en måte at det kan være lokalisert senere er globalisering.

Nasjonale innstillinger/kultur Språk og region bestemte formater/innstillinger-inkludert, dato og kalenderformatene, klokkeslettformater, valutaformater, magnesiumlegering, sortering og strengsammenligning, adresseformatene, telefon tallformater, papirstørrelser, Enhetskode, skriving retning og så videre.

ID for nasjonal innstilling (LCID) En DWORD-verdi som angir språk-IDen og sorterings-ID. Den kan brukes til å angi en bestemt region-formater for ex dato/klokkeslett osv skal formateres i henhold til.

Localizability Muligheten for et program til å presentere innholdet for den etterspurte språk og nasjonale innstillingen.

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

Multibyte-tegnsett Et tegn angitt i tegnene er sammensatt av to eller flere byte, for eksempel japansk. UTF-8 er også faller under denne kategorien. (Unicode er teknisk sett i denne kategorien, men den har en egen kategori i Windows.)

Unicode En 2-byte-kodeoppsettet. Windows bruker Unicode internt. Alle APIene spesielt for Unicode er markert med en "W" på slutten av funksjonsnavnet. Også kjent som bredt tegn; kan ikke brukes direkte fra web-applikasjoner.

UTF-8 En tegnkoding der et tegn kan representeres av 1-6 byte. I Windows er området 1-3 byte. Støtter ikke under NT4 for web-applikasjoner.
Hvis du vil ha mer informasjon, kan du klikke følgende artikkelnummer for å vise artikkelen i Microsoft Knowledge Base:
175392 UTF8-støtte


Stort tegnsett Et alias for Unicode. Også kjent som DBCS (dobbelbyte-tegnsett), UCS-2, UTF-16.
Som alltid, sende inn ideer om emner du vil gjerne omtalt i fremtidige kolonner eller i kunnskapsbasen ved hjelp av
Be For det skjemaet.