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

Программы будут создавать файлы с именами в кодировке, указанной при монтировании ФС

Где ключик выбора кодировки у ext*? У FAT и NTFS он есть, но не от хорошей жизни.

Файл создать можешь, но его имя не будет в UTF-8

Что ты тогда имеешь в виду под «ОС поддерживает UTF-8»? Файл создать могу (скажем, из Python или PHP с нормальной UTF-8 строкой), поиск работает, в т.ч. регистронезависимый. Что ещё?

wchar_t fn[] = L"यूनिकोड юникода.txt";
std::ofstream outfile(fn);
char ch=65;
outfile.put(ch)

MSVS 2012, работает

Что ты тогда имеешь в виду под «ОС поддерживает UTF-8»?

Что API-функции ОС принимают строки в UTF-8 и позволяют с ними работать.

В GNU/Linux это верно — например если передать fopen строку UTF-8 как имя файла, он откроется. В Windows это неверно, так как для любой работы с UTF-8 требуется конвертировать строку в другую кодировку.

Python и PHP не являются частью ОС и в них для Windows сделан костыль, и полагаю даже с их помощью если ты создашь файл с именем за пределами базовой плоскости, с ним будут проблемы.

Да, все работает, везде (на всех моих линуксах и фряхах) показывается нормально. Но я все равно не использую кириллицу в именах файлов.
Игоры на линуксе? Нет уж, для этого есть семерочка максимальная.

L

Вообще-то речь была о UTF-8, а не UTF-16. Предположим, что у тебя есть текстовый файл filename.dat в котором содержится «यूनिकोड юникода.txt» в кодировке UTF-8. Требуется написать программу которая будет создавать файл с таким именем и скажем писать туда «Привет мир!\nСтрока вторая\n» с концами строк LF и без BOM в кодировке UTF-8.

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

Работают. Я вот только на днях с koi8 на utf8 перешёл. Дистрибутив не менял, ALT да базе шестой ветки. То есть, вполне работало до последнего момента. Правда, актуальная ветка седьмая сейчас. Вот приложения есть, которые кривовато написаны, потому и перешёл на utf8.

Вот приложения есть, которые кривовато написаны, потому и перешёл на utf8.

А их много? Можно называния нескольких более-менее популярных?

Это уже не проблема windows. Была заявка, что нельзя создавать файлы с названием в юникоде, оказалось, можно.
К слову, .NET Framework - часть системы, начиная с висты, так что можно считать её стандартной

Можно называния нескольких более-менее популярных ?

LibreOffice например, как минмум 4.1 который. В локали LANG=ru_RU.KOI8-R формирует задание с кривым именем для CUPS, и ничего не печатается.

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

Я говорил, что нельзя создать файлы с названием конкретно в UTF-8.

Напиши такой код на C или C++, который сам по себе находится в файле с кодировкой UTF-8, соответствует стандарту C++11 и скомпилируется и правильно отработает и в GCC на GNU/Linux, и в Windows.

То что ты предложил ранее у меня не работает, я так понял потому что функция std::ofstream требует char*.

1. Иксы и работа с файлами - никак не относящиеся друг к другу вещи
2. А локаль ru_RU.KOI8-R ты сгенерил? Что показывает locale -a?

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

Только последний быдлокодер будет сохранять файлы не в ASCII!

А локаль ru_RU.KOI8-R ты сгенерил? Что показывает locale -a?

Ничего не генерил, в locale -a она есть.

Только последний быдлокодер будет сохранять файлы не в ASCII!

Ты ещё скажи, что имена файлов не нужны, вполне достаточно inode-ов.

Транслит — зло. А английский знают не все.

Репорть баг

Репорть баг

Какой баг?

$ locale -a | grep -i koi
ru_RU.koi8r

Ты еще скажи, что пробел в имени файла — норма...

Ты еще скажи, что пробел в имени файла — норма...

Всё что не '/' и не '\0' допустимо стандартом — значит норма.

А английский знают не все.

Кодер обязан. Хотя бы на базовом уровне. А кодер без инглиша — как мужик без яиц.

И трахайся потом с этим извращением в баш-скриптах! Потому-то и люблю я на сишечке скриптики писать.

Кодер обязан. Хотя бы на базовом уровне. А кодер без инглиша — как мужик без яиц.

А причём тут кодер? Мы же говорим о именах файлах и локалях, а они у всех юзеров.

Вот ты реально считаешь, что 80-летняя бабушка обязана учить английский чтоб только не называть файлы русскими именами?

И трахайся потом с этим извращением в баш-скриптах!

баш-скрипты, которые криво работают с такими именами бажные, очевидно.

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

Скрипты на C — извращение. Пиши на нормальном языке типа Tcl лучше

А при том, что я посмотрел, на что ты отвечал:

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

Только последний быдлокодер будет сохранять файлы не в ASCII!

Вот при этом. И вот как раз «бабушки»-то тут и ни при чём.

