- 1
find . -type f -exec perl -n -e 'print "{}:$.$_" if(/不聞不若聞之,聞之不若見之/);' {} \;
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−113
find . -type f -exec perl -n -e 'print "{}:$.$_" if(/不聞不若聞之,聞之不若見之/);' {} \;
А знаете почему? - Потому что Греп - говно.
tirinox 14.01.2015 21:09 # 0
wvxvw 14.01.2015 21:17 # 0
Stallman 14.01.2015 21:19 # 0
wvxvw 14.01.2015 21:27 # 0
Stallman 14.01.2015 21:42 # 0
wvxvw 14.01.2015 21:56 # 0
3.14159265 14.01.2015 22:09 # 0
roman-kashitsyn 14.01.2015 21:19 # 0
wvxvw 14.01.2015 21:25 # 0
Stallman 14.01.2015 21:48 # 0
bormand 14.01.2015 21:58 # 0
wvxvw 14.01.2015 22:01 # 0
bormand 14.01.2015 22:21 # 0
P.S. Насчет регулярок - просто перегони в юникодные строки, с ними, емнип, всё норм. Что я делаю не так?
wvxvw 14.01.2015 22:31 # 0
- У меня получалось, что либо type - str, либо если пытаться перекодировать, то получается полная херня, никак не совпадающая с юникодными кодпоинтами, либо я это вообще не могу распечатать, т.е. оно валится с ошибкой конвертации, либо при печати, либо при вызове format().
bormand 14.01.2015 22:48 # 0
Stallman 14.01.2015 22:34 # 0
wvxvw 14.01.2015 22:42 # 0
Вот это примерно воспроизводит ситуацию. Дословно не помню, код остался на работе. Вобщем смысл в том, что это головняк (особенно всилу того, что эти принты расставлены в библиотечном коде).
bormand 14.01.2015 22:51 # 0
wvxvw 14.01.2015 22:57 # 0
bormand 14.01.2015 23:00 # 0
wvxvw 14.01.2015 23:10 # 0
Говорю я это не гипотетически. В экшнскрипте, не смотря на кучу плохих решений, была внезапамятные времена возможность System.setCodepage() - работала глобально для всех строк. Но потом, что-то Макромедию осенило, и они это убрали, заменив все на Юникод, а для желающих поработать с однобайтными строками дали ByteArray. Который, конечно не работает ни с регулярками, ни с другими строковыми функциями. И однобайтные строки исчезли впринципе. Т.е. до сих пор есть люди, которые пишут на АС2 (который уже 10 лет как не развивается), но однобайтовых строк я не видел уже лет семь, а то и больше.
bormand 14.01.2015 23:15 # 0
Считаем юникодную строку нормальной, а все остальные - закодированными (в какую-то кодировку, лол). Тогда всё встаёт на свои места.
В третьем питоне по сути и есть массив байт (просто массив байт) и строка (юникодная, без конкретной кодировки). И они друг в друга тупо не кастуются без decode/encode. А вот во втором есть мультибайтовая строка (str), юникодная строка (unicode) и этот сраный автокаcт c кодеком ascii по-умолчанию (и вроде бы сменить его никак).
wvxvw 14.01.2015 23:29 # +1
Они какогото хера добавили locale.getpreferredencoding() и sys.getfilesystemencoding() - своеобразный корейский рандом, который кто-то может использовать где-то, и потом в чужой програме все порушится. open() в таком случае будет себя вести неадекватно. Человек не должен писать codecs.open(file, encoding="utf-8") и т.п. херню, чтобы получить строку в формате по умолчанию. Тот, кто хочет приключений должен страдать, а не тот, кто хотел просто побыстрее сделать и забыть.
bormand 14.01.2015 23:30 # 0
В третьем и не дают! И большая часть воплей со стороны питонистов как раз из-за того, что там далеко не все методы, которые есть у строки.
guest 19.01.2015 12:34 # 0
Есть такое. Но в 3 появился необязательный параметр "кодировка" у str/bytes.
>Просто вообще не нужно было никаких encode/decode/unicode - только юникодные строки. Кто хочет неюникода - пусть страдает (использует самодельные списки и т.п.) вот от этого ошибок заметно поубавилось.
Поехавший, что предлагаешь на замену byte[]? Кстати, ты предлагаешь взять опыт жавы. Питон потихоньку к ней идет :)
Stallman 14.01.2015 23:14 # 0
Это пхпитонисты.
bormand 14.01.2015 23:27 # +1
wvxvw 14.01.2015 23:48 # 0
bormand 14.01.2015 23:54 # 0
Ну упадёт на print(group). Что в этом такого? Юзер приказал высрать русские буквы в latin-1, а они в latin-1 непредставимы. И остаётся или замести проблему под ковёр и вопросиков нахуярить, или исключение кинуть. ССЗБ короче. Как и вывод японских иероглифов, если в консоли cp1251.
wvxvw 14.01.2015 23:58 # 0
bormand 14.01.2015 23:59 # 0
Скорее всего для интеграции с legacy программами. Например следующая программа в конвейере жрёт только koi8-r, или мы перенаправляем вывод в файл, и хотим cp1251. Спорно, конечно, тут iconv проще засунуть.
> кто-то ею воспользуется, чтобы пофиксить свою неработающую програму
И это его личная проблема. Он так и локаль может поставить latin1, а потом жаловаться, чего это русские буквы не выводятся.
wvxvw 15.01.2015 00:21 # 0
wvxvw 15.01.2015 12:45 # +1
bormand 15.01.2015 15:03 # 0
wvxvw 15.01.2015 15:15 # +1
wvxvw 14.01.2015 22:46 # 0
bormand 14.01.2015 22:54 # 0
Чтобы читать файлы, сгенеренные прогами 20го века. В третьем питоне аргументы сразу в юникоде, тащемта.
bormand 14.01.2015 22:57 # 0
Регулярка точно юникодная была? Потому что регулярка r"[а-я]" (не путать с ur"[а-я]") парсится вообще хуй-пойми как. Что-то типа \xd0 диапазона от \xb0 до \xd1 и \x8f. Так что там запросто всякая хуйня попадёт. И да, искать такая регулярка будет побайтово, не посимвольно.
wvxvw 14.01.2015 23:02 # 0
Stallman 14.01.2015 23:12 # 0
wvxvw 14.01.2015 23:30 # 0
bormand 14.01.2015 23:34 # +2
Юникод, сам по себе, не имеет никакого байтового представления. Это просто коды символов (codepoint вроде бы называется). И записать в файл его нельзя, для этого нужен кодек, записывающий эти кодепоинты в какой-то кодировке (просто питон неявно подставляет какой-то по умолчанию).
А utf-8 - это одна из кодировок, отображающих байты <-> коды символов. От всяких уебанских кодировок типа cp1251 она отличается только одним - в ней представимы все символы юникода.
str() в utf-8 в питоне 2.х - НЕ ЮНИКОДНАЯ СТРОКА. Это надо написать в начале мана крупным шрифтом и заставлять всех питонистов повторять как заповедь по утрам... Юникодная строка в питоне 2.х unicode() и только unicode(). И ее литерал пишется как u"..." и ur"...".
wvxvw 14.01.2015 23:39 # 0
bormand 14.01.2015 23:43 # 0
P.S. Благодаря юникоду длину строки теперь можно считать в:
- в кодепоинтах
- в глифах (ту же ё можно записать как джва кодепоинта - е + точки)
- в байтах (в какой-то конкретной кодировке, в разных - разная)
- в пикселях (если шрифт не моноширинный)
- в знакоместах (моноширинный шрифт консоли, всякие японские символы по 2 знакоместа)
inkanus-gray 15.01.2015 16:32 # 0
guest 16.01.2015 15:53 # 0
guest 19.01.2015 12:36 # +1
bormand 19.01.2015 13:58 # 0
Dummy00001 15.01.2015 00:11 # 0
> Кроме того, регулярки в Юникоде находят хз. что.
перлу нужно сказать что у тебя юникод. по умолчанию старый добрый аскии/байнари.
смотри в `man perlrun` опцию `-C`. плюс `use utf8`. у меня это иногда работало.
но проблемы с регулярками все равно всплывали, почему изредка питоном для этих целей приходится пользоватся.
> нахер вообще в 21м веке кодировки кроме УТФ8?
азиатов это жутко напрягает, потому что в утф8, у них все буквы 3 байта. местные кодировки - 2 байта. текстовые базы/прочее раздуваются в размере очень быстро. вот поэтому часто утф8 строной обходят.
ЗЫ а в decode/encode это они на самом деле дерьмо сделали. можешь попробовать еще на perlmonks спросить.
wvxvw 15.01.2015 00:24 # 0
Dummy00001 15.01.2015 00:41 # 0
bormand 15.01.2015 06:18 # 0
Но ведь это не только русские буквы, но и вся остальная кириллица.
wvxvw 15.01.2015 10:28 # +1
Dummy00001 15.01.2015 23:59 # +1
самое главное это искать большие легко-обрабатываемы куски и их как можно раньше обработать и выкидывать, что бы количество данных постепенно уменьшать.
bormand 15.01.2015 10:47 # 0
А ведь юникод, в основном, ради них и арабов запиливали...
Зажрались они, имхо. Тот же текст на русском подлиннее будет, т.к. у нас слова не по 2 иероглифа.
Dummy00001 15.01.2015 13:31 # +1
Да. Но это было уже давно. Потом Юникод.орг начал все остальные языки туда тоже добавлять, включая мертвые и полумертвые, почему и вылезли из 2-х байтового диапазона.
(Я помню там какой-то почти мертвый иероглифический язык добавили из того же региона, которым никто почти и не пользуются. Местность нищая, писать умеют не многие (потому что язык долбанутый и недоразвитый), компов ни у кого нет - но зато 10+К символов в Юникод таблице для них добавили. Народ в те времена долго возмущался на эту тему. И как раз азиаты. Потому что Юникод после этого в 2 байта перестал помещается...)
> Тот же текст на русском подлиннее будет, т.к. у нас слова не по 2 иероглифа.
Для большинство разговорной речи айзеры пользуются фонетической записью. Я слышал что даже китайцы начали уже адаптироваться для SMS/текстинг, и правильными иероглифами пишется мало, а вместо этого используется только подмножество как суррогатный фонетический алфавит. (По принципу японских хираганы и катаканы).
Другими словами, я не думаю что большая разница там где-то будет по сравнению с русским. Во первых, во вторых, все большие русские базы которые я видел, все наповал пользуются win-1251. Да, потом конвертится в утф, но на диске лежит в win-1251.
wvxvw 15.01.2015 13:00 # 0