Unicode

Den här artikeln behöver fler eller bättre källhänvisningar för att kunna verifieras. (2024-05) Åtgärda genom att lägga till pålitliga källor (gärna som fotnoter). Uppgifter utan källhänvisning kan ifrågasättas och tas bort utan att det behöver diskuteras på diskussionssidan.

Unicode är en branschstandard för hur datorer ska hantera text skriven i olika skriftsystem. Unicode är utvecklad tillsammans med den internationella standarden Universal Coded Character Set och publicerad på internet och i bokform. Unicode består av en repertoar med fler än 100 000 skrivtecken. Ett av de viktigaste målen är att alla tecken i världens alla skriftsystem ska finnas med: bokstäver, kinesiska tecken, siffror, skiljetecken, matematiska symboler, och så vidare. Unicode består även av ett antal metoder för att lagra tecknen i datorer, bland annat UTF-8 och UTF-16. Även en serie teckenegenskaper definieras, som exempelvis: huruvida ett tecken är en bokstav, siffra, skiljetecken, om en bokstav är en versal eller gemen, med mera. Unicode ger även en beskrivning hur normalisering ska gå till och i vilken ordning tecken ska visas när tecken ur höger-till-vänster-skriftsystem (till exempel arabiska) används. En separat Unicode-standard ger en grundläggande sorteringsordning, som sedan kan anpassas till olika språk.

Unicode-konsortiet är en ideell organisation grundad för att styra utvecklingen av Unicodestandarden och består av representanter från bland annat mobil- och datortillverkare, till exempel Apple, Microsoft, Facebook och Google men även lingvister och typografer.^[1]

Unicode initierades av Apple computer, inc. (Mark Davis) och Xerox Corporation (Joe Becker, Lee Collins) år 1980, men först 1991 bildades Unicodekonsortiet.^[1]

Unicode är tänkt att ersätta flera hundra äldre kodningar som ASCII, SJIS, ISO 8859-1, med flera. Syftet är att få en världsgemensam teckenkodning som fungerar för alla, oavsett språk eller datorsystem. Unicode försöker så långt som möjligt vara kompatibelt med äldre standarder. Man ska kunna ta en text, omvandla den till Unicode och sedan tillbaka och få tillbaka texten likadan. Detta innebär bland annat att tecken från alla gamla teckenkodningsstandarder, inklusive de-facto standarder, tagits med. En del ej rekommenderade äldre standarder, såsom fransk 7-bitskodning stöds formellt, men avråds från, eftersom det har skapat parallella sätt att lagra tecken.

Fördelen med att införa Unicode är att kunna översätta datadokument, webbsidor, program och så vidare till valfritt språk utan tekniskt krångel. Med tidigare standarder gick det inte så bra, eftersom varje standard bara täckte ett mindre antal (eller ett enda) språk. För de flesta språk (även svenska) fanns ett antal olika kodningar utvecklade av olika tillverkare. Att överföra text via filer eller e-brev orsakade lätt problem. På japanska kallas problemet Mojibake. Översättningar kunde medföra tekniska problem vid konvertering av olika kodningar och teckensnitt. Med Unicode har dessa problem förpassats till dåtid. Exempel: Wikipedia finns på drygt 200 språk, i allmänhet utan tekniska problem. Man kan blanda språk på samma sida. En artikel om en kinesisk eller arabisk stad kan ha originalnamnet med i artikeln.

Många mindre språk med annorlunda skriftspråk har haft väldigt liten tillgång till mjukvara på det egna språket. De har haft svårt att skriva och ta emot dokument, webbsidor och e-brev på sitt eget språk innan Unicode infördes.

Idag används Unicode i bland annat Windows, Mac OS, Symbian OS, GNU/Linux, Oracle, Sybase och andra system inklusive mobiltelefoner. Unicode infördes exempelvis i Microsofts Officepaket 1997, vilket möjliggjorde att dokument kunde hanteras utan en speciell version av Officepaketet avsedd för det alfabet användaren föredrog, i den mån en sådan version fanns. Innan dess kunde till exempel en japan som jobbade i USA inte läsa japanska Word-dokument utan att ha det japanska Officepaketet installerat.

