เปรียบเทียบข้อความสองชิ้น _

อัลกอริทึม diff ทำงานอย่างไร

มุมมอง diff ทุกแบบในหน้านี้ผลิตโดย Myers algorithm — เทคนิคปี 1986 ของ Eugene W. Myers ที่หา edit script ที่สั้นที่สุดระหว่างสองลำดับ token ใน O((N+M)D) เวลา โดย D คือ edit distance อัลกอริทึมสร้างบน Longest Common Subsequence problem และ engine ทำงานทั้งหมดในเบราว์เซอร์ของคุณโดยใช้ไลบรารี open-source jsdiff

1. Tokenise ข้อมูลที่ป้อน — ก่อนเปรียบเทียบ อัลกอริทึมแบ่งแต่ละข้อมูลที่ป้อนเป็นลำดับ tokens ความละเอียดระดับบรรทัดแบ่งที่ newlines ความละเอียดระดับคำแบ่งที่ขอบเขต whitespace และ punctuation ความละเอียดระดับอักขระถือ Unicode code point แต่ละตัวเป็น token ของตัวเอง
2. สร้าง edit graph — Myers algorithm จำลองการเปรียบเทียบเป็นเส้นทางผ่าน grid 2D โดยเคลื่อนไปทางขวาหมายถึง "ลบจากต้นฉบับ" เคลื่อนลงหมายถึง "แทรกจากที่เปลี่ยนแปลง" และเคลื่อนแนวทแยงหมายถึง "token ตรงกันทั้งสองฝั่ง" อัลกอริทึมหาเส้นทางที่มีแนวทแยงมากที่สุดและสั้นที่สุด
3. ดึง LCS — การเคลื่อนแนวทแยงในเส้นทางที่สั้นที่สุด trace Longest Common Subsequence — tokens ที่ปรากฏในทั้งสอง input ในลำดับสัมพัทธ์เดิม ทุก token ใน LCS คือ "ไม่เปลี่ยนแปลง" ส่วนที่เหลือเป็นการเพิ่มหรือการลบ
4. ใช้ preprocessing options — ถ้าเปิด "ละเว้นตัวพิมพ์ใหญ่-เล็ก" ทั้งสอง input จะถูกเปลี่ยนเป็นตัวพิมพ์เล็กก่อน LCS pass เพื่อให้ "HELLO" และ "hello" นับเป็นตัวเดียวกัน "ละเว้นช่องว่าง" ยุบช่องว่างหลายตัวเป็นหนึ่ง "ตัดช่องว่างทุกบรรทัด" ลบ whitespace นำหน้าและต่อท้ายต่อบรรทัดก่อนเปรียบเทียบ
5. Render มุมมองที่เลือก — ผลลัพธ์คือ LCS เดิมที่แสดงสามวิธี: Side-by-side แสดงต้นฉบับด้านซ้ายและที่เปลี่ยนแปลงด้านขวาใน grid สองคอลัมน์พร้อม row highlights สีแดงและเขียว Unified แสดงคอลัมน์เดียวพร้อม − และ + นำหน้าบรรทัด เหมือนผลลัพธ์ของ git diff Inline แสดงการลบเป็น strikethrough สีแดงและการเพิ่มเป็น underline สีเขียวภายในกระแสข้อความเดียวกัน
6. คำนวณ summary strip — หลัง render เครื่องมือนับว่ามี tokens กี่ตัวที่ถูกเพิ่ม ลบ และไม่เปลี่ยนแปลง จากนั้นคำนวณ similarity เป็นอัตราส่วนของ tokens ที่ไม่เปลี่ยนแปลงต่อความยาวที่มากกว่าของสอง input ความคล้ายคลึง 100% หมายถึง inputs เหมือนกันหลัง preprocessing

ทำไมต้องใช้ diff checker

