LINUX.ORG.RU

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

Вы говорите как сторонник UTF-8. Сторонники UTF-32 думают иначе.

Я говорю как сторонник фактов. Переход с однобайтного ада на utf8 решил кучу проблем. Переход на utf32 не решает ни одной, зато ломает кучу софта.

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

С KOI8-R тоже просто работают.

Правда теперь им нужно перекодировать весь текст из/в utf8, отказаться от части программм и ныть на форумах, что однобайтовые кодировки живы.

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

Во-первых, кругом полно текста в самых разных кодировках, а не только в UTF-8. Во-вторых, юзер может настроить всё так, что к нему многие тексты автоматически будут приходить в кодировке его локали (какая бы она ни была). В-третьих, большинство софта, особенно GNU'тый мейнстрим, продолжает поддерживать однобайтные кодировки. Более того, в рамках проекта GNU развивается тот же однобайтный текстовый редактор moe. Так что, всё просто работает.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

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

HTTP на 90% Unicode. JSON и YAML - тоже, это зашито в стандартах. EPUB/FB в Unicode.

Во-вторых, юзер может настроить всё так, что к нему многие тексты автоматически будут приходить в кодировке его локали (какая бы она ни была). В-третьих, большинство софта, особенно GNU'тый мейнстрим, продолжает поддерживать однобайтные кодировки.

Автоматически ничего не будет, кто-то должен делать декодирование.

Более того, в рамках проекта GNU развивается тот же однобайтный текстовый редактор moe. Так что, всё просто работает.

А еще GNU развивает свой savannah. Только он никому не нужен.

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

HTTP на 90% Unicode. JSON и YAML ... кто-то должен делать декодирование

Это автоматически делает lynx. И ему фиолетово из интернета текст или локальный.

Я вообще могу просто закинуть в одну директорию кучу *.pdf, *.djvu, *.chm, *.epub, *.fb2, *.ps, *.doc, *.docx, *.rtf, *.lit, *.ppt и *.html файлов, запустить свои скрипты, и получить на выходе автоматически готовые текстовые файлы в KOI8-R.

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

Круть! Свои два чая с пирожками ты заслужил!

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

Я вообще могу просто закинуть в одну директорию кучу *.pdf, *.djvu, *.chm, *.epub, *.fb2, *.ps, *.doc, *.docx, *.rtf, *.lit, *.ppt и *.html файлов, запустить свои скрипты, и получить на выходе автоматически готовые текстовые файлы в KOI8-R.

Вот видишь. А пользователи UTF-8 всей этой мастурбацией не занимаются.

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

Чтобы получить текст в UTF-8 юзерам UTF-8 тоже нужно конвертировать *.pdf, *.djvu, *.chm, *.epub, *.fb2, *.ps, *.doc, *.docx, *.rtf, *.lit, *.ppt и *.html файлы в plaintext. То, что скрипт не только сконвертирует всё это в plaintext, но также заодно и сконвертирует в другую кодировку, для юзера ничего не поменяет. И тот и другой юзеры просто запускают по скрипту.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Зачем «юзеру» конвертировать еще и «заодно» в какую-то кодировку, со чтением которой потом возникнет куча проблем?

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

Затем, что мы говорим про 2-х юзеров, которые юзают ядерную консоль без иксов и желают удобно читать тексты в less'е. Разница только в том, что у одного юзера локаль KOI8-R, а у другого - UTF-8. Рассматривать всё это надо именно так. Иначе и юзеру с локалью KOI8-R совсем не надо ничего конвертировать - в иксах просмотрщики и так откроют что угодно.

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

Иначе и юзеру с локалью KOI8-R совсем не надо ничего конвертировать - в иксах просмотрщики и так откроют что угодно.

Телеграму это расскажи :)

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

Затем, что мы говорим про 2-х юзеров, которые юзают ядерную консоль

Слава б-гу, что вас таких всего двое.

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

Вы зачем прыгаете с одной темы на другую? Если уж говорим о том, что в интернете почти всё, включая *.epub и *.html файлы, в UTF-8, то говорим конкретно об этом. Клиенты сетевых IM протоколов - отдельная тема.

Нормально написанные сетевые клиенты учитывают, что у юзера может быть любая локаль, и обеспечивают прозрачное конвертирование между сетью и юзером. Клиент telegram-cli этого не учитывает чем я и возмущался. bitlbee + telegram-purple, как я уже писал выше, реализованы нормально и позволяют работать с любой локалью. При этом, да, не всем и не всегда нужен телеграм.

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

Вы зачем прыгаете с одной темы на другую? Если уж говорим о том, что в интернете почти всё, включая *.epub и *.html файлы, в UTF-8, то говорим конкретно об этом. Клиенты сетевых IM протоколов - отдельная тема.

Какая разница? Текст он и есть текст.

Нормально написанные сетевые клиенты учитывают, что у юзера может быть любая локаль, и обеспечивают прозрачное конвертирование между сетью и юзером. Клиент telegram-cli этого не учитывает чем я и возмущался. bitlbee + telegram-purple, как я уже писал выше, реализованы нормально и позволяют работать с любой локалью. При этом, да, не всем и не всегда нужен телеграм.

Слава богу, это уже потихоньку выпиливают.

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

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

Какая разница? Текст он и есть текст.

Разница в том, где именно этот текст и какие клиенты каких протоколов в наличии. Сеть - понятие довольно широкое. При этом выше речь уже шла конкретно о конвертировании __локальных файлов__ и, при этом, __не в plaintext'е__ в нужный plaintext.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

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

В нормальных консольных клиентах нормально работают интернет-банки? Нет? Соснольные клиенты идут лесом.

Разница в том, где именно этот текст и какие клиенты каких протоколов в наличии. Сеть - понятие довольно широкое. При этом выше речь уже шла конкретно о конвертировании __локальных файлов__ и, при этом, __не в plaintext'е__ в нужный plaintext.

Какой дебил конвертирует pdf в текст?

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

Разным людям нужно разное. *.pdf файлы тоже бывают разные. Не только с иллюстрациями. Их содержимое зачастую совсем или почти совсем ничем не отличается от обычного текста (исключением, пожалуй, являются только сканированные документы/книги и сложно форматированные документы). Кстати, никто не отменял того, что и в ядерной консоли юзер может сконвертировать *.pdf файлы в *.jpeg'и и смотреть эти картинки графическим просмотрщиком. Но, если юзеру нужен именно plaintext для less'а и grep'а, то ему нужен именно plaintext.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 2)
Ответ на: комментарий от saahriktu

Разным людям нужно разное. *.pdf файлы тоже бывают разные. Не только с иллюстрациями. Их содержимое зачастую совсем или почти совсем ничем не отличается от обычного текста (исключением, пожалуй, являются только сканированные документы/книги и сложно форматированные документы). Кстати, никто не отменял того, что и в ядерной консоли юзер может сконвертировать *.pdf файлы в *.jpeg'и и смотреть эти картинки графическим просмотрщиком. Но, если юзеру нужен именно plaintext для less'а и grep'а, то ему нужен именно plaintext.

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

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

Так локально юзеру и не нужно ничего перекодировать если у него текстовые файлы в кодировке его локали. Из документов, которые не являются plaintext'ом, plaintext добывать всё равно надо. И тут как юзер локили KOI8-R, так и юзер локали UTF-8, просто запускают по скрипту (между скриптами лишь маленькая разница). И получают результат. Юзер локали UTF-8 получает текстовые файлы в локали UTF-8. Юзер локали KOI8-R получает текстовые файлы в локали KOI8-R. С одними и теми же усилиями.

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

Так локально юзеру и не нужно ничего перекодировать если у него текстовые файлы в кодировке его локали. Из документов, которые не являются plaintext'ом, plaintext добывать всё равно надо. И тут как юзер локили KOI8-R, так и юзер локали UTF-8, просто запускают по скрипту (между скриптами лишь маленькая разница). И получают результат. Юзер локали UTF-8 получает текстовые файлы в локали UTF-8. Юзер локали KOI8-R получает текстовые файлы в локали KOI8-R. С одними и теми же усилиями.

$ qpdfview file.pdf

Смотри, не нужно ничего добывать и кодировать!

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

Нет, нужно. Даже когда у юзера локаль UTF-8. Но, нет ни иксов, ни Qt, ни qpdfview. Конечно, повторяю, он может захотеть посмотреть его картинками. Но, это уже другой случай. А для less'а и grep'а добывать plaintext таки нужно в любом случае. Даже если у юзера локаль UTF-8.

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

Но ведь это тоже требует монитора! Почему нет вывода на ленту? Правда она тоже не всем нужна, лучше на нейроинтерфейс.

StReLoK ☆☆
()
Ответ на: комментарий от kirk_johnson

Про серверы никто не говорит. Не всем нужны иксы на десктопе. А если юзеру всё-таки нужны иксы, то ему, повторяю, и при локали KOI8-R ничего перекодировать чтобы просмотреть PDF/DJVU в просмотрщике не нужно.

Говорить о конвертировании текста имеет смысл именно в контексте plaintext'а, less'а и grep'а. Во всех остальных случаях, подчёркиваю ещё раз, нет никакого смысла говорить о конвертировании вообще. Только когда юзер работает непосредственно с plaintext'ом.

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

Не всем нужны иксы на десктопе.

Ведь иначе не получится страдать!

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

Глупости какие-то. Вот разрабы irssi почему-то говорят.

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

Вы опять смешиваете разные случаи в одну кучу? Мы говорим конкретно о документах. *.pdf, *.djvu, *.txt, *.epub,... - вот это вот всё. Здесь юзеру нужно конвертировать только plaintext если он работает с plaintext'ом. А в иксах юзеру любой локали совершенно не нужно конвертировать *.pdf'ы и *.epub'ы.

А текст в сетевых IM-клиентах - это не то, что получает юзер когда с ними работает. Если бы он получал текст текстом, то он мог бы применять к нему iconv скриптами и проблем бы не было. И когда юзер пишет такие сетевые IM-клиенты на bash'е, то он может просто вкручивать туда iconv - и никаких проблем. Проблемы у софта, который держит текст в себе. И тут уже нужно его крутить чтобы он держал его в себе правильно.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Вы опять смешиваете разные случаи в одну кучу? Мы говорим конкретно о документах. *.pdf, *.djvu, *.txt, *.epub,... - вот это вот всё.

Это ты о них говоришь.

А в иксах юзеру любой локали совершенно не нужно конвертировать *.pdf'ы и *.epub'ы.

А разработчикам нужно. И некоторым это надоело.

А текст в сетевых IM-клиентах - это не то, что получает юзер когда с ними работает. Если бы он получал текст текстом, то он мог бы применять к нему iconv скриптами и проблем бы не было.

Зачем ему это делать? Сейчас во все протоколы зашивают, что они должны быть в UTF-8.

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

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

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

Это ты о них говоришь.

Продолжая Ваше продолжение. Я сказал, что юзер может настроить всё так, что все тексты будут приходить ему автоматические в его локали. Вы сказали, что автоматически ниего никогда не конвертируется. Я привёл конкретный пример с документами. Вы сказали, что, мол, юзеру локали UTF-8 (который сидит в иксах) ничего конвертировать не надо (только потому, что он сидит в иксах и смотрит картинки в окошках)... Ну и т.д. И в этот же контекст Вы зачем-то примешиваете сетевые IM-протоколы. В то время как о них я говорил отдельно.

Зачем ему это делать?

Затем, что у юзера локаль не UTF-8. Нормальный софт умеет в фоне перекодировать текст от пользователя в UTF-8 и обратно. И всё прекрасно работает.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Разным людям удобно разное.

Я от тебя только и слышу что «перекодирование», «скрипты», «ваш софт должен уметь». Удобство-то где?

Только вот не начинай про байтики и строки на C. Для этого есть более подходящие инструменты.

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

У юзеров локали KOI8-R уже есть софт и скрипты, которые выполняют перекодирование в фоне автоматически.

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

У юзеров локали KOI8-R уже есть софт и скрипты, которые выполняют перекодирование в фоне автоматически.

Их можно выкинуть нахрен всего лишь поменяв локаль.

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от neuer_Reedych

Да как-то начал менять аватарки и запутался. В итоге поставил последнюю попавшуюся под руку. Сейчас верну одну из прежних.

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