LINUX.ORG.RU
ФорумTalks

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

 


0

0

Изобретаю свою кодировку символов, решил начать с разбора уже созданного: CP1251.gz IBM866.gz ISO-8859-5.gz KOI-8.gz MAC-CYRILLIC.gz

Всего в них 348 символов, при этом только 225 встречаются сразу в 3 файлах и только 191 символ во всех пяти. Это что за избыток? Если бы оптимально подойти, так даже юникод бы был не нужен.

Взял википедию, распарсил (100 метров текста, без html), получил такую статистику:

7930095 -- 32 ( )
3121686 -- 1080 (и)
3047308 -- 10 (newline)
2727631 -- 1072 (а)
2660128 -- 1077 (е)
2507843 -- 1086 (о)
2016752 -- 1090 (т)
1864330 -- 1085 (н)
1801039 -- 1089 (с)
1560947 -- 1088 (р)
1243790 -- 1074 (в)
1157556 -- 1082 (к)
1087145 -- 46 (.)
968049 -- 1076 (д)
967860 -- 111 (o)
918355 -- 1083 (л)
907342 -- 105 (i)
891229 -- 101 (e)
831035 -- 115 (s)
824269 -- 1087 (п)
733941 -- 97 (a)
702895 -- 1103 (я)
685540 -- 1084 (м)
673506 -- 110 (n)
664169 -- 1091 (у)
658174 -- 49 (1)
582796 -- 116 (t)
565215 -- 47 (/)
548710 -- 114 (r)
517877 -- 1099 (ы)
504408 -- 1073 (б)
454062 -- 1079 (з)
452653 -- 48 (0)
416049 -- 1100 (ь)
407703 -- 44 (,)
368651 -- 50 (2)
366363 -- 1075 (г)
352360 -- 1081 (й)
325533 -- 53 (5)
319754 -- 1078 (ж)
318320 -- 99 (c)
315863 -- 1095 (ч)
315031 -- 109 (m)
312899 -- 108 (l)
282834 -- 57 (9)
281910 -- 107 (k)
266933 -- 1094 (ц)
254630 -- 117 (u)
253757 -- 56 (8)
240258 -- 112 (p)
228629 -- 104 (h)
227408 -- 1042 (В)
224604 -- 51 (3)
215619 -- 55 (7)
208874 -- 73 (I)
201042 -- 54 (6)
192741 -- 100 (d)
189071 -- 58 (:)
181948 -- 0 ()
179733 -- 52 (4)
169519 -- 98 (b)
165862 -- 41 ())
163832 -- 40 (()
162130 -- 103 (g)
160669 -- 45 (-)
158650 -- 8212 (—)
157646 -- 1057 (С)
150448 -- 69 (E)
149826 -- 124 (|)
142652 -- 34 (")
140720 -- 1097 (щ)
134240 -- 1055 (П)
129408 -- 102 (f)
127147 -- 119 (w)
124803 -- 1054 (О)
120406 -- 1096 (ш)
118526 -- 83 (S)
117908 -- 70 (F)
117333 -- 1093 (х)
110915 -- 120 (x)
108591 -- 121 (y)
102798 -- 183 (·)
102082 -- 1048 (И)
102043 -- 1102 (ю)
96918 -- 59 (;)
95518 -- 1092 (ф)
92157 -- 42 (*)
91549 -- 1101 (э)
91527 -- 1053 (Н)
90432 -- 65 (A)
86069 -- 1059 (У)
84928 -- 66 (B)
83979 -- 1058 (Т)
80931 -- 84 (T)
77966 -- 118 (v)
74973 -- 68 (D)
72832 -- 82 (R)
72026 -- 1050 (К)
71584 -- 1056 (Р)
70031 -- 77 (M)
68987 -- 76 (L)
67174 -- 64 (@)
62347 -- 78 (N)
60582 -- 80 (P)
60075 -- 1040 (А)
57134 -- 1052 (М)
55951 -- 71 (G)
55103 -- 86 (V)
54232 -- 67 (C)
48727 -- 8226 (•)
48016 -- 1105 (ё)
46030 -- 1060 (Ф)
44632 -- 1069 (Э)
43205 -- 85 (U)
38891 -- 1047 (З)
37864 -- 1041 (Б)
34758 -- 160 ( )
33634 -- 91 ([)
33556 -- 1044 (Д)
33075 -- 93 (])
28855 -- 75 (K)
28664 -- 1043 (Г)
28593 -- 72 (H)
27359 -- 87 (W)
26463 -- 187 (»)
26459 -- 79 (O)
26457 -- 171 («)
26377 -- 1071 (Я)
25550 -- 1045 (Е)
24323 -- 106 (j)
23610 -- 122 (z)
23561 -- 33 (!)
23520 -- 88 (X)
19422 -- 2494 (া)
19010 -- 39 (')
17882 -- 61 (=)
17810 -- 231 (ç)
16799 -- 123 ({)
16721 -- 1051 (Л)
15952 -- 2480 (র)
15028 -- 2366 (ा)
14400 -- 74 (J)
13446 -- 125 (})
13122 -- 8234 ( )
12975 -- 8236 ( )
12562 -- 215 (×)
11964 -- 2495 (ি)
11930 -- 269 (č)
10506 -- 89 (Y)
10149 -- 113 (q)
9994 -- 95 (_)
9228 -- 252 (ü)
9094 -- 63 (?)
9028 -- 1063 (Ч)
8366 -- 126 (~)
8294 -- 1061 (Х)
7309 -- 1098 (ъ)
7213 -- 1064 (Ш)
6998 -- 353 (š)
6755 -- 241 (ñ)
6705 -- 60 (<)
6702 -- 62 (>)
6558 -- 2346 (प)
6157 -- 224 (à)
5734 -- 226 (â)
5723 -- 2344 (न)
5523 -- 234 (ê)
5305 -- 4312 (ი)
5301 -- 229 (å)
5296 -- 4304 (ა)
5236 -- 4325 (ქ)
5059 -- 2349 (भ)
4995 -- 1062 (Ц)
4794 -- 8206 ( )
4636 -- 233 (é)
4355 -- 2352 (र)
4242 -- 1111 (ї)
4012 -- 235 (ë)
3903 -- 90 (Z)
3857 -- 957 (ν)
3850 -- 953 (ι)
3839 -- 940 (ά)
3839 -- 951 (η)
3832 -- 954 (κ)
3829 -- 917 (Ε)
3804 -- 3618 (ย)
3796 -- 3607 (ท)
3795 -- 3652 (ไ)
3670 -- 43 (+)
3413 -- 8209 (‑)
3386 -- 7871 (ế)
3058 -- 371 (ų)
2954 -- 205 (Í)
2900 -- 1070 (Ю)
2844 -- 2350 (म)
2743 -- 1110 (і)
2696 -- 37 (%)
2588 -- 7879 (ệ)
2586 -- 232 (è)
2464 -- 8220 (“)
2458 -- 225 (á)
2412 -- 1046 (Ж)
2349 -- 8221 (”)
1842 -- 242 (ò)
1839 -- 601 (ə)
1477 -- 1377 (ա)
1442 -- 1408 (ր)
1419 -- 1397 (յ)
1413 -- 1344 (Հ)
1407 -- 81 (Q)
1241 -- 1049 (Й)
1171 -- 8470 (№)
1093 -- 38 (&)
1056 -- 8211 (–)
966 -- 8593 (↑)
849 -- 8217 (’)
847 -- 176 (°)
568 -- 228 (ä)
521 -- 3240 (ನ)
486 -- 1067 (Ы)
458 -- 35 (#)
452 -- 237 (í)
418 -- 9658 (►)
418 -- 9668 (◄)
416 -- 8594 (→)
402 -- 8230 (…)
397 -- 279 (ė)
396 -- 381 (Ž)
388 -- 1065 (Щ)
374 -- 8592 (←)
361 -- 248 (ø)
324 -- 1179 (қ)
318 -- 1178 (Қ)
284 -- 244 (ô)
282 -- 1460 (ִ)
278 -- 243 (ó)
276 -- 1025 (Ё)
268 -- 3277 (್)
261 -- 3221 (ಕ)
260 -- 3233 (ಡ)
255 -- 1068 (Ь)
251 -- 227 (ã)
249 -- 2879 (ି)
249 -- 651 (ʋ)
249 -- 2822 (ଆ)
249 -- 2835 (ଓ)
249 -- 2908 (ଡ଼)
245 -- 177 (±)
231 -- 245 (õ)
227 -- 96 (`)
223 -- 250 (ú)
203 -- 8224 (†)

Тут есть все нужное, включая «ёлочки», длинные тире "—" и прочие нужные при оформлении текста символы. Даже ế, которое оказывается не такое уж малоиспользуемое. Вопрос: чем думали авторы CP1251 + IBM866 + ISO-8859-5 + KOI-8 + MAC-CYRILLIC? Ведь если бы подойти правильно к делу создания кодировки, то острой необходимости для юникода бы и небыло!

Особенно порадовали баги в i18n, где таблицы символов местами кривые:

<U> /x55 <U0055> LATIN CAPITAL LETTER U
<U:> /x55 <U00DC> LATIN CAPITAL LETTER U WITH DIAERESIS

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

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

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

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

Begemoth ★★★★★
()

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от Begemoth

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

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от Begemoth

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от Begemoth

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

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

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

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

EmStudio
() автор топика
Ответ на: комментарий от DNA_Seq

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

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

EmStudio
() автор топика
Ответ на: комментарий от DNA_Seq

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

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

EmStudio
() автор топика
Ответ на: комментарий от EmStudio

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

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от DNA_Seq

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

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

EmStudio
() автор топика
Ответ на: комментарий от EmStudio

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

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от EmStudio

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от EmStudio

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от DNA_Seq

> Все с вами ясно гражданин пэхепешник, проследуйте в биореактор. Про то что 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.

EmStudio
() автор топика
Ответ на: комментарий от DNA_Seq

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

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

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

EmStudio
() автор топика
Ответ на: комментарий от EmStudio

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

Кому?

Gary ★★★★★
()
Ответ на: комментарий от DNA_Seq

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

unicode != utf-8

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

sergej ★★★★★
()
Ответ на: комментарий от DNA_Seq

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

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

Begemoth ★★★★★
()
Ответ на: комментарий от Gary

> Кому?

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

EmStudio
() автор топика
Ответ на: комментарий от Terrens

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

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

EmStudio
() автор топика
Ответ на: комментарий от DNA_Seq

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

dimon555 ★★★★★
()
Ответ на: комментарий от EmStudio

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

dimon555 ★★★★★
()
Ответ на: комментарий от EmStudio

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

dimon555 ★★★★★
()
Ответ на: комментарий от dimon555

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

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

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

мимо

EmStudio
() автор топика

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

Suigintou ★★★★★
()
Ответ на: комментарий от Suigintou

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

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

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

EmStudio
() автор топика

Вообще, юникод - это конечно хорошая штука, но если верить пакету 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) уже достали...

EmStudio
() автор топика
Ответ на: комментарий от prorok2k

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

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

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

Miguel ★★★★★
()
Ответ на: комментарий от EmStudio

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

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

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

anonymous_incognito ★★★★★
()
Ответ на: комментарий от anonymous_incognito

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

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

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

EmStudio
() автор топика
Ответ на: комментарий от EmStudio

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

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

anonymous_incognito ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.