Wat is het voordeel van ASCII-codering boven UTF-8?

In sommige gevallen kan het de toegang tot individuele karakters versnellen. Stel je voor dat string str="ABC" gecodeerd is in UTF8 en in ASCII (en ervan uitgaande dat de taal / compiler / database weet van codering)

Om toegang te krijgen tot derde (C) teken uit deze string met behulp van de array-access operator die in veel programmeertalen voorkomt, zou je zoiets doen als c = str[2].

Nu , als de string ASCII-gecodeerd is, hoeven we alleen de derde byte uit de string op te halen.

Als de tekenreeks echter UTF-8-gecodeerd is, moeten we eerst controleren of het eerste teken een teken van één of twee bytes is, dan moeten we dezelfde controle uitvoeren op het tweede teken, en alleen dan hebben we toegang tot de derde teken. Het verschil in prestatie zal groter zijn naarmate de string langer is.

Dit is bijvoorbeeld een probleem in sommige database-engines, waar het begin van een kolom kan worden gevonden “na” een UTF-8 gecodeerde VARCHAR , hoeft de database niet alleen te controleren hoeveel tekens er in het VARCHAR-veld staan, maar ook hoeveel bytes elk ervan gebruikt.

Opmerkingen

• Als de database ‘ t zowel de ” karaktertelling ” en de ” bytetelling “, dan zeg ik ‘ it ‘ s heeft wat problemen …
• TBH Ik ken geen database die een van beide zou opslaan …
• @Mchl: hoe stel je je voor dat de database weet wanneer het het einde van de string heeft bereikt?
• Meestal door 0x00 of 0x0000 te bereiken
• @DeanHarding Hoe vertelt het aantal karakters je waar het tweede karakter begint ? Of moet de database ook een index bevatten voor elke tekenoffset? Opmerking: het is niet ‘ t slechts 2 tekens, maar het kan maximaal 4 zijn (tenzij het ‘ s 6) stackoverflow.com/questions/9533258/… . (Ik denk dat het ‘ de enige utf-16 is die de echt lange gruwelen had die je systeem konden vernietigen)

Als je “alleen de US-ASCII (of ISO 646) subset van UTF-8 gaat gebruiken, dan is er geen echt voordeel voor de een of de ander; in feite is alles identiek gecodeerd.

Als u “verder gaat dan de US-ASCII-tekenset en (bijvoorbeeld) tekens met accenten, umlauten, enz. gebruikt die in typische West-Europese talen, dan is er een verschil – de meeste hiervan kunnen nog steeds worden gecodeerd met een enkele byte in ISO 8859, maar zullen twee of meer bytes nodig hebben wanneer ze gecodeerd zijn in UTF-8. Er zijn natuurlijk ook nadelen: ISO 8859 vereist dat u een aantal out-of-band-middelen gebruikt om de gebruikte codering te specificeren, en het ondersteunt slechts één van deze talen tegelijk. U kunt bijvoorbeeld alle tekens van het Cyrillische (Russisch, Wit-Russisch, enz.) alfabet met slechts één byte per stuk, maar als je die met Franse of Spaanse karakters (anders dan die in de US-ASCII / ISO 646-subset) nodig hebt / wilt hebben, heb je vrijwel geen geluk – je moet volledig verander tekensets om dat te doen.

ISO 8859 is eigenlijk alleen nuttig voor Europese alfabetten. Om de meeste alfabetten te ondersteunen die worden gebruikt in de meeste Chinese, Japanse, Koreaanse, Arabische, enz. alfabetten, moet u een totaal andere codering. Sommige hiervan (bijv. Shift JIS voor Japans) zijn absoluut lastig om mee om te gaan. Als er een kans bestaat dat u ze ooit wilt ondersteunen, zou ik het de moeite waard vinden om Unicode alleen in case.

ANSI kan veel dingen zijn, de meeste zijn in dit opzicht 8 bit tekensets (zoals codetabel 1252 onder Windows).

Misschien dacht u aan ASCII, dat 7-bit is en een goede subset van UTF-8. D.w.z. elke geldige ASCII-stream is ook een geldige UTF-8-stream.

Als u aan 8-bits tekensets dacht, zou een zeer belangrijk voordeel zijn dat alle representeerbare tekens precies 8-bits zijn, waarbij in UTF -8 ze kunnen maximaal 24 bits zijn.

Reacties

• ja ik ‘ m heb het over de 7-bits ASCII-set. kun je 1 voordeel bedenken dat we ooit nodig zullen hebben om iets op te slaan als ascii in plaats van utf-8? (aangezien de 7-bit sowieso als 8-bit zou worden opgeslagen, zou de bestandsgrootte exact hetzelfde zijn)
• Als je tekens hebt die groter zijn dan de unicode-waarde 127, kunnen ze niet worden opgeslagen in ASCII.
• @Pacerier: Elke ASCII-string is een UTF-8-string , dus er is geen verschil . De coderingsroutine zou sneller kunnen zijn, afhankelijk van de tekenreeksweergave van het platform dat je gebruikt, hoewel ik ‘ geen significante versnelling zou verwachten, terwijl je een aanzienlijk verlies hebt in flexibiliteit.
• @Thor dat is precies waarom ik ‘ m vraag of opslaan als ASCII überhaupt voordelen heeft
• @Pacerier, als u XML opslaat als ASCII, moet u bijv & # 160; voor een niet-breekbare ruimte. Dit is meer vullend, maar maakt uw gegevens beter bestand tegen ISO-Latin-1 versus UTF-8 coderingsfouten. Dit is wat we doen, aangezien ons onderliggende platform veel onzichtbare magie doet met personages. Door in ASCII te blijven, worden onze gegevens robuuster.

