Vad är fördelen med att välja ASCII-kodning framför UTF-8?

I vissa fall kan det påskynda åtkomsten till enskilda tecken. Föreställ dig sträng str="ABC" kodad i UTF8 och i ASCII (och förutsatt att språket / kompilatorn / databasen känner till kodning)

För att komma åt tredje (C) karaktär från den här strängen med array-access-operatör som finns i många programmeringsspråk skulle du göra något som c = str[2].

Nu , om strängen är ASCII-kodad, allt vi behöver göra är att hämta tredje byte från strängen.

Om huruvida strängen är UTF-8-kodad, måste vi först kontrollera om första tecknet är en eller två byte-tecken, sedan måste vi utföra samma kontroll på andra tecknet, och först då kan vi komma åt tredje karaktären. Skillnaden i prestanda blir ju större, desto längre strängen.

Detta är ett problem till exempel i vissa databasmotorer, där man hittar en början på en kolumn placerad ”efter” en UTF-8-kodad VARCHAR , behöver databasen inte bara kontrollera hur många tecken som finns i VARCHAR-fältet utan också hur många byte var och en använder.

Kommentarer

• Om databasen inte ’ t lagrar både ” teckenantal ” och ” byteantal ”, då säger jag ’ det ’ har några problem …
• TBH Jag känner ingen databas som skulle lagra antingen …
• @Mchl: hur föreställer du dig att databasen vet när den har nått slutet av strängen?
• Vanligtvis genom att nå 0x00 eller 0x0000
• @DeanHarding Hur berättar teckenräkningen var det andra tecknet börjar ? Eller ska databasen innehålla ett index för varje teckenförskjutning också? Obs! Det är inte ’ t bara två tecken, men kan vara upp till 4 (om inte ’ s 6) stackoverflow.com/questions/9533258/… . (Jag tror att det ’ är enda utf-16 som hade de riktigt långa styggelserna som kunde förstöra ditt system)

Om du bara använder US-ASCII (eller ISO 646) delmängd av UTF-8, så finns det ingen verklig fördel för den ena eller den andra; i själva verket är allt kodat identiskt.

Om du ska gå längre än US-ASCII-teckenuppsättningen och använda (till exempel) tecken med accenter, paraplyer etc. som används i typiska Västeuropeiska språk, då är det en skillnad – de flesta av dessa kan fortfarande kodas med en enda byte i ISO 8859, men kommer att kräva två eller flera byte när de kodas i UTF-8. Det finns naturligtvis också nackdelar: ISO 8859 kräver att du använder några medel utanför bandet för att specificera kodningen som används, och den stöder bara ett av dessa språk åt gången. Du kan till exempel koda alla karaktärer i kyrillerna (ryska, vitryska etc.)) alfabetet med endast en bitgrupp, men om du behöver / vill blanda dem med franska eller spanska tecken (andra än de i US-ASCII / ISO 646-delmängden) har du ganska lite tur – du måste helt ändra teckenuppsättningar för att göra det.

ISO 8859 är egentligen bara användbart för europeiska alfabet. För att stödja de flesta alfabet som används i de flesta kinesiska, japanska, koreanska, arabiska etc. alfabet måste du använda någon helt annan kodning. Några av dessa (t.ex. Shift JIS för japanska) är en absolut smärta att hantera. Om det finns någon chans att du någonsin vill stödja dem, skulle jag vilja betrakta det som värt att använda Unicode bara i fall.

ANSI kan vara många saker, de flesta är 8 bitars teckenuppsättningar i detta avseende (som kodsida 1252 under Windows).

Du kanske tänkte på ASCII som är 7-bitars och en ordentlig delmängd av UTF-8. Dvs valfri ASCII-ström är också en giltig UTF-8-ström.

Om du tänkte på 8-bitars teckenuppsättningar, skulle en mycket viktig fördel vara att alla representativa tecken är exakt 8-bitar, där i UTF -8 de kan vara upp till 24 bitar.

Kommentarer

• ja jag ’ jag talar om 7-bitars ASCII-uppsättningen. kan du tänka på en fördel som vi någonsin kommer att behöva spara något som ascii istället för utf-8? (eftersom 7-bitars ändå skulle sparas som 8-bitars skulle filstorleken vara exakt densamma)
• Om du har tecken som är större än unicode-värdet 127 kan de inte sparas i ASCII.
• @Pacerier: Alla ASCII-strängar är en UTF-8-sträng , så det finns ingen skillnad . Kodningsrutinen kanske är snabbare beroende på strängrepresentationen för plattformen du använder, även om jag inte ’ inte förväntar dig betydande hastighet, medan du har en betydande förlust i flexibilitet.
• @Thor det är just därför jag ’ jag frågar om att spara som ASCII har några fördelar alls
• @Pacerier, om du sparar XML som ASCII måste du använda t.ex. & # 160; för ett icke-brytbart utrymme. Detta är mer fyllning, men gör dina data mer motståndskraftiga mot ISO-Latin-1 vs UTF-8-kodningsfel. Det här är vad vi gör eftersom vår underliggande plattform gör mycket osynlig magi med karaktärer. Att stanna i ASCII gör våra data mer robusta.

