Bruk av Unicode for å støtte flerspråklige applikasjoner

Den foretrukne måten å lagre tekst på er å bruke strenger som støtter unicode, siden dette tillater en blanding av tegn fra alle språk. Når du bruker unicode-strenger, er det noen funksjoner som er nyttige å være klar over for å unngå problemer. Noen av disse funksjonene er også forskjeller fra strenger som ikke støtter unicode, og som man bør ta hensyn til, spesielt når man konverterer en eksisterende løsning fra ikke-unicode til unicode.

Arven

Hvordan et tegn skal representeres når det lagres og behandles i en datamaskin i dag, dikteres av standarder som har en historie helt tilbake til de første datamaskinene, og faktisk også før det. Denne artikkelen skal ikke forsøke å nøste opp hele historien, men en kort og noe forenklet forklaring av noen begreper er på sin plass.

ASCII - American Standard Code for Information Interchange er det vanligste tegnkodingsformatet for tekstdata i datamaskiner. I standard ASCII-kodede data brukes 7 bits, noe som resulterer i unike verdier for 128 alfabetiske, numeriske eller spesielle tilleggstegn og kontrollkoder.

Extended ASCII - En ekstra bit brukes til å kode ytterligere 128 tegn, noe som gir totalt 256 tegn. De ekstra tegnene er ikke tilordnet en bestemt kode, men kan brukes til å lagre forskjellige tegn i henhold til en kodeside. På denne måten kan flere forskjellige tegnsett støttes, for eksempel japanske, kinesiske og nordiske tegn, bare ikke samtidig. Den utvidede ASCII-koden er også kjent som ANSI.

Code Page - Et navngitt sett med tegn og koden som brukes til å representere dem. For eksempel inneholder kodesiden "865 Nordic Languages" tilordningen av tegnet "Æ" til koden 145 i den utvidede ASCII-kodingen.

Alt i alt er det mange problemer knyttet til kompleksiteten i denne arven. Ikke-unikode-tegnsett, som ASCII eller de ulike utvidede ASCII-settene, er med sitt begrensede omfang utilstrekkelige i dagens globale miljø, der datainput bokstavelig talt kan være på hvilket som helst språk eller symbolsett. Med ikke-unikode-tegnsett må alle tegn utenfor det begrensede området konverteres, noe som ofte fører til tap av data eller feilaktige representasjoner. 

Hva er Unicode?

Unicode er en internasjonal kodingsstandard for ulike språk og skript, der hver bokstav, hvert siffer og hvert symbol tildeles en unik numerisk verdi som gjelder på tvers av ulike plattformer og programmer.

Unicode løser dermed problemene med språkstøtte i applikasjoner ved at alle tegn på alle språk kan kodes konsekvent.

Dette høres fantastisk ut, men det er imidlertid noen ting man må være oppmerksom på. For å kode alle tegn på alle språk, inkludert alle symboler osv., kreves det 4 byte (32 bit). Dette er en firedobling i forhold til ANSI/Extended ASCII, og i mange tilfeller er dette helt bortkastet, da én byte ville vært tilstrekkelig. Unicode kan kodes på forskjellige måter, særlig UTF-8 og UTF-16, som tar for seg optimalisering av minnebruken.

UTF - Unicode Transformation Format er et tegnkodingsformat som kan kode alle mulige tegnkodepunkter i Unicode.

Tallverdien i navnet på en UTF-koding angir antall bits som brukes som "enhet", slik at UTF-8 - er en koding med variabel bredde som bruker én til fire byte for å kode et tegn, mens UTF-16 - er en koding med variabel bredde som bruker to eller fire byte for å kode et tegn.

Betraktninger

I SQL Server er hovedforskjellen mellom databasedatatypene VARCHAR og NVARCHAR:

• VARCHAR lagrer ett tegn i én byte. En kolonne definert som VARCHAR(10) rapporterer en størrelse på 10 byte.

• NVARCHAR bruker UTF-16 og lagrer ett tegn i to eller fire byte, avhengig av tegnet. En kolonne definert som NVARCHAR(10) rapporterer en størrelse på 20 byte.

I begge definisjonene VARCHAR(10) / NVARCHAR(10) angir tallene faktisk IKKE antall tegn, men strenglengden i byte for varchar og i bytepar for nvarchar. For varchar stemmer dette godt overens med antall tegn i de fleste tilfeller. For nvarchar blir det tydelig at det er en mulig uoverensstemmelse, ettersom hvert tegn kan kreve så mye som fire byte, eller to bytepar, avhengig av tegnet.

