حاسبة الوقت

تقوم أداة فحص الفروق بمقارنة نصين وتوضيح الأسطر التي تختلف بينهما بدقة. الصق النص الأصلي (نسخة "ما قبل التعديل") في مربع النص الأيسر والنص المعدل (نسخة "ما بعد التعديل") في مربع النص الأيمن؛ وستقوم الأداة بتشغيل مقارنة تعتمد على خوارزمية (LCS) وتحديد كل اختلاف في غضون أجزاء من الثانية.

تظهر الأسطر المضافة باللون الأخضر، والأسطر المحذوفة باللون الأحمر، بينما تُظهر الأسطر المُعدَّلة تمييزاً على مستوى الحروف للجزء الذي تم تغييره بالفعل. يعرض سطر الملخص في الأعلى عدد الأسطر المضافة والمحذوفة والمُعدَّلة بالإضافة إلى نسبة التشابه.

استخدمها لأي مقارنة نصوص عادية:

• الكود المصدري
• إعدادات JSON
• ملفات تعريف YAML
• صادرات CSV
• ملفات السجل (logs)
• مسودات Markdown
• النصوص العادية

تتعامل الأداة مع مدخلات UTF-8 بحجم يصل إلى عدة ميغابايت لكل جانب دون أي توقف.

والأهم من ذلك: يتم تنفيذ كل بايت من عمليات الحساب محلياً داخل متصفحك. لا يتم إرسال أي شيء إلى الخادم، ولا يتم تسجيل أي بيانات، ولا يغادر أي شيء جهازك — مما يجعلها آمنة تماماً للأكواد الخاصة، والمستندات الداخلية، والبيانات السرية.

تتطلب مقارنة نصين ثلاث خطوات سريعة:

• الخطوة 1: الصق النص الأصلي في المربع الأيسر. هذه هي نسخة "قبل" — الملف كما كان قبل التعديلات، المسودة الأصلية، أو الإعدادات السابقة. استخدم اختصار Ctrl+A ثم Ctrl+C من أي محرر نصوص أو متصفح لنسخ النص، ثم استخدم Ctrl+V للصقه في أداة فحص الفروق.
• الخطوة 2: الصق النص المعدل في المربع الأيمن. هذه هي نسخة "بعد" — الملف المُحرَّر، المسودة الجديدة، أو الإعدادات المُحدَّثة. يتم حساب الفروق تلقائياً بمجرد احتواء كلا الجانبين على محتوى.
• الخطوة 3: اقرأ النتيجة. الأسطر الخضراء هي إضافات موجودة في اليمين وليست في اليسار؛ والأسطر الحمراء هي عمليات حذف موجودة في اليسار وليست في اليمين؛ والأسطر ذات التمييز على مستوى الحروف هي أسطر "مُعدَّلة" (زوج من الحذف والإضافة على محتوى متطابق تقريباً).

يمنحك الملخص الموجود في الأعلى نظرة عامة شاملة: عدد الإضافات، وعدد الحذف، ونسبة تشابه تتراوح من 0% (لا يوجد تطابق) إلى 100% (متطابق تماماً).

قم بتفعيل خيار "تجاهل المسافات الفارغة" إذا كانت التغييرات الوحيدة تتعلق بإعادة التنسيق؛ وقم بتفعيل خيار "تجاهل حالة الأحرف" إذا كنت لا تهتم بالفرق بين الحروف الكبيرة والصغيرة مثل Hello وhello.

تعمل أدوات الفروق وفقاً لواحد من ثلاثة مستويات من الدقة: السطر، أو الكلمة، أو الحرف.

