Работают ли современные дистрибутивы с локалями отличными от *.UTF-8?

Лишнее неудобство для пользователя.

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

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

Таким образом, новое приложение с правильным инсталлером — работает сразу и показывает текст в UTF-8, приложение, не устанавливающее нужный параметр (хоть старое, хоть новое) — работает сразу, если выставлена нужная дефолтная страница или после установки этой страницы в настройках совместимости приложения, если какая-то другая. Или после установки другой кодовой страницы в общих настройках системы.

Может быть можно было бы и ещё какой-нибудь аналог #define UNICODE сделать, чтоб информация о том, что приложение использует UTF-8 была и в самом исполнимом файле, главное чтоб он не мешал компилированию на системах отличных от Windows.

Так безо всяких костылей char == ANSI, wchar == юникод

А UTF-8 где тогда?

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

Если приложение написано правильно (в соответствии с winapi, TCHAR для символов)

Если приложение написано «правильно» — оно на линуксе даже не скомпилируется, разве нет? Значит это приложение написано неправильно.

спорное утверждение

Приведи хоть один аргумент против.

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

молодец, возьми с полки пирожок.

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

В линуксе проблем с апгрейдами нет, поэтому некрофилия 10-летней давности никому невпёрлась, соответственно никто в софт костыли не встраивает.

Вообще-то есть. Безусловно это важно только для тех проектов, которые были начаты более десяти лет назад. Возможно всякие встроеные и урезанные среды тоже имеют подобные проблемы.

Я считал?

Работают.

Она спокойно работает с UTF-8 начиная с Win7

Расказывай об этом тем, кто никогда не видел Win7.

При чем здесь место? Мне удобно пользоваться однобайтной кодировкой. И нет проблем с обработкой кириллических текстов как в баше, так и в сях.

В Debian все прекрасно работает и с utf8 и с cp1251 и с cp866 и с koi8-r. Присваивать нужно не только эти переменные но и LANGUAGE, вообщем все переменные команды locale.

$ locale

# dpkg-reconfigure locales

Если приложение написано «правильно» — оно на линуксе даже не скомпилируется, разве нет?

1% да кому он нужен?

А UTF-8 где тогда?

Проблема конктерного C/C++. С# работает со строками в UTF-8, вот пример:

var f = new StreamWriter("1.txt");
f.WriteLine("यूनिकोड юникода");
f.Close();

Вместо того, чтобы обойтись меньшим злом (пофиксить кирилицу в VT), ты выбрал большее зло (грабли от быдлокодеров).

пофиксить кирилицу в VT

У меня кириллица в VT работает. И никакие это не грабли. Грабли — хрюникод.

была заморожена на уровне SLC3.

Что такое SLC3?

1% да кому он нужен?

каким-то там петушиным стандартам

Ну ты что-то как-то совсем уж в толсту скатился. Прекращай уже — ты можешь лучше.

Почему UTF-16 отстой, кстати, уже объясняли — худшие черты UTF-32 и UTF-8 — ни фиксированной длины символа, ни совместимости с ASCII.

Проблема конктерного C/C++

Не C/C++, а реализации их в Windows.

сохранит текст в UTF-8.

А если сделать то же самое, но выводить на stdout и перенаправлять в файл оператором '>'?

Ну по твоим постам можно было понять так.

Scientific Linux CERN

KOI8

Давили-давили, давили-давили, а оно всё ещё живо.

В некро-BSD до сих пор можно встретить. А красноглазые админы в сальных свитерах даже в самый свежих дистрах меняют локаль на тёплую ламповою КОИ8.

Ты меня не понял

Эмм. Ты:

 — считаешь поддержку конкретной фичи C++0x компилятора поддержкой юникода

 — не в курсе о кодировке файловой системы (да, линуксы настолько плохи, что её просто нет. В нормальных системах после этого непривычно)

chcp 65001

А вот в GNU/Linux этот пример компилируется и файл создаётся именно с тем именем, которое указано.

Ты лжёшь. Твой код локалезависим и ты сам это прекрасно знаешь. Точнее, в линуксе файл создаётся ничерта не с этим именем, но в нужной локали ты видишь результат, который считаешь «именно тем именем». И мы ещё не касались нормализации.

Значит, я ошибся и это хорошо.

За использование LC_ALL надо пороть розгами :)

откуда fstream знать, что это строка в UTF-8? кодировок то существует много

А вот как раз для этого существует переменные окружения LC_* и LANG. Прописанные в стандарте.

Ох ты ж лол.

В POSIX все функции для работы с файловой системы кладут на LC_* и LANG и пишут набор байт (не юникодную строку!) в имя файла. Не пытаясь его нормализовать (поэтому можно смело заявлять: линуксовые ФС не умеют в юникод). Если у читателя этой ФС будет другая локаль — это проблемы читателя.

