[вещества] Используемые кодировки кириллицы

> Если бы оптимально подойти, так даже юникод бы был не нужен.

Если оптимизировать для конкретного языка, то надо делать переменную ширину символа (часто используемые символы короче).

> Ведь если бы подойти правильно к делу создания кодировки, то острой необходимости для юникода бы и небыло!

Нет. Юникод - это правильная вещь, т.к. позволяет мешать в одном документе текст на разных языках с разными системами письменности.

И вас это удивляет? То что обычно побеждает наилучшее решение из наихудших давно известная закономерность.

>то надо делать переменную ширину символа

не надо, сильно затрудняет парсинг текста. Ты в курсе что вычисление длины строки в юникоде занимает на порядко-другой больше времени чем у строк с постоянной шириной символов?

А для документа на разных языках достаточно переключения кодовых страниц и это давно уже не является проблемой скажем в браузерах.

> Если оптимизировать для конкретного языка, то надо делать переменную ширину символа (часто используемые символы короче).

Не вижу проблемы: добавляем управляющий символ (место еще есть) и через него записываем расширенный набор символов, или даже другие кодировки, хоть юникод.

> Нет. Юникод - это правильная вещь, т.к. позволяет мешать в одном документе текст на разных языках с разными системами письменности.

Ага, тото я из статистики замучился китайские и японские иероглифы выковыривать (например, статья про японских футболистов на русском языке)

> И вас это удивляет? То что обычно побеждает наилучшее решение из наихудших давно известная закономерность.

Т.е. cp1251, где нет части нужных символов - это лучшее решение?

> не надо, сильно затрудняет парсинг текста. Ты в курсе что вычисление длины строки в юникоде занимает на порядко-другой больше времени чем у строк с постоянной шириной символов?

Затрудняет кому? Для программиста? Я при парсинге использовал только binmode(STDIN,":utf8"); для указания кодировки, дальше обычный length. Для CPU? Дык все зависит от конкретной имплементации, никто не мешает хранить в памяти строки хоть в 32-байтовой кодировке, считать будет аки реактивное. Правда в нормальных языках есть еще что-то вроде ropes, дабы с длинными строками можно было работать без проблем, а тут с подсчетом еще хуже. Жертвовать ли скоростью подсчета во имя скорости при добавлении/удалении символов?

>Т.е. cp1251, где нет части нужных символов - это лучшее решение?

В некоторых условиях лучшее. Или вам в школе не рассказывали про escape-последовательности?

> Или вам в школе не рассказывали про escape-последовательности?

А в вашей школе только про интернеты рассказывают? А то в нашей школе еще decode_entities использовать учат, прежде чем текст из html выводить...

>Затрудняет кому?

на программистов покуй. А вот на ресурсы процессора нет. Натрави grep на десяток гигабайт текста и сравни скорость работы. Даже плоская 16-битная кодировка была бы лучшим решением

Да, ты забыл упомянуть, что с escape-последовательностями сложнее находить длину строки.

Все с вами ясно гражданин пэхепешник, проследуйте в биореактор. Про то что escape-последовательности можно ставить и в плоский текст вы не в курсе.

Они вообще-то включаются в длину строки. И в любом случае это меньше процента текста тогда как длина строки на юникоде может отличатся в два раза

> Все с вами ясно гражданин пэхепешник, проследуйте в биореактор. Про то что escape-последовательности можно ставить и в плоский текст вы не в курсе.

А, вы видимо про управляющие символы, как в юникоде? См.выше, где я написал про возможность переключения хоть на альтернативные кодировки. Хотя в юникоде так сложно считать размер строк...

На всякий случай:

An escape sequence is a series of characters used to change the state of computers and their attached peripheral devices. These are also known as control sequences, reflecting their use in device control. Some control sequences are special characters which always have the same meaning. Escape sequences use an escape character to change the meaning of the characters which follow it. The characters can be interpreted as a command to be executed rather than data.

> И в любом случае это меньше процента текста тогда как длина строки на юникоде может отличатся в два раза

1. Но этого достаточно для переполнения буфера.

2. А почему тогда в cp1251 не включают эти самые эскейп-последовательности?

>Да, ты забыл упомянуть, что с escape-последовательностями сложнее находить длину строки.

Кому?

>> Ты в курсе что вычисление длины строки в юникоде занимает на порядко-другой больше времени чем у строк с постоянной шириной символов?

unicode != utf-8

Есть представления юникода с постоянным размером символов.

> Изобретаю свою кодировку символов

Зачем?

> ы в курсе что вычисление длины строки в юникоде занимает на порядко-другой больше времени чем у строк с постоянной шириной символов?

Будем различать внешнее (в файлах) и внутреннее представление (для быстрой обработки) строк?

