Mi az előnye az ASCII kódolás választásának az UTF-8-mal szemben?

Bizonyos esetekben felgyorsíthatja az egyes karakterekhez való hozzáférést. Képzelje el az UTF8-ban és az ASCII-ben kódolt str="ABC" karakterláncot (és feltételezve, hogy a nyelv / fordító / adatbázis ismeri a kódolást)

A harmadik () karakter ebből a karaktersorozatból a tömb-hozzáférés operátor segítségével, amely sok programozási nyelven szerepel, például c = str[2].

Most , ha a karakterlánc ASCII kódolású, akkor csak annyit kell tennünk, hogy lekérjük a harmadik bájtot a stringből.

Ha a karaktersorozat UTF-8 kódolású, akkor először meg kell vizsgálnunk, hogy az első karakter egy vagy két bájtos karakter-e, akkor ugyanezt az ellenőrzést kell végrehajtanunk a második karakternél is, és csak ezután férhetünk hozzá a harmadik karakter. A teljesítménybeli különbség annál nagyobb, annál hosszabb a karaktersorozat.

Ez például néhány adatbázis-motor problémája, ahol az UTF-8 kódolású VARCHAR “után” elhelyezett oszlop elejét kell megtalálni. , az adatbázisnak nem csak azt kell ellenőriznie, hogy hány karakter van a VARCHAR mezőben, hanem azt is, hogy mindegyikük hány bájtot használ.

Megjegyzések

• Ha az adatbázis nem ‘ t tárolja mind a ” karakterek számát ” és a ” bájtok száma “, majd ‘ mondom ez ‘ problémákat okozott …
• TBH Nem ismerek olyan adatbázist sem, amely tárolná …
• @Mchl: hogyan képzeli, hogy az adatbázis tudja, mikor érte el a karakterlánc végét?
• Általában a 0x00 vagy a 0x0000 elérésével
• @DeanHarding Hogyan adja meg a karakterek száma, hogy hol kezdődik a második karakter? ? Vagy az adatbázisnak tartalmaznia kell indexet az egyes eltolt karakterekről is? Megjegyzés: Ez nem ‘ t csak 2 karakter, de legfeljebb 4 karakter lehet (kivéve, ha ‘ s 6) stackoverflow.com/questions/9533258/… . (Azt hiszem, hogy ‘ csak az utf-16-os, amelynek valóban hosszú utálatosságai voltak, amelyek tönkretehették a rendszerét)

Ha csak az UTF-8 US-ASCII (vagy ISO 646) részhalmazát fogja használni, akkor nincs valódi előnye egyik vagy másik számára; valójában minden egyformán van kódolva.

Ha túllép az USA-ASCII karakterkészleten, és (például) olyan karaktereket használ ékezetekkel, umlautokkal stb., amelyeket a tipikusan használnak nyugat-európai nyelvek, akkor különbség van – ezek többsége továbbra is egyetlen bájttal kódolható az ISO 8859 szabvány szerint, de két vagy több bájtra lesz szükségük, ha UTF-8-ba kódolják. Vannak természetesen hátrányai is: az ISO 8859 előírja, hogy a sávon kívüli eszközöket használjon a használt kódolás megadásához, és egyszerre csak ezeknek a nyelveknek egy jét támogatja. Például kódolhatja a cirill betű összes karakterét (orosz, belorusz stb.)) ábécé, darabonként csak egy bájtot használva, de ha francia / spanyol karakterekkel kell keverni őket (kivéve az USA-ASCII / ISO 646 alcsoportban szereplőeket), akkor nagyjából nincs szerencséd – teljesen meg kell változtassa meg a karakterkészleteket ehhez.

Az ISO 8859 valóban csak az európai ábécék esetében hasznos. A legtöbb kínai, japán, koreai, arab stb. ábécében használt ábécék nagy részének támogatásához használnia kell némelyik teljesen más kódolást. Néhány ilyen (pl. Shift JIS japánul) abszolút fájdalmat jelent. Ha van esély arra, hogy valaha is támogatni szeretné őket, érdemesnek tartanám az Unicode használatát eset.

Az ANSI sokféle lehet, ebből a szempontból a legtöbb 8 bites karakterkészlet (például az 1252. kódlap alatt Windows).

Talán az ASCII-re gondolt, amely 7 bites és az UTF-8 megfelelő részhalmaza. Azaz. bármely érvényes ASCII adatfolyam is érvényes UTF-8 adatfolyam.

Ha 8 bites karakterkészletekre gondoltál, akkor egy nagyon fontos előny az lenne, hogy az összes ábrázolható karakter pontosan 8 bites lenne, ahol az UTF-ben -8 legfeljebb 24 bit lehet.

Megjegyzések

• igen i ‘ beszélek a 7 bites ASCII készlet. tudsz 1 előnyt gondolni, amire valaha szükségünk lesz valamire ascii formában menteni az utf-8 helyett? (mivel a 7-bites egyébként 8-bites lenne, így a fájlméret pontosan megegyezik)
• Ha a 127-es unicode-nál nagyobb karakterek vannak, akkor nem menthetők el az ASCII-ben.
• @Pacerier: Bármely ASCII karakterlánc UTF-8 karakterlánc , tehát nincs különbség . A kódolási rutin gyorsabb lehet, a használt platform karakterlánc-ábrázolásától függően, bár nem várnám, hogy ‘ számottevő gyorsulást várnék, míg Önnek jelentős vesztesége van rugalmasságban.
• @Thor pontosan ezért kérdezem ‘ azt, hogy van-e egyáltalán előnye az ASCII-ként történő mentésnek
• @Pacerier, Ha XML-t ASCII-ként ment el, akkor pl & # 160; egy nem törhető tér számára. Ez teltebb, de ellenállóbbá teszi az adatait az ISO-Latin-1 és az UTF-8 kódolási hibákkal szemben. Ezt tesszük, mivel a mögöttes platformunk sok láthatatlan mágiát varázsol a karakterekkel. Az ASCII-ben maradva robusztusabbá tehetjük adatainkat.