Ja, det finns fortfarande vissa användningsfall där ASCII meningsfullt: filformat och nätverksprotokoll . I synnerhet för användning där:

• Du har data som genereras och konsumeras av datorprogram som aldrig presenteras för slutanvändare;
• Men som det är användbart för programmerare för att kunna läsa, för att underlätta utveckling och felsökning.

Genom att använda ASCII som din kodning undviker du komplexiteten i kodning av flera byte samtidigt som du behåller åtminstone viss läsbarhet för människor.

Ett par exempel:

• HTTP är ett nätverksprotokoll definierat i termer av oktetter, men det är mycket användbart (åtminstone för engelsktalande programmerare) att dessa motsvarar ASCII-kodningen av ord som ”GET”, ”POST”, ”Accept-Language” och så vidare.
• klumptyper i PNG-bildformat består av fyra oktetter, men det är praktiskt om du programmerar en PNG-kodare eller avkodare som IDAT betyder” bilddata ”och PLTE betyder” palett ”.

Naturligtvis måste du var försiktig så att uppgifterna verkligen inte kommer att presenteras för slutanvändarna, för om det blir synligt (som hände i fallet med webbadresser), kommer användarna med rätta att förvänta sig att data att vara på ett språk de kan läsa.

Kommentarer

• Bra sagt. Det ’ är lite ironiskt att HTTP, protokollet som överför den mest unicode på planeten bara behöver stödja ASCII. (Egentligen antar jag att samma sak gäller TCP och IP, binärt stöd, ASCII-stöd … att ’ är allt du behöver på den nivån i stacken)

Först och främst: din titel använder / d ANSI, medan du i texten hänvisar till ASCII. Observera att ANSI inte motsvarar ASCII. ANSI innehåller ASCII-uppsättningen. Men ASCII-uppsättningen är begränsad till de första 128 numeriska värdena (0 – 127).

Om all din data är begränsad till ASCII (7-bit), spelar det ingen roll om du använder UTF-8 , ANSI eller ASCII, eftersom både ANSI och UTF-8 försämrar hela ASCII-uppsättningen. Med andra ord: numeriska värden 0 till och med 127 representerar exakt samma tecken i ASCII, ANSI och UTF-8.

Om du behöver tecken utanför ASCII-uppsättningen måste du välja en kodning. Du kan använda ANSI, men då stöter du på problemen med alla de olika kodsidorna.Skapa en fil på maskin A och läs den på maskin B kan / kommer att producera roliga texter om dessa maskiner är inställda på att använda olika kodsidor, enkelt eftersom numeriskt värde nnn representerar olika tecken på dessa kodsidor.

Denna ”kodsida helvete” är anledningen till att Unicode-standard definierades. UTF-8 är bara en enda kodning av den standarden, det finns många fler. UTF-16 är den mest använda eftersom det är den inbyggda kodningen för Windows.

Så, om du behöver stödja något utöver de 128 tecken i ASCII-uppsättningen, är mitt råd att gå med UTF-8 . På det sättet spelar det ingen roll och du behöver inte oroa dig för vilken kodsida dina användare har ställt in sina system.

Kommentarer

• om jag inte behöver stödja mer än 128 tecken, vad är fördelen med att välja ACSII-kodning framför UTF8-kodning?
• Förutom att begränsa dig till dessa 128 tecken? Inte mycket. UTF-8 utformades speciellt för att tillgodose ASCII och de flesta västerländska språk som ” endast ” behöver ANSI. Du kommer att upptäcka att UTF-8 bara kommer att koda ett relativt litet antal högre ANSI-tecken med mer än en byte. Det finns en anledning till att de flesta HTML-sidor använder UTF-8 som standard …
• @Pacerier, om du inte behöver ’ t behöver kodas över 127, Att välja ASCII kan vara värt när du använder något API för att koda / avkoda, eftersom UTF behöver ytterligare bitverifiering för att betrakta ytterligare byte som samma tecken, det kan ta ytterligare beräkning snarare än ren ASCII som bara läser 8 bitar utan verifiering. Men jag rekommenderar dig bara att använda ASCII om du verkligen behöver en hög nivå av optimering i stora (stora stora) beräkningar och du vet vad du ’ gör i den optimeringen. Om inte, använd bara UTF-8.