Làm thế nào để phân tích cú pháp HTML hoạt động nếu chúng không sử dụng regexp?

Tôi thấy các câu hỏi mỗi ngày hỏi cách phân tích cú pháp hoặc trích xuất nội dung nào đó từ một chuỗi HTML nào đó và câu trả lời / nhận xét đầu tiên luôn là "Đừng sử dụng RegEx để phân tích cú pháp HTML, kẻo bạn cảm thấy tức giận!" (phần cuối đó đôi khi bị lược bỏ).

Điều này khá khó hiểu đối với tôi, tôi luôn nghĩ rằng nói chung, cách tốt nhất để phân tích cú pháp bất kỳ chuỗi phức tạp nào là sử dụng một biểu thức chính quy. Vậy trình phân tích cú pháp HTML hoạt động như thế nào? Nó không sử dụng biểu thức chính quy để phân tích cú pháp.

Một đối số cụ thể để sử dụng biểu thức chính quy là không phải lúc nào cũng có một giải pháp thay thế phân tích cú pháp (chẳng hạn như JavaScript, trong đó DOMDocument không phải là một tùy chọn khả dụng phổ biến). jQuery, chẳng hạn, dường như quản lý tốt bằng cách sử dụng regex để chuyển đổi một chuỗi HTML thành các nút DOM.

Không chắc có nên CW điều này hay không, đó là một câu hỏi thực sự mà tôi muốn được trả lời và không thực sự có ý định trở thành một chủ đề thảo luận.

Thông thường bằng cách sử dụng tokeniser. Đặc tả HTML5 dự thảo có một thuật toán mở rộng để xử lý "HTML trong thế giới thực".

Vậy trình phân tích cú pháp HTML hoạt động như thế nào? Nó không sử dụng biểu thức chính quy để phân tích cú pháp?

Ồ không.

Nếu bạn quay trở lại bộ não của mình về một khóa học lý thuyết về tính toán, nếu bạn đã tham gia một khóa học hoặc khóa học về trình biên dịch, hoặc thứ gì đó tương tự, bạn có thể nhớ lại rằng có nhiều loại ngôn ngữ và mô hình tính toán khác nhau. Tôi không đủ điều kiện để đi vào tất cả các chi tiết, nhưng tôi có thể cùng bạn xem xét một vài điểm chính.

Loại ngôn ngữ & tính toán đơn giản nhất (cho những mục đích này) là ngôn ngữ thông thường. Chúng có thể được tạo bằng các biểu thức chính quy và được nhận dạng bằng các dữ liệu tự động hữu hạn. Về cơ bản, điều đó có nghĩa là các chuỗi "phân tích cú pháp" trong các ngôn ngữ này sử dụng trạng thái, nhưng không sử dụng bộ nhớ phụ. HTML chắc chắn không phải là một ngôn ngữ thông thường. Nếu bạn nghĩ về nó, danh sách các thẻ có thể được lồng sâu tùy ý. Ví dụ: bảng có thể chứa các bảng và mỗi bảng có thể chứa nhiều thẻ lồng nhau. Với biểu thức chính quy, bạn có thể chọn ra một cặp thẻ, nhưng chắc chắn không phải bất cứ thứ gì được lồng vào nhau một cách tùy tiện.

Một ngôn ngữ đơn giản cổ điển không thông thường được kết hợp chính xác trong dấu ngoặc đơn. Cố gắng hết sức có thể, bạn sẽ không bao giờ có thể tạo một biểu thức chính quy (hoặc một tự động hóa hữu hạn) luôn hoạt động. Bạn cần có bộ nhớ để theo dõi độ sâu của tổ.

Máy trạng thái có ngăn xếp bộ nhớ là điểm mạnh tiếp theo của mô hình tính toán. Đây được gọi là một tự động đẩy xuống và nó nhận dạng các ngôn ngữ được tạo bởi các ngữ pháp không có ngữ cảnh. Ở đây, chúng ta có thể nhận ra các dấu ngoặc được khớp chính xác - thực sự, một ngăn xếp là mô hình bộ nhớ hoàn hảo cho nó.