> Изобретаю свою кодировку символов

Убить тебя мало. Такие как ты уже столько геморроя создали

> Кому?

Я сам пока не понимаю, но DNA_Seq так говорил...

Я создаю свои, новые интернеты, заменив http на xmpp-подобный протокол. Подробнее: http://www.linux.org.ru/view-message.jsp?msgid=3694019

utf8 уж слишком много трафика кушает, поэтому я перехожу на 1-байтовую кодировку. Увы, все существующие кодировки не имеют каких-то нужных символов, поэтому я изобретаю свою.

>Ты в курсе что вычисление длины строки в юникоде занимает на порядко-другой больше времени чем у строк с постоянной шириной символов?
оно как бы зависит от кодировки, может в UTF-8 и дольше, а если сделать 3 байта ширину символа постоянной, то просто в 3 раза больше места.

>utf8 уж слишком много трафика кушает,
но при этом он использует XML для протокола ;) кира жжот(если это конечно кира)

>utf8 уж слишком много трафика кушает, поэтому я перехожу на 1-байтовую кодировку.
ASCII символы будут занимать 1 байт, если я ничего не путаю

> но при этом он использует XML для протокола

А у меня будет преобразователь xml в tlv, т.е. весь протокол бинарный, трафик маленький, исчезают проблемы с отправкой бинарных данных (изображения, звук, видео). Изначально я хотел использовать AMQP, но оный я ниасилил, а для XMPP у меня уже есть самодельный клиент. Прикрутить к нему свою кодировку + xml2tlv не долго

> кира жжот(если это конечно кира)

мимо

Потом такие кодеры пишут непереносимый и непереводимый софт, который работает только в одной единственной локали и с текстом на одном единственном языке. Фтопку.

> Потом такие кодеры пишут непереносимый и непереводимый софт, который работает только в одной единственной локали и с текстом на одном единственном языке. Фтопку.

А вот представь: ты делаешь большой проект, а тебя увольняют. А через полгода слезно просят вернуться, ибо больше никто это раскурить ниасилил. Разве не красота? Можно диктовать свои условия.

Вообще, 1-байтовая кодировка тоже кушает много места, я вот думаю сделать 7-битную с управляющим символом для переключения в 8-битный режим, а данные читать не по байтам, а как бинарный поток. Так трафик будет еще меньше, а зарплата будет еще больше. Статистика из вики - это прямо кладезь для создания своей кодировки.

Вообще, юникод - это конечно хорошая штука, но если верить пакету i18n...

<U2615>     /x81/x37/xa4/x35 <Not Assigned>

http://www.fileformat.info/info/unicode/char/2615/browsertest.htm - видимо не должен сущестовать

Вот так выглядит нулл в разных локалях:

<U0000>     /x00         <control>
<U0000>     /x00         NUL
<U0000>                      /x00         NULL
<U0000>     /x00         NULL
<U0000>     /x00             NULL
<U0000>     /x00             NULL (NUL)
<U0000>     /x00         NULL (NUL)
<U0000>     /x00     NULL (NUL)
<U0000>         /x00    NULL (NUL)
<U0000>     /x80         ARABIC NULL (NUL)

Как понять, какой юникод-код у символа:

<U=>    /x04/x23        CYRILLIC CAPITAL LETTER U

? Я вижу, что /x04/x23 в локальной кодировке, а в глобальной?


Косяки i18n (glibc) уже достали...

> > Изобретаю свою кодировку символов

> Убить тебя мало. Такие как ты уже столько геморроя создали

Это уж точно. В биореактор.

> utf8 уж слишком много трафика кушает, поэтому я перехожу на 1-байтовую кодировку.

Ты изобретаешь велосипед под названием "уменьшение энтропии источника" или если более понятным языком говорить, "сжатие потока данных", потому что твоя попытка уменьшить траффик за счёт выбора своей кодировки с наиболее часто встречающимися символами это именно и ничто иное как самое настоящее сжатие. Метод Хаффмана в примитивном виде.

Не лучше ли использовать сжатие потока в явном виде, которое кстати и для http поддерживается?

> Не лучше ли использовать сжатие потока в явном виде, которое кстати и для http поддерживается?

гзип сверху никто не отменял.

Более того, мне еще нужен список символов для пререндера, ибо на целевой платформе может нехватать каких-то шрифтов для отображения текстов. Все конечно рендерить глупо, но первые 255 самых используемых символов я спокойно осилю.

Непонятно ради чего ты всё это затеял?

Если ради экономии ресурсов, то их другими методами экономят, а изобретение очередной кодировки символов - не та вещь, которая сейчас может быть нужной. Разве что для каких-то встроенных решений с очень сильно ограниченными ресурсами.