Hva er fordelen med å velge ASCII-koding fremfor UTF-8?

I noen tilfeller kan det øke tilgangen til individuelle tegn. Se for deg streng str="ABC" kodet i UTF8 og i ASCII (og forutsatt at språket / kompilatoren / databasen vet om koding)

For å få tilgang til tredje (C) tegn fra denne strengen ved hjelp av array-access-operatør som er omtalt i mange programmeringsspråk, vil du gjøre noe sånt som c = str[2].

Nå , hvis strengen er ASCII-kodet, er alt vi trenger å gjøre å hente tredje byte fra strengen.

Hvis imidlertid strengen er UTF-8-kodet, må vi først sjekke om første tegn er en eller to byte-tegn, så må vi utføre samme kontroll på andre tegn, og bare da kan vi få tilgang til tredje karakter. Forskjellen i ytelse vil være større, jo lengre strengen.

Dette er for eksempel et problem i noen databasemotorer, hvor du finner en begynnelse på en kolonne plassert «etter» en UTF-8-kodet VARCHAR. , trenger databasen ikke bare å sjekke hvor mange tegn det er i VARCHAR-feltet, men også hvor mange byte hver av dem bruker.

Kommentarer

• Hvis databasen ikke ‘ t lagrer både » tegnantall » og » antall byte «, så sier jeg ‘ den ‘ har noen problemer …
• TBH Jeg kjenner ingen database som heller vil lagre …
• @Mchl: hvordan forestiller du deg at databasen vet når den har nådd slutten av strengen?
• Vanligvis ved å nå 0x00 eller 0x0000
• @DeanHarding Hvordan forteller karaktertellingen deg hvor det andre tegnet starter ? Eller burde databasen inneholde en indeks for hvert tegnforskyvning også? Merk: Det er ikke ‘ t bare to tegn, men kan være opptil 4 (med mindre det ‘ s 6) stackoverflow.com/questions/9533258/… . (Jeg tror det ‘ er eneste utf-16 som hadde de virkelig lange styggedommene som kunne ødelegge systemet ditt)

Hvis du bare vil bruke US-ASCII (eller ISO 646) delsett av UTF-8, så er det ingen reell fordel for den ene eller den andre; faktisk er alt kodet identisk.

Hvis du kommer til å gå utover US-ASCII-tegnsettet, og bruke (for eksempel) tegn med aksenter, omlapper osv., som brukes i typisk vest-europeiske språk, så er det en forskjell – de fleste av disse kan fremdeles være kodet med en enkelt byte i ISO 8859, men vil kreve to eller flere byte når de er kodet i UTF-8. Det er selvfølgelig også ulemper: ISO 8859 krever at du bruker noen ut av bånd betyr for å spesifisere kodingen som brukes, og den støtter bare ett av disse språkene om gangen. For eksempel kan du kode alle tegnene til kyrillerne (russisk, hviterussisk osv.) alfabetet som bare bruker en byte per stykk, men hvis du trenger / ønsker å blande dem med franske eller spanske tegn (andre enn de i US-ASCII / ISO 646-delmengden), er du ganske uheldig – du må helt endre tegnsett for å gjøre det.

ISO 8859 er egentlig bare nyttig for europeiske alfabeter. For å støtte de fleste alfabeter som brukes i de fleste kinesiske, japanske, koreanske, arabiske osv., alfabeter, må du bruke noen helt andre kodinger. Noen av disse (f.eks. Shift JIS for japansk) er en absolutt smerte å håndtere. Hvis det er noen sjanse for at du noen gang vil støtte dem, vil jeg anse det som verdt å bruke Unicode bare i sak.

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

Kanskje du tenkte på ASCII som er 7-bit og en riktig delmengde av UTF-8. Dvs. hvilken som helst gyldig ASCII-strøm er også en gyldig UTF-8-strøm.

Hvis du tenkte på 8-bits tegnsett, ville en veldig viktig fordel være at alle representable tegn er 8-bits nøyaktig, der i UTF -8 de kan være opptil 24 bits.

Kommentarer

• ja i ‘ jeg snakker om 7-biters ASCII-settet. kan du tenke deg en fordel vi noen gang trenger å lagre noe ascii i stedet for utf-8? (siden 7-bit ville blitt lagret som 8-bit uansett, ville filstørrelsen være nøyaktig den samme)
• Hvis du har tegn som er større enn unicode-verdien 127, kan de ikke lagres i ASCII.
• @Pacerier: En hvilken som helst ASCII-streng er en UTF-8-streng , så det er ingen forskjell . Kodningsrutinen kan være raskere avhengig av strengrepresentasjonen til plattformen du bruker, selv om jeg ikke ville ‘ ikke forvente betydelig hastighet, mens du har et betydelig tap i fleksibilitet.
• @Thor det er nettopp derfor jeg ‘ spør om lagring som ASCII i det hele tatt har noen fordeler
• @Pacerier, hvis du lagrer XML som ASCII, må du bruke f.eks & # 160; for et rom som ikke kan brytes. Dette er mer fyllende, men gjør dataene dine mer motstandsdyktige mot ISO-Latin-1 vs UTF-8-kodingsfeil. Dette er hva vi gjør som vår underliggende plattform gjør mye usynlig magi med tegn. Å være i ASCII gjør dataene våre mer robuste.

