Video và phụ đề · Bộ công cụ phụ đề
Cách trình duyệt phân tích cú pháp tệp SRT: khối, chỉ mục, mã thời gian và văn bản
· Cách thức hoạt động
phụ đề srt file-formats
SRT có vẻ tầm thường cho đến khi bạn gặp các tệp thực. Bài đăng này hướng dẫn cách trình phân tích cú pháp phân tách các khối, đọc chỉ mục và mã thời gian, xử lý văn bản nhiều dòng và khôi phục từ các khối không đúng định dạng mà các tệp trong thế giới thực chứa.
Tệp 'trông ổn' nhưng thiếu một nửa tín hiệu - làm thế nào một định dạng trông có vẻ khoan dung lại che giấu những kỳ vọng nghiêm ngặt
SRT không có nội dung thông số kỹ thuật, không có đăng ký MIME và không có trình xác thực đi kèm với người chơi. Thay vào đó, những gì tồn tại là một hình dạng mà hầu hết các phần mềm đều đồng ý: một con số, một dòng mã thời gian, một hoặc nhiều dòng văn bản, sau đó là một dòng trống. Bởi vì hình dạng là thông thường chứ không phải được chỉ định, cả hai tệp đều có thể trông chính xác trong trình soạn thảo văn bản trong khi chỉ một trong số chúng tải và lỗi thường diễn ra im lặng. Người chơi không thể đọc tín hiệu có xu hướng bỏ qua thay vì báo cáo nó, do đó, một tệp có khối bị hỏng sẽ phát có khoảng trống thay vì lỗi.
Do đó, một trình phân tích cú pháp có hai công việc có hướng ngược nhau. Nó phải chấp nhận các biến thể chứa trong các tệp thực, bởi vì các tệp được tạo ra bởi các dịch vụ phiên âm, chỉnh sửa thủ công và các trình chuyển đổi định dạng mà mỗi tệp đưa ra các giả định khác nhau. Nó cũng phải từ chối các kết quả đọc có thể đưa ra tín hiệu sai thời điểm, bởi vì dấu thời gian sai âm thầm còn tệ hơn cả lỗi được báo cáo.
Chia thành các khối — các dòng trống làm dấu phân cách và sự cố với khoảng trắng lạc chỗ và CRLF
Việc chia tách xảy ra trên các dòng trống, không phải trên các số chỉ mục. Trình phân tích cú pháp chuẩn hóa các kết thúc dòng trước tiên, thay thế cả cặp CRLF và một CR đơn độc bằng một dòng mới, bởi vì một tệp được tạo trên Windows và được chỉnh sửa trên Unix có thể chứa cả hai. Sau đó, nó phân tách thành hai hoặc nhiều dòng mới, cắt từng khối kết quả và loại bỏ các khối trống. Vấn đề thứ tự đó: việc phân tách trước khi chuẩn hóa sẽ để lại dấu xuống dòng đi lạc ở cuối dòng mã thời gian và khi đó mã thời gian sẽ không khớp.
Dấu thứ tự byte bị loại bỏ trước bất kỳ dấu hiệu nào trong số này. UTF-8 BOM ở đầu tệp là ba byte mà một trình phân tích cú pháp đơn giản coi là một phần của số chỉ mục đầu tiên, đủ để làm cho tín hiệu đầu tiên không thể đọc được trong khi mỗi tín hiệu sau đó sẽ phân tích cú pháp. Các khoảng trắng ở cuối trên một dòng phân cách trống sẽ được phần cắt xử lý, do đó, một tệp có các dòng trống chứa khoảng trắng vẫn được phân chia chính xác.
Dòng chỉ mục - tại sao các số thường sai, trùng lặp hoặc bị thiếu và tại sao các trình phân tích cú pháp không nên tin cậy chúng
Số chỉ mục được đọc và sau đó bị bỏ qua. Tín hiệu số tệp thực từ 0, bắt đầu đánh số lại sau khi hợp nhất, sao chép số sau khi chỉnh sửa thủ công hoặc bỏ qua hoàn toàn dòng khi trình chuyển đổi ghi tệp. Tin tưởng những con số đó có nghĩa là kế thừa mọi lỗi trong số đó, do đó, trình phân tích cú pháp sẽ chỉ định số tuần tự của riêng nó, đếm các tín hiệu mà nó đã xây dựng thành công cho đến nay.
Lựa chọn đó cũng giải thích tại sao trình phân tích cú pháp không bao giờ yêu cầu phải có dòng chỉ mục. Nó định vị dòng mã thời gian bằng cách tìm kiếm khối dòng đầu tiên chứa mũi tên, thay vì giả sử mã thời gian là dòng thứ hai. Một khối không có dòng chỉ mục sẽ phân tích cú pháp bình thường và một khối có hai dòng đi lạc trước mã thời gian vẫn phân tích cú pháp, bởi vì vị trí không phải là thứ xác định mã thời gian.
Dòng mã thời gian — HH:MM:SS,mmm --> HH:MM:SS,mmm, các biến thể được chấp nhận và các biến thể khiến người chơi bị hỏng
Dòng mã thời gian được khớp với một biểu thức chính quy duy nhất và dung sai trong đó là có chủ ý. Giờ là tùy chọn vì WebVTT cho phép đọc hai trường và bộ chuyển đổi phát ra nó. Dấu phẩy hoặc dấu chấm hoàn toàn được chấp nhận làm dấu phân cách mili giây bất kể tệp yêu cầu định dạng nào, bởi vì dấu phân cách hỗn hợp đủ phổ biến để việc từ chối chúng sẽ khiến nhiều tệp tốt hơn tệp xấu. Các chữ số phân số được đệm ở bên phải, do đó, tín hiệu kết thúc bằng một chữ số duy nhất được đọc dưới dạng hàng trăm mili giây thay vì đơn vị.
Hai bài đọc bị từ chối. Trường phút hoặc giây trên 59 bị từ chối thay vì được lưu, vì chín mươi giây không phải là chỉ số đồng hồ và thường chỉ ra tệp bị hỏng hoặc bị chuyển đổi sai; bình thường hóa nó một cách âm thầm sẽ di chuyển tín hiệu. Một dòng có phần đầu hoặc phần cuối không thể phân tích cú pháp sẽ tạo ra sự cố được ghi lại khi đặt tên cho văn bản vi phạm và hình dạng mong muốn, đồng thời khối này bị bỏ qua thay vì được đoán.
Dòng văn bản - tín hiệu nhiều dòng, thẻ định dạng và nơi thực sự kết thúc một khối
Mọi thứ sau dòng mã thời gian là văn bản gợi ý, được nối lại cùng với dòng mới. Không có giới hạn dòng và không có nỗ lực chỉnh lại dòng, do đó tín hiệu ba dòng vẫn tồn tại dưới dạng ba dòng. Đây là lý do tại sao dòng trống chịu tải: đó là điều duy nhất cho trình phân tích cú pháp biết văn bản đã kết thúc, đó là lý do tại sao tín hiệu có văn bản riêng chứa dòng trống sẽ được đọc dưới dạng hai khối và nửa sau sẽ được báo cáo là không có mã thời gian.
Cài đặt tín hiệu được phân tách khỏi dấu thời gian kết thúc bằng một khoảng cách từ hai khoảng trắng trở lên. WebVTT cho phép các chỉ thị định vị như căn chỉnh và vị trí dòng tuân theo thời gian kết thúc trên cùng một dòng, do đó, trình phân tích cú pháp sẽ tách chúng ra trước khi dấu thời gian được phân tích cú pháp và giữ chúng dọc theo tín hiệu. Một khoảng trắng không phải là dấu phân cách, giúp giữ cho dòng mã thời gian lộn xộn không bị mất thời gian kết thúc.
Ví dụ đã hoạt động: phân tích cú pháp tệp có 5 dấu hiệu với hai lỗi cố ý — trình phân tích cú pháp mạnh mẽ sẽ khôi phục nội dung nào và nội dung nó gắn cờ
Lấy một tệp năm khối trong đó khối ba có dòng mã thời gian bị hỏng để đọc 00:01:75,000 --> 00:01:78,000 và khối bốn đã mất hoàn toàn dòng mã thời gian trong quá trình sao chép và dán. Trình phân tích cú pháp đọc các khối một và hai một cách bình thường và đánh số chúng một và hai. Khối ba khớp với hình dạng của mã thời gian nhưng mang trường giây là 75, vì vậy khối này bị từ chối và được ghi lại dưới dạng dấu thời gian sai đặt tên cho dòng mà nó không thể đọc được.
Khối bốn không chứa mũi tên nào cả, vì vậy nó được ghi là không có dấu thời gian, trích dẫn bốn mươi ký tự đầu tiên của khối để có thể tìm thấy dòng này trong tệp gốc. Chặn năm phân tích cú pháp và trở thành tín hiệu thứ ba, không phải tín hiệu thứ năm, vì việc đánh số sẽ tính các tín hiệu thành công. Kết quả là có ba tín hiệu có thể sử dụng được và hai khiếu nại cụ thể, được xác định rõ ràng, thay vì một ngoại lệ đối với lỗi đầu tiên và không có thông tin về lỗi thứ hai.
Điều này không bao gồm những gì — ASS/SSA kiểu dáng, mã định vị và văn bản không có phụ đề được đưa vào SRT
Phần này mô tả SRT và các phần của WebVTT có chung hình dạng gợi ý của nó. Nó không bao gồm ASS và SSA, mang tiêu đề tập lệnh, định nghĩa kiểu và tham chiếu kiểu cho mỗi sự kiện và không thể đọc được bằng cách phân tách trên các dòng trống. Định giờ karaoke, lệnh vẽ và thẻ ghi đè nội tuyến mà các định dạng đó sử dụng nằm ngoài mô hình trình phân tích cú pháp tín hiệu và mã thời gian.
Nó cũng không sửa chữa văn bản. Bản ghi được dán vào một tệp không có mã thời gian sẽ tạo ra một danh sách các khối không có dấu thời gian, được báo cáo chính xác nhưng không thể chuyển thành phụ đề nếu không có thông tin về thời gian. Lỗi mã hóa là một mối quan tâm riêng: một tệp được giải mã với bộ ký tự sai sẽ phân tích thành các tín hiệu hoàn toàn hợp lệ có văn bản sai và không có mức độ kiểm tra cấu trúc nào sẽ phát hiện ra điều đó.
Bài học rút ra: phân tích cú pháp một cách khoan dung, viết nghiêm ngặt — cách Bộ công cụ phụ đề đọc lộn xộn SRT và viết lại một cách rõ ràng
Quy tắc làm việc là phân tích cú pháp một cách khoan dung và viết nghiêm ngặt. Trong quá trình đăng nhập, hãy chấp nhận giờ tùy chọn, dấu phân cách, dòng chỉ mục bị thiếu, kết thúc dòng hỗn hợp và dấu thứ tự byte ở đầu, đồng thời ghi lại mọi lỗi dưới dạng sự cố được xác định thay vì đưa vào lỗi đầu tiên, do đó, tệp có thể được sửa trong một lần chuyển. Trên đường ra, phát ra một hình dạng kinh điển.
Đó là những gì Bộ công cụ phụ đề thực hiện khi chuyển đổi. Các tín hiệu được đánh số lại từ một và giữ liền kề nhau, dấu thời gian được phát lại bằng dấu phẩy cho SRT và dấu chấm hoàn toàn cho WebVTT, đồng thời tệp trả về có hình dạng mà người chơi mong đợi bất kể đầu vào có bất thường đến mức nào. Dán tệp mà người chơi đã từ chối vào trình chuyển đổi và đọc các vấn đề được báo cáo trước; họ đặt tên cho gợi ý và trích dẫn dòng đó, thường là đủ để tìm ra lỗi trong bản gốc.