Использование кодировки KOI8-R может указывать на то, что разработчики тестировали русские команды

Тут вопрос в безконечной кривизне софта

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

При однобайтных локалях однобайтный софт никогда ничего не ломает.

Особенно когда его запускают на машинах с отличной локалью. С utf8 таких проблем нет - он одинаков везде - и в России, и в США, и в Японии. Какая кодировка использовалась в очередном велосипеде - сложный вопрос. Запустишь программу, а у тебя текст квадратиками. И сменить кодировку у того что на экране нельзя.

Я же специально подчеркнул:

для ниши однобайтных локалей

Так что, не надо про другие локали. Речь конкретно про нишу однобайтных локалей. И в ней однобайтный софт работает хорошо.

На машине автора. Ибо как объяснить такому софту что что-то в твоей системе отличается от машины автора?

На всех машинах с однобайтными локалями.

Если софт заточен под конкретную однобайтную локаль (например, KOI8-R), то на всех машинах с этой конкретной однобайтной локалью.

Если софт заточен под конкретную однобайтную локаль (например, KOI8-R), то на всех машинах с этой конкретной однобайтной локалью.

Т.е. эта софтина не будет нормально работать примерно на 99,99999% машин. Отлично.

Но, будет работать на 100% машин в той нише, для которой она и написана.

Нужность такой программы стремится к нулю вместе с нужностью локали кои8-р.

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

Если софт заточен под конкретную однобайтную локаль (например, KOI8-R), то на всех машинах с этой конкретной однобайтной локалью.

Допустим есть программа для проверки правописания. Мне всё равно в виде чего она хранит словарь. Главное чтоб его хранение не вызывало проблем в работе. Но программе надо к примеру написать: «проверка завершена». Да, на русском. У тебя это работает. У меня utf8. Что увижу я в окне программы? Нечитаемые квадратики?

Но, будет работать на 100% машин в той нише, для которой она и написана.

Где гарантия, что эта программа не будет запущена к примеру в Японии, где о KOI8-R даже не слышали? Мир теснее чем кажется.

Что увижу я в окне программы? Нечитаемые квадратики?

Да. А вот не надо таскать софт из одной ниши в другую без модификаций. Те же бинарники под x86_64 не работают на ARM'ах и наоборот. И это норма. Здесь все понимают, что нужно, как минимум, перекомпилировать. Но, точно также и с кодировками. Чтобы осознать эти двойные стандарты достаточно начать думать о разных локалях как о разных архитектурах. И перестать требовать от софта чтобы он работал на всех локалях одновременно.

Гарантий никогда нет. Однако, во-первых, если заточенность под KOI8-R не указана в Readme, то это неполное Readme. Во-вторых, устанавливающие софт без чтения Readme сами себе злобные буратины. В-третьих, в Японии вполне слышали про KOI8-R: https://ja.wikipedia.org/wiki/KOI8-R , https://linuxjm.osdn.jp/html/LDP_man-pages/man7/koi8-r.7.html , https://charset.uic.jp/show/koi8-r/ ,... И это не говоря о том, что модуль Char-KOI8R для Perl 5 пилит именно японец INABA Hitoshi.

Да. А вот не надо таскать софт из одной ниши в другую...

Разупорись. Настраиваешь себе юникод и таскаешь что угодно куда угодно.

начать думать о разных локалях как о разных архитектурах

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

Разупорись. Настраиваешь себе юникод и таскаешь что угодно куда угодно.

Не всем нужен юникод. Даже если 10 человек сменят себе локаль на UTF-8, то ниша локали KOI8-R всё равно останется.

зачем ты думаешь о локалях?

Работа с текстом в кодировке локали напрямую зависит от архитектуры этой самой локали. От этого никуда не деться. Так что, пока будут тексты люди будут думать про кодировки и локали. За исключением тех, у кого нет компьютеров.

Софт может специально создаваться для ниши однобайтных локалей

А я знал, я знал, что секретная база нацистов в Антарктиде — это правда. Больше ведь некому, кроме них, заниматься настолько бесчеловечными вещами.

Не всем нужен юникод.

По факту всем.

В качестве локали по факту - не всем.

Да. А вот не надо таскать софт из одной ниши в другую без модификаций.

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

Те же бинарники под x86_64 не работают на ARM'ах и наоборот.

Нет. Сходи в гугл, спроси про эмуляцию.

Здесь все понимают, что нужно, как минимум, перекомпилировать.

В 99% это излишне.

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

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

В-третьих, в Японии вполне слышали про KOI8-R

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

Даже если 10 человек сменят себе локаль на UTF-8, то ниша локали KOI8-R всё равно останется.

Но количество пользователей уменьшится в 9 раз.

Ну так и с кодировками так можно:

cat data.txt | iconv -c -f utf-8 -t koi8-r | filter_for_koi8-r | iconv -f koi8-r -t utf-8
cat data.txt | iconv -f koi8-r -t utf-8 | filter_for_utf-8 | iconv -c -f utf-8 -t koi8-r

Что можно? Как с бинарником быть, который что то на экран выводит? Особенно если он рисует нечитаемое нечто на экране?

Перехватывать вывод и конвертировать из одной кодировки в другую.

Одна идея базрассуднее другой. Чем вывод перехватывать?

Конвейером. Программа что, не в stdout/stderr пишет что-ли?

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

Программа что, не в stdout/stderr пишет что-ли?

ВНЕЗАПНО.

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

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

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

Ну или можно временно переключать локали.

А для какой ниши нужен софт с однобайтными локалями? Зачем его писать в 2017 году?

