Разбор плохо отформатированных файлов журнала?

Question

Я работаю с некоторыми файлами журналов, которые очень плохо отформатированы, разделитель столбцов - это элемент, который (часто) появляется в поле, и он не экранирован. Например:

sam,male,september,brown,blue,i like cats, and i like dogs

Где:

name,gender,month,hair,eyes,about

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

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

Edit:

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

Answer 1

Если только в последнем столбце есть неэкранированные запятые, то в большинстве языков реализация разделения строк может ограничить количество выполненных разделений, например, в Python s.split(',',5)

Если вы хотите проанализировать файл как CSVпарсер значений, разделенных запятыми), тогда я думаю, что лучшим подходом было бы запустить средство исправления, которое делает правильный выход перед передачей его в парсер csv.

Answer 2

Полагаю, вы можете сделать определенные предположения о типе данных. Например, gender, month, hair и eyes имеют домен значений, а затем убедитесь, что.

Также может иметь смысл, что все поля, кроме about и, возможно, name, не будут содержать запятую, поэтому, возможно, вы можете жадно анализировать, заставляя первые 5 или 6 запятых вести себя как разделители, а все остальное является частью about. Проверьте еще раз, если необходимо.

Answer 3

Может быть невозможно их полностью проанализировать, если не использовать экранирование.

Ли Райан отметил, что, если только последний столбец может иметь эти значения, у вас есть опция.

Если это не так, есть ли какие-либо столбцы, в которых вам гарантировано отсутствие неэкранированных, зарезервированных символов? Кроме того, есть ли какие-либо столбцы, в которых вы гарантированно всегда будете иметь только определенный набор значений?

Если любое из них истинно, вы можете сначала идентифицировать эти поля и отделить все остальное, чтобы отделить его оттуда.

Мне нужно знать больше информации о вашей информации, чтобы идти дальше.

Answer 4

Вот две идеи, которые вы можете попробовать:

• Длина / формат шаблонов - Я думаю, вы могли бы определить некоторые шаблоны в отдельных столбцах файла. Например, значения в некоторых столбцах могут быть короче, а значения в некоторых столбцах могут быть короче. Значения в некоторых столбцах обычно являются числами или из ограниченного набора значений (например, месяцев) или, по крайней мере, часто содержат некоторую подстроку.

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

• Грамматические правила - еще одна идея, вдохновленная вашим примером - обычно запятые, которые не экранированы, сопровождаются некоторыми строками (например, словами "и" или "о"?) Если да, вы может использовать эту информацию, чтобы угадать, какие разделители следует экранировать.

Наконец, если ни один из этих специальных методов не может решить вашу проблему, тогда вы можете использовать некоторые статистические данные для оценки. Есть некоторые механизмы машинного обучения, которые могут сделать тяжелую статистику для вас, но это все еще довольно сложная проблема. Например, в .NET вы можете использовать Infer.NET от Microsoft Research.

Answer 5

Ваши журналы неоднозначны: вы не можете быть уверены, какую из многих возможных интерпретаций сделать.Работа с неопределенностью - это работа для теории вероятностей.Естественным инструментом тогда является вероятностная контекстно-свободная грамматика - существуют алгоритмы для поиска наиболее вероятного анализа.(У меня не было случая использовать его самостоятельно, хотя с таким статистическим подходом я выполнил более простые задачи. В статье об исправлении орфографии *1004* Питера Норвига подробно описан один такой пример.)

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

(Еще один пример работы с данными с различиями стерт: у меня был набор данных тегов с полумиллиона фотографий Flickr. Теги были получены из их API со всеми словами вместе с пробелами. Iвычислил наиболее вероятные границы слов, используя частоты слов, сведенные в таблицу с сайтов интернет-фотографии, плюс код, подобный этому SO-ответу .)

Answer 6

Если 6-й столбец всегда является последним и всегда не экранирован, этот бит perl должен помочь:

$file = '/path/to/my/log.txt';
open(LOG, $file);
@lines = <LOG>;

foreach $line (@lines)
{
    chomp($line);
    if ($line =~ /([A-Za-z0-9_]+)\,([A-Za-z0-9_]+)\,([A-Za-z0-9_]+)\,([A-Za-z0-9_]+)\,([A-Za-z0-9_]+)\,([A-Za-z0-9_\, ]+)/)
    {
        print "Name:         $1\n";
        print "Gender:       $2\n";
        print "Month:        $3\n";
        print "Color #1:     $4\n";
        print "Color #2:     $5\n";
        print "Random Text:  $6\n";
    }
}

close(LOG)

Answer 7

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