Bedste svar
De andre svar er ikke helt rigtige.
Unicode , det er sandt, indeholder en liste over tegn fra næsten alle verdensmanuskripter. Dette er dog kun en del af Unicode-standarden: Universal Coded Character Set . Unicode-standarden indeholder også regler til gengivelse, ordning, normalisering og, ja, kodning af disse Unicode-tegn.
UTF-8 er en af de tre standardkodningskoder, der bruges til at repræsentere Unicode som computertekst (de andre er UTF-16 og UTF-32). Historisk blev tekstfiler typisk kodet som sekvenser af bytes, hvor hver byte repræsenterede et tegn. Da en byte kun kan tage en af 256 værdier, er dette imidlertid ikke muligt for Unicode. Den enkleste Unicode-kodning er UTF-32 , som bruger 4 bytes (eller 32 bit) pr. Tegn. Dette er imidlertid ineffektivt i brugen af lager, hukommelse og behandling. Indtil 1996 blev det troet (eller håbet), at 2 byte ville være nok til at repræsentere alle Unicode-tegn, men så indså folk, hvor mange kinesiske tegn der er. Som et resultat bruger nogle sprog som JavaScript stadig 2 bytes ( UCS-2 ) til at repræsentere tegn, hvilket kan forårsage problemer ved håndtering af tegn som \ unicode {x1F60E }. For at løse dette blev UCS-2 erstattet af UTF-16 , hvor nogle tegn blev repræsenteret af to to-byte kodeenheder snarere end en. Dette gør strengmanipulation mere kompleks (for eksempel at beregne længden af en streng), men bruger mindre plads end UTF-32.
UTF-8 ligner UTF-16, bortset fra at dens kodeenheder alle er en byte (8 bit) lange med tegn repræsenteret af mellem en og fire kodeenheder. Almindelig tekst (dvs. ASCII) tegn er alle repræsenteret af en enkelt byte på en måde, der er identisk med normale ikke-Unicode-strenge. Dette har den store fordel, at ældre ASCII-tekst også er gyldig UTF-8. Desuden bruges bytes, der repræsenterer ASCII, ikke til gengivelse af andre tegn, så ældre programmer, der søger efter dem, behøver ikke at blive opdateret. Disse fordele kombineret med det faktum, at UTF-8 normalt er den mest pladseffektive måde at gemme Unicode-tekst (især til vestlige tekster) betyder, at langt størstedelen af websider i disse dage er kodet i UTF-8.
Svar
Tekstbehandlingsprogrammet skal levere noget (og gem noget i en fil). Hvis du vil have programmer til at fungere sammen, skal dit tekstbehandlingsprogram f.eks. tale med din printer og scannerdrivere, skal du beskrive, hvordan de kommunikerer. Og du vil gerne gøre det effektivt. en standard muliggør denne interkommunikation. Ellers fungerer dine Microsoft Word-smarte citater ikke sammen med din Canon-printer og HP-scanner. Ikke hvad du vil …
Rediger tilføjet: Se Comets svar om, hvordan unicode er relateret til semantik (ikke syntaks /repræsentation). Dette går til mit punkt om interoperabilitet. Du ønsker, at din tegnsekvens skal være “meningsfuld”. Derfor er nogle ting repræsenteret i unicode, og andre ikke. Brugere af det latinske alfabet, de kyrilliske alfabetbrugere, de græske alfabetbrugere og de tyrkiske alfabetbrugere har alle et bogstav, der ligner “a” (skønt de i nogle skrifttyper kan skelnes og i andre ikke), men forfatterne på disse sprog betragter dem forskellige tegn (de har en semantisk forskel). Således betragter unicode dem som forskellige kodepunkter. De repræsenterer forskellige semantikker, sorterer forskelligt osv. Det samme gælder for venstre og højre citater og visse accenttegn. På nogle sprog gør de en semantisk forskel. Du får en bestemt slags interoperabilitet, når du repræsenterer semantik korrekt.
Du får en anden slags, når du repræsenterer ting billedligt korrekt. Imidlertid stræber unicode efter det første, ikke det andet.
Hvis unicode repræsenterede homoglyffer som enkelttegn, ville de have problemet med, hvilken skrifttype der blev brugt, og det ville ødelægge semantisk korrekthed. Et latinsk bogstav a med sort skrifttype er meget forskelligt fra et helvetisk fra et romersk osv. Og skrå og kursiv er ikke altid det samme, men nogle gange er det.
Når jeg læser skilte i Bulgarien, er de fleste nogle gange bruger de en meget anden skrifttype til deres kyrilliske tegn end deres latinske transkription, så det er tydeligt, at de er forskellige tegn, selv for ting som bogstavet “a”. Men nogle gange gør de det ikke, og når jeg ser Bm på en nummerplade, skal jeg skelne, om den transkriberes til Vt på engelsk eller simpelthen er den latinske Bm, og der er hele ord som jeg skal læse for at vide, hvilket tegnsæt de bruger.
Og selv det er svært at få semantisk korrekthed. De tyske skarpheder findes kun med små bogstaver, og hvis du udskriver ordet med alle små bogstaver, bruger du to S-tegn, men der er ord med små bogstaver, der bruger to “små bogstaver” og dem, der bruger skarpe s.
Således, som næsten alle standarder, er unicode et kompromis. Det forsøger at få svarene rigtige, så ord er korrekt repræsenteret og kan overføres ved hjælp af det. Det forsøger ikke at være “grafisk” korrekt, så en unicode-sekvens beskriver dets trykte repræsentation utvetydigt med alle foreskrevne detaljer. Du har brug for mere end unicode for at gøre det.
Og når du går ned ad den sti, har du problemet med enheder, der ikke kan output (eller indtaste) den beskrivelse, du ønsker angivet. En 200 dpi printer kan kun gøre så meget, og der er finesser, som en 1200 dpi printer kan udtrykke, som simpelthen går tabt ved 200 dpi. Spørgsmålet bliver, om du er ligeglad? Nogle gange gør du det, men andre gange ikke.
Unicode er godt i mange tilfælde, hvor du ikke ønsker det og blot ønsker den rigtige semantik. Når du vil overføre et ord utvetydigt, og ved at vide, hvilke unicode-kodepunkter der bruges, skal du vide, hvordan ordet staves på et naturligt sprog. Eksistensen af homoglyffer tillader en at være tvetydig, men kræver det ikke. Du kan være entydig i unicode. Du kan bare ikke repræsentere alle detaljer om, hvordan den kan blive udskrevet .