เครื่องมือสำหรับนักพัฒนา · การเปรียบเทียบข้อความ
ทุกบรรทัดเปลี่ยนไปเหรอ? การสิ้นสุดบรรทัด ช่องว่างต่อท้าย และ BOM ในส่วนต่าง
· มันทำงานอย่างไร
ข้อความที่แตกต่าง การสิ้นสุดบรรทัด การดีบัก
วินิจฉัยสาเหตุที่มองไม่เห็นสามประการของการเปรียบเทียบที่รายงานทุกบรรทัดว่าแตกต่างกัน และแสดงวิธีบอกว่าคุณมีสาเหตุใดก่อนที่จะกล่าวโทษผู้เขียน
ไฟล์เดียวกันที่บันทึกสองครั้งและเห็นได้ชัดว่าเขียนใหม่ - ตั้งค่ากรณีทั่วไปของไฟล์ที่ถูกแก้ไขในระบบปฏิบัติการสองระบบ
การบันทึกสองครั้งอาจดูเหมือนเป็นการเขียนใหม่เมื่อโปรแกรมแก้ไขเปลี่ยนอักขระที่มองไม่เห็น แต่การทำงานของ ToolAcre ขึ้นอยู่กับอักขระที่เปลี่ยนแปลง โดยจะทำให้การสิ้นสุดบรรทัดเป็นปกติก่อนที่จะจับคู่ ในขณะที่ช่องว่างที่ขอบของบรรทัดและ U+FEFF ที่จุดเริ่มต้นยังคงเป็นเนื้อหาบรรทัดธรรมดา เว้นแต่ตัวเลือกอื่นจะเปลี่ยนคีย์
สร้างฟิกซ์เจอร์วินิจฉัยแทนการคาดเดาจากสี เปรียบเทียบคู่หนึ่งที่แตกต่างกันเฉพาะตอนจบ คู่อื่นต่างกันในการเว้นวรรคต่อท้าย และคู่ที่สามที่มี BOM นำหน้า คู่ที่ได้รับการควบคุมจะเปิดเผยขอบเขตของเครื่องมือได้อย่างน่าเชื่อถือมากกว่าไฟล์จริงที่มีการเปลี่ยนแปลงที่มองไม่เห็นหลายอย่างในคราวเดียว
CRLF เทียบกับ LF: อักขระที่ส่วนท้ายของทุกบรรทัด — อธิบายว่าทำไม Windows จึงลงท้ายบรรทัดด้วยอักขระสองตัว, Unix ด้วยอักขระหนึ่งตัว และความแตกต่างจึงเห็นการขึ้นบรรทัดใหม่อย่างไร
`splitLines` แทนที่ CRLF และ CR เดียวด้วย LF จากนั้นจึงแยก การทดสอบแสดงให้เห็นว่าแบบแผนทั้งสามสร้างอาร์เรย์เดียวกัน ดังนั้น CRLF-ความแตกต่างเพียงอย่างเดียวจึงไม่สามารถมองเห็นได้ แม้ว่า Ignore whitespace จะปิดอยู่ก็ตาม การกล่าวอ้างของโครงร่างที่ว่าทุกบรรทัดจะแตกต่างกันนั้นขัดแย้งกับการดำเนินการนี้
การขึ้นบรรทัดใหม่ครั้งสุดท้ายไม่ได้สร้างแถวเพิ่มเติม หลังจากแยกแล้ว รายการว่างของเทอร์มินัลหนึ่งรายการจะถูกลบออก บรรทัดว่างตรงกลางยังคงเป็นหน่วยเปรียบเทียบ ดังนั้นลักษณะการทำงานจึงแยกแยะรูปแบบการลงท้ายไฟล์จากการแยกแนวตั้งโดยเจตนาภายในเอกสาร
ToolAcre ทำให้ CRLF, CR และ LF เป็นมาตรฐานก่อนการเปรียบเทียบ ดังนั้นการเปลี่ยนแปลงเฉพาะตอนจบจึงหายไป
ช่องว่างต่อท้ายยังคงอยู่ในบรรทัดเดิม จากการเปรียบเทียบทั่วไป `name=value` และ `name=value ` มีคีย์ที่แตกต่างกัน ละเว้นช่องว่างที่ตัดปลายทั้งสองข้างและยุบการรันภายใน เพื่อให้ตัวเลือกนั้นสามารถทำให้การจับคู่ตรงกันในขณะที่ยังคงรักษาข้อความต้นฉบับด้านซ้ายในแถวที่เท่ากันที่แสดงอยู่
ไลบรารียังใช้ตัวเลือก `ignoreTrailingWhitespace` ที่แคบกว่า แต่ UI ปัจจุบันไม่เปิดเผย บทความต้องไม่อธิบายช่องทำเครื่องหมายที่ผู้ใช้ไม่สามารถเลือกได้ แผงที่จัดส่งเสนอกรณีละเว้น ละเว้นความแตกต่างของช่องว่างทั้งหมด และยุบการรันที่ไม่มีการเปลี่ยนแปลงเป็นเวลานาน
เครื่องหมายลำดับไบต์ที่ด้านบนของไฟล์ — อธิบายอักขระ U+FEFF ที่เอดิเตอร์บางคนเติมหน้าไฟล์ UTF-8 และเหตุใดจึงทำให้เพียงบรรทัดแรกแตกต่างกัน
เครื่องหมายลำดับไบต์ UTF-8 ที่ถอดรหัสเป็นข้อความ JavaScript คือ U+FEFF ที่จุดเริ่มต้นของบรรทัดแรก `splitLines` ไม่มีการลบ BOM อย่างชัดเจน ด้วยการจับคู่แบบธรรมดา อักขระนั้นสามารถทำให้เฉพาะแถวแรกต่างกันในขณะที่บรรทัดต่อๆ ไปยังคงเท่ากัน
การดำเนินการ JavaScript ช่องว่างอาจถือว่า U+FEFF เป็นช่องว่างเมื่อละเว้นการเรียกใช้ช่องว่าง `trim` แต่บทความนี้ไม่ได้สรุปลักษณะดังกล่าวเป็นพฤติกรรมการถอดรหัสไฟล์ เอดิเตอร์ได้รับสตริง มันไม่อ่านไบต์ของไฟล์หรือการเข้ารหัสรายงาน ตรวจสอบอักขระจริงเมื่อแหล่งที่มาระดับไบต์มีความสำคัญ
ตัวอย่างการทำงาน: การบอกสาเหตุทั้งสามออกจากกัน - ให้เส้นทางการตัดสินใจ: ความแตกต่างเฉพาะบรรทัดแรกชี้ไปที่ BOM ทุกบรรทัดชี้ไปที่จุดสิ้นสุด เส้นที่กระจัดกระจายชี้ไปที่ช่องว่างต่อท้าย
เริ่มด้วย `alpha beta` และ `alpha beta`: ผลลัพธ์จะเหมือนกัน จากนั้นเปรียบเทียบ `alpha beta` กับ `alpha beta`: โหมดปกติจะแสดงแถวที่ถูกแทนที่ ส่วนโหมดละเว้นช่องว่างจะถือว่าตรงกัน สุดท้ายเติม U+FEFF ไว้หน้า alpha ฝั่งหนึ่งและสังเกตผลที่บรรทัดแรก
ลำดับนั้นแยกสาเหตุโดยใช้การดำเนินการที่ได้รับการพิสูจน์แล้วจากพื้นที่เก็บข้อมูล หากทุกบรรทัดยังคงแตกต่างกันหลังจากสิ้นสุดการทำให้เป็นมาตรฐาน ให้ตรวจสอบเนื้อหา การเยื้อง หรืออักขระต่อท้าย แทนที่จะโทษ CRLF เพียงอย่างเดียว หากมีเพียงบรรทัดเดียวที่แตกต่างกัน ให้ตรวจสอบจุดโค้ดนำหน้าก่อนที่จะเขียนไฟล์ใหม่ทั้งหมด
การใช้ตัวเลือกช่องว่างในการวินิจฉัย — แสดงให้เห็นว่าการเปิดใช้งานการละเว้นช่องว่างใน ToolAcre การเปรียบเทียบข้อความสามารถดูดซับช่องว่างต่อท้ายและเสียงที่สิ้นสุดบรรทัดเพื่อให้การแก้ไขที่แท้จริงโดดเด่น
การละเว้นช่องว่างมีประโยชน์สำหรับสัญญาณรบกวนช่องว่างต่อท้าย เนื่องจากจะตัดแต่งและย่อคีย์บรรทัด จะไม่รับผิดชอบในการซ่อน CRLF กับ LF; ที่เกิดขึ้นแล้วระหว่างการแยกทาง การแยกขั้นตอนเหล่านั้นออกจากกันจะช่วยป้องกันข้อสรุปที่ทำให้เข้าใจผิดว่าตัวเลือกใดที่ซ่อมแซมการเปรียบเทียบได้
เรียกใช้ทั้งสองมุมมองเนื่องจากการตัดแต่งสามารถซ่อนการเยื้องที่มีความหมาย และการย่อสามารถเปลี่ยนแปลงค่าความกว้างคงที่หรือตัวอักษรสตริงได้ ผลลัพธ์ที่ทำให้เป็นมาตรฐานแบบเงียบบอกว่าคีย์ตรงกันภายใต้การเปลี่ยนแปลงนั้น ไม่รับรองว่าไฟล์ต้นฉบับเป็นแบบไบต์เหมือนกันหรือเปลี่ยนความหมายได้
โหมดช่องว่างจะวินิจฉัยช่องว่างต่อท้าย ในขณะที่การสิ้นสุดบรรทัดถูกทำให้เป็นมาตรฐานอยู่แล้ว
Text diff จะไม่แปลงไฟล์ กำหนดค่า Git เปลี่ยนการตั้งค่าตัวแก้ไข หรือเปิดเผยไบต์ฐานสิบหก ยอมรับการดำเนินการสตริงที่วางและรายงาน คำแนะนำเกี่ยวกับ `.gitattributes`, `core.autocrlf` หรือการซ่อมแซมการเข้ารหัสเป็นของเครื่องมือที่สามารถตรวจสอบการทำงานแยกกันได้
เครื่องมือนี้ยังไม่สามารถแยกแยะได้ว่าอักขระที่มองไม่เห็นเข้ามาในข้อความได้อย่างไร ฟอร์แมตเตอร์ คลิปบอร์ด ตัวถอดรหัส หรือการแก้ไขด้วยตนเองอาจสร้างสตริงเดียวกัน ใช้การเปรียบเทียบเพื่อค้นหาแถว จากนั้นตรวจสอบไปป์ไลน์ต้นทางก่อนกำหนดสาเหตุ
ประเด็นสำคัญ: ตรวจสอบสิ่งที่มองไม่เห็นก่อนที่จะตำหนิผู้เขียน — สรุปเส้นทางการวินิจฉัยและบันทึกการเปรียบเทียบที่ทำงานในเบราว์เซอร์ของคุณ เพื่อให้ไฟล์ที่ละเอียดอ่อนยังคงอยู่ในเครื่องของคุณ
ตรวจสอบสิ่งที่มองไม่เห็นตามลำดับคงที่: ตอนจบ ต่อท้าย หรือช่องว่างภายใน จากนั้นนำอักขระพิเศษ การทดสอบของ ToolAcre ให้ผลลัพธ์ที่แน่ชัดสำหรับหมวดหมู่แรก และตัวเลือกต่างๆ จะช่วยแยกหมวดหมู่ที่สองออกจากกัน ตัวที่สามอาจต้องมีตัวตรวจสอบอักขระอยู่นอกเส้นทางนี้
การแยกบรรทัดฝั่งเบราว์เซอร์ทำให้ความแตกต่างในการสิ้นสุดข้ามแพลตฟอร์มหายไปตามการออกแบบ สะดวก แต่ก็หมายความว่าเครื่องมือนี้ไม่สามารถพิสูจน์ได้ว่าไฟล์ต้นฉบับสองไฟล์ใช้ไบต์ขึ้นบรรทัดใหม่แบบฟิสิคัลเดียวกัน เลือกยูทิลิตี้ byte-aware เมื่อต้องรักษาการแสดงสายหรือพื้นที่เก็บข้อมูลที่แน่นอนไว้เป็นข้อกำหนด