Använda Unicode för att stödja flerspråkiga applikationer

Det bästa sättet att lagra text är att använda strängar som stöder unicode, eftersom detta möjliggör en blandning av tecken från vilket språk som helst. När man använder unicode-strängar finns det några funktioner som är bra att känna till för att undvika problem. Vissa av dessa funktioner skiljer sig också från icke-unicode-strängar, vilket man bör ta hänsyn till, särskilt när man konverterar en befintlig lösning från icke-unicode till unicode.

Arvet

Hur man representerar ett tecken när man lagrar och bearbetar det i en dator idag styrs av standarder som har en historia som går tillbaka till de första datorerna, och faktiskt ännu längre tillbaka. Denna artikel kommer inte att försöka redogöra för hela historien, men en kort och något förenklad förklaring av några termer är på sin plats.

ASCII – American Standard Code for Information Interchange är det vanligaste teckenkodningsformatet för textdata i datorer. I standard ASCII-kodade data används 7 bitar, vilket resulterar i unika värden för 128 alfabetiska, numeriska eller speciella tilläggstecken och kontrollkoder.

Utökad ASCII – En extra bit används för att koda ytterligare 128 tecken, vilket ger totalt 256 tecken. De extra tecknen tilldelas inte någon specifik kod, utan kan användas för att lagra olika tecken enligt en kodsida. På så sätt kan flera olika teckenuppsättningar stödjas, till exempel japanska, kinesiska och nordiska tecken, men inte samtidigt. Den utökade ASCII kallas också ANSI.

Kodtabell – En namngiven uppsättning tecken och den kod som används för att representera dem. Till exempel innehåller kodtabellen "865 Nordic Languages" mappningen av tecknet "Æ" till koden 145 i den utökade ASCII-kodningen.

Sammantaget är scenen redo för problem som uppstår på grund av komplexiteten i detta arv. Icke-Unicode-teckensnitt, såsom ASCII eller de olika utökade ASCII-teckensnitten, med sitt begränsade omfång, är otillräckliga i dagens globala miljö, där datainmatning bokstavligen kan ske i vilket språk eller teckensnitt som helst. Med icke-Unicode-teckensnitt måste alla tecken utanför deras begränsade omfång konverteras, vilket ofta resulterar i dataförlust eller felaktiga representationer. 

Vad är Unicode?

Unicode är en internationell kodningsstandard för användning med olika språk och skript, där varje bokstav, siffra eller symbol tilldelas ett unikt numeriskt värde som gäller på olika plattformar och i olika program.

Unicode löser därmed problemen med språkstöd i applikationer genom att alla tecken i alla språk kan kodas på ett enhetligt sätt.

Det låter fantastiskt, men det finns dock några funktioner man bör vara medveten om. För att koda alla tecken i alla språk, inklusive alla symboler etc., krävs 4 byte (32 bit). Detta är en fyrdubbling av kraven för ANSI/Extended ASCII. I många fall är detta ett totalt slöseri, eftersom en byte skulle räcka. Unicode kan kodas på olika sätt, framför allt UTF-8 och UTF-16, vilket optimerar minnesanvändningen.

UTF – Unicode Transformation Format är ett teckenkodningsformat som kan koda alla möjliga teckenkodpunkter i Unicode.

Det numeriska värdet i namnet på en UTF-kodning anger antalet bitar som används som "en enhet", så UTF-8 är en kodning med variabel bredd som använder en till fyra byte för att koda ett tecken, medan UTF-16 är en kodning med variabel bredd som använder två eller fyra byte för att koda ett tecken.

Överväganden

I SQL Server är den största skillnaden mellan databasdatatyperna VARCHAR och NVARCHAR följande:

• VARCHAR lagrar ett tecken i en byte. En kolumn definierad som VARCHAR(10) rapporterar en storlek på 10 byte.

• NVARCHAR använder UTF-16 och lagrar ett tecken i två eller fyra byte beroende på tecknet. En kolumn definierad som NVARCHAR(10) rapporterar en storlek på 20 byte.

I båda definitionerna VARCHAR(10) / NVARCHAR(10) anger siffrorna faktiskt INTE antalet tecken, utan stränglängden i byte för varchar och i bytepar för nvarchar. För varchar motsvarar detta i de flesta fall antalet tecken. För nvarchar blir det uppenbart att det kan uppstå en diskrepans, eftersom varje tecken kan kräva upp till fyra byte, eller två bytepar, beroende på tecknet.

