Нельзя ничего построчно обрабатывать в реальных программах

Примерно 100% проблем в программировании происходят из-за некорректных предположений.

А вообще, да, нужно использовать нормальные форматы обмена, умеющие в экранирование переносов строки в данных.

Какие еще форматы обмена, просто файл жирнющий, около 20 Гб. В принципе в RAM влезет сразу весь, но хотелось как-то элегантнее и без затраты ресурсов и последовательно обрабатывать без лишних хлопот, а вот блин не вышло. Буду парсить на свежую голову.

*сидит весь обмазанный XML'ем и во рту тоже XML*

На кой тебе вообще в RAM файл целиком всасывать, если описываемая обработка строки выполняется быстрее чтения с диска следующей, просто™ берёшь и ищешь что надо. Если есть потребность искать много раз - задумайся об индексах, а не вот это вот.

Засунь в субеде.

Потому что не надо применять автоматные грамматики там, где нужны контекстно-свободные.

Дык, проблема в регэкспах или построчном чтении?

Во-первых:

Some people, when confronted with a problem, think «I know, I’ll use regular expressions.» Now they have two problems.

Во-вторых, данные принято валидировать.

В-третьих, «регэкспами» и «элегантно» — противоречие.

Вы говорите «XML» так, как будто это что-то плохое. Почему любят винить инструмент больше, чем неправильность его использования?

Уточни задачу, которую решал. Регэкспы правда не для всего подходят.

Вы говорите «регулярные выражения» так, как будто это что-то плохое.

ftfy

А XML норм, просто миллениалы считают, что в нём слишком много буковов.
*размазывает по ушам*

А XML норм, просто миллениалы считают, что в нём слишком много буковов.

Мне тут кто-то недавно доказывал, что XML устарел и вообще говно. Хоффисер вроде.

Во-вторых, данные принято валидировать.

Дык тоже регекспами, ну =)

Какие еще форматы обмена, просто файл

А потом хренак и оказывается на практических данных

В квотезы.

В интервью с Крокфордом было про то, что JSON намного лучше XML. Тут тема была про интервью.

Да нет, там прямо в каком-то треде кто-то усирался, что ХМЛ «устарел».

Ну, «устарел» — понятие размытое. А то, что говно — это факт.

Проще сразу это делать.

Проще сразу всё знать.

А то, что говно — это факт.

Я всё таки склонен считать, что это не «факт», а личное мнение.

Я не понимаю эти наезды на XML. Формат текстовых данных - очень субъективная вещь. Одним нравится(привыкли) к одному, другие к другому. Если максимально обобщить, то хорошего формата нет, они все говно. Всё несовершенно.

но хотелось как-то элегантнее и без затраты ресурсов

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

Если максимально обобщить

Если попытаться объективно оценить, есть иерархия языков по Хомскому. И xml по мощности - это скобочное выражение, которое можно распарсить с помощью контекстно-свободной грамматики, но нет - приходится использовать контекстно-зависимые грамматики.

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

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

Уточни задачу, которую решал. Регэкспы правда не для всего подходят.

Почистить некоторые доморощенные логи, результат сложить оттуда в CSV и грузить в Excel (можно в OOCalc). Было очень разумное предположение, на первый взгляд правильное, что одна запись - одна строчка.

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

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

А, ну ладно. Тебе просто «в логи насрали».
Когда я был юн, логи парсились из Цэ с помощью вот такого: https://en.cppreference.com/w/c/io/fscanf

- но это было просто, потому что писались они тоже с помощью sprintf.

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

Правда, «насранное» могло не поместиться в буфер (мы же в Цэ следим за размерами буферов?)... Но в следующие итерации нужные строки нашлись бы. Может быть. Если обработчик поиска начала записи сделать.

А потом хренак и оказывается на практических данных, что надо было учитывать

Му-ха-ха! Впечатления старшеклассницы впервые попробовавшей сЭкис :))))

Ты ещё попроси регексп чтобы парсить *.csv :-D :-)))

поучи ещё тут, умник

с потерей девственности, чё.

Для пацанов столько инструментов наделали, что просто разберись.

А шо у тебя за регэксп такой каличный, что ‘\n’ считает обычным пробелом? Руки сначала отрасти где надо!

Я обычно тупо mmap’лю файл и оставляю все проблемы считывания и буферизации ядру. А сам работаю как с обычной строкой (пусть и с символами ‘\n’ внутри).

