» »

Unicode 8.0.0 prinaša več kot sedem tisoč novih znakov

Unicode 8.0.0 prinaša več kot sedem tisoč novih znakov

Slo-Tech - Izšla je nova verzija standarda Unicode, ki se uporablja za enoten zapis znakov vseh jezikov na svetu. Verzija 8.0.0 prinaša 7.716 novih znakov, ki dopolnjujejo zlasti kitajski, japonski in korejski sistem zapisa. Druge novosti so še dodatni mali znaki za pisavo Cherokeejev ter posamezne dopolnitve afriških pisav. Nenazadnje so dodali tudi 41 novih smeškov.

Unicode je standard, ki vsakemu znaku pripiše enolično številko. Dejansko kodiranje je različno, daleč najpogosteje pa se uporablja de facto standard UTF-8, ki je zamenjal ASCII in razne stare omejene standarde, npr. CP852 ali Windows-1250. UTF-8 kodira znake tako, da je dolžina znaka od 1 do 4 bajtov, odvisno od pozicije znaka v kodni tabeli. To je bilo nujno za zagotavljanje združljivosti z ASCII in varčevanje s prostorom (kako deluje trik preslikave na ravnine, kaže spodnji videoposnetek). UTF-16 in UTF-32 sta druga načina kodiranja, kjer v prvem potrebujemo 2-4 bajte, v drugem pa vedno 4. Internet je v glavnem UTF-8, UTF-16 najdemo na primer interno v Windows, UTF-32 pa je sorazmerno redek, razen v nišni uporabi.

Unicode lahko teoretično vsebuje 1.114.112 znakov, ki so razporejeni po 17 ravninah. Trenutno je dodeljenih okrog 10 odstotkov vseh kapacitet, vse na prvih dveh ravninah, zato nam prostora še lep čas ne bo zmanjkalo. Ker gre svet v čedalje večjo standardizacijo in poenotenje, bo Unicode verjetno ostal standard še dolga desetletja.

38 komentarjev

HPME ::

Zakaj se Unicode ne uporablja v Linuxu?

TEDY ::

saj se

čuhalev ::

Tole nekoliko kvari dobre stare programerske trike, kako dobiti iz malih črk velike in obratno, pa tudi strlen funkcije bodo dražje, ker mora funkcija razumeti črko in ne samo prešteti skoke do 0x00.

technolog ::

jaakaa, pod katero skalo si živel prejšnjih 10 let?

phantom ::

Jaakaa, kadar te funkcije rabiš, string pretvoriš v UTF-32 in tako šteješ znake, lepiš stringe, režeš substringe. Ob koncu, ko hočeš string izpisati ali zapisati v datoteko, ga pretvoriš nazaj v UTF-8. Java in .NET te pretvorbe delata avtomatsko, vse stringe interno hranita v UTF-32. V C-ju imaš funkcije wcstombs()/mbstowcs() za te pretvorbe v standardni knjižnjici.
~
~
:wq

StarMafijec ::

Optimalneje bi sicer bilo, da bi bil proces obraten. Torej, da bi se ljudje počasi privadili na zgolj en jezik in da bi v nekaj generacijah bila na svetu le ena materinščina.

johnnyyy ::

jaakaa: Črke v Unicode tabeli niso nametane naključno ampak so v nekem zaporedju. Zato menjava ni pereč problem. Tudi strlen ni problematična, saj funkcija vrne dolžino stringa v bajtih. Največje greške, ki se pri tem naredijo so predpostavke, da je na offsetu xyz v bajtih (seštevanje pointerjev), xyz-ti znak.

MrStein ::

phantom je izjavil:

Java in .NET te pretvorbe delata avtomatsko, vse stringe interno hranita v UTF-32.

Java interno uporablja UTF-16: http://stackoverflow.com/questions/9699...

PS: No, eni "skeptiki" so tudi jamrali, da bo parsanje stringov težje, varnost pa kar izginila. Če se ne motim, prav na ST-ju je bil ta post. Podobno za mednarodne domain name-je. V uporabi so že čez desetletje, pa konca sveta še kar ni. ;)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

smash ::

StarMafijec je izjavil:

Optimalneje bi sicer bilo, da bi bil proces obraten. Torej, da bi se ljudje počasi privadili na zgolj en jezik in da bi v nekaj generacijah bila na svetu le ena materinščina.


