Про похороны на примере nap и si

Переводчик может сразу верстать в TeX'е, а там инструменты для однобайтовых кодировок из коробки.

Помянем

Переводчик может сразу верстать в TeX'е

А может и не верстать.

Помянем

Мы собрались здесь чтобы над трупом KOI8-R издеваться, не мешай.

Так и я про неё.

А на место каждого убитого придут ещё.

И съедят тело предыдущего?

Переводчик может сразу верстать

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

И съедят тело предыдущего?

Зомби обычно мозги едят, так что нет.

Зомби обычно мозги едят

Мы про пользователей кои8, где ты там мозги нашёл?

Мы про пользователей кои8, где ты там мозги нашёл?

Так я и говорю что им за свою тушку нечего бояться.

Архитектурно однобайтные кодировки гораздо удобнее.

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

Так за неимением мозгов придётся кушать тушку. Жить-то хочется. Ну, то есть, не жить, конечно, но чего-то хочется, koi8, например, поставить системной кодировкой.

Так за неимением мозгов придётся кушать тушку.

Пользователей KOI8-R соответственно их количеству можно прямо сейчас в красную книгу заносить, так что мозгов вокруг даже для зомбей хватит.

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

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

Как я понял, единственный плюс заключается в том что „не всем нужен юникод”.

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

Пользователей KOI8-R соответственно их количеству можно прямо сейчас в красную книгу заносить

К видам, которые находятся на грани исчезновения, по состоянию на 18 ноября 2016 г. относится 4749 видов, в том числе 2427 видов животных, 4 вида грибов, 2314 видов растений, 4 вида хромистов

4 вида грибов

KOI8, CP866, CP1251, ISO8859-5
Совпадение? Не думаю.

Это не плюс, а аргумент. Один из ряда:

• Зачем прыгать с кодировки на кодировку? А если потом появится ещё какая-нибудь VUG-256, то все с радостью на неё перепрыгнут и переконвертируют свои коллекции текстовых файлов? Не проще ли выбрать кодировку один раз в жизни?
• Экономия системных ресурсов; тексты занимают меньше места на носителях и в оперативке и быстрее обрабатываются;
• Можно продолжать юзать <<main (int argc, char **argv)>>, strncpy, strncmp, printf,... и другие неюникодные функции;
• Можно переместить указатель на подстроку со смещением N символов просто прописав <<strptr + N>> без привлечения лишних сущностей в лице ICU (для отфильтровывания диакритики и других модификаторов);
• В ядерной консоли по-прежнему размер символа может быть не больше чем 32x32 пикселя, а весь шрифт может весить не более чем 64 Кб. Отсюда и проблемы с кол-вом символов более чем 256. На уровне ядра. Поэтому юзерам ядерной консоли без иксов особой разницы нет, и можно продолжать извлекать преимущества KOI8-R.
• И т.д.

Зачем прыгать с кодировки на кодировку?

Действительно, зачем? Есть же юникод, пространства символов которого хватает всем.

переконвертируют свои коллекции текстовых файлов

Зачем?

Не проще ли выбрать кодировку один раз в жизни?

Твои утилиты с названиями из /dev/urandom как бы намекают что нет.

Экономия системных ресурсов; тексты занимают меньше места на носителях и в оперативке и быстрее обрабатываются

Экономия на спичках и статистических погрешностях в жертву удобства не нужна.

Можно продолжать юзать <<main (int argc, char **argv)>>, strncpy, strncmp, printf,... и другие неюникодные функции
Можно переместить указатель на подстроку со смещением N символов просто прописав <<strptr + N>> без привлечения лишних сущностей в лице ICU (для отфильтровывания диакритики и других модификаторов)

А можно не заниматься байтодрочерством и просто делать свою работу.

В ядерной консоли по-прежнему размер символа может быть не больше чем 32x32 пикселя, а весь шрифт может весить не более чем 64 Кб. Отсюда и проблемы с кол-вом символов более чем 256. На уровне ядра. Поэтому юзерам ядерной консоли без иксов особой разницы нет, и можно продолжать извлекать преимущества KOI8-R.

Даже разработчикам ведра пофиг на пользователей KOI8-R.

Можно переместить указатель на подстроку со смещением N символов просто прописав <<strptr + N>>

Сраное гуманистическое общество, которое не считает этого достаточным для расстрела как самого пациента, так и его родителей, воспитавших его в бесчеловечных традициях.

Зачем прыгать с кодировки на кодировку?

Потому что до 2002-2003 с использованием utf8 в линуксе возникали некоторые проблемы. Как только проблемы решились, все с облегчением перепрыгнули на utf8.

А если потом появится ещё какая-нибудь VUG-256

Когда/если она появится, тогда и будем думать. Сейчас я не готов обсуждать строительство противодраконьих укреплений вокруг дома, как-то у нас с драконами напряжёнка в наших широтах, как, собственно, и с VUG-256.

Действительно, зачем? Есть же юникод

