Странное поведение str_replace() при заменах в HTML?

Question

[JastaFly]

Мне нужно заменить биты ссылки в HTML коде:

<p style="text-align: justify;">
	 Many some boring text without images <a href="https://www.some-site.com/some/site/section /" target="_blank">some link text</a> - still some boring text without images
</p>

В конце ссылки перед слешем стоит пробел что ломает её. Но суть не в этом, для решения задачи я написал регулярку, которую засунул в функцию preg_replace_callback():

$textWithoutSpaces = preg_replace_callback(
                '/(https:\/\/[\w_-]+(?:(?:\.[\w_-]+)+)[\w.,@?^=%&:\/~+#-]*[\w][ ]{1,}\/)/',
                'self::deleteSpaces',
                $text
            );

Для того чтобы изменить ссылки в HTML использовал следующую конструкцию:

private static function deleteSpaces($match) {
        return str_replace($match, str_replace(' ', '', $match), self::$currentText);
    }

Совпадения по регулярке в $match, отлично находятся, эта конструкция:
str_replace(' ', '', $match)
Отлично убирает из них пробелы, вся проблема в том что в итоговый HTML код попадает лишний кусок взявшийся хрен знает от куда, который дублирует часть текста:

<p style="text-align: justify;">
         Many some boring text without images <a href="<p style="text-align: justify;">
	 Many some boring text without images <a href="https://www.some-site.com/some/site/section /" target="_blank">some link text</a> - still some boring text without images
</p>

Пробовал переписать на:

private static function deleteSpaces($match) {
        $positionToText = strpos(self::$currentEnDetailNewsText, $match);
        return substr_replace(self::$currentEnDetailNewsText, str_replace(' ', '', $match), $positionToText, strlen($match));
    }

Результат идентичен. Подскажите что не так? Или может быть какой-то альтернативный способ?

Answer 1

[Ivan Ustûžanin]

Подскажите что не так?

в нежелании читать документацию

в колбэк $match приходит в виде массива, с используемой регуляркой нужно использовать либо $match[0], либо $match[1]

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

Comments

[JastaFly]

IvanU7n да знаю это. Убрал массивы из кода чтобы не отвлекать лишними деталями, в оригинале всё это разумеется было учтено:

private static function deleteSpaces($match) {
        return str_replace($match[0], str_replace(' ', '', $match[0]), self::$currentText);
    }

[Ivan Ustûžanin]

JastaFly, ничего себе "лишние детали", это важные детали
теперь дальше, документацию всё же нужно читать, а там написано, что то, что вернёт колбэк, будет использовано для замены сматченного
другими словами нужно возвращать исправленную ссылку, а не (судя по коду) весь фрагмент с исправленной ссылкой

ПС. вызовы вида 'self::function' задеприкейчены в PHP 8.2: https://www.php.net/manual/en/migration82.deprecat...
ПС2. обновил ответ

[JastaFly]

@IvanU7n

ругими словами нужно возвращать исправленную ссылку

Спасибо. Совсем глаз замылился, проблема была реально в возвращаемом значении

вызовы вида 'self::function' задеприкейчены в PHP 8.2:

У меня 8.1, так что пока прокатит)
А как тогда быть если нужно вызвать собственный метод класса в версиях 8.2 и выше?!

[Ivan Ustûžanin]

JastaFly, [ __CLASS__, 'function', ] или что-то подобное

[JastaFly]

IvanU7n, функция при этом всё так-же должна быть статической. Верно?

[Ivan Ustûžanin]

JastaFly, если вызывается через класс, а не его экземпляр, то да, должна быть статической

Answer 2

[ThunderCat]

$html = str_replace(' /" ', '/" ' ,$html);Есть ненулевая вероятность попасть в какой-то текст, но в целом ей можно пренебречь.

Answer 3

[Rsa97]

Работать регулярками с HTML можно, но сложно.
Проще использовать библиотеку, предназначенную для этого, например Simple HTML DOM Parser.

Comments

[JastaFly]

Rsa97, и как мне без регулярок найти в паре сотне HTML-ек различные битые ссылки с пробелами на конце?

[Александр Аксентьев]

JastaFly, очень просто загнать документ в html парсер и достать оттуда все ссылки, а потом уже проверить их любым удобным способом(необязательно регулярками, strpos в помощь)

include 'simple_html_dom.php';
$html = file_get_html('https://qna.habr.com/q/1339408');

foreach($html->find('a') as $element) {
 if(strpos($element->href, " ") !== false) { 
       echo $element->href. '<br>';
 }
}

[Виктор Кожухарь]

JastaFly,
Каждый опытный веб-программист знает два непреложных закона:
1. Если вы используете регулярные выражения для решения проблемы, то у вас теперь две проблемы. ) Это правило шуточное, но в каждой программистской шутке есть громадный кусок горькой правды...
2. НИКОГДА! не используйте регулярные выражения для парсинга HTML, а используйте специальный парсер. И вот это правило серьёзное, и нарушать его выйдет себе дороже.

