Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, 777777w, Вы писали:
7>>Это есть в Юникоде? BFE>Да.
7>>На фига это нужно? По-моему это противоречит его собственным принципам! BFE>Именно! У них была здравая идея, но они её испоганили. Нет им уважения !
В Unicode более сотни диактитических знаков. Так что идея у них очень даже здравая и расширяемая.
Здравствуйте, 777777w, Вы писали: 7>>Доведение до абсурда обычно используется в тех случаях, когда нечего ответить по существу. 7>С чем вы не согласны? Я утверждаю, что тех, кому требуется UTF-32 — мизерное количество, тысячные доли процента. В ответ на это мне говорят: а тех кого не устраивает ASCII тоже немного, 40%, значит ими тоже можно пренебречь. Это что по-вашему, конструктивное возражение?
По существу вам отвечали — UTF-16/UCS-2 ни в чём не лучше UTF-8, а для UTF-8 разрядность символа почти не имеет значения. Доведение до абсурда — вполне себе конструктивное возражение, попытка показать оппоненту абсурдность его утверждений со стороны.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ytz, Вы писали:
Ytz>>Самый правильный — это utf-8 и utf-32
_>Логично для английской и китайского языка соответственно. А для русского по идее оптимальнее всего как раз utf-16 выходит. Надо объяснять почему? )
Здравствуйте, Mystic, Вы писали: M>Просто идет обсуждение сферического коня в вакууме. Все кодировки, в которых один символ в кодировке = один печатный символ являются восьмибитными.
И даже в них есть непечатные символы. Какой смысл у strlen (кроме размера занимаемой памяти) для строки, содержащей BEL ('\a', 7), BS ('\b', 8), HT ('\t', 9)? 8-битные кодировки в этом отношении не лучше UTF-8.
Здравствуйте, Mystic, Вы писали:
M>>>Ты сам себе вбил принцип "один код на один печатный символ". Увы, при таком подходе даже 32-бит может не хватить --- комбинаторный взрыв. Ибо та же диактитика есть в японском, деванагари. Итого нужно дублировать все кодовые страницы??? BFE>>И что? Нельзя было взять сразу 64-бита? Хотите экономить — используйте UTF-представление! Зачем стандарт — то было поганить ? M>Имхо, он и так неплох. Некоторые задачи обработки символов проще реализовывать в UTF-8, например, расстояние по Левенштейну со специальными весами на каждой паре символов. Опять же, диактитических знаков может быть больше чем 64. Некоторые могут комбинироваться. Нужно придумать логическую схему, как это можно разрулить. А то надо 128 бит уже
Даже если предположить, что каждый(!) живущий на земле изобретёт свой алфавит в 32 буквы и на земле проживает 2 в 33 степени людей и сменится 2 в 26 степени поколений (т.е. стандарт будет существовать более 3 миллионов лет!), то и тогда 64 бит хватит !
Здравствуйте, Mystic, Вы писали:
BFE>>Именно! У них была здравая идея, но они её испоганили. Нет им уважения !
M>В Unicode более сотни диактитических знаков. Так что идея у них очень даже здравая и расширяемая.
Была здравая идея: занумеровать все когда либо использованные людьми знаки. Один символ — одна цифра. Два символа — две цифры. И т.д.... Здравая, разумная идея!
Стандартезёры эти испугались не понятно чего и стали разделять символы на части. Иначе как вредительством я это назвать не могу. Если хочется символ по частям рисовать — возьмите матрицу 32х32 и рисуйте себе по-пиксельно! Как раз 128 бит хватит на всё! И сравнивать удобно и рисовать.
Здравствуйте, B0FEE664, Вы писали: BFE>Даже если предположить, что каждый(!) живущий на земле изобретёт свой алфавит в 32 буквы и на земле проживает 2 в 33 степени людей и сменится 2 в 26 степени поколений (т.е. стандарт будет существовать более 3 миллионов лет!), то и тогда 64 бит хватит !
А кто будет рисовать и распространять шрифты для этих зиллионов символов? Даже без шрифтов, на одну таблицу свойств (строчная буква, прописная, переходы от одной к другой) у вас не хватит дисков.
Здравствуйте, Mystic, Вы писали:
M>Просто идет обсуждение сферического коня в вакууме. Все кодировки, в которых один символ в кодировке = один печатный символ являются восьмибитными. И они устраивают большое число пользователей. Далее, если брать UTC-2, то уже для этой кодировки это условие не выполняется.
Только не UTC (Universal Time Coordinated), а UCS (Unicode Character Set)
Здравствуйте, gegMOPO4, Вы писали:
MOP>Здравствуйте, B0FEE664, Вы писали: BFE>>Даже если предположить, что каждый(!) живущий на земле изобретёт свой алфавит в 32 буквы и на земле проживает 2 в 33 степени людей и сменится 2 в 26 степени поколений (т.е. стандарт будет существовать более 3 миллионов лет!), то и тогда 64 бит хватит !
MOP>А кто будет рисовать и распространять шрифты для этих зиллионов символов? Даже без шрифтов, на одну таблицу свойств (строчная буква, прописная, переходы от одной к другой) у вас не хватит дисков.
Это Mystic'у 128 бит не хватает
Я вот тут подсчитал, что если я буду тратить по секунде на один символ, то мне ста лет не хватит, чтобы только просмотреть все символы, которые можно с помощью 4 байт закодировать
Здравствуйте, Ytz, Вы писали:
Ytz>Неужели чтобы сэкономить аж 2 байта на символ?
Лучше посчитайте не на сколько байт, а во сколько раз. И так же учтите нюансы обработки всего этого (в контекте русского языка естественно).
В общем если говорить о русском (а так же о многих других не латинских и не имеющих систему "слово — знак") языке, то система реализованная в windows выглядит оптимальнее системы linux'a.
Я уже не говорю о той кривизне, которую вы почему то засчитываете за достоинство. Это то что с анси и с юникодными данными там работают одни и те же функции. Проблем для программистов от этого только больше.
Здравствуйте, B0FEE664, Вы писали: BFE>Это Mystic'у 128 бит не хватает
Если отказаться от комбинированных символов — то таки не хватит.
BFE>Я вот тут подсчитал, что если я буду тратить по секунде на один символ, то мне ста лет не хватит, чтобы только просмотреть все символы, которые можно с помощью 4 байт закодировать
Если вы будете тратить по секунде на одно слово, то вам жизни не хватит, чтобы проговорить все слова, которые можно закодировать 64 битами. И кому он нужен, алфавит?
Здравствуйте, gegMOPO4, Вы писали:
MOP>По существу вам отвечали — UTF-16/UCS-2 ни в чём не лучше UTF-8
UCS-2 лучше — у нее фиксированный размер симлова. UTF-8 лучше тем, что она экономит память, на латинских буквах в 2 раза. (Правда, не забывайте, что на китайских символах она больше на 25%). Но при размерах памяти измеряемых гигабайтами экономить ее глупо, для работы же с такими строками придется менять все алгоритмы, да еще появляются отдельные понятия для длины строки в символах и байтах. Таким образом для программирования явно удобнее UCS-2, с ней алгоритмы останутся теми же, меняется лишь char на wchar_t, а UTF-8 лучше использовать там, где критичны объемы информации — например для передачи по сетям.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ytz, Вы писали:
Ytz>>Неужели чтобы сэкономить аж 2 байта на символ? _>Лучше посчитайте не на сколько байт, а во сколько раз. И так же учтите нюансы обработки всего этого (в контекте русского языка естественно). _>В общем если говорить о русском (а так же о многих других не латинских и не имеющих систему "слово — знак") языке, то система реализованная в windows выглядит оптимальнее системы linux'a.
Для русского UTF-8 выгоднее. 2 байта только буквы, управляющие символы и пунктуация — 1 байт (а также разметка в html и проч.).
_>Я уже не говорю о той кривизне, которую вы почему то засчитываете за достоинство. Это то что с анси и с юникодными данными там работают одни и те же функции. Проблем для программистов от этого только больше.
Проблема для программистов, что необходимо продублировать все функции, работающие с текстом — для UCS-2/UTF-16. А поскольку продублировать всё и сразу не выйдет (на забываем основанные на ASCII протоколы и форматы) — бесконечные перекодировки из одного в другое. Посмотрим, как виндовые программисты будут выкручиваться, когда появится третья копия API — для UTF-32.
Здравствуйте, gegMOPO4, Вы писали:
MOP>Для русского UTF-8 выгоднее. 2 байта только буквы, управляющие символы и пунктуация — 1 байт (а также разметка в html и проч.).
Да уж, при типичной памяти 2 Гб экономить 1 байт на каждом знаке препинания — это сильно!
_>>Я уже не говорю о той кривизне, которую вы почему то засчитываете за достоинство. Это то что с анси и с юникодными данными там работают одни и те же функции. Проблем для программистов от этого только больше.
MOP>Проблема для программистов, что необходимо продублировать все функции, работающие с текстом — для UCS-2/UTF-16.
Для UCS-2. UTF-16 — никому не нужный урод, совмещающий только недостатки как UCS-2 так и UTF-8.
Так вот, микрософту это почему-то удалось. Наверное потому, что это совсем неложно — всего лишь заменить char на wchar_t
MOP>А поскольку продублировать всё и сразу не выйдет (на забываем основанные на ASCII протоколы и форматы) — бесконечные перекодировки из одного в другое. Посмотрим, как виндовые программисты будут выкручиваться, когда появится третья копия API — для UTF-32.
Она появится чтобы насолить микрософту? Стандартизаторам не достаточно 4 миллиардов символов?
Здравствуйте, 777777w, Вы писали: 7>Здравствуйте, gegMOPO4, Вы писали: MOP>>По существу вам отвечали — UTF-16/UCS-2 ни в чём не лучше UTF-8 7>UCS-2 лучше — у нее фиксированный размер симлова. UTF-8 лучше тем, что она экономит память, на латинских буквах в 2 раза. (Правда, не забывайте, что на китайских символах она больше на 25%). Но при размерах памяти измеряемых гигабайтами экономить ее глупо, для работы же с такими строками придется менять все алгоритмы, да еще появляются отдельные понятия для длины строки в символах и байтах. Таким образом для программирования явно удобнее UCS-2, с ней алгоритмы останутся теми же, меняется лишь char на wchar_t, а UTF-8 лучше использовать там, где критичны объемы информации — например для передачи по сетям.
Расход памяти — это сущие мелочи. Гораздо хуже, что UCS-2 несовместим с прежними 8-битными интерфейсами. Придётся их дублировать, и для 16 бит. И постоянно перекодировать туда-сюда (потому, что не все интерфейсы сразу обретут близнецов). И есть внешние форматы и протоколы. В текстовый 8-битный протокол UTF-8 без труда засунешь, а с UCS-2 — сломается.
Длина строки в символах не имеет смысла (кроме одного случая — узнать размер необходимой памяти для UTF-32). Символы имеют разную ширину, зависящую от шрифта, есть управляющие символы.
Здравствуйте, gegMOPO4, Вы писали:
BFE>>Это Mystic'у 128 бит не хватает MOP>Если отказаться от комбинированных символов — то таки не хватит.
Если какие-то символы никто никогда не будет использовать, то зачем их кодировать?
BFE>>Я вот тут подсчитал, что если я буду тратить по секунде на один символ, то мне ста лет не хватит, чтобы только просмотреть все символы, которые можно с помощью 4 байт закодировать MOP>Если вы будете тратить по секунде на одно слово, то вам жизни не хватит, чтобы проговорить все слова, которые можно закодировать 64 битами. И кому он нужен, алфавит?
Именно! Именно! 64 бит хватит, чтобы закодировать вообще все слова, а не только все символы.
Не надо пытаться объять необъятное — это никому не нужно. Количество различных символов используемых человечеством — конечно. Вместо того, чтобы занумеровать все известные символы — занимаются изобретением новых. В академических целях — это хорошо. Но тащить такие возможности в практическое применение — это без толку использовать человеческие ресурсы.
Здравствуйте, 777777w, Вы писали: 7>Здравствуйте, gegMOPO4, Вы писали: MOP>>Для русского UTF-8 выгоднее. 2 байта только буквы, управляющие символы и пунктуация — 1 байт (а также разметка в html и проч.). 7>Да уж, при типичной памяти 2 Гб экономить 1 байт на каждом знаке препинания — это сильно!
Это любители 16-битной кодировки беспокоятся о памяти. Впрочем, на скорость обработки текстовых форматов/протоколов это влияет заметно — до двух раз (см. баталии вокруг Питона при переходе с 8-битных строк на 16/32-битные).
_>>>Я уже не говорю о той кривизне, которую вы почему то засчитываете за достоинство. Это то что с анси и с юникодными данными там работают одни и те же функции. Проблем для программистов от этого только больше. MOP>>Проблема для программистов, что необходимо продублировать все функции, работающие с текстом — для UCS-2/UTF-16. 7>Для UCS-2. UTF-16 — никому не нужный урод, совмещающий только недостатки как UCS-2 так и UTF-8. 7>Так вот, микрософту это почему-то удалось. Наверное потому, что это совсем неложно — всего лишь заменить char на wchar_t
Ага, удалось. Конторе с многомиллиардным бюджетом удалось, затратив тысячи человеко-лет, продублировать свой API. Ещё и вынудив сделать это авторов сторонних библиотек. То, что какая-то глупость оказалась возможна, не означает, что она нужна.
MOP>>А поскольку продублировать всё и сразу не выйдет (на забываем основанные на ASCII протоколы и форматы) — бесконечные перекодировки из одного в другое. Посмотрим, как виндовые программисты будут выкручиваться, когда появится третья копия API — для UTF-32.
7>Она появится чтобы насолить микрософту? Стандартизаторам не достаточно 4 миллиардов символов?
Ну может быть, когда дойдёт, что 16 бит для wchar_t — маловато (это фантастика). А может, чтобы насолить программистам. Всё равно ведь меняют процессор, библиотеки, сплошной HTML5. Нагибали мир уже несколько раз — нагнут ещё.
Перекуём баги на фичи!