Målet med Unicode är att alla skrivtecken i världens alla skriftsystem ska finnas med: bokstäver, logogram, siffror, skiljetecken, matematiska symboler, med mera. Detta även för skriftsystem som inte längre används aktivt.

Unicode har tecken för i princip alla skriftsystem som används idag. Dessutom finns bland annat tekniska symboler, matematiska symboler, symboler för att skriva musik, internationella fonetiska alfabetet och även symboler för APL med.

Fler skrivsystem har lagts till och läggs till, inklusive historiska skrivsystem (som till exempel runskrift) som inte längre används. Dessutom lägger man till tecken till skriftsystem som redan finns med, liksom symboler. Däremot har man sagt nej till skrivsystem som klingonska (används inte ens av klingonsällskapet, och symbolerna är egentligen scendekor). För en del konstgjorda skriftsystem som bara används av en snäv krets entusiaster finns icke-standardiserade allokeringar inom kodområdet för privat användning. En del av dessa skriftsystem kan på sikt komma att bli formellt standardiserade.

Det finns långt över tusen skriftspråk i världen, men många använder samma tecken, eller nästan samma tecken. Precis som i äldre, mer begränsade kodningar, låter man i Unicode förena likadana tecken i olika språk till samma teckenkod, vilket kallats unifiering. Oftast är det trivialt. A–Z i engelska är till exempel samma som A–Z i svenska. Några problem har det blivit även med latinska tecken, där några tecken avvikit något lite i utseende mellan två länder. De unifierades ibland till samma tecken i Unicode, men man har fått skilja dem åt efteråt. Till exempel turkiska Ş används också på rumänska men där med "fritt hängande" krok, vilket senare har införts i Unicode, men som ännu^[när?] inte stöds i de flesta datorer. I praktiken används Ş på rumänska i datorer eftersom det stöds både av Unicode och aktuell äldre kodning, vilket S med fri krok under inte gjort. Rumänska stilmedvetna har beklagat sig.

Man har dock valt att (liksom i äldre kodningar) helt skilja på tecken som ser likadana ut men hör hemma i olika skriftsystem. Till exempel skiljer man på grekiskt, kyrilliskt och latinskt A. Dels för att de som sagt hör hemma i olika skriftsystem, men även för att de har lite olika egenskaper; i detta fall ser den motsvarande gemena bokstaven olika ut i latinska skriftsystemet och i grekiska skriftsystemet. Även inom vissa skriftsystem skiljer man på tecken med lika utseende: decimala siffror kodas alltid skilt från bokstäver (men det gäller inte andra sorters siffror).

För kinesiska, koreanska och japanska har unifieringen gjorts av en arbetsgrupp som kallas IRG (Ideographics Rapporteur Group). Den består av representanter från Japan, Kina, Taiwan, Vietnam, Sydkorea, och numera även Nordkorea. De har utgått från historiska och semantiska principer. Den stavningsreform som resulterade i vad som brukar kallas förenklad kinesiska är inte ett separat skriftsystem, inte heller bara glyfvarianter av de tecken som används i traditionell stavning (traditionell kinesiska). Den reformerade stavningen använder helt enkelt andra (enklare) kinesiska tecken. Dock infördes endast ett mycket litet antal nya kinesiska tecken i och med stavningsreformen. Även historiska kinesiska tecken finns med. Det har hittills resulterat i att över 71 000 kinesiska tecken har kodats i ISO/IEC 10646 och Unicode (5.0).

Varje existerande tecken från världens alla skriftsystem tilldelas ett heltal, en så kallad kodpunkt (eng: code point). När man refererar till en kodpunkt i beskrivande text, görs det på formen "U+" följt av 4–6 hexadecimala siffror. Exempelvis anges kodpunkten för α (grekiska lilla alfa) som U+03B1 (det decimala numret, här 945, undviks för att inte riskera förväxling och förvirring). Ofta brukar även kodpunktens namn inkluderas; U+03B1 GREEK SMALL LETTER ALPHA.