• Code review โดยไม่มี Git client — วางสอง config file เวอร์ชัน, SQL migration หรือ shell script สองเวอร์ชันแล้วดูว่าอะไรเปลี่ยน โดยไม่ต้อง clone repo, สลับ branch หรือรอ CI pipeline เครื่องมือนี้มีประโยชน์สำหรับการ review ด่วนระหว่าง pair programming, contractor handoffs ที่อีกฝ่ายยังไม่แชร์ Git history และ codebase เก่าที่ยังไม่มี version control unified view ให้ผลลัพธ์ที่คัดลอกตรงไปยัง thread แชทหรือตั๋วได้
• Redlines สัญญาและเอกสาร — Word-level diff แสดงว่า term ใดเปลี่ยนระหว่าง draft สัญญาได้เร็วกว่าแผง Track Changes ของ Word วาง clause A จาก draft แรกและ clause B จากสำเนาที่ execute และการแทนที่จะสว่างขึ้นเป็นสีแดงบนเขียวที่วลีที่เปลี่ยนพอดี ทีม paralegal และ procurement ใช้สิ่งนี้เพื่อตรวจสอบว่า redline นาทีสุดท้ายไม่ผ่านการ review ก่อนลงนามสัญญา
• การแก้ไข essay และ draft — นักเขียนที่เปรียบเทียบ draft แรกกับเวอร์ชันที่แก้ไขสามารถสลับไปที่ word granularity เพื่อดูทุกการแทนที่ การแทรก และการตัดโดยไม่ต้องอ่านซ้ำทั้งสองสำเนา กระบวนการเดิมใช้ได้สำหรับนักแปลที่ตรวจสอบการเปลี่ยนแปลงกับข้อความต้นฉบับ บรรณาธิการที่ตรวจสอบว่า copy edit รักษา voice ของผู้แต่ง และทีมข่าวที่ reconcile บทความที่เผยแพร่กับ draft ที่ยื่น
• เปรียบเทียบ log และ config — sysadmins ที่เปรียบเทียบ server config snapshots สองอัน, cron schedules สองอัน หรือผลลัพธ์ ps aux สองอันสามารถใช้ line granularity เพื่อค้นหา parameter ที่เปลี่ยนตัวเดียวในไฟล์ 200 บรรทัดในไม่กี่วินาที จับคู่กับตัวเลือก Ignore-whitespace และ diff ที่ noisy จากการจัดตำแหน่งเท่านั้นจะยุบเหลือ parameter changes ที่สำคัญจริง ๆ

การใช้งานทั่วไป

Text diff ปรากฏที่ท้ายทุก edit cycle ในงานเขียน พัฒนาและ operations

• Pull request review: วางสอง function implementations เคียงข้างกันเพื่อเข้าใจ logic change ก่อนอนุมัติ โดยไม่ต้อง checkout branch
• QA การแปลภาษา: เปรียบเทียบ source string ภาษาอังกฤษกับ equivalent ที่แปลแล้วในระดับคำเพื่อตรวจจับการแทรก การละเว้น หรือการสลับ terminology ที่นักแปลอาจแนะนำ
• การวิเคราะห์ incident: diff snapshots Kubernetes manifest สองอันหรือผลลัพธ์ "docker inspect" สองอันในระดับบรรทัดเพื่อแยก configuration change ที่เกิดก่อน outage

ตัวอย่างการทำงาน

ลอง server config ห้าบรรทัด ต้นฉบับ: host=localhost, port=5432, dbname=app_db, user=app, password=secret ที่เปลี่ยนแปลง: host=db.prod.example.com, port=5432, dbname=app_db, user=app_prod, password=secret ด้วย line granularity และ Side-by-side view บรรทัด 1 แสดงสีแดงด้านซ้าย (host=localhost) และสีเขียวด้านขวา (host=db.prod.example.com) บรรทัด 4 แสดงสีแดง (user=app) และสีเขียว (user=app_prod) และบรรทัด 2, 3 และ 5 ยังคงไม่เปลี่ยนทั้งสองฝั่ง summary strip รายงาน 2 การเพิ่ม 2 การลบ 3 ไม่เปลี่ยน และความคล้ายคลึง 60% — สามในห้าบรรทัดคงเดิม สลับไปที่ word granularity และ diff แน่นขึ้น: เฉพาะค่าทางขวาของ = ในบรรทัด 1 และ 4 สว่างขึ้น keys ไม่เปลี่ยนแปลง และความคล้ายคลึงขึ้นเป็นประมาณ 85% เพราะ LCS นับ host, user และ punctuation รอบข้างเป็นส่วนที่คงเดิม