Во-первых, там, где решили «Работает - не трогай!». Во-вторых, там, где: 1) нужна экономия памяти; 2) 256 символов выше крыши; 3) нужна экономия сил разработчиков за счёт упрощения архитектуры разбирающего текст кода (например, разработчик может переместить указатель на N символов через «strptr + N»).

Во-первых, там, где решили «Работает - не трогай!»

Работает криво, но работает же!

Во-вторых, там, где: 1) нужна экономия памяти; 2) 256 символов выше крыши; 3) нужна экономия сил разработчиков за счёт упрощения архитектуры разбирающего текст кода (например, разработчик может переместить указатель на N символов через «strptr + N»).

Жуткая экономия на комфорте людей.

Так всё, повторяю, зависит от ниш и задач. Если кому-то без юникода никак, то он и поставит себе юникодную локаль и будет гоняться за свежим софтом.

А есть люди, которые за всем этим не гонятся. И они могут себе позволить в т.ч. юзать софт и из 70-80-х гг. Как оригинальный так и с улучшениями.

Ну или можно временно переключать локали.

Гениально! Захотел воспользоваться одной программой - сменил локаль, захотел другой - опять сменил. Ладно в линуксе еще можно соорудить костыль в виде какого-нибудь $ LC_ALL=ru_RU.cp1250 /usr/bi/katkayatohreni.bin А в винде, не знаю как сейчас, но раньше для смены локали приходилось вообще-то ребутаться. Была у меня во времена оные программка с румынским интерфейсом, авторы которой не осилили юникод, и естественно вся диакритика в русифицированной винде превращалась в тыкву из бнопни. Поменяешь локаль на cp1250 - получишь кракозябры в другом софте. Очень удобно, чо.

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

Это понятно, что есть какие-то очень специфичные железяки, где килобайты критичны и разработчики экономят на чем могут. Но на десктопе-то такая экономия на кой? При том что взамен получается куча головной боли.

И это единственный случай, когда я пользовался кодировкой ISO-8859-5. Потому что добрый автор библиотеки для TFT 128x64 подумал о других языках и положил в свою библиотеку шрифты, отличные от ASCII. Ага, шрифты для кодировок семейства ISO-8859 — ну стандарт же! Т.е. пользователи кои даже тут в пролёте, даже мёртворождённая недокодировка (которая абсолютно худшая среди однобайтных кириллических кодировок) в единственной оставшейся нише однобайтных кодировок их обошла.

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

Если этот микроконтроллер ничего никуда не пишет, то это логично. Если этот микроконтроллер выводит эту информацию куда-то то логичным будет использовать юникод.

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

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

Зависит от того, что подразумевать под сменой локали. «chcp 20866» в cmd.exe никто не отменял.

Зависит от того, что подразумевать под сменой локали. «chcp 20866» в cmd.exe никто не отменял.

Это где? В гуи или опять только в консоли?

В GUI можно и юникод юзать, особенно в 2017-м году. А вот без GUI, особенное если в шрифтах всего по 256 символов, KOI8-R незаменим.

В GUI можно и юникод юзать, особенно в 2017-м году

Обычно сторонники какой-то кодировки думают что именно она стоит в качестве дефолтной на любой машине. Именно по этому у меня такое к ним отношение.

Я всегда был не из тех, кто так думает, и уже больше 10-ти лет знаю, что теперь в линуксах кругом по дефолту юникод (а до этого я был уверен в том, что все существующие мануалы по руссификации описывают настройку локали KOI8-R, которая опять таки не по дефолту). Но, дефолт никогда не отменяет возможности выбора того, что нужно. Юзер всё равно может ставить любую нужную ему локаль и юзать любые нужные ему кодировки.

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

Юзер, конечно, может убедить себя, что черное - это белое, а нормальная поддержка даже родного языка, не говоря уже об иностранных, ему не нужна. Но это говорит лишь о том, что юзер упорот и ССЗБ.

Зависит от того, что подразумевать под сменой локали. «chcp 20866» в cmd.exe никто не отменял.

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

Мне кажется что вы не понимаете до конца, о чем идет речь.Микроконтроллер может быть просто не способен на вывод чего-то в виде юникода. Попытайтесь представить себе программу, которая получает данные, производит с ними какие-то действия и выводит их куда-то. И все это умещается в 512 байт памяти ОЗУ. И хранится эта программа, например, в 1 кб памяти на ПЗУ. А вы предлагаете в этот 1 кб еще и вместить реализацию таблицы символов юникода, и нагрузить ОЗУ хранением выводимых юникодных данных. Вам кажется реальным то, что вы считаете логичным? Хотя, конечно же, в некоторых ситуациях это возможно.

Пусть тогда эта программа работает исключительно с ascii вплоть до 128. С ними точно проблем не возникнет.

Ситуации бывают разные. В т.ч. бывает, что и GUI нет вообще. А бывает и так, что GUI есть, но на налаженном производстве требуется конкретное решение, которое запилили в 90-х через KOI8-R и нет смысла это переделывать, поскольку эта софтина просто чем-то управляет локально, а не висит мордой в интернеты. А бывает и так, что юзер на 99% набирает тексты в ASCII, а на 1% буквами [а-яА-Я]. А потому не видит смысл переходить на юникодную локаль. Тем более, что такой софт как тот же Firefox стартует с поддержкой юникода и на локали KOI8-R. Да, я уже когда-то про это говорил, даже с локалью KOI8-R в Firefox'е можно читать юникодные тексты как они есть, со всеми тысячами символов. А уж PDF'ы и подавно везде открываются как они есть независимо от локалей. При этом в том же TeX'е можно верстать со всеми поддерживаемыми возможностями через ASCII последовательности на любой локали.

Да. Именно так. Но иногда этого недостаточно, а использование юникода невозможно.