En del kodpunkter står för annat än tecken, såsom kontrollkoderna från ASCII, anvisningar för program som hanterar texten och kodpunkter som tillsammans bildar tecken (till exempel accenter kan kombineras med intilliggande bokstav: akut accent och e blir é). Standarden innehåller regler för normalisering av tecken som kan representeras på olika sätt.

Kodpunkterna serialiseras till en följd av oktetter (byte), som kan lagras i filer eller överföras mellan datorsystem. Oktetter har åtta bitar, för få för Unicodes kodpunkter. De serialiseringar som används kallas UTF-8, UTF-16BE, UTF-16LE, UTF-32BE och UTF-32LE.

Kodpunkterna är sammanlagt 17·2¹⁶ (drygt en miljon) stycken. Man konstaterade att man behöver tillgång till fler tecken än 2¹⁶, men att dessa, som kan representeras med UTF-16, räcker med god marginal. Alla kodpunkter kan representeras i 21 bitar, men så som datorerna arbetar är det ofta effektivare att allokera 32 bitar per kodpunkt. Drygt 250 000 kodpunkter har allokerats, varav drygt 100 000 för tecken, formateringskoder etcetera, de övriga bland annat för UTF16-mekanismen och framförallt för privat användning.

Unicodes kodpunkter är uppdelade i 17 plan. Varje plan har plats för 65 536 (2¹⁶) kodpunkter. Det första planet (plan 0), det så kallade Basic Multilingual Plane (BMP), är där de flesta tecken finns allokerade (än så länge). BMP innehåller tecknen för nästan alla moderna skriftspråk, samt ett stort antal symboler som används i text. Av kodpunkterna i användning är runt 70 000 kinesiska och drygt 11 000 koreanska tecken, varav cirka 25 000 i BMP, de flesta i det tredje planet (plan 2), Supplementary Ideographic Plane.

Varje plan indelas dels i rader omfattande 256 (2⁸) tecken, dels i block. De senare är "areor" av varierande storlek reserverade för (delar av) teckensystem. Till exempel: hebreiska tecken hamnar i första hand i blocket Hebrew som sträcker sig från U+0590 till U+05FF.

Två plan utöver BMP används för ”grafiska” tecken.

• Plan 1, Supplementary Multilingual Plane (SMP), används mestadels för historiska skriftsystem, men även till exempel för symboler för att skriva musik. Och för emojier, vilket kraftigt ökat användningen av plan utöver BMP på nätet.
• Plan 2, Supplementary Ideographics Plane (SIP), används för över 50 000 ovanliga kinesiska tecken, de flesta historiska (en del direkta felskrivningar i ordböcker), men även en del tecken som används i modern text.
• Plan 3, Tertiary Ideographic Plane (TIP) har reserverats för fler kinesiska tecken, och några tusen tecken har allokerats (skrivet 2022). Det diskuteras att ta med tecken som inte använts på tusentals år såsom Orakelbensskrift och andra, men det är många tusen tecken ytterligare.

Tio plan (plan 4–13) har ännu inte tilldelats någon funktion.

Ett plan (plan 14), Supplementary Special-purpose Plane, används för diverse koder, inte för tecken.

Dessutom är 6400 tecken i BMP plus två hela plan (plan 15 och 16, 131072 tecken) reserverade för ”privat användning”, där de som skriver och läser texten får komma överens vad de betyder. Ett område är reserverat för operativsystemets privata tecken, till exempel Apple-loggan i Macintosh.

