Kiinan, japanin ja korean kielet. Tietomäärän ja muistikapasiteetin mittayksiköt: kilotavuja, megatavuja, gigatavuja ...

(Eikä kyse ole koosta)

Elliot Rusty Harold
Julkaistu 25.09.2013

Sivustokarttapalvelu Googleäskettäin aiheutti hieman kohua XML-yhteisössä, koska se alkoi vaatia, että kaikki sivustokartat julkaistaan ​​yksinomaan UTF-8 Unicodessa. Google ei edes salli vaihtoehtoisia Unicode-koodauksia (kuten UTF-16), puhumattakaan ei-Unicode-koodauksista, kuten ISO-8859-1. Teknisestä näkökulmasta tämä tarkoittaa, että Google käyttää jonkinlaista ei-standardien mukaista XML-jäsennintä, koska XML-suosituksen mukaan "Kaikkien XML-prosessorien PITÄÄ hyväksyä UTF-8- ja UTF-16 Unicode 3.1 -koodaukset". Onko tämä kuitenkin todella tällainen ongelma?

UTF-8 on kaikkien saatavilla

Monipuolisuus on ensimmäinen ja painavin syy valita UTF-8. Tämä koodaus pystyy toimimaan lähes minkä tahansa nykyään käytössä olevan kirjoitusjärjestelmän kanssa. Joitakin aukkoja on jäljellä, mutta ne ovat yhä harvinaisempia ja niitä täytetään. Suurin osa paljastamattomista kirjoitusjärjestelmistä ei myöskään ole toteutettu missään muussa merkistössä, ja vaikka olisikin, ne eivät ole saatavilla XML-muodossa. V paras tapaus ne toteutetaan yksitavuisten merkistöjen, kuten Latin-1, päälle rakennetuilla fonttihakkereilla. Todellinen tuki sellaisille harvinaisia ​​järjestelmiä kirjaimet näkyvät ensin Unicodessa (ja on todennäköistä, että vain Unicodessa eivätkä missään muualla).

Tämä on kuitenkin vain yksi Unicoden puolesta puhuvista argumenteista. Miksi valita UTF-8 UTF-16:n tai muiden Unicode-koodausten sijaan? Yksi ilmeisimmistä syistä on laaja tuki työkaluja... Lähes kaikki merkittävät editorit, joita voidaan käyttää XML:n kanssa, toimivat UTF-8:ssa, mukaan lukien JEdit, BBEdit, Eclipse, emacs ja jopa Windowsin Muistio(Muistilehtiö). Mikään muu Unicode-koodaus ei voi ylpeillä näin laajalla työkalutuella XML- ja ei-XML-apuohjelmissa.

Joissakin tapauksissa (kuten BBEdit ja Eclipse) UTF-8 ei ole oletusmerkistö. On aika muuttaa oletusasetuksia – kaikkien työkalujen oletuskoodauksen tulee olla UTF-8. Kunnes niin tapahtuu, jäämme loukkuun toiminnallisesti yhteensopimattomien tiedostojen suohon, jotka vioituvat siirrettäessä kansallisten rajojen, alustarajojen ja kielellisten rajojen yli. Kuitenkin, kunnes kaikkien ohjelmien oletuskoodaus on UTF-8, voit helposti muuttaa oletusasetuksia itse. Esimerkiksi Eclipsen Kuvassa 1 näkyvässä General / Editors -paneelissa voit määrittää, että kaikkien tiedostojen tulee olla UTF-8-koodattuja. Saatat huomata, että Eclipse "haluaa" MacRoman-oletusasennuksen; Jos kuitenkin sallitaan, tiedostojasi ei käännetä, kun ne välitetään ohjelmoijille, jotka työskentelevät toimivilla tietokoneilla Microsoftin järjestelmä® Windows® ja kaikki tietokoneet Amerikan ja Länsi-Euroopan ulkopuolella.

Kuva 1. Eclipsen oletusmerkkijoukon muuttaminen

Tietenkin, jotta UTF-8 toimisi, myös kehittäjien, joiden kanssa vaihdat tiedostoja, on käytettävä myös UTF-8:aa. mutta sen ei pitäisi olla ongelma. Toisin kuin MacRoman, UTF-8 ei rajoitu vain muutamaan kirjoitusjärjestelmään ja yhteen epätavalliseen alustaan. UTF-8 toimii hyvin yhdelle ja kaikille. Tilanne on täysin erilainen MacRomanin, Latin-1:n, SJIS:n ja monien muiden perinteisten kansallisten merkkisarjojen kanssa.

UTF-8 toimii myös paremmin työkaluilla, jotka eivät odota vastaanottavansa monitavuisia tietoja. Muut Unicode-muodot (kuten UTF-16) sisältävät yleensä useita nollatavuja. Monet työkalut tulkitsevat nämä tavut tiedoston lopuksi tai joksikin muuksi erityiseksi erottimeksi, jolla on odottamattomia, odottamattomia ja usein epämiellyttäviä seurauksia. Jos esimerkiksi UTF-16-data ladataan "nerokkaasti" C-merkkijonoon, merkkijono voidaan katkaista ensimmäisen ASCII-merkin toisessa tavussa. UTF-8-tiedostot sisältävät vain nollia, joiden pitäisi itse asiassa olla nollia. Tietenkään sinun ei pitäisi valita näitä yksinkertaisempia työkaluja XML-dokumenttien käsittelyyn. Asiakirjat päätyvät kuitenkin usein sellaisiin epätavallisiin paikkoihin perinteisissä järjestelmissä, joissa kukaan ei todellakaan ajatellut tai ymmärtänyt "uuden viinin kaatamisen vanhoihin viinileileihin" seurauksia. Järjestelmät, jotka eivät tunne Unicodea ja XML:ää, eivät todennäköisesti kohtaa ongelmia UTF-8:n kanssa kuin UTF-16:n tai muiden Unicode-koodausten kanssa.

