В X11 кодировкой по умолчанию для России становится UTF8

>"тупые сигнатуры" - это BOM, который есть часть стандарта UTF?

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

> бинарные заголовки в ТЕКСТОВЫХ файлах? ТУПОСТЬ!

бинарные заголовки в текстовых файлах придумал unicode.org а совсем не винда, а в Linux оно не поддерживается из-за вот этого самого #! в начале скрипта.

>А чем "текстовые" байты отличаются от "бинарных", а?

тем что представляют собой читаемые символы

>Простите, а вы можете назвать файлы в кодировках UTF-8 или, например, UCS-2/UCS-4(UTF-32) текстовыми в классическом смысле этого слова (т.е. в сравнении с однобайтными ?

да, а почему нет?

BOM — не бинарный и не заголовок. Это как раз вполне читаемый символ нулевой ширины.

> кто у нас эти стандарты сочиняет?

UTF-8 вообще сионские мудрецы придумали. Вы можете гнать на стандарты уникода и утф сколько угодно - но они уже есть. И нотепад этому стандарту следует. Следовательно, говорить о проблемах с утф8 (имеющимся стандартом - а не Вашей мечтой о нем) в нотепаде - 4.2. ЧСД.

>smbfs мертва. cifs. Если Вы пользуетесь мертвячиной - это Ваши проблемы.

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

какая разница cfs или smbfs? если и в том и другом случае указать codepage=utf-8 увидишь на русских шарах кракозяблы

>Это проблемы перла

это проблемы именно венды (кстати скажем у shell будет такой же результат, или у python)

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

и только вендулет тут "фпереди планеты всей"

Вы бы хоть доки про BOM почитали на досуге...

>и попробуй в юниксе этот сценарий пустить, и опять же поплюйся на этот псевдоюникод

текст будет в ucs-2, перловый интерпретатор его не понимает, и что юникс-винда - тут побоку

>smbfs мертва. cifs. Если Вы пользуетесь мертвячиной - это Ваши проблемы.

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

Я уже сказал - это проблемы всех скриптовых языков. Они не справляются с КОРРЕКТНЫМ (соответствующим стандарту) utf8 файлом. Кстати, любопытный эксперимент - попробовать предложить в bash патчик для этого дела.

ЗЫ Кстати, багрепорт про обработку текстовых файлов с BOM в жабке я нашел на сановском сайте.

> > additional Unicode semantics

> это что такое? citation needed ;)