Bland de tekniskt mer komplicerade funktionerna i Unicode är de för höger-till-vänster-riktade skriftspråk såsom arabiska. Texten ska enligt Unicode-standarden (samt flera tidigare standarder) lagras i den ordning man läser. Man kan blanda tecken med olika skrivriktning. Unicode-standarden har en algoritm (”bidi-algoritmen”) som ger i vilken ordning tecknen ska skrivas ut, som programvara som skriver ut en text måste använda om den stödjer höger-till-vänster-riktade skriftspråk. För bland annat det arabiska alfabetet finns den extra komplikationen att man ofta ska "binda ihop" en bokstav med intilliggande bokstäver. Lite förenklat kan man göra detta genom att ha fyra former för en bokstav: isolerad, initial, medial, samt final form. I moderna system görs detta byte av glyf via data i den font som används. Fontformatet OpenType har stöd för detta. I vissa äldre system bytte man stället vid visning ut tecknen mot ”presentationsformer” som även finns i Unicode. Dessa tecken finns bara för delar av det arabiska skriftsystemet, och inte alls för syriska, n-kå, mongoliska, med mera. Dessa "presentationsformer" bör inte användas i textfiler. För parenteser (och liknande tecken) gäller att man använder de vanliga parentestecknen, med "(" för början av parentes och ")" för slut av parentes, men de ska spegelvändas om det är arabisk text innanför, men inte om det är europeiska tecken innanför.

Thailändska har också vissa komplikationer. Man ska lägga till symboler (som räknas som bokstäver) ovanför normala bokstäver på ett mycket friare sätt än i europeiska alfabet. Man har inte förformade tecken som i Europa (där á och à är hela tecken), eftersom det är för många kombinationer och de mindre tecknen ovanför själva räknas som bokstäver. Program som visar thailändsk text får göra ett speciellt arbete för detta språk. Hindi har ett liknande problem. Vietnamesiska använder det latinska alfabetet men med mängder av markeringar över och under som modifierar dem. Unicode har valt den tidigare vietnamesiska metoden att ha förformade tecken, vilket är mycket lättare rent tekniskt, även om det är mer än 200 Vietnam-unika tecken.

Kinesiska, japanska och koreanska är lättare rent tekniskt, även om de vardera har många tusen tecken. Kinesiska tecken består i allmänhet av en kombination av två andra tecken, vilket gör att det finns ett stort antal sådana tecken. För att något minska på antalet har man genomfört en delvis kontroversiell unifiering av dessa tecken. De kinesiska tecknen används för alla de tre språken och bland de 65 535 lägsta kodnumren i Unicode finns drygt 27 000 kinesiska tecken, och över 50 000 på högre kodnummer där det lagts till en del japanska, koreanska och taiwanesiska varianter av kinesiska tecken.

För koreanska används i första hand skrivsättet Hangul, där bokstäver samlas i stavelser om 2–4 stycken. För Hangul har Unicode liksom den koreanska standarden valt att koda alla möjliga kombinationer av stavelser, cirka 11 100 st, som varsitt tecken, även om det också finns en metod med att koda bokstäverna var för sig och låta datorn skapa stavelsetecken. Det senare blir inte stilmässigt korrekt om man har lite högre krav, och används inte av till exempel Windows.

Unicode använder teoretiskt 21 bitar för ett tecken, med 1 114 112 möjliga positioner; antalet kommer från hur UTF-16 är uppbyggt. Strängar av tecken måste lagras på något sätt i datorer, och i filer med mera. Om man lagrar tecknen som heltal med minst 21 bitar blir det ganska rättframt att använda UTF-32, det vill säga 32 bitar per tecken, då det är effektivare i dagens datorer än att använda 21 eller 24 bitar. Denna kodform används dock sällan i filer, då den är mer utrymmeskrävande (mesta delen av texten kommer att lagras som nollbitar). Den används ofta internt i program i unixliknande system.

Nyare versioner av Windows använder UTF-16 internt. Där lagras texten som 16-bitars heltal. Det finns en särskild mekanism för att hantera tecken med kod över U+FFFF, vilket inte stöds av den äldre standarden UCS-2. I filer (där informationen lagras byte för byte) får man lagra 16-bitars heltal som två oktetter, med serialiseringarna UTF-16BE eller UTF-16LE, beroende på ordningen hos dessa två oktetter. Äldre versioner av Windows använde UCS-2.

