LINUX.ORG.RU
ФорумTalks

КОИ32

 , ,


1

1

Внезапно подумалось, что было бы очень хорошо если бы кто-нибудь взялся разработать отечественный аналог UTF-32 под названием КОИ32. Тогда бы можно было убрать модификаторы, и получить абсолютно правильную кодировку, в которой каждый символ всегда ровно 4 байта.

Полезная бы получилась кодировка.

★★★★★
Ответ на: комментарий от Evgueni

Во-первых, в KOI8-R всё хорошо сбалансировано, включая псевдографику. В других однобайтных кодировках псевдографика урезана. Во-вторых, в последнее время KOI8-R удобнее именно юникодных кодировок по описанным выше причинам:

А одинаковый вес символов в байтах и отсутствие модификаторов - это именно удобства.

Эти же удобства можно ввести и в новой кодировке с большим количеством символов.

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

Следует отметить, что в koi8-r нет символа № и ёлочек, что для кириллических текстов гораздо важнее, чем псевдографика, отсюда всякого рода фиксы в виде koi8-ru. Иными словами, утверждение, что koi8-r божественна в своей идеальной неизменности не верно.

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

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 4)
Ответ на: комментарий от saahriktu

В однобайтных кодировках можно же.

Никому не нужны однобайтовые кодировки.

можно создать свою новую кодировку

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

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

Никому не нужны однобайтовые кодировки.

К сожалению есть программы, которые считают, что всё ASCII. Они потихоньку вымирают, но ещё пока это полностью не приключилось.

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

Нет. Такое пишется в подавляющем своём большинстве англоязычными пользователями. Их тупо больше, чем ТС и Эдика.

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 1)

надо еще запилить ее в гипертекстовой фидонет - и тогда заживем!

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

Во первых, скажем мягко, экспериментаторы встречаются всегда и везде и «программу на Fortran» ты можешь написать на абсолютно любом языке программирования.

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

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

в koi8-r нет символа № и ёлочек

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

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

Гораздому большему числу людей (вы ведь за людей радеете?), чем псевдографика. Я вас уверяю. Так же, даже в koi8-ru нет символа длинного тире: — (сравните с -)

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 1)
Ответ на: комментарий от Shaman007

Грант на разработку кодировки специально для чебурнета. Только православные русские буквы и псевдографика. Добро пожаловать в 2049.

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от saahriktu

наравне с KOI8-R.

Наравне с KOI8-R в этом веке создать уже ничего нельзя. Это надо мертвородить археологическую ценность, ты как себе это представляешь?

t184256 ★★★★★
()

КОИ32

Клуб Отпетых Извращенцев впал в маразм и теперь хочет все то, что хаял, причем вдвойне.

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

С тех пор я при подтверждении читаю и исходники тоже.

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

Обычно, кажется, что ты серьёзно, но ты — троллюга, переодически себя выдаёшь.

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

Для остальных подойдет и UTF-8, ведь можно просто не использовать возможности, которые в данный момент не нужны, не так ли?

И вообще, мне стало интересно: что ж это за мегаудобство такое, чтоб ради него терпеть очередную волну геморроя с совместимостью?

segfault ★★★★★
()

Насколько я помню, КОИ это банальный костыль, чтобы при NEPRAWILXNOJ KODIROWKE MOVNO BYLO HOTX KAK-TO PRO^ESTX TEKST. Что там вообще может быть хорошего? Или сама аббревиатура возбуждает?

отечественный аналог UTF-32

Любит отчизна аналоги того, что там не взлетело. Так что может и будет, вот как раз чебурнет строят.

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

ведь можно просто не использовать возможности, которые в данный момент не нужны, не так ли?

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

Если софтина работает с текстами в той кодировке, в которой есть модификаторы, то кто-нибудь может скормить этой софтине тексты, в которых есть модификаторы. И что тогда? Тогда окажется, что софтина не поддерживает ту кодировку, с которой работает, на 100%.

А для того, чтобы поддерживать кодировки без модификаторов на 100%, совершенно не нужно что-то дополнительно делать. В этом случае всё всегда просто работает. Ведь, если в кодировке, с которой работает софтина, нет модификаторов, то никто и никогда не сможет скормить ей тексты с модификаторами. В этом и суть.

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

Что там вообще может быть хорошего?

KOI8-R - это хорошая стандартная рабочая юниксовая кодировка. В ней всё хорошо.

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

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

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

Так вопрос в решении других задач. Например, в простом и лёгком выделении подстроки с 4-го символа по 17-й без предварительного парсинга.

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

Так вопрос в решении других задач. Например, в простом и лёгком выделении подстроки с 4-го символа по 17-й без предварительного парсинга.

Я так понимаю, это все в контексте пользовательского ввода. А это столь редкие ивенты, что можно и распарсить, и срендерить пару лишних раз.

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

Это в контексте разбора текста. В т.ч. и из файлов.

А для разбора прямо из файловых потоков в UTF-8 и так уже есть libfatchars. Но это всё жруче и медленно. Гораздо быстрее и лучше когда и так заранее известны где какого символа байты.

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

А зачем оно может быть нужно? Всякий парсинг XML/JSON, импорт/экпорт БД происходит в чистом ASCII, где строчки текста идут либо в HEX-е, либо тупо UTF-8, который не парсится, а тупо грузится as is.

Для всяких специфических применений, типа лексического/статистического анализа целых библиотек, можно и предварительно сконвертировать тексты в удобную кодировку.

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

либо тупо UTF-8, который не парсится

Так это оно пока в UTF-8. А я предложил в этой теме, чтобы оно было в КОИ32. Не просто же для галочки я эту кодировку предложил, а чтобы её практически применять. Вместо UTF-8.

Вот тогда и будет проще манипулировать такими текстами.

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

Так это оно пока в UTF-8. А я предложил в этой теме, чтобы оно было в КОИ32.

Двумя абзацами выше вы жаловались, что разбор UTF-8 шибко медленный. Я примерно прикинул объемы текстов, при котором это станет проблемой. Так вот - в 4-байтной кодировке эти же тексты будут жрать в 2-3 раза больше памяти, и это тоже будет серьезной проблемой.

Если уже стоит задача работать с килотоннами текста, то надо использовать однобайтовые кодировки под каждый язык. Это будет и быстро, и компактно.

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

Вот тогда и будет проще манипулировать такими текстами.

Всякие memcpy/memchr работают как раз с однобайтовыми блоками, характерными как раз для ASCII, UFT-8 и т.п. Что может быть еще проще?

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