Mitä speksit sanovat

XML oli ensimmäinen tärkeä standardi, joka tukee täysin UTF-8:aa, mutta se oli vasta trendin alkua. Standardointielimet suosittelevat yhä enemmän UTF-8:aa. Esimerkiksi URL-osoitteet, jotka sisältävät muita kuin ASCII-merkkejä, pitkä aika ovat olleet ratkaisematon ongelma Internetissä. PC:llä käynnissä oleva URL-osoite, joka sisälsi muita kuin ASCII-merkkejä, kieltäytyi toimimasta, kun se ladattiin Mac-alusta ja päinvastoin. Tämä ongelma ratkesi vasta äskettäin, kun konsortio Maailmanlaajuinen Web (W3C) ja Internet Engineering Task Force (IETF) ovat sopineet, että kaikki URL-osoitteet koodataan vain UTF-8-koodauksella, ei muuta koodausta.

Molemmat organisaatiot (W3C ja IETF) sisään viime aikoina ovat tulleet päättäväisemmiksi valitessaan UTF-8:n yleensä ja joskus ainoaksi koodaukseksi. Asiakirjassa W3C-hahmomalli maailma Laaja verkko 1.0: Perusteet("W3C-merkkimalli World Wide Web 1.0:lle: Perustiedot") todetaan: "Kun yksiselitteistä merkkikoodausta vaaditaan, merkkikoodauksen TÄYTYY olla UTF-8, UTF-16 tai UTF-32. US-ASCII-koodaus on ylöspäin yhteensopiva UTF-8:n kanssa (US-ASCII-merkkijono on myös UTF-8-merkkijono, katso), joten UTF-8:aa voidaan käyttää, jos US-ASCII-yhteensopivuus vaaditaan. Käytännössä US-ASCII-yhteensopivuus on niin hyödyllistä, että se on melkein vaatimus. W3C selittää viisaasti: "Muissa tilanteissa, kuten API:ille, UTF-16 tai UTF-32 voivat olla sopivampia. Mahdollisia syitä yhden näistä koodauksista voidaan valita sisäinen käsittelytehokkuus ja yhteentoimivuus muiden prosessien kanssa."

Voin uskoa väitettä sisäisen käsittelyn tehokkuudesta. Esimerkiksi merkkijonojen sisäinen esitys Java kieli™ perustuu UTF-16:een, mikä nopeuttaa huomattavasti merkkijonoon indeksointia. mutta Java koodi ei koskaan paljasta sisäistä esitystään ohjelmille, joiden kanssa se kommunikoi. Sen sijaan java.io.Writer käytetään ulkoiseen viestintään ja merkistö on erikseen määritelty. Tätä valintaa tehtäessä UTF-8 on erittäin suositeltavaa.

IETF:n vaatimukset ovat vieläkin selkeämpiä. Asiakirjassa IETF-merkkisarjakäytäntö(IETF Character Set Policy) sanoo nimenomaisesti:

Protokollien TÄYTYY pystyä käyttämään kaikessa tekstissä UTF-8-merkistöä, joka koostuu ISO 10646 -koodatusta merkistöstä yhdistettynä liitteessä R määriteltyyn UTF-8-merkistöön (julkaistu tarkistuksessa 2).

Protokollat ​​VOIVAT lisäksi määrittää, kuinka muita merkistöjä tai muita merkistökoodauksia käytetään ISO 10646:lle, kuten UTF-16, mutta UTF-8:n käyttämättä jättäminen on tämän käytännön vastaista. tällainen rikkomus edellyttäisi jonkinlaista hylkäysmenettelyä (lauseke 9), jossa on selkeä ja pakottava perustelu protokollamäärittelyasiakirjassa ennen standardipolulle siirtymistä tai siirtymistä alaspäin.

Olemassa oleville protokollille ja protokollille, jotka siirtävät tietoja olemassa olevista tietovarastoista, yksi vaatimus voi olla muiden merkistöjen tukeminen tai jopa muun kuin UTF-8:n oletuskoodauksen käyttö. Tämä on hyväksyttävää, mutta UTF-8-tuen TÄYTYY olla läsnä.

Keskeinen hetki: perinteisten protokollien ja tiedostojen tuki saattaa edellyttää muiden kuin UTF-8-merkkisarjojen ja -koodausten hyväksymistä jonkin aikaa - mutta astuisin kurkkuuni oma biisi jos minun pitäisi tehdä tämä. Jokainen uusi protokolla, jokainen uusi sovellus ja jokainen uusi asiakirja pitäisi käyttää UTF-8:aa.

Kiinan, japanin ja korean kielet