Ja, er zijn nog steeds enkele gebruiksscenarios waarin ASCII is logisch: bestandsindelingen en netwerkprotocollen . In het bijzonder voor toepassingen waarbij:

• U gegevens heeft die zijn gegenereerd en gebruikt door computerprogrammas, nooit aan eindgebruikers worden gepresenteerd;
• Maar waarvoor het nuttig is programmeurs om te kunnen lezen, voor gemakkelijke ontwikkeling en foutopsporing.

Door ASCII als uw codering te gebruiken, vermijdt u de complexiteit van multi-byte codering terwijl u op zijn minst enige menselijke leesbaarheid behoudt. / p>

Een paar voorbeelden:

• HTTP is een netwerkprotocol gedefinieerd in termen van reeksen octetten, maar het is erg handig (in ieder geval voor Engelssprekende programmeurs) dat deze overeenkomen met de ASCII-codering van woorden als “GET”, “POST”, “Accept-Language” enzovoort.
• De bloktypen in de PNG-afbeeldingsindeling bestaan uit vier octetten, maar het is handig als je een PNG-encoder of -decoder programmeert die IDAT betekent” afbeeldingsgegevens “, en PLTE betekent” palet “.

Natuurlijk moet u wees voorzichtig dat de gegevens echt niet aan eindgebruikers zullen worden gepresenteerd, want als ze zichtbaar worden (zoals is gebeurd in het geval van URLs), zullen gebruikers die gegevens terecht verwachten om in een taal te zijn die ze kunnen lezen.

Reacties

• Goed gezegd. Het is ‘ een beetje ironisch dat HTTP, het protocol dat de meest unicode ter wereld uitzendt, alleen ASCII hoeft te ondersteunen. (Eigenlijk denk ik dat hetzelfde geldt voor TCP en IP, binaire ondersteuning, ASCII-ondersteuning … dat ‘ alles is wat je nodig hebt op dat niveau van de stack)

Allereerst: uw titel gebruikt / d ANSI, terwijl u in de tekst verwijst naar ASCII. Houd er rekening mee dat ANSI niet gelijk is aan ASCII. ANSI bevat de ASCII-set. Maar de ASCII-set is beperkt tot de eerste 128 numerieke waarden (0 – 127).

Als al uw gegevens beperkt zijn tot ASCII (7-bit), maakt het niet uit of u UTF-8 gebruikt , ANSI of ASCII, aangezien zowel ANSI als UTF-8 de volledige ASCII-set bevatten. Met andere woorden: de numerieke waarden 0 tot en met 127 vertegenwoordigen exact dezelfde tekens in ASCII, ANSI en UTF-8.

Als u tekens nodig heeft buiten de ASCII-set, moet u een codering kiezen. Je zou ANSI kunnen gebruiken, maar dan kom je de problemen van alle verschillende codepaginas tegen.Maak een bestand op machine A en lees het op machine B kan / zal grappig uitziende teksten produceren als deze machines zijn ingesteld om verschillende codepaginas te gebruiken, eenvoudig omdat numerieke waarde nnn verschillende karakters in deze codepaginas vertegenwoordigt.

Deze “codepagina hell” is de reden waarom de Unicode-standaard werd gedefinieerd. UTF-8 is maar een enkele codering van die standaard, er zijn er nog veel meer. UTF-16 wordt het meest gebruikt omdat het de native codering voor Windows is.

Dus als je iets wilt ondersteunen dat verder gaat dan de 128 tekens van de ASCII-set, is mijn advies om te gaan met UTF-8 . Op die manier doet het er niet toe en hoeft u zich geen zorgen te maken met welke codepagina uw gebruikers hun systemen hebben ingesteld.

Opmerkingen

• als ik niet meer dan 128 tekens hoef te ondersteunen, wat is dan het voordeel van ACSII-codering boven UTF8-codering?
• Behalve jezelf beperken tot die 128 tekens? Niet veel. UTF-8 is specifiek ontworpen voor ASCII en de meeste westerse talen die ” alleen ” ANSI nodig hebben. U zult zien dat UTF-8 slechts een relatief klein aantal hogere ANSI-tekens codeert met meer dan één byte. Er is een reden waarom de meeste HTML-paginas UTF-8 als standaard gebruiken …
• @Pacerier, als je ‘ geen codering boven 127 nodig hebt, het kiezen van ASCII kan de moeite waard zijn als je een API gebruikt om te coderen / decoderen, omdat UTF extra bitverificatie nodig heeft om extra bytes als hetzelfde teken te beschouwen, het kan extra berekeningen vergen in plaats van pure ASCII die alleen 8 bits leest zonder verificatie. Maar ik raad je alleen aan om ASCII te gebruiken als je echt een hoog niveau van optimalisatie nodig hebt bij grote (grote grote) berekeningen en je weet wat je ‘ doet in die optimalisatie. Gebruik anders UTF-8.