И да, в линуксовой VFS такого понятия, как «кодировка файловой системы» не существует вообще. У реализаций мелкомягких ФС в линуксе, впрочем, кодировку можно указать при монтировании, но линуксовый софт от этого не учится нормально работать с юникодными именами (нормализовывать опять же никто не пытается).

Для сравнения: NTFS в оффтопике — в UTF-16, следовательно — в юникоде, нормализация везде проводится.

из-за чего юникод в Windows несовместим с ASCII

Это хорошо: меньше программ, которые «вроде бы работают» «вроде бы с юникодом» и больше девелоперов, которые таки осилили маны.

Почему UTF-16 отстой, кстати, уже объясняли — худшие черты UTF-32 и UTF-8 — ни фиксированной длины символа, ни совместимости с ASCII.

Длина строки в UTF-16, UTF-8 и UTF-32 одинаково (бес)полезна и годна исключительно для оценки потребления памяти. «Символ» в UTF-32 не имеет ничего общего с тем, что под символом понимают люди. Фиксированная длина ничерта не даёт на практике кроме возможности пропустить обработку суррогатных пар (не факт, что это добавит скорости: в UTF-32 в кэш влезает почти в 2 раза меньше на реальных данных).

UTF-8 объективно дольше парсится, чем UTF-16 и в значительной доле случаев ещё и длиннее. Не стоит считать его лучше по всем параметрам. Ну и юникод в оффтопике делали до того, как в линуксе он более-менее заработал.

Кстати, мне хочется посмотреть на дистрибутив линукса, где кодировкой можно выбрать Shift-JIS (сюрприз: её нельзя 1-в-1 конвертировать в юникод и обратно). От подобного крышу снесёт всем coreutils и практически всем остальным частям «OS GNU поверх линукса» кроме, возможно, heirloom toolchest.

бНОПНЯ! Какие могут быть проблемы от UTF?

У меня кириллица в VT работает. И никакие это не грабли. Грабли — хрюникод.

Грабли описаны здесь

По-моему получается, что они есть в любом случае.

что у тебя не работает?

с локалями отличными от *.UTF-8?

А зачем?

считаешь поддержку конкретной фичи C++0x компилятора поддержкой юникода

Не считаю, в принципе ОК, если файл сохранён в UTF-8 и u8 перед строкой нет. Но неподдержка этой фичи — не поддержка стандарта C++11.

не в курсе о кодировке файловой системы (да, линуксы настолько плохи, что её просто нет. В нормальных системах после этого непривычно)

Кодировка файловой системы — это не забота программы, это забота ядра. Для FAT например есть опции iocharset и codepage, позволяющие задать как кодировку используемую в ФС, так и кодировку, используемую для общения с ней.

линуксы настолько плохи

троллсто.

Кодировка файловой системы — это не забота программы, это забота ядра.

Ну так ext*, btrfs, zfs и компания не умеют кодировку от слова «совсем», как и ядро.

в принципе ОК, если файл сохранён в UTF-8 и u8 перед строкой нет.

Эмм. Компилятор не обязан угадывать кодировку, в которой сохранён файл. И не обязан поддерживать любую кодировку. В конце концов, компилятор — это не текстовый процессор/редактор.

что у тебя не работает?

У меня-то работает, а вот у тебя — нет.

Ну так ext*, btrfs, zfs и компания не умеют кодировку от слова «совсем», как и ядро.

А нафига модулям ядра еще и заниматься декодированием? Место для enca только в пространстве пользователя есть, а какой идиот будет extX, reiserfs или что подобное через fuse монтировать?

4.2 какое, а!

Где это у меня что-то не работает? Что ты выдумываешь?

enca

Кстати, костыль невообразимых размеров и не работает в общем случае.

То, что в ядре и стандартной библиотеке нет понятия о стандартной кодировке — нормально для линукса. В конце концов, линукс (пока) не настолько жирный, чтобы не влезать в то, что сейчас называют embedded. Там кроме ascii не всегда что-то нужно. Но говорить, что на десктопах это тоже плюс — странно.

костыль невообразимых размеров и не работает в общем случае

А больше ничего и нет! Как ты опознаешь, что за кодировка в файле? Только методом частотного, а лучше даже — лексического анализа!

В ядре — да, только ASCII и должно быть. И это правильно.

Да и вообще, по-хорошему было бы всю мировую письменность на ASCII переделать. Ибо нефиг!

Ну так ext*, btrfs, zfs и компания не умеют кодировку от слова «совсем», как и ядро.

