LINUX.ORG.RU

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

 , , ,


0

0

Три часа назад, не без помощи со стороны svu, Daniel Stone внёс в код libX11 важное изменение, лог которого звучит следующим образом: "так как никто не пользуется кодировкой 8859-5, то кодировкой по умолчанию для России будет UTF-8".

Не прошло и 20 лет...

>>> Подробности



Проверено: anonymous_incognito ()
Последнее исправление: CYB3R (всего исправлений: 1)

Ответ на: комментарий от yk4ever

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

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

xargs ★★★
()
Ответ на: комментарий от xargs

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

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

Eshkin_kot ★★
()
Ответ на: комментарий от SKYRiDER

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

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

xargs ★★★
()
Ответ на: комментарий от xargs

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

anonymfus ★★★★
()
Ответ на: комментарий от xargs

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

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

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

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

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

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

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

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

xargs ★★★
()
Ответ на: комментарий от xargs

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

svu ★★★★★
()
Ответ на: комментарий от xargs

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

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

frame ★★★
()
Ответ на: комментарий от svu

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

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

anonymous
()
Ответ на: комментарий от xargs

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

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

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

xargs ★★★
()
Ответ на: комментарий от xargs

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

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

frame ★★★
()
Ответ на: комментарий от xargs

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

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

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

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

xargs ★★★
()
Ответ на: комментарий от svu

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

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

yk4ever
()
Ответ на: комментарий от xargs

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

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

yk4ever
()
Ответ на: комментарий от yk4ever

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

наглый гон

xargs ★★★
()
Ответ на: комментарий от svu

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

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

anonymous
()
Ответ на: комментарий от KRoN73

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

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

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

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

anonymous
()
Ответ на: комментарий от xargs

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

svu ★★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

svu ★★★★★
()
Ответ на: комментарий от svu

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

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

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

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

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

xargs ★★★
()
Ответ на: комментарий от Evgueni

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

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

anonymous
()
Ответ на: комментарий от xargs

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

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

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

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

svu ★★★★★
()
Ответ на: комментарий от anonymous

> > И альтернативы всё равно нет. В 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.

SKYRiDER ★★★
()
Ответ на: комментарий от svu

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

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

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

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

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

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

уже тепло

xargs ★★★
()
Ответ на: комментарий от yk4ever

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

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

anonymous
()
Ответ на: комментарий от svu

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

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

xargs ★★★
()

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

anonymous
()
Ответ на: комментарий от xargs

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

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

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

SKYRiDER ★★★
()
Ответ на: комментарий от xargs

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

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

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

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

> уже тепло

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

svu ★★★★★
()
Ответ на: комментарий от SKYRiDER

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

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

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

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

xargs ★★★
()
Ответ на: комментарий от xargs

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

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

svu ★★★★★
()
Ответ на: комментарий от xargs

> но это не значит что внутреннее представление данных в билли системе на 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]

svu ★★★★★
()
Ответ на: комментарий от svu

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

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

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

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

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

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

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

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

xargs ★★★
()
Ответ на: комментарий от svu

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

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

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

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

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

xargs ★★★
()
Ответ на: комментарий от SKYRiDER

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

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

xargs ★★★
()
Ответ на: комментарий от xargs

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.