Beste svaret
De andre svarene er ikke helt riktige.
Unicode inneholder riktignok en oversikt over tegn fra nesten alle verdensmanus. Dette er imidlertid bare en del av Unicode-standarden: Universal Coded Character Set . Unicode-standarden inkluderer også regler for gjengivelse, bestilling, normalisering og, ja, koding av disse Unicode-tegnene.
UTF-8 er en av de tre standardkodekodningene som ble brukt til å representere Unicode som datamaskintekst (de andre er UTF-16 og UTF-32). Historisk sett ble tekstfiler vanligvis kodet som sekvenser av byte der hver byte representerte ett tegn. Siden en byte bare kan ta en av 256 verdier, er dette imidlertid ikke mulig for Unicode. Den enkleste Unicode-kodingen er UTF-32 , som bruker 4 byte (eller 32 bits) per tegn. Dette er imidlertid ineffektivt i bruken av lagring, minne og prosessering. Fram til 1996 ble det antatt (eller håpet) at to byte ville være nok til å representere alle Unicode-tegn, men da skjønte folk hvor mange kinesiske tegn det er. Som et resultat bruker noen språk som JavaScript fremdeles to byte ( UCS-2 ) for å representere tegn, noe som kan forårsake problemer når du håndterer tegn som \ unicode {x1F60E }. For å fikse dette ble UCS-2 erstattet av UTF-16 , der noen tegn ble representert med to to-byte kodeenheter i stedet for en. Dette gjør strengmanipulering mer kompleks (for eksempel å beregne lengden på en streng), men bruker mindre plass enn UTF-32.
UTF-8 ligner på UTF-16, bortsett fra at kodenhetene alle er en byte (8 bits) lange, med tegn representert av mellom en og fire kodenheter. Vanlig tekst (dvs. ASCII) tegn er alle representert av en enkelt byte, på en måte som er identisk med normale ikke-Unicode-strenger. Dette har den store fordelen at eldre ASCII-tekst også er gyldig UTF-8. Videre brukes ikke byte som representerer ASCII i representasjonen av andre tegn, så eldre programmer som søker etter de som ikke trenger å bli oppdatert. Disse fordelene, kombinert med det faktum at UTF-8 normalt er den mest plasseffektive måten å lagre Unicode-tekst (spesielt for vestlige tekster) betyr at de aller fleste websider i disse dager er kodet i UTF-8.
Svar
Tekstbehandlingsprogrammet må levere noe (og lagre noe i en fil). Hvis du vil at programmer skal fungere sammen, for eksempel at tekstbehandlingsprogrammet skal snakke med skriveren og skannerdrivere, må du beskrive hvordan de kommuniserer. Og du vil gjøre det effektivt. en standard muliggjør interkommunikasjon. Ellers fungerer ikke dine smarte Microsoft Word-anførselstegn med Canon-skriveren og HP-skanneren din. Ikke hva du vil …
Edit lagt til: Se Comets svar om hvordan unicode er relatert til semantikk (ikke syntaks /representasjon). Dette går til poenget mitt om interoperabilitet. Du vil at tegnsekvensen din skal være «meningsfull». Derfor er noen ting representert i unicode og andre ikke. De latinske alfabetbrukerne, de kyrilliske alfabetbrukerne, de greske alfabetbrukerne og de tyrkiske alfabetbrukerne har alle en bokstav som ser ut som “a” (selv om de i noen skrifter kan skilles og i andre ikke), men forfatterne på disse språkene anser dem forskjellige karakterer (de har en semantisk forskjell). Dermed anser unicode dem som forskjellige kodepunkter. De representerer forskjellig semantikk, sorterer annerledes osv. Det samme gjelder venstre og høyre sitater og visse aksenttegn. På noen språk utgjør de en semantisk forskjell. Du får en viss type interoperabilitet når du representerer semantikk riktig.
Du får en annen type når du representerer ting korrekt. Imidlertid strever unicode for det første, ikke det andre.
Hvis unicode representerte homoglyffer som enkelttegn, ville de ha problemet med hvilken skrift som ble brukt, og det ville ødelegge semantisk korrekthet. En latinsk bokstav a i sort skrift er veldig forskjellig fra en helvetisk bokstav fra en romersk bokstav osv. Og skråstilling og kursiv er ikke alltid det samme, men noen ganger er det.
Når jeg leser tegn i Bulgaria, er de fleste noen ganger bruker de en helt annen skrift for sine kyrilliske tegn enn deres latinske transkripsjon, så det er åpenbart at de er forskjellige tegn, selv for ting som bokstaven «a». Men noen ganger gjør de det ikke, og når jeg ser Bm på en lisensplate, må jeg skille om den transkriberes til Vt på engelsk eller bare er den latinske Bm, og det er hele ord som jeg må lese for å vite hvilket tegnsett de har bruker.
Og til og med å få semantisk korrekthet er vanskelig. Den tyske skarpheten eksisterer bare med små bokstaver, og hvis du skriver ut ordet i store bokstaver, bruker du to S-tegn, men det er ord med små bokstaver som bruker to små bokstaver og de som bruker skarpe s.
Dermed, som nesten alle standarder, er unicode et kompromiss. Den prøver å få svarene riktig slik at ord blir korrekt representert og kan overføres ved hjelp av det. Det prøver ikke å være «grafisk» riktig, slik at en unicode-sekvens beskriver den trykte representasjonen entydig med alle detaljer foreskrevet. Du trenger mer enn unicode for å gjøre det.
Og når du går ned den banen, har du problemet med enheter som ikke kan sende (eller legge inn) beskrivelsen du vil spesifisere. En 200 dpi-skriver kan bare gjøre så mye, og det er finesser en 1200 dpi-skriver kan uttrykke som bare går tapt ved 200 dpi. Spørsmålet blir om du bryr deg? Noen ganger gjør du det, men andre ganger ikke.
Unicode er bra i mange tilfeller der du ikke vil og rett og slett vil ha den rette semantikken. Når du vil overføre et ord entydig og ved å vite hvilke unicode-kodepunkter som brukes, vet du hvordan ordet er stavet på et naturlig språk. Eksistensen av homoglyffer tillater en å være tvetydig, men krever ikke det. Du kan være entydig i unicode. Du kan bare ikke representere alle detaljene for hvordan den kan skrives ut .