UTF-8 (forkortelse for Universal Character Set Transformation Format - 8 bits ) er en kodning af computerkarakterer designet til at kode tegnsættet fra "universal coded character repertoire", oprindeligt udviklet af ISO i standarden. International ISO / IEC 10646 , nu fuldt kompatibel med Unicode- standarden , mens den fortsat er kompatibel med ASCII- standarden begrænset til grundlæggende engelsk, men i vid udstrækning brugt i årtier.
UTF-8 bruges af 82,2% af webstederne i december 201487,6% i 2016, 90,5% i 2017, 93,1% i februar 2019 og næsten 95,2% i oktober 2020. UTF-8 bruges af sin art i stigende grad på Internettet og i systemer, der har brug for at udveksle information. Det er også den mest anvendte kodning i GNU , Linux og kompatible systemer til at styre tekster og deres oversættelser så enkelt som muligt i alle skrivesystemer og alle alfabeter i verden.
UTF-8 er en "transformation format" oprindeligt fra arbejde til ISO / IEC 10646 standarden , dvs. UTF-8 definerer en kodende for enhver skalar kodepunkt ( abstract karakter eller "ikke-tegn”) fra Universal tegnsæt ( UCS ) vejviser. Denne mappe er nu fælles for ISO / IEC 10646-standarden (siden revision 1) og for Unicode- standarden (siden dens version 1.1).
UTF-8 er officielt defineret i ISO / IEC 10646-standarden siden vedtagelsen i en ændring offentliggjort i 1996. Den blev også beskrevet i Unicode- standarden og har været en del af denne standard siden version 3.0 offentliggjort i 2000. I 1996 blev offentliggjort RFC 2044 (" UTF-8, et transformationsformat på ISO 10646 ") for at give en tilgængelig specifikation af UTF-8 og begynde sin standardisering inden for Internet Engineering Task Force (IETF). Denne RFC blev revideret i 1998 ( RFC 2279) og endelig i 2003 ( RFC 3629), hvor sidstnævnte version gjorde UTF-8 til en af Internets standarder (STD 63).
Teknisk set involverer dette kodning af Unicode- tegn i form af sekvenser på et til fire kodepunkter med en byte hver. Unicode-standarden definerer blandt andet et sæt (eller bibliotek) med tegn. Hvert tegn identificeres i dette sæt med et helt indeks, også kaldet " kodepunkt ". For eksempel tegnet ”€” ( euro ) er den 8365 th karakter Unicode biblioteket, dets indeks, eller kode punkt, er derfor 8364 (0x20AC) (vi begynder at tælle fra 0).
Unicode-biblioteket kan indeholde over en million tegn, som er alt for stort til at blive kodet som en enkelt byte (begrænset til værdier mellem 0 og 255). Unicode-standarden definerer derfor standardiserede metoder til kodning og lagring af dette indeks i form af en bytesekvens: UTF-8 er en af dem sammen med UTF-16 , UTF-32 og deres forskellige varianter.
Hovedkarakteristikken ved UTF-8 er, at den er bagudkompatibel med ASCII-standarden, det vil sige, at ethvert ASCII-tegn er kodet i UTF-8 i form af en enkelt byte, identisk med ASCII-koden. For eksempel har “A” (store bogstaver A) ASCII-kode 65 (0x41) og er kodet i UTF-8 af byte 65. Hvert tegn, hvis kodepunkt er større end 127 (0x7F) (ikke-ASCII-tegn) er kode på 2 til 4 byte . “€” (euro) -tegnet er kodet for eksempel på 3 bytes : 226, 130 og 172 (0xE2, 0x82 og 0xAC).
Antallet (skalarværdi) for hvert kodepunkt i Universal Character Set (UCS) gives af standarden ISO / IEC 10646, der tildeler et kodepunkt til hvert tegn gyldigt og tillader deres kodning ved at tildele en skalarværdi identisk med kodepunktet ; denne standard er inkluderet i Unicode- standarden (som bruger den samme mappe siden version 1.1).
Alle " kodepunkter " fra U + 0000 til U + D7FF og fra U + E000 til U + 10FFFF er repræsentative i UTF-8 - også dem, der er tildelt "ikke-tegn" ( ikke-tegn ) og alle dem, der endnu ikke er tildelt - og kun dem. De eneste kodepunkter, der er gyldige i UCS-rummet, og som ikke skal være repræsenteret i UTF-8, er dem, der er tildelt " halvkodepunkterne " ( surrogater på engelsk), fordi de ikke er repræsentative på en måde. Bijektive i UTF-16-kodningen og er heller ikke tegn i sig selv: i modsætning til andre kodepunkter har halvkoder derfor ikke en defineret " skalær værdi ".
Punktkoden med en skalarværdi fra 0 til 127 (U + 0000 kodepunkter U + 007F, der er tildelt tegnene i sættet kodet på 7 bit i ASCII) er kodet på en byte, hvoraf den bit, der er mest signifikant, er nul.
De andre kodepunkter (tildelt eller ikke til tegn) med en skalarværdi større end 127 (undtagen dem, hvortil der er tildelt "halvkoder", som ikke selv er tegn), er kodet på flere byte, der hver har deres egne. mest signifikante bit: de mest betydningsfulde bits i den første byte i den kodede sekvens danner en sekvens med 1's længde svarende til det samlede antal bytes (mindst 2), der er brugt til hele sekvensen efterfulgt af en 0, og de efterfølgende krævede bytes har deres to mest betydningsfulde bits er sat til 10.
Kodede tegn | UTF-8 binær repræsentation | Første gyldige byte (hexadecimal) | Betyder |
---|---|---|---|
U + 0000 til U + 007F | 0 xxxxxxx | 00 til 7F | 1 byte, der koder for 7 bit |
U + 0080 til U + 07FF | 11 0 xxxxx 10 xxxxxx | C2 til DF | 2 bytes, der koder 11 bit |
U + 0800 til U + FFFF | 111 0 xxxx 10 xxxxxx 10 xxxxxx | E0 til EF | 3 byte, der koder for 16 bit |
U + 10000 til U + 10FFFF | 1111 0 xxx 10 xxxxxx 10 xxxxxx 10 xxxxxx | F0 til F4 | 4 bytes, der koder for 21 bit |
Dette princip kunne udvides til otte bytes for et enkelt kodepunkt (til at repræsentere kodepunkter på op til 42 bit), men den nuværende standardiserede version af UTF-8 sætter grænsen til fire.
Kodningen forbyder repræsentation af kodepunkter reserveret til halvkoder (som ikke har en defineret skalær værdi for at bevare kompatibilitet med UTF-16, som heller ikke tillader dem at blive repræsenteret). Det tillader dog repræsentation af kodepunkter, der er tildelt ikke-tegn (selvom deres tilstedeværelse er forbudt i en overensstemmelsestekst).
Type | Karakter |
Kode punkt (hexadecimal) |
Skalarværdi | UTF-8-kodning | ||
---|---|---|---|---|---|---|
decimal | binær | binær | hexadecimal | |||
Styring | [INGEN] | U + 0000 | 0 | 0 | 0 0000000 | 00 |
[OS] | U + 001F | 31 | 1111 | 0 0011111 | 1F | |
Tekst | [SP] | U + 0020 | 32 | 100000 | 0 0100000 | 20 |
PÅ | U + 0041 | 65 | 100.0001 | 0 100.0001 | 41 | |
~ | U + 007E | 126 | 111 1110 | 0 1111110 | 7E | |
Styring | [AF] | U + 007F | 127 | 111 1111 | 0 1111111 | 7F |
[PAD] | U + 0080 | 128 | 000 1000 0000 | 110 000 10 10 000 000 | C2 80 | |
[APC] | U + 009F | 159 | 000 1001 1111 | 110 000 10 10 011 111 | C2 9F | |
Tekst | [NBSP] | U + 00A0 | 160 | 000 1010 0000 | 110 000 10 10 100 000 | C2 A0 |
é | U + 00E9 | 233 | 000 1110 1001 | 110 000 11 10 101 001 | C3 A9 | |
߿ | U + 07FF | 2047 | 111 1111 1111 | 110 111 11 10 111 111 | DF BF | |
ࠀ | U + 0800 | 2048 | 1000 0000 0000 | 1110 0000 10 1000 00 10 000000 | E0 A0 80 | |
€ | U + 20AC | 8 364 | 100000 10101100 | 1110 0010 10 0000 10 10 101100 | E2 82 AC | |
| U + D7FF | 55,295 | 1101 0111 1111 1111 | 1110 1101 10 0111 11 10 111111 | ED 9F BF | |
Halvkodet | U + D800 | (ikke noget) | (kodning forbudt) | |||
U + DFFF | ||||||
Privat brug | [] | U + E000 | 57,344 | 1110 0000 0000 0000 | 1110 1110 10 0000 00 10 0000000 | EE 80 80 |
[] | U + F8FF | 63.743 | 1111 1000 1111 1111 | 1110 1111 10 1000 11 10 111111 | EF A3 BF | |
Tekst | U + F900 | 63 744 | 1111 1001 0000 0000 | 1110 1111 10 1001 00 10 000 000 | EF A4 80 | |
﷏ | U + FDCF | 64 975 | 1111 1101 1100 1111 | 1110 1111 10 1101 11 10 001111 | EF B7 8F | |
Ikke-tegn | U + FDD0 | 64 976 | 1111 1101 1101 0000 | 1110 1111 10 1101 11 10 010000 | EF B7 90 | |
U + FDEF | 65,007 | 1111 1101 1110 1111 | 1110 1111 10 1101 11 10 101111 | EF B7 AF | ||
Tekst | ﷰ | U + FDF0 | 65,008 | 1111 1101 1111 0000 | 1110 1111 10 1101 11 10 110000 | EF B7 B0 |
U + FFFD | 65.533 | 1111 1111 1111 1101 | 1110 1111 10 1111 11 10 111101 | EF BF BD | ||
Ikke-tegn | U + FFFE | 65.534 | 1111 1111 1111 1110 | 1110 1111 10 1111 11 10 111110 | EF BF BE | |
U + FFFF | 65.535 | 1111 1111 1111 1111 | 1110 1111 10 1111 11 10 111111 | EF BF BF | ||
Tekst | ? | U + 10.000 | 65.536 | 1 0000 0000 0000 0000 | 110 11 000 10 01 0000 10 0000 00 10 000000 | F0 90 80 80 |
? | U + 1D11E | 119.070 | 1 1101 0001 0001 1110 | 11110 000 10 01 1101 10 0001 00 10 011 110 | F0 9D 84 9E | |
? | U + 1FFFD | 131,069 | 1 1111 1111 1111 1101 | 11110 000 10 01 1111 10 1111 11 10 111 101 | F0 9F BF BD | |
Ikke-tegn | U + 1FFFE | 131.070 | 1 1111 1111 1111 1110 | 11110 000 10 01 1111 10 1111 11 10 111 110 | F0 9F BF BE | |
U + 1FFFF | 131.071 | 1 1111 1111 1111 1111 | 110 11 000 10 01 1111 10 1111 11 10 111111 | F0 9F BF BF | ||
Tekst | ? | U + 20.000 | 131.072 | 10 0000 0000 0000 0000 | 110 11 000 10 10 0000 10 0000 00 10 000000 | F0 A0 80 80 |
? | U + 2FFFD | 196,605 | 10 1111 1111 1111 1101 | 11110 000 10 10 1111 10 1111 11 10 111 101 | F0 AF BF BD | |
Ikke-tegn | U + 2FFFE | 196,606 | 10 1111 1111 1111 1110 | 11110 000 10 10 1111 10 1111 11 10 111 110 | F0 AF BF BE | |
U + 2FFFF | 196,607 | 10 1111 1111 1111 1111 | 110 11 000 10 10 1111 10 1111 11 10 111111 | F0 AF BF BF | ||
... andre planer forbeholdt ... | ||||||
Tilbud | ? | U + E0000 | 917.504 | 1110 0000 0000 0000 0000 | 11110 011 10 10 0000 10 0000 00 10 000000 | F3 A0 80 80 |
? | U + EFFFD | 983.037 | 1110 1111 1111 1111 1101 | 11110 011 10 10 1111 10 1111 11 10 111101 | F3 AF BF BD | |
Ikke-tegn | U + EFFFE | 983.038 | 1110 1111 1111 1111 1110 | 11110 011 10 10 1111 10 1111 11 10 111110 | F3 AF BF BE | |
U + EFFFF | 983.039 | 1110 1111 1111 1111 1111 | 11110 011 10 10 1111 10 1111 11 10 111111 | F3 AF BF BF | ||
Privat brug | [?] | U + F0000 | 983.040 | 1111 0000 0000 0000 0000 | 11110 011 10 11 0000 10 0000 00 10 000000 | F3 B0 80 80 |
[ ] | U + FFFFD | 1.048.573 | 1111 1111 1111 1111 1101 | 11110 011 10 11 1111 10 1111 11 10 111101 | F3 BF BF BD | |
Ikke-tegn | U + FFFFE | 1.048.574 | 1111 1111 1111 1111 1110 | 11110 011 10 11 1111 10 1111 11 10 111.110 | F3 BF BF BE | |
U + FFFFF | 1.048.575 | 1111 1111 1111 1111 1111 | 11110 011 10 11 1111 10 1111 11 10 111111 | F3 BF BF BF | ||
Privat brug | [?] | U + 100.000 | 1.048.576 | 1 0000 0000 0000 0000 0000 | 11110 100 10 00 0000 10 0000 00 10 000000 | F4 80 80 80 |
[?] | U + 10FFFD | 1.114.109 | 1 0000 1111 1111 1111 1101 | 11110 100 10 00 1111 10 1111 11 10 111101 | F4 8F BF BD | |
Ikke-tegn | U + 10FFFE | 1.114.110 | 1 0000 1111 1111 1111 1110 | 11110 100 10 00 1111 10 1111 11 10 111110 | F4 8F BF BE | |
U + 10FFFF | 1.114.111 | 1 0000 1111 1111 1111 1111 | 11110 100 10 00 1111 10 1111 11 10 111111 | F4 8F BF BF |
I enhver karakterstreng kodet i UTF-8 bemærker vi, at:
Det største punkt af gyldig kode henføres til et gyldigt tegn ikke privat er U + EFFFD i 15 th Plan (det er endnu ikke tildelt, men kan blive i fremtiden), men UTF-8 kan også bruges, i en standard måde, til at repræsentere ethvert gyldigt tegn til privat brug (i et af de tre områder U + E000 til U + F8FF, U + F0000 til U + FFFFD og U + 100000 til U + 10FFFD).
Uanset om ikke-tegn eller private anvendelsestegn accepteres , overlades applikationer eller teksttransportprotokoller. Men ikke-tegn er normalt ikke accepteres i tekster strengt i overensstemmelse med den Unicode standard eller til ISO / IEC 10646 standarden .
Nogle applikationer pålægger yderligere begrænsninger for de kodepunkter, der kan bruges (for eksempel forbyder HTML- og XML- standarderne i ethvert dokument, der overholder disse specifikationer, tilstedeværelsen af de fleste kontroltegn mellem U + 0000 og U + 001F og mellem U + 0080 og U + 009F, uden for fanebladet U + 0009 betragtes som et tomt tegn og forbyder også ikke-tegn ).
Ethvert kodepunkt er altid repræsenteret af nøjagtig den samme binære rækkefølge, uanset dens relative position i teksten, og disse sekvenser autosynkroniseres på den udelte position af de signifikante kodepunkter (her bytes: vi kan altid vide, om en byte begynder eller ikke en effektiv binær sekvens); denne kodning tillader derfor hurtige tekstsøgningsalgoritmer, såsom Boyer-Moore-algoritmen .
Dette er ikke altid tilfældet med kontekstuelle kodninger (som normalt bruger datakomprimering , f.eks. SCSU defineret i den valgfri UTS-standard nr. 6 teknisk note, der supplerer Unicode-standarden), og som muligvis kræver læsning af teksten helt fra starten. Heller ikke kodningsbaseret på mere end en enkelt tilstandsvariabel (eller som indeholder yderligere redundanskoder); i bedste fald kan nogle af disse kodninger kræve brug af komplekse resynkroniseringsalgoritmer, ofte baseret på heuristik, der kan mislykkes eller føre til falske fortolkninger, hvis teksten ikke læses fra starten (f.eks. BOCU -1).
Princip og unikhed ved kodningI tabellen ovenfor ser vi, at tegnet “€” findes ved kodepunktet U + 20AC, enten i decimal 8364 eller binært: 100.000 10101100.
Dette sidste tal har betydelige binære cifre, så der kræves mindst 14 bit for at kode "€" -tegnet. Den ovenfor præsenterede standard kræver faktisk tre byte for at repræsentere disse tegn.
Med fire tilgængelige byte ville det være muligt at placere op til 21 bits i henhold til denne standard , så især at repræsentere tegnet “€” ved 00000 00 100000 10101100 ved at tilføje 7 nuller til det . Standarden pålægger imidlertid, at et program, der afkoder UTF-8, af sikkerhedsmæssige årsager ikke må acceptere unødvendigt lange byte-strenge som i dette eksempel (undgå brug af for tolerante substringtest). Således vil "€" blive kodet: 11100010 10000010 10101100, men kodningen 11110000 10000010 10000010 10101100, trukket fra repræsentationen af "€" på 21 bit , selvom den er entydig, må ikke bruges.
En sådan længere end nødvendigt form kaldes overlong på engelsk . Sådanne formularer (oprindeligt godkendt i gamle specifikationer, før de successivt blev standardiseret af den oprindelige RFC, der blev offentliggjort af X / Open Consortium , derefter parallelt med ISO 10646-standarden og Unicode-standarden) er forbudte og skal behandles som ugyldige.
Kodningen er forudsigelig og gør det altid muligt at finde positionen for den første byte i en sekvens, der repræsenterer et kodepunkt, fra værdien af en hvilken som helst byte og fra aflæsningen af et begrænset antal nabobyte i de to læseretninger (det vil altid være selve byten eller den første kvalificerede i en af de 1 til 3 nabobytes ).
Sådanne sekvenser siges at være dårligt dannede . (Se referencen ovenfor, især den anden tabel i D36- overensstemmelsesklausulen i standarden eller Unicode- artiklen ).
På den anden side er reserverede kodepunkter (endnu ikke tildelt til tegn) autoriserede (selvom fortolkningen af tegnene muligvis forbliver tvetydige): det er op til applikationerne at afgøre, om disse tegn er acceptable eller ej, velvidende at det samme applikationer vil sandsynligvis fortsat blive brugt, selvom disse positioner er tildelt i Unicode- og ISO 10646-standarderne til nye, fuldt gyldige tegn.
Tilsvarende er andre kodepunkter, der er tildelt permanent til andre “ ikke-tegn ”, forbudt i tekster, der overholder ISO / IEC 10646 eller Unicode- standarden : for eksempel U + x FFFE til U + x FFFF (hvor x angiver et hexadecimalt plannummer fra 0 til 10). Men de forbliver kodelige og dekodbare som sådan i UTF-8 ( ikke-tegn er tilgængelige for applikationer, der kan gøre brug af dem inden for interne API'er, for eksempel som mellemliggende koder, der er nødvendige for implementering af visse processer.).
Begrænsningen af repræsentationen plads til kun kodepunkter mindre end eller lig med U + 10FFFF (ikke inklusive kodepunkter tildelt halv kodepunkter ) har ikke altid været anvendt:
En tekst i US-ASCII er kodet identisk i UTF-8 (når styklisten ikke bruges).
Fordi et tegn er opdelt i en række byte (ikke ord med flere byte), er der ikke noget endianness ( endianness engelsk).
For de fleste latinske script-sprog, digitale datafiler eller programkildekoder eller mange tekstlige kommunikationsprotokoller (såsom FTP , HTTP eller MIME ), der bruger tegn i udstrakt grad (eller nogle gange kun i dele) US-ASCII, UTF-8 kræver færre bytes end UTF-16 eller UTF-32 .
Mange computerprogrammeringsteknikker , der er gyldige med ensartede enkeltbyte-tegn, forbliver gyldige med UTF-8, herunder:
Dette er en selvsynkroniseringskodning (ved at læse en enkelt byte, ved vi, om den er den første af et tegn eller ej).
Kodepunkter er repræsenteret i UTF-8 ved sekvenser af bytes i forskellige størrelser (såvel som i UTF-16), hvilket gør nogle operationer på strenge af kodepunkter mere komplicerede: beregning af antallet af kodepunkter; positionering ved en given afstand (udtrykt i antal kodepunkter) i en tekstfil og generelt enhver operation, der kræver adgang til kodepunktet for position N i en kæde.
En variabel størrelse på tegnene i en streng forhindrer brugen af effektive algoritmer med hensyn til strengesammenligninger, såsom Knuth-Morris-Pratt- algoritmen og straffer derfor kraftigt databehandling af masser som i udnyttelse. Dette problem er dog mere relateret til aspekter af standardisering end kodning.
For sprog, der bruger mange tegn uden for US-ASCII , tager UTF-8 betydeligt mere plads. For eksempel bruger almindelige ideogrammer brugt i tekster på asiatiske sprog som kinesisk eller japansk (f.eks. Kanji ) 3 byte i UTF-8 versus 2 byte i UTF-16.
Generelt optager skrifter, der bruger mange kodepunkter, der er lig med eller større end U + 0800, mere hukommelse, end hvis de var kodet med UTF-16 (UTF-32 vil kun være mere effektiv for tekster, der hovedsageligt bruger skrifter. gamle eller sjældne kodet uden for den grundlæggende flersprogede plan, det vil sige fra U + 10000, men det kan også vise sig at være nyttigt lokalt i visse processer for at forenkle algoritmerne, fordi tegnene der altid har en størrelse fast, konverterer input eller output data fra eller til UTF-8 eller UTF-16 er trivielle).
Ved sit kodningssystem var det muligvis muligt at repræsentere en kode på forskellige måder i UTF-8, hvilket kunne udgøre et sikkerhedsproblem: et dårligt skrevet program kan acceptere et bestemt antal UTF-8-repræsentationer, normalt ugyldigt ifølge RFC 3629 og i specifikationerne (nu svarende til hinanden) offentliggjort af ISO 10646 og Unicode; men dette var ikke tilfældet i henhold til den oprindelige specifikation, som tillod dem at blive konverteret som et enkelt tegn.
Således kan en software, der opdager bestemte tegnstrenge ( for eksempel for at forhindre SQL-injektioner ), mislykkes i sin opgave (dette er ikke længere tilfældet, hvis kodningen er i overensstemmelse med den strenge og standardiserede definition af UTF-8. Først af alle).
Lad os tage et eksempel fra et rigtigt tilfælde af en virus, der angriber HTTP-servere på Internettet i 2001 ( (da) Crypto-Gram: 15. juli 2000 Microsoft IIS og PWS Udvidet Unicode Directory Traversal Sårbarhed Microsoft IIS 4.0 / 5.0 Web Directory Traversal Sårbarhed ) . En sekvens, der skal detekteres, kunne være “/../” repræsenteret i ASCII ( a fortiori i UTF-8) af byte “ 2F 2E 2E 2F ” i hexadecimal notation . Imidlertid ville en misdannet måde at kode denne streng i UTF-8 være " 2F C0 AE 2E 2F ", også kaldet overlang form . Hvis softwaren ikke er omhyggeligt skrevet for at afvise denne kæde, for eksempel ved at sætte den i kanonisk form , åbnes et potentielt sikkerhedsbrud. Dette angreb kaldes directory traversal .
Software, der accepterer tekst kodet i UTF-8, er blevet afskærmet for systematisk at afvise disse lange formularer, fordi de ikke overholder standarden: enten afvises hele teksten; men nogle gange erstattes de ugyldige sekvenser med et substitutionstegn (normalt U + FFFD, hvis applikationen accepterer og behandler dette tegn normalt; undertiden et spørgsmålstegn eller substitutionskontroltegnet SUB U + 001A i ASCII, som kan udgøre andre problemer med kompatibilitet); sjældnere elimineres disse forbudte sekvenser lydløst (hvilket anbefales meget lidt).
UTF-8 kan kun repræsentere nulkontroltegnet (U + 0000) med en enkelt nulbyte, hvilket udgør kompatibilitetsproblemer med behandlingen af strenge, der ikke separat koder deres effektive længde, fordi denne nulbyte ikke repræsenterer så ingen tegn, men slutningen af strengen (meget almindeligt tilfælde på C- eller C ++ -sprog og i operativsystemets API'er). Hvis et null-tegn skal gemmes i en tekst på sådanne systemer, vil det være nødvendigt at ty til et escape-system, specifikt for dette sprog eller system, før kodning i UTF-8 for den således transformerede tekst. I praksis bør ingen gyldig tekst indeholde dette tegn. En anden løsning er at bruge en af de sekvenser, der er forbudt i standard UTF-8-kodning for at kode for tegnet ved denne sekvens; men den således kodede tekst vil ikke være i overensstemmelse med UTF-8-standardkodningen, selvom den således modificerede kodning forbliver i overensstemmelse med et universelt transformationsformat (som dog ikke bør betegnes som "UTF-8"). Se afsnittet nedenfor om ikke-standardvarianter baseret på UTF-8.
Brug af UTF8, som enhver kodning med variabel tonehøjde, i en database udgør flere ydeevne problemer.
Sammenligningsoperationer (=,>, <, MELLEM, LIKE ...), sortering (ORDER BY), gruppering (GROUP BY), som deduplikationsoperationer (DISTINCT) baseret på semantikken i information, er umulige at blive styret direkte i UTF8 .
For tegnstrenge, der omfatter det samme antal bogstaver (for eksempel CHAR (8)), kan antallet af bytes være forskelligt (især på grund af de diakritiske tegn: accenter, ligatur ...), skal de anvendte algoritmer, for udfør for det meste en justering, før du er i stand til at betjene, hvilket medfører en ikke-ubetydelig ekstra behandlingsomkostning.
For eksempel har MySQL / MariaDB DBMS valgt at repræsentere tegnene i strengene præsenteret som UTF8 ved systematisk at bruge 3 bytes pr. Tegn. Konsekvenserne er som følger: tredobling af datamængden og dividering med indeksnøglernes potentielle længde i forhold til ASCII-kodning med tre, og forlængelse af udførelsestiderne for sammenligninger, sorter, grupperinger eller deduplicering. Strengen returneres endelig i UTF8-form efter oprydning af unødvendige bytes.
Andre DBMS'er som Microsoft SQL Server har valgt at komprimere UTF8-understøttelse ved at indsætte de ekstra tegn i en 2-byte-kodning baseret på UNICODE, der udnytter de mellemrum, der er tomme i specifikationen. Den ekstra indsats for oversættelsen til UTF8 ligger kun i omkodningen af tegnene kodet på 2 byte og udvidelsen af dem kodet på 3.
UTF-8 blev opfundet af Kenneth Thompson under en middag med Rob Pike rundtSeptember 1992. Kaldt FSS-UTF derefter , blev det straks brugt i Plan 9- operativsystemet, de arbejdede på. En begrænsning, der skulle løses, var at kode nul- og '/' -tegnene som i ASCII, og at ingen byte, der koder for et andet tegn, har den samme kode. UNIX- operativsystemer kunne således fortsætte med at søge efter disse to tegn i en streng uden softwaretilpasning.
FSS-UTF var genstand for en foreløbig X / Open-standard fra 1993, som blev foreslået til ISO. Sidstnævnte vedtog det som en del af ISO / IEC 10646-standarden under navnet først på UTF-2, derefter til sidst UTF-8.
Graf, der viser brugen af UTF-8 (lyseblå), der overstiger andre større teksttegnkodninger på Internettet. I 2010 var forekomsten af UTF-8 omkring 50%, men i 2016 var det mere som 90%. |
Statistik, der afspejler de anvendte teknologier på webstederne, bestemt ud fra genkendelsesteknikker til forskellige mønstre, herunder HTML-elementer, specifikke HTML-tags (såsom "generator meta" -tagget, JavaScript-koden, CSS-koden, strukturen på webadresserne på webstedet, off-site links, HTTP-overskrifter for eksempel cookies, HTTP-svar på visse anmodninger såsom komprimering.
Statistik baseret på en stikprøve af de 10 bedste websteder ifølge Alexa. Det samlede beløb når ikke 100%, fordi nogle servere bruger mere end en teknologi. |
Kilde w3techs |
Den oprindelige FSS-UTF-kodning var beregnet til at erstatte UTF-1-multibytkodning oprindeligt foreslået af ISO 10646. Denne oprindeligt tilladelige kodning tillod flere binære repræsentationer for det samme tegn (dette var forbudt i den standardiserede version i RFC offentliggjort af X / Åbent konsortium og godkendt af Kenneth Thompson).
Derudover kunne den (i en foreløbig version ikke bibeholdes) kode for alle de tegn, hvis kodepunktsværdi omfattede op til 32 bits ved at definere en ottende type byte (i sekvenser, der omfatter op til 6 byte ), i stedet for de 7 typer af bytes, der endelig bibeholdes for at kode (i sekvenser, der også omfatter op til 6 byte ), peger kun koden op til 31 bit i den oprindelige version af UTF-8 (udgivet af Consortium X / Open under navnet FSS-UTF, derefter foreslået af teknisk udvalg af ISO 10646 som "UTF-2" -forslaget, så stadig i konkurrence med "UTF-1" -forslaget, indtil UTF-2-forslaget bibeholdes og vedtager UTF-8-navnet, der allerede er bevaret og brugt i X / Open og Plan 9).
Denne UTF-8-kodning blev yderligere begrænset, når Unicode og ISO 10646 enige om at afsætte tegn kun i de første 17 fly for at opretholde kompatibilitet med UTF-16 på ubestemt tid (uden at skulle ændre det), ved at begrænse sekvenser indtil 'til 4 byte kun og kun bruge de første 5 af de 7 typer bytes (hvilket nødvendiggjorde at definere som ugyldige nye byteværdier og visse bytesekvenser, dog gyldige individuelt).
IETF kræver nu UTF-8 er understøttet som standard (og ikke blot som en forlængelse understøttes) af alle de nye kommunikationsprotokoller af internettet (offentliggjort i sin RFC nummereret), som udveksling tekst (de ældste protokoller er imidlertid ikke blevet ændret at gøre denne support obligatorisk, men kun udvidet, hvis det er muligt, at understøtte den valgfrit, hvis dette producerer inkompatibilitet eller indfører nye sikkerhedsrisici: dette er tilfældet med protokoller, der er meget udbredt som DNS , HTTP , FTP , Telnet og HTML i de første versioner derefter endnu ikke standardiseret af W3C og ISO).
Det er blevet vigtigt, især i de vigtigste webkommunikationssoftware og i dag operativsystemer:
Imidlertid fortsatte varianter af UTF-8 (baseret på kodningsmulighederne for den oprindelige ubegrænsede version) fortsat med at blive brugt (især i implementeringen af Java-strengserialisering) for at tillade kodning som en. Multibyt undslippe visse reserverede ASCII-tegn, der normalt er kodet i en enkelt byte (for eksempel nulltegnet).
Derudover bruger nogle systemer ubegrænsede strenge: for eksempel repræsenterer Java (og andre sprog inklusive strengmanipulationsbiblioteker i C, PHP, Perl osv.) Tegn med kodningsenheder på 16 bit (hvilket gør det muligt at gemme strenge ved hjælp af UTF -16 kodning, men uden gyldighedsbegrænsninger pålagt af UTF-16 vedrørende forbudte værdier og parring i rækkefølgen af "halvkoder" eller surrogater ); i dette tilfælde behandles kodningsenhederne som binære værdier, og det er nødvendigt at serialisere dem individuelt (uafhængigt af deres mulige fortolkning som tegn eller som kodehalvpunkter). I dette tilfælde serieliseres hver 16-bit kodningsenhed, der repræsenterer et "tegn" (ubegrænset) i form af sekvenser, der omfatter op til 3 bytes hver, og nogle byte, der er forbudt ved implementeringen (for eksempel nul tegn eller fraktionsbjælken ' / 'i et filsystem eller andre enkelt-byte-tegn i andre protokoller) er kodet som dobbelt-byte-escape-sekvenser, hvoraf ingen er nul, blot ved hjælp af kodningsprincippet i den første specifikation af FSS-UTF (før den tilbageholdes af X / Åbent konsortium i sin oprindelige RFC, hvor disse undslip specifikt var forbudt og har været det).
Før vedtagelsen af UTF-2-forslaget, der blev bevaret til UTF-8, var der også en UTF-1-variant, hvor flere kodninger ikke var mulige, men krævede vanskeligere kodning / afkodning for at tage hensyn til placeringen af hver byte. Og brug et antal "magiske" værdier.
Disse varianter skal ikke kaldes "UTF-8".
En af disse ikke-standardvarianter var imidlertid genstand for en senere standardisering (som et alternativ til UTF-16 og anvendelse af par af "halvkoder", der hver blev kodet på 3 bytes, det vil sige 6 bytes i stedet for. Af 4 med UTF-8): se CESU-8 .
Eksempel på en variant anvendt i JavaF.eks. API'er til virtuel Java- integration af Java (til JNI, Java Native Interface eller til serialisering af prækompilerede klasser), som tillader udveksling af ubegrænsede Java-strenge i form af sekvenser af bytes (for at manipulere dem, bruge eller producere ved indfødt kode eller til lagring som en indfødt fil kodet i strenge af bytes), er efterfulgt af "UTFChars" eller "UTF", men denne Java-specifikke kodning er ikke UTF-8 (Suns dokumentation henviser til det som modificeret UTF , men nogle ældre JNI-dokumenter henviser stadig forkert til denne kodning som UTF-8 , som har produceret nogle adfærdsmæssige anomalier i nogle native JNI-biblioteker, især med system-API'er. Ældre native-platforme, der ikke oprindeligt understøtter tegnkodninger over 8 bit ), fordi:
Følgelig :
Disse processer kan være ineffektive til grænseflade mellem store mængder tekst, fordi de kræver tildeling af yderligere hukommelsesbuffere for derefter at interface i native kode med system- eller netværksgrænseflader, der kun accepterer standard UTF-8.
JNI leverer dog også en mere effektiv binær API, der gør det muligt at bruge UTF-16 direkte, i stand til at grænseflade direkte med netværksprotokoller og systemgrænseflader (f.eks. Windows API'er), der understøtter UTF-16, uden at kræve yderligere hukommelsesallokering til transkodning (kun overensstemmelse check kan være nødvendigt, hovedsageligt for at kontrollere den kodede tekst for den korrekte parring af halvkoden eller surrogatet , som Java (som også andre programmeringssprog) tillader at manipulere uden gyldighedsbegrænsning i sine egne tegnstrenge, der ikke er beregnet til kun lagring af tekster kompatibel med UCS). Denne binære API understøttes på alle systemer, hvor Java er blevet porteret, selv dem, hvis operativsystem ikke tilbyder en Unicode-tekst-API (support kan udføres i den oprindelige værtsapplikation eller ved hjælp af standardbibliotekerne, der leveres med JVM eller anden uafhængig native biblioteker.