Hvad er fordelen ved at vælge ASCII-kodning frem for UTF-8?

I nogle tilfælde kan det fremskynde adgangen til individuelle tegn. Forestil dig streng str="ABC" kodet i UTF8 og i ASCII (og forudsat at sproget / kompilatoren / databasen kender til kodning)

For at få adgang til tredje (C) tegn fra denne streng ved hjælp af array-adgangsoperatør, som findes i mange programmeringssprog, ville du gøre noget som c = str[2].

Nu , hvis strengen er ASCII-kodet, er alt, hvad vi skal gøre, at hente tredje byte fra strengen.

Hvis strengen imidlertid er UTF-8-kodet, skal vi først kontrollere, om det første tegn er en eller to byte-tegn, så skal vi udføre den samme kontrol på det andet tegn, og først derefter kan vi få adgang til tredje karakter. Forskellen i ydeevne vil være jo større, jo længere strengen.

Dette er f.eks. Et problem i nogle databasemotorer, hvor man finder en begyndelse på en kolonne placeret “efter” en UTF-8-kodet VARCHAR , database behøver ikke kun at kontrollere, hvor mange tegn der er i VARCHAR-feltet, men også hvor mange byte hver enkelt af dem bruger.

Kommentarer

• Hvis databasen ikke ‘ ikke gemmer både ” tegnantal ” og ” antal byte “, så siger jeg ‘ det ‘ har nogle problemer …
• TBH Jeg kender ingen database, der heller ikke vil gemme …
• @Mchl: hvordan forestiller du dig, at databasen ved, hvornår den har nået slutningen af strengen?
• Normalt ved at nå 0x00 eller 0x0000
• @DeanHarding Hvordan fortæller tegnet dig, hvor det andet tegn starter ? Eller skal databasen indeholde et indeks for hvert tegn, der forskydes? Bemærk: Det er ikke ‘ t kun 2 tegn, men kan være op til 4 (medmindre det ‘ s 6) stackoverflow.com/questions/9533258/… . (Jeg tror, det ‘ er den eneste utf-16, der havde de virkelig lange vederstyggeligheder, der kunne ødelægge dit system)

Hvis du kun vil bruge US-ASCII (eller ISO 646) delmængde af UTF-8, så er der ingen reel fordel for den ene eller den anden; faktisk er alt kodet ens.

Hvis du vil gå ud over US-ASCII-tegnsættet og bruge (for eksempel) tegn med accenter, umlauter osv., der bruges i typiske vesteuropæiske sprog, så er der en forskel – de fleste af disse kan stadig kodes med en enkelt byte i ISO 8859, men kræver to eller flere byte, når de er kodet i UTF-8. Der er naturligvis også ulemper: ISO 8859 kræver, at du bruger nogle ud af båndmidler til at specificere den kodning, der bruges, og den understøtter kun et af disse sprog ad gangen. For eksempel kan du kode alle tegn på kyrillerne (russisk, hviderussisk osv.) alfabet, der kun bruger en byte pr. stykke, men hvis du har brug for / ønsker at blande dem med franske eller spanske tegn (andre end dem i US-ASCII / ISO 646-delmængde), er du stort set ude af lykke – du skal helt ændre tegnsæt for at gøre det.

ISO 8859 er egentlig kun nyttigt for europæiske alfabeter. For at understøtte de fleste af de alfabeter, der bruges i de fleste kinesiske, japanske, koreanske, arabiske osv., alfabeter, skal du bruge nogle helt forskellige kodninger. Nogle af disse (f.eks. Shift JIS for japansk) er en absolut smerte at håndtere. Hvis der er nogen chance for, at du nogensinde vil støtte dem, vil jeg betragte det som værd at bruge Unicode bare i tilfældet.

ANSI kan være mange ting, de fleste er 8 bit tegnsæt i denne henseende (som kodeside 1252 under Windows).

Måske tænkte du på ASCII, der er 7-bit og en ordentlig delmængde af UTF-8. Dvs. enhver gyldig ASCII-strøm er også en gyldig UTF-8-strøm.

Hvis du tænkte på 8-bit tegnsæt, ville en meget vigtig fordel være, at alle repræsentative tegn er 8-bit nøjagtigt, hvor i UTF -8 de kan være op til 24 bit.

Kommentarer

• ja i ‘ jeg taler om 7-bit ASCII-sættet. kan du tænke på en fordel, vi nogensinde har brug for at gemme noget som ASCII i stedet for UTF-8? (da 7-bit alligevel ville blive gemt som 8-bit, ville filstørrelsen være nøjagtig den samme)
• Hvis du har tegn, der er større end unicode-værdi 127, kan de ikke gemmes i ASCII.
• @Pacerier: En hvilken som helst ASCII-streng er en UTF-8-streng , så der er ingen forskel . Kodningsrutinen kan være hurtigere afhængigt af strengrepræsentationen af den platform, du bruger, selvom jeg ikke ‘ ikke forventer betydelig hastighed, mens du har et betydeligt tab i fleksibilitet.
• @Thor det er netop derfor, jeg ‘ spørger, om gemning som ASCII overhovedet har nogen fordele
• @Pacerier, hvis du gemmer XML som ASCII, skal du bruge f.eks & # 160; for et ikke-brudbart rum. Dette er mere udfyldende, men gør dine data mere modstandsdygtige over for ISO-Latin-1 vs UTF-8 kodningsfejl. Dette er hvad vi gør, da vores underliggende platform gør meget usynlig magi med tegn. At forblive i ASCII gør vores data mere robuste.