• مقارنة سطر بسطر هي الوضع الافتراضي العام للكود والإعدادات: يتم التعامل مع كل سطر كحدة واحدة، وتحدد أداة الفروق الأسطر الكاملة التي تمت إضافتها أو حذفها أو تغييرها بشكل جوري. هذا هو ما تعرضه أدوات GNU diff وgit diff وطلببات السحب في GitHub وعروض الفروق في بيئات التطوير.
• مقارنة كلمة بكلمة (تسمى أحياناً "فروق الكلمات") تقسم النص عند حدود المسافات الفارغة — وهي أفضل للنصوص الأدبية حيث غالباً ما تحدث التعديلات داخل الجمل.
• مقارنة حرف بحرف هي أعلى درجات الدقة، وتُستخدم داخلياً بواسطة معظم أدوات الفروق لتحديد النص الفرعي الدقيق الذي يختلف داخل السطر المُعدَّل.

تُظهر الأداة أعلاه مقارنة الأسطر كعرض أساسي ومقارنة الحروف كتمييز على الأسطر المُعدَّلة — وهي نفس النهج ثنائي المستوى الذي تستخدمه بيئات VS Code وJetBrains وGitHub.

استخدم مقارنة الأسطر لمراجعة الأكواد، ومقارنة الكلمات لتحرير النصوص، ومقارنة الحروف فقط للمقارنات القصيرة (الجمل الفردية، والمعرفات، وروابط URL).

يعتبر الكود المصدري الاستخدام الأكثر شيوعاً لأدوات الفروق — فكل مراجعة للكود، وكل طلب سحب (PR)، وكل التزام في git يتضمن مقارنة الأكواد.

تتعامل أداة فحص الفروق مع أي لغة برمجة لأن خوارزمية LCS مستقلة عن لغة البرمجة: JavaScript، TypeScript، Python، Go، Rust، Java، Kotlin، Swift، C، C++، C#، PHP، Ruby، Scala، Elixir، Clojure، نصوص الـ shell، ملفات Dockerfiles، Terraform HCL، SQL — كلها تعمل بنفس الطريقة.

أفضل الممارسات لمقارنة الأكواد: قم بتنسيق كلا الجانبين باستخدام نفس أداة تنسيق الكود (مثل Prettier للغتي JS/TS، وBlack للغة Python، وgofmt لغة Go، وrustfmt لغة Rust) قبل اللصق، حتى لا تؤدي الاختلافات في المسافات والأسلوب إلى التشويش على فروق الدلالات الحقيقية. إذا تعذر عليك إعادة التنسيق، استخدم خيار "تجاهل المسافات الفارغة" لتخطي فروق المسافات البادئة أو اللاحقة.

عند مقارنة لغات مختلفة (مقارنة تطبيق مكتوب بلغة Python بنسخة مطورة بلغة Go على سبيل المثال)، ستقوم مقارنة الأسطر بعملها ولكن ستكون نسبة التشابه مضللة — فالوحدة ذات المعنى هنا هي التشابه الهيكلي وليست تطابق الأسطر.

تعتبر فروق ملفات JSON واحدة من أكثر حالات الاستخدام طلباً — حيث تُستخدم لمقارنة استجابات واجهات برمجة التطبيقات (APIs)، وملفات الإعدادات، وملفات package.json، وصادرات البيانات المهيكلة.

خطوة استباقية هامة: قم بتنسيق الجانبين بشكل متطابق تماماً. استخدم التنسيق المقروء (Pretty-print) مع نفس المسافة البادئة (عادة 2 أو 4 مسافات) ورتب مفاتيح الكائنات أبجدياً. بدون هذا التوحيد، قد ينتج عن مستند JSON متطابق هيكلياً فرق مليء بالتشويش لمجرد أن المفاتيح مرتبة بترتيب مختلف.

أدوات لتوحيد التنسيق:

• أداة jq مع علامة --sort-keys
• دالة json.dumps في بايثون مع معامل sort_keys=True
• موقع jsonformatter.org

لمقارنة ملفات JSON مع فهم دلالاتها (حيث يكون {a:1, b:2} مساوياً لـ {b:2, a:1})، فإن الأدوات المخصصة مثل json-diff (عبر npm) أو jq أو معيار RFC 6902 JSON Patch تنتج مخرجات أفضل من مقارنة الأسطر.

