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

Прозреваю детскую травму с FAT-32.

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

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

Мелкософту нужно сломать всё

Можно перейти на UTF8 и сохранив совместимость. Как — см. выше.

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

Из тех, которые есть на данный момент — самая лучшая.

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

Я знаю про нормализацию юникода. Да, в линуксе можно создать два файла, имена которых выглядят одинаково. Но то же справедливо и для Windows — достаточно заменить местами английскую 'a' на русскую и/или наоборот.

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

А почему бы и не байты?

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

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

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

Но ожидать угадывания механизмом вроде enca — бред по очевидным причинам.

Я с этим и не спорю. Хотя вот кривая мелкософтовская студия пытается угадывать например и часто делает это неправильно.

То есть у них было целых полгода

целых

Делись веществами. За полгода до релиза. Релиза. Не «релиза» убунты, а релиза. ОС под новую архитектуру. Впиливать появившийся только что стандарт, который никто ещё не видел и который может забыться через месяц. И да, работа utf-8 медленнее и это было важно в те времена.

В линуксах и тех о utf-8 можно было говорить лет 10 назад. В оффтопике юникод уже больше 20 лет.

Но то же справедливо и для Windows — достаточно заменить местами английскую 'a' на русскую и/или наоборот.

В Windows это можно сделать только специально. В Linux любой кореец может случайно наткнуться на это. Несколько раз в день. И снести этот линукс к чёрту в итоге.

добавить CP_UTF8 в список однобайтовых локалей

Да млин. Это добавит не поддержку юникода, а «поддержку» как в линуксе. И оно уже фиг знает сколько есть в таком виде и называется CP 65001.

Нужна тонна усилий чтобы превратить «поддержку» в поддержку. Усилия не бесплатны, эти деньги лучше пожертвовать голодающим детям в Уганде (и они станут долларовыми миллиардерами). Профита в таком переходе — ноль по сравнению с нормальной поддержкой UTF-16.

Если одно устройство два раза смонтировать, опции всё равно почему-то получаются одинаковыми.

Смонтировать один раз и прочитать двумя пользователями. Что они увидят?

Из тех, которые есть на данный момент — самая лучшая.

Ещё один нашедший серебряную пулю. В этом вашем юникоде ещё юнификацию не отменили. Перевод из Shift-JIS в юникод — до сих пор только с потерями. С китайскими кодировками, вроде бы, то же самое.

О том, что utf-8 — не всегда лучшая из кодировок юникода, я уже говорил.

А почему бы и не байты?

Зачем байты? Сейчас от них все уходят. Недавно windows научилась выдавать нормализованное имя, а не просто ожидать, что весь софт, включая тот, что пишет в обход WinAPI (например, на смонтированную линуксом ФС) написан имеющими здравый смысл кодерами.

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

Лол. Что они увидят вместо имён файлов друг друга? И это не чинится в общем случае вообще никак: информации о кодировке в файловой системе не записано вообще, а угадать кодировку мы не можем.

А вот в Windows это невозможно.

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

Делись веществами. За полгода до релиза. Релиза. Не «релиза» убунты, а релиза. ОС под новую архитектуру.

Только вот Windows сразу после релиза почему-то так глючит, что и убунте не снилось...

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

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

И оно уже фиг знает сколько есть в таком виде и называется CP 65001.

Тогда скажи, как сделать, чтоб мой пример без изменений (или с минимальными изменения в одном месте, которые не ломают работу под линуксом) заработал под Windows? Где мне прописать эту чудесную CP 65001? А в FAT можно в таком случае сохранять файлы в юникоде?

Нужна тонна усилий чтобы превратить «поддержку» в поддержку. Усилия не бесплатны

И какие конкретно усилия нужны?

Смонтировать один раз и прочитать двумя пользователями. Что они увидят?

То, что получилось при конвертации параметра опции codepage в кодировку iocharset, очевидно.

Зачем байты? Сейчас от них все уходят.

Это не аргумент. Можно ещё сказать «сейчас все дистрибутивы на systemd переходят» — но вообще-то это не будет значит, что systemd — это хорошо.

Лол. Что они увидят вместо имён файлов друг друга?

Пусть используют одинаковую кодировку. Вероятно действительно, имеет смысл по-немногу дропнуть поддержку не utf-8.

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

Ой, только вот врать не надо. В винде даже в консоли не та же кодировка, что в гуи

Только вот Windows сразу после релиза почему-то так глючит, что и убунте не снилось...

Знаешь, а мне даже интересно стало. Можно ссылку на неглючащую убунту 1993 года?

Как, интересно?