I filer i Unix-liknande operativsystem (till exempel GNU/Linux och macOS) används ofta UTF-8, där en kodpunkt upptar en till fyra oktetter. Det latinska alfabetet (a–z), liksom andra 7-bitars ASCII-tecken, lagras som i ASCII medan andra tecken lagras så att de inte kan förväxlas med dessa. Därmed behöver datorprogram för vilka en del ASCII-tecken har speciell betydelse, medan andra tecken inte har det, inte veta om en fil kodats enligt ASCII eller UTF-8. UTF-8 är standard för webbsidor som använder XHTML och en vanlig kodning för andra webbsidor och för e-post. UTF-8 används också i flera programmeringsspråk. UTF-8 rekommenderas för nya Internet-standarder.

Lista över kodningar:

• UTF-7 (icke-officiell kodning), trots namnet EJ en UTF (utan en TES, Transfer Encoding Syntax), var avsett (enbart!) för e-post, men är även för denna användning helt överspelad,
• UTF-8,
• UTF-9 (icke-officiell kodning),
• UTF-16 (en begränsad äldre variant kallas UCS-2), UTF-16BE, UTF-16LE (big endian respektive little endian byteserialiseringar),
• UTF-32, UTF-32BE, UTF-32LE (big endian respektive little endian byteserialiseringar),
• UTF-EBCDIC (icke-officiell kodning), EBCDIC-baserad,
• SCSU (icke-officiell kodning),
• BOCU-1 (icke-officiell kodning),
• Punycode, en TES (Transfer Encoding Syntax) avsedd endast för internationaliserade domännamn.

Eftersom alfabetisk ordning skiljer sig mellan olika språk och till och med inom språken och på grund av Unicodes komplicerade natur är alfabetisk sortering av godtyckliga Unicode-kodade fraser komplicerat. Sortering i Unicode är samordnat med ISO 14651, men beskrivs i en skild standard, Unicode Technical Standard 10: Unicode Collation Algoritm. Standarden innefattar data för den normala sorteringsordningen ("DUCET": Default Unicode Collation Element Table) och metoder för att tillmötesgå behoven för olika alfabet, språk, kontext och användarpreferenser.

Innan fraser jämförs bör de normaliseras, så att samma tecken kodat på olika sätt räknas lika (till exempel kan accenter ofta antingen kodas skilt eller som en del av tecknet). Användaren bör kunna välja vilket språks regler som skall användas, hur små skillnader som skall räknas betydelsefulla, huruvida interpunktion skall beaktas, huruvida versaler och gemener skall anses lika, huruvida siffror skall betraktas som tal eller tecken, huruvida olika alfabet skall sorteras i en viss ordning och så vidare. För det latinska alfabetet används tre nivåer, som alla kan anpassas enligt behov: alfabetisk ordning, diakritisk ordning och ordning ifråga om gemener och versaler.^[2]

Unicode har samma teckenallokering, inklusive teckennamn, som den internationella standarden ISO/IEC 10646 (Universal Coded Character Set, UCS). Även kodningsformerna (UTF-8, UTF-16, UTF-32) är gemensamma med ISO/IEC 10646. Unicode lägger till egenskaper, algoritmer och implementeringsanvisningar, som inte är en del av ISO/IEC 10646.

Unicode standardiserar teckenegenskaper, vilket ISO/IEC 10646 inte gör. Teckenegenskaper är bland annat "generell kategori" (bokstav, siffra, med mera), radbrytningsegenskaper, egenskaper för bidirektionalitet, och mycket mer.

ISO/IEC 10646 har formaliserade "delmängder", vilket Unicode inte har.

För rena textfiler använder man UTF-8 eller UTF-16. UTF-16 har komplikationen att det finns två varianter (big-endian och little-endian) och det är svårt för ett program att veta vilket det är, åtminstone om det kan vara ett språk som kinesiska, eller om det i själva verket är en 8-bitskodning. Ett exempel på fel är att om man har en textfil i ANSI med innehållet Bush hid the facts och öppnar den i notepad (Windows XP) får man 畂桳栠摩琠敨映捡獴 istället, eftersom notepad tror det är Unicode UTF-16. UTF-8 har inte denna komplikationen och tar mindre utrymme för europeiska språk, men mer för östasiatiska språk.