Yksi yleinen väärinkäsitys on, että UTF-8:n oletetaan olevan pakkausmuoto. Tämä on pohjimmiltaan väärin. ASCII-alueen merkit vievät vain puolet siitä tilasta UTF-8:ssa, jonka ne vievät joissakin muissa Unicode-koodauksissa, erityisesti UTF-16:ssa. Jotkut symbolit vaativat kuitenkin jopa 50 % enemmän tilaa UTF-8-koodaukselle - erityisesti kiinalaiset, japanilaiset ja korealaiset (CJK) merkit.

Mutta vaikka koodaat CJK XML:n UTF-8:aan, todellinen koon kasvu UTF-16:een verrattuna ei todennäköisesti ole yhtä merkittävää. Esimerkiksi XML-dokumentti Kiinalainen sisältää monia ASCII-merkkejä, kuten<, >, &, =, ",", ja välilyönti. Kaikki nämä merkit vievät vähemmän tilaa UTF-8:ssa kuin UTF-16:ssa. Pakkauksen tai laajennuksen tarkka määrä vaihtelee asiakirjasta toiseen, mutta joka tapauksessa ero ei todennäköisesti ole kovin havaittavissa.

Lopuksi on syytä huomata, että ideografiset kirjoitukset, kuten kiina ja japani, ovat yleensä "säästäviä" merkkien lukumäärän suhteen verrattuna aakkoskirjoihin, kuten latina ja kyrillinen kirjain. Jotkut näiden merkkien suuret absoluuttiset määrät vaativat vähintään kolme tavua per merkki edustaakseen täysin näitä kirjoitusjärjestelmiä; tämä tarkoittaa, että samat sanat ja lauseet voidaan ilmaista pienemmällä määrällä merkkejä kuin kielillä, kuten englanti ja venäjä. Esimerkiksi japanilainen puun ideogrammi on 木. (Se näyttää vähän puulta). Tämä ideogrammi on kolme tavua UTF-8:ssa, kun taas englanninkielinen sana "puu" on neljä kirjainta pitkä ja kestää neljä tavua. Japanilainen lehdon ideogrammi on æž- (kaksi puuta vierekkäin). Se vie myös kolme tavua UTF-8:ssa, kun taas englanninkielinen sana "grove" on viisi kirjainta pitkä ja kestää viisi tavua. Japanilainen ideogrammi æ £ ® (kolme puuta) vie edelleen vain kolme tavua. Ja vastaava englanninkielinen sana "metsä" kestää kuusi.

Jos olet todella kiinnostunut pakkaamisesta, pakkaa XML käyttämällä zip- tai gzip-apuohjelmia. Pakattu UTF-8 on todennäköisesti kooltaan lähellä pakattua UTF-16 alkuperäisestä kokoerosta huolimatta. Aluksi suurempi koko yksi asiakirjoista kompensoidaan suuremmalla redundanssilla, jonka pakkausalgoritmi eliminoi.

Luotettavuus

Todellinen kohokohta on, että suunnittelutarkoituksessa UTF-8 on paljon luotettavampi ja helpompi tulkita muoto kuin mikään muu ennen UTF-8:aa ja sen jälkeen kehitetty tekstikoodaus. Ensinnäkin, toisin kuin UTF-16, UTF-8:ssa ei ole tavujärjestysongelmia. Big endian ja big endian UTF-8 ovat identtisiä, koska UTF-8 määritellään 8-bittisinä tavuina eikä 16-bittisinä sanoina. UTF-8:ssa ei ole tavujärjestyksen epäselvyyttä, joka pitäisi ratkaista tavujärjestysmerkeillä tai muilla heuristiikalla.

Vielä enemmän tärkeä ominaisuus UTF-8:n ei tarvitse sitoa tilaa. Jokainen UTF-8-virran tai -sekvenssin tavu on ainutlaatuinen. UTF-8:ssa tiedät aina missä olet - eli yhden tavun perusteella voit välittömästi määrittää, onko kyseessä yksitavuinen merkki, kaksitavuisen merkin ensimmäinen tavu, kaksitavuisen merkin toinen tavu. tavumerkki tai kolmi- tai nelitavuisen merkin toinen, kolmas tai neljäs tavu... (Nämä eivät ole kaikki mahdollisuudet, mutta annetut tiedot auttavat sinua saamaan yleinen idea). UTF-16:ssa et aina tiedä, edustaako tavu "0x41" kirjainta "A". Joskus on ja joskus ei. Sinun on seurattava tilaa tarpeeksi tietääksesi missä olet streamissa. Jos jokin yksittäinen tavu katoaa, kaikki myöhemmät tiedot tästä pisteestä ovat vioittuneet. UTF-8:ssa kadonneet tai vioittuneet tavut havaitaan välittömästi vahingoittamatta muuta dataa.

UTF-8 ei ole ihanteellinen kaikkiin käyttötarkoituksiin. Sovellukset, jotka vaativat satunnaisen pääsyn tiettyihin dokumentin indekseihin, voivat toimia nopeammin, kun käytetään jonkinlaista kiinteän leveyden koodausta, kuten UCS2 tai UTF-32. (UTF-16 on muuttuvaleveinen koodaus, jos korvaavat parit otetaan huomioon.) XML-käsittely ei kuitenkaan ole relevanttia tällaisissa sovelluksissa. XML-spesifikaatio vaatii itse asiassa jäsentäjien aloittavan jäsentämisen ensimmäisestä tavusta XML-dokumentti ja jatkoi jäsentämistä loppuun asti, ja kaikki olemassa olevat jäsentimet toimivat juuri tällä tavalla. Satunnaiskäytön nopeuttaminen ei auttaisi XML-käsittelyä millään tavalla; siksi, vaikka tämä voi olla yksi hyvä syy käyttää jotakin muuta koodausta tietokannassa tai muussa järjestelmässä, se ei ole XML.

