Аннотация:
В статье предлагается Pure Java API для произвольной обработки строк. При этом показывается, как пользоваться такого рода библиотекой на конкретном примере разработанной автором библиотеки. Также сравнивается подход автора с классическим.
AB>Авторы: AB>Alexander Babaev
AB>Аннотация: AB>В статье предлагается Pure Java API для произвольной обработки строк. При этом показывается, как пользоваться такого рода библиотекой на конкретном примере разработанной автором библиотеки. Также сравнивается подход автора с классическим.
зачем так сложно ? есть же регулярные выражения ...
Re[2]: Фильтрация строк с использованием автоматов
AB>Авторы: AB>Alexander Babaev
AB>Аннотация: AB>В статье предлагается Pure Java API для произвольной обработки строк. При этом показывается, как пользоваться такого рода библиотекой на конкретном примере разработанной автором библиотеки. Также сравнивается подход автора с классическим.
Вы, не пожалели, потратили время на библиотеку. Это замечательно! Я предлагаю Вам взглянуть на свой код под другим углом.
развивая идею Вы сказали для себя, на входе у меня есть строка А правильно ли это? Вы задумывались откуда могут появляется строки?
В 99% случаев это чтение из потока. т.е. как правило все строки часто изначально это байтовый поток который потом приобразуется в строку.
А не проще ли напрямую работать с поступающим байтовым потоком, безо всякого ненужного преобразования в строку?
Мои рассуждения базируются на опыте написания HTML парсеров. Так вот когда я посмотрел на проблемму шире и отказался от ненужного преобразования в строку, все вдруг стало намного проще, изящнее и эффективнее. Попробуйте посмотреть так. Удачи!
С Уважением Сергей Чикирев
Re: Фильтрация строк с использованием автоматов
От:
Аноним
Дата:
13.09.05 14:06
Оценка:
Здравствуйте, Alexander Babaev, с статье есть предложение:
>> Другой немаловажный недостаток регулярных выражений состоит в том, что мало кто понимает, как они работают. >> «Я пишу это, он делает то…» А как – это проблема тех, кто библиотеку разрабатывает. >> «Чукча не читатель, чукча писатель». В результате – ляпы, непонятные «глюки», и неправильно, >> некорректно работающий программный код.
Регулярные выражения тем и отличаются от самописных обработчиков строк, что работают и оптимизируются по математическим законам. Поведение их вполне определено и для того, кто знает чего хочет получить от RegExp'а и знает как это сделать — нет никаких проблем.
А "плохому танцору" и данная библиотека не поможет, всё равно вопросов будет больше, чем ответов...
AB>Авторы: AB>Alexander Babaev
AB>Аннотация: AB>В статье предлагается Pure Java API для произвольной обработки строк. При этом показывается, как пользоваться такого рода библиотекой на конкретном примере разработанной автором библиотеки. Также сравнивается подход автора с классическим.
Насколько я понимаю:
1. Для каждого символа не может быть более одного обработчика.
2. Фильтр не может быть применен к результату работы другого фильтра? Поскольку фильтр добавляет в результат.
Долго пытался понять, что должен делать метод addToPosition(int), когда понял, удивился, почему он не называется incrementPosition или incPos
Мои фильтры вытянуты в цепочку, каждый знает про следующего, умеет принимать последовательность строк на вход, а в качестве результата кормит следующего. Есть фильтр для подстановки параметров в шаблоны, автоматической вставки отступов, подсчета текущей позиции. Первоначально было значительно больше, выжили только эти
Вообще, таким способом можно делать очень интересные вещи. Например, был фильтр, который позволял откатывать результат генерации до запомненного состояния (a-la транзакции). Использовался для умного форматирования текста — пытаемся вывести так, если не получилось (строка слишком длинная или на одну строку не поместилось), откатываем и пробуем следующий вариант.
Re[2]: Фильтрация строк с использованием автоматов
Здравствуйте, all-x, Вы писали:
AX>Насколько я понимаю: AX>1. Для каждого символа не может быть более одного обработчика.
Нет, их может быть произвольное количество. Проверяются по-порядку (порядок определяется при добавлении правил), каждое правило может прервать обработку (переместить ее на следующий символ, или через несколько).
AX>2. Фильтр не может быть применен к результату работы другого фильтра? Поскольку фильтр добавляет в результат.
Результат работы фильтра — строка. Которая повторно может быть отфильтрована, не вижу проблем.
AX>Долго пытался понять, что должен делать метод addToPosition(int), когда понял, удивился, почему он не называется incrementPosition или incPos
Инкремент — это обычно добавление единицы, мне часто нужно "перескакивать" несколько символов, поэтому и появилось такое, сам не уверен, насколько корректное название.
AX>В свое время делал фильтры немного для других целей — поддержка генерации форматированного текста с использованием шаблонов. AX>JavaDoc: http://treedl.sourceforge.net/atplib/apidocs/com/unitesk/atp/text/filters/package-summary.html AX>Source xref: http://treedl.sourceforge.net/atplib/xref/com/unitesk/atp/text/filters/package-summary.html
AX>Мои фильтры вытянуты в цепочку, каждый знает про следующего, умеет принимать последовательность строк на вход, а в качестве результата кормит следующего. Есть фильтр для подстановки параметров в шаблоны, автоматической вставки отступов, подсчета текущей позиции. Первоначально было значительно больше, выжили только эти
AX>Вообще, таким способом можно делать очень интересные вещи. Например, был фильтр, который позволял откатывать результат генерации до запомненного состояния (a-la транзакции). Использовался для умного форматирования текста — пытаемся вывести так, если не получилось (строка слишком длинная или на одну строку не поместилось), откатываем и пробуем следующий вариант.
Именно это и делает библиотека Только то, что у вас называется фильтром, я называю правилом. А упорядоченная последовательность правил — это и есть фильтр.
Если вытягивать фильтры в цепочку, то получается достаточно стандартная вещь. При этом каждый фильтр обрабатывает всю строку. Прелесть jFilter в том, что все правила обрабатывают строку сразу. Это дает очень, очень хорошую производительность. Это как будто написано регулярное выражение, которое одно выполняет все то, что делает фильтр. Как это выражение выглядит, я боюсь даже представить (сейчас у меня для jDnevnik фильтр, в котором несколько десятков порой очень непростых правил)...
Re[2]: Фильтрация строк с использованием автоматов
Здравствуйте, Аноним, Вы писали:
AB>>Аннотация: AB>>В статье предлагается Pure Java API для произвольной обработки строк. При этом показывается, как пользоваться такого рода библиотекой на конкретном примере разработанной автором библиотеки. Также сравнивается подход автора с классическим.
А>зачем так сложно ? есть же регулярные выражения ...
Я писал в статье, что регулярные выражения — не панацея и работают хорошо, но не всегда. Впрочем, как и jFilter. В общем, в статье ответ есть.
Re[2]: Фильтрация строк с использованием автоматов
Здравствуйте, vladserge, Вы писали:
V>Вы, не пожалели, потратили время на библиотеку. Это замечательно! Я предлагаю Вам взглянуть на свой код под другим углом. V>развивая идею Вы сказали для себя, на входе у меня есть строка А правильно ли это? Вы задумывались откуда могут появляется строки? V>В 99% случаев это чтение из потока. т.е. как правило все строки часто изначально это байтовый поток который потом приобразуется в строку. V>А не проще ли напрямую работать с поступающим байтовым потоком, безо всякого ненужного преобразования в строку?
V>Мои рассуждения базируются на опыте написания HTML парсеров. Так вот когда я посмотрел на проблемму шире и отказался от ненужного преобразования в строку, все вдруг стало намного проще, изящнее и эффективнее. Попробуйте посмотреть так. Удачи!
У меня нет потоков, есть строка. Поскольку библиотека разрабатывалась под конкретное применение, то и потоков пока не появлялось. Но идея очень правильная, жаль, что не заметил такую возможность ранее. В следующей версии будет и возможность работы с потоками.
Re[2]: Фильтрация строк с использованием автоматов
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Alexander Babaev, с статье есть предложение:
>>> Другой немаловажный недостаток регулярных выражений состоит в том, что мало кто понимает, как они работают. >>> «Я пишу это, он делает то…» А как – это проблема тех, кто библиотеку разрабатывает. >>> «Чукча не читатель, чукча писатель». В результате – ляпы, непонятные «глюки», и неправильно, >>> некорректно работающий программный код.
А>Регулярные выражения тем и отличаются от самописных обработчиков строк, что работают и оптимизируются по математическим законам. Поведение их вполне определено и для того, кто знает чего хочет получить от RegExp'а и знает как это сделать — нет никаких проблем.
А>А "плохому танцору" и данная библиотека не поможет, всё равно вопросов будет больше, чем ответов...
Есть пример, я его привел в статье. Можно найти полный текст регулярного выражения, которое проверяет e-mail. Вы можете рассказать по выражению, что оно делает?
Есть другой пример. Решение квадратного выражения используется часто, оно простое. А вы использовали решение произвольного кубического выражения? А оно ведь есть, вполне математическое...
Я к тому, что простые выражения — это хорошо, это правильно и я сам это применяю. Но есть и сложные случаи, какой встретился и у меня. И если писать выражения для таких случаев, то получатся либо несколько более простых, но это многопроходность, потеря скорости, либо такой монстр, что он хоть и определен математически, но это определение занимает не одну страницу, и пользоваться им почти бесполезно.
Re[3]: Фильтрация строк с использованием автоматов
Здравствуйте, babaev, Вы писали:
B>Здравствуйте, all-x, Вы писали:
AX>>Насколько я понимаю: AX>>2. Фильтр не может быть применен к результату работы другого фильтра? Поскольку фильтр добавляет в результат.
B>Результат работы фильтра — строка. Которая повторно может быть отфильтрована, не вижу проблем.
К сожалению, ценой потери однопроходности — основного козыря библиотеки.
AX>>Долго пытался понять, что должен делать метод addToPosition(int), когда понял, удивился, почему он не называется incrementPosition или incPos
B>Инкремент — это обычно добавление единицы, мне часто нужно "перескакивать" несколько символов, поэтому и появилось такое, сам не уверен, насколько корректное название.
По словарю — не обязательно добавление именно единицы. Но стереотип имеется.
AX>>В свое время делал фильтры немного для других целей — поддержка генерации форматированного текста с использованием шаблонов. AX>>JavaDoc: http://treedl.sourceforge.net/atplib/apidocs/com/unitesk/atp/text/filters/package-summary.html AX>>Source xref: http://treedl.sourceforge.net/atplib/xref/com/unitesk/atp/text/filters/package-summary.html
AX>>Мои фильтры вытянуты в цепочку, каждый знает про следующего, умеет принимать последовательность строк на вход, а в качестве результата кормит следующего. Есть фильтр для подстановки параметров в шаблоны, автоматической вставки отступов, подсчета текущей позиции. Первоначально было значительно больше, выжили только эти
AX>>Вообще, таким способом можно делать очень интересные вещи. Например, был фильтр, который позволял откатывать результат генерации до запомненного состояния (a-la транзакции). Использовался для умного форматирования текста — пытаемся вывести так, если не получилось (строка слишком длинная или на одну строку не поместилось), откатываем и пробуем следующий вариант.
B>Именно это и делает библиотека Только то, что у вас называется фильтром, я называю правилом. А упорядоченная последовательность правил — это и есть фильтр.
Это скорее простые и составные фильтры — интерфейс у них одинаковый, а что там внутри — цепочка или монолитная реализация — другой вопрос.
B>Если вытягивать фильтры в цепочку, то получается достаточно стандартная вещь. При этом каждый фильтр обрабатывает всю строку. Прелесть jFilter в том, что все правила обрабатывают строку сразу. Это дает очень, очень хорошую производительность. Это как будто написано регулярное выражение, которое одно выполняет все то, что делает фильтр. Как это выражение выглядит, я боюсь даже представить (сейчас у меня для jDnevnik фильтр, в котором несколько десятков порой очень непростых правил)...
Специфика разная. Интересно бы придумать обобщение этих подходов.
Одно направление рядом уже обсуждается — потоки вместо строк.
Мои фильтры принимают на вход последовательность строк (фактически, элементы потока) и выдают другую последовательность.
Re[4]: Фильтрация строк с использованием автоматов
Здравствуйте, all-x, Вы писали:
AX>К сожалению, ценой потери однопроходности — основного козыря библиотеки.
Да, именно для этого и есть правила, для этого они удобно добавляются,... Но возможность тем не менее имеется, для особо сложных случаев (я вполне допускаю и такое)
AX>По словарю — не обязательно добавление именно единицы. Но стереотип имеется.
Да, именно стереотип. Если есть более корректное название — с удовольствием приму.
AX>Это скорее простые и составные фильтры — интерфейс у них одинаковый, а что там внутри — цепочка или монолитная реализация — другой вопрос.
Да, это интересная идея. Цепочка фильтров в любом случае не помешала бы, пожалуй, стоит сделать. Хотя это может привести к использованию только цепочек, вместо одного фильтра, что не рационально и некорректно.
B>>Если вытягивать фильтры в цепочку, то получается достаточно стандартная вещь. При этом каждый фильтр обрабатывает всю строку. Прелесть jFilter в том, что все правила обрабатывают строку сразу. Это дает очень, очень хорошую производительность. Это как будто написано регулярное выражение, которое одно выполняет все то, что делает фильтр. Как это выражение выглядит, я боюсь даже представить (сейчас у меня для jDnevnik фильтр, в котором несколько десятков порой очень непростых правил)...
AX>Специфика разная. Интересно бы придумать обобщение этих подходов. AX>Одно направление рядом уже обсуждается — потоки вместо строк. AX>Мои фильтры принимают на вход последовательность строк (фактически, элементы потока) и выдают другую последовательность.
Я не совсем понял, в чем обобщение? То есть сделать трехуровневую систему? "правило — фильтр — процессор строк", каждый следующий является последовательностью предыдущих... Так?
AB>В статье предлагается Pure Java API для произвольной обработки строк. При этом показывается, как пользоваться такого рода библиотекой на конкретном примере разработанной автором библиотеки. Также сравнивается подход автора с классическим.
LEX принимает на входе файл с описанием регулярных выражений. На выходе отдает код для разбора этих выражений конечным автоматом.
AB>Возможен другой вариант, который и подводит непосредственно к автоматному методу работы. Те, кто более глубоко интересовался регулярными выражениями, скажут, что автоматы и регэкспы – это одно и то же. Да, любое регулярное выражение – это всего лишь короткая строковая запись автомата. Но обсуждение такого рода различий выходит далеко за рамки статьи.
Судя по этому абзацу, вы понимаете соотношение между автоматами и регэкспами. А стандартный, работающий уже десятилетиями инструмент — почему-то не используете. Почему?
Re[5]: Фильтрация строк с использованием автоматов
B>Да, именно для этого и есть правила, для этого они удобно добавляются,... Но возможность тем не менее имеется, для особо сложных случаев (я вполне допускаю и такое)
AX>>По словарю — не обязательно добавление именно единицы. Но стереотип имеется.
B>Да, именно стереотип. Если есть более корректное название — с удовольствием приму.
Шурик, addToPosition воспринимается как добавление чего-либо в указанную позицию.
Если ты по сути дела сдвигаешь текущую позицию — так и говори, например:
shiftPos
shiftCurrentPosition
skipSymbols
... << RSDN@Work 1.1.3 stable >>
Winamp молчит, работа идёт
Standarts are great, everyone should have one!
Здравствуйте, nzeemin, Вы писали:
N>Здравствуйте, Alexander Babaev, Вы писали:
N>LEX принимает на входе файл с описанием регулярных выражений. На выходе отдает код для разбора этих выражений конечным автоматом.
AB>>Возможен другой вариант, который и подводит непосредственно к автоматному методу работы. Те, кто более глубоко интересовался регулярными выражениями, скажут, что автоматы и регэкспы – это одно и то же. Да, любое регулярное выражение – это всего лишь короткая строковая запись автомата. Но обсуждение такого рода различий выходит далеко за рамки статьи.
N>Судя по этому абзацу, вы понимаете соотношение между автоматами и регэкспами. А стандартный, работающий уже десятилетиями инструмент — почему-то не используете. Почему?
Потому что я сам библиотекой делаю несколько иное. Я беру некоторые стандартные правила и "почти так же, как и в регулярном выражении" парсю строку. В регулярных выражениях мне очень не нравится сложность, возрастающая при увеличение регэкспа многократно.
Моя задача — не создать автомат или какую-то иную запись автомата. Я хотел этой библиотекой создать инструмент работы со строками. Такой, который, обладая большой скорость, не уступал бы регулярным выражениям в гибкости. А по настройке и простоте превосходил бы.
Сейчас появилась какая-то "китайская" утилита, которая позволяет создать регэксп при помощи текстового описания. Вот, это уже ближе к тому, что сделал я. Но у jFilter'а есть и более интересные достоинства вроде отсутствия необходимости перекомпилирования регулярного выражения при его изменении...
Здравствуйте, babaev, Вы писали:
B>Потому что я сам библиотекой делаю несколько иное. Я беру некоторые стандартные правила и "почти так же, как и в регулярном выражении" парсю строку. В регулярных выражениях мне очень не нравится сложность, возрастающая при увеличение регэкспа многократно.
Отсюда вопрос — а вы вообще-то LEX смотрели?
Re[2]: Фильтрация строк с использованием автоматов
А>Регулярные выражения тем и отличаются от самописных обработчиков строк, что работают и оптимизируются по математическим законам. Поведение их вполне определено и для того, кто знает чего хочет получить от RegExp'а и знает как это сделать — нет никаких проблем. А>А "плохому танцору" и данная библиотека не поможет, всё равно вопросов будет больше, чем ответов...
-1
Мы недавно завершили проект — сайт технической поддержки на Java. Для рендеринга страниц сначала использовали radeox — он как раз на регулярных выражениях.
Чтобы добиться нужного нам поведения пришлось переписать половину фильтров
Например нам нужно было реализовать автонумерацию рисунков на странице — чтобы тег {image}
заменялся на картинку с подписью Рисунок N в зависимсти от числа предыдущих картинок.
Так и не получилось победить, пришлось делать это на этапе xslt преобразования...
После перехода на JFilter все сильно упростилось и выросла скорость обработки.
Правила здесь делать проще , да и сама библиотека легче и компактнее по сравнению с radeox.
Те вещи которые делались через RegExp'ы, удобнее оказалось сделать на Java.
Здравствуйте, nzeemin, Вы писали:
N>Здравствуйте, babaev, Вы писали:
B>>Потому что я сам библиотекой делаю несколько иное. Я беру некоторые стандартные правила и "почти так же, как и в регулярном выражении" парсю строку. В регулярных выражениях мне очень не нравится сложность, возрастающая при увеличение регэкспа многократно.
N>Отсюда вопрос — а вы вообще-то LEX смотрели?
Напиши тогда статью "Фильтрация строк с использованием LEX (JLex)".
пришлось переписать половину фильтров 