För filer i binärformat kan man använda vad man vill, UTF-8, UTF-16, 24-bitars eller UTF-32. Programmet styr då själv över vad som lagras och vet vad det är.

I programspråk som till exempel C kan man använda UTF-8 för källkodsfiler och då använda alla Unicodetecken i strängar, dock endast ren ASCII i resten av källkoden. Även äldre kompilatorer stödjer det eftersom ren ASCII också är korrekt UTF-8, men nya bibliotek för in- och utmatning behövs då.

Som format för strängvariabler kan man välja mellan UTF-8 och UTF-16. UTF-8 har fördelen att det är mer kompatibelt med äldre bibliotekskod, UTF-16 anses^{[Eventuellt plattformsspecifikt?]} passa bättre om det stöds av standardbiblioteken. För UTF-8 kan man använda char* precis som för 8-bitskodningar, fastän det inte är säkert ett tecken ryms i en char. Funktioner som skall hantera enskilda tecken eller specifika antal tecken bör alltså stöda kodningen. För UTF-16 behöver man någon annan variabeltyp för teckensträngar. wchar_t hanterar tecken i ett kompilatorberoende format, som i vissa fall är UTF-16. Liksom i UTF-8 varierar teckenbredden i UTF-16, dock så att endast ovanliga tecken kräver 2·16 bit, medan de andra lagras i 16 bit. (2·16 bitstecken är 2017 vanligare då vissa sociala medier har lagt till stöd för emojis)

Programspråket Java använder UTF-16 under körning, och UTF-8 för sådant som XML-filer (UTF-8 i källkoden). Det är lättare att hantera enskilda tecken i en textsträng om alla tecken tar lika många byte, vilket de gör med UTF-32 och med UCS-2 (en föråldrad variant av UTF-16, som inte stödjer tecken över U+FFFF).

Märkspråken HTML (som är SGML-baserat) och XML, och därmed alla XML-baserade dokumentformat (till exempel: XHTML, XSL och SMIL), har ISO 10646 (se ovan för förklaring) som så kallad dokumentteckenmängd.^[3] Dokumenten kan vara kodade i vilken teckenkodning som helst som stöds av webbläsaren som behandlar det, men det går inte att använd några andra tecken än de som är definierade i ISO 10646. För alla system som tolkar XML-baserade dokument krävs att de kan hantera kodningarna UTF-8 och UTF-16. Om man utelämnar teckenkodningsangivelsen i ett XML-dokument, så ska teckenkodningen vara UTF-8. Om det är UTF-16 i HTML utan att det anges kan man hantera problemet med byte-ordningen genom att man vet att det ska vara många engelska bokstäver och tecken som "<" och ">" i början.

Men oavsett vilken teckenkodning som används refererar de eventuella så kallad numeriska teckenreferenserna i dokumenten till ISO 10646:s tecken, med de kodnummer de har där (kodpunktens nummer, inte de nummer som används i kodformerna UTF-8 eller UTF-16).

Till exempel refererar μ alltid till grekiska lilla my (μ, U+03BC GREEK SMALL LETTER MU), som bland annat används för att beteckna mikro. Oberoende av vilken teckenkodning som egentligen användes för att koda dokumentet i fråga.

Dokumentens källtexter blir dock ofta svårlästa om man använder teckenreferenser, så användningen bör begränsas till tecken som inte kan representeras i dokumentets teckenkodning, eller till tecken som annars är "udda", till exempel U+200D ZERO WIDTH JOINER. Numeriska teckenreferenser kan även ges i decimal form (ovan är angivna på hexadecimal form), men detta är extra förvirrade då inga officiella teckentabeller använder decimalform.

E-post använder en annan standard, kallad MIME. Eftersom många e-postservrar fortfarande utgår från 7-bitars tecken måste text kodad som UTF-8 eller UTF-16, då den skickas till sådana servrar, dessutom kodas med Base64 eller Quoted printable (många e-postprogram gör denna kodning automatiskt, för säkerhets skull). Med den förra kodningen blir meddelandet 4/3 så stort som ursprungligen och oläsligt utan omkodning, med den senare kommer varje byte utanför ASCII-mängden att kodas med tre tecken per byte, och alltså minst sex tecken per bokstav. Till exempel blir ÅÄÖ (kodat som UTF-8) w4XDhMOW som base64 och =C3=85=C3=84=C3=96 som quoted printable. Tecknen som hör till ASCII (bland andra A-Z) hålls oförändrade i quoted printable, så västerländsk text växer bara måttligt och är fortfarande någorlunda läslig också som sådan.

MIME-deklarationen av ett meddelande av denna typ kan då vara

Content-Type: text/plain; charset=utf-8

Content-Transfer-Encoding: Quoted-Printable

I fall då e-postprogrammet med grundinställningar inte stöder kodningen används ofta så kallade bilagor, som kan författas och kodas oberoende av stödet i själva e-postprogrammet. Rätt konfigurerade moderna e-postprogram stöder i allmänhet Unicode direkt på det ovan beskrivna sättet, utan att användaren behöver bry sig om de tekniska detaljerna.

År 2003 publicerades ett utkast till standard (RFC 3490) som möjliggör användande av Unicode i domännamn och registrering av sådana så kallade "internationaliserade domännamn" (IDN) tilläts hos olika registratorer med början samma år, bland annat i Sverige.^[4] Domännamnssystemet (DNS) använder inte UTF-8, men tecken som inte hör till de tillåtna kodas med Punycode och omkodas av tillämpningsprogrammet innan DNS-förfrågan görs. Den punykodade ASCII-formen av domännamnet börjar med xn--.

Nyare versioner (från 2006^{[källa behövs]}) av e-postprogram, webbläsare och så vidare har börjat stödja denna konvertering. Man har börjat tillåta Unicode också i toppdomänen, det vill säga till exempel landskoden ".рф", vilket infördes 2010.

I webbadresser (URL) används också en begränsad teckenuppsättning, oberoende av begränsningarna i DNS. Domännamnet måste då antingen skrivas i punycode eller kodat i hexadecimalform (och i det senare fallet omkodas till punycode före DNS-förfrågningar). Hexadecimalformen, med ett procenttecken (%) före varje kodad byte, används också för eventuella otillåtna tecken i resten av adressen.

De kodade tecknen i resten av adressen tolkas av värddatorn enligt lokala konventioner. Sedan 2005 rekommenderar man att UCS-tecken kodas med UTF-8 för att sedan kodas i hexadecimalform, vad gäller nya scheman, men används också rätt allmänt ifråga om äldre scheman. Metoden är utrymmeskrävande för språk som inte använder latinska alfabetet: Unicode på hindi heter यूनिकोड vilket blir %E0%A4%AF%E0%A5%82%E0%A4%A8%E0%A4%BF%E0%A4%95%E0%A5%8B%E0%A4%A1.

Moderna webbläsare tillåter ofta att användaren skriver in webbadresser med de avsedda tecknen, utan kodning. Detta förutsätter att webbläsaren kan gissa vilken kodning som ska användas, vilket kan misslyckas till exempel om webbläsaren använder UTF-8 och webbservern Latin-1 eller Windows-1252.

Den 11 oktober 2010 släpptes Unicode 6.0 och innehöll 994 emojier som därmed var fritt fram att använda för alla tjänster. Det innebar att företag som Google, Microsoft, Facebook och Twitter kunde börja skapa sina egna versioner av emojier som kan synas även om ett meddelande skickas från ett annat operativsystem eller tjänst. Operativsystemet IOS 5 till Iphone från Apple blev i slutet av 2011 först med att lansera emojier internationellt. I operativsystemet fanns även ett eget tangentbord för emojier inbyggt.^[1]

• Tabell över Unicode-tecken 128 till 999
• Unicode-runor

Den här artikeln är helt eller delvis baserad på material från engelskspråkiga Wikipedia, tidigare version.

• Officiell webbplats
• Vad är Unicode?
• DecodeUnicode
• Unicode Snowman for You: visar Unicode-tecknet ☃ (☃) i förstorad form

Auktoritetsdata • LCCN: sh98000843 • GND: 4343497-6 • NKC: ph571669