Показывают белиберду, как обычно.

Вот за это мы и любим Эдичку. ☺

for Name in `ls -1`

И после этого ты ещё кого-то быдлокодером называешь?

Иди читай до просветления.

Впрочем покажи ещё скрипт rmspaces, может там это учтено?

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

Только не надо спорить. Вы оба частично правы и частично неправы.

1) Пробелы в именах файлов не всегда корректно обрабатываются софтом и скриптами — поэтому желательно не использовать их без нобходимости

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

В любом случае char — это байт сейчас.

в C# (.net), байт - это byte, а char - нормальнй юникодный символ

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

Так имя файла можно интерпретировать по разному, можно как юникод, можно как CP1251, CP866 или кои-8 (ну мало ли), или какая-нибудь CP932 (не однобайтовая).

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

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

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

Ну так utf-8 совместим с ascii на латинице. В чем проблема?

Ты о SP2/SP3 слышал или как?

😋

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

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

Слышал. Только какое отношение имеет исправление ошибок в ОС к поддержке UTF-8?

Только какое отношение имеет исправление ошибок в ОС к поддержке UTF-8?

А какое отношение имеет отсутствие поддержки Wi-Fi к ошибкам ОС?

мылосру не показатель

Вот, скриншотик ещё приложу для ценителей. ☺ http://i.imgur.com/msjf7jq.png

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

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

А что, всё правильно: нынче даже самых завалящий SEO'шник бомжара знает, что пробел надо заменять дефисом — он-читабельнее-подчёркивания :)

1) Пробелы в именах файлов не всегда корректно обрабатываются софтом и скриптами — поэтому желательно не использовать их без нобходимости

Башепроблемы.

Где тут кнопка «рекомендовать комментарий»? :3

Насчёт «читабельнее» не вполне согласен. Дефис заметнее, глаз за него сразу цепляется, но длинные имена с дефисами (около десятка) вместо пробелов выглядят как-то уж совсем коряво.

Подчёркивание, может быть, не так заметно, но таки читабельнее будет.

PS: Я заметил твой смайлик в конце, и, вероятно, был излишне серьёзен. И всё же: 2-3 дефиса в имени файла — не криминал.

Не поэтому. А потому что в fqdn не может быть подчеркивания.

Так там же сплошной ascii, не считая «Музыка»

Вообще-то, я пошутил, да и про fqdn речи не было… Предпочитают дефисы потому, что Google подчёркивания, говорят, как разделитель слов не воспринимает, и не рекомендует их использовать в URL'ах.

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

А я поддержал;)

мылосру не показатель

95 миллионов посетителей в сутки — это для тебя не показатель? o_O Ну, тут уже доктор нужен :)

<>[]()&$*:;,.

А какое отношение имеет отсутствие поддержки Wi-Fi к ошибкам ОС?

Никакого. Был бы фичреквест на UTF-8, наверняка и его бы запилили.

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

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

Так имя файла можно интерпретировать по разному, можно как юникод, можно как CP1251, CP866 или кои-8 (ну мало ли), или какая-нибудь CP932 (не однобайтовая).

Можно, конечно, но в современной системе его следует интерпретировать как UTF-8.

в C# (.net), байт - это byte, а char - нормальнй юникодный символ

А в mono? Как бы то ни было, не важно, так как речь о C и C++

Факт остаётся фактом, UTF-8 винда не поддерживает, из-за чего юникод в Windows несовместим с ASCII. А вот если бы не выпендривались, а сделали CP_UTF8, многое бы работало без переписывания приложений — например юникодные имена файлов можно было бы создавать без каких-либо специальных усилий как и в GNU/Linux.

<>[]()&$*:;,.

Это все ascii. Не зря же эти символы в Си и Перл издавна используются

Это всё знаки препинания и спецсимволы. Угадайте чем в этом каталоге будет блевать говнокод, который Эдди выше выдавал за скрипт?

переменные окружения LC_* и LANG. Прописанные в стандарте.

Опять же, в каком стандарте? Покажи ссылку на MSDN

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

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