Johtopäätös

Yhä kansainvälistyvässä maailmassa, jossa kielelliset ja poliittiset rajat hämärtyvät päivä päivältä, paikallisesti erityisistä merkistöistä tulee käyttökelvottomia. Unicode on ainoa merkistö, jota voidaan käyttää kaikilla alueilla maailmassa. UTF-8 on oikea Unicode-toteutus, joka:

• sisältää laajan työkalutuen, mukaan lukien paras yhteensopivuus vanhojen ASCII-järjestelmien kanssa;
• yksinkertainen ja tehokas käsitellä;
• kestää tietojen korruptiota;
• on alustariippumaton.

On aika lopettaa merkistö- ja koodauskeskustelu – valitse UTF-8 ja lopeta keskustelu.

Teoriassa näihin ongelmiin on ollut ratkaisu jo pitkään. Sitä kutsutaan Unicode Unicode On koodaustaulukko, jossa käytetään 2 tavua kunkin merkin koodaamiseen, ts. 16-bittinen. Tällaisen taulukon perusteella N = 2 16 = 65 536 merkkiä voidaan koodata.

Unicode sisältää lähes kaikki nykyaikaiset kirjaimet, mukaan lukien: arabia, armenia, bengali, burma, kreikka, georgia, devanagari, heprea, kyrillinen, kopti, khmeri, latina, tamili, hangul, han (Kiina, Japani, Korea), Cherokee, Etiopia, japanilaiset (Katakana, Hiragana, Kanji) ja muut.

Akateemisiin tarkoituksiin on lisätty monia historiallisia kirjoituksia, mukaan lukien: antiikin kreikka, egyptiläiset hieroglyfit, nuolenpääkirjoitus, maya-kirjoitus, etruskien aakkoset.

Unicode tarjoaa laajan valikoiman matemaattisia ja musiikillisia symboleja ja kuvakkeita.

Unicodessa on kaksi koodialuetta kyrillisille merkeille:

Kyrillinen (# 0400 - # 04FF)

Kyrillinen lisäosa (# 0500 - # 052F).

Mutta pöytäinjektio Unicode puhtaassa muodossaan se on pidätetty siitä syystä, että jos yhden merkin koodi ei vie yhtä tavua vaan kaksi tavua, tekstin tallentamiseen kuluu kaksi kertaa enemmän levytila, ja sen lähettämiseksi viestintäkanavien kautta - kaksi kertaa pidempään.

Siksi käytännössä nykyään UTF-8:n (Unicode Transformation Format) Unicode-esitys on yleisempi. UTF-8 tarjoaa parhaan yhteensopivuuden 8-bittisiä merkkejä käyttävien järjestelmien kanssa. Teksti, joka sisältää vain merkkejä, joiden numero on alle 128, muunnetaan tavalliseksi ASCII-tekstiksi, kun se kirjoitetaan UTF-8:lla. Loput Unicode-merkit esitetään 2–4 tavun pituisina sarjoina. Yleisesti ottaen, koska maailman yleisimmät merkit - latinalaisten aakkosten merkit - UTF-8:ssa vievät edelleen 1 tavun, tämä koodaus on taloudellisempaa kuin puhdas Unicode.

Koodatussa Englanninkielinen teksti käytetään vain 26 latinalaisen aakkoston kirjainta ja 6 muuta välimerkkiä. Tässä tapauksessa 1000 merkkiä sisältävä teksti voidaan taata pakattavaksi ilman tietojen menetystä kokoon:

Ellochkan sanakirja - "kannibaali" (hahmo romaanissa "Kaksitoista tuolia") on 30 sanaa. Kuinka monta bittiä riittää koodaamaan koko sanastoa Ellochki? Vaihtoehdot: 8, 5, 3, 1.

1. Tietomäärän ja muistikapasiteetin mittayksiköt: kilotavuja, megatavuja, gigatavuja ...

Joten, huomasimme, että useimmissa nykyaikaiset koodaukset Tekstin yhden merkin tallentamiseen sähköiselle medialle on varattu 1 tavu. Nuo. tavuina datan varaama tilavuus (V) mitataan niiden tallennuksen ja siirron aikana (tiedostot, viestit).

Tietomäärä (V) - tavujen määrä, joka tarvitaan niiden tallentamiseen elektronisen tietovälineen muistiin.

Tallennusvälineitä puolestaan ​​on rajoitettu kapasiteettia, eli kyky sisältää tietyn tilavuuden. Muistikapasiteetti elektroninen media tieto mitataan tietysti myös tavuissa.

Tavu on kuitenkin pieni tietomäärän mittayksikkö, suuremmat ovat kilotavuja, megatavuja, gigatavuja, teratavuja ...

On muistettava, että etuliitteet "kilo", "mega", "giga" ... eivät ole mukana tässä tapauksessa desimaali. Joten "kilo" sanassa "kilotavu" ei tarkoita "tuhatta", ts. ei tarkoita "10 3". Bitti on binääriyksikkö, ja tästä syystä tietojenkäsittelytieteessä on kätevää käyttää mittayksiköitä, jotka ovat luvun "2" kerrannaisia ​​luvun "10" sijaan.

1 tavu = 2 3 = 8 bittiä, 1 kilotavu = 2 10 = 1024 tavua. V binääri 1 kilotavu = & 1 000 000 000 tavua.

Nuo. "Kilo" tarkoittaa tässä lähimpänä tuhatta olevaa lukua, joka on luvun 2 potenssi, ts. joka on "pyöreä" luku binäärijärjestelmä laskeminen.

Taulukko 10.

Johtuen siitä, että tilavuuden ja kapasiteetin mittayksiköt tiedon välittäjät ovat 2:n kerrannaisia ​​eivätkä 10:n kerrannaisia, useimmat tämän aiheen ongelmat on helpompi ratkaista, kun niissä esiintyvät arvot esitetään potenssilla 2. Tarkastellaan esimerkkiä samanlaisesta ongelmasta ja sen ratkaisusta:

Tekstitiedosto sisältää 400 sivua tekstiä. Jokainen sivu sisältää 3200 merkkiä. Jos koodaus on KOI-8 (8 bittiä per merkki), tiedostokoko on:

Ratkaisu

Määritä tekstitiedoston merkkien kokonaismäärä. Tässä tapauksessa edustamme lukuja, jotka ovat 2:n potenssin kerrannaisia, 2:n potenssina, ts. 4:n sijasta kirjoitamme 2 2 jne. Taulukkoa 7 voidaan käyttää tutkinnon määrittämiseen.

hahmoja.

2) Tehtävän ehdon mukaan 1 merkki vie 8 bittiä, ts. 1 tavu => tiedosto vie 2 7 * 10 000 tavua.

3) 1 kilotavu = 2 10 tavua => tiedoston koko kilotavuina on:

