LINUX.ORG.RU
ФорумTalks

В июле этого года исполняется 3^3 лет стандарту KOI8-R

 ,


0

1

Сабж. Именно 3^3 лет назад, в июле 1993-его года, был создан RFC 1489.
За принятие RFC 1489 выступала Society of Unix User Groups (SUUG), поскольку кодировка KOI8-R уже была де-факто стандартом мира Unix на территории бывшего СССР.
Юникод уже существовал и RFC 1489 описывает соответствие кодов символов кодам уже принятого юникодного стандарта ISO 10646 для тех, кому юникод избыточен.
Через некоторое время (в мае 1999-го) и в glibc (версии 2.1.1) поддержка локали KOI8-R была добавлена не отдельной самодостаточной подсистемой, на поддержку которой нужны дополнительные силы и время, а как подмножество юникода (поддержка которого была добавлена только в glibc 2.0.1 (февраль 1997-го)).

Стандарт KOI8-R до RFC 1489 никогда не публиковался, но основан на нескольких опубликованных стандартах: ГОСТ 19768-74 (старый КОИ8), ISO 6937/8 (не зарегистрирован) и вариациях - INIS-cyrillic и ISO 5427.

Стандарт KOI8-U был принят позже - в RFC 2319 в апреле 1998-го года (в апреле было 22 года).

* * *

Ура! Поздравляю KOI8-R'щиков с очередным днём рождения стандарта самой лучшей кодировки!

Праздничная программа: gopher://sdf.org/9/users/saahriktu/filez/var/koi8r3r3.ha

★★★★★

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

Ну то же саахрикту, у него такой юмор.

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

dovecot 1.* еще лет 10 назад вполне себе хранил(не пересылал, слава б-гу) файлы в mUTF-7. Как вспомню - так вздрагивать начинаю.

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

Ты нашёл кого вспомнить. Нет, это были разные. И с Sun-ch я так вживую и не встретился :(

hateyoufeel ★★★★★
()

Всего-то?! Так он вообще смузихлёбский, получается. Не то что ГОСТ 13052-67!

mertvoprog
()
Ответ на: комментарий от YogSagot

Чушь, HTML-страницы могут в сущности. Можно хоть всё не-ASCII сущностями кодировать, и положить болт на кодировку. Весить, конечно, будет в несколько раз больше, но gzip-сжатие это нивелирует ;)

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

Чушь, HTML-страницы могут в сущности

HTML-страницы, конечно, в сущности могут. А вот те кто пишут имейлы - нет, а уж примитивные ранние вэб-интерфейсы догмайловской вэб-почты так и подавно.

YogSagot ★★★
()

Ненужно, стандарт де-факто был CP866

TheAnonymous ★★★★★
()

поскольку кодировка KOI8-R уже была де-факто стандартом мира Unix на территории бывшего СССР

Стандарт KOI8-R до RFC 1489 никогда не публиковался

Стандарт был настолько секретный, что все его использовали даже не читая.

gremlin_the_red ★★★★★
()
Ответ на: комментарий от cvs-255

Там вообще нет строк, есть массивы байт.

В этом и суть. Если есть только массивы байт и в них надо руками отсчитывать байты, то проще всего когда все символы занимают в массиве одинаковое кол-во байт. Как, например, в KOI8-R.

А в Паскале есть такой тип данных как строки. И там отсчитыванием символов занимается стандартная библиотека. И не надо ничего отсчитывать руками.

Можно, конечно, и в Си написать библиотеку, которая будет отсчитывать символы. Однако, это будет не так удобно как уже реализовано в Паскале.

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

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

То есть, погоди. Ты хочешь сказать, что KOI8 младше UTF8? Зачем его вообще придумали тогда?

Затем, что не всем нужен юникод!

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

не совсем понятно зачем все отображать одним шрифтом. ненужную информацию типа меню удобно шрифтом поменьше, нужно – шрифтом побольше.

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

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

Сколько вас тут осталось?

Сложный вопрос.

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

Где? Я только тут на ЛОРе вижу одного упоротого фанатика. Или вы как посетители фурри бдсм вечеринок в гей-клубах стараетесь на афишировать свои предпочтения?

- Дорогой, где ты был?
- Дорогая, мы с коллегами после работы пошли по пиву выпить.
- Да? А почему тогда от тебя за версту несёт KOI8? Ты что, опять однобайтовый текст через гофер гонял?
- Милая, я могу всё объяснить!
- Не надо ничего объянять! Я думала, ты бросил свои вредные привычки, а ты... Ты... Ты всё ещё однобайтовый! Собирай свои вещи и чтобы духу твоего не было тут больше!
hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от saahriktu

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

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

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

то проще всего когда все символы занимают в массиве одинаковое кол-во байт.

Нет. Надо различать строки и массивы и использовать строковые типы, определенные в отдельных библиотеках

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

использовать строковые типы, определенные в отдельных библиотеках

Это в каких библиотеках?

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

можно увеличить масштаб страницы.

Можно. Однако, тогда крупные шрифты станут ещё крупнее. И вообще всё станет слишком крупным.

Впрочем, не всегда тексты наползают друг на друга, да.

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

Не все люди сидят на ЛОРе. Например, те же Antonio Diaz Diaz и Джордж Р. Р. Мартин не сидят на ЛОРе.

Многое зависит от задач юзеров. Чтобы, например, писать тот же код в ASCII никакой юникод ни разу не нужен.

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

