Care este avantajul alegerii codificării ASCII peste UTF-8?

În unele cazuri, poate accelera accesul la caractere individuale. Imaginați-vă șirul str="ABC" codificat în UTF8 și în ASCII (și presupunând că limba / compilatorul / baza de date știe despre codificare)

Pentru a accesa al treilea (C) caracter din acest șir folosind un operator de acces la matrice care este prezentat în multe limbaje de programare, ați face ceva de genul c = str[2].

Acum , dacă șirul este codat ASCII, tot ce trebuie să facem este să preluăm al treilea octet din șir.

Dacă, cu toate acestea șirul este codificat UTF-8, trebuie mai întâi să verificăm dacă primul caracter este un caracter de unu sau doi octeți, atunci trebuie să efectuăm aceeași verificare a celui de-al doilea caracter și numai atunci putem accesa al treilea personaj. Diferența de performanță va fi cu atât mai mare, cu cât șirul va fi mai lung.

Aceasta este o problemă, de exemplu, în unele motoare de baze de date, unde se găsește un început al unei coloane plasate „după” un VARCHAR codificat UTF-8 , baza de date nu trebuie doar să verifice câte caractere există în câmpul VARCHAR, ci și câte octeți folosește fiecare dintre ele.

Comentarii

• Dacă baza de date nu ‘ nu stochează atât ” numărul de caractere ” și ” număr de octeți „, apoi ‘ spun ‘ are unele probleme …
• TBH Nu știu nici o bază de date care să stocheze …
• @Mchl: cum îți imaginezi că baza de date știe când a ajuns la sfârșitul șirului?
• De obicei, ajungând la 0x00 sau 0x0000
• @DeanHarding Cum îți spune numărul de caractere de unde începe al doilea personaj? ? Sau ar trebui ca baza de date să dețină și un index pentru fiecare caracter compensat? Notă: nu este ‘ doar 2 caractere, dar poate avea până la 4 (cu excepția cazului când ‘ s 6) stackoverflow.com/questions/9533258/… . (Cred că este ‘ singurul utf-16 care a avut abominări foarte lungi care ar putea distruge sistemul dvs.)

Dacă veți folosi numai subsetul US-ASCII (sau ISO 646) al UTF-8, atunci nu există niciun avantaj real pentru unul sau pentru celălalt; de fapt, totul este codat în mod identic.

Dacă vei merge dincolo de setul de caractere US-ASCII și vei folosi (de exemplu) caractere cu accente, umlauturi etc., care sunt folosite în tipic limbile vest-europene, atunci există o diferență – majoritatea acestora pot fi încă codificate cu un singur octet în ISO 8859, dar vor necesita doi sau mai mulți octeți atunci când sunt codate în UTF-8. Există, desigur, dezavantaje: ISO 8859 necesită utilizarea unor mijloace în afara benzii pentru a specifica codificarea utilizată și acceptă doar una dintre aceste limbi la un moment dat. De exemplu, puteți codifica toate caracterele chirilice (rusă, bielorusă etc.) alfabet folosind doar un octet fiecare, dar dacă aveți nevoie / doriți să le amestecați cu caractere franceză sau spaniolă (altele decât cele din subsetul US-ASCII / ISO 646), sunteți destul de mult din noroc – trebuie să completați schimbați seturile de caractere pentru a face acest lucru.

ISO 8859 este cu adevărat utilă numai pentru alfabetele europene. Pentru a accepta majoritatea alfabetelor utilizate în majoritatea alfabetelor chinezești, japoneze, coreene, arabe etc., trebuie să utilizați unele codificări complet diferite. Unele dintre acestea (de exemplu, Shift JIS pentru japoneză) sunt o durere absolută de rezolvat. Dacă există vreo șansă să vreți vreodată să le sprijiniți, aș considera că merită să utilizați Unicode doar în caz.

ANSI poate fi o mulțime de lucruri, majoritatea fiind seturi de caractere de 8 biți în acest sens (cum ar fi pagina de cod 1252 din Windows).

Poate că te gândeai la ASCII, care este pe 7 biți și un subset adecvat de UTF-8. Adică orice flux ASCII valid este, de asemenea, un flux UTF-8 valid.

Dacă te-ai gândi la seturi de caractere pe 8 biți, un avantaj foarte important ar fi că toate caracterele reprezentabile sunt exact pe 8 biți, unde în UTF -8 pot avea până la 24 de biți.

Comentarii

• da despre care ‘ vorbesc setul ASCII pe 7 biți. vă puteți gândi la un avantaj de care va trebui vreodată să salvăm ceva ca ascii în loc de utf-8? (întrucât 7-bit ar fi salvat ca 8-bit oricum, dimensiunea fișierului ar fi exact aceeași)
• Dacă aveți caractere mai mari decât valoarea unicode 127, acestea nu pot fi salvate în ASCII.
• @Pacerier: Orice șir ASCII este un șir UTF-8 , deci nu există nicio diferență . Rutina de codificare s-ar putea fi mai rapidă în funcție de reprezentarea șirului de pe platforma pe care o utilizați, deși nu m-aș aștepta la ‘ nu mă aștept la o accelerare semnificativă, în timp ce aveți o pierdere semnificativă în flexibilitate.
• @Thor tocmai de aceea „c7158ce818”>

