Tại sao việc sử dụng một lexer / trình phân tích cú pháp trên dữ liệu nhị phân lại quá sai?

Tôi thường làm việc với lexer / trình phân tích cú pháp , trái ngược với trình kết hợp trình phân tích cú pháp và thấy những người chưa bao giờ tham gia một lớp phân tích cú pháp, hỏi về phân tích dữ liệu nhị phân. Thông thường dữ liệu không chỉ là nhị phân mà còn nhạy cảm với bối cảnh. Điều này về cơ bản dẫn đến việc chỉ có một loại mã thông báo, mã thông báo cho byte.

Ai đó có thể giải thích tại sao phân tích dữ liệu nhị phân bằng lexer / trình phân tích cú pháp lại quá sai với đủ rõ ràng cho một sinh viên CS chưa tham gia lớp phân tích cú pháp, nhưng với lý thuyết không?

Về nguyên tắc, không có gì sai.

Trong thực tế,

• hầu hết các định dạng dữ liệu phi văn bản mà tôi biết là không có ngữ cảnh và do đó không phù hợp với các trình tạo trình phân tích cú pháp phổ biến. Lý do phổ biến nhất là chúng có các trường dài cho số lần sản xuất phải có mặt.

  Rõ ràng, việc có một ngôn ngữ không ngữ cảnh chưa bao giờ ngăn cản việc sử dụng trình tạo trình phân tích cú pháp: chúng tôi phân tích một siêu ngôn ngữ và sau đó sử dụng các quy tắc ngữ nghĩa để giảm nó theo những gì chúng ta muốn. Cách tiếp cận đó có thể được sử dụng cho các định dạng phi văn bản nếu kết quả sẽ mang tính quyết định. Vấn đề là tìm một cái gì đó khác hơn là đếm để đồng bộ hóa vì hầu hết các định dạng nhị phân cho phép dữ liệu tùy ý được nhúng; trường chiều dài cho bạn biết nó là bao nhiêu.

  Sau đó, bạn có thể bắt đầu chơi các thủ thuật như có một lexer viết thủ công có thể xử lý điều đó với phản hồi từ trình phân tích cú pháp (ví dụ xử lý lex / yacc của C sử dụng loại thủ thuật đó để xử lý typedef). Nhưng sau đó chúng ta đến điểm thứ hai.

• hầu hết các định dạng dữ liệu phi văn bản khá đơn giản (ngay cả khi chúng không có ngữ cảnh). Khi số lượng được đề cập ở trên bị bỏ qua, các ngôn ngữ là chính quy, LL1 tệ nhất và do đó rất phù hợp cho các kỹ thuật phân tích cú pháp thủ công. Và việc xử lý số lượng dễ dàng cho các kỹ thuật phân tích cú pháp thủ công như gốc đệ quy.

Chúng ta hãy phân loại dữ liệu thành ba loại: dữ liệu có thể đọc được bởi con người (thường là văn bản, thay đổi từ sách đến chương trình), dữ liệu dự định được đọc bởi máy tính và dữ liệu khác (phân tích hình ảnh hoặc âm thanh).

Đối với danh mục đầu tiên, chúng ta cần xử lý chúng thành một thứ mà máy tính có thể sử dụng. Vì các ngôn ngữ được sử dụng bởi con người nói chung có thể được nắm bắt tương đối tốt bởi các trình phân tích cú pháp, chúng tôi thường sử dụng các trình phân tích cú pháp cho việc này.

Một ví dụ về dữ liệu trong danh mục thứ ba sẽ là hình ảnh được quét của một trang trong cuốn sách mà bạn muốn phân tích thành văn bản. Đối với thể loại này, bạn hầu như luôn cần kiến ​​thức rất cụ thể về đầu vào của mình và do đó bạn cần một chương trình cụ thể để phân tích cú pháp. Công nghệ phân tích cú pháp tiêu chuẩn sẽ không giúp bạn tiến xa đến đây.

Câu hỏi của bạn là về loại thứ hai: nếu chúng ta có dữ liệu ở dạng nhị phân, thì nó hầu như luôn là sản phẩm của một chương trình máy tính, dành cho một chương trình máy tính khác. Điều này ngay lập tức cũng có nghĩa là định dạng của dữ liệu được chọn bởi chương trình chịu trách nhiệm cho việc tạo ra nó.

Các chương trình máy tính hầu như luôn tạo ra dữ liệu theo định dạng có cấu trúc rõ ràng. Nếu chúng tôi phân tích một số đầu vào, về cơ bản chúng tôi đang cố gắng tìm ra cấu trúc của đầu vào. Với dữ liệu nhị phân, cấu trúc này thường rất đơn giản và dễ phân tích bằng máy tính.

Nói cách khác, thông thường sẽ hơi lãng phí khi tìm ra cấu trúc của đầu vào mà bạn đã biết cấu trúc. Vì phân tích cú pháp không miễn phí (cần nhiều thời gian và tăng thêm độ phức tạp cho chương trình của bạn), đây là lý do tại sao việc sử dụng từ vựng / trình phân tích cú pháp trên dữ liệu nhị phân là 'quá sai'.

$a + b \times (c - d) + e$(+ a (* b (- c d)) e)a b c d - * + e +. Ký hiệu toán học thông thường có nhiều dư thừa hơn Lisp (yêu cầu nhiều dấu ngoặc đơn hơn, nhưng có các giá trị thay đổi miễn phí, do đó yêu cầu ít biểu tượng hơn để biểu thị biểu thức bằng cách sử dụng các giá trị lớn) hoặc RPL (không bao giờ cần dấu ngoặc đơn). Sự dư thừa như vậy hiếm khi hữu ích cho máy tính - và ở đâu, đó là khi có thể có lỗi trong dữ liệu, logic sửa lỗi thường được tách biệt với ý nghĩa chức năng của dữ liệu, ví dụ sử dụng mã sửa lỗi áp dụng cho tùy ý chuỗi byte bất kể những gì chúng đại diện.

Các định dạng nhị phân thường được thiết kế nhỏ gọn, có nghĩa là một vài tính năng ngôn ngữ đơn giản như dấu ngoặc đơn cân bằng có thể biểu thị bằng ngữ pháp không ngữ cảnh. Hơn nữa, nó thường hữu ích cho các biểu diễn nhị phân của dữ liệu là chính tắc, nghĩa là có một biểu diễn duy nhất của mỗi đối tượng. Điều này loại trừ các tính năng đôi khi dư thừa như dấu ngoặc đơn. Một hậu quả khác, ít đáng khen ngợi hơn khi có ít sự dư thừa là nếu mọi đầu vào đều đúng về mặt cú pháp, nó sẽ giúp kiểm tra lỗi.

Một yếu tố khác chống lại các trình phân tích cú pháp không cần thiết cho dữ liệu nhị phân là rất nhiều định dạng nhị phân được thiết kế để được phân tích cú pháp bởi mã cấp thấp thích hoạt động trong bộ nhớ không đổi với ít chi phí. Kích thước cố định được ưu tiên khi áp dụng để cho phép lặp lại tùy ý một phần tử. Một định dạng như TLV cho phép trình phân tích cú pháp từ trái sang phải phân bổ lượng bộ nhớ bên phải cho một đối tượng trước, sau đó đọc biểu diễn của đối tượng. Phân tích cú pháp từ trái sang phải là một lợi thế vì nó cho phép dữ liệu được xử lý khi có, không có bộ đệm trung gian.