Так не получится хотя бы потому, что в линаксе название файла - массив char, а в windows - массив юникодных символов (wchar_t), и так просто скормить юникодное представление не получится (т.к. у ofstream:ofstream(char*) один char - один символ), а в gcc нет конструктора от wchar_t*

#ifdef наше все

#ifdef шиндошс «скачать визуал студию»?

оскорбляешь чувства верующих в святую KOI8

Ага, всех одного.

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

у меня есть деб сквызи с кои8-у

Вот при этом. И вот как раз «бабушки»-то тут и ни при чём.

Кодеры пишут и для бабушек тоже. Имелось ввиду сохраняться с помощью написанных кодером программ, а не сохраняться самим кодером в диалоге сохранения (или операторе вывода в консоли)

Так не получится хотя бы потому, что в линаксе название файла - массив char, а в windows - массив юникодных символов (wchar_t)

Вот это я и имел ввиду, утверждая, что Windows не поддерживает UTF-8. Кроме того он даже не поддерживает стандарт C++, где сказано, что должен быть char*. Вот что будет если использовать не wchar_t* а просто char* в Windows? Не скомпилируется и не заработает?

т.к. у ofstream:ofstream(char*) один char - один символ

А должно быть один char - один байт

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

А если в имени файла будет '\n' или ещё что-нибудь контрольное, он отрабатывает?

А если будет два файла, которые в транслите должны называться одинаково, например схизма.txt и шизма.txt ?

А если в имени файла будет '\n' или ещё что-нибудь контрольное, он отрабатывает?

Пока таких файлов не было, если будут — добавлю и обработку этого.

А если будет два файла, которые в транслите должны называться одинаково, например схизма.txt и шизма.txt ?

Ну это уж совсем шиза ☺

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

«Если за это не убивать, то за что тогда вообще убивать?» ©

А должно быть один char - один байт

кто сказал?

Убивать за то, что названия файлов пишут не в ASCII, с пробелами и знаками препинания. В общем, бить за такое молотком по пальцам кривым!

Не скомпилируется и не заработает

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

«Крутится волчок...тарам-парам-парам-па...крутится волчок» (с)

Так интернеты не нужны же.

скомпилируется и заработает, но не так, как требуется.

Ну вот пример кода — если его скомпилировать в Windows и запустить, что будет?

кто сказал?

А как ещё? char — это синоним signed byte, разве нет?

Ну это уж совсем шиза ☺

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

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

Я тоже думаю, что лучше бы UTF-VAR какой-нибудь сделали, где на 1 символ может быть сколько угодно байтов. Чтоб уже наверняка.

Это называется utf-8.

Ну, тогда пусть будут.

Как видишь, ключика -f нет, так что проблем не будет.

rmspaces
for Name in `ls -1`
do
    Newname=`echo "$Name"| enconv | sed -e \
    "y/йукенгзхъфывапролдэсмитьбЙУКЕНГЗХЪФЫВАПРОЛДЭСМИТЬБ/jukengzh'fyvaproldesmit'bJUKENGZH'FYVAPROLDESMIT'B/"\
    -e "s/ц/tz/g"   \
    -e "s/ш/sh/g"   \
    -e "s/щ/sch/g"  \
    -e "s/ж/zh/g"   \
    -e "s/ч/ch/g"   \
    -e "s/ю/yu/g"   \
    -e "s/я/ya/g"   \
    -e "s/ё/yo/g"   \
    -e "s/Ё/YO/g"   \
    -e "s/Ц/TZ/g"   \
    -e "s/Ш/SH/g"   \
    -e "s/Щ/SCH/g"  \
    -e "s/Ж/ZH/g"   \
    -e "s/Ч/CH/g"   \
    -e "s/Ю/YU/g"   \
    -e "s/?/_/g"    \
    -e "s/Я/YA/g"`
    if [ "$Name" != "$Newname" ]; then
        mv "$Name" "$Newname"
    echo -e "$Name   ->    $Newname                             \r\c"
    fi
    if [ -d "$Newname" ]; then
    cd "$Newname"
    echo -e "\n\nDiving into $Newname"
    rename_translit
    cd ../
    fi
done

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

char - ещё и character. И в windows не нужны костыли, чтобы писать имя файла как поток байт, что впоследствии приводит к самым разным проблемам с кодировками.

только последний дегенерат допускает пробелы в имени файла!

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

Когда я читаю подобные эпифонемы, мне становится смешно и грустно.

Если это шутка, то какая-то несмешная.

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

/* у самого полно файлов и с пробелами, и с подчёркиваниями, иногда меняю, иногда нет, проблем тоже нет */

char - ещё и character. И в windows не нужны костыли, чтобы писать имя файла как поток байт, что впоследствии приводит к самым разным проблемам с кодировками.

Ну это он так назывался по историческим причинам. Можешь ещё /usr считать местом для пользовательских данных, а в /sbin класть только статические бинарники. В любом случае char — это байт сейчас.

Второе предложение не понял. Что приводит к проблемам? К каким например?

Факт в том, что в стандарте написано, что fstream требует char*, значит он должен с этим корректно работать, даже если этот char* — строка в UTF-8.