Mikä etu on valita ASCII-koodaus UTF-8: n kanssa?

Joissakin tapauksissa se voi nopeuttaa yksittäisten merkkien käyttöä. Kuvittele merkkijono str="ABC", joka on koodattu UTF8: een ja ASCII: een (ja olettaen, että kieli / kääntäjä / tietokanta tietää koodauksesta)

Kolmannen () -merkki tästä merkkijonosta käyttämällä matriisipääsyoperaattoria, joka on esillä monilla ohjelmointikielillä, tekisit jotain c = str[2].

Nyt , jos merkkijono on ASCII-koodattu, meidän on vain haettava kolmas tavu merkkijonosta.

Jos merkkijono on UTF-8-koodattu, meidän on ensin tarkistettava, onko ensimmäinen merkki yhden tai kahden tavun merkki, sitten meidän on suoritettava sama tarkistus toiselle merkille, ja vasta sitten voimme käyttää kolmas merkki. Suorituskykyero on sitä suurempi, mitä pidempi merkkijono on.

Tämä on ongelma esimerkiksi joissakin tietokantamoottoreissa, joista löytyy UTF-8-koodatun VARCHARin ”jälkeen” sijoitetun sarakkeen alku. , tietokannan ei tarvitse vain tarkistaa, kuinka monta merkkiä VARCHAR-kentässä on, vaan myös kuinka monta tavua kukin niistä käyttää.

Kommentit

• Jos tietokanta ei ’ t tallenna molempia ” -merkkilukuja ” ja ” tavujen määrä ”, sitten sanon ’ sanon se ’ s sai joitain ongelmia …
• TBH En tiedä tietokantaa, joka myöskään tallentaisi …
• @Mchl: miten luuletko tietokannan tietävän, milloin se on saapunut merkkijonon loppuun?
• Tavallisesti saavuttamalla 0x00 tai 0x0000
• @DeanHarding Kuinka merkkimäärä kertoo, mistä toinen merkki alkaa ? Vai pitäisikö tietokannassa pitää olla hakemisto myös jokaiselle offset-merkille? Huomaa: Se ei ole ’ t vain 2 merkkiä, mutta voi olla jopa 4 merkkiä (paitsi jos se ’ s 6) stackoverflow.com/questions/9533258/… . (Luulen, että se on ’ ainoa utf-16, jolla oli todella pitkät kauhistukset, jotka voisivat tuhota järjestelmän)

Jos aiot käyttää vain UTF-8: n US-ASCII (tai ISO 646) -joukkoa, ei ole todellista etua yhdelle tai toiselle; itse asiassa kaikki on koodattu identtisesti.

Jos aiot ylittää USA-ASCII-merkistöjen ja käytät (esimerkiksi) merkkejä korostuksilla, umlauteilla jne., joita käytetään tyypillisesti Länsi-Euroopan kielillä on ero – suurin osa näistä voidaan silti koodata yhdellä tavulla ISO 8859: ssä, mutta ne edellyttävät vähintään kahta tavua, kun ne koodataan UTF-8: een. On tietysti myös haittoja: ISO 8859 edellyttää, että käytät joitain kaistan ulkopuolisia keinoja määritellä käytettävä koodaus, ja se tukee vain yhtä näistä kielistä kerrallaan. Voit esimerkiksi koodata kaikki kirillisen merkit (venäjä, valkovenäjä jne.)) aakkoset, joissa on vain yksi tavu kappaleelta, mutta jos haluat / haluat sekoittaa ranskalaisia tai espanjalaisia merkkejä sisältäviä merkintöjä (muut kuin US-ASCII / ISO 646 -alaryhmässä olevat merkit), sinulla on melkein epäonnea – sinun on täysin muuta merkkijoukkoja tehdäksesi niin.