Därför måste man vid användning av nvarchar överväga om det är nödvändigt att öka storleken på kolumnen i databasen.

• Kommer egenskapen endast att innehålla text på västerländska språk, eller även andra språk med asiatiska, grekiska, kyrilliska tecken etc., eller en blandning? En namnegenskap kan till exempel innehålla vilket tecken som helst, även om applikationen endast använder ett enda västerländskt språk för sina data.

• Är strängstorleken för egenskapen inställd lite för snäv, så att den i många fall skulle fyllas eller nästan fyllas?

• Finns kolumnen i en tabell med hög volym, till exempel en transaktionstabell? Bör vi ens fortsätta använda varchar?

• Är det troligt att det förekommer emojis i innehållet, till exempel i kommentaregenskaper eller liknande?

• Är det viktigt att alla tecken som en användare kan mata in kan lagras?

• Är det acceptabelt att användaren får ett varningsmeddelande om att texten är för lång för att kunna sparas?

Kom ihåg att storleken på en nvarchar-kolumn definieras genom att ange ett antal bytepar, och byte-storleken är därmed dubbelt så stor. Om du fördubblar storleken på en nvarchar-kolumn för att säkerställa att alla tecken i alla språk kan lagras, blir resultatet en fyrdubbling av storleken.

VARCHAR (100) – anger 100 byte, och kolumnens storlek är 100 byte.

NVARCHAR(200) – anger 200 bytepar och kolumnens storlek är 400 byte.

Rekommendationer

De flesta textegenskaperna i applikationen bör definieras med datatypen Unicode String, och egenskapen Data Size bör ställas in på det antal tecken som egenskapen kan innehålla.

Motsvarande datatyp som ska användas i databasen bör vara NVARCHAR(n). (n) bör fastställas efter en bedömning från fall till fall.

Konvertera från icke-Unicode till Unicode-data

Att konvertera icke-Unicode-data (som VARCHAR) till Unicode-datatyper (som NVARCHAR) i SQL Server är i allmänhet okomplicerat. 

Om du till exempel vill ändra en kolumn från VARCHAR till NVARCHAR kan du använda ALTER TABLE-satsen: 

ALTER TABLE DittTabellnamn ALTER COLUMN DittKolumnnamn NVARCHAR(255); 

Detta uttalande modifierar den angivna kolumnen så att den använder datatypen NVARCHAR, vilket gör det möjligt att lagra Unicode-data. Storleken (255 i detta exempel) kan justeras utifrån dina datakrav. 

Om du behöver infoga data i en Unicode-kolumn och källdata är i ett icke-Unicode-format konverterar SQL Server dessutom implicit datatypen, om möjligt. I scenarier som kräver explicit konvertering kan du använda funktionen CAST eller CONVERT: 

INSERT INTO YourUnicodeTable (YourUnicodeColumn) 
SELECT CAST(YourNonUnicodeColumn AS NVARCHAR(255)) 
FROM YourNonUnicodeTable; 

Kom ihåg att datatypen i Genus Studio också måste ändras från icke-unicode-sträng till unicode-sträng.

När man inte ska använda Unicode

Det kan finnas vissa fall då unicode inte bör användas. Det gäller fall då texten är strikt formaterad eller begränsad av semantik eller systemspecifikationer. Exempel kan vara telefonnummer, kontonummer, objektidentifierare som ordernummer med en blandning av alfanumeriska och numeriska tecken etc.

Antaganden i denna artikel

Denna artikel försöker förklara olika aspekter av Unicode i samband med Genus-applikationen, och syftet är att göra det enkelt att använda Unicode. Artikeln innehåller dock vissa förenklingar baserade på vad som rekommenderas i de allra flesta fall.

• SQL Server används som grund för datatyper och exempel.

• Beskrivningen av VARCHAR utgår från att en sortering med enbytes teckenuppsättning används, vilket är det vanligaste fallet.

• Exemplen använder VARCHAR och NVARCHAR, men samma överväganden gäller för datatyperna CHAR och NCHAR.

Det finns andra möjliga konfigurationer som också skulle fungera, i kombination med specifika sorteringar, andra databastyper etc. Att täcka alla dessa kombinationer och möjligheter skulle motverka syftet med denna artikel, och lämnas därför åt var och en att utforska i detalj om behovet uppstår.