Hva er UTF-8: definisjon, drift, feil og bruk

Informatec Digital » Databehandling » Hva er UTF-8: definisjon, drift, feil og bruk

Hvis du leser denne artikkelen i dag uten å se noen merkelige symboler, er det takket være UTF-8 . Denne kodingen gjør at bokstaver, aksenter, tekniske symboler og til og med emojier kan vises på samme måte i alle moderne nettlesere, operativsystemer eller e-postklienter. Det er den mest utbredte standarden på nettet og grunnlaget for digital kommunikasjon slik vi kjenner den.

Når en enhet viser tekst, behandler den faktisk tall . Disse tallene er kodepunkter definert av Unicode-standarden , og for å konvertere dem til byte som beveger seg over et nettverk eller lagres i en fil, utfører vi en transformasjon: UTF-8 . I de følgende linjene vil du forstå hva det er, hvordan det fungerer, hvorfor det ble standard, dets fordeler og begrensninger, og hvordan du unngår vanlige feil.

Hva er UTF-8?

UTF-8 (8-bit Unicode Transformation Format) er en måte å transformere Unicode-kodepunkter til bytesekvenser . Hovedfunksjonen er at den bruker variabel lengde : noen tegn opptar 1 byte, mens andre krever 2, 3 eller 4 byte. Dette gir mulighet for kompakte tekster med enkle latinske tegn , men den kan også representere et hvilket som helst tegn fra Unicode-repertoaret.

Den er fullt kompatibel med ASCII : de første 128 tegnene (U+0000 til U+007F) er kodet med én byte som er identisk med 7-bit ASCII. Dette forenklet overgangen fra eldre systemer og forklarer mye av suksessen på Internett, i e-post og i IETF-protokoller.

UTF-8 skiller seg ut for sin robusthet : den inneholder synkroniseringsbiter som muliggjør pålitelig identifisering av starten på hvert symbol. Denne selvsynkroniseringsegenskapen gjør det enkelt å oppdage om en sekvens "ser ut" som UTF-8 , noe som er veldig nyttig i verktøy og parsere.

Unicode: Grunnlaget for alt

Unicode er den universelle standarden som tildeler et unikt nummer til hvert tegn , uavhengig av språk, plattform eller applikasjon. Dette nummeret kalles et kodepunkt og skrives vanligvis i heksadesimalformat i formatet U+XXXX (eller flere sifre om nødvendig).

Eg Storbokstaven «A» er U+0041I HTML kan vi også referere til det som A. Datamaskinen din «tenker» ikke på A som en bokstav, men som tallet 65, og deretter bestemmer kodingen (som UTF-8) hvordan tallet skal representeres i byte.

Hvis du vil se hvordan Unicode oversettes til tegn på PC-en din , kan du i Windows holde nede Alt-tasten og skrive inn desimalkoden på det numeriske tastaturet: for eksempel returnerer Alt+65 «A» (se hele listen over Alt-koder ). Det er en klassisk snarvei som viser hvordan kodene ligger til grunn for tegnene du ser.

Litt historie: hvordan UTF-8 ble født

UTF-8 ble utviklet av Ken Thompson under veiledning av Rob Pike 2. september 1992. De implementerte det i Plan 9-operativsystemet fra Bell Labs og presenterte det offisielt på USENIX (San Diego, januar 1993) . Under standardiseringen, sponset av X/Open Joint Internationalization Group (XOJIG) , var det kjent under navn som FSS/UTF og UTF-2 før det ble konsolidert som UTF-8.

Designet løste praktiske problemer som plaget tidligere forsøk på universell koding: ASCII-kompatibilitet, selvsynkronisering, ingen overlappende byte og enkel feildeteksjon. Denne balansen gjorde det til de facto-standarden for nettet.

Hvordan UTF-8 fungerer under panseret

UTF-8 grupperer tegn i henhold til antall byte som trengs for å kode dem . Antall byte avhenger utelukkende av Unicode-kodepunktet og følger bitmønstre som angir lengden på sekvensen.

• 1 byte (U+0000 til U+007F)ASCII-tegn. Format: 0xxxxxxxDen mest signifikante biten er 0, som garanterer direkte kompatibilitet med ASCII.
• 2 byte (U+0080 til U+07FF): Format 110yyyyy 10xxxxxx. Den brukes for de fleste europeiske alfabeter med diakritiske tegn og andre som gresk, kyrillisk, hebraisk eller arabisk..
• 3 byte (U+0800 til U+FFFF): Format 1110zzzz 10yyyyyy 10xxxxxx. Inkluderer den flerspråklige basisplanen (BMP), med CJK (kinesisk, japansk, koreansk), tekniske symboler og de mest brukte tegnene.
• 4 byte (U+10000 til U+10FFFF): Format 11110uuu 10uuzzzz 10yyyyyy 10xxxxxx. Representerer de supplerende planeneavanserte matematiske symboler, historiske skrifter, mindre vanlige ideografiske symboler, osv.