[JastaFly]

Александр Аксентьев, в переводе на программистский это называется: "переизобретением велосипеда"

[JastaFly]

Виктор Кожухарь, допустим, но продублирую тут вопрос из комментария выше:

как мне без регулярок найти в паре сотне HTML-ек различные битые ссылки с пробелами на конце?

Плюс можете подробнее расписать почему нельзя использовать регулярки для парсинга HTML?

[Александр Аксентьев]

JastaFly, всё можно, никто не запрещает)
Ещё можно json парсить регулярками, но никто этого не делает, хотя можно.
По той же причине и html проще парсить как html.
Это же структурированный документ с разметкой которая программно читается и можно с ней удобно работать через запросы по селекторам. Как в js/css примерно.

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

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

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

/(https:\/\/[\w_-]+(?:(?:\.[\w_-]+)+)[\w.,@?^=%&:\/~+#-]*[\w][ ]{1,}\/)/

Хотя можно было бы ограничиться вот такой например href="(.*?)(\s+)", но все обязательно пытаются туда засунуть всё что только можно, а потом разбираться что не так)

[Александр Аксентьев]

JastaFly, https://regexr.com/7t469

[Виктор Кожухарь]

JastaFly,
1. Ничего вам не мешает использовать регулярные выражения для парсинга HTML. Каждый волен делать всё, что взбредёт ему в голову. Я вам даже отличную статью подкину, где описывается мощь регулярных выражений, и то, как с помощью них можно спарсить даже такие языки, как HTML. https://habr.com/ru/articles/171667/
Дело в том, что HTML - это констекстно-свободный и при этом не регулярный язык. Видите это словосочетание "не регулярный"? Это вам никаких намёков не даёт? В статье показано, как можно, сделав операцию на глаза через задний проход, спарсить HTML регулярками, но зачем оно нам надо? Сделать код абсолютно не читаемым и не подверженным дебаггингу? Если это ваша цель, то смело идите к ней.

2. Мы очень часто забываем, насколько толерантны браузеры к чтению и отображению невалидного и непривычного нам HTML кода. Дело в том, что HTML - это далеко не красивый XML, в котором существует чёткая и единственно-верная спецификация. HTML - это самый настоящий бардак (как и Javascript... только не бейте меня за это))

Вот вам буквально парочка примеров HTML:

<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>Document</title>
</head>
<body>
    <select multiple>
        <!-- Не правда ли прекрасно, что значение атрибута value работает без кавычек?-->
        <option value=foo selected>FOO</option>
        <!-- А вот так делают старые любители XHTML -->
        <option value="bar" selected="selected">BAR</option>
        <!-- А что если вот так? ... Да что же это такое происходит?! -->
        <!-- Невалидно, но браузер прекрасно кушает, правда не так, как мы думали -->
        <option value="baz" selected="true">BAZ</option>
        <option value="fuc" selected=false>Ой...</option>
    </select>
    
    <!-- Все картинки работают -->
    <img src="https://placehold.co/20" alt="aaa">
    <img src="https://placehold.co/30" alt="aaa"/>
    <!-- Валидатор сопротивляется, но браузеру плевать -->
    <img src="https://placehold.co/40" alt="aaa"></img>

    <!-- Идём дальше -->
    <br /> Тег br закрыт. Само собой, текст находится не внутри br
    
    Точно так же:
    <br> Тег br закрыт. Само собой, текст находится не внутри br

    И тут начинается что-то странное:

    <div /> Тээк. Div же закрыт. А текст находится внутри Div. Шта?

    Спецификация HTML чёткая и понятная. Ничего сильно запоминать не надо.
    Любой новичок справится.
    Так? ... Так?
    
    <input />Этот текст снаружи элемента input
    <input>Этот текст снаружи элемента input. Ошибка, но работает</input>

    <div>Этот текст внутри div</div>
    <div />Этот текст внутри div
    
    <!-- Всё валидненько -->
    <p>Этот текст внутри p</p>
    <p>Этот текст внутри p
    <p>Этот текст внутри p</p>
    <!-- Невалидно, но работает в браузере -->
    <p />Невалидно, текст внутри p
    
    И много-много радостей вам парсинг регулярками принесёт...

</body>
</html>

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

3. Если ваша цель просто быстренько найти какое-то сочетание символов в HTML коде, то пользуйтесь на здоровье регулярками. Инструмент всегда выбирается под задачу. Но начинающему, как мне кажется, лучше всегда советовать категорично. По типу либо "всегда", либо "никогда". Так ему будет проще, а с нюансами он потом сам разберется. Вот я и посоветовал никогда не использовать регулярки при парсинге HTML.