.

Kuinka monta bittiä on yhdessä kilotavussa?

&10000000000000.

Mitä on 1 MB?

1024 tavua;

1024 kilotavua;

• 1 000 000 tavua.

Kuinka monta bittiä neljänneskilotavuisessa viestissä on? Vaihtoehdot: 250, 512, 2000, 2048.

Äänenvoimakkuus tekstitiedosto 640 kb... Tiedosto sisältää kirjan, joka on kirjoitettu keskimäärin 32 riviä sivua kohden 64 merkkijonossa. Kuinka monta sivua kirjassa on: 160, 320, 540, 640, 1280?

Asiakirja työntekijöistä 8 Mb... Jokainen niistä sisältää 16 sivut ( 32 riviä 64 merkki per rivi). Kuinka monta työntekijää organisaatiossa: 256; 512; 1024; 2048?

Tämä viesti on tarkoitettu niille, jotka eivät ymmärrä mitä UTF-8 on, mutta haluavat ymmärtää sen, ja saatavilla oleva dokumentaatio kattaa tämän ongelman usein hyvin laajasti. Yritän kuvailla sitä täällä sillä tavalla, että itse haluaisin jonkun kertovan sen minulle aiemmin. Siitä lähtien minulla on ollut sotku päässäni UTF-8:sta.

Muutama yksinkertainen sääntö

1. Joten UTF-8 on Unicoden ympärillä oleva kääre. Se ei ole erillinen merkkikoodaus, vaan se on kääritty Unicodeen. Tiedät luultavasti Base64-koodauksen tai olet kuullut siitä – se voi kääriä binääritiedot tulostettaviin merkkeihin. Duck, UTF-8 on sama Base64 Unicodelle kuin Base64 binääritiedoille. Tällä kertaa. Jos ymmärrät tämän, niin paljon tulee jo selväksi. Ja sen, kuten Base64:n, tiedetään myös ratkaisevan merkkien yhteensopivuusongelmat (Base64 keksittiin sähköpostille tiedostojen siirtämiseksi postitse, joissa kaikki merkit ovat tulostettavissa)
2. Lisäksi, jos koodi toimii UTF-8:n kanssa, niin sisäisesti se toimii edelleen Unicode-koodauksilla, eli jossain syvällä sisällä on täsmälleen Unicode-merkkien symbolien taulukot. Totta, sinulla ei ehkä ole Unicode-merkkitaulukoita, jos sinun on esimerkiksi laskettava kuinka monta merkkiä rivillä on (katso alla)
3. UTF-8 on tehty siihen tarkoitukseen, että vanhat ohjelmat ja nykyiset tietokoneet voivat toimia normaalisti Unicode-merkeillä, kuten vanhoilla koodauksilla, kuten KOI8, Windows-1251 jne. UTF-8:ssa ei ole nollia sisältäviä tavuja, kaikki tavut ovat ne ovat joko 0x01 - 0x7F, kuten normaali ASCII, tai 0x80 - 0xFF, joka toimii myös C-ohjelmissa, koska se toimisi muiden kuin ASCII-merkkien kanssa. Totta, varten oikea työ symboleilla ohjelman tulee tuntea Unicode-taulukot.
4. Kaikki, jolla on merkittävin 7. bitti tavussa (bitit lasketaan nollasta) UTF-8 on osa Unicode-koodivirtaa.

UTF-8 sisältä ulospäin

Jos tiedät bittijärjestelmän, niin tässä sinulle nopea muistio miten UTF-8 on koodattu:

UTF-8-merkin ensimmäinen Unicode-tavu alkaa tavulla, jossa 7. bitti on aina yksi ja 6. bitti on aina yksi. Tässä tapauksessa ensimmäisessä tavussa, jos katsot bittejä vasemmalta oikealle (7., 6. ja niin edelleen nollaan), yksiköitä on yhtä monta kuin tavua, mukaan lukien ensimmäinen, siirry yhden Unicode-merkin koodaamiseen. Ykkösten sarja päättyy nollaan. Ja sen jälkeen ovat itse Unicode-merkin bitit. Loput merkin Unicode-bitit kuuluvat toiseen tai jopa kolmanteen tavuun (enintään kolme, miksi - katso alla). Loput tavut ensimmäistä lukuun ottamatta tulevat aina Unicode-merkin alussa '10' ja sitten 6 bitillä seuraavasta osasta.

Esimerkki

Esimerkiksi: on tavuja 110 10000 ja toinen 10 011110 ... Ensimmäinen alkaa luvulla 110, mikä tarkoittaa, että jos niitä on kaksi, UTF-8-virrasta tulee kaksi tavua, ja toinen tavu, kuten kaikki muutkin, alkaa numerolla 10. Ja nämä kaksi tavua koodaavat Unicode-merkin, joka koostuu 10100 bitistä ensimmäisestä palasta + 101101 toisesta, käy ilmi -> 10000011110 -> 41E heksadesimaalijärjestelmässä tai U + 041E kirjallisesti Unicode-merkinnät. Tämä on suuren venäläisen O:n symboli.

Kuinka monta tavua per merkki on suurin?

Katsotaan myös kuinka monta tavua maksimimäärä menee UTF-8:aan Unicode-koodauksen 16 bitin koodaamiseksi. Toinen ja sitä seuraavat tavut voivat aina sisältää enintään 6 bittiä. Joten jos aloitat perässä olevilla tavuilla, kaksi tavua katoaa täsmälleen (2. ja kolmas), ja ensimmäisen on alettava numerolla 1110 koodatakseen kolme. Tämä tarkoittaa, että ensimmäinen tavu voi tässä tapauksessa koodata Unicode-merkin 4 ensimmäistä bittiä. Se käy ilmi 4 + 6 + 6 = 16 tavu. Osoittautuu, että UTF-8:ssa voi olla joko 2 tai 3 tavua Unicode-merkkiä kohden (ei voi, koska ei tarvitse koodata 6 bittiä (8 - 2 bittiä '10') - ne ASCII-merkki... Tästä syystä UTF-8:n ensimmäinen tavu ei voi koskaan alkaa luvulla 10).

Johtopäätös

Muuten, tämän koodauksen ansiosta voit ottaa minkä tahansa tavun virrasta ja määrittää, onko tavu Unicode-merkki (jos 7. bitti ei ole ASCII), jos on, onko se ensimmäinen UTF-8-virrassa tai ei ensimmäinen (jos '10' ei tarkoita ensimmäistä), jos ei ensimmäinen, voimme siirtyä tavua taaksepäin löytääksemme ensimmäisen UTF-8-koodin (jonka kuudes bitti on 1), tai siirtyä oikealle ja ohita kaikki 10 tavua löytääksesi seuraavan merkin. Tämän koodauksen ansiosta ohjelmat voivat myös Unicodea tuntematta lukea kuinka monta merkkiä merkkijonossa on (ensimmäisen UTF-8-tavun perusteella laskea merkin pituus tavuina). Yleisesti ottaen, jos ajattelet sitä, UTF-8-koodaus keksittiin erittäin pätevästi ja samalla erittäin tehokas.

Unicode tukee lähes kaikkia olemassa olevia merkistöjä. Paras muoto Unicode-merkistön koodaus on UTF-8-koodaus. Se toteuttaa ASCII-yhteensopivuuden, tietojen korruption keston, tehokkuuden ja käsittelyn helppouden. Mutta ensin asiat ensin.

Koodauslomakkeet

Tietokoneet eivät käytä numeroita vain abstrakteina matemaattisina esineinä, vaan yksiköiden yhdistelminä tiedon tallentamiseksi ja käsittelemiseksi. kiinteä koko- tavut ja 32-bittiset sanat. Koodausstandardin tulee ottaa tämä huomioon esitystapaa määritettäessä.

V tietokonejärjestelmät kokonaisluvut tallennetaan 8 bitin (1 tavu), 16 tai 32 bitin muistipaikkoihin. Jokainen Unicode-koodauksen muoto määrittää, mikä muistipaikkojen sarja edustaa tiettyä merkkiä vastaavaa kokonaislukua. Standardi esittää kolme useita muotoja Unicode-merkkikoodaus: 8-, 16- ja 32-bittiset lohkot. Sen mukaisesti niitä kutsutaan UTF-8, UTF-16 ja UTF-32. Nimi UTF tulee sanoista Unicode Transformation Format. Jokainen kolmesta koodausmuodosta on samanlainen tapa esittää Unicode-merkkejä, ja sillä on etuja eri alueita sovellus.

Näitä koodauksia voidaan käyttää edustamaan kaikkia Unicode-merkkejä. Näin ollen ne ovat täysin yhteensopivia ratkaisujen mukaan eri syistä käyttämällä erilaisia ​​koodausmuotoja. Jokainen koodaus voidaan yksiselitteisesti muuntaa mihin tahansa kahdesta muusta ilman tietojen menetystä.

Päällekkäisyyden periaate