تعمل أداة مقارنة الأسطر المذكورة أعلاه بشكل جيد مع ملفات JSON عندما يكون كلا الجانبين موحدين مسبقاً؛ وإذا كنت بحاجة بانتظام إلى مقارنة دلالات JSON، ففكر في استخدام مكتبة تدعم صيغة JSON ضمن بيئة عملك.

YAML وCSV هما تنسيقان يعتمدان على الأسطر ويمكن مقارنتهما بدقة باستخدام الأدوات المعتمدة على الأسطر — وعادةً ما يكون التشويش فيهما أقل من JSON لأن ملفات YAML لا تحتوي على أقواس ولأن ملفات CSV لها هيكل صفوف ثابت.

نصائح لمقارنة ملفات YAML: تأكد من أن كلا الجانبين يستخدمان نفس المسافات البادئة (الفرق بين 2 و4 مسافات مهم؛ لأن المسافات في YAML ذات دلالة)، ونفس اصطلاح ترتيب المفاتيح، ونفس نمط الاقتباس للنصوص. بالنسبة لملفات Kubernetes وDocker Compose وملفات سير عمل CI بصيغة YAML، فإن أداة مقارنة الأسطر أعلاه هي الأداة القياسية المستخدمة في كل مراجعة للأكواد.

نصائح لمقارنة ملفات CSV: تأكد من أن كلا الملفين يمتلكان نفس الفاصل (فاصلة، فاصلة منقوطة، أو علامة تبويب)، ونفس نهايات الأسطر (LF مقابل CRLF — العديد من ملفات CSV الصادرة عن Excel تستخدم CRLF)، ونفس ترتيب الأعمدة، ورؤوس الأعمدة المتطابقة.

بالنسبة لملفات CSV الكبيرة (أكثر من 10,000 صف)، فإن الأدوات المخصصة مثل csvdiff (لـ Aswinkarthik) أو daff (لـ paulfitz) تنتج فروقاً مهيكلة توضح الصف والأعمدة التي تغيرت؛ أما بالنسبة للملفات الأصغر، فإن أداة مقارنة الأسطر أعلاه تعتبر سريعة وبسيطة.

تعتمد جميع أدوات الفروق الحديثة على عائلة خوارزميات أطول سلسلة فرعية مشتركة (LCS).

نُشرت خوارزمية الفروق الأصلية بواسطة جيمس هانت ودوغ ماكلروي في مختبرات بيل (Bell Labs) في عام 1976 — وهي نفس الورقة البحثية التي أفرزت أمر 'diff' في نظام يونكس والذي لا يزال مستخدماً حتى يومنا هذا. وفي عام 1986، نشر يوجين مايرز (Eugene Myers) بحثاً بعنوان "خوارزمية لاكتشاف الفروق بزمن O(ND) وتنويعاتها"، والتي قامت بتحسين خوارزمية LCS لتتناسب مع الحالة الشائعة لوجود اختلافات صغيرة في مدخلات ضخمة.

تعمل خوارزمية مايرز في زمن قدره O((N+M)D) حيث يمثل N+M إجمالي حجم المدخلات وD عدد التعديلات — وهو أسرع بكثير من خوارزمية O(N×M) التقليدية في حالات الفروق الواقعية النموذجية (حيث يكون D صغيراً مقارنة بـ N+M). تنفذ أدوات GNU diff وgit diff وlibxdiff (المستخدمة في Mercurial وSubversion وGitHub) خوارزمية مايرز أو التنويعات المرتبطة بها ارتباطاً وثيقاً مثل "patience diff" و"histogram diff".

تستخدم أداة فحص الفروق أعلاه تنفيذ خوارزمية LCS بلغة JavaScript والمض خصيصاً لأداء المتصفح — وهي سريعة بما يكفي لمدخلات تصل إلى عدة ميغابايت لكل جانب.

هناك طريقتان رئيسيتان لعرض الفروق: العرض جنباً إلى جنب (العرض المنقسم) والعرض الموحد.

