У меня есть определенная строка, для которой я хочу проверить, является ли это html или нет. Я использую регулярное выражение для того же, но не получаю должного результата.
Я подтверждено мое регулярное выражение , и он прекрасно работает здесь .
var htmlRegex = new RegExp("<([A-Za-z][A-Za-z0-9]*)\b[^>]*>(.*?)</\1>");
return htmlRegex.test(testString);
Вот скрипка, но регулярное выражение там не работает. http://jsfiddle.net/wFWtc/
На моей машине код работает нормально, но в результате я получаю ложь вместо истины. Чего здесь не хватает?
javascript
regex
user1240679
источник
источник
<
и хотя бы один,>
и назвать ее HTML, или вы можете проверить, что она строго действительна с правильным синтаксисом HTML или что-то среднее. В простейшем случае анализатор HTML не требуется.Ответы:
Лучшее регулярное выражение для проверки того, является ли строка HTML:
Например:
Фактически, это настолько хорошо, что он будет возвращаться
true
для каждой переданной ему строки, потому что каждая строка является HTML . Серьезно, даже если он плохо отформатирован или недействителен, это все равно HTML.Если вы ищете наличие элементов HTML, а не просто текстовое содержимое, вы можете использовать что-то вроде:
Это никоим образом не поможет вам разобрать HTML, но определенно пометит строку как содержащую элементы HTML.
источник
a < b && a > c
HTML?a<b && a>c
HTML ... Я бы хотел, чтобы обнаружение HTML было настолько упрощено. Разбор никогда не бывает легким.a < b && a > c
браузер поворачивать>
и<
символы в>
и<
лицо надлежащим образом . Если вместо этого вы используетеa<b && a>c
браузер, он будет интерпретировать разметку какa<b && a>c</b>
отсутствие пробела, что означает<b
открытие<b>
элемента. Вот небольшая демонстрация того, о чем я говорю .Способ №1 . Вот простая функция для проверки, содержит ли строка данные HTML:
Идея состоит в том, чтобы позволить парсеру DOM браузера решать, выглядит ли предоставленная строка как HTML или нет. Как видите, он просто проверяет
ELEMENT_NODE
(nodeType
из 1).Провел пару тестов и вроде работает:
Это решение будет правильно определять строку HTML, однако имеет побочный эффект: img / vide / etc. Теги начнут загружать ресурс после анализа в innerHTML.
Способ №2 . Другой метод использует DOMParser и не имеет побочных эффектов загрузки ресурсов:
Примечания:
1.
Array.from
это метод ES2015, можно заменить на[].slice.call(doc.body.childNodes)
.2. Стрелочную функцию в
some
вызове можно заменить обычной анонимной функцией.источник
isHTML("</a>") --> false
).innerHTML
заставит браузер начать выборку этих ресурсов. :(Немного проверки с помощью:
Это ищет пустые теги (некоторые из них предопределены) и
/
завершенные пустые теги XHTML и проверяет как HTML из-за пустого тега ИЛИ захватывает имя тега и пытается найти его закрывающий тег где-нибудь в строке для проверки как HTML.Разъясненная демонстрация: http://regex101.com/r/cX0eP2
Обновить:
Полная проверка с помощью:
Это правильная проверка, поскольку она содержит ВСЕ теги HTML, сначала пустые, а затем остальные, которым нужен закрывающий тег.
Разъясненная демонстрация здесь: http://regex101.com/r/pE1mT5
источник
document.querySelector('strange')
оцените - это сработает.Ответ zzzzBov выше хорош, но он не учитывает случайные закрывающие теги, например:
Версия, которая также улавливает закрывающие теги, может быть следующей:
источник
<[a-z/][\s\S]*>
- обратите внимание на косую черту в первой группе.Вот неаккуратный однострочник, который я использую время от времени:
Он будет в основном возвращаться
true
для строк, содержащих a,<
за которымANYTHING
следует>
.По
ANYTHING
словом я подразумеваю практически все, кроме пустой строки.Это не здорово, но это однострочный.
использование
Как видите, он далек от совершенства, но в некоторых случаях может сработать за вас.
источник
Все ответы здесь чрезмерны, они просто ищут, а за
<
ними следует>
. Не существует идеального способа определить, является ли строка HTML, но вы можете сделать лучше.Ниже мы ищем закрывающие теги , они будут намного точнее и точнее:
И вот оно в действии:
источник
Если вы создаете регулярное выражение из строкового литерала, вам нужно избегать любых обратных косых черт:
В этом нет необходимости, если вы используете литерал регулярного выражения, но тогда вам нужно избегать косых черт:
Также ваш jsfiddle не работал, потому что вы назначили
onload
обработчик внутри другогоonload
обработчика - по умолчанию, установленное на панели Frameworks & Extensions слева, заключается в том, чтобы обернуть JS в файлonload
. Измените это на опцию nowrap и исправьте экранирование строкового литерала, и оно «работает» (в рамках ограничений, на которые все указали в комментариях): http://jsfiddle.net/wFWtc/4/Насколько мне известно, регулярные выражения JavaScript не имеют обратных ссылок. Итак, эта часть вашего выражения:не будет работать в JS (но будет работать на некоторых других языках).источник
<br>
<hr>
<input...>
@ user1240679?/<\/?[^>]*>/.test(str)
Только определить, содержит ли он теги html, может быть xmlисточник
27 is < 42, and 96 > 42.
Это не HTML.С jQuery:
источник
isHTML("<foo>");
// возвращает истинуisHTML("div");
// возвращает истину, еслиdiv
на странице есть s@
Не является корректным синтаксис для выбора. Таким образом, когда вы передадите его селектору jQuery, он выдаст исключение (т.е.$("you@example.com")
из!!$(str)[0]
). Я имею в виду именно!!$(str)[0]
часть. Вы только что отредактировали свой ответ, но теперь проверяете HTML до того, как jQuery что-нибудь сделает.В этом случае с помощью jQuery простейшей формой будет:
Если
$(testString).length = 1
, это означает, что внутри есть один HTML-тегtextStging
.источник
$()
это операция селектора CSS. Но также фабрика узлов DOM из текстовой сериализации HTML. Но также… согласно другому ответу, страдающему такой же зависимостью от jQuery, «div» не является HTML, но он вернется,true
если<div>
на странице существуют какие-либо элементы. Это очень и очень плохой подход, как я и ожидал практически от любого решения, в котором без необходимости используется jQuery. (Пусть умирает.)Существуют причудливые решения, включающие использование самого браузера, чтобы попытаться проанализировать текст, определить, были ли созданы какие-либо узлы DOM, что будет… медленным. Или регулярные выражения, которые будут быстрее, но… потенциально неточными. Из этой проблемы также возникают два очень разных вопроса:
Q1: содержит ли строка фрагменты HTML?
Струнная часть HTML-документа, содержащего разметку HTML-элемента или закодированные объекты? Это может использоваться как индикатор того, что строка может потребовать обесцвечивания / дезинфекции или декодирования объекта:
Ты можешь видеть этот шаблон используется на всех примерах из всех существующих ответов на момент написания этой статьи, а также с некоторыми… довольно ужасными образцами текста, созданными WYSIWYG или Word, и множеством ссылок на символьные сущности.
Q2: Является ли строка HTML-документом?
Спецификация HTML шокирующе свободна в отношении того, что она считает документом HTML . Браузеры идут на все, чтобы проанализировать практически любой мусорный текст как HTML. Два подхода: либо просто рассмотрите весь HTML (поскольку, если он поставляется с
text/html
Content-Type, будут затрачены большие усилия, чтобы попытаться интерпретировать его как HTML пользовательским агентом), либо найдите маркер префикса:С точки зрения "правильности" это и почти ничего "не требуется". Ниже приводится 100% полный, полностью действительный HTML-документ, содержащий все элементы HTML, которые, по вашему мнению, опускаются:
Ага. Есть четкие правила о том , как сформировать «отсутствующие» элементы , такие как
<html>
,<head>
, и<body>
. Хотя мне кажется довольно забавным, что подсветка синтаксиса SO не смогла правильно определить это без явной подсказки.источник
Мое решение
источник
Существует пакет NPM is-html, который может попытаться решить эту проблему https://github.com/sindresorhus/is-html.
источник
<html>
и<body>
теги, которые являются необязательными . Показательный тест на «несоответствие XML».