Ved bruk av nvarchar må man derfor vurdere om det er nødvendig å øke størrelsen på kolonnen i databasen.

• Skal egenskapen bare inneholde tekst på vestlige språk, eller andre språk med asiatiske, greske, kyrilliske tegn osv. eller en blanding? En navneegenskap kan f.eks. inneholde alle tegn, selv om applikasjonen bare bruker et enkelt vestlig språk for dataene.

• Er strengstørrelsen på egenskapen satt litt stramt, slik at den i mange tilfeller vil være fylt eller nesten fylt?

• Ligger kolonnen i en tabell med stort volum, for eksempel en transaksjonstabell? Bør vi til og med holde oss til varchar?

• Er det sannsynlig med emojis i innholdet, for eksempel i kommentarfelt eller lignende?

• Er det avgjørende at alle tegn som er mulig å skrive inn for en bruker, kan lagres?

• Er det akseptabelt at brukeren får en advarsel om at teksten er for lang til å lagres?

Husk at størrelsen på en nvarchar-kolonne defineres ved å angi et antall bytepar, og at bytestørrelsen dermed er det dobbelte av dette. Så hvis du dobler størrelsen på en nvarchar-kolonne for å sikre at alle tegn i alle språk kan lagres, blir resultatet en firedobling av størrelsen.

VARCHAR (100) - angir 100 byte, og størrelsen på kolonnen er 100 byte.

NVARCHAR(200) - angir 200 bytepar, og størrelsen på kolonnen er 400 byte.

Anbefalinger

De fleste tekstegenskaper i applikasjonen bør defineres ved hjelp av datatypen Unicode String, og egenskapen Data Size bør settes til det antall tegn egenskapen kan inneholde.

Den tilsvarende datatypen som skal brukes i databasen, bør være NVARCHAR(n). (n) bør fastsettes etter en vurdering i hvert enkelt tilfelle.

Konvertering fra ikke-unicode til unicode-data

Konvertering av ikke-unicode-data (som VARCHAR) til unicode-datatyper (som NVARCHAR) i SQL Server er vanligvis ukomplisert. 

Hvis du for eksempel vil endre en kolonne fra VARCHAR til NVARCHAR, kan du bruke ALTER TABLE-setningen: 

ALTER TABLE YourTableName ALTER COLUMN YourColumnName NVARCHAR(255); 

Denne setningen endrer den angitte kolonnen til å bruke datatypen NVARCHAR, slik at den kan lagre Unicode-data. Størrelsen (255 i dette eksemplet) kan justeres basert på datakravene dine. 

Hvis du må sette inn data i en Unicode-kolonne, og kildedataene ikke er i Unicode-format, konverterer SQL Server implisitt datatypen hvis det er mulig. I scenarier som krever eksplisitt konvertering, kan du bruke CAST- eller CONVERT-funksjonen: 

INSERT INTO DinUnicodeTabell (DinUnicodeKolonne) 
SELECT CAST(YourNonUnicodeColumn AS NVARCHAR(255)) 
FROM YourNonUnicodeTable; 

Husk at datatypen i Genus Studio også må endres fra Non-unicode String til Unicode String.

Når du ikke skal bruke Unicode

Det kan være tilfeller der Unicode ikke bør brukes, for eksempel når teksten er strengt formatert eller begrenset av semantikk eller systemspesifikasjoner. Eksempler kan være telefonnumre, kontonumre, objektidentifikatorer som ordrenummer med en blanding av alfanumeriske og numeriske tegn osv.

Forutsetninger i denne artikkelen

Denne artikkelen forsøker å forklare aspekter ved Unicode i forbindelse med en Genus -applikasjon, og målet er å gjøre det enkelt å bruke Unicode. Artikkelen inneholder imidlertid noen forenklinger basert på hva som anbefales i de aller fleste tilfeller.

• SQL Server brukes som grunnlag for datatyper og eksempler.

• Beskrivelsen av VARCHAR forutsetter at det brukes et enkeltbyte-tegnsett, noe som er langt det vanligste.

• Eksemplene bruker VARCHAR og NVARCHAR, men de samme betraktningene gjelder for datatypene CHAR og NCHAR.

Det finnes andre mulige konfigurasjoner som også vil fungere, i kombinasjon med bestemte sorteringer, andre databasetyper osv. Å gå inn på alle disse kombinasjonene og mulighetene vil ikke være formålet med denne artikkelen, og vi overlater derfor til den enkelte å utforske dem i detalj hvis det skulle være behov for det.