Unicode Normalisering i Windows

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har brugt 'unicode strings' i Windows så længe ... Jeg har lært om Unicode (f.eks. efter graduering). Men det mindede mig altid, at Win32API nævner 'unicode' meget løst. I særdeleshed er 'unicode' -varianten nævnt af MSN UTF-16 (selvom 'wide char' -terminologien stammer fra det faktum, at det plejede at være UCS-2, hvilket ikke er Unicode). Det gør dog næsten ingen omtale af Unicode Normalization.


MSN har et par sider om Unicode og Unicode Normalization Forms og funktioner til at ændre normaliseringsformularen. Siden om normalisering siger endda: [10] [11] [12]



  Win32 og .NET Framework understøtter alle fire normaliseringsformer.



Jeg har dog ikke fundet nogen steder i dokumenterne, hvilken normaliseringsformular der bruges (eller forstås) af Win32 API.


Spørgsmål 1 : Hvilken normaliseringsform bruges som standard til brugerindgang (f.eks. en Rediger kontrol) og konvertering gennem MultiByteToWideChar()?


Spørgsmål 2 : Skal strengene sendes til Win32API-funktionerne i en bestemt normaliseringsformular, eller er kerne- og filsystemets normaliseringsagnostik?

Bedste reference


Fra MSDN-artiklen Brug af Unicode Normalization til at repræsentere strenge. [13]



  Windows, Microsoft-applikationer og .NET Framework genererer generelt tegn i form C ved hjælp af normale input metoder. For de fleste formål på Windows er formular C den foretrukne form. For eksempel produceres tegn i formular C ved hjælp af Windows tastaturindgang. Tegn, der importeres fra internettet og andre platforme, kan dog introducere andre normaliseringsformer i datastrømmen.



Opdatering: Jeg har medtaget nogle specifikke detaljer vedrørende spørgsmål nr. 2.


Med hensyn til filsystemet kræves normalisering ikke - baseret på artiklen Navngivning af filer, stier og navnepladser. [14]



  Der er ikke behov for at udføre nogen Unicode-normalisering på stier til stier og filnavne til brug i Windows-filens I/O API-funktioner, fordi filsystemet behandler stinavn og filnavne som en uigennemsigtig række WCHARs. Enhver normalisering, som din ansøgning kræver, skal udføres med dette i tankerne, eksternt for eventuelle opkald til relaterede Windows-I/O API-funktioner.



Med hensyn til SQL Server kræves der ingen normalisering - heller ikke data normaliseres, når den gemmes i databasen. Når man sammenligner strenge, bruger SQL Server 2000 sin egen streng normaliseringsmekanisme inde i indekser; men jeg kan ikke finde specifikke detaljer om hvad det er. En SQL Server 2005-artikel hedder det samme. [15] [16] [17]



  En vigtig ændring i SQL Server 7.0 var tilvejebringelsen af ​​en operativsystemuafhængig model til streng sammenligning, så collationerne mellem alle operativsystemer fra Windows 95 til Windows 2000 ville være konsistente. Denne streng sammenligningskode blev baseret på den samme kode, som Windows 2000 bruger til sin egen streng normalisering, og er indkapslet til at være den samme på alle computere og i alle versioner af SQL Server.


Andre referencer 1



  Hvilken normaliseringsform bruges som standard til brugerindgang



Afhænger af dit tastaturlayout/IME. Det er muligt at generere normal form C, D eller en skør blanding af begge, hvis du vil.


Tastaturlayouter har tendens til NFC, fordi de i de pre-Unicode-dage, de normalt har udgivet et enkelt byte-tegn på den lokale kode side for hver tastetryk. Der er dog undtagelser.


For eksempel ved hjælp af det Windows-vietnamesiske tastaturlayout, skrives nogle diakritiske tegn som en enkelt tastetryk kombineret med brevet (f.eks. Omkreds â) og nogle er skrevet som en kombinerende diakritisk (fx grav ). Graheme a-med-circumflex-og-graven ville blive skrevet som en-omklekse efterfulgt af combining-grav ầ, som ville være 0xE2,0xCC i vietnamesisk kode side 1258 og ville komme ud som U + 00E2 , U + 0300 i Unicode.


Dette er ikke i normal form C (som ville være U + 1EA7 Latin lille bogstaver A med omklekse og grave) eller D (som ville være ầ U + 0061, U + 0302, U + 0300).


Der er generelt en kulturel præference for NFC i Windows verden og på internettet, og for NFD i Apple verden. Men det er ikke stramt håndhævet, og du bør forvente at klare enhver blanding af kombinerede og dekomponerede tegn.



  er kerne- og filsystem normalisering-agnostik?



Ja, kerne- og filsystemet ved ikke noget om normalisering og vil ganske gerne tillade dig at have filer med navnene ầ.txt, ầ.txt og ầ.txt i samme mappe.

Andre referencer 2


Først og fremmest tak for et glimrende spørgsmål. Jeg fandt svaret i Michael Kaplan s blog: [18]



  Men da alle metoder til tekstindtastning på Windows har tendens til at bruge den samme normaliseringsformular allerede (formular C), ...