Premyslim, k cemu to je. Unicode se dost casto koduje UTF-8, tedy napriklad :-), slozeny z jednobajtovych znaku zabere o jeden bajt min, tedy 3 bajty, narozdil od emoji, ktery je kodovany jako 4 bajty. Precte si ho kazdy i bez podpory unicode/utf-8, napise ho na klavesnici kazdy bez krkolomnych n-hmatu na klavesnici...
Nejde jen o to, jak něco vypadá zobrazené. Třeba české znaky s háčky a čárkami také klidně můžete zobrazit tak, že zobrazíte zvlášť jednoduchý znak a zvlášť čárku nebo háček. Ale existují i další způsoby zpracování, než jen "člověk vidí". Může to předčítat hlasová čtečka. Může to zpracovávat počítač. Takže orientovat se jen na zobrazení je špatně, a když s tím máte pracovat různými způsoby, je vždy lepší, když je jeden znak/symbol zapsán i jedním znakem v znakové sadě, než když musíte ten text parsovat a pokoušet se uhodnout, zda ta která kombinace znaků má být jedním symbolem, nebo je to jen náhodou vzniklá kombinace těch správných znaků.
Navíc podle symbolů, které zaujaly ostatní tady v diskusi, bych řekl, že ne pro všechny nové znaky existuje náhradní vyjádření pomocí dvojteček a závorek.
Jenže rozeznávat znak z 4 bytů, je v téměř tak složité, jako rozeznávat znak ze 3 znaků o velikosti 1 byte :-) Konec konců, mnoho zařízení / aplikací to dnes již normálně dělá (telefony, email klienti, IM atd.).
Druhý problém je právě ta hromada variant, kdy k zažitým :-) ;-) se přidávají ještě smajlíky s očima ve tvaru srdíček, stříšek a kdo ví co ještě ....
Na druhou stranu standardizovat není úplně k zahození, protože některé aplikace prostě některé smajlíky interpretují dost odlišně B-) 8-)
Ne, rozeznávat jeden znak složený ze čtyř bajtů je mnohem jednodušší, než rozeznávat 3 znaky složené ze 3 bajtů, a pak celý text procházet ještě jednou a pokoušet se uhodnout, které kombinace znaků vlastně mají představovat jiný znak. Jinak ve skutečných aplikacích to funguje tak, že o načítání UTF-8 z bajtů do znaků se stará nějaká systémová knihovna, a aplikace pracuje až se znaky. Takže jde o to, zda aplikace bude textový řetězec vůbec parsovat a zavádět nějakou speciální strukturu, ve které bude moci reprezentovat jak znaky, tak smajlíky. Nově nic z toho nebude nutné, prostě jenom některé znaky budou reprezentovat smajlíky.
Ale kdepak. UTF-8 je přenosové kódování, které se před každým použitím rozbalí z bajtů do znaků, aby se s ním vůbec dalo pracovat. Takže smajlík je reprezentován jedním 20bitovým číslem stejně jako jakékoli jiné písmeno. Což vzhledem k tomu, že dnešní počítače jsou přinejmenším 32bitové nepředstavuje zásadní výkonostní problém.
Aplikace pak může každý znak vzít a vytisknout samostatně. Proti tomu rozeznávání smajlíků vyžaduje dívat se na budoucí znaky, jestli tento není jen začátkem nějaké sekvence. Nehledě na false positive, třeba při zapisování IPv6 adres. Například takový dokumentační prefix 2001:DB8:: s oblibou ukazuje vysmátý obličej :D.
Je to k tomu, ze vis ze je to jeden znak a pak s nim muzes podle toho nalozit - trebas zajistit spravnou sazbu toho znaku.
Psat nabodenicka s hackama/carkama extra (najdes v mnoha PDF, protoze acrobat to tak dela default) je zas dobry k tomu, ze nemusis resit 150 variant stejnyho pismene a navic, zarizeni ktery neni vybaveny prislusnym fontem, to muze alespon "nejak" zobrazit (stejne jako v cestine nema nikdo problem chapat text bez nabodenicek, to funguje ve vetsine podobnych pripadu).
Mnoho ruznych "rozpoznavani" smailu je spis k zlosti ... kuprikladu sem mockrat narazil na to, ze chces napsat neco na zpusob (188) a kretenska aplikace ti z toho udela (18"smile"