ISO 8859 on oikeastaan hyödyllinen vain eurooppalaisille aakkosille. Jos haluat tukea suurinta osaa aakkosista, joita käytetään useimmissa kiinalaisissa, japanilaisissa, korealaisissa, arabialaisissa jne. aakkosissa, sinun on käytettävä jotkut täysin erilaiset koodaukset. Jotkut näistä (esim. Shift JIS japanilaisille) ovat ehdoton tuska käsitellä. Jos sinulla on mahdollisuuksia koskaan tukea niitä, pidän kannattavana käyttää Unicodea vain tapaus.

ANSI voi olla monia asioita, useimmat ovat tältä osin 8-bittisiä merkistöjä (kuten koodisivu 1252 kohdassa Windows).

Ehkä ajattelit ASCII: ta, joka on 7-bittinen ja oikea UTF-8: n alajoukko. Eli. mikä tahansa kelvollinen ASCII-virta on myös kelvollinen UTF-8-virta.

Jos ajattelit 8-bittisiä merkistöjä, yksi erittäin tärkeä etu olisi, että kaikki edustettavat merkit ovat tarkalleen 8-bittisiä, missä UTF: ssä -8 ne voivat olla enintään 24 bittiä.

Kommentit

• kyllä minä ’ m puhun 7-bittinen ASCII-sarja. voitko miettiä yhtä etua, joka meidän on koskaan tallennettava jotain ascii-muodossa utf-8: n sijaan? (Koska 7-bittinen tallennettaisiin joka tapauksessa 8-bittisenä, tiedostokoko olisi täsmälleen sama)
• Jos sinulla on merkkejä, jotka ovat suurempia kuin unicode-arvo 127, niitä ei voi tallentaa ASCII-tiedostoon.
• @Pacerier: Mikä tahansa ASCII-merkkijono on UTF-8-merkkijono , joten siinä ei ole eroa . Koodausrutiini saattaa olla nopeampi riippuen käyttämäsi alustan merkkijonosta, vaikka en odota ’ odottavan merkittävää nopeutumista, kun taas sinulla on merkittävä menetys joustavuudessa.
• @Thor juuri tämän vuoksi ’ kysyn, onko ASCII-tallennuksella mitään hyötyä
• @Pacerier, Jos tallennat XML: n ASCII-muodossa, sinun on käytettävä esim & # 160; murtumattomalle tilalle. Tämä on täyteläisempi, mutta tekee tietostasi kestävämmät ISO-Latin-1 vs UTF-8 -koodausvirheitä vastaan. Tätä teemme, kun taustalla oleva alusta tekee paljon näkymätöntä taikuutta hahmojen kanssa. ASCII: ssa pysyminen tekee tietostamme vakaamman.

Kyllä, on vielä joitain käyttötapauksia, joissa ASCII järkevää: tiedostomuodot ja verkkoprotokollat . Erityisesti käyttötarkoituksiin, joissa:

• Sinulla on tietoja, jotka tietokoneohjelmat tuottavat ja kuluttavat, ei koskaan esitetä loppukäyttäjille;
• mutta mistä se on hyödyllistä ohjelmoijat voivat lukea, kehityksen ja virheenkorjauksen helpottamiseksi.

Käyttämällä ASCII: ta koodauksena vältät monitavuisen koodauksen monimutkaisuuden ja säilytät ainakin osan ihmisten luettavuudesta.

Pari esimerkkiä:

• HTTP on verkkoprotokolla, joka on määritelty oktettisekvensseinä, mutta on erittäin hyödyllistä (ainakin englanninkielisille ohjelmoijille), että nämä vastaavat ASCII-koodausta sanoista kuten ”GET”, ”POST”, ”Hyväksy kieli” ja niin edelleen.
• kappaletyypit PNG-kuvamuodossa koostuvat neljästä oktetista, mutta se on kätevä, jos ohjelmoit uudelleen PNG-kooderin tai -dekooderin, joka IDAT tarkoittaa” kuvatietoa ”ja PLTE tarkoittaa” palettia ”.