Da, există încă câteva cazuri de utilizare în care ASCII are sens: formate de fișiere și protocoale de rețea . În special, pentru utilizări în care:

• Aveți date care sunt generate și consumate de programe de computer, care nu au fost prezentate niciodată utilizatorilor finali;
• Dar pentru care este utilă programatorii să poată citi, pentru ușurință în dezvoltare și depanare.

Prin utilizarea ASCII ca codificare, evitați complexitatea codificării pe mai mulți octeți, păstrând în același timp o anumită lizibilitate umană.

Câteva exemple:

• HTTP este un protocol de rețea definit în termeni de secvențe de octeți, dar este foarte util (cel puțin pentru programatorii care vorbesc limba engleză) că acestea corespund codificării ASCII a cuvintelor precum „GET”, „POST”, „Accept-Language” și așa mai departe.
• tipurile de bucăți în formatul de imagine PNG constau din patru octeți, dar este la îndemână dacă programați un codificator PNG sau un decodor care IDAT înseamnă” date de imagine „și PLTE înseamnă” paletă „.

Desigur, trebuie să aveți grijă ca datele să nu fie prezentate cu adevărat utilizatorilor finali, deoarece dacă acestea ajung să fie vizibile (așa cum sa întâmplat în cazul adreselor URL), atunci utilizatorii se așteaptă pe bună dreptate ca aceste date să fie într-o limbă pe care o pot citi.

Comentarii

• Bine spus. Este ‘ puțin ironic că HTTP, protocolul care transmite cel mai mult unicode de pe planetă, are nevoie doar de suport pentru ASCII. (De fapt, presupun că același lucru este valabil și pentru TCP și IP, suport binar, suport ASCII … că ‘ este tot ce aveți nevoie la acel nivel al stivei)

În primul rând: titlul dvs. folosește / d ANSI, în timp ce în text faceți referire la ASCII. Vă rugăm să rețineți că ANSI nu este egal cu ASCII. ANSI încorporează setul ASCII. Dar setul ASCII este limitat la primele 128 de valori numerice (0 – 127).

Dacă toate datele dvs. sunt restricționate la ASCII (7 biți), nu contează dacă utilizați UTF-8 , ANSI sau ASCII, deoarece atât ANSI, cât și UTF-8 încorporează întregul set ASCII. Cu alte cuvinte: valorile numerice de la 0 până la 127 inclusiv reprezintă exact aceleași caractere în ASCII, ANSI și UTF-8.

Dacă aveți nevoie de caractere în afara setului ASCII, va trebui să alegeți o codificare. Ați putea folosi ANSI, dar apoi vă confruntați cu problemele tuturor diferitelor pagini de cod.Creați un fișier pe mașina A și citiți-l pe mașina B poate / va produce texte amuzante dacă aceste mașini sunt configurate pentru a utiliza pagini de cod diferite, simplu deoarece valoarea numerică nnn reprezintă caractere diferite în aceste pagini de cod.

Acest „iad de pagină de cod” este motivul pentru care a fost definit standard Unicode . UTF-8 este doar o singură codificare a acelui standard, există multe altele. UTF-16 fiind cel mai utilizat pe măsură ce este codificarea nativă pentru Windows.

Deci, dacă trebuie să acceptați ceva dincolo de cele 128 de caractere ale setului ASCII, sfatul meu este să mergeți cu UTF-8 . În acest fel nu contează și nu trebuie să vă faceți griji cu ce pagină de cod și-au configurat utilizatorii.

Comentarii

• dacă nu trebuie să accept mai mult de 128 de caractere, care este avantajul alegerii codificării ACSII în locul codificării UTF8?
• În afară de a te limita la cele 128 de caractere? Nu prea mult. UTF-8 a fost conceput special pentru a satisface ASCII și majoritatea limbilor occidentale care ” numai ” au nevoie de ANSI. Veți descoperi că UTF-8 va codifica doar un număr relativ mic din caracterele ANSI superioare cu mai mult de un octet. Există un motiv pentru care majoritatea paginilor HTML folosesc UTF-8 ca implicit …
• @Pacerier, dacă nu aveți nevoie de ‘ de codificare peste 127, alegerea ASCII poate fi utilă atunci când utilizați unele API-uri pentru a codifica / decoda, deoarece UTF are nevoie de verificare de biți suplimentari pentru a lua în considerare octeți suplimentari ca același caracter, poate fi nevoie de un calcul suplimentar, mai degrabă decât ASCII pur, care tocmai citește 8 biți fără verificare. Dar îți recomand să folosești ASCII numai dacă ai nevoie într-adevăr de un nivel ridicat de optimizare în calculele mari (mari mari) și știi ce faci ‘ în această optimizare. Dacă nu, utilizați doar UTF-8.