Nøkkelen til selvsynkronisering ligger i header-bitene : 0 for ASCII; 110 for to byte; 1110 for tre; 11110 for fire. Fortsettelsesbyte begynner alltid med 10. På grunn av dette kan en fortsettelsesbyte aldri vises som en startbyte , og en gyldig sekvens kan aldri være en delstreng av en lengre (prinsippet om ikke-overlapping).

Ekvivalens med UTF-16 og surrogatpar

UTF-16 representerer BMP-kodepunkter med en enhet på 16 bits og poeng over U+FFFF med erstatningspar innen rekkevidde D800–DFFF. I stedet UTF-8 koder alltid ekte kodepunkter, ikke UTF-16-enheter, noe som unngår forvirring med erstatninger.

Historisk sett tillot noen utkast 5 eller 6 byte i UTF-8 for å dekke et bredere spekter, men Unicode og RFC 3629 begrenser UTF-8 til maksimalt 4 byte . ISO/IEC vurderte bredere alternativer, men disse er ikke en del av den nåværende standarden.

Praktisk eksempel: ñ

Tegnet «ñ» har kodepunkt U+00F1, som faller innenfor tobyte-området. Ved å følge mønsteret er den kodet som 110xxxxx 10xxxxxx. UTF-8-representasjonen er 0xC3 0xB1Dekoding er den motsatte prosessen: å lese de nyttige bitene og rekonstruere det opprinnelige kodepunktet.

Fordeler og begrensninger med UTF-8

Hovedfordeler :

• ASCII-støtteASCII-tekster er gyldige i UTF-8 uten endringer.
• Universellkan representere ethvert Unicode-tegn, inkludert tekniske symboler og emojier.
• Effektivitet i latinske tekster: når du bruker 1 byte for ASCII, sparer plass sammenlignet med UTF-16 på mange vestlige språk.
• Selvsynkronisering og deteksjon: bitmønstre tillater oppdage tegnbegynnelser og validere sekvenser med letthet.

Begrensninger og avveininger :

• CJK-tekst tar opp mer plass enn UTF-16-tekst, hvor mange av disse tegnene passer inn i 2 faste byte.
• Beregningskostnad: har variabel lengde, noen operasjoner (f.eks. «gå til tegn n») krever å gå gjennom fra starten av, og enkelte oppgaver kan være raskere i UTF-16/UTF-32.

BOM (Byte Order Mark) i UTF-8

UTF-8 trenger ikke BOM fordi byterekkefølgen ikke endrer betydningen av verdiene (den minste enheten er byten). Likevel, Det finnes en valgfri stykkliste, tegnet U+FEFF kodet som EF BB BF i starten av en fil eller strøm, som kan brukes til å indikere «dette er Unicode/UTF-8».

Beste praksis : Hvis det dukker opp i begynnelsen, godtar noen systemer det, mens andre behandler det bokstavelig. I sammenkjedede systemer anbefales det å fjerne mellomliggende BOM-er . Det er ikke obligatorisk å inkludere det, og nytten av det i UTF-8 er begrenset sammenlignet med UTF-16/UTF-32, hvor det markerer endianness.

Typiske kodefeil og hvordan man håndterer dem

En robust UTF-8-dekoder må enten avvise feilformede sekvenser eller erstatte dem med U+FFFD (ERSTATNINGSTEGN) eller flagge en feil. De vanligste feilene er:

• Avkortede sekvenser: en flerbyte innledende byte uten tilstrekkelige fortsettelser.
• Løse fortsettelsesbytes: vises 10xxxxxx uten en gyldig leadbyte.
• Overlengder: koding med flere byte enn nødvendig; for eksempel, forsøk på å kode en ASCII med 2 byte (0xC0 y 0xC1 er ugyldige).
• Forbudte lengder: begynner å foreslå 5 eller 6 byte (0xF8-0xFD er ikke gyldige i standard UTF-8).
• Verdier utenfor Unicode-området: støttes ikke over U+10FFFFvisse verdier (0xF5-0xF7 som begynnelser) er ugyldige.
• UTF-16 surrogatpar: D800–DFFF er ikke gyldige kodepunkter i Unicode; de ​​skal ikke vises kodet i UTF-8.

Når du ser tegnet «�» på skjermen , skyldes det mest sannsynlig en kodingsavvik eller en fil som er lagret på en annen kodeside. Løsningen er å tvinge frem ende-til-ende UTF-8-koding (fil, server, database, HTTP-overskrifter).

UTF-8 på nettet og i e-post

En HTML-side trenger bare å deklarere én koding . Den anbefalte kodingen, for kompatibilitet og omfang, er UTF-8. Inkluder følgende metatag i overskriften så snart som mulig:

<meta charset="UTF-8">

Plasser den i begynnelsen av `<head>`-taggen slik at nettleseren leser den før den behandler dokumentet. Dette forhindrer inkonsekvenser og "ødelagte" tegn. Bruken av UTF-8 på nettet er overveldende ; det brukes av de aller fleste nåværende nettsteder.