Jokainen Unicode-koodauksen muoto on suunniteltu päällekkäisyyttä ajatellen. Esimerkiksi Windows-932 luo merkkejä yhdestä tai kahdesta kooditavusta. Jakson pituus riippuu ensimmäisestä tavusta, joten kahden tavun ja yhden tavun sekvenssin johtavan tavun arvot eivät mene päällekkäin. Sarjan yksittäisen tavun ja lopputavun arvot voivat kuitenkin olla samat. Tämä tarkoittaa esimerkiksi sitä, että etsiessäsi merkkiä D (koodi 44), voit vahingossa löytää sen sisältyvän merkin "D" kahden tavun sekvenssin toiseen osaan (koodi 84 44). Selvittääkseen, mikä sekvenssi on oikea, ohjelman on otettava huomioon edelliset tavut.

Tilanne muuttuu monimutkaisemmaksi, jos alku- ja lopputavut ovat samat. Tämä tarkoittaa, että epäselvyyden poistamiseksi suoritetaan käänteistä hakua, kunnes tekstin alkuun tai yksiselitteiseen koodisarjaan päästään. Tämä ei ole vain tehotonta, mutta se ei ole immuuni sille mahdollisia virheitä, koska yksi väärä tavu riittää tekemään koko tekstistä lukukelvottoman.

Unicode-muunnosmuoto välttää tämän ongelman, koska alku-, loppu- ja yksittäisen tallennusyksikön arvot eivät täsmää. Tämän ansiosta kaikki Unicode-koodaukset sopivat etsimiseen ja vertailuun, eivätkä koskaan anna virheellistä tulosta osuman vuoksi. eri osat merkkikoodi. Se tosiasia, että nämä koodausmuodot noudattavat päällekkäisyysperiaatetta, erottaa ne muista monitavuisista Itä-Aasian koodauksista.

Toinen ei-leikkauksen puoli on, että jokaisella hahmolla on hyvin määritellyt rajat. Tämä eliminoi tarpeen skannata määrittelemätön määrä aikaisempia merkkejä. Tämä ominaisuus koodauksia kutsutaan joskus itsesynkronointiksi. Yhden koodiyksikön vääristyminen johtaa vain yhden merkin vääristymiseen, ja ympäröivät merkit pysyvät ennallaan. 8-bittisessä muunnosmuodossa, jos osoitin viittaa tavuun, joka alkaa 10xxxxxx (binäärikoodauksessa), merkin alun löytäminen vaatii yhdestä kolmeen taaksepäin hyppäämistä.

Johdonmukaisuus

Unicode Consortium tukee täysin kaikkia kolmea koodauksen muotoa. On tärkeää olla vastustamatta UTF-8:aa ja Unicodea, koska kaikki muunnosmuodot ovat yhtä laillisia Unicode-merkkikoodausmuotojen inkarnaatioita.

Tavusuuntaus

UTF-32-merkin edustamiseksi tarvitset yhden 32-bittisen koodiyksikön, joka on sama kuin Unicode-koodi. UTF-16 - Yksi tai kaksi 16-bittistä yksikköä. Ja UTF-8 käyttää jopa 4 tavua.

UTF-8-koodaus on suunniteltu yhteensopivaksi tavusuuntautuneiden järjestelmien kanssa ASCII-pohjainen. Suurin osa olemassa olevia ohjelmistoja ja käytäntöjä tietotekniikat pitkä aika luotti merkkien esittämiseen tavujonona. Monet protokollat ​​ovat riippuvaisia ​​muuttumattomuudesta ja käyttävät tai välttävät erityisiä ohjausmerkkejä. Yksinkertaisella tavalla Voit mukauttaa Unicoden tällaisiin tilanteisiin käyttämällä 8-bittistä koodausta edustamaan Unicode-merkkejä, jotka vastaavat mitä tahansa merkkiä tai ohjausmerkkiä. Tätä varten UTF-8-koodaus on tarkoitettu.

Vaihteleva pituus

UTF-8 - koodaus vaihteleva pituus, joka koostuu 8-bittisistä tiedon tallennusyksiköistä, joiden merkittävimmät bitit osoittavat, mihin sekvenssin osaan kukin yksittäinen tavu kuuluu. Yksi arvoalue on varattu koodisekvenssin ensimmäiselle elementille, toinen seuraaville. Tämä varmistaa, että koodaus ei ole leikkaava.

ASCII

UTF-8-koodaus tukee täysin ASCII-koodit(0x00-0x7F). Tämä tarkoittaa, että Unicode-merkit U + 0000-U + 007F muunnetaan yhdeksi tavuksi 0x00-0x7F UTF-8, joten niistä tulee erottamattomia ASCII:stä. Lisäksi epäselvyyden välttämiseksi arvoja 0x00-0x7F ei käytetä missään muussa Unicode-tavussa. Kahden tavun sekvenssiä käytetään ei-ideografisten ei-ASCII-merkkien koodaamiseen. Merkkejä alueella U + 0800-U + FFFF edustaa kolme tavua, ja lisämerkit, joiden koodi on suurempi kuin U + FFFF, vaativat neljä tavua.

Sovellusalue

UTF-8 on yleensä parempi kuin HTML ja vastaavat.

XML:stä tuli ensimmäinen standardi täysi tuki UTF-8-koodaukset. Myös standardiorganisaatiot suosittelevat sitä. Tukiongelma sisään URL-osoitteet ei-ASCII-merkit ratkaistiin, kun W3C-konsortio ja IETF-insinööriryhmä sopivat koodaavan kaiken yksinomaan UTF-8:lla.