Chà, điều này có đủ tốt cho HTML không? Thật đáng buồn không. Có thể đối với XML siêu duper đã được xác thực cẩn thận, trong đó tất cả các thẻ luôn xếp hàng hoàn hảo. Trong HTML thế giới thực, bạn có thể dễ dàng tìm thấy các đoạn mã như <b><i>wow!</b></i>. Điều này rõ ràng là không lồng vào nhau, vì vậy để phân tích cú pháp chính xác, một ngăn xếp không đủ mạnh.

Cấp độ tính toán tiếp theo là các ngôn ngữ được tạo ra bởi các ngữ pháp chung và được các máy Turing nhận dạng. Điều này thường được chấp nhận là mô hình tính toán mạnh nhất có hiệu quả - một máy trạng thái, với bộ nhớ phụ, bộ nhớ của nó có thể được sửa đổi ở bất cứ đâu. Đây là những gì ngôn ngữ lập trình có thể làm. Đây là mức độ phức tạp của HTML.

Để tóm tắt mọi thứ ở đây trong một câu: để phân tích cú pháp HTML chung, bạn cần một ngôn ngữ lập trình thực sự, không phải một biểu thức chính quy.

HTML được phân tích cú pháp giống như cách các ngôn ngữ khác được phân tích cú pháp: lexing và phân tích cú pháp. Bước lexing chia nhỏ luồng ký tự riêng lẻ thành các mã thông báo có ý nghĩa. Bước phân tích cú pháp tập hợp các mã thông báo, sử dụng các trạng thái và bộ nhớ, thành một tài liệu mạch lạc về mặt logic có thể được thực hiện.

Biểu thức chính quy chỉ là một dạng phân tích cú pháp. Một trình phân tích cú pháp HTML trung thực đến tốt đẹp sẽ phức tạp hơn đáng kể so với việc có thể được diễn đạt bằng regex, sử dụng phương pháp rút gốc đệ quy , dự đoán và một số kỹ thuật khác để giải thích văn bản một cách chính xác. Nếu bạn thực sự muốn tham gia, bạn có thể xem lex & yacc và các công cụ tương tự.

Lệnh cấm sử dụng regexes để phân tích cú pháp HTML có lẽ nên được viết đúng hơn là: "Đừng sử dụng các cụm từ thông dụng ngây thơ để phân tích cú pháp HTML ..." (kẻo bạn cảm thấy tức giận) "... và xử lý kết quả một cách thận trọng." Đối với các mục tiêu cụ thể nhất định, regex có thể hoàn toàn phù hợp, nhưng bạn cần phải hết sức cẩn thận để nhận biết các hạn chế của regex và thận trọng khi phù hợp với nguồn văn bản bạn đang phân tích cú pháp (ví dụ: nếu nó đầu vào của người dùng, thực sự phải rất cẩn thận).

Phân tích cú pháp HTML là việc chuyển đổi một văn bản tuyến tính thành một cấu trúc cây. Biểu thức chính quy thường không thể xử lý cấu trúc cây. Biểu thức chính quy bạn cần tại mỗi thời điểm để nhận mã thông báo tiếp theo luôn thay đổi. Bạn có thể sử dụng biểu thức chính quy trong trình phân tích cú pháp, nhưng bạn sẽ cần một mảng toàn bộ các biểu thức chính quy cho mỗi trạng thái phân tích cú pháp có thể có.

Nếu bạn muốn có một giải pháp 100%: Bạn cần viết mã tùy chỉnh của riêng mình lặp đi lặp lại từng ký tự HTML và bạn cần có một lượng logic lớn để xác định xem bạn có nên dừng nút hiện tại và bắt đầu kế tiếp.

Lý do là đây là HTML hợp lệ:

<ul>
<li>One
<li>Two
<li>Three
</ul>

Nhưng đây là điều:

<ul>
<li>One</li>
<li>Two</li>
<li>Three</li>
</ul>

Nếu bạn đồng ý với "giải pháp 90%": Thì việc sử dụng trình phân tích cú pháp XML để tải tài liệu là tốt. Hoặc sử dụng Regex (mặc dù xml sẽ dễ dàng hơn nếu sau đó bạn là người nắm vững nội dung).