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

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

Исходя из условия saahriktu, взять произвольный старт и нужную длину, не узнавая их с помощью чего-то постороннего; да и просто как PoC.

P.S. KOI8 is dead.

P.P.S. в рабочем «дистрибутиве» illumos с огромным удовольствием выпилил все однобайтные локали, как полное «ненужно».

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

Немного говнокода для текущей локали, заданной через setlocale().

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

PS. Нормальным решение для C/C++ является wchar, который жрёт по 4 байта на каждый символ. В 2 раза больше чем юникодные строки в Паскале.

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

В 2 раза больше чем юникодные строки в Паскале.

Это которые UTF-16? UTF-16 - это вообще то тоже кодировка с переменным числом байт на символ, ибо есть surrogate pairs. Даже в UTF-32 символ может состоять из нескольких wchar_t в случае композитных символов и лигатур.

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

Да. И поэтому, насколько я понял, юникод на 100% не поддерживает никто и никогда. В отличие от однобайтных кодировок, которые всегда поддерживаются на 100%. Тем не менее, большинству людей вполне хватает и такой поддержки юникода. И они так и считают, что лучше поддержка юникода менее чем на 100%, чем однобайтных кодировок, но на 100%.

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

Конечно лучше, у меня (не)детская травма от зоопарка в начале 00х, когда файлы с именами в разных кодировках были (koi8-r, cp1251, или еще лучше какие-то иероглифы в euc), и особенно тэги в mp3. Как узнал про utf-8, так и стал только её использовать (2005? 2006?), с тех пор почти всё стало уже адекватно поддерживать.

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

И они так и считают, что лучше поддержка юникода менее чем на 100%, чем однобайтных кодировок, но на 100%.

Я так тоже считаю. Юникод позволяет хранить все языки в одном формате и забыть про кодировки. Поддерживать можно только то, что нужно. Я живу в Японии и использую японский язык. В однобайтовую кодировку он физически не влезает. Поддержка юникода в основном состоит в отрисовке текста и определения позиции и размера компонентов строки. Это уже реализовано в библиотеках.

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

Для этого есть логи.

…которые могли не записаться из-за разных причин (диск вышел из строя, дисковый кеш не записался, и т.д.).

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

Тогда у юзера гораздо более серьёзные проблемы чем чтение логов.

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

Не перестала. Как работала, так и прекрасно работает. Убрали программный буфер, так что да, все полтора владельца ISA видяшек пострадали, придётся им обновить своё видео 1990го на железо 1995 года.

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

Хитрый какой. Выполни

#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 Вася Пупкин", 12, 8);
  printf("\"%s\"\n", buf);
  return 0;
}

http://cpp.sh/84pxp

"�ася "
Psilocybe ★★★★
()
Последнее исправление: Psilocybe (всего исправлений: 1)
Ответ на: комментарий от Psilocybe

Вся хитрость в:

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

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

Если объявляется ф-ция типа работающая с UTF-8, то она должна корректно обрабатывать все свои входные данные.

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

Если обрезать UTF-8 посередине логических символов, ничего страшного не произойдёт. В UTF-8 предусмотрена обработка некорректных последовательностей. От "�ася " браузер не падает.

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

Это типа мастер-класс? Если программа не падает, то все нормально, можно сдавать клиенту. Ясно , понятно.

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