Запросто, достаточно скачать любой файл и попробовать сделать с ним что-то из консоли. Довольно велики шансы того, что нормализация не совпадёт. Автодополнение, кстати, не поможет: оно не настолько умное.

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

А осуществляет её не драйвер, емнип. В линуксе это был бы уровень glibc.

мой пример

Говно.

Windows умеет юникод, конкретный вариант UTF не так важен.

без изменений

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

Твой прикладной софт не пытается. Двоемыслие?

в FAT можно в таком случае сохранять файлы в юникоде?

А FAT сколько лет и с чего бы тебе использовать его сейчас при наличии NTFS, UDF и exFAT?

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

man gettext. Ну и твой пример не работает под линуксом в общем случае: он ломается при многих локалях.

И какие конкретно усилия нужны?

Сделать по UTF-8 локали на каждый язык/страну (ru_RU.UTF-8, en_US.UTF-8 и de_DE.UTF-8 — абсолютно разные вещи). Объяснить девелоперам нужность этого. Заставить их переписывать работающий и устраивающий всех софт (сколько это человекочасов — сам представишь), включая библиотеки.

То, что получилось при конвертации параметра опции codepage в кодировку iocharset, очевидно.

Вывод: iocharset — ненужный костыль. Но линуксы без него не могут.

Это не аргумент.

Лишняя сложность валидации — аргумент.

Пусть используют одинаковую кодировку.

Один из них использует ту же EUC-JP. Теперь из-за убогости линуксов ему постоянно работать с потерями?

по-немногу дропнуть поддержку не utf-8

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

Стоп, это же про линуксы. Тут это — в порядке вещей. Если у юзера проблемы — пусть курит маны и вообще он ССЗБ (начиная с момента, когда поставил линукс).

В винде даже в консоли не та же кодировка, что в гуи

4.2. И там, и там — юникод. А пользоваться legacy не нужно. Юникод в венде поддерживается более 20 (двадцати) лет.

4.2. И там, и там — юникод. А пользоваться legacy не нужно. Юникод в венде поддерживается более 20 (двадцати) лет.

Хреновый там юникод. прямо скажем.

Один из них использует ту же EUC-JP. Теперь из-за убогости линуксов ему постоянно работать с потерями?

Нет, использовать нормальную файловую систему, а желательно, ещё и нормальную кодировку.

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

Весь нужный софт это уже умеет, если это не совсем говно мамонта. А если совсем — то запускать в режиме совместимости.

man gettext. Ну и твой пример не работает под линуксом в общем случае: он ломается при многих локалях.

Что gettext? Он в любом случае создаст файл с именем в UTF-8, независимо от локали. И это вполне логичное поведение, так как вероятно в неюникодных локалях выполнить задачу (смешать кириллицу и хинди) просто нельзя.

и с чего бы тебе использовать его сейчас при наличии NTFS, UDF и exFAT?

Ты же сам его упомянул. А вообще-то, винда ни одной нормальной файловой системы не поддерживает, так что FAT норм. UDF не записывает, например, ntfs журналируемая, а exfat запатентованная и вообще-то разновидность fat.

Хреновый там юникод. прямо скажем.

Прекрати шланговать и осиль WriteConsoleW().

Нет, использовать нормальную файловую систему, а желательно, ещё и нормальную кодировку.

То есть терять информацию. Ок.

В линуксах:

 — при локали не-UTF-8 нельзя рассчитывать, что твои имена файлов хоть кто-то поймёт

 — при локали UTF-8 практически нечем работать с данными внутри файла в другой кодировке (нужность EUC-JP я уже раза три объяснил: перевод файлов в юникод — с необратимой потерей информации).

Вывод: юзер при любом раскладе страдает. Зато ФС «нормальная».

В венде:

 — при любой кодировке софта, даже написанного 15 лет назад, его имя файла читается всеми.

Весь нужный софт это уже умеет

4.2

Что gettext?

Не надо держать юникодные литералы как литералы в файле с сырцами, лол.

UDF не записывает

4.2

ntfs журналируемая

Конечно, это минус.

В венде:
— при любой кодировке софта, даже написанного 15 лет назад, его имя файла читается всеми.

А что насчёт твой японской кодировке, может японец-виндузоид сохранить свой файл, обозвав его в ней?

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

А в Windows с UTF-16 есть с чем работать с euc-jp?

при локали не-UTF-8 нельзя рассчитывать, что твои имена файлов хоть кто-то поймёт

А винде локаль файловой системы кроме utf16 вообще невозможна. А японец с своим eupjp может хотя бы локально работать с именами файлов в желаемой кодировке, но если ему их надо кому-то передать — то да, придётся имена файлов конвертировать.