Tietysti sinun on ole varovainen, että tietoja todella ei ”esitetä loppukäyttäjille, koska jos ne päätyvät näkyviin (kuten URL-osoitteiden tapauksessa tapahtui), käyttäjät odottavat oikeutetusti kyseisiä tietoja olla kielellä, jota he voivat lukea.

Kommentit

• Hyvin sanottu. ’ on hieman ironista, että HTTP: n, protokollan, joka välittää planeetan eniten unicodea, tarvitsee vain tukea ASCII: ta. (Itse asiassa oletan, että sama koskee TCP: tä ja IP: tä, binaaritukea, ASCII-tukea … että ’ on kaikki mitä tarvitset tällä pinon tasolla)

Ensinnäkin: otsikossa käytetään / d ANSI: ta, kun taas tekstissä viitataan ASCII: een. Huomaa, että ANSI ei ole sama kuin ASCII. ANSI sisältää ASCII-sarjan. Mutta ASCII-sarja on rajoitettu ensimmäisiin 128 numeeriseen arvoon (0 – 127).

Jos kaikki tietosi on rajoitettu ASCII: een (7-bittinen), sillä ei ole väliä, käytätkö UTF-8: ta , ANSI tai ASCII, koska sekä ANSI että UTF-8 sisällyttävät koko ASCII-sarjan. Toisin sanoen: numeeriset arvot 0 – 127 mukaan lukien edustavat täsmälleen samoja merkkejä ASCII: ssa, ANSI: ssa ja UTF-8: ssa.

Jos tarvitset merkkejä ASCII-joukon ulkopuolella, sinun on valittava koodaus. Voisit käyttää ANSI: ta, mutta sitten törmäät kaikkien eri koodisivujen ongelmiin.Luo tiedosto koneelle A ja lue se koneelta B voi / voi tuottaa hauskoja tekstiä, jos nämä koneet on asetettu käyttämään eri koodisivuja, yksinkertaista, koska lukuarvo nnn edustaa eri merkkejä näillä koodisivuilla.

Tämä ”koodisivuhelvetti” on syy, miksi Unicode-standardi määritettiin. UTF-8 on vain yksi standardin koodaus, niitä on paljon enemmän. UTF-16 on yleisimmin käytetty, koska se on Windowsin natiivikoodaus.

Joten jos sinun on tuettava jotain muuta kuin ASCII-sarjan 128 merkkiä, neuvoni on mennä kohtaan UTF-8 . Tällä tavalla sillä ei ole merkitystä ja sinun ei tarvitse huolehtia siitä, millä koodisivulla käyttäjät ovat asettaneet järjestelmänsä.

Kommentit

• jos minun ei tarvitse tukea yli 128 merkkiä, mikä on etu valita ACSII-koodaus UTF8-koodauksen sijaan?
• Sen lisäksi, että rajoitut vain näihin 128-merkkiin? Ei paljon. UTF-8 on suunniteltu vastaamaan ASCII-kieliä ja useimpia länsimaisia kieliä, jotka ” vain ” tarvitsevat ANSI: ta. Tulet huomaamaan, että UTF-8 koodaa vain suhteellisen pienen määrän korkeampia ANSI-merkkejä, joissa on enemmän kuin yksi tavu. On syystä, että suurin osa HTML-sivuista käyttää UTF-8: ta oletuksena …
• @Pacerier, jos et ’ tarvitse koodausta yli 127, ASCII: n valitseminen voi olla kannattavaa, kun käytät jonkin API: n koodaamiseen / dekoodaamiseen, koska UTF tarvitsee lisää bittitarkistusta, jotta lisävatavut voidaan pitää samana merkkinä, se voi viedä lisälaskennan eikä puhdasta ASCII: ta, joka vain luki 8 bittiä ilman vahvistusta. Mutta suosittelen sinua käyttämään ASCII: ta vain, jos tarvitset todella paljon optimointia suuressa (isossa suuressa) laskennassa ja tiedät mitä ’ teet optimoinnissa. Jos ei, käytä vain UTF-8: ta.