ASCII-yhteensopivuus tekee siirtymisestä helppoa ohjelmisto... Useimmat tekstieditorit toimivat UTF-8:n kanssa, mukaan lukien JEdit, Emacs, BBEdit, Eclipse ja Notepad käyttöjärjestelmä Windows. Mikään muu Unicode-koodaus ei voi ylpeillä sellaisella työkalutuella.

Koodauksen etuna on, että se koostuu tavujen sarjasta. UTF-8-merkkijonoja on helppo työstää C-ohjelmointikielillä ja muilla ohjelmointikielillä. Se on ainoa koodausmuoto, joka ei vaadi tuoteluetteloa tai koodausilmoitusta XML-muodossa.

Itsesynkronointi

Ympäristössä, joka käyttää 8-bittistä merkkikäsittelyä, UTF-8:lla on seuraavat edut muihin monitavuisiin koodauksiin verrattuna:

• Koodisekvenssin ensimmäinen tavu sisältää tietoa sen pituudesta. Tämä parantaa suorahaun tehokkuutta.
• Merkin alun löytäminen on yksinkertaistettu, koska aloitustavu on rajoitettu kiinteään arvoalueeseen.
• Tavuarvoilla ei ole leikkauskohtaa.

Etujen vertailu

UTF-8-koodaus on kompakti. Mutta kun niitä käytetään, 3-tavuisia sarjoja käytetään koodaamaan itä-aasialaisia ​​merkkejä (kiina, japani, korea, kiinalaisia ​​merkkejä). Lisäksi UTF-8-koodaus on muita koodausmuotoja huonompi käsittelynopeuden suhteen. Ja merkkijonojen binäärilajittelu antaa saman tuloksen kuin Unicoden binäärilajittelu.

Merkkien koodausjärjestelmä

Merkkikoodausmalli koostuu merkkien koodausmuodosta ja koodiyksiköiden tavukohtaisesta järjestelystä. Koodausmallin määrittelemiseksi Unicode-standardi mahdollistaa tavujärjestysmerkin (BOM) käytön.

Kun BOM sisällytetään UTF-8:aan, etikettitoiminto rajoittuu vain osoittamaan koodausmuodon käyttöä. UTF-8:lla ei ole ongelmia tavujärjestyksen määrittämisessä, koska sen koodausyksikön koko on yhtä suuri kuin yksi tavu. BOM:n käyttöä tälle koodausmuodolle ei vaadita eikä suositella. Tuoteteksti voi esiintyä tekstissä, joka on muunnettu muista koodauksista, jotka käyttävät tuoteluetteloa, tai UTF-8-koodausallekirjoituksessa. Se on 3 tavun sekvenssi EF 16 BB 16 BF 16.

Kuinka asettaa UTF-8-koodaus

UTF-8:ssa se asennetaan seuraavalla koodilla:

˂meta http-equiv = "Content-Type" content = "text / html; charset = utf-8" ˃

V PHP koodaus UTF-8 asetetaan otsikko () -toiminnolla aivan tiedoston alussa sen jälkeen, kun olet asettanut virheen lähtötason arvon:

virhe_raportointi (-1);

Merkistö = utf-8");

Yhteyden muodostaminen tukikohtiin MySQL-tiedot UTF-8-koodaus on asetettu seuraavasti:

mysql_set_charset ("utf8");

CSS-tiedostoissa UTF-8-merkkikoodaus on määritetty seuraavasti:

@charset "utf-8";

Kaiken tyyppisiä tiedostoja tallennettaessa valitaan UTF-8-koodaus ilman BOM:ia, muuten sivusto ei toimi. Tätä varten DreamWeave-ohjelmassa valitse valikkokohta "Modifikaatiot - Sivun ominaisuudet - Otsikko / Koodaus", vaihda koodaukseksi UTF-8. Lataa sitten sivu uudelleen, poista valinta "Connect Unicode Signatures (BOM)" -ruudusta ja ota muutokset käyttöön. Jos jokin sivulla tai tietokannassa oleva teksti on syötetty muulla koodauksella, se on syötettävä tai koodattava uudelleen. Kun työskentelet säännöllisiä lausekkeita muista käyttää u-muuttajaa.

Tekstissä Muistioeditori++, jos koodaus poikkeaa UTF-8:sta, käytä "Muunna UTF-8:ksi ilman tuoteluetteloa" -valikkokohtaa vaihtaaksesi koodauksen ja tallentaaksesi sen UTF-8-koodauksella.

Ei ole vaihtoehtoa

Globalisaation yhteydessä, kun poliittiset ja kielelliset rajat poistetaan, paikallisia piirteitä sisältävistä merkistöistä tulee vähän hyötyä. Unicode on ainoa merkistö, joka tukee kaikkia lokalisointeja. Ja UTF-8 on esimerkki oikeasta Unicode-toteutuksesta, joka:

• Tukee monenlaisia ​​työkaluja, mukaan lukien ASCII-yhteensopivuus;
• kestää tietojen korruptiota;
• yksinkertainen ja tehokas käsittelyssä;
• alustasta riippumaton.

UTF-8:n myötä keskustelu siitä, mikä koodaus tai merkistö on paras, on muuttunut merkityksettömäksi.