То есть терять информацию. Ок.

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

Прекрати шланговать и осиль WriteConsoleW().

Для начала продемонстрируй её применение в коде, который правильно работает не только в Windows, но и в GNU/Linux.

А что насчёт твой японской кодировке, может японец-виндузоид сохранить свой файл, обозвав его в ней?

Софт автоматически сконвертирует имя файла в юникод, что вполне разумно. То же имя файла будет показываться у любого пользователя на компьютере независимо от локали. Потому, что Windows NT — многопользовательская ОС by design, а не терминал к minix.

А в Windows с UTF-16 есть с чем работать с euc-jp?

Да. И более того, в ней есть софт, работающий с shift-jis, который гнутые утилиты не умеют вообще (потому, что он ничерта не совместим с ASCII и появился до того, как появилась мания совмещать с ASCII всё). И этот софт работает с юникодными именами файлов, зачастую даже не подозревая о существовании юникода.

Для начала продемонстрируй её применение в коде, который правильно работает не только в Windows, но и в GNU/Linux.

#ifdef и прекрати ожидать невозможного + шланговать.

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

Нет.

В целом, о чём речь:

• Неюникодные кодировки нужны
• Но не в файловой системе многопользовательской ОС
  • Вообще, у файловой системы должна быть стандартная независимая от юзера кодировка
  • Например, юникод в NFC
  • Хоть и UTF-8, если речь идёт о линуксоподобных ОС
• И весь софт должен работать с ФС в этой кодировке независимо от локали

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

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

Кстати, зачем это нужно: имя файла — для людей, а не для роботов (файловой системе достаточно айнода). Набор байт без кодировки — не для людей.

И весь софт должен работать с ФС в этой кодировке независимо от локали

Eddy_Em с тобой не согласится.

Неюникодные кодировки нужны

Не факт. Можно просто доработать юникод и это правильнее.

#ifdef и прекрати ожидать невозможного + шланговать.

А почему, если код работает в GNU/Linux и не использует специфичных фич типа /proc и cgroups, он будет работать и на BSD без изменений, а чтоб поддерживать Windows нужно идти и изучать Windows API и нестандартные расширения стандартной библиотеки? Не говорит ли это о том, что Windows (включая микрософтовский компилятор) — кривое говно, несовместимое ни с POSIX, ни с C99, ни с C++11?

C99

Очевидно же, что в венде нет компилятора C как самостоятельного продукта. Только плюсы. Требовать от компилятора плюсов поддержки стандартов C — несколько странно. А C++11 не настолько уж давно появился, да и в M$VC++ есть то, в чём он впереди планеты всей (await, например).

будет работать и на BSD без изменений

Теоретик?

Можно просто доработать юникод и это правильнее.

Вперёд.

Требовать от компилятора плюсов поддержки стандартов C — несколько странно.

То есть в MSVC нет поддержки C?

А C++11 не настолько уж давно появился, да и в M$VC++ есть то, в чём он впереди планеты всей (await, например).

Это только proposed и это могут в стандарт и не принять. А вот u8"" уже приняли, например. Ну ладно, а стандарт C++ который был до 11 оно хотя бы полностью поддерживает?

Не говорит ли это о том, что Windows (включая микрософтовский компилятор) — кривое говно, несовместимое ни с POSIX, ни с C99, ни с C++11?

Это говорит о том, что POSIX, C99 и C++11 — кривое говно, не совместимое с Windows и микрософтовскими компиляторами.

Это говорит о том, что POSIX, C99 и C++11 — кривое говно, не совместимое с Windows и микрософтовскими компиляторами.

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

А вот u8"" уже приняли, например.

1. u8 не говорит, что файл исходника — в UTF-8

2. И не говорит, что между кавычками литерал в UTF-8. Он может быть в чём угодно.

3. Кроссплатформенной договорённости о кодировке плюсовых исходников нет, поэтому непонятно, почему ты одновременно ратуешь за кроссплатформенность и говоришь о utf-8 литералах, захардкоженных в плюсах.

Кроссплатформенной договорённости о кодировке плюсовых исходников нет

Это проблема. Но если такая будет, то почти наверняка все сойдутся на UTF-8, поэтому сейчас следует писать все исходники в UTF-8, а компиляторам на это указывать, если они сами не догадываются.

u8 не говорит, что файл исходника — в UTF-8

Но он зато говорит, что в исполнимом файле он должен быть закодирован в utf-8.

Как раз искал, что послушать. Годно, спасибо :)

На здоровье. ☺ Можете тогда ещё в этот тред заглянуть.