v bistvu je treba stremet k temu, da bo na svetu čimveč raznolikosti, torej čimveč različnih jezikov

technolog ::

MrStein je izjavil:

phantom je izjavil:

Java in .NET te pretvorbe delata avtomatsko, vse stringe interno hranita v UTF-32.

Java interno uporablja UTF-16: http://stackoverflow.com/questions/9699...

PS: No, eni "skeptiki" so tudi jamrali, da bo parsanje stringov težje, varnost pa kar izginila. Če se ne motim, prav na ST-ju je bil ta post. Podobno za mednarodne domain name-je. V uporabi so že čez desetletje, pa konca sveta še kar ni. ;)


Kako lahko potem charAt teče v konstantnem času?

MrStein ::

Ker je shranjeno v char [] array?
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

WhiteAngel ::

HPME je izjavil:

Zakaj se Unicode ne uporablja v Linuxu?


V Linuxu izbereš za locale, kar hočeš. Večina uporabnikov in programja uporablja UTF-8 v praksi.

čuhalev je izjavil:

Tole nekoliko kvari dobre stare programerske trike, kako dobiti iz malih črk velike in obratno, pa tudi strlen funkcije bodo dražje, ker mora funkcija razumeti črko in ne samo prešteti skoke do 0x00.


Iz malih črk velike in obratno lahko dobiš še vedno isto, saj je UTF-8 kompatibilen z ASCII za prvih 128 znakov. Če si pa želel mali č v veliki Č, pa to že prej ni bilo tako trivialno.

technolog je izjavil:

MrStein je izjavil:

phantom je izjavil:

Java in .NET te pretvorbe delata avtomatsko, vse stringe interno hranita v UTF-32.

Java interno uporablja UTF-16: http://stackoverflow.com/questions/9699...

PS: No, eni "skeptiki" so tudi jamrali, da bo parsanje stringov težje, varnost pa kar izginila. Če se ne motim, prav na ST-ju je bil ta post. Podobno za mednarodne domain name-je. V uporabi so že čez desetletje, pa konca sveta še kar ni. ;)


Kako lahko potem charAt teče v konstantnem času?


Se da. Operacija, ki te zanima je constant time rank&select. Potrebuješ pa dodaten bit na vsak znak v stringu.

technolog ::

MrStein: Ne.

@White Angel:

Kar se tiče pretvarjanja velike male črke je še večji problem. Recimo nemški ostri s (ß), če ga prevoriš v velike črke, rata dvakrat s (SS). große -> GROSSE.

Hvala za tole, si bom malo pogledal.

MrStein ::

Ne, kaj?
V Javi je dobesedno: return value[index];
value pa je: private final char value[];
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

commissar ::

phantom je izjavil:

Jaakaa, kadar te funkcije rabiš, string pretvoriš v UTF-32 in tako šteješ znake, lepiš stringe, režeš substringe. Ob koncu, ko hočeš string izpisati ali zapisati v datoteko, ga pretvoriš nazaj v UTF-8. Java in .NET te pretvorbe delata avtomatsko, vse stringe interno hranita v UTF-32. V C-ju imaš funkcije wcstombs()/mbstowcs() za te pretvorbe v standardni knjižnjici.


java in .net vse interne stvari hranita v utf-16

arjan_t ::

MrStein je izjavil:

Ne, kaj?
V Javi je dobesedno: return value[index];
value pa je: private final char value[];


char je velik 2 bajta torej to ne dela za vse primere pravilno.

MrStein ::

Kaj ne dela pravilno?
Se precej nejasno izražate....

Mimogrede, tisto zgoraj je koda v uporabi že tam 20 let. Preverjeno deluje.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

HPME ::

Če Windows in Linux uporabljata Unicode zakaj so imena datotek na ASCII?

arjan_t ::

Ne dela pravilno za znake velike 4 bajte.

MrStein ::

Znaki, ki ne gredo v en char, so razbita na dva char-a.
Pač kot veleva UTF-16 standard.

HPME je izjavil:

Če Windows in Linux uporabljata Unicode zakaj so imena datotek na ASCII?

Imena datotek so Unicode že 20 let. Na Windows.
Na Linux pa so "whatever you like them to be (the OS doesn't care, they are bytes to them)".
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