Ja, der er stadig nogle brugssager, hvor ASCII giver mening: filformater og netværksprotokoller . Især til anvendelser, hvor:

• Du har data, som “genereres og forbruges af computerprogrammer, aldrig præsenteres for slutbrugere;
• Men som de er nyttige til programmører for at være i stand til at læse, for at lette udvikling og fejlretning.

Ved at bruge ASCII som din kodning undgår du kompleksiteten ved multi-byte-kodning, mens du bevarer mindst en vis menneskelig læsbarhed.

Et par eksempler:

• HTTP er en netværksprotokol defineret i form af sekvenser af oktetter, men det er meget nyttigt (i det mindste for engelsktalende programmører), at disse svarer til ASCII-kodning af ord som “GET”, “POST”, “Accept-Language” og så videre.
• klumptyper i PNG-billedformatet består af fire oktetter, men det er praktisk, hvis du programmerer en PNG-koder eller dekoder, der IDAT betyder” billeddata “, og PLTE betyder” palette “.

Selvfølgelig skal du være forsigtig med at dataene virkelig ikke bliver præsenteret for slutbrugerne, for hvis de ender med at være synlige (som det skete i tilfælde af webadresser), vil brugerne med rette forvente, at data at være på et sprog, de kan læse.

Kommentarer

• Godt sagt. Det ‘ er lidt ironisk, at HTTP, den protokol, der transmitterer den mest unicode på planeten, kun behøver at understøtte ASCII. (Faktisk antager jeg, at det samme gælder TCP og IP, binær support, ASCII-støtte … at ‘ er alt hvad du behøver på det niveau af stakken)

Først og fremmest: din titel bruger / d ANSI, mens du henviser til ASCII i teksten. Bemærk, at ANSI ikke svarer til ASCII. ANSI inkorporerer ASCII-sættet. Men ASCII-sættet er begrænset til de første 128 numeriske værdier (0 – 127).

Hvis alle dine data er begrænset til ASCII (7-bit), betyder det ikke noget, om du bruger UTF-8 , ANSI eller ASCII, da både ANSI og UTF-8 inkorporerer det fulde ASCII-sæt. Med andre ord: de numeriske værdier 0 til og med 127 repræsenterer nøjagtigt de samme tegn i ASCII, ANSI og UTF-8.

Hvis du har brug for tegn uden for ASCII-sættet, skal du vælge en kodning. Du kan bruge ANSI, men så løber du ind i problemerne med alle de forskellige kodesider.Opret en fil på maskine A og læs den på maskine B kan / vil producere sjove udseende tekster, hvis disse maskiner er indstillet til at bruge forskellige kodesider, simpelt fordi numerisk værdi nnn repræsenterer forskellige tegn på disse kodesider.

Denne “kodeside helvede” er grunden til, at Unicode-standard blev defineret. UTF-8 er kun en enkelt kodning af den standard, der er mange flere. UTF-16 er den mest anvendte, da det er den oprindelige kodning til Windows.

Så hvis du har brug for at understøtte noget ud over de 128 tegn i ASCII-sættet, er mit råd at gå med UTF-8 . På den måde betyder det ikke noget, og du behøver ikke bekymre dig om, hvilken kodeside dine brugere har oprettet deres systemer.

Kommentarer

• hvis jeg ikke behøver at understøtte mere end 128 tegn, hvad er fordelen ved at vælge ACSII-kodning frem for UTF8-kodning?
• Udover at begrænse dig selv til disse 128 tegn? Ikke meget. UTF-8 blev specielt designet til at tage højde for ASCII og de fleste vestlige sprog, der ” kun ” har brug for ANSI. Du vil opdage, at UTF-8 kun koder for et relativt lille antal af de højere ANSI-tegn med mere end en byte. Der er en grund til, at de fleste HTML-sider bruger UTF-8 som standard …
• @Pacerier, hvis du ikke ‘ ikke har brug for kodning over 127, at vælge ASCII kan være værd, når du bruger noget API til at kode / afkode, fordi UTF har brug for yderligere bitbekræftelse for at betragte yderligere byte som det samme tegn, det kan kræve yderligere beregning snarere end ren ASCII, som bare læser 8 bit uden verifikation. Men jeg anbefaler dig kun at bruge ASCII, hvis du virkelig har brug for et højt optimeringsniveau i stor (stor stor) beregning, og du ved, hvad du ‘ laver i den optimering. Hvis ikke, skal du bare bruge UTF-8.