เครื่องมือสำหรับนักพัฒนา · การเปรียบเทียบข้อความ
เหตุใด Windows และ Unix จึงไม่เห็นด้วยกับการสิ้นสุดบรรทัด: เรื่องราว CR, LF และ CRLF
· พื้นหลัง
ข้อความที่แตกต่าง การสิ้นสุดบรรทัด ประวัติซอฟต์แวร์
ติดตามการสิ้นสุดบรรทัดตั้งแต่เครื่องพิมพ์ดีดและเทเลไทป์ไปจนถึงระบบปฏิบัติการสมัยใหม่ และอธิบายว่าทำไมแบบแผนสองแบบจึงยังอยู่ร่วมกันในทุกโปรเจ็กต์ข้ามแพลตฟอร์ม
ตัวละครที่มองไม่เห็นหนึ่งตัว ความขัดแย้งหลายทศวรรษ เปิดขึ้นด้วยความรำคาญข้ามแพลตฟอร์มอย่างต่อเนื่อง
การสิ้นสุดบรรทัดจะมองไม่เห็นในโปรแกรมแก้ไขทั่วไป แต่อาจมีความสำคัญต่อไฟล์และโปรโตคอล อย่างไรก็ตาม ใน ToolAcre CR, LF และ CRLF จะถูกทำให้เป็นมาตรฐานก่อนการเปรียบเทียบบรรทัด คู่ที่แตกต่างกันเฉพาะในตัวแยกเหล่านั้นจะสร้างอาร์เรย์เส้นเดียวกันและผลลัพธ์ที่เหมือนกัน
พฤติกรรมดังกล่าวช่วยตอบคำถามเชิงปฏิบัติสำหรับเส้นทางนี้ ในขณะเดียวกันก็จำกัดสิ่งที่สามารถวินิจฉัยได้ การเปรียบเทียบไม่สามารถพิสูจน์ได้ว่าบรรทัดใหม่ใดที่ไฟล์ต้นฉบับมีอยู่หลังจากข้อความไปถึงบรรณาธิการ จำเป็นต้องมีเครื่องมือ byte-aware สำหรับการเก็บรักษาหรือการตรวจสอบโปรโตคอล
การขึ้นบรรทัดใหม่และการป้อนบรรทัดบนเครื่องพิมพ์ดีด - อธิบายการกระทำทางกายภาพทั้งสองอย่างที่ตัวละครอธิบายไว้ในตอนแรก
เงื่อนไขการขึ้นบรรทัดใหม่และการป้อนบรรทัดมีความหมายทางกายภาพและในอดีต แต่พื้นที่เก็บข้อมูลไม่มีแหล่งที่มาของเครื่องพิมพ์ดีด การทำซ้ำเรื่องราวต้นกำเนิดเชิงกลจากความทรงจำจะเป็นการละเมิดสัญญาหลักฐาน แม้ว่าเรื่องราวจะฟังดูคุ้นเคยก็ตาม
บทความนี้จึงถือว่า CR เป็น ` ` code unit and LF as ` ` เฉพาะในกรณีที่การใช้งานใช้เท่านั้น คำอธิบายทางประวัติศาสตร์ควรเพิ่มในภายหลังจากมาตรฐานหลักหรือเอกสารสำคัญ แทนที่จะยืมมาจากโครงร่างที่ไม่ใช่แหล่งที่มาอย่างชัดเจน
ความหมายของเครื่องพิมพ์ดีดเป็นการกล่าวอ้างทางประวัติศาสตร์ที่ต้องใช้แหล่งข้อมูลภายนอก
ในทำนองเดียวกัน ไฟล์ต้นฉบับไม่ได้จัดทำเอกสารแบบแผนเทเลไทป์หรือการตัดสินใจของระบบปฏิบัติการในช่วงแรกๆ โดยเปิดเผยเฉพาะตัวเลือกความเข้ากันได้ใน JavaScript ปัจจุบัน: แทนที่ทุก CRLF หรือ CR เดี่ยวด้วย LF ก่อนที่จะแยก
การแปลงนั้นยอมรับข้อความที่วางที่สร้างขึ้นภายใต้แบบแผนหลายประการ โดยไม่ต้องเติมเอาต์พุตด้วยการเปลี่ยนแปลงเฉพาะการลงท้ายเท่านั้น เป็นการตัดสินใจในการดำเนินการที่มองเห็นได้ในนิพจน์ทั่วไปเดียวและตรึงโดยการทดสอบสำหรับทั้งสามรูปแบบ
สายโทรพิมพ์และระบบปฏิบัติการเป็นหลักฐานนอกพื้นที่เก็บข้อมูล
เป็นเรื่องปกติที่จะเชื่อมโยง Unix กับ LF, Windows กับ CRLF และระบบเก่ากว่าด้วย CR เดียว แต่พื้นที่เก็บข้อมูลปัจจุบันไม่สามารถใช้เป็นข้อพิสูจน์ทางประวัติศาสตร์ของการยอมรับเหล่านั้นได้ การอ้างสิทธิ์ที่ปลอดภัยใช้งานได้: อินพุตทั้งสามกลายเป็น LF ภายใน `splitLines`
เทอร์มินัล LF จะไม่สร้างแถวว่างสุดท้าย ในขณะที่บรรทัดว่างตรงกลางยังคงอยู่ ความแตกต่างนี้หมายความว่าเนื้อหาเชิงตรรกะยังคงอยู่ แม้ว่าความแตกต่างทางกายภาพของตัวคั่นจะถูกลบไปแล้วก็ตาม การเปรียบเทียบจะเป็นแบบเส้น ไม่ใช่แบบรักษาไบต์
รหัสพิสูจน์ว่าแบบแผนสามแบบทำให้เป็นมาตรฐาน มันไม่ได้พิสูจน์ว่าทำไมระบบถึงนำมันมาใช้
โปรโตคอลเครือข่ายและข้อความบางตัวระบุตัวยุติบรรทัดที่แน่นอน แต่ข้อกำหนดต้องมาจากข้อกำหนดเฉพาะ การทำให้เป็นมาตรฐานของ ToolAcre ทำให้ไม่เหมาะสมสำหรับการพิสูจน์ความสอดคล้องกับรูปแบบเส้นลวดดังกล่าว เนื่องจากหลักฐานตัวคั่นดั้งเดิมถูกลบออกโดยเจตนา
ใช้โปรแกรมดูเลขฐานสิบหกหรือเครื่องมือตรวจสอบโปรโตคอลก่อนแยกวิเคราะห์เมื่อลำดับ CRLF ตรงทั้งหมดมีความสำคัญ ผลลัพธ์ความแตกต่างข้อความใหม่ทั้งหมดสามารถยืนยันบรรทัดลอจิคัลที่ตรงกันและปกปิดข้อบกพร่องระดับการขนส่งไปพร้อมๆ กัน ข้อสังเกตทั้งสองอาจเป็นจริงได้เนื่องจากเครื่องมือตอบคำถามต่างกัน
ข้อกำหนดของโปรโตคอลจำเป็นต้องมีข้อกำหนดเฉพาะของตนเองและละเว้นไว้ที่นี่
เปรียบเทียบ `alpha beta`, `alpha beta` และ `alpha beta` เป็นคู่ แต่ละกรณีให้สองบรรทัดคือ alpha และ beta โดยไม่มีการเพิ่มหรือลบ ความเท่ากันนี้ไม่ได้เกิดจากตัวเลือกละเว้นช่องว่าง เพราะมีการปรับรูปแบบระหว่างการแบ่งบรรทัดแล้ว
เพิ่มช่องว่างต่อท้ายในแถวเบต้าหนึ่งแถว จากนั้นโหมดธรรมดาจะรายงานความแตกต่าง เปิดใช้งานละเว้นช่องว่างและมันอาจจะหายไป ลำดับจะแยกการจัดการบรรทัดใหม่ออกจากการจัดการช่องว่างของคีย์บรรทัด และป้องกันการให้เครดิตตัวเลือกที่ไม่ถูกต้อง
ตัวอย่างการทำงาน: แบบฟอร์มสิ้นสุดทั้งสามแบบเปรียบเทียบว่าเท่ากันก่อนตัวเลือกช่องว่าง
เส้นทางนี้ไม่ได้กำหนดค่าตัวแก้ไข เขียนไฟล์ใหม่ ตั้งค่าแอตทริบิวต์ Git หรือการสิ้นสุดการแปลงจำนวนมาก นอกจากนี้ยังไม่เปิดเผยตัวคั่นเดิมในแถวผลลัพธ์ สตริงที่วางจะเข้าสู่ไปป์ไลน์การเปรียบเทียบ ไม่ใช่ยูทิลิตีการย้ายขึ้นบรรทัดใหม่
สาเหตุทางประวัติศาสตร์และมาตรฐานของโปรโตคอลจะถูกละเว้นแหล่งที่มาที่รอดำเนินการ ความยับยั้งชั่งใจนั้นทำให้บทความเล็กลงแต่แม่นยำ: แบบแผนสามข้อทำอะไรในการใช้งานนี้ ซึ่งบรรทัดว่างยังคงอยู่ และเหตุใดความเท่าเทียมกันที่นี่จึงไม่สร้างเอกลักษณ์ของไบต์
ประเด็นสำคัญ: รู้ว่าข้อความของคุณมีแบบแผนแบบใด — สรุปประวัติและวิธีที่การเปรียบเทียบข้อความของ ToolAcre ช่วยยืนยันว่าความแตกต่างเป็นเพียงการลงท้ายบรรทัดเท่านั้น
รู้ว่าหลักฐานใดที่รอดจากเครื่องมือนี้ หลังจากการทำให้เป็นมาตรฐาน ToolAcre สามารถเปรียบเทียบเนื้อหาบรรทัดแบบลอจิคัลระหว่างตัวคั่นทั่วไปได้ ไม่สามารถบอกคุณได้ว่าแหล่งข้อมูลใดที่ใช้แบบแผนใด หรือผู้บริโภคดาวน์สตรีมต้องการลำดับไบต์เดียวที่แน่นอนหรือไม่
ใช้ส่วนต่างของเบราว์เซอร์สำหรับการตรวจสอบโดยเจ้าหน้าที่และการตรวจสอบระดับไบต์สำหรับพื้นที่เก็บข้อมูลหรือการบังคับใช้โปรโตคอล เครื่องมือมีความน่าเชื่อถือเมื่อการแปลงมีความชัดเจน ผู้ตรวจสอบยังคงรับผิดชอบในการเลือกสิ่งที่รักษาทรัพย์สินที่พวกเขาจำเป็นต้องตรวจสอบ