Это аргумент относительно тех, кто уже более 10-ти лет юзает локаль KOI8-R. В этом контексте дефолт - KOI8-R. И зачем куда-то ещё прыгать?

Зачем?

Чтобы grep'ать без перекодирования regexp'ов и т.д.

Твои утилиты с названиями из /dev/urandom как бы намекают что нет.
Экономия на спичках и статистических погрешностях

Кому как.

в жертву удобства

Всем удобно разное. У всех разные задачи. Кто-то, может, прямо сейчас на первопне в MS DOS'овском софте без юникода музыку пишет, а про тексты и их обработку никогда и не задумывался.

Даже разработчикам ведра пофиг на пользователей KOI8-R.

Но, они же не выпилили поддержку однобайтных кодировок. Тут скорее можно сказать, что им безразличны ультракрасноглазые юзеры юникода. Вот им действительно непросто ультракрасноглазить без иксов с однобайтными кодировками.

бесчеловечных традициях

Задачи и алгоритмы бывают разные. Вот, например, есть задача вывода текста моношинным шрифтом с форматированием: фиксированной ширины. Как ещё наименьшими усилиями это сделать кроме как через «strptr + N»?

Поясняю подробнее: есть текстовая строка большой длины. Пусть, например, 534907 символов. А вывести её нужно с шириной, например, 80 символов. Строка записана в «char *strptr;».

Дай угадаю, ты сам в качестве «модельного примера» эту задачу решать не собираешься, а собираешься решать задачу «вывести строку в кодировке KOI8-R на ядерную консоль в локали KOI8-R с установленным шрифтом в KOI8-R».

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

Это аргумент относительно тех, кто уже более 10-ти лет юзает локаль KOI8-R. В этом контексте дефолт - KOI8-R. И зачем куда-то ещё прыгать?

Чтобы не пилить всякие костыли и не придумывать им адские, вызывающие сатану имена, например.

Чтобы grep'ать без перекодирования regexp'ов и т.д.

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

Кому как.

Пишешь с калькулятора?

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

Fixed.

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

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

Если рассматривать задачу с текстом в UTF-8, то, наоборот, эту задачу мне задают все те, кто хоронят KOI8-R. Да, мне подсказывали решение через разного рода wchar_t и ICU. Только, вот, каждый символ при этом будет жрать по 4 байта оперативки. Даже ASCII символы. И куча сишного софта написана именно через «char *», включая тот, который приводят в качестве примера сторонники UTF-8. И этому софту либо не нужны такие операции, либо у него свои хитрые парсеры.

А так отформатировать однобайтный текст в ряде случаев можно и вообще посимвольно:

> cat myfmt.c
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv){
        int tbwdth, k = 0;
        char c;
        if(argc < 2){
                puts("usage: myfmt width");
                return 1;
        }
        tbwdth = atoi(argv[1]);
        while ((c = getchar()) != EOF){
                putchar(c);
                k++;
                if (k == tbwdth){
                        putchar('\n');
                        k=0;
                }
        }
        return 0;
}
> echo "cdck (CD/DVD check tools) is a simple console program to verify CD/DVD quality. The known fact is that even if all files on the disc are readable, some sectors having bad timing can easily turn into unreadable ones in the future." | ./myfmt 40
cdck (CD/DVD check tools) is a simple co
nsole program to verify CD/DVD quality.
The known fact is that even if all files
 on the disc are readable, some sectors
having bad timing can easily turn into u
nreadable ones in the future.
>

Зачем форматирование текста? Текст может и не влазить по ширине, поэтому хорошим тоном является, например, join строк в одну, а затем форматирование её по нужной ширине.

Не справился даже в однобайтной кодировке-то... Про управляющие символы слышал, небось?

join строк в одну

Только спасительный ядерный апокалипсис спасёт эту планету.

Не нужно, во всех вменяемых текстовых редакторах

Ваши решения только для того, чтобы сидел человек с кучей GUI софта и клацал мышкой. А мои решения для того, чтобы на другой стороне могли быть скрипты и другие программы.

Только это тоже символы, хоть и управляющие, и они могут обрабатываться скрптами и программами своими способами. Но, если уж делать именно для людей, то всё фиксит пара строк:

> diff -u myfmt.c myfmt2.c
--- myfmt.c     2017-03-10 12:45:38.544762677 +0300
+++ myfmt2.c    2017-03-10 13:09:32.066738517 +0300
@@ -10,6 +10,7 @@
        }
        tbwdth = atoi(argv[1]);
        while ((c = getchar()) != EOF){
+               if (c < 32) continue;
                putchar(c);
                k++;
                if (k == tbwdth){
@@ -17,5 +18,6 @@
                        k=0;
                }
        }
+       putchar('\n');
        return 0;
 }