Igen, még mindig vannak olyan esetek, amikor az ASCII van értelme: fájlformátumok és hálózati protokollok . Különösen azokra a felhasználásokra, ahol:

• Rendelkezik olyan adatokkal, amelyeket számítógépes programok generálnak és fogyasztanak, amelyeket soha nem mutattak be a végfelhasználóknak;
• de amelyekre hasznos programozóknak, hogy képesek legyenek olvasni, a fejlesztés és a hibakeresés megkönnyítése érdekében.

Az ASCII használatával kódolásként elkerüli a többbájtos kódolás bonyolultságát, miközben megtartja legalább az emberek olvashatóságát.

Néhány példa:

• HTTP az oktettek sorozatában meghatározott hálózati protokoll, de nagyon hasznos (legalábbis az angolul beszélő programozók számára), hogy ezek megfelelnek az olyan szavak ASCII kódolásának, mint a “GET”, “POST”, “Accept-Language” és így tovább.
• A A darabtípusok a PNG képformátumban négy oktettből állnak, de hasznos, ha olyan PNG kódolót vagy dekódert programoz, amely jelentése” képadatok “, a PLTE jelentése” paletta “.

Természetesen meg kell vigyázzon, hogy az adatokat valóban ne “mutassák be a végfelhasználóknak, mert ha végül láthatóak lesznek (mint az URL-ek esetében történt), akkor a felhasználók joggal várják el ezeket az adatokat hogy az általuk olvasható nyelven legyenek.

Megjegyzések

• Jól mondták. ‘ kissé ironikus, hogy a HTTP-nek, a bolygón a legtöbb unicode-ot továbbító protokollnak csak az ASCII-t kell támogatnia. (Tulajdonképpen feltételezem, hogy ugyanez vonatkozik a TCP-re és az IP-re, a bináris támogatásra, az ASCII-támogatásra … hogy ‘ mindenre szükséged van a verem azon szintjén)

Először is: a címed a / d ANSI-t használja, míg a szövegben az ASCII-re hivatkozol. Felhívjuk figyelmét, hogy az ANSI nem egyenlő az ASCII-vel. Az ANSI magában foglalja az ASCII készletet. De az ASCII készlet az első 128 numerikus értékre korlátozódik (0 – 127).

Ha az összes adat csak az ASCII (7 bites) fájlra korlátozódik, akkor nem számít, hogy UTF-8-at használ-e. , ANSI vagy ASCII, mivel az ANSI és az UTF-8 is beépíti a teljes ASCII készletet. Más szavakkal: a 0-tól 127-ig terjedő numerikus értékek pontosan ugyanazokat a karaktereket képviselik az ASCII, ANSI és UTF-8-ban.

Ha az ASCII készleten kívüli karakterekre van szüksége, akkor kódolást kell választania. Használhatná az ANSI-t, de akkor az összes különböző kódoldal problémáiba ütközik.Hozzon létre egy fájlt az A gépen, és olvassa el a B gépen vicces megjelenésű szövegeket hozhat létre / hoz létre, ha ezek a gépek különböző kódlapok használatára vannak beállítva, egyszerűen azért, mert az nnn numerikus érték különbözõ karaktereket képvisel ezeken a kódlapokon.

Ez a “kódoldali pokol” az oka annak, hogy a Unicode szabványt definiálták. Az UTF-8 csak egy szabványos kódolás, ennél sokkal több van. Az UTF-16 a legelterjedtebb, mivel ez a Windows natív kódolása.

Tehát, ha az ASCII készlet 128 karakterén túl bármit támogatnia kell, azt tanácsolom, hogy UTF-8 . Így nincs jelentősége, és nem kell aggódnia, hogy a felhasználók melyik kódlappal állították be rendszereiket.

Megjegyzések

• ha nem kell 128 karakternél többet támogatnom, mi az előnye, ha az ACSII kódolást választom az UTF8 kódolás helyett?
• Amellett, hogy csak arra a 128 karakterre korlátozod magad? Nem sok. Az UTF-8 kifejezetten az ASCII és a legtöbb nyugati nyelv kielégítésére készült, amelyek ” csak ” ANSI-t igényelnek. Megállapítja, hogy az UTF-8 csak viszonylag kis számban kódolja a magasabb ANSI karaktereket, több bájttal. Ennek oka van, hogy a legtöbb HTML-oldal az UTF-8-at használja alapértelmezettként …
• @Pacerier, ha nem kell ‘ 127-nél magasabb kódolás, Az ASCII kiválasztása érdemes lehet, ha valamilyen API-t használ a kódoláshoz / dekódoláshoz, mivel az UTF-nek további bitellenőrzésre van szüksége ahhoz, hogy a további bájtokat ugyanazon karakterként tekintse meg, ez további számítást igényel, nem pedig tiszta ASCII-t, amely csak 8 bitet olvas le ellenőrzés nélkül. De csak akkor ajánlom, hogy használja az ASCII-t, ha valóban magas szintű (nagy nagy) számításokra van szüksége magas szintű optimalizálásra, és tudja, mit csinál ‘ ebben az optimalizálásban. Ha nem, csak használja az UTF-8-at.