Všechny znaky v ASCII lze kódovat pomocí UTF-8 bez navýšení úložiště (oba vyžadují bajt úložiště).
UTF-8 má další výhodu podpory znaků nad rámec „ASCII znaků“. Pokud tomu tak je, proč někdy zvolíme kódování ASCII přes UTF-8?
Existuje případ použití, když místo UTF-8 zvolíme ASCII?
Komentáře
- Na podporu starších věcí …
- Myslím tím, že UTF8 je legacy také podpora ASCII. takže i když musíte podporovat starší věci, UTF8 by fungoval dobře, žádné další změny nejsou potřeba.
- Možná jste ‚ spolupracovali s systém, který obsahuje 8 znaků ASCII do 7 bajtů? Lidé dělali bláznivé věci, aby se do nich vešly.
- Říkejte mi blázen, ale já ‚ říkají bezpečnost a stabilita. Znaková sada bez vícebajtových sekvencí je mnohem těžší prolomit. Nedělej mě špatně, když je důležitá podpora lidského jazyka ASCII vyhraje ‚ t cut it. Ale pokud ‚ děláte jen základní programování a můžete se vrhnout do rodného jazyka, kompilátor a operatin g systém byl napsán pro, proč přidat složitost? @Donal Fellows. Naposledy jsem zkontroloval … ASCII je 7 bajtů. (cokoli s tímto bitem navíc prostě není ‚ t ASCII a žádá o potíže)
- @ebyrob Myslím, že Donal Fellows znamená bitové balení 8 ascii symbolů do 7 bytů , protože každý symbol používá každý 7 bitů … 8 * 7 = 56 bitů = 7 bytů. Znamenalo by to speciální funkci kódování a dekódování, jen ušetřit 1 bajt úložiště z každých 8.
Odpovědět
V některých případech může zrychlit přístup k jednotlivým znakům. Představte si řetězec str="ABC"
kódovaný v UTF8 a v ASCII (a za předpokladu, že jazyk / překladač / databáze ví o kódování)
Přístup k třetímu (C
) znak z tohoto řetězce pomocí operátoru přístupu k poli, který je uveden v mnoha programovacích jazycích, uděláte něco jako c = str[2]
.
Nyní , pokud je řetězec kódován ASCII, vše, co musíme udělat, je načíst třetí bajt z řetězce.
Pokud je však řetězec zakódován v UTF-8, musíme nejprve zkontrolovat, zda je první znak jedno nebo dvoubajtový znak, pak musíme provést stejnou kontrolu druhého znaku a teprve poté můžeme přistupovat k třetí znak. Rozdíl ve výkonu bude tím větší, čím delší bude řetězec.
Toto je problém například v některých databázových strojích, kde najdete začátek sloupce umístěného „za“ kódem VTARCHAR kódovaným UTF-8. , databáze nejen potřebuje zkontrolovat, kolik znaků je v poli VARCHAR, ale také kolik bajtů každý z nich používá.
Komentáře
- Pokud databáze ‚ t neukládá “ počet znaků “ a “ počet bajtů „, pak řeknu ‚ d to ‚ s má nějaké problémy …
- TBH Neznám žádnou databázi, která by ukládala buď …
- @Mchl: jak Dokážete si představit, že databáze ví, kdy dosáhla konce řetězce?
- Obvykle dosažením 0x00 nebo 0x0000
- @DeanHarding Jak vám počet znaků řekne, kde začíná druhý znak ? Nebo by měla databáze obsahovat také index pro každý znakový offset? Poznámka: Není to ‚ pouze 2 znaky, ale může to být až 4 (pokud to není ‚ s 6) stackoverflow.com/questions/9533258/… . (Myslím, že je to ‚ pouze utf-16, který měl opravdu dlouhé ohavnosti, které by mohly zničit váš systém)
Odpověď
Pokud budete používat pouze podmnožinu UTF-8 US-ASCII (nebo ISO 646), nebude mít jedna nebo druhá skutečná výhoda; ve skutečnosti je vše kódováno shodně.
Pokud se chystáte jít nad rámec znakové sady US-ASCII a použít (například) znaky s diakritikou, přehláskami atd., které se používají v typických západoevropské jazyky, pak je tu rozdíl – většina z nich může být stále kódována jedním bajtem v ISO 8859, ale při kódování v UTF-8 bude vyžadovat dva nebo více bajtů. Existují samozřejmě také nevýhody: ISO 8859 vyžaduje, abyste k určení použitého kódování použili nějaké mimopásmové prostředky a podporuje pouze jeden z těchto jazyků najednou. Můžete například zakódovat všechny znaky cyrilice (ruština, běloruská atd.)) abeceda používající pouze jeden bajt za kus, ale pokud je potřebujete / chcete kombinovat s francouzskými nebo španělskými znaky (kromě těch, které jsou v podmnožině US-ASCII / ISO 646), máte hodně štěstí – musíte úplně za tímto účelem změňte znakové sady.
ISO 8859 je opravdu užitečné pouze pro evropské abecedy. Chcete-li podporovat většinu abeced používaných ve většině čínských, japonských, korejských, arabských atd. abeced, musíte použít některá úplně jiná kódování. Některá z nich (např. Shift JIS pro japonštinu) jsou absolutní námahou. Pokud existuje nějaká šance, že je budete někdy chtít podporovat, považuji za užitečné použít Unicode jen v case.
Odpověď
ANSI může být mnoho věcí, přičemž v tomto ohledu jde většinou o 8bitové znakové sady (například kódová stránka 1252 pod Windows).
Možná jste mysleli na ASCII, které je 7bitové a vlastní podmnožinou UTF-8. Tj. jakýkoli platný proud ASCII je také platným proudem UTF-8.
Pokud jste uvažovali o 8bitových znakových sadách, jednou velmi důležitou výhodou by bylo, že všechny reprezentovatelné znaky jsou přesně 8bitové, kde v UTF -8 mohou mít až 24 bitů.
Komentáře
- ano i ‚ mluvím o 7bitová sada ASCII. Napadá vás 1 výhoda, kterou budeme někdy muset uložit jako ascii místo utf-8? (protože 7bitový by se stejně uložil jako 8bitový, velikost souboru by byla úplně stejná)
- Pokud máte znaky větší než hodnota unicode 127, nelze je uložit v ASCII.
- @Pacerier: Libovolný řetězec ASCII je řetězec UTF-8 , takže není žádný rozdíl . Rutina kódování může být rychlejší v závislosti na řetězcové reprezentaci platformy, kterou používáte, i když bych neočekával ‚ výrazné zrychlení, zatímco máte značnou ztrátu ve flexibilitě.
- @Thor právě proto se ‚ ptám, zda má ukládání jako ASCII vůbec nějaké výhody
- @Pacerier, pokud ukládáte XML jako ASCII, musíte použít např & # 160; pro nerozbitný prostor. To je více vyplňující, ale vaše data jsou odolnější proti chybám kódování ISO-Latin-1 vs UTF-8. To je to, co děláme, protože naše základní platforma dělá s postavami spoustu neviditelného kouzla. Díky pobytu v ASCII jsou naše data robustnější.
Odpověď
Ano, stále existují případy použití, kdy ASCII dává smysl: formáty souborů a síťové protokoly . Zejména pro použití, kde:
- Máte data, která jsou generována a spotřebována počítačovými programy, nikdy se nepředávají koncovým uživatelům;
- Ale pro která jsou užitečná programátoři budou schopni číst, což usnadní vývoj a odladění.
Použitím ASCII jako kódování se vyhnete složitosti vícebajtového kódování při zachování alespoň určité čitelnosti pro člověka.
Několik příkladů:
- HTTP je síťový protokol definovaný v posloupnosti oktetů, ale je velmi užitečné (alespoň pro anglicky mluvící programátory), že odpovídají kódování ASCII slov jako „GET“, „POST“, „Accept-Language“ atd.
- The typy bloků ve formátu obrázku PNG se skládají ze čtyř oktetů, ale je užitečné, když programujete kodér nebo dekodér PNG, který znamená„ obrazová data “a
PLTE
znamená„ paletu „.
Samozřejmě musíte dávejte pozor, aby data skutečně nebyla zobrazena koncovým uživatelům, protože pokud budou nakonec viditelná (jako se to stalo v případě adres URL), uživatelé budou oprávněně očekávat, že data být v jazyce, který umí číst.
Komentáře
- Dobře řečeno. ‚ Je trochu ironické, že protokol HTTP, který přenáší nejvíce unicode na planetě, musí podporovat pouze ASCII. (Vlastně předpokládám, že to samé platí pro TCP a IP, binární podporu, podporu ASCII … to ‚ je vše, co na této úrovni zásobníku potřebujete)
Odpověď
Za prvé: váš název používá / d ANSI, zatímco v textu odkazujete na ASCII. Upozorňujeme, že ANSI se nerovná ASCII. ANSI zahrnuje sadu ASCII. Sada ASCII je ale omezena na prvních 128 číselných hodnot (0 – 127).
Pokud jsou všechna vaše data omezena na ASCII (7bitová), nezáleží na tom, zda používáte UTF-8. , ANSI nebo ASCII, protože jak ANSI, tak UTF-8 obsahují celou sadu ASCII. Jinými slovy: číselné hodnoty 0 až 127 včetně včetně představují přesně stejné znaky v ASCII, ANSI a UTF-8.
Pokud potřebujete znaky mimo sadu ASCII, budete muset zvolit kódování. Můžete použít ANSI, ale pak narazíte na problémy všech různých kódových stránek.Vytvořte soubor na stroji A a přečtěte si jej na stroji B může / bude vytvářet vtipně vypadající texty, pokud jsou tyto stroje nastaveny na používání různých kódových stránek, jednoduché, protože číselná hodnota nnn představuje různé znaky na těchto kódových stránkách.
Tato „kódová stránka sakra“ je důvodem, proč byl definován standard Unicode . UTF-8 je pouze jediné kódování tohoto standardu, existuje jich mnohem více. UTF-16 je nejpoužívanější, protože se jedná o nativní kódování pro Windows.
Takže pokud potřebujete podporovat cokoli nad 128 znaků sady ASCII, moje rada je jít s UTF-8 . Tímto způsobem na tom nezáleží a nemusíte si dělat starosti s tím, s jakou kódovou stránkou vaši uživatelé nastavili své systémy.
Komentáře
- pokud nepotřebuji podporovat více než 128 znaků, jaká je výhoda volby kódování ACSII před kódováním UTF8?
- Kromě toho, že se omezujete na těch 128 znaků? Ne moc. UTF-8 byl speciálně navržen tak, aby vyhovoval ASCII a většině západních jazyků, které “ pouze “ potřebují ANSI. Zjistíte, že UTF-8 bude kódovat pouze relativně malý počet vyšších ANSI znaků s více než jedním bajtem. Existuje důvod, proč většina stránek HTML používá UTF-8 jako výchozí …
- @Pacerier, pokud ‚ nepotřebujete kódování nad 127, volba ASCII může být užitečná, když k kódování / dekódování použijete nějaké API, protože UTF potřebuje další ověření bitů, aby zvážila další bajty jako stejný znak, může to vyžadovat spíše další výpočet než čistý ASCII, který bez ověření přečetl 8 bitů. Doporučuji vám však použít ASCII pouze v případě, že opravdu potřebujete vysokou úroveň optimalizace ve velkém (velkém) výpočtu a víte, co v této optimalizaci děláte ‚. Pokud ne, stačí použít UTF-8.