참고: 이름에서 알 수 있듯이 간단한 작업에 유용합니다. HTML 파서 대신 정규식을 사용하므로 더 복잡한 작업의 경우 속도가 훨씬 느려집니다. 코드베이스의 대부분은 2008년에 작성되었으며 그 이후로 약간의 개선이 이루어졌습니다. 최신 PHP 코딩 표준을 따르지 않으며 최신 PSR 호환 프로젝트에 통합하기가 어렵습니다.
DOM을 사용하여 생산성을 높이려면 시간이 좀 걸리지만 제 생각에는 시간을 들일 가치가 있습니다. DOM은 언어 중립적인 인터페이스이므로 여러 언어로 구현된 것을 찾을 수 있으므로 프로그래밍 언어를 변경해야 하는 경우 해당 언어의 DOM API를 사용하는 방법을 이미 알고 있을 가능성이 높습니다.
DOM 확장을 사용하는 방법은 StackOverflow에서 광범위하게 다루어졌으므로 DOM 확장을 사용하기로 선택한 경우 발생하는 대부분의 문제는 Stack Overflow를 검색/탐색하여 해결할 수 있습니다.
XMLReader는 DOM과 마찬가지로 libxml을 기반으로 합니다. HTML 파서 모듈을 트리거하는 방법을 모르기 때문에 XMLReader를 사용하여 손상된 HTML을 구문 분석하는 것은 libxml의 HTML 파서 모듈을 사용하도록 명시적으로 지시할 수 있는 DOM을 사용하는 것만큼 강력하지 않을 수 있습니다.
다시 말하지만, 나는 이 파서를 추천하지 않습니다. CPU 사용량이 높을 때는 상당히 느립니다. 생성된 DOM 객체의 메모리를 지우는 기능도 없습니다. 이러한 문제는 중첩 루프에서 특히 심각합니다. 문서 자체가 부정확하고 철자 오류가 포함되어 있으며, 2016년 4월 14일 이후로 수정 답변이 없습니다.
HTML 5
위의 내용을 사용하여 HTML5를 구문 분석할 수 있지만 HTML5에서 허용하는 마크업으로 인해 몇 가지 이상한 일이 발생할 수 있습니다. 따라서 HTML5의 경우 전용 파서 사용을 고려할 수 있습니다. 이는 PHP로 작성되었으므로 하위 수준 언어로 컴파일된 확장에 비해 성능이 느려지고 메모리 사용량이 증가합니다.
태그 일치를 위해 웹에서 찾은 대부분의 코드 조각은 취약합니다. 대부분의 경우 매우 구체적인 HTML 조각에서만 작동합니다. 작은 마크업 변경(예: 공백 추가, 마크업의 속성 추가 또는 변경)을 잘못 작성하면 정규식이 실패할 수 있습니다. HTML에서 RegEx를 사용하기 전에 수행 중인 작업을 알아야 합니다.
HTML 파서는 이미 HTML의 구문 규칙을 알고 있습니다. 새로 작성하는 모든 정규식에 대해 정규식을 가르쳐야 합니다. 정규 표현식은 어떤 경우에는 유용하지만 실제로는 사용 사례에 따라 다릅니다.
더 안정적인 파서를 작성할 수 있지만 정규식을 사용하여 완전하고 안정적인 사용자 정의 파서를 작성하는 것은 위의 라이브러리가 이미 존재하고 훨씬 더 나은 작업을 수행할 때 시간 낭비입니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
간단한 HTML DOM 파서를 사용해 보세요.
참고: 이름에서 알 수 있듯이 간단한 작업에 유용합니다. HTML 파서 대신 정규식을 사용하므로 더 복잡한 작업의 경우 속도가 훨씬 느려집니다. 코드베이스의 대부분은 2008년에 작성되었으며 그 이후로 약간의 개선이 이루어졌습니다. 최신 PHP 코딩 표준을 따르지 않으며 최신 PSR 호환 프로젝트에 통합하기가 어렵습니다.
예:
HTML 요소를 얻는 방법:
으아아아HTML 요소 수정 방법:
으아아아HTML에서 콘텐츠 추출:
으아아아슬래시닷 잡기:
으아아아기본 XML 확장
저는 네이티브 XML 확장 중 하나를 사용하는 것을 선호합니다. 왜냐하면 일반적으로 모든 타사 라이브러리보다 PHP에서 더 빠르게 작동하고 마크업에 대해 필요한 모든 제어를 제공하기 때문입니다.
DOM
DOM은 실제(깨진) HTML을 구문 분석하고 수정할 수 있으며 XPath 쿼리를 수행할 수 있습니다. 이는 libxml을 기반으로 합니다.
DOM을 사용하여 생산성을 높이려면 시간이 좀 걸리지만 제 생각에는 시간을 들일 가치가 있습니다. DOM은 언어 중립적인 인터페이스이므로 여러 언어로 구현된 것을 찾을 수 있으므로 프로그래밍 언어를 변경해야 하는 경우 해당 언어의 DOM API를 사용하는 방법을 이미 알고 있을 가능성이 높습니다.
DOM 확장을 사용하는 방법은 StackOverflow에서 광범위하게 다루어졌으므로 DOM 확장을 사용하기로 선택한 경우 발생하는 대부분의 문제는 Stack Overflow를 검색/탐색하여 해결할 수 있습니다.
기본 사용 예 및 일반 개념 개요는 다른 답변에서 찾을 수 있습니다.
XMLReader
XMLReader는 DOM과 마찬가지로 libxml을 기반으로 합니다. HTML 파서 모듈을 트리거하는 방법을 모르기 때문에 XMLReader를 사용하여 손상된 HTML을 구문 분석하는 것은 libxml의 HTML 파서 모듈을 사용하도록 명시적으로 지시할 수 있는 DOM을 사용하는 것만큼 강력하지 않을 수 있습니다.
기본 사용 예는 다른 답변에 나와 있습니다.
XML 파서
XML 파서 라이브러리도 libxml을 기반으로 하며SAX 스타일 XML 푸시 파서를 구현합니다. 메모리 관리를 위해서는 DOM이나 SimpleXML보다 더 나은 선택일 수 있지만 XMLReader로 구현된 풀 파서보다는 사용하기가 더 어렵습니다.
SimpleXml
SimpleXML은 HTML이 유효한 XHTML임을 알고 있는 경우에 사용할 수 있는 옵션입니다. 손상된 HTML을 구문 분석해야 하는 경우 SimpleXml이 차단되므로 고려하지 마세요.
기본 사용 예가 제공되며, PHP 매뉴얼에도 많은 내용이 있습니다.
타사 라이브러리(libxml 기반)
타사 라이브러리를 사용하고 싶다면 문자열 구문 분석 대신 실제로 아래의 DOM/libxml을 사용하는 것이 좋습니다.
FluentDom
HtmlPageDom
phpQuery
이는 "버려진 소프트웨어 및 버그: 사용에 따른 책임은 사용자에게 있습니다"라고 설명되어 있지만 최소한으로 유지 관리되는 것으로 보입니다.
laminas-dom
fDOMDocument
세이버/xml
FluidXML
타사(libxml 기반 아님)
DOM/libxml을 기반으로 구축할 때의 이점은 기본 확장을 기반으로 구축하기 때문에 즉시 좋은 성능을 얻을 수 있다는 것입니다. 그러나 모든 타사 라이브러리가 이 경로를 사용하는 것은 아닙니다. 그 중 일부는 아래에 나열되어 있습니다
PHP 단순 HTML DOM 파서
저는 일반적으로 이 파서를 권장하지 않습니다. 코드 기반은 형편없으며 파서 자체는 매우 느리고 메모리 집약적입니다. 모든 jQuery 선택기(예: sub-selectors)가 가능한 것은 아닙니다. 모든 libxml 기반 라이브러리는 이보다 쉽게 성능이 뛰어납니다.
PHP HTML 파서
다시 말하지만, 나는 이 파서를 추천하지 않습니다. CPU 사용량이 높을 때는 상당히 느립니다. 생성된 DOM 객체의 메모리를 지우는 기능도 없습니다. 이러한 문제는 중첩 루프에서 특히 심각합니다. 문서 자체가 부정확하고 철자 오류가 포함되어 있으며, 2016년 4월 14일 이후로 수정 답변이 없습니다.
HTML 5
위의 내용을 사용하여 HTML5를 구문 분석할 수 있지만 HTML5에서 허용하는 마크업으로 인해 몇 가지 이상한 일이 발생할 수 있습니다. 따라서 HTML5의 경우 전용 파서 사용을 고려할 수 있습니다. 이는 PHP로 작성되었으므로 하위 수준 언어로 컴파일된 확장에 비해 성능이 느려지고 메모리 사용량이 증가합니다.
HTML5DomDocument
HTML5
정규 표현식
마지막이자 가장 권장되지 않는인 경우 정규 표현식을 사용하여 HTML a >에서 데이터를 추출할 수 있습니다. 일반적으로 HTML에서는 정규식을 사용하지 않는 것이 좋습니다.
태그 일치를 위해 웹에서 찾은 대부분의 코드 조각은 취약합니다. 대부분의 경우 매우 구체적인 HTML 조각에서만 작동합니다. 작은 마크업 변경(예: 공백 추가, 마크업의 속성 추가 또는 변경)을 잘못 작성하면 정규식이 실패할 수 있습니다. HTML에서 RegEx를 사용하기 전에 수행 중인 작업을 알아야 합니다.
HTML 파서는 이미 HTML의 구문 규칙을 알고 있습니다. 새로 작성하는 모든 정규식에 대해 정규식을 가르쳐야 합니다. 정규 표현식은 어떤 경우에는 유용하지만 실제로는 사용 사례에 따라 다릅니다.
더 안정적인 파서를 작성할 수 있지만 정규식을 사용하여 완전하고 안정적인 사용자 정의 파서를 작성하는 것은 위의 라이브러리가 이미 존재하고 훨씬 더 나은 작업을 수행할 때 시간 낭비입니다.
참조Cthulhu 방식 분석 Html
책
돈 좀 쓰고 싶다면 확인해 보세요- PHP를 사용한 웹 스크래핑을 위한 PHP 설계자 가이드
저는 PHP 설계자나 작성자와 관련이 없습니다.