I e-post er UTF-8 bredt støttet og anbefalt av organisasjoner som Internet Mail Consortium. Å konfigurere e-postklienter til å bruke UTF-8 reduserer problemer ved utveksling av meldinger med personer som snakker andre språk.

UTF-8, UTF-16 og UTF-32: Hva er forskjellen?

UTF-8 : Koding med variabel lengde i 8-bits enheter; ideell for nettet , svært effektiv med ASCII og vestlige språk. Utmerket kompatibilitet og feildeteksjon.

UTF-16 : variabel lengde i 16-bits enheter; bruker surrogatpar for U+10000 og over. Det er ofte fordelaktig når ikke-ASCII-tegn dominerer , og brukes i mange API-er og plattformer (for eksempel kjører Windows innebygd i UTF-16 ).

UTF-32 : fast lengde på 32 bits per tegn; veldig enkel å indeksere , men plasskrevende. Den er reservert for tilfeller der størrelse er sekundært til enkelhet i behandlingen.

Inkompatible varianter: CESU-8 og «Modifisert UTF-8»

CESU-8 koder UTF-16-enheter direkte (inkludert surrogatpar) i stedet for å kode kodepunkter, og skiller seg dermed fra standard UTF-8 for tegn over U+FFFF. Noen historiske plattformer brukte det: Oracle 8 tilbød det under aliaset UTF-8, og fra og med Oracle 9 la det til standard UTF-8 under et annet alias. Java og Tcl har brukt CESU-8 i visse sammenhenger.

Modifisert UTF-8 (for eksempel i Java-miljøer) representerer NUL-tegnet (U+0000) som 0xC0 0x80 i stedet for 0x00. Den unngår nullbyten i C-strenger , men er ikke kompatibel med UTF-8-standarden. Mange implementeringer av denne "modifiserte" versjonen er også i samsvar med CESU-8.

UTF-8 på Windows og API-er: Kodetabeller og konvertering

Windows fungerer internt i UTF-16 (WCHAR), men siden Windows 10 versjon 1903 kan du tving frem UTF-8 som prosesskodesett via applikasjonsmanifestet (egenskap activeCodePageDette gjør det enklere for eldre kode som bruker «-A» API-er å fungere over UTF-8.

API-er -A vs. -W: den -A avhenger av ANSI-kodesiden konfigurert (kan være CP_UTF8), mens -W de bruker UTF-16Å samhandle, MultiByteTilBredTegn y Bredt tegn til flere byte lar deg konvertere mellom UTF-8 og UTF-16; usa CP_UTF8 og, hvis aktuelt, MB_ERR_INVALID_CHARS for å oppdage inndatafeil.

Ekte kompatibilitet: nettlesere og systemer

UTF-8 er kompatibel med moderne nettlesere (Chrome, Firefox, Safari, Edge, Opera og nyere versjoner av Internet Explorer) og de fleste operativsystemer (Windows, Linux, macOS, Android, iOS). Med mindre du har veldig gammel programvare, burde du ikke ha noen problemer.

Slik konverterer du filer til UTF-8

I Windows (Notisblokk) : åpne filen, gå til «Fil > Lagre som…», og velg UTF-8 i «Koding» . Lagre med et nytt navn hvis du vil beholde originalen.

I macOS (TextEdit) : I «TextEdit > Innstillinger > Åpne og lagre» velger du Unicode (UTF-8) når du lagrer. Eksporter deretter filen med det alternativet aktivert.

På Linux: med terminalen du kan bruke iconv. For eksempel: iconv -f <codificación_origen> -t UTF-8 <entrada> -o <salida>. Sjekk senere at applikasjonen som bruker den også forventer UTF-8.

Hvordan kan du vite om en fil er i UTF-8? Mange moderne editorer indikerer dette i statuslinjen. Hvis du ser merkelige tegn som «�», ødelagte aksenter eller feilaktig viste «ñ/ç», sjekk filkodingen og innstillingene for editor/server/database.

Gode ​​vaner for å unngå overraskelser

Deklarer UTF-8 så tidlig som mulig i HTML- og HTTP-overskrifter. Juster kodingen gjennom hele stakken (kildefiler, maler, database og tilkobling). Unngå å blande kodinger på samme side eller flyt, og bruk verktøy som validerer/normaliserer input.

For integrasjoner og API-er, spesifiser alltid kodingen i overskriftene (Content-Type: application/json; charset=UTF-8, for eksempel). Test med flerspråklige data (aksenter, CJK, emojier) for å oppdage svake punkter før produksjon.

UTF-8 vant fordi den balanserer kompatibilitet, effektivitet og rekkevidde . Det er den mest praktiske måten å sikre at tekst forflytter seg intakt på tvers av kulturer, systemer og applikasjoner, uavhengig av om den inneholder aksenter, tekniske symboler eller ikke-latinske skrifttyper.