Encodings...

Be 4udq se az, ama qwno sym nogo typ, za da se 4udq, no ponej weroqtno sym, se 4udq...

Sled kato na men stranicite mi (stawa wypros za html) sa mi na bylgarski, a sa s UTF-8, kakyw e 6i****q smisyl da polzame CP1251???
Prosto typata mi glawa ne go pobira, sled kato na UTF-8 se 4ete i pi6e normalno!!!????
Prosto neka minem kym UTF-8 i si4ko ok!


Fiat Lux!

Nie dvamata sme minali veche ostava samo oshte niakolko miliona da minat. tova podoziram che shte otneme izvestno vreme.

Просто с UTF-8 буквичките стават два пъти по-големи, съответно - трафикът два пъти по-голям (при това не само за кирилица). Ами, в общи линии това е материалистичната причина.
Има и други - навик, неразбиране (т.е. незнание, че въобще има такова нещо като кодировка), мързел, субективизъм и каквото още се сетиш.

Ej bre tozi trafik. Posrahte se da svalaite mp3 i avi fajlove a sega za tova che edin e-mail ili tekstov dokument shte e dva puti po-goliam gledaj kakuv problem stana, goliam trafik se pravi.

prichinata e che powecheto programi (wkl. redaktori) smiatat che char == 1 byte.

буквичките в който и да е енкодинг, след компресия са еднакво големи, а компресия има във всеки мрежов bottleneck (вж PPP). от друга страна, миграцията никога не е била лесна работа.

Пролетта е дяволски далече............

Ама че изказване. Удома си всеки прави каквото смята за необходимо. Обаче, я си представи една служебна поща... На моята работа всеки ден получаваме около 80-100 писма, които не са просто едно-две изречения. Не е много практично да увеличиш двойно обема на трафика, който правиш от това, не мислиш ли?

не съм се ровил, ама няма ли възможност тялото на SMTP съобщението да бъде смачкано с gzip, примерно? Това ще ти реши проблема с големия трафик... Пък и 100 писма, по 5 страници всяко прави 1 мб на ден... не е кой знае какво...

Ако пък писмата са предимно на latinica, обемът им няма да се промени. Самият Unicode стандарт наистина е двубайтов, но както можеш да видиш тук, UTF-8 е неразличим от ASCII, когато става въпрос за латинската азбука.

Като цяло идеята за UTF-8 кодиране е много добра - имаш на разположение 65535 знака (даже и нек'ви изчезнали езици) - няма да има проблеми със несъвместимост на кодовите таблици. Май че единствените пречки за по-широкото му разпростанение са съществуващите в момента протоколи (представи си само web страница написана с UTF-8 кодиране как се точи по HTTP протокол)

воля, воля... и пак воля...

Ако пък писмата са предимно на latinica, обемът им няма да се промени

нима?

Говоря ти съвсем сериозно. Ако ти е интересно - кажи, ще ти го обясня по-подробно

Добре, може и на бележка, за да не досаждаме на другите, ако не им е интересно. Или на поща - pocu@bk.ru
Макар че това малко ме съмнява, честно казано. Все пак уникод си е уникод, независимо дали пишеш на латиница, кирилица, /каквато/и/да/е/маймуница... Но пък искам да чуя и твоето мнение.

dokolkoto si spomniam utf-8 definira encoding na celia UCS (31 bit characters)
razmera opredeleno ne se uvelichava znachitelno pri izpolzwane na normalnite simvoli -- stranici s kirilica shte uvelichat razmera si s okolo 50% sredno

shtoto wse niakoi niama da e razbral

щото нямам много време. Цитатът е от документа, за който ти дадох link:

0000 0000-0000 007F 0xxxxxxx
0000 0080-0000 07FF 110xxxxx 10xxxxxx
0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx

0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx

Това е представянето на 32-битовото число вляво според UCS-4 (приеми го за нещо като абсолютно пълен Unicode) с променлива дължина байтове. Както се вижда, за латинските символи (ASCII от 0 до 127) е достатъчен един байт. За символите до 7FF - два байта (кирилицата, а и не само тя, е там). За следващите символи - 3, 4 и повече байтове. Принципът е като при най-простите компресиращи алгоритми - колкото по-често се среща едно число, с толкова по-кратка битова последователност го записваме. Така пестим място, щото по-добре 100 пъти * 1 байт и 5 пъти * 3, от колкото 105 пъти по 2 байта.

Има и други причини, освен мястото, да бъде избран този подход. Най-простата, но много полезна е, че ако вземеш UTF-8 кодиран Unicode текст само с латиница, той е еквивалентен на ASCII кодиран същия текст.

За интересуващите се - пак link-а.

Twurdo sum za UTF-8. Tokowa problemi si reshih sled kato minah na nego che ideq si nqmate. UTF-8 super. Naprimer weche ne prawq nikakuw escpaing na user input. Neka pishat kakwoto si iskat - sled obrabotkata ot application servera puham w bazata kakwoto i da e kodirano kato UTF-8 i nqmam nikakwi problemi.
A i mnogo ot nowiq software si bachka po default na UTF-8 - XML parseri, SOAP i t.n.

Не всеки може да си позволи компресия/декомпресия на трафика - един натоварен web сървър подаващ основно динамични страници, например Аltavista, въобще не може да си позволи такъв лукс.

Като видях таблицата с битовете/кодирането, която си постнал почнах да пиша обяснение че това всъщност е вид Хъфманова компресия, blah-blah-blah... само за да видя че си го обяснил малко по-надолу :-) Язък за фермана дето бях го написал. Единственото ми утешение е, че "краткостта е сестра на таланта" както обичаше да казва Борман.

Ок, съгласих се. Е, сигурно пак ще поразпитам, но пък звучи напълно логично. Мерси

za da moje da se mine izcialo na UTF-8 triabwa _wsichko_ w Linux da go polzwa. pomisli si samo za grep, sed, ls, find i oshte hiliadi takiva programi koito triabwa da se promeniat za poddyrjat UTF-8 pravilno. ne vijdam w ramkite na 10 godini towa da stane :(