> xxd test
00000000: 546f 0767 6574 0661 6e20 6964 6561 2061  To.get.an idea a
00000010: 626f 7574 2061 2064 6973 6320 6364 636b  bout a disc cdck
00000020: 2072 6561 6473 0569 7420 7365 6374 6f72   reads.it sector
00000030: 2062 7920 7365 6374 6f72 2c20 6b65 6570   by sector, keep
00000040: 696e 6720 616c 6c0a                      ing all.
> cat test | ./myfmt2 35
Togetan idea about a disc cdck read
sit sector by sector, keeping all
>

Хоронили nap и si, в KOI8 порвали две строки.

Нет, не может. Нет ни одного юзкейса, когда KOI-8 предпочтительнее utf8.

Раз уж о некрофилии заговорили...У меня тут матричник печатает в cp866, есть какие-нибудь программы для форматирование текста под 80/160 символов на строку? Ну и чтобы еще на тетрадь кучу текста раскидать можно было.

Не всем нужен юникод в качестве локали.

Умная мысль.

В том же интернете полно *.txt файлов в cp1251, cp866,... и т.д.

Это одна из проблем интернета: на 95% это просто свалка информационного мусора. Умирают серверы, уходят идеи, уходят люди, а бесполезный информационный хлам, оставшийся после них — остаётся навсегда. Интернет-поисковики решили эту проблему с помощью вывода на первую страницу тех, кто больше всех заплатил, а не тех кто наиболее релевантен запросу.

решение через разного рода wchar_t и ICU

Ситуация такая, что в продакшен-нативе нет ЯП, которые прозрачно и комфортно для программиста работают с юникодом из коробки. Их реально нет, и кому нужно обрабатывать юникод изнутри, используют ICU (что иногда бывает некомфортно), или же приняли тёмную сторону силы, переехав на java, где юникод внедрён на самом нижнем уровне (с т.з. программиста).

Нас много, всех не переловите.

«Больше одного» это ещё не «много»

А на место каждого убитого придут ещё.

4.2

В том же интернете полно *.txt файлов в cp1251, cp866,... и т.д.

Legacy. Относительно общего количества текстовых файлов - немного.

При этом любой желающий может внезапно настроить локаль KOI8-R и автоматизировать создание и получение текстов в KOI8-R. Т.е. можно скачивать CHM/DJVU/PDF/DOC/DOCX/EPUB/HTML/FB2/LIT/PDB/ODT/XLS/PPT/RTF/... и т.д. файлы, потом скинуть их в одно место, а затем указать директорию скрипту, который разом конвертнёт всё это в plaintext в KOI8-R.

Да. Быть мазохистом и заниматься особыми извращениями закон не запрещает.

Долгое время в дистрибутивах была Qt3

И сейчас есть (не ставится по дефолту, но есть везде), ибо LSB.

Ещё в учебниках по информатике 2010-го года писали, что в Linux'ах KOI8-R

В них много бреда писали.

да и в готовящемся к выпуску Debian'е 9 куча всего для поддержки KOI8-R из коробки

У деба начиная с 4 юникод по дефолту. То, что KOI8-R поленились выпилить, не значит, что он каким-то образом жив или релевантен сегодня.

Также напоминаю о существовании ромадзи, что позволяет записывать тексты на японском в KOI8-R.

Это то же самое, что писать по-русски транслитом. Можно, но криво, неудобно, и преобразование необратимо (в случае русского - необратимы некоторые граничные случаи, в случае японского - необратимо 99% случаев). Зачем страдать, если есть нормальная кодировка, кодирующая все языки?

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

Это какой же такой странный дефолт?

Но, они же не выпилили поддержку однобайтных кодировок.

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

Для скриптов есть iconv, который делает то же, что делают редакторы.

И каждый раз переконвертировать сотни гигабайт текстовых файлов (да ещё и пожатых lzma) чтобы узнать в каких из них есть ключевые слова?

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

В любом случае, конвертация в этом случае будет жрать пренебрежимо малое количество врмени по сравнению с чтением с диска и декомпрессией.

И каждый раз переконвертировать сотни гигабайт текстовых файлов (да ещё и пожатых lzma) чтобы узнать в каких из них есть ключевые слова?

Вот чтобы такого не было, нужно, чтобы у всех был Unicode. Тогда проблемы не возникнет :)

Так эти сотни гигабайт текстовых файлов у меня уже в кодировке моей локали - KOI8-R.

Один раз конвертнуть в KOI8-R не проблема. Потом конвертировать в другие - уже лишнее. Как и менять локаль.

Так эти сотни гигабайт текстовых файлов у меня уже в кодировке моей локали - KOI8-R.

У всего остального мира в UTF-8.

Один раз конвертнуть в KOI8-R не проблема. Потом конвертировать в другие - уже лишнее. Как и менять локаль.

Ну так тебе каждый раз приходится конвертировать из UTF-8 в KOI8-R. Может проще один раз сконвертировать в UTF-8?

Как и менять локаль.

Поменял компьютер, накатил на него новую ОС — локаль поменялась сама на utf-8. А вручную менять на koi8 — это как раз лишнее.