А вот если бы не выпендривались, а сделали CP_UTF8

И сломали бы совместимость, ага

Как бы то ни было, не важно, так как речь о C и C++

Изначально речь была о поддержке в windows. Так что это уже проблемы не системы, а реализации C и C++

это ж рунет

наверняка

у MS всё так

А так это само собой. Я у него из профиля просто шикарнейший коментарий вытащил:

Eddy_Em ☆☆☆☆☆ (08.04.2014 21:46:51) Я - не программист! Помните это.

... многое объясняет :)

// а вот тут даже доставляет: http://storage6.static.itmages.ru/i/14/0408/h_1396989841_4164154_79d0451a93.png

UTF-8 винда не поддерживает, из-за чего юникод в Windows несовместим с ASCII

Как раз совместим, и не только с ASCII, но и с локальной кодовой страницей

Опять же, в каком стандарте? Покажи ссылку на MSDN

MSDN — это не стандарт и никак не авторитет. http://msdn.microsoft.com/en-us/library/wyzd2bce.aspx но если уж так хочется.

Неочевидно. К тому же есть много старого софта, который нужно поддерживать.

Вот потому-то и нужно использовать ascii-совместимый UTF8, а не вводить UTF16, требующий переписывать существующий код.

Как с этим в линуксе, попробуй установи-запусти какой-нибудь пакет для Debian 2.0

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

Как раз совместим

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

А ты попробуй запустить w16 приложение на Windows 8

И сломали бы совместимость, ага

С чем? Как раз UTF8 совместим с ASCII и совместимости ни с чем не ломает.

Изначально речь была о поддержке в windows. Так что это уже проблемы не системы, а реализации C и C++

Стандартная библиотека входящая в Windows — это часть Windows, очевидно.

Стандартная библиотека входящая в Windows — это часть Windows, очевидно

Если уж говорить о windows, в winapi тип данных в 1 байт называется BYTE, а символьный TCHAR зависит от параметров юникода.

http://msdn.microsoft.com/en-us/library/wyzd2bce.aspx но если уж так хочется.

И где противоречия? Про юникод, имена файлов

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

Можно не переписывать, а оставить как есть. Если в настройках стоит русская локаль, будет нормально работать с CP1251.
Тогда как UTF-8 локаль ломает совместимость со всеми 1-байтными кодировками

Можно юзкейс для не UTF-8 локали? Спрашиваю потому, что моя личная поделка ничего кроме UTF-8 не понимает.

time grep жопа /dev/urandom

на не utf-8 локалях на 3 порядка быстрее, т.е. тебе в 1000 раз меньше времени нужно чтобы найти жопу в рандоме.

Тогда как UTF-8 локаль ломает совместимость со всеми 1-байтными кодировками

Какую совместимость, при каких условиях? Можно сделать функцию API. которая позволяет выбрать кодовую таблицу ANSI, если программа выбирает CP_UTF8 — следовательно она знает, как работать с юникодом, если выбирает что-то другое — не знает. Старые программы выбирают CP1251 и работают как работали, а система прозрачно конвертирует их вывод в UTF8. Новые программы делают один API-вызов при инициализации а дальше работают как привычно.

Можно не переписывать, а оставить как есть. Если в настройках стоит русская локаль, будет нормально работать с CP1251.

Тогда не будет возможности работать с символами за пределами CP1251, типа греческих букв без полного переписывания приложения. А вот в предложенном варианте — достаточно всего лишь поменять кодовую таблицу на UTF8 и исправить все места, где используется предположение, что 1 символ == 1 байт, которых может и не быть в принципе, если программа не работает со строками — и она продолжит работать. Объём исправлений не больше чем для локализации программы на другой язык, где требуются символы с переменной длиной.

Кроме того, ввод wchar_t ломает совместимость со стандартом C++ и требует переписывания программ, до этого успешно работавших с юникодом (пример выше)

И где противоречия?

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

Если ты считаешь xp sp0 и xp sp3 одной и той же операционкой - то ты глуп.