العرض جنباً إلى جنب يضع النسخة الأصلية والمعدلة في عمودين مع محاذاة التغييرات أفقياً — وهو أسهل للقراءة البشرية لأنه يمكنك رؤية النسختين معاً، كما أن التجميع المرئي يجعل البنية واضحة. هذا هو العرض الافتراضي في بيئات التطوير المتكاملة (VS Code, IntelliJ)، وطلببات سحب GitHub (في وضع "الانقسام")، ومعظم أدوات الفروق عبر الإنترنت.

العرض الموحد يدمج الأسطر المحذوفة والمضافة في عمود واحد مع بادئات '-' و '+' بالإضافة إلى 3 أسطر من السياق غير المتغير أعلى الأسفل وأسفله — وهو أكثر إيجازاً، وقابل للبرمجة (فهو تنسيق ملفات التصحيح patch الذي تستهلكه أدوات 'git apply' و 'patch')، وهو الوضع الافتراضي في أدوات سطر الأوامر ومراجعات الكود المستندة إلى البريد الإلكتروني (مثل القائمة البريدية لنواة لينكس، وغيرها).

اختر العرض جنباً إلى جنب للمراجعة البصرية للتغييرات الصغيرة والمتوسطة؛ واختر العرض الموحد للعرض المختصر لعمليات إعادة الكتابة الكبيرة، أو للنسخ كملف تصحيح، أو للمشاركة في السياقات النصية فقط (الدردشة، البريد الإلكتروني، سطر الأوامر).

مقارنة المستندات تغطي نطاقاً واسعاً: تتبع التغييرات التي أجراها المحرر على مسودة، مقارنة نسختين من عقد قانوني، التحقق مما تم إعادة صياغته مقابل ما تم نسخه (اكتشاف الانتحال الخفيف)، أو تدقيق انحراف الترجمة.

استخدم أداة فحص الفروق لأي مستند نصي عادي. بالنسبة لتنسيقات المصادر المختلفة:

• بالنسبة لـ ملفات Microsoft Word ذات اللاحقة .docx، قم بالتصدير إلى نص عادي أولاً (File > Save As > Plain Text في برنامج Word، أو Format > Plain Text في LibreOffice). ستفقد التنسيق (الخط العريض، المائل، العناوين) ولكنه سيلتقط كل تغيير نصي.
• بالنسبة لـ ملفات PDF، استخدم أداة تحويل PDF إلى نص أولاً (مثل pdftotext من حزمة poppler-utils، أو الأدوات المعتمدة على المتصفح)، ثم قارن النص المستخرج.
• بالنسبة لـ مستندات Google Docs، استخدم ميزة سجل الإصدارات المدمجة (File > Version history > See version history) والتي تظهر الفروق وتتبع المؤلفين بشكل أصلي.

بالنسبة للنصوص الطويلة التي تكون فيها فواصل الأسطر تعسفية، فكر في استخدام أدوات مقارنة على مستوى الكلمات (مثل أمر diff --word-diff في git) — فهي تتجاهل التفاف الأسطر وتبرز التغييرات الحقيقية على مستوى الكلمات.

الخصوصية أمر مهم عند مقارنة الأكواد الخاصة، أو المستندات الداخلية، أو السجلات المالية، أو بيانات العملاء، أو أي نص سرّي. تقوم العديد من أدوات الفروق عبر الإنترنت برفع النصوص المدخلة إلى خوادمها للمعالجة — وهو أمر مريح ولكنه يشكل خطراً حقيقياً على المحتوى الحساس.

أداة فحص الفروق الموجودة على هذه الصفحة تعمل بالكامل من جانب العميل: خوارزمية LCS تعمل بلغة JavaScript داخل متصفحك، ولا يتم إجراء أي استدعاء لـ fetch() يغادر جهازك إطلاقاً، ولا يتم إنشاء أي سجل في أي خادم. تحقق من ذلك بنفسك عن طريق فتح أدوات المطورين (DevTools) > تبويب Network والصق النص — وسترى أن عدد الطلبات الخارجية الصادرة هو صفر.