Ядро как раз умеет, хотя конечно опции типа ioenc и fsenc не помешали бы для всех файловых систем, чтоб можно было нормально смонтировать файловую систему, созданную в каком-нибудь там древнем линуксе. С другой стороны, никто не отменял утилит типа convmv для таких редких случаев, так что это некритично.

Эмм. Компилятор не обязан угадывать кодировку, в которой сохранён файл.

Если компилятор не будет угадывать кодировку, он не сможет поддерживать литералы типа L"" и все другие подобные.

Впрочем не страшно, пусть компилятор считает, что кодировка всегда UTF-8, если есть литералы, предполагающие конвертирование, и выдаёт ошибку если не сможет перевести строку, а если нет таких, просто пихает как блоб в код, что бы там ни было — хоть KOI8, хоть байты из /dev/urandom

UTF-8 объективно дольше парсится, чем UTF-16 и в значительной доле случаев ещё и длиннее.

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

Ну и юникод в оффтопике делали до того, как в линуксе он более-менее заработал.

И сделали в итоге USC2 вместо юникода. Пример — в блокноте, как и в диалоге переименования файлов символ за пределами базовой плоскости удаляется двумя нажатиями на backspace.

Это хорошо

Ломать совместимость без нужды — это совсем нехорошо.

В POSIX все функции для работы с файловой системы кладут на LC_* и LANG и пишут набор байт (не юникодную строку!) в имя файла. Не пытаясь его нормализовать

Файловая система — это контейнер для данных. Чем меньше она налагает ограничений на данные — тем лучше. А LC_* следует обрабатывать самой программе, а не драйверу файловой системы. Впрочем из-за того что некоторые разработчики этого не знают, и появляются программные пакеты, которые их не обрабатывают. Но это не страшно. так как сейчас везде UTF8, а где не UTF8, там она (по назначению) используется только ради ретроградских программ, которые заведомо поддерживают нужную локаль правильно.

Ты лжёшь.

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

файл создаётся именно с тем именем, которое указано.

Твой код локалезависим и ты сам это прекрасно знаешь.

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

А ядро и не должно интерпретировать данные, переданные как имя файла, кроме проверки '/' и '\0', если они предназначены для записи на нативную файловую систему и это правильно.

чтоб можно было нормально смонтировать файловую систему, созданную в каком-нибудь там древнем линуксе

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

Где это у меня что-то не работает? Что ты выдумываешь?

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

А, так при чем здесь это? Быдлокодеры — они и в Африке быдлокодеры. Это к делу не относится. Если у тебя быдлокодерские программки сегфолты постоянно выдают, ты сделаешь вывод, что вся система — говно?

Если у тебя быдлокодерские программки сегфолты постоянно выдают, ты сделаешь вывод, что вся система — говно?

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

Ну ты даешь!

Т.е. по-твоему, в сегфолтах программы язык виноват? Да я тебе такую кучу быдлокода выдать могу, который будет не только сегфолтится, а еще и работать от случая к случаю! И ты скажешь, что это — проблемы языка? ДАНУНАФИГ!

Да я тебе такую кучу быдлокода выдать могу, который будет не только сегфолтится, а еще и работать от случая к случаю!

Попробуй. Только чур чтоб этот код был на Coq!

Т.е. по-твоему, в сегфолтах программы язык виноват?

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

на Coq

WTF?

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

Ты прямо фантастику какую-то рассказываешь.

Почитай про Coq, поймёшь, про что я говорю.

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

Ядро как раз не умеет. Попробуй смонтировать ту же vfat с любыми опциями для двух пользователей одновременно, один из которых работает с UTF-8 локалью, другой — с EUC-JP, скажем. После этого выдай ещё один перл вроде

А LC_* следует обрабатывать самой программе, а не драйверу файловой системы.

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

Если компилятор не будет угадывать кодировку, он не сможет поддерживать литералы типа L"" и все другие подобные.

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

Угадывать кодировку — бред. Если в спеках к компилятору указано, что файлы предполагаются в кодировке X — это ок. Если он читает кодировку в начале файла или в опциях командной строки — всё ещё ок. Но ожидать угадывания механизмом вроде enca — бред по очевидным причинам.

Файловая система — это контейнер для данных. Чем меньше она налагает ограничений на данные — тем лучше.

Иди и прочитай про нормализацию юникода и зачем она нужна.

пусть компилятор считает, что кодировка всегда UTF-8

UTF-8 (и даже больше того — юникод вообще) — не идеальная кодировка, глупо ждать её от всего мира.

Ломать совместимость без нужды — это совсем нехорошо.

Советую выучить историю. UTF-16 в коммерческом релизе оффтопика появилось через полгода после официальной презентации UTF-8. Мелкософту нужно сломать всё из-за того, что UTF-8 внезапно стал популярен на 1.5% десктопов через 20 лет после этого?