вот смотри, такой код

#include "stdafx.h"
#include <iostream>
#include <fstream>

int _tmain(int argc, _TCHAR* argv[])
{

	char* fn = "ололdsf.txt";
	std::ofstream outfile (fn);
	char ch=65;
	outfile.put(ch);
	return 0;
}

Можно сделать функцию API. которая позволяет выбрать кодовую таблицу ANSI

Можно. Осталось только научить ею пользоваться кучу legacy-софта, давно не поддерживаемого и проприетарного, но необходимого некоторым

это ж рунет

За границей уже не 1990-е. И за устаревшую неподдерживаемую ОС особо не держатся:

Steam — 5%: http://store.steampowered.com/hwsurvey

w3schools — 10%: http://www.w3schools.com/browsers/browsers_os.asp

Steam

Тебе сказать почему это не показатель или сам догадаешься?

w3schools

у тебя с каждым разом источники всё авторитетнее и авторитетнее

Станочки на WinXP Prof SP3 до сих пор на предприятия приходят от немцев с австрийцами и те как-то не особо спешат свой софт под win7 переписывать.

у тебя с каждым разом источники всё авторитетнее и авторитетнее

Угу. Только все они показывают, что XP весьма далеко до 30%. И доля всё падает.

Фактические контраргументы будут или так и останешься при пролетарском чутье?

Станочки на WinXP Prof SP3 до сих пор на предприятия приходят

И там так актуален вопрос utf-8? o_O — Работают ли современные дистрибутивы с локалями отличными от *.UTF-8? (комментарий)

Проблемы будут когда будешь копировать на различные носители с ntfs или fat. Ещё могут быть проблемы, если по webdav куда заливать будешь.

http://gs.statcounter.com/#desktop-os-ww-monthly-201303-201403

вот смотри, такой код

Не компилируется.

In function `_start': ... csu/../sysdeps/x86_64/elf/start.S:109: undefined reference to `main'
collect2: ld returned 1 exit status

Почему у тебя _tmain вместо main и какой-то _TCHAR вместо char?

ta-filetest.cpp:1:20: fatal error: stdafx.h: No such file or directory
compilation terminated.

После исправления — опять какой-то нестандарт.

После убирания заголовка:

ta-filetest.cpp: In function ‘int main(int, char**)’:
ta-filetest.cpp:7:16: warning: deprecated conversion from string constant to ‘char*’

Но всё-таки работает.

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

Совместимость с GNU/Linux не полная, так как добавлена несовместимая фигня, которую пришлось убирать. Без неё бы не работало? Почему?

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

Можно. Осталось только научить ею пользоваться кучу legacy-софта, давно не поддерживаемого и проприетарного, но необходимого некоторым

Зачем? Есть же «режим совместимости». Если он включен — выбирается таблица ANSI в тех же настройках, причём возможно разная для разных приложений. Если выключен — по умолчанию выбирается CP_UTF8 и приложения, работающие с юникодом в линуксе компилируются и работают без изменений.

Если пишется новая версия приложения — переписать придётся только строковые операции, а всё остальное остаётся без изменений.

Выбранный же мелкомягкими метод с UTF16 требует не только изменить строковые операции, но ещё заменить все вызовы API, чтоб перейти на него и несовместим с POSIX. То есть однозначно хуже чем CP_UTF8

Без неё бы не работало? Почему?

Потому что это проект MSVS.

Зачем? Есть же «режим совместимости». Если он включен — выбирается таблица ANSI

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

Если пишется новое приложение — переписать придётся только строковые операции, а всё остальное остаётся без изменений.
Выбранный же мелкомягкими метод с UTF16 требует не только изменить строковые операции, но ещё заменить все вызовы API, чтоб перейти на него и несовместим с POSIX

Фигню написал. Если приложение написано правильно (в соответствии с winapi, TCHAR для символов), то достаточно написать «#define UNICODE», или включить опцию в свойствах проекта

То есть однозначно хуже чем CP_UTF8

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

До сих пор место экономишь?

В квотезы!