garamond ::

technolog je izjavil:

Kar se tiče pretvarjanja velike male črke je še večji problem. Recimo nemški ostri s (ß), če ga prevoriš v velike črke, rata dvakrat s (SS). große -> GROSSE.
Poleg ß obstaja tudi veliki ß (ẞ), ki naj bi se uporabljal v geografskih imenih, ki so napisana z velikimi črkami.
A parody of extremism is impossible to differentiate from sincere extremism.

WhiteAngel ::

HPME je izjavil:

Če Windows in Linux uporabljata Unicode zakaj so imena datotek na ASCII?


ASCII je 7-bitni standard. Če bi Windows in Linux uporabljala le ASCII, potem ne bi mogel imeti šumnikov v imenih datotek. Pa jih imaš.

ender ::

phantom je izjavil:

Jaakaa, kadar te funkcije rabiš, string pretvoriš v UTF-32 in tako šteješ znake, lepiš stringe, režeš substringe.
UTF-32 ti ne pomaga nič, ker je lahko vsaka črka sestavljena iz večih znakov (del Unicode standarda so že od začetka kombinirane označevalne oznake).

MrStein je izjavil:

Imena datotek so Unicode že 20 let. Na Windows.
Na Linux pa so "whatever you like them to be (the OS doesn't care, they are bytes to them)".
Na Windowsih so imena datotek v resnici UCS-2 znaki, in sam sistem tudi briga, če gre za veljavne UTF16 sekvence - edina razlika glede na Linux je, da so znaki 16-bitni, namesto 8-bitni.
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

MrStein ::

Ne, NTFS (in FAT in Joliet, torej praktično vsi MS fajl sistemi) uporabljata prav Unicode (ali UCS), v smislu, da je recimo "Š" zapisan od Unicode koda za "Š" (lahko tudi S+kljukica, kot dve kodi).
To se potem po potrebi pretvori v kaki legacy 8-bitni encoding, za posamezno aplikacijo, odvisno od nastavitev (non-Unicode applications).

V Linux pa je zaporedje bajtov.
Aplikacija jo lahko interpretira kot UTF-8, UTF-17, EBCDIC ali karkoli.

Torej delno je razlika res 16-vs-8 bitov, ampak dodatno je na tistih še predpisano, da so UTF-16 (pa čeprav driver ne preverja veljavnosti).

PS: Torej "a" bo na MS vedno koda 97 (decimalno), na Linux pa lahko 97, lahko 129, ali karkoli.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

Mavrik ::

ender je izjavil:

UTF-32 ti ne pomaga nič, ker je lahko vsaka črka sestavljena iz večih znakov (del Unicode standarda so že od začetka kombinirane označevalne oznake)..


Normalizirani UTF-32 ti zagotavlja, da paše vsak znak v `char32_t`. Je pa res da moraš na vhodu vse zelo jasno normalizirati v t.i. "fully composed normal form". Je pa res da je večinoma pametneje uporabljati UTF-8 z ustreznimi knjižnicami. UTF-16 je sranje, ki zaradi privzetosti v jedrih OSov in programskih jezikov povzroča resne probleme.
The truth is rarely pure and never simple.

Zgodovina sprememb…

  • spremenil: Mavrik ()

ender ::

Mavrik je izjavil:

Normalizirani UTF-32 ti zagotavlja, da paše vsak znak v `char32_t`. Je pa res da moraš na vhodu vse zelo jasno normalizirati v t.i. "fully composed normal form".
Problem je, ker ne moreš̹ vseh znakov normalizirat v fully-composed normal form (ki, kolikor vem obstaja predvsem za združljivost s starimi codepagi, in kjer je bil vsaj na začetku namen, da se uporablja decomposed znake).
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

noraguta ::

Ma pa zato mas malo morje kniznic. V kermu nanespaceu obstajajo pa kako je ime funkcije je v 95% trivialen problem.
Pust' ot pobyedy k pobyedye vyedyot!

user1618 ::

WhiteAngel je izjavil:

HPME je izjavil:

Če Windows in Linux uporabljata Unicode zakaj so imena datotek na ASCII?


ASCII je 7-bitni standard. Če bi Windows in Linux uporabljala le ASCII, potem ne bi mogel imeti šumnikov v imenih datotek. Pa jih imaš.


