วิดีโอและคำบรรยาย · ชุดเครื่องมือคำบรรยาย
วิธีที่เบราว์เซอร์แยกวิเคราะห์ไฟล์ SRT: บล็อก ดัชนี รหัสเวลา และข้อความ
· มันทำงานอย่างไร
คำบรรยาย ถ ไฟล์รูปแบบ
SRT ดูไม่สำคัญจนกว่าคุณจะพบกับไฟล์จริง โพสต์นี้อธิบายวิธีที่ parser แยกบล็อก อ่านดัชนีและรหัสเวลา จัดการข้อความหลายบรรทัด และกู้คืนจากบล็อกที่มีรูปแบบไม่ถูกต้องซึ่งมีไฟล์ในโลกแห่งความเป็นจริง
ไฟล์ 'ดูดี' แต่สัญญาณหายไปครึ่งหนึ่ง - รูปแบบที่ดูผ่อนปรนซ่อนความคาดหวังที่เข้มงวดได้อย่างไร
SRT ไม่มีเนื้อหาข้อกำหนด ไม่มีการลงทะเบียน MIME และไม่มีเครื่องมือตรวจสอบที่มาพร้อมกับผู้เล่น สิ่งที่มีอยู่แทนคือรูปร่างที่ซอฟต์แวร์ส่วนใหญ่เห็นด้วย: ตัวเลข บรรทัดรหัสเวลา ข้อความหนึ่งบรรทัดขึ้นไป ตามด้วยบรรทัดว่าง เนื่องจากรูปร่างเป็นแบบทั่วไปแทนที่จะระบุไว้ สองไฟล์จึงสามารถดูถูกต้องในโปรแกรมแก้ไขข้อความในขณะที่โหลดเพียงไฟล์เดียว และความล้มเหลวมักจะเงียบ ผู้เล่นที่ไม่สามารถอ่านคิวได้มักจะข้ามไปแทนที่จะรายงาน ดังนั้นไฟล์ที่มีบล็อกที่เสียหายจะเล่นโดยมีช่องว่างแทนที่จะเป็นข้อผิดพลาด
parser จึงมีงานสองงานที่ดึงไปในทิศทางตรงกันข้าม ต้องยอมรับรูปแบบที่มีอยู่ในไฟล์จริง เนื่องจากไฟล์ถูกสร้างขึ้นโดยบริการถอดเสียง การแก้ไขด้วยมือ และตัวแปลงรูปแบบที่แต่ละแห่งตั้งสมมติฐานที่แตกต่างกัน นอกจากนี้ ยังต้องปฏิเสธการอ่านที่จะวางคิวผิดเวลา เนื่องจากการประทับเวลาผิดแบบเงียบๆ นั้นเลวร้ายยิ่งกว่าความล้มเหลวที่รายงาน
การแยกออกเป็นบล็อก — เส้นว่างเป็นตัวคั่นและปัญหากับช่องว่างที่หลงทางและ CRLF
การแยกเกิดขึ้นบนบรรทัดว่าง ไม่ใช่บนหมายเลขดัชนี parser ทำให้การสิ้นสุดบรรทัดเป็นปกติก่อน โดยแทนที่ทั้งคู่ CRLF และ CR เดี่ยวด้วยการขึ้นบรรทัดใหม่เพียงบรรทัดเดียว เนื่องจากไฟล์ที่เขียนบน Windows และแก้ไขบน Unix สามารถมีทั้งสองบรรทัดได้ จากนั้นจะแยกบรรทัดใหม่สองบรรทัดขึ้นไป ตัดแต่ละบล็อกผลลัพธ์และละทิ้งบล็อกว่าง การสั่งซื้อนั้นมีความสำคัญ: การแยกก่อนที่จะทำให้เป็นมาตรฐานจะทำให้การขึ้นบรรทัดใหม่ผิดพลาดที่ส่วนท้ายของบรรทัดรหัสเวลา และรหัสเวลาจะไม่ตรงกัน
เครื่องหมายลำดับไบต์จะถูกถอดออกก่อนสิ่งใดสิ่งหนึ่ง UTF-8 BOM ที่จุดเริ่มต้นของไฟล์คือสามไบต์ที่ parser ไร้เดียงสาเห็นว่าเป็นส่วนหนึ่งของหมายเลขดัชนีแรก ซึ่งเพียงพอที่จะทำให้คิวแรกไม่สามารถอ่านได้ในขณะที่คิวถัดไปทุกคิวแยกวิเคราะห์ ช่องว่างต่อท้ายบนบรรทัดตัวคั่นว่างจะถูกจัดการโดยการตัด ดังนั้นไฟล์ที่มีบรรทัดว่างมีช่องว่างยังคงแบ่งอย่างถูกต้อง
บรรทัดดัชนี — เหตุใดตัวเลขจึงมักผิด ซ้ำกัน หรือหายไป และเหตุใดผู้แยกวิเคราะห์จึงไม่ควรเชื่อถือตัวเลขเหล่านั้น
หมายเลขดัชนีถูกอ่านแล้วละเว้น หมายเลขไฟล์จริงจะชี้นำจากศูนย์ เริ่มการกำหนดหมายเลขใหม่หลังจากการรวม ทำซ้ำตัวเลขหลังจากการแก้ไขด้วยตนเอง หรือละบรรทัดทั้งหมดเมื่อตัวแปลงเขียนไฟล์ การเชื่อถือตัวเลขเหล่านั้นหมายถึงการสืบทอดข้อผิดพลาดเหล่านั้นทั้งหมด ดังนั้น parser จึงกำหนดหมายเลขตามลำดับของตัวเองแทน โดยนับสัญญาณที่ตัวชี้นำที่สร้างไว้สำเร็จจนถึงตอนนี้
ตัวเลือกนั้นยังอธิบายด้วยว่าเหตุใด parser จึงไม่จำเป็นต้องมีบรรทัดดัชนี โดยจะค้นหาบรรทัดรหัสเวลาโดยการค้นหาบล็อกสำหรับบรรทัดแรกที่มีลูกศร แทนที่จะถือว่ารหัสเวลาเป็นบรรทัดที่สอง บล็อกที่ไม่มีเส้นดัชนีจะแยกวิเคราะห์ตามปกติ และบล็อกที่มีเส้นหลงทางสองเส้นก่อนที่รหัสเวลาจะยังคงแยกวิเคราะห์ เนื่องจากตำแหน่งไม่ใช่สิ่งที่ระบุรหัสเวลา
เส้นรหัสเวลา — HH:MM:SS,mmm --> HH:MM:SS,mmm รูปแบบที่ยอมรับได้ และรูปแบบที่ทำลายผู้เล่น
บรรทัดรหัสเวลาจะจับคู่กับนิพจน์ทั่วไปรายการเดียว และค่าเผื่อในบรรทัดนั้นเป็นไปตามเจตนา ชั่วโมงเป็นทางเลือก เนื่องจาก WebVTT อนุญาตให้มีการอ่านแบบสองฟิลด์และผู้แปลงปล่อยค่าดังกล่าว ยอมรับเครื่องหมายจุลภาคหรือจุดเต็มเป็นตัวคั่นมิลลิวินาที ไม่ว่าไฟล์จะอ้างว่าอยู่ในรูปแบบใดก็ตาม เนื่องจากตัวคั่นแบบผสมเป็นเรื่องปกติเพียงพอที่การปฏิเสธจะทำให้ไฟล์ที่ดีมากกว่าไฟล์ที่ไม่ดีเสียหาย ตัวเลขเศษส่วนจะถูกบุไว้ทางด้านขวา ดังนั้นคิวที่ลงท้ายด้วยตัวเลขหลักเดียวจึงอ่านเป็นหลายร้อยมิลลิวินาทีแทนที่จะเป็นหน่วย
การอ่านสองครั้งถูกปฏิเสธ ฟิลด์นาทีหรือวินาทีที่อยู่เหนือห้าสิบเก้าถูกปฏิเสธแทนที่จะดำเนินการ เนื่องจากเก้าสิบวินาทีไม่ใช่การอ่านนาฬิกา และมักจะบ่งชี้ว่าไฟล์เสียหายหรือแปลงผิด การทำให้เป็นมาตรฐานอย่างเงียบ ๆ จะเป็นการย้ายคิว บรรทัดที่จุดเริ่มต้นหรือจุดสิ้นสุดล้มเหลวในการแยกวิเคราะห์ทำให้เกิดปัญหาที่บันทึกไว้โดยตั้งชื่อข้อความที่ไม่เหมาะสมและรูปร่างที่คาดหวัง และบล็อกนั้นถูกข้ามไปแทนที่จะคาดเดา
บรรทัดข้อความ — ตัวชี้นำหลายบรรทัด การจัดรูปแบบแท็ก และตำแหน่งที่บล็อกสิ้นสุด
ทุกสิ่งที่อยู่หลังบรรทัดไทม์โค้ดคือข้อความคิวที่เชื่อมกลับเข้าด้วยกันด้วยการขึ้นบรรทัดใหม่ ไม่มีการจำกัดบรรทัดและไม่มีการพยายามจัดเรียงใหม่ ดังนั้นคิวสามบรรทัดจึงคงอยู่เป็นสามบรรทัด นี่คือเหตุผลที่บรรทัดว่างรับน้ำหนัก: มันเป็นสิ่งเดียวที่บอก parser ว่าข้อความสิ้นสุดลงแล้ว ซึ่งเป็นเหตุผลว่าทำไมคิวที่มีข้อความของตัวเองมีบรรทัดว่างจะถูกอ่านเป็นสองช่วงตึกและครึ่งหลังจะถูกรายงานว่าไม่มีรหัสเวลา
การตั้งค่าคิวจะถูกแยกออกจากการประทับเวลาสิ้นสุดโดยการเว้นวรรคตั้งแต่ 2 ช่องขึ้นไป WebVTT อนุญาตให้ใช้คำสั่งการวางตำแหน่ง เช่น การจัดตำแหน่งและการจัดวางบรรทัดตามเวลาสิ้นสุดบนบรรทัดเดียวกัน ดังนั้น parser จะแยกคำสั่งเหล่านั้นออกก่อนที่จะแยกวิเคราะห์การประทับเวลาและเก็บไว้ข้างคิว ช่องว่างเดียวไม่ใช่ตัวคั่น ซึ่งจะทำให้บรรทัดรหัสเวลาที่ไม่เป็นระเบียบไม่ให้สูญเสียเวลาสิ้นสุด
ตัวอย่างการทำงาน: การแยกวิเคราะห์ไฟล์ห้าคิวที่มีข้อผิดพลาดโดยเจตนาสองครั้ง - โปรแกรมแยกวิเคราะห์ที่แข็งแกร่งจะกู้คืนอะไรและสิ่งที่มันติดธง
ใช้ไฟล์ห้าบล็อกซึ่งบล็อกที่สามมีบรรทัดรหัสเวลาเสียหายเพื่ออ่าน 00:01:75,000 --> 00:01:78,000 และบล็อกที่สี่สูญเสียบรรทัดรหัสเวลาทั้งหมดในระหว่างการคัดลอกและวาง โปรแกรมแยกวิเคราะห์จะอ่านบล็อกหนึ่งและสองตามปกติ และระบุหมายเลขเป็นหนึ่งและสอง บล็อกที่สามตรงกับรูปร่างของรหัสเวลา แต่มีฟิลด์วินาทีที่เจ็ดสิบห้า ดังนั้นจึงถูกปฏิเสธและบันทึกเป็นการประทับเวลาที่ไม่ดีซึ่งทำให้ไม่สามารถอ่านบรรทัดได้
บล็อกที่สี่ไม่มีลูกศรเลย ดังนั้นจึงถูกบันทึกว่าไม่มีการประทับเวลา โดยอ้างอิงอักขระสี่สิบตัวแรกของบล็อกเพื่อให้สามารถค้นหาบรรทัดได้ในไฟล์ต้นฉบับ บล็อกห้าแยกวิเคราะห์และกลายเป็นคิวสาม ไม่ใช่คิวห้า เนื่องจากการนับเลขนับตัวชี้นำที่ประสบความสำเร็จ ผลลัพธ์ที่ได้คือสัญญาณที่ใช้งานได้สามสัญญาณและข้อร้องเรียนที่ระบุเฉพาะสองรายการ แทนที่จะเป็นข้อยกเว้นสำหรับข้อผิดพลาดครั้งแรกและไม่มีข้อมูลเกี่ยวกับข้อผิดพลาดที่สอง
สิ่งนี้ไม่ครอบคลุม — ASS/SSA การออกแบบ รหัสตำแหน่ง และข้อความที่ไม่มีคำบรรยายที่ทิ้งลงใน SRT
สิ่งนี้จะอธิบาย SRT และส่วนของ WebVTT ที่มีรูปร่างคิวเหมือนกัน ไม่ครอบคลุมถึง ASS และ SSA ซึ่งมีส่วนหัวของสคริปต์ คำจำกัดความของสไตล์ และการอ้างอิงสไตล์ต่อเหตุการณ์ และที่ไม่สามารถอ่านได้โดยการแยกบรรทัดว่าง การกำหนดเวลาคาราโอเกะ คำสั่งการวาด และแท็กแทนที่แบบอินไลน์ที่รูปแบบเหล่านั้นใช้อยู่นอกรูปแบบตัวแยกวิเคราะห์คิวและรหัสเวลา
นอกจากนี้ยังไม่สามารถซ่อมแซมข้อความได้ การถอดเสียงที่วางลงในไฟล์ที่ไม่มีรหัสเวลาจะสร้างรายการบล็อกที่ไม่มีการประทับเวลา ซึ่งได้รับการรายงานอย่างถูกต้อง แต่ไม่สามารถเปลี่ยนเป็นคำบรรยายได้หากไม่มีข้อมูลการกำหนดเวลาที่ไม่มีอยู่ ข้อผิดพลาดในการเข้ารหัสเป็นข้อกังวลอีกประการหนึ่ง: ไฟล์ที่ถอดรหัสด้วยชุดอักขระที่ไม่ถูกต้องจะแยกวิเคราะห์เป็นตัวชี้นำที่ถูกต้องสมบูรณ์ซึ่งมีข้อความผิด และไม่มีการตรวจสอบโครงสร้างจำนวนเท่าใดที่จะตรวจพบสิ่งนั้น
ประเด็นสำคัญ: แยกวิเคราะห์อย่างผ่อนปรน เขียนอย่างเคร่งครัด — วิธีที่ Subtitle Toolkit อ่าน SRT ที่ยุ่งเหยิง และเขียนกลับอย่างสะอาด
กฎการทำงานคือการแยกวิเคราะห์อย่างผ่อนปรนและเขียนอย่างเคร่งครัด ระหว่างทางให้ยอมรับชั่วโมงเสริม ทั้งตัวคั่น เส้นดัชนีที่ขาดหายไป การลงท้ายบรรทัดแบบผสม และเครื่องหมายลำดับไบต์นำหน้า และบันทึกข้อผิดพลาดทั้งหมดเป็นปัญหาที่พบ แทนที่จะโยนไปที่ปัญหาแรก เพื่อให้สามารถแก้ไขไฟล์ได้ในการส่งผ่านครั้งเดียว เมื่อออกไป ให้ปล่อยรูปร่างตามรูปแบบบัญญัติหนึ่งรูปแบบ
นั่นคือสิ่งที่ Subtitle Toolkit ทำเมื่อทำการแปลง ตัวชี้นำจะถูกกำหนดหมายเลขใหม่จากหมายเลขหนึ่งและเก็บไว้ต่อเนื่องกัน การประทับเวลาจะถูกส่งอีกครั้งด้วยเครื่องหมายจุลภาคสำหรับ SRT และจุดเต็มสำหรับ WebVTT และไฟล์ที่กลับมาคือรูปร่างที่ผู้เล่นคาดหวัง ไม่ว่าอินพุตจะไม่สม่ำเสมอเพียงใด วางไฟล์ที่ผู้เล่นปฏิเสธลงในตัวแปลงและอ่านปัญหาที่รายงานก่อน พวกเขาตั้งชื่อคิวและอ้างอิงบรรทัด ซึ่งโดยปกติจะเพียงพอที่จะค้นหาข้อบกพร่องในต้นฉบับ