P.S. Совсем забыл про решение. При помощи парсера, что вам предложили, выбираете все ссылки, которые хотите проверить, проверяете их атрибут href на вшивость, и заменяете этот атрибут на корректное значение. Потом сохраняете весь DOM. Ктати, вот тут, при проверке конкретной ссылки, если не терпится, можно использовать регулярку, ведь это просто одна строчка урла, без кучи мусора. Но зачем, если тут гораздо проще обойтись без неё?

[JastaFly]

Александр Аксентьев,

json парсить регулярками

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

через запросы по селекторам. Как в js/css примерно.

Как по селектору мне найти битые ссылки в HTML?

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

Вы русский язык буква читать уметь?! Вот цитата из топика:

Совпадения по регулярке в $match, отлично находятся

то есть проблем с регуляркой у меня не было, она прекрасно работала, я просто проявил невнимательность при использование функции preg_replace_callback(). О чём Вы вообще?!

сравните с кодом сверху который я отправлял

Лично для мне наоборот странно выглядит велосипед из множества строк кода с циклами и вложенными в них условиями, вместо одной строчки с регуляркой
Виктор Кожухарь,

спарсить HTML регулярками, но зачем оно нам надо?

Ей богу не знаю, зачем оно Вам надо, мой вопрос парсинга HTML, не касается

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

Короче вместо одной строчки кода с регуляркой, Вы предлагаете соорудить целый космический шатл-субмарину из либы для парсинга HTML, циклов, условий...... и в конце всё равно использовать регулярку чтобы не усложнять и без того громоздкую конструкцию. Да Вы просто сумрачный гений инженерной мысли!

[Александр Аксентьев]

JastaFly,
> parse «производить анализ, анализировать, разбирать», далее из лат.

[JastaFly]

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

[Виктор Кожухарь]

JastaFly, Вот вы тут пишете, что всё работало, но вы проявили невнимательность в preg_replace_callback.
Это и есть проблема, это и будет у вас всегда проблемой, если будете парсить HTML регулярками. Потому что это всё трудно анализировать и дебажить. Жаль, что будете учиться на своих ошибках, а не на чужих. Я когда-то, много лет назад тоже был такой парсильщик HTML регулярками, когда их изучил. Уйму времени потратил совершенно бестолково.
А насчёт того, что я вам посоветовал регулярку после обработки парсером, так это потому, что это как раз и место для регулярок: одна типовая строчка. Тут не запутаешься.

[JastaFly]

вы проявили невнимательность в preg_replace_callback. Это и есть проблема, это и будет у вас всегда проблемой, если будете парсить HTML регулярками

Вы вообще можете в причины следственные связи?! То есть у меня проблемы с ньюансами работы функции preg_replace_callback(), не с регуляркой. Регулярка которую я написал всё прекрасно находит! Каким образом вы из этой истории сделали вывод о проблемности регулярок?!

А насчёт того, что я вам посоветовал регулярку после обработки парсером, так это потому, что это как раз и место для регулярок: одна типовая строчка. Тут не запутаешься

О чём Вы?! Мой итоговый код выглядит так:

$regularUrlPattern = '/(https:\/\/[\w_-]+(?:(?:\.[\w_-]+)+)[\w.,@?^=%&:\/~+#-]*[\w][ ]{1,}\/)/';
$detailTextWithoutSpaces = preg_replace_callback($regularUrlPattern, 'self::deleteSpaces', $detailText);

  private static function deleteSpaces($match)
    {
        return str_replace(' ', '', $match[0]);
    }

Что Вам здесь в 6 строчках кода не понятно?! А сколько строк займёт предлагаемая вами альтернатива с либой для парсинга, циклами, условиями и регуляркой?!

[Rsa97]

JastaFly, А вы уверены, что через месяц спокойно прочтёте свою регулярку?

[JastaFly]

Rsa97, там название переменной как бы намекает на то что она делает

[Rsa97]

JastaFly, Но не говорит о том, как именно это делается. Предположим, вам надо добавить небольшое изменение - пропускать ссылки, которые находятся внутри блоков pre и code, поскольку вы решили написать статью и в этих блоках находятся примеры неправильных ссылок.

[JastaFly]

Rsa97,

Но не говорит о том, как именно это делается

Это уже вопрос квалификации разработчика, для непрограммиста код высокоуровнего ЯПа не понятнее греческого

Предположим, вам надо добавить небольшое изменение - пропускать ссылки, которые находятся внутри блоков pre и code

Модифицирую свой код под эту задачу, тут уже вполне проглядывается смысл в либе для прасинга, так как придётся анализировать не является ли ссылка потомком pre или code. Как видите я не догматик который топит за/против регулярок, только потому что где-то об этом услышал, а своего ума понять что и как не хватает. Это всего лишь инструмент и как любой инструмент он хорош для одних задач и плох для других. И всё в большей степени зависит от того в чьих руках он находится, вряд-ли разумно обвинять микроскоп в том что им гвозди забивать неудобно