В UTF-8 буквы кириллицы занимают по два байта, в то время как латинские — по одному. Это во-первых несправедливо, а во-вторых неоптимально для большинства текстов использующих кириллицу. По-моему есть смысл в наличии кодировки в которой кириллица требовала бы меньше места, почему же такой кодировки до сих пор нет?
Здравствуйте, igna, Вы писали:
I>В UTF-8 буквы кириллицы занимают по два байта, в то время как латинские — по одному. Это во-первых несправедливо, а во-вторых неоптимально для большинства текстов использующих кириллицу. По-моему есть смысл в наличии кодировки в которой кириллица требовала бы меньше места, почему же такой кодировки до сих пор нет?
Здравствуйте, igna, Вы писали:
I>В UTF-8 буквы кириллицы занимают по два байта, в то время как латинские — по одному. Это во-первых несправедливо, а во-вторых неоптимально для большинства текстов использующих кириллицу. По-моему есть смысл в наличии кодировки в которой кириллица требовала бы меньше места, почему же такой кодировки до сих пор нет?
Ну, во-первых, формально utf-8 это не кодировка, а Unicode transformation format.
Вам в принципе ничто не мешает придумать свой transformation format для своего применения. Вопрос только, насколько это будет эффективно в каком случае, переносимо, какая часть сообщества разработчиков поддержит... мне что-то кажется, что даже при наличии общедоступной библиотеки большинство не захотят этим заморачиваться. Всё-таки пока что Unicode со стандартными форматами вполне удовлетворяет граничным условиям на подход типа "безобразно, но единообразно".
Здравствуйте, igna, Вы писали:
I>В UTF-8 буквы кириллицы занимают по два байта, в то время как латинские — по одному.
Утешься тем, что некоторые пользуют до 4х байт на символ.
I>Это во-первых несправедливо, а во-вторых неоптимально для большинства текстов использующих кириллицу.
Используй не-юникодные кодировки.
I>По-моему есть смысл в наличии кодировки в которой кириллица требовала бы меньше места, почему же такой кодировки до сих пор нет?
Хорошо. Представь, что китайцы захотели того же. И корейцы с японцами тоже. И что это будет? Обратно к куче не-юникодных кодировок? Спасибо тебе огромное.
...Впрочем, в твоей идее есть рациональное зерно. Имело бы смысл заиметь кодировки типа: "UTF-mostly-2bit" или "UTF-mostly-4bit", в которых кодпойнты совпадающие с "предпочтительным" размером кодировались бы коротко, а остальные наоборот...
Но, в свете того, что нынче и трафик и дисковое пространство дешевое, и дальше дешевеет, заниматься таким "выковыриванием гнид" (nitpicking) всерьез никто не станет. То есть, идея твоя несколько запоздала. Если бы ты ее выродил хотя бы лет 10 назад — попал бы ты в историю инернетов.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, igna, Вы писали:
I>В UTF-8 буквы кириллицы занимают по два байта, в то время как латинские — по одному. Это во-первых несправедливо, а во-вторых неоптимально для большинства текстов использующих кириллицу. По-моему есть смысл в наличии кодировки в которой кириллица требовала бы меньше места, почему же такой кодировки до сих пор нет?
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA> Но, в свете того, что нынче и трафик и дисковое пространство дешевое
Мобильный трафик не так уж дешев, а учитывая рост количества мобильных девайсов (и я говорю не только о телефонах), забота о его уменьшении довольно актуальна. Хотя тут никакой проблемы нет. Скажем, если у тебя обмен с сервисом идет в XML, то просто кодируешь все в cp1251 (кириллица и латиница однобайтовые), а все что за рамками cp1251 ескейпится согласно спеке (аналогично и для HTML).
Здравствуйте, hattab, Вы писали:
H>Мобильный трафик не так уж дешев, а учитывая рост количества мобильных девайсов (и я говорю не только о телефонах), забота о его уменьшении довольно актуальна.
Сжимающие прокси тебе в помощь. Например, Opera Turbo.
Впрочем, я от них отказался т.к. некоторые сайты (например этот) в турбо-опере не работают. Уж не знаю почему.
А моего пакета мобильного трафика и так хватает, не знаю как вам. И обходится он дешево — примерно 0.3% от зарплаты.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA> H>Мобильный трафик не так уж дешев, а учитывая рост количества мобильных девайсов (и я говорю не только о телефонах), забота о его уменьшении довольно актуальна.
DEA> Сжимающие прокси тебе в помощь. Например, Opera Turbo.
Спасибо, не нужно. Gzip решает. Но cp1251 сжато будет все равно лучше, чем UTF-8.
DEA> Впрочем, я от них отказался т.к. некоторые сайты (например этот) в турбо-опере не работают. Уж не знаю почему. DEA> А моего пакета мобильного трафика и так хватает, не знаю как вам. И обходится он дешево — примерно 0.3% от зарплаты.
У меня вообще безлимит, но на 3G-модеме, а на телефоне он мне нафиг не нужен — платить за него, но юзать инет через телефон иногда приходится. Вообще, какая проблема с кодированием? Не все ли равно во что кодировать в cp1251 или в UTF-8, сам факт кодирования то никто не отменил, а на 1251 профит по объему, так почему нет?
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Используй не-юникодные кодировки. DEA>Хорошо. Представь, что китайцы захотели того же. И корейцы с японцами тоже. И что это будет? Обратно к куче не-юникодных кодировок?
Ты сам себе противоречишь то предлагая использовать неюникодную кодировку, то сетуя по поводу неюникодных кодировок. Речь-то о (несуществующей) юникодной кодировке с однобайтной кириллицей. И да, я забыл повторить слово Unicode в тексте, но оно есть в названии темы.
Здравствуйте, hattab, Вы писали:
H>... если у тебя обмен с сервисом идет в XML, то просто кодируешь все в cp1251 (кириллица и латиница однобайтовые), а все что за рамками cp1251 ескейпится согласно спеке ...
Здравствуйте, igna, Вы писали:
i> H>... если у тебя обмен с сервисом идет в XML, то просто кодируешь все в cp1251 (кириллица и латиница однобайтовые), а все что за рамками cp1251 ескейпится согласно спеке ...
i> "Спеке" это что?
Спека — спецификация. В общем, XML и HTML позволяют эскейпить любой unicode codepoint (допустимый для этих форматов). Скажем, русская "А" может быть представлена в виде А (десятичная форма) или А (шестнадцатеричная форма). Сам документ при этом может быть, например, в ASCII кодировке.
Здравствуйте, hattab, Вы писали:
H>Спека — спецификация. В общем, XML и HTML позволяют эскейпить любой unicode codepoint (допустимый для этих форматов). Скажем, русская "А" может быть представлена в виде А (десятичная форма) или А (шестнадцатеричная форма). Сам документ при этом может быть, например, в ASCII кодировке.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>>Используй не-юникодные кодировки. DEA>>Хорошо. Представь, что китайцы захотели того же. И корейцы с японцами тоже. И что это будет? Обратно к куче не-юникодных кодировок?
I>Ты сам себе противоречишь то предлагая использовать неюникодную кодировку, то сетуя по поводу неюникодных кодировок. Речь-то о (несуществующей) юникодной кодировке с однобайтной кириллицей.
Я неудачно выразился.
Кодировки — юникодные, но их много и каждая "мастурбирует по-своему", чтобы закодировать покороче свой любимый диапазон кодпойнтов.
В итоге, снова мы окажемся с зоопарком несовместимых кодировок, как это было в до-юникодную эру.
Так понятнее?
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, igna, Вы писали:
i> H>Спека — спецификация. В общем, XML и HTML позволяют эскейпить любой unicode codepoint (допустимый для этих форматов). Скажем, русская "А" может быть представлена в виде А (десятичная форма) или А (шестнадцатеричная форма). Сам документ при этом может быть, например, в ASCII кодировке.
i> Ну и никаких UTF-8 тогда тоже не нужно.
Так ведь XML'ом и HTML'ом дело не ограничивается, есть еще и plaint text. Да и юникод-кодировки просто более универсальны, вполне может быть так, что у какого нибудь китайского клиента не будет установлена cp1251 на машине (хотя, что китайскому клиенту делать на русско-ориентированном сервисе), следовательно он обломается с таким сервисом работать (хотя если сервис адекватный и воспринимает Accept-Encodings, то и этот вопрос решается)
Здравствуйте, hattab, Вы писали:
H>Ну как сказать... На plain text, вроде, никто свои сервисы не строит, а для хранения юникод-кодировки вполне себе приемлемы
А, ну то есть нет проблемы. И UTF-8 в данном случае не нужен.
Здравствуйте, igna, Вы писали:
i> H>Ну как сказать... На plain text, вроде, никто свои сервисы не строит, а для хранения юникод-кодировки вполне себе приемлемы
i> А, ну то есть нет проблемы. И UTF-8 в данном случае не нужен.
Однозначно сказать нельзя. Я же говорил, что у некого клиента, cp1251 может отсутствовать в системе, а вот UTF-8 он сможет понять в любом случае т.к. это требование спецификации. Ну а сервис должен ориентироваться на Accept-Encodings и в случае отсутствия у клиента предпочтительной кодировки отдавать контент в UTF-8.
On 18.01.2011 20:07, igna wrote:
> В UTF-8 буквы кириллицы занимают по два байта, в то время как латинские — по > одному. Это во-первых несправедливо, а во-вторых неоптимально для большинства > текстов использующих кириллицу.
О, как жетока злая судьба!
И куда же смотрели создатели Unicode?
Здравствуйте, hattab, Вы писали:
H>Однозначно сказать нельзя. Я же говорил, что у некого клиента, cp1251 может отсутствовать в системе, а вот UTF-8 он сможет понять в любом случае т.к. это требование спецификации. Ну а сервис должен ориентироваться на Accept-Encodings и в случае отсутствия у клиента предпочтительной кодировки отдавать контент в UTF-8.
Ну а зачем здесь UTF-8, если можно использовать более простую UTF-32/UCS-4?
Здравствуйте, igna, Вы писали:
i> H>Однозначно сказать нельзя. Я же говорил, что у некого клиента, cp1251 может отсутствовать в системе, а вот UTF-8 он сможет понять в любом случае т.к. это требование спецификации. Ну а сервис должен ориентироваться на Accept-Encodings и в случае отсутствия у клиента предпочтительной кодировки отдавать контент в UTF-8.
i> Ну а зачем здесь UTF-8, если можно использовать более простую UTF-32/UCS-4?
В основном для экономии на тегах и ASCII-контенте (скажем, бинарные данные в base64) , в UTF-8 они будут состоять из однобайтовых "символов", а в UTF-16 из двухбайтовых. Про UTF-32 вообще молчу , более того, XML парсер не обязан ее поддерживать в отличии от первых двух.
Здравствуйте, igna, Вы писали:
I>В UTF-8 буквы кириллицы занимают по два байта, в то время как латинские — по одному. Это во-первых несправедливо, а во-вторых неоптимально для большинства текстов использующих кириллицу. По-моему есть смысл в наличии кодировки в которой кириллица требовала бы меньше места, почему же такой кодировки до сих пор нет?
Потому что компы делают и развивают не в России.
А еще на клавиатуре недостаточно клавиш для русского алфавита, в результате чего знаки препинания в русской раскладке пришлось перенести с привычных мест и сократить их число. Да и сам факт наличия необходимости постоянно переключать раскладки уже как наручники для печатающего.
Но это всё фигня по сравнению с теми, у кого текст пишется не слева направо, или один символ юникода не равняется одному знаку на экране.
Здравствуйте, Кодёнок, Вы писали:
Кё>Потому что компы делают и развивают не в России.
Кё>А еще на клавиатуре недостаточно клавиш для русского алфавита, в результате чего знаки препинания в русской раскладке пришлось перенести с привычных мест и сократить их число. Да и сам факт наличия необходимости постоянно переключать раскладки уже как наручники для печатающего.
Кодировка все же в достаточной степени независима от вышеназванных вещей.
Здравствуйте, igna, Вы писали:
Кё>>А еще на клавиатуре недостаточно клавиш для русского алфавита, в результате чего знаки препинания в русской раскладке пришлось перенести с привычных мест и сократить их число. Да и сам факт наличия необходимости постоянно переключать раскладки уже как наручники для печатающего.
I>Кодировка все же в достаточной степени независима от вышеназванных вещей.
Смысл в том, что причины те же. Никого кроме русских, и то не всех, такие вещи не волнуют вообще. Тебе надо — сделай.
Здравствуйте, igna, Вы писали:
DEA>>В итоге, снова мы окажемся с зоопарком несовместимых кодировок, как это было в до-юникодную эру. I>UTF-8 и UTF-16, к примеру, совместимы?
Разумеется, нет. Алгоритмы разные. То есть:
[строка в UTF-8] --> <алгоритм декодирования UTF-8> --> [строка в UCS-32]
[строка в UTF-16] --> <алгоритм декодирования UTF-16> --> [строка в UCS-32]
А теперь такое:
[строка в UTF-16] --> <алгоритм декодирования UTF-8> --> [а здесь что будет?]
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, igna, Вы писали:
DEA>>Разумеется, нет. I>А ASCII и UTF-8?
...Совместимы только кодпойнты 0-127.
ЗЫ. Сер, лично мне неприятно с вами общаться. Вы придираетесь к словам. Вы не проявляете ну совершенно никакой сообразительности. Вы не предлагаете никаких идей, кроме той, что была выдвинута в начальном сообщении. Подумайте над этим.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, igna, Вы писали:
I>В UTF-8 буквы кириллицы занимают по два байта, в то время как латинские — по одному. Это во-первых несправедливо, а во-вторых неоптимально для большинства текстов использующих кириллицу. По-моему есть смысл в наличии кодировки в которой кириллица требовала бы меньше места, почему же такой кодировки до сих пор нет?
Надо полагать — потому, что недостаточно людей согласны с выделенным.
Стоимость широкого внедрения новой кодировки чудовищно высока.
А для узких применений никто не может запретить реализовать своего потомка System.Encoding, в котором хоть чёрта лысого встроить. Можно, к примеру, захреначить туда Хаффмановское кодирование для предопределённой таблицы частот всех code-points.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Стоимость широкого внедрения новой кодировки чудовищно высока.
Так и не надо ее широко внедрять.
S>А для узких применений никто не может запретить реализовать своего потомка System.Encoding, в котором хоть чёрта лысого встроить.
Верно, только что плохого в том, если большинство этих узких применений будут использовать одну и ту же стандартизированную кодировку?
Здравствуйте, igna, Вы писали:
I>Верно, только что плохого в том, если большинство этих узких применений будут использовать одну и ту же стандартизированную кодировку?
Неверная постановка вопроса. Скорректируем: что хорошего в том, что большинство этих узких применений будут использовать одну и ту же стандартизированную кодировку? Перевешивают ли эти преимущества затраты на стандартизацию кодировки?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Неверная постановка вопроса. Скорректируем: что хорошего в том, что большинство этих узких применений будут использовать одну и ту же стандартизированную кодировку? Перевешивают ли эти преимущества затраты на стандартизацию кодировки?
Ну конечно же. Один раз придумать и десять раз использовать.
Здравствуйте, igna, Вы писали:
I>Ну конечно же. Один раз придумать и десять раз использовать.
Стоимость придумывания близка к нулю. UTF-8 вообще была набросана на салфетке в кафе.
Основные затраты — корректная реализация. Поскольку широкого внедрения единой реализации не предполагается, то эти затраты придётся нести всем.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>...Совместимы только кодпойнты 0-127.
То есть нельзя сказать, что ASCII и UTF-8 совместимы в том смысле, какой вкладываешь в это слово ты? Если так, то в твоем понимании совместимы только идентичные кодировки. Зачем же тогда употреблять термин "совместимость" вместо "идентичность"?
DEA>Вы придираетесь к словам. Вы не проявляете ну совершенно никакой сообразительности.
Ну один раз я проявил сообразительность, на что ты быстренько ответил, что мол "неудачно выразился". Естественно теперь уточняю все непонятное.
Здравствуйте, Sinclair, Вы писали:
S>Основные затраты — корректная реализация. Поскольку широкого внедрения единой реализации не предполагается, то эти затраты придётся нести всем.
Точно так же, один раз корректно реализовать и десять раз использовать. А всем или не всем — по разному бывает. Можно всем по 10%, например. Или это может быть бесплатная университетская реализация.
В UTF-8 не используются последовательности байтов начинающиеся с 10xxxxxx. Определив дополнительно к последовательностям UTF-8 однобайтовые последовательности начинающиеся с 10xxxxxx, получим достаточно места для 64 букв кириллицы. Любой текст в UTF-8 является также текстом в этой новой кодировке. (Так же как любой текст в ASCII является текстом в UTF-8.) Реализацию кодировщиков можно на 97% заимствовать из имеющих для UTF-8.
Ага, спасибо, есть значит все же сyrillic-friendly Unicode encoding. Или по крайней мере нечто, что может быть использовано как сyrillic-friendly Unicode encoding.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, igna, Вы писали:
i>> H>Так ведь XML'ом и HTML'ом дело не ограничивается, есть еще и plaint text.
i>> Ага, значит есть все же проблема.
H>Ну как сказать... На plain text, вроде, никто свои сервисы не строит, а для хранения юникод-кодировки вполне себе приемлемы
Строят некоторые...
Здравствуйте, blackhearted, Вы писали:
b> H>Ну как сказать... На plain text, вроде, никто свои сервисы не строит, а для хранения юникод-кодировки вполне себе приемлемы
b> Строят некоторые...
I>В UTF-8 буквы кириллицы занимают по два байта, в то время как латинские — по одному. Это во-первых несправедливо, а во-вторых неоптимально для большинства текстов использующих кириллицу. По-моему есть смысл в наличии кодировки в которой кириллица требовала бы меньше места, почему же такой кодировки до сих пор нет?
От прочих отличается лишь тем, что не является чарсетом (charset).
