Война кодировок (отрезано от "удаления подстроки в sed")

[drBatty]

i	Уведомление от модератора /dev/random
	Отрезано отсюда: Удаление подстроки в sed

sciko
наверное то, что вам надо всё перевести сначала в cp1251, потом выстовить локаль cp1251, а потом обработать всё sed.
cp1251 - самая лучшая кодировка, ибо там все байты == допустимые символы (в отличие от утф), и кроме того, там буквы идут подряд (в отличие от koi8). Едингственное - беда с буквой ё, и с любыми не-русскими и не английскими буквами.

PS: да, ещё беда с 1251: у вас в системе наверняка не она, потому используйте не sed-одностроки, а sed-скрипты - пишите(в 1251) свои sed-команды в файлы, делайте их исполняемыми, и запускайте.

[/dev/random]

cp1251 - самая лучшая кодировка

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

[drBatty]

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

а почему этот форум в cp1251?

[t.t]

а почему этот форум в cp1251?

Как говорила одна моя очень милая преподаватель в институте, «тому що життя складне» (буквально «потому что жизнь сложная», но по-украински это лучше звучит).

[drBatty]

тому що життя складне

вот и я про то:
1) то, что приходит из www надо преобразовать во что-то одно, и это одно 1251. Хотя-бы потому, что обычно оно и так в 1251.
2) регулярные выражения не срабатывают на UTF-8, потому-что в UTF-8 есть несимволы (/./ совпадает с любым символом, ну а если это несимвол? тогда не совпадает. Соответственно /.*/ совпадает не с любой строкой, что обычно неожиданно)
3) utf-8 работает раза в полтора-два медленнее.
4) в 1251 можно написать любую большую русскую букву так /[А-ЯЁ]/, в utf & koi8 приходится вписывать весь алфавит.

вот и я использую "маздаевскую" кодировку :(

[watashiwa_daredeska]

2) регулярные выражения не срабатывают на UTF-8, потому-что в UTF-8 есть несимволы (/./ совпадает с любым символом, ну а если это несимвол? тогда не совпадает. Соответственно /.*/ совпадает не с любой строкой, что обычно неожиданно)

Бред какой. Надо просто определиться, с чем работать: со знаками или с кодпойнтами. Реализации регекспов, у которой /.*/ не каждую строку матчит, я что-то не видал еще.

3) utf-8 работает раза в полтора-два медленнее.

utf-8 вообще не работает. Это не программа.

4) в 1251 можно написать любую большую русскую букву так /[А-ЯЁ]/, в utf & koi8 приходится вписывать весь алфавит.

В Unicode русский алфавит тоже по порядку идет. И не только заглавный, но и строчный.

[t.t]

4) в 1251 можно написать любую большую русскую букву так /[А-ЯЁ]/, в utf & koi8 приходится вписывать весь алфавит.

Насчёт «несимволов» я не очень в курсе, но здесь могу контр-пример привести:

Код: Выделить всё

$ echo 'йцукенгшщзфывапролджячсмитьбюхэёъ' | sed 's/[а-я]//g'

$ echo 'ЙЦУКЕНГШЩЗФЫВАПРОЛДЖЯЧСМИТЬБЮХЭЁЪ' | sed 's/[А-Я]//g'

$

[ZyX]

4) в 1251 можно написать любую большую русскую букву так /[А-ЯЁ]/, в utf & koi8 приходится вписывать весь алфавит.

Насчёт «несимволов» я не очень в курсе, но здесь могу контр-пример привести:

Код: Выделить всё

$ echo 'йцукенгшщзфывапролджячсмитьбюхэёъ' | sed 's/[а-я]//g'

$ echo 'ЙЦУКЕНГШЩЗФЫВАПРОЛДЖЯЧСМИТЬБЮХЭЁЪ' | sed 's/[А-Я]//g'

$

Работает в grep (кажется, он использует ту же реализацию, что и sed), pcregrep (а также в grep -P), perl, но не работает в vim. Есть подозрение, что при смене локали на koi8-r это продолжит работать везде, кроме vim, в котором сломается совсем (уже имел «удовольствие» сидеть с ним на koi8-r).

[drBatty]

Бред какой. Надо просто определиться, с чем работать: со знаками или с кодпойнтами. Реализации регекспов, у которой /.*/ не каждую строку матчит, я что-то не видал еще.

Код: Выделить всё

doc@bx:~$ echo -e "ABC\xD1XYZ"
ABC?XYZ
doc@bx:~$ echo -e "ABC\xD1XYZ" | sed 's/.*/123/'
123?XYZ

utf-8 вообще не работает. Это не программа.

не придирайтесь к словам - sed с UTF-8 работает в 1.5-2 раза медленнее, чем в однобайтовой кодировке.
и это не минус sed, что она такая медленная - по умолчанию всякие perl работают с байтами.

В Unicode русский алфавит тоже по порядку идет. И не только заглавный, но и строчный.

Код: Выделить всё

doc@bx:~$ echo -e "ф" | sed 's/[a-z]/-/'
ф
doc@bx:~$ echo -e "ф" | sed 's/[а-я]/-/'
sed: -e выражение #1, символ 12: Неверный знак сортировки
doc@bx:~$ echo $LC_CTYPE

doc@bx:~$ echo $LC_COLLATE
C

а если подумать, то:

Код: Выделить всё

doc@bx:~$ export LC_COLLATE=$LANG
doc@bx:~$ echo $LC_COLLATE
ru_RU.UTF-8
doc@bx:~$ echo -e "ф" | sed 's/[а-я]/-/'
-

но всё равно - там в кодах "дыры", т.е. есть символы которые между а и я, но это не русские буквы.
И в старых версиях sed также неправильно работает UTF-8, о чём написано в Changelog'е

Код: Выделить всё

$ sed --version
GNU sed версия 4.2

а у вас?

[t.t]

Я совсем не вимер, но подозреваю, что уж где-где, а в нём-то настроить можно.

[drBatty]

PS: в GNU sed нет реализации регулярных выражений. Точнее есть, но отключена если доступна glibc. У здесь присутствующих - доступна, т.ч. это вовсе не глюк sed.

Я совсем не вимер, но подозреваю, что уж где-где, а в нём-то настроить можно.

я не очень понимаю, как это можно настроить, если буквы идут не по порядку? Какой смысл в выражении "от а до я", если там
абцдефгх...
или как-то так. Причём буква я - совсем не последняя :(

У меня - не работало, ни в sed, ни в vim.

[/dev/random]

а почему этот форум в cp1251?

Потому что соник выбрал cp1251, а при перекодировании возникают проблемы (в силу особенностей движка)

[drBatty]

Потому что соник выбрал cp1251, а при перекодировании возникают проблемы (в силу особенностей движка)

это я знаю. но вы хотели-бы другую? или нет? какую?

[Nazyvaemykh]

Не скажу, какая точно версия sed, но та, которая в Lenny, действительно, с Юникодом (utf-8) тормозит жутко. 4.2.1 уже так безбожно не тормозит.

Что касается vim, то всегда можно использовать внешние команды…

[drBatty]

Не скажу, какая точно версия sed, но та, которая в Lenny, действительно, с Юникодом (utf-8) тормозит жутко. 4.2.1 уже так безбожно не тормозит.

повторяю - в RE тормозов с UTF-8 быть не должно - там RE из glibc, только версии для windows тащут свою реализацию. А упомянутый мной глюк просто в некоторых случаях приводил к неправильной работе. К тому-же это и не новость:

ChangeLog

2008-09-29 Paolo Bonzini <bonzini@gnu.org>

* BUGS: Document s/.*.// behavior with invalid multibyte sequences.

просто англоязычных кодеров это похоже мало волнует, в отличие от русских.

[/dev/random]

это я знаю. но вы хотели-бы другую? или нет? какую?

Что будет на выходе - мне пофиг, хоть quoted-printable. Но внутри должен быть юникод. Неважно, какой - utf8, ucs2, любой. Иначе это чревато багами наподобие тех, которые можно наблюдать в "быстром редактировании".

[t.t]

Потому что соник выбрал cp1251, а при перекодировании возникают проблемы (в силу особенностей движка)

это я знаю. но вы хотели-бы другую? или нет? какую?

Я бы хотел utf-8. По многим причинам.

upd, поправка: согласен с Олегом, ucs2 тоже бы устроила.

[Nazyvaemykh]

Не скажу, какая точно версия sed, но та, которая в Lenny, действительно, с Юникодом (utf-8) тормозит жутко. 4.2.1 уже так безбожно не тормозит.

повторяю - в RE тормозов с UTF-8 быть не должно - там RE из glibc, только версии для windows тащут свою реализацию.

Да, это моя ошибка.
Проверял на машинах сильно разных по производительности. И на той, и на другой (sed 4.15 и 4.2.1) скорость работы простейшего скрипта в зависимости от локали (UTF-8 и C) меняется на порядок. Просто визуально 55.7 с и 3.48 с различаются гораздо сильнее, чем 1.53 с и 0.14 с. Это и ввело меня в заблуждение.

[watashiwa_daredeska]

а если подумать, то:

Garbage In, Garbage Out. Т.е. если по русски, то дерьмо на входе, дерьмо на выходе.

Всё, что может sed+cp1251, может и sed+utf-8. sed+utf-8 может гораздо больше. Не любая последовательность байтов является корректным utf-8, в отличие от cp1251. Медленно? Да, объем текста в utf-8 больше, чем в cp1251, обрабатывается, соответственно, тоже медленнее, но в 99.9% случаев это не имеет значения.

[drBatty]

Но внутри должен быть юникод. Неважно, какой - utf8, ucs2, любой. Иначе это чревато багами наподобие тех, которые можно наблюдать в "быстром редактировании".

да... согласен с вами.

Проверял на машинах сильно разных по производительности. И на той, и на другой (sed 4.15 и 4.2.1) скорость работы простейшего скрипта в зависимости от локали (UTF-8 и C) меняется на порядок.

тут сразу много причин:
1) самих байтов для обработки текста в 1.5-2 раза больше
2) буквы больше, и для таблиц недостаточно 256х32 бита. Уж не знаю, как это там реализованно, но даже простейший поиск обычного слова из-за этого дольше.
3) в 32х байтной архитектуре можно искать в строке сразу 32х буквенный шаблон. Беда в том, что для UTF это всего 16и буквенный, и его часто не хватает, приходится искать по частям.
4) в UTF-8 иные символы из 1го байта, а иные из двух, потому надо сначала выяснить границы символов.

Garbage In, Garbage Out.

ну вот когда очистят Сеть от дерьма, тогда можно и утф вводить :( А до тех пор приходится юзать разные костыли, вроде новой sed-команды z (а иначе даже не очистить стороку от несимволов, которые ни с чем не совпадают).

Всё, что может sed+cp1251, может и sed+utf-8. sed+utf-8 может гораздо больше.

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

Да, объем текста в utf-8 больше, чем в cp1251, обрабатывается, соответственно, тоже медленнее, но в 99.9% случаев это не имеет значения.

имеет ИМХО. я не согласен с цифрой 99.9, ИМХО что-то ближе к 80...
Но намного более важна проблемма надёжности:
Вот например такой скрипт выполняет любую команду, которую ему подсунули в качестве входа(я подсунул ls):

Код: Выделить всё

echo -e "--ф\xD1; ls" | sed -r 's/\W*(\w*).*/\1/;s/.*/echo "&"/e'

хотя по замыслу автора должен просто вывести первое слово на stdout...

[/dev/random]

Вот например такой скрипт выполняет любую команду, которую ему подсунули в качестве входа(я подсунул ls):

Код: Выделить всё

echo -e "--ф\xD1; ls" | sed -r 's/\W*(\w*).*/\1/;s/.*/echo "&"/e'

хотя по замыслу автора должен просто вывести первое слово на stdout...

А не надо использовать команду e. Лично я буду всеми руками за, если её удалят к чёртовой бабушке из sed'а.
Генерация кода на основе обрабатываемых данных - самая идиотская идея, которая когда-либо приходила в голову человека. Люди, вон, целые проекты пишут, наподобие PaX, чтобы _заблокировать_ генерацию/изменение кода на лету. А тут её добровольно запускают.

[watashiwa_daredeska]

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

В современном мире надо. А кроме алфавитов, в utf-8 много всяких полезных символов.

всегда можно записать особый символ как-то иначе, например в HTML через & #.

Т.е. вместо одной кодировки Вы предлагаете другую. Якобы другую. Ибо «&#» в HTML это тот же самый Unicode. Более того, с этой фигнёй вообще никакие регекспы не работают никак, в отличие от utf-8. Чем это лучше?

Вот например такой скрипт выполняет любую команду, которую ему подсунули в качестве входа(я подсунул ls):

Garbage in, garbage out. Поставьте на входе фильтр, который будет править невалидный utf-8.

Кстати, Ваш скрипт — полное барахло и не работает с предлагаемой Вами же кодировкой:

Код: Выделить всё

echo "first& #32;second& #32;word" | bla-bla-bla

P.S. Блин, как HTML-entities вставлять так, чтобы они не раскрывались?

[/dev/random]

P.S. Блин, как HTML-entities вставлять так, чтобы они не раскрывались?

Бьюсь над этим. Долбаный движок... И долбаная кодировка.

[ZyX]

P.S. Блин, как HTML-entities вставлять так, чтобы они не раскрывались?

У меня всегда получалось вставлять «&» как «&#38;»

[djalex]

я считаю пусть будет лучше одна кодировка на всех, и лучше если стандартом будет utf-8

а с мелкими проблемами рано или поздно будет покончено

[eddy]

Потому что соник выбрал cp1251, а при перекодировании возникают проблемы (в силу особенностей движка)

А я бы выбрал другую кодировку

[drBatty]

А не надо использовать команду e. Лично я буду всеми руками за, если её удалят к чёртовой бабушке из sed'а.

то, что молотком можно проломить голову - не повод запрещать молотки.

Кстати, Ваш скрипт — полное барахло и не работает с предлагаемой Вами же кодировкой:

с чем там у меня что-то не работает?

А я бы выбрал другую кодировку smile.gif

что-бы я не писал в этой теме, но всё одно - я попросту вынужден переходить на UTF-8...

[watashiwa_daredeska]

с чем там у меня что-то не работает?

Там же строчкой ниже пример, который не работает. Потому что html entities:
1. многобайтная кодировка, к тому же гораздо менее эффективная, чем utf-8;
2. один символ может быть записан несколькими способами ("«", "&#171;", "&#xab;", "&laquo;");
3. всё равно, это unicode, а значит в программе таблиц на 256 символов всё равно не достаточно.

[Nazyvaemykh]

Недавно обнаружил, буква «й», представленная комбинацией двух символов, «и» и «U0306, не удовлетворяет ни регулярному выражению ‘.{1}’, ни ‘.{2}’, ни ‘.{3}’, зато удовлетворяет выражению ‘.\+’. Речь здесь о GNU grep и UTF-8. Насколько такое поведение правильно?

[watashiwa_daredeska]

Насколько такое поведение правильно?

Зависит от локали, т.е. воспринимает ли grep входной поток как utf-8 или как однобайтную кодировку:

user@lobalhost

$ echo -e 'и\xcc\x861' й1 $ echo -e 'и\xcc\x861' | egrep '^.{2}1$' й1 $ echo -e 'и\xcc\x861' | LC_ALL=C egrep '^.{4}1$' й1