А это надо читать в самом стандарте, процитированная фраза взята из The Unicode Standard ver. 5.0, Appendix C: Relationship to ISO/IEC 10646, p. 1095 (http://www.unicode.org/versions/Unicode5.0.0/appC.pdf).

>Я уже сказал - это проблемы всех скриптовых языков.

ага, все скриптовые языки виноваты, только виндовс и M$ вся в белом

>потому что написанный в UTF-8 локали файл в любой другой операционной системе нормально будет исполнен perl'ом, shell'ом, итп

Это только потому, что все необходимые символы [0..127] не изменятся и останутся однобайтовыми, а для работы с остальными придется писать дополнительный код

> ага, все скриптовые языки виноваты, только виндовс и M$ вся в белом

При чем тут MS???? Вы хотя бы слышите, что Вам говорят? Я создам КОРРЕКТНЫЙ (=соответствующий стандарту) utf8 файл с сигнатурой BOM в каком-нибудь другом редакторе (например, шестнадцатеричном) - и перл на нем сломает зубы. Это будет лично вина БГ?

Сколько раз надо объяснять, что корректность определяется только соответствием стандарту - а никак не Вашими мечтами или ожиданиями интерпретаторов скриптовых языков?

ЗЫ Если Вам так будет легче, можете считать форматы UTF8 и UTF16 нетекстовыми. Многие, кстати, так и считают.

>При чем тут MS???? Вы хотя бы слышите, что Вам говорят? Я создам КОРРЕКТНЫЙ

в чем смысл utf-8, как ты думаешь?

> Я уже сказал - это проблемы всех скриптовых языков.

В python проблем нет, а остальные - всё равно гамно, а не языки.

> ага, все скриптовые языки виноваты, только виндовс и M$ вся в белом

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

> p какого размера?

unit *p;

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

наглый гон

тьфу, простите. если на C, то

unsigned char *p;

> Я уже сказал - это проблемы всех скриптовых языков. Они не справляются с КОРРЕКТНЫМ (соответствующим стандарту) utf8 файлом. Кстати, любопытный эксперимент - попробовать предложить в bash патчик для этого дела.

Мне всегда казалось, что shebang интерпретируется _ядром_. Которое в этом месте не понимает ни BOM, ни многобайтных кодировок. Сам по себе перл, кажется, такие файлы вполне себе выполняет.

> И альтернативы всё равно нет. В UTF-32 они всё равно будут кодироваться даже не тремя, а 4-мя байтами. А UTF-16 - не хватает.

Это в каком смысле, "не хватает"? Иероглифы кодируются двумя байтами, закодировать можно любой символ (размер переменный 2 или 4 байта).

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

Да ну? А как же винда? Все там в UCS2 или UTF16, и никаких проблем особых не вылезло.

Разговоры о смысле (жизни) оставьте для кухонных посиделок. В данном вопросе есть стандарт - все остальное болтовня.

Кстати, а как бы еще прийти к одинаковому концу строки в текстовых файлах...

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

> Вы меня убедили! Даёшь истинно Русскую Православную Духовную кодировку!

Да пожалуйста!

http://www.irmologion.ru/ucsenc/necessity.html

http://www.irmologion.ru/ucsenc/ucsenc.html

http://www.irmologion.ru/ucsenc/ucsacc.html

>Разговоры о смысле (жизни) оставьте для кухонных посиделок. В данном вопросе есть стандарт - все остальное болтовня.

разговоры о смысле они самые важные.

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

а все эти стандарты итп - пустое.

итак повторяю вопрос: как ты думаешь в чем смысл utf-8, и почему именно utf-8 а не скажем 32 (с точки зрения программирования более простой) был повсеместно выбран и внедряется?

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

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

> разговоры о смысле они самые важные.

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

> почему именно utf-8 а не скажем 32 (с точки зрения программирования более простой) был повсеместно выбран и внедряется?

И даже это 4.2. Внутри виндов совсем не утф8 - а значит, слово "повсеместно" идет лесом. А утф8 выбран потому, что он позволяет использовать существующие ascii файлы. Корректный ascii файл --> корректный utf8 файл. Но никогда не обещали наоборот!

и второй вопрос: почему нигде кроме биллиных [недо]поделок эти сигнатуры не применяются?

> > И альтернативы всё равно нет. В UTF-32 они всё равно будут кодироваться даже не тремя, а 4-мя байтами. А UTF-16 - не хватает.

> Это в каком смысле, "не хватает"? Иероглифы кодируются двумя байтами, закодировать можно любой символ (размер переменный 2 или 4 байта).

KRoN73 наверное имел ввиду UCS-2, а не UTF-16. А в UCS-2 полностью не поместится текущая база Unicode («Unicode 5.1.0 contains over 100,000 characters»).

А преимуществ у представления UTF-16 никаких нет. Корректно обрабатывать UTF-16 ничем не легче чем UTF-8, зато последний экономнее в использовании памяти. Кроме того в случае UTF-16 появляется ещё необходимость следить за byte order и следовательно два варианта - BE и LE. Так что предпочтительнее всё же использовать UTF-8 или же переходить сразу на UTF-32.

Вы готовы утверждать про _весь_ софт в мире? Сильно...

>До тех пор, пока не принят стандарт.

на принятие стандарта сильно влияет тот у кого в кармане больше бабла.

вон смежная тема про опендокумент была (я краем глаза правда за этим слежу) ну приняли стандарт и че? поделки билли опять ему не соответсвует

>И даже это 4.2. Внутри виндов совсем не утф8

если выписать перечень операционных систем то венда из них будет всего лишь одной из многих

>А утф8 выбран потому, что он позволяет использовать существующие ascii файлы.

уже тепло

> Во-вторых, на лысом C пишут только злобные буратины, у которых других проблем и так вагон.

Расскажи это Линусу.

>Вы готовы утверждать про _весь_ софт в мире? Сильно...

ну давай пример невиндового редактора (имеющегося скажем в debian-репозитарии) сохраняющего utf-8 текстовые файлы с сигнатурой

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

> и второй вопрос: почему нигде кроме биллиных [недо]поделок эти сигнатуры не применяются?

Наверное из-за того что только в системе у Билли более используется представление UTF-16 и в нём BOM практически необходим. При использовании UTF-8 он не особо нужен, но всё же ПРЕДУСМОТРЕН стандартом.

Почитайте FAQ: http://unicode.org/faq/utf_bom.html#BOM

> на принятие стандарта сильно влияет тот у кого в кармане больше бабла.

Тогда Вы не на того гоните. Гоните на утф8, придумывайте новый - но не гоните на МС, в этом пункте МС невиновен, он следует стандарту. Придумаете стандарт лучше утф8 - мы его тут обсудим (когда его примет кто-нибудь серьезный и начнут использовать в софте).

> если выписать перечень операционных систем то венда из них будет всего лишь одной из многих

Это неважно. Утверждение "повсеместно" означает тотальность - которой мы не наблюдаем. Следовательно, Ваше утверждение 4.2. Я даже поленюсь напоминать Вам о том, что будет если рядом с каждой ОС в Вашем списке поставить кол-во пользователей - ибо этот аргумент в данном случае не важен. Всеобщности у утф8 нет.

> уже тепло

Это не тепло. Это и есть правда. Все остальное - Ваши мечты. Помедитируйте над вопросом о совместимости в одну сторону (чтение старых файлов новыми тулзами - но не наоборот).

s/более/более широко/

>Наверное из-за того что только в системе у Билли более используется представление UTF-16

зачем же тогда биллины поделки сохраняют тексты из блокнота не в utf-16 а в utf-8 или 1251?

а просто потому что фраза "в системе у Билли более используется представление UTF-16" не относится к системе билли. то есть да в API есть несколько функций для работы с utf-16 но это не значит что внутреннее представление данных в билли системе на utf-16 работает.

имена файлов, контент файлов итп даже то что делает сам билли практически нигде не встретишь этого utf16

Зачем? Мир не исчерпывается дебиановским репозитарием. Это Вы должны доказать, что не существует в мире ни одного редактора (включая тот, который я могу написать через 5 минут), который бы сохранял утф8 с BOM.

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

> но это не значит что внутреннее представление данных в билли системе на utf-16 работает.

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

http://en.wikipedia.org/wiki/UTF-16#Use_in_major_operating_systems_and_enviro...

UTF-16 is the native internal representation of text in the Microsoft Windows 2000/XP/2003/Vista/CE, Qualcomm BREW operating systems; the Java and .NET bytecode environments; Mac OS X's Cocoa and Core Foundation frameworks; and the Qt cross-platform graphical widget toolkit.[1][2][citation needed]

На чём оно работает?

>Это неважно. Утверждение "повсеместно" означает тотальность - которой мы не наблюдаем.

я когда говорил о тотальности написал "и только M$ шагает невногу"

>Всеобщности у утф8 нет.

какая из немертвых ОС (кроме биллиных поделок) сейчас не поддерживает utf-8 локали?

>Это не тепло. Это и есть правда. .... (чтение старых файлов новыми тулзами - но не наоборот).

это очень близко к правде. если бы изначально стояло "но не наоборот" никаких бы utf8 великов не изобретал бы никто.

это как переход с локали koi8 на локаль 1251 в (нормальных) редакторах возможность конверта кодировки отродясь была и перешли - переконвертили контент.

однако utf8 дает возможность именно плавного перехода на новую кодировку, то есть и новые и старые данные работают ну баги разве что появляются (часть которых обходится простой заменой одних #include-файлов на другие

>Вы бы и правда книжки почитали чтоль...

>http://en.wikipedia.org/wiki/UTF-16#Use_in_major_operating_systems_and_enviro...

ну да на заборе тоже написано нечто, а за забором как известно этого нечто нет

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

почему большая часть рунета в кодировке 1251, а не в utf16? ведь "известно" что UTF16 лежит в основе виндавс которой пользуется большинство?

Завязывайте, уже не смешно.

>Завязывайте, уже не смешно.

да это не смешно, когда такое количество народу как заведенные повторяют рекламную чушь от билли что якобы юникод давно и внутри венды :-\

> какая из немертвых ОС (кроме биллиных поделок) сейчас не поддерживает utf-8 локали?

Да вроде бы маководы жаловались на свой родный терминал.