للحصول على أقصى قدر من الخصوصية على المحتوى شديد الحساسية، استخدم أداة محلية لا تتصل بالشبكة أبداً:

• أداة GNU diff (مثبتة مسبقاً في Linux/macOS)
• أداة git diff (لأي مستودع)
• ميزة الفروق المدمجة في VS Code
• فروق بيئات تطوير JetBrains
• أداة Beyond Compare

للمقارنات لمرة واحدة للنصوص الأقل حساسية، تمنحك أداة موثوقة تعتمد على المتصفح مثل تلك الموجودة أعلاه راحة الأدوات الويب وخصوصية الأدوات المحلية.

بالنسبة للمطورين، تعتبر الفروق بنية أساسية يومية — مراجعة الأكواد، مراجعة طلبات السحب، حل تعارضات الدمج، مقارنة الإعدادات عبر البيئات المختلفة، وتتبع الأخطاء البرلمانية "لماذا تغير هذا".

استخدم git diff للتغييرات المتتبعة (git diff، git diff --staged، git diff main..feature، git diff HEAD~3)؛ واستخدم أداة فحص الفروق عبر الإنترنت المذكورة أعلاه للمقارنات العرضية (شخص ما قام لصق مقطع في Slack، تقوم بمقارنة تفريغ متغيرات البيئة بين مرحلة التجربة staging والإنتاج prod، وتقوم بمرجة إعدادات زميلك المحلية مع إعداداتك).

لحل تعارضات الدمج، تفوق أدوات الفروق ثلاثية الاتجاهات (kdiff3، p4merge، وعرض الدمج ثلاثي الاتجاهات المدمج في VS Code) أدوات الفروق ثنائية الاتجاهات لأنها توضح السلف المشترك بالإضافة إلى كلا الجانبين.

لمراجعة الأكواد على نطاق واسع، تستخدم طلببات سحب GitHub (PRs) وطلبات الدمج في GitLab (MRs) وGerrit نفس خوارزمية الفروق السطرية LCS تحت الغطاء — وما تراه في طلب السحب هو نفس الخوارزمية التي يمكنك تشغيلها محلياً باستخدام git diff أو لصقها في الأداة عبر الإنترنت أعلاه. الفروق قابلة للإنتاج عبر الأدوات المختلفة: المدخلات نفسها تنتج دائماً الفروق نفسها.

كلاهما ينتج فروقاً تعتمد على خوارزمية LCS وتكافئ بعضها رياضياً — الخوارزمية الأساسية واحدة.

استخدم git diff عندما:

• تمتلك ملفات داخل مستودع git
• تريد مقارنة الالتزامات (commits) أو الفروع (branches) أو التغييرات المُجهّزة (staged)
• تحتاج إلى كتابة سكربتات للفروق (فحوصات CI، خطاطيف ما قبل الالتزام pre-commit hooks)
• تحتاج إلى مقارنة واعية بالتاريخ (git log، git blame)
• أو كنت تقوم بإنشاء ملف تصحيح patch (git format-patch)

استخدم فاحص الفروق عبر الإنترنت عندما:

• تمتلك نصاً خاماً غير موجود في مستودع (مقطع من محادثة، استجابة API، تفريغ إعدادات)
• تريد مقارنة بصرية سريعة جنباً إلى جنب دون إعداد مستودع
• كنت تقارن بين أنظمة لا يتوفر فيها git (شخص يستخدم جهاز Chromebook، أو اجتماع لمراجعة الكود)
• أو أن المحتوى حساس وتريد أداة موثوقة تعمل حصرياً في المتصفح دون أي طلبات شبكية.

تنتمي كلا الأداة إلى مجموعة أدوات المطور؛ ولا تحل أداة منهما محل الأخرى. الميزات الخارقة للأداة عبر الإنترنت هي عدم الحاجة لأي إعداد والعرض البصري جنباً إلى جنب؛ بينما تتمثل الميزات الخارقة لأداة git في الوعي بالتاريخ والتكامل مع المنظومة البرمجية.