Нет. У разных юзеров разные задачи. А выбираемые юзерами инструменты зависят от их задач.

saahriktu ★★★★★
() автор топика
23 октября 2020 г.
Ответ на: комментарий от hateyoufeel

А почему тогда от тебя за версту несёт KOI8? Ты что, опять однобайтовый текст через гофер гонял?

В квотезы.

hobbit ★★★★★
()

А когда у товарища Брежнева день рожденья?

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

В vCard 4.0 уже постулировали обязательность UTF8, вот только 4.0 используется чуть более, чем нигде, за исключением экспорта-импорта в облаках (google contacts & nextcloud). А в андроидфонах от того же гугля 2.1 и иногда в виде особой милости 3.0.

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

для других письменностей, отличных от кириллицы.

Это для защиты их культурной уникальности! Выйдет чукча в интернет, насмотрится аниме и вся дайвёрсити моржу под хвост.

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

Это для юникода Си (по крайней мере, классической его части) уже маловато будет. В Си поддержка юникода реализована через прикрученные сбоку костыли.

Для UTF-8 никакая специальная поддержка не нужна. Можно работать также как и с ASCII.

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

но продолжает быть актуальной именно KOI8-R

Какая ещё актуальность? Это уже более 20 лет не актуально. Везде UTF-8.

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

Какая ещё актуальность?

У юзеров однобайтных кодировок. glibc, ruby, perl 5,... и т.д. продолжают поддерживать KOI8-R.

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

В этом и суть. Если есть только массивы байт и в них надо руками отсчитывать байты, то проще всего когда все символы занимают в массиве одинаковое кол-во байт. Как, например, в KOI8-R.

Зачем вам понадобилось обращение к отдельным символам? Тем более с символами не всё так просто: есть глифы состоящие из нескольких логических символов, есть лигатуры, есть смешанный текст слева направо и справа налево и т.д..

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

glibc, ruby, perl 5,… и т.д. продолжают поддерживать KOI8-R.

От добавления ещё одной таблицы соответствия с юникодом никому хуже не станет.

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

Для выделения подстрок же. Ещё в Бейсиках и Паскалях была и есть функция

SUBSTR(string, start, length)

Поскольку там есть строки как строки. А в Си вместо строк просто массивы байтов.

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

Для выделения подстрок же.

Зачем? И для UTF-8 это тоже работает.

Держите:

void Substring(char *dst, const char *src, size_t beg, size_t len)
{
	memcpy(dst, src + beg, len);
	dst[len] = '\0';
}
X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от mertvoprog

Ну contacts.google.com, положим, это не совсем теория. Прикол в том, что он вообще экспортирует несколько другой vcf, чем телефон с андроидом, с которым синхронизируется. В частности, группы (CATEGORIES) при экспорте с облака означают то же, что у нормальных людей (FAMILY, FRIENDS, WORK и др.), а при экспорте через файл с телефона забиты служебной хренью вроде CATEGORIES:System Group: My Contacts.

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

Юзкейсы выделения подстрок бывают самыми разными.

И для UTF-8 это тоже работает. Держите

Каким это образом? Эта процедура просто копирует len байт, что корректно только для однобайтной кодировки.

Если у меня, например, строка «My name is Вася Пупкин», то эта самая Substring(subname, str1, 11, 4); вернёт только «Ва», а не «Вася».

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

Согласен что для UTF-8 пример выше не работает, но написать совершенно не сложно.

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

Юзкейсы выделения подстрок бывают самыми разными.

Пример хоть одного в студию.

то эта самая Substring(subname, str1, 11, 4); вернёт только «Ва», а не «Вася».

You are doing it wrong:

#include <stdio.h>
#include <string.h>

void Substring(char *dst, const char *src, size_t beg, size_t len)
{
	memcpy(dst, src + beg, len);
	dst[len] = '\0';
}

int main(void) {
  char buf[256];
  Substring(buf, "My name is Вася Пупкин", 11, 8);
  printf("\"%s\"\n", buf);
  return 0;
}

Output:

"Вася"

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

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

Пример хоть одного в студию.

Например, для проверки есть ли в начале или конце строки соответствующая подстрока. Если бы это никому не было бы нужно, то в том же Python'е не было бы тех же .startswith() и .endswith().

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

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

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

Например, для проверки есть ли в начале или конце строки соответствующая подстрока.

Всё это прекрасно работает с UTF-8.

bool BeginWith(const char *src, const char *pat)
{
	size_t i;
	i = 0;
	while (src[i] != '\0' && pat[i] != '\0' && src[i] == pat[i]) i++;
	return pat[i] == '\0';
}

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

Разбивание по пробелам будет нормально работать. А вообще для переносов есть отдельные библиотеки. В общем случае это нетривиальная задача и для некоторых языков требуется разбор грамматики.

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

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

char *
mbsubstr(char *dst, const char *src, int start, int len)
{
        const char *c = src;
        int i, l, slen = 0;

        /* Skip */
        for (i = 0; i < start; i++) {
                l = mblen(c, MB_CUR_MAX);
                if (l < 0)
                        return (NULL);
                c += l;
        }
        /* Find length in bytes */
        for (i = 0; i < len; i++) {
                l = mblen(c + slen, MB_CUR_MAX);
                if (l < 0)
                        return (NULL);
                slen += l;
        }
        (void) memcpy(dst, c, slen);
        dst[slen] = '\0';

        return (dst);
}
xtouqh
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.