Ja, det er fortsatt noen bruksområder der ASCII gir mening: filformater og nettverksprotokoller . Spesielt for bruk der:

• Du har data som er generert og konsumert av dataprogrammer, aldri presentert for sluttbrukere;
• Men som det er nyttig for programmerere for å være i stand til å lese, for å lette utvikling og feilsøking.

Ved å bruke ASCII som koding, unngår du kompleksiteten i multibyte-koding mens du beholder minst noe menneskelig lesbarhet. / p>

Et par eksempler:

• HTTP er en nettverksprotokoll definert i form av sekvenser av oktetter, men det er veldig nyttig (i det minste for engelsktalende programmerere) at disse tilsvarer ASCII-kodingen av ord som «GET», «POST», «Accept-Language» og så videre.
• klumpetyper i PNG-bildeformat består av fire oktetter, men det er praktisk hvis du programmerer en PNG-koder eller dekoder som IDAT betyr» bildedata «, og PLTE betyr» palett «.

Selvfølgelig må du Vær forsiktig med at dataene virkelig ikke kommer til å bli presentert for sluttbrukere, for hvis det ender opp med å være synlig (slik det skjedde i tilfelle nettadresser), vil brukerne med rette forvente at data å være på et språk de kan lese.

Kommentarer

• Vel sagt. Det ‘ er litt ironisk at HTTP, protokollen som overfører mest unicode på planeten, bare trenger å støtte ASCII. (Egentlig antar jeg at det samme gjelder TCP og IP, binær støtte, ASCII-støtte … at ‘ er alt du trenger på det nivået i bunken)

Først og fremst: tittelen din bruker / d ANSI, mens du i teksten refererer til ASCII. Vær oppmerksom på at ANSI ikke tilsvarer ASCII. ANSI inneholder ASCII-settet. Men ASCII-settet er begrenset til de første 128 numeriske verdiene (0 – 127).

Hvis alle dataene dine er begrenset til ASCII (7-bit), spiller det ingen rolle om du bruker UTF-8 , ANSI eller ASCII, da både ANSI og UTF-8 utgjør hele ASCII-settet. Med andre ord: tallverdiene 0 til og med 127 representerer nøyaktig de samme tegnene i ASCII, ANSI og UTF-8.

Hvis du trenger tegn utenfor ASCII-settet, må du velge en koding. Du kan bruke ANSI, men så får du problemer med alle de forskjellige kodesidene.Opprett en fil på maskin A og les den på maskin B kan / vil produsere morsomme tekster hvis disse maskinene er satt opp til å bruke forskjellige kodesider, enkelt fordi numerisk verdi nnn representerer forskjellige tegn på disse kodesidene.

Denne «kodesiden helvete» er grunnen til at Unicode-standard ble definert. UTF-8 er bare en enkelt koding av den standarden, det er mange flere. UTF-16 er den mest brukte siden det er den opprinnelige kodingen for Windows.

Så hvis du trenger å støtte noe utover de 128 tegnene i ASCII-settet, er mitt råd å gå med UTF-8 . På den måten spiller det ingen rolle, og du trenger ikke å bekymre deg for hvilken kodeside brukerne dine har satt opp systemene sine.

Kommentarer

• Hvis jeg ikke trenger å støtte mer enn 128 tegn, hva er fordelen med å velge ACSII-koding fremfor UTF8-koding?
• Foruten å begrense deg til de 128 tegnene? Ikke mye. UTF-8 ble spesielt designet for å imøtekomme ASCII og de fleste vestlige språk som » bare » trenger ANSI. Du vil oppdage at UTF-8 bare vil kode for et relativt lite antall av de høyere ANSI-tegnene med mer enn en byte. Det er en grunn til at de fleste HTML-sidene bruker UTF-8 som standard …
• @Pacerier, hvis du ikke trenger ‘ t trenger koding over 127, Å velge ASCII kan være verdt når du bruker noe API til å kode / dekode, fordi UTF trenger ekstra bitverifisering for å betrakte ekstra byte som samme tegn, det kan ta ytterligere beregning i stedet for ren ASCII som bare leser 8 bits uten bekreftelse. Men jeg anbefaler deg bare å bruke ASCII hvis du virkelig trenger et høyt nivå av optimalisering i store (store store) beregninger og du vet hva du ‘ gjør i den optimaliseringen. Hvis ikke, er det bare å bruke UTF-8.