Heh, pa so bili v lokalizirani ASCII, v času DOS-a in prvih Windows 3:
Kodiranje %C5%A1umnikov @ Wikipedia
"If we were supposed to talk more than listen
we would have been given two mouths and one ear"
- Mark Twain

Mavrik ::

To ni ASCII standard - te kodne tabele so razširitev ASCIIja (ki je posledica tega, da so bili na PCjih znaki s 7 bitov razširjeni na 8 bitov in se je tako dobil prostor še za 128 znakov).
The truth is rarely pure and never simple.

čuhalev ::

Ekola, Gimp (orodje za obdelavo slik) ne more odpreti jpg slike, ki se nahaja v mapi, katere ime vsebuje č. Izpiše, da slike ne najde, pri tem pa izpiše pot do datoteke brez strešic, morala bi pa biti s strehicami.

GTX970 ::

Os ?

MrStein ::

Verjetno Windows. Tam se še vedno najde kar nekaj pred-pred-predzgodovinskih programov (ali knjižnic), ki ne delujejo v Unicode načinu.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

čuhalev ::

Windows, da. Če sliko premaknem na namizje (pot ne vsebuje strešic), lahko odpre.

ender ::

Katera verzija GIMPa? Včasih vem, da je bil problem, samo meni v 2.8.14 odpira ne glede na ime mape in datoteke (sem preizkusil z imenom datoteke, ki ga slo-tech spremeni v vprašaje).
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Zgodovina sprememb…

  • spremenilo: ender ()

čuhalev ::

Imam 2.8.10.

user1618 ::

Mavrik je izjavil:

To ni ASCII standard - te kodne tabele so razširitev ASCIIja (ki je posledica tega, da so bili na PCjih znaki s 7 bitov razširjeni na 8 bitov in se je tako dobil prostor še za 128 znakov).

Ti govoriš o CP852, jaz pa o standardnem 7-bitnem ASCII, ki so mu določene znake npr. [\~ po nekem takratnem YU-standardu za potrebe lokalizacije spremenili v ŠĐč itd. V DOS-u je za to skrbel TSR, videlo pa se je že na promptu C:\> -> C:Đ>. V direktoriju si lahko imel HIŠA.DOC, pravzaprav shranjeno kot HI[A.DOC. Tudi tiskalniki so takrat imeli vgrajeno tabelo za ta standard. Kakšna tajnica iz tistih časov se vsega tega spomni.
Tovrstne gonilnike se je dodajalo še v Windows 3.0, pred izidom Windows 3.1 for Central and Eastern Europe.
"If we were supposed to talk more than listen
we would have been given two mouths and one ear"
- Mark Twain

Zgodovina sprememb…

  • spremenil: user1618 ()

ender ::

Kodna tabela, kjer so bili ~^{[`@}]|\ zamenjani s čČšŠžŽćĆđĐ ni bila ASCII. ASCII je specifično kodiranje, ki obsega 128 znakov (95 natisljivih in 33 kontrolnih), med katerimi ni šumnikov.
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

johnnyyy ::

user1618 je izjavil:

Ti govoriš o CP852, jaz pa o standardnem 7-bitnem ASCII, ki so mu določene znake npr. [\~ po nekem takratnem YU-standardu za potrebe lokalizacije spremenili v ŠĐč itd.

Ta standard ni bil ASCII ampak YUSCII. Je pa res da so nekatere črke zamenjali tako v kodni tabeli, kot v imenu standarda :).


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

[php] encoding niza

Oddelek: Izdelava spletišč
173635 (1550) BivšiUser2
»

Unicode 8.0.0 prinaša več kot sedem tisoč novih znakov

Oddelek: Novice / Ostala programska oprema
3834199 (28678) johnnyyy
»

Novi Unicode 7.0 prinaša tudi nerazvozlane pisave

Oddelek: Novice / Ostale najave
95594 (4022) ender
»

Byte-Order Mark found in UTF-8 File.

Oddelek: Izdelava spletišč
51046 (1011) krho
»

Varnostna luknja v večini brskalnikov (strani: 1 2 3 )

Oddelek: Novice / Varnost
10112950 (10157) Trinitron

Več podobnih tem