สิ่งนี้ทำงานในเบราว์เซอร์ของฉันหรือไม่?

ใช่ การคำนวณ diff ทั้งหมดทำงาน client-side โดยใช้ไลบรารี open-source jsdiff ที่โหลดพร้อมหน้า ไม่มีสิ่งที่คุณพิมพ์ วาง หรือเปรียบเทียบถูกส่งไปยังเซิร์ฟเวอร์ใด คุณสามารถยืนยันได้เอง: เปิด browser DevTools สลับไปที่แท็บ Network ล้าง log คลิกเปรียบเทียบ และยืนยันว่าไม่มี network request ที่ fire สำหรับขั้นตอนการเปรียบเทียบ

เปอร์เซ็นต์ความคล้ายคลึงหมายความว่าอะไร?

ความคล้ายคลึงคำนวณเป็น tokens ที่ไม่เปลี่ยน / max(tokens ทั้งหมดในต้นฉบับ, tokens ทั้งหมดที่เปลี่ยนแปลง) คะแนน 100% หมายถึงทั้งสอง input เหมือนกันหลัง preprocessing options คะแนน 0% หมายถึงไม่มี token ใดที่ share ระหว่าง input ตัวชี้วัดนี้เป็นการประมาณ edit distance คร่าว ๆ — มีประโยชน์เป็นตัววัดเร็ว — ไม่ใช่คะแนน plagiarism หรือ originality

Diff JSON / YAML / XML เชิงความหมายได้ไหม?

ไม่ได้ในเครื่องมือนี้ นี่คือ text-level diff ดังนั้นการ reformat เฉพาะ whitespace ของ JSON หรือ XML ยังแสดงการเปลี่ยนแปลงมากแม้ข้อมูลเหมือนกันทางตรรกะ การเรียงลำดับ object keys ใน JSON ใหม่ก็แสดงเป็นการเปลี่ยนแปลงแม้ parser ส่วนใหญ่ถือว่าลำดับ key ไม่สำคัญ สำหรับ semantic diff จริงที่เปรียบเทียบ parsed object trees และละเว้นลำดับ key และการจัดรูปแบบ เรากำลังวางแผนเครื่องมือ JSON Diff โดยเฉพาะ ตอนนี้ให้ normalize ทั้งสอง input เป็น indentation และลำดับ key เดียวกันก่อนวางที่นี่

มุมมอง unified กับ side-by-side ต่างกันอย่างไร?

Side-by-side render สองคอลัมน์: ต้นฉบับด้านซ้ายและที่เปลี่ยนแปลงด้านขวา พร้อม removed lines highlighted สีแดงด้านซ้ายและ added lines highlighted สีเขียวด้านขวา Unchanged lines ปรากฏในทั้งสองคอลัมน์ aligned ที่ row เดิม Unified render คอลัมน์เดียวพร้อม prefix − และพื้นหลังสีแดงสำหรับ removed lines และ prefix + และพื้นหลังสีเขียวสำหรับ added lines — layout เดียวกับที่ git diff พิมพ์ไปที่ terminal ใช้ unified เมื่อต้องการคัดลอกผลลัพธ์เป็น patch file หรือวางใน code review thread ใช้ side-by-side เมื่อ visual alignment ของสิ่งที่แทนที่อะไรสำคัญกว่า patch text ดิบ

วาง original ด้านซ้าย เวอร์ชันที่เปลี่ยนแปลงด้านขวา เลือก view และ granularity และการเปรียบเทียบปรากฏในมิลลิวินาที เปิด Live mode และ diff รันซ้ำทุกครั้งที่พิมพ์ฝั่งใดฝั่งหนึ่ง ดาวน์โหลดผลลัพธ์เป็นไฟล์ unified .patch มาตรฐานที่ git apply ใช้งานได้โดยตรง ไม่อัปโหลด ไม่มีบัญชี ไม่มี vendor API key ไม่มี quota