Unicode
Från Rilpedia
Unicode är en industristandard som låter datorer hantera text skrivet i världens alla skriftsystem. Den är utvecklad tillsammas med den internationella standarden Universal Character Set och publicerad på internet och i bokform. Unicode består av en repertoar med mer än 100 000 skrivtecken. Ett av de viktigare målen är att alla tecken i världens alla skriftsystem skall finnas med: bokstäver, siffror, skiljetecken, matematiska symboler, o.s.v. 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 utvalt tecken är en versal eller gemen, beskrivning hur normalisering och sortering bör gå till.
Unicode-konsortiet är en ideell organisation grundad för att styra utvecklingen av Unicodestandarden.
Innehåll |
Bakgrund och utveckling
Unicode initierades av Apple computer, inc. (Mark Davis) och Xerox Corporation (Joe Becker, Lee Collins) år 1980, men först 1991 bildades Unicodekonsortiet.
Unicode är tänkt att ersätta flera hundra äldre kodningar som ASCII, SJIS, ISO 8859-1, m.fl. 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. Detta innebär bl.a. att tecken från alla gamla teckenkodningsstandarder, inklusive de-facto standarder, tagits med.
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.
Idag används Unicode i bland annat Windows, Mac OS, Symbian OS, GNU/Linux, Oracle, Sybase och andra system inklusive mobiltelefoner. Unicode har infördes exempelvis i Microsofts Officepaket 1997, vilket möjliggjorde att dokument kunde fungera utan att ha en version av Officepaketet avsett för det alfabetet, i den mån det fanns. Innan dess kunde en till exempel japan som jobbade i USA inte läsa japanska Word-dokument utan att ha det japanska Officepaketet installerat.
Skriftsystem som finns med i Unicode
Målet med Unicode är att alla skrivtecken i världens alla skriftsystem skall finnas med: bokstäver, 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 bl.a. tekniska symboler, matematiska symboler, symboler för att skriva musik, internationella fonetiska alfabetet och även symboler för APL med.
Fler skrivsystem har lagt 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 symblerna är egentligen scendekor). För en del konstgjorda skriftsystem som bara används av en snäv krets entausiaster finns icke standardierade allokeringar inom kodområdet för privat användning. En del av dessa kan på sikt komma att bli formellt standardiserade.
Unifiering
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. T.ex. 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 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 är i olika skriftsystem. T.ex. så skiljer man på grekiskt, kyrilliskt och latinskt A. Dels för att de som sagt ligger i olika skriftsystem, men även för att de har lite olika egenskaper; i detta fall ser den motsvarande gemena bokstaven olika ut i latiska 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).
Teknik
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+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 kodpunktens namn även inkluderas; U+03B1 GREEK SMALL LETTER ALPHA
.
Dessa kodpunkter representeras i sin tur av föjder av kodenheter, vilka varierar beroende på teckenkodningsform (UTF-8, UTF-16, UTF-32). Följden av kodenheter kan i sin tur serialiseras till en följd av oktetter (8-bitars byte), som kan lagras i filer eller överföras mellan datorsystem. Bytes har bara 8 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.
Unicode använder upp till 21 bitar och har plats för över en miljon tecken – varav drygt 100 000 tecken redan är tilldelade (varav runt 70 000 kinesiska och drygt 11 000 koreanska). Unicodes kodutrymme på 1 114 112 (= 17 · 216) platser är uppdelat i 17 plan. Varje plan har plats för 65 536 kodplatser. 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 tecken för nästan alla moderna skriftspråk, samt ett stort antal symboler som används i text.
Varje plan indelas dels i rader omfattande 256 (28) 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 och med U+05FF
.
Två ytterligare plan används för "grafiska" tecken. Plan 1, Supplementary Multilingual Plane (SMP), används mestadels till historiska skriftsystem, men även till exempel symboler för att skriva musik. Plan 2, Supplementary Ideographics Plane (SIP), används för över 40 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.
Dessutom är 6400 tecken i BMP plus två plan reserverade för "privat användning", där de som skriver och läser text via teckensnitten får komma överens vad de betyder. Ett område är reserverat för operativsystemets privata tecken, t.ex. Apple-loggan i Macintosh.
Unicode för Asiens språk
Bland de tekniskt mest komplicerade funktionerna i Unicode är de för höger-till-vänster-riktade skriftspråk såsom arabiska alfabetet. Texten ska enligt Unicode-standarden och tidigare standarder lagras i den ordning man läser. Den programvara som skriver ut en text får hålla reda på riktningen. Om man blandar skrivriktningarna i en mening blir det komplicerat att hålla reda på det hela. Det finns en avancerad algoritm i Unicode-standarden ("bidi-algoritmen"). För arabiska alfabetet finns den extra komplikationen att tecknen måste förändras efter var de står. Man ska nämligen oftast binda ihop bokstäverna med grannen om det finns någon. Normalt byter man vid visning ut tecknena mot "presentationsformer" som finns i Unicode. Dessa ska inte användas i textfiler. För parenteser gäller att man använder de vanliga ur ASCII-sidan, 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 räknas som bokstäver själva. Program som visar thailändsk text får göra ett speciellt arbete för detta språk. Hindi har ett liknande problem. Vietnamesiska har det latinska alfabetet men med mängder av markeringar över och under som modifierar dem. Unicode har valt såsom tidigare vietnamesisk metod att ha förformade tecken vilket är lättast, även om det är mer än 200 vietnamunika tecken.
Då är kinesiska, japanska och koreanska lättare rent tekniskt, även om det finns många tusen tecken vardera. Det finns lite skrivet i kapitlet Unifiering angående kinesiska tecken. De kinesiska tecknen används för alla de tre språken och bland de 65.535 lägsta kodnumrena i Unicode finns drygt 27.000 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 koreansk standard 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 t.ex. Windows.
Lagring och överföring
Unicode använder teoretiskt c:a 21 bitar för ett tecken, eller mer exakt 1 114 112 möjliga positioner. Strängar av tecken måste lagras på något sätt i datorer, och i filer m.m. Om man lagrar tecknen som heltal med minst 21 bitar blir det ganska rättframt (UTF-32, d.v.s. med 32 bitar, då det är effektivare i dagens datorer än att använda 21 eller 24 bitar). Denna kodform används dock sällan, annat än för enskilda tecken, då den är mer utrymmeskrävande (mesta delen av texten kommer att lagras som null-bytes). Den används ofta internt i program om man inte har så mycket text, då den är enklast.
Vanligare internt i program är att använda UTF-16. Där lagras texten som 16-bits heltal. Det finns en särskild mekanism för att hantera tecken med kod över U+FFFF, vilket ofta inte stöds av program eftersom det är en komplikation och sådana tecken inte är så vanliga. I filer, där 8-bits bytes används får man lagra 16-bits heltalen som två bytes, serialiseringarna UTF-16BE eller UTF-16LE, beroende på ordingen hos dessa två bytes.
Ett vanligt sätt för filer är att använda UTF-8, vilket utan tvetydigheter blir 8-bit bytes, 1-4 st per tecken. Det passar för bl.a. XHTML-sidor, C-program och liknande dataspråk med engelska nyckelord. Engelska bokstäver och andra 7-bits ASCII-tecken lagras då oförändrade. UTF-8 används för Wikipedias sidor.
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-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.
Relation till ISO/IEC 10646
Unicode har samma teckenallokering, inklusive teckennamn, som den internationella standarden ISO/IEC 10646 (Universal 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 bl.a. "generell kategori" (bokstav, siffra, m.m.), radbrytningsegenskaper, egenskaper för bidirektionalitet, och mycket mer.
ISO/IEC 10646 har formaliserade "delmängder", vilket Unicode inte har.
Användning av Unicode
Unicode i textfiler
För rena texfiler 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.
Unicode i programspråk
I programspråk som C kan man i princip använda UTF-8 i källkoden. Även äldre kompilatorer bör stödja det, men nya bibiotek för in/utmatning behövs då.
Under körning av programmen kan man välja på UTF-8 och UTF-16, där UTF-8 har fördelen att det är mer kompatibelt med äldre bibliotekskod, medan UTF-16 anses passa bättre om det stöds av standardbiblioteken. 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 är med UTF-16 om man inte stödjer tecken över U+FFFF.
Unicode i HTML och XML
Märkspråken HTML (som är SGML-baserat) och XML, och därmed alla XML-baserade dokumentformat (t.ex: XHTML, XSL och SMIL), har ISO 10646 (se ovan för förklaring) som s.k. dokumentteckenmängd[1]. 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 teckenkodningasangivelsen 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.k. 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 så 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.
Unicode i e-post
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 (bl.a. 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.
Unicode i Internets domännamn och webbadresser
Å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.[2]. 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. Det finns också en process att tillåta Unicode också i toppdomänen, det vill säga till exempel landskoden ".рф". Det skulle införas 2008, men är fördröjt.
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 skall användas, vilket kan misslyckas till exempel om webbläsaren använder UTF-8 och webbservern Latin-1 eller Windows-1252.
Källor
- Denna artikel är helt eller delvis baserad på material från engelskspråkiga Wikipedia
Se även
Externa länkar
- unicode.org - Officiell webbplats.
- Vad är Unicode?
- DecodeUnicode
- Unicode Snowman for You