А не для лохов придумали ноду (чтобы такие вот дибилы парсили 20 гб).

Чиста поржать: https://nodejs.org/api/readline.html

Плюсы, асинхронность, ДЛЯ ПРО!

нодежс только совсем упоротые идиоты используют же!

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

Если согласно формату строки независимы, т.е. перевод строки является терминатором, то не оказывается. Ваш к.о.

В XML нет массивов. При этом в нём есть дублирующие друг друга элементы, типа <something><attribute>whatever</attribute></something> vs <something attribute=«whatever» /> и порядка чайлдов. А массивов нет. Ну как так можно?

В XML нет массивов.

Чем <a><e>1</e><e>2</e><e>3</e>...</a> не массив?

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

Считывай по записям. Если формат предусматривает многострочные строки, ищи, что является в нём разделителем строки.

Э, нет. Это не так работает. Когда мне надо было разбирать дофига жирные файлы с данными (до 100 Гб на файл), то я подгружал их в оперативку кусками (которые можно рассматривать как логически цельные и независимые друг от друга) таким образом, чтобы они занимали примерно 60% от свободной оперативки (из оставшихся 40% 30% от общей свободной оперативки забивались извлечёнными полезными данными), после чего пачка обработанных данных складывалась на диск и начиналось чтение и обработка следующего куска данных. Это гораздо быстрее, чем обрабатывать построчно или сразу с диска, при условии что писать данные приходится на тот же самый диск с которого они читаются. Да, обрабатывалось долго, один файл разбирался за 16 часов, если бы я делал построчно, то было бы несколько суток, а если с диска, то больше недели. Но блин, недельку помайнил и готовый датасет по которому уже можно учить модельки машинного обучения и который будет актуален 10 лет (потом опять надо пересматривать данные которые очень медленно, но меняются со временем).

JSON лучше.

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

Смотря где и для чего.

Я вот по работе с XML вообще не сталкиваюсь.

Только когда забредаю в суровый мир Java по случайной необходимости. Где мне на глаза попадается какой-нибудь кусок конфигурации на XML, после чего я крещусь, морок развеивается, и я просыпаюсь в привычном мире JS с JSON во всех местах.

Кек, ты начал познавать дзен. Поздравляю. Первым делом тебе надо было разобраться как именно пишется лог и проанализировать крайние случаи, чтобы понять, что там гарантированно, а что нет. Обычно для этого лучше всего связаться с челом, который делал пишущую логи штуку и просто поговорить с ним о том, как и почему всё устроено так как устроено. В команде это называется умением работать в команде/коммуникабельностью и очень ценится.

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

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

Ты хотя бы узнаешь что именно разбивается, а что наоборот склеивается. А так будут одни гадания на кофейной гуще с попытками найти все предельные случаи на глазок (и фиговым результатом, поскольку все случаи в 20 гигабайтах текста на глазок не найдутся)

Тем, что не стандартизовано.

Ты видел, скажем, как устроены plist-ы? Я видел. Там, в частности, вот такое примерно:

<blablabla><key>key1</key><value>value1</value><key>key2</key><value>value2</value>...</blablabla>

"blablabla": [{"key": key1, "value": value1}, {"key": key2, "value":value2}...]

У чела явно линейный поиск, ему хватит и стоковой буферизации на сколько-то-там килобайт вперёд, предоставляемой библиотекой файлового IO.

Это исключительно вопрос соглашения, я вполне видел API, бросающие ошибку при реордере записей в JsonObject. Ты можешь быть сколь угодно прав в знании стандартов, но когда дополнительные ограничения ускоряют импорт, и МЕСЯЦ ЗАКРЫВАЕТСЯ 12 ЧАСОВ ВМЕСТО 18, всем резко становится пофиг на их соблюдение.

В JSON-е всё стандартно: порядок ключей в объекте не важен (а если кто-то его учитывает, то он редиска), порядок элементов в массиве — важен.

В XML ещё проще: порядок любых элементов важен. Порядок атрибутов не важен.

XML - язык разметки по определению. Выводы делайте сами. Даешь TeX для обмена данными между человекомашинами!

XML вообще говно, а не формат! Для человека он неприемлем, т.к. вообще нечитаем (а уж писать XML — тупо невозможно!). Для машин — тоже лютый оверхед.

В общем, лучше JSON в данном случае ничего нет. А если надо шустро, то бинарные структуры с данными.

Ага, разбежался. В схеме есть такая фишка как xs:all — что и даёт нам произвольный порядок.