أدوات المطورين · SHA حاسبة التجزئة
نفس النص، مختلف SHA-256: أسطر جديدة، وترميزات، ووحدات البايت المخفية
· كيف يعمل
شا-256 ترميز معالجة النصوص تصحيح الأخطاء
يقول سطر الأوامر شيئًا واحدًا ويقول المتصفح شيئًا آخر لما يشبه النص نفسه. الأسطر الجديدة اللاحقة، UTF-16 وCRLF تشرح كل حالة تقريبًا؛ يوضح هذا المنشور كيفية العثور على البايتات المخفية.
يقول الصدى تجزئة واحدة، والأداة تقول تجزئة أخرى - عدم التطابق اليومي ولماذا لا يكون أي منهما خطأ
تقوم الوحدة الطرفية بالإبلاغ عن ملخص SHA-256 واحد ويقوم المتصفح بالإبلاغ عن ملخص آخر لما يبدو أنه نص متطابق. لم تتعطل أداة سطر الأوامر، ولم يتعطل المتصفح أيضًا. وحدات البايت التي يتم تجزئتها ليست متماثلة، على الرغم من أن الأحرف المرئية تبدو متطابقة. يتتبع هذا المنشور المصادر الأكثر شيوعًا لتلك البايتات المخفية ويوضح كيفية العثور عليها باستخدام حقل نصي وعارض سداسي عشري.
المشكلة لا تكمن أبدًا في خوارزمية SHA-256 نفسها. SHA-256 حتمية: تنتج نفس البايتات دائمًا نفس الملخص، ويكون الملخص صحيحًا. عندما تختلف النواتج، تختلف البايتات. ينشأ الالتباس لأن "نفس النص" غامض: يرى الشخص الأحرف، لكن دالة التجزئة ترى البايتات، والترجمة بينهما هي المكان الذي تختبئ فيه الاختلافات المخفية.
السطر الجديد اللاحق - كيف يقوم الصدى بإلحاق بايت بينما لا يقوم printf بذلك، وماذا يفعل ذلك في الملخص
يُلحق أمر الصدى في الصدفة حرف سطر جديد (U+000A، بايت 0x0A) إلى مخرجاته. هذا حسب التصميم: التقليد في Unix بأن الملفات النصية تنتهي بسطر جديد تعطي صدى لمهمة واحدة بسيطة. عندما تكتب echo abc في محطة طرفية وتوجهه إلى sha256sum، فإن البايتات التي تم استيعابها هي 61 62 63 0A (رموز ASCII لـ a وb وc والبايت للخط الجديد)، وليس 61 62 63. تستخدم الأداة ToolAcre لحساب التجزئة تجزئة البايتات 61 62 63 وتنتج نتيجة مختلفة.
لا يضيف أمر printf سطرًا جديدًا إلا إذا قمت بكتابته في سلسلة التنسيق. برينتف اي بي سي | يحسب sha256sum ملخص البايتات 61 62 63 وحده، وهو ما يطابق أداة المتصفح. وهذا هو السبب في أن مقارنة التجزئة تعني غالبًا تشغيل printf بدلاً من echo، أو التوصيل إلى sha256sum باستخدام العلامة -z، أو تحديد الإدخال الأولي بأي شكل توفره أداتك. السطر الجديد المخفي هو السبب الأكثر شيوعًا لعدم توافق أداة المتصفح وأداة سطر الأوامر.
UTF-8 مقابل UTF-16 - لماذا تختلف الأحرف نفسها في البايتات في بعض الأصداف والمحررين
يقوم UTF-8 وUTF-16 بترميز نفس الأحرف كتسلسلات بايت مختلفة. يتم ترميز الحرف é (U+00E9، وهو e بلكنة حادة) على شكل وحدتي بايت UTF-8: 0xC3 0xA9. في UTF-16، وهي الطريقة التي يمثل بها JavaScript السلاسل داخليًا، يشغل نفس الحرف بايتين بترتيب مختلف (اعتمادًا على النهاية) أو في شكل مختلف تمامًا إذا كان مكونًا من حرف أساسي وعلامة دمج. عندما تقوم بنسخ مقهى من تطبيق Windows ولصقه في أداة تجزئة المتصفح، فقد لا تتطابق وحدات البايت الخاصة بتجزئة الأداة مع ما تجزئته محطة Mac، لأن الأنظمة اختارت ترميزات أو نماذج تسوية مختلفة بشكل افتراضي.
تقوم أداة التجزئة ToolAcre بتحويل النص بشكل صريح إلى UTF-8 قبل التجزئة عبر TextEncoder. هذا هو نفس الترميز الذي يستخدمه سطر أوامر Unix افتراضيًا. يُظهر الكود المصدري في apps/dev/src/lib/base64.js الوظيفة textToBytes التي تستدعي TextEncoder().encode() الجديد، والتي تضمن UTF-8. إذا كان نظام آخر يستخدم UTF-16 أو اللاتينية-1 أو أي ترميز آخر، فستختلف وحدات البايت المنتجة. تعرض الأداة عدد البايتات بجانب الملخص، ولهذا السبب فإن لصق مقهى ومقارنتها بتجزئة سطر الأوامر سيُظهر أعداد بايت مختلفة إذا تباينت الترميزات.
CRLF، BOM والتطبيع - نهايات الأسطر وعلامات ترتيب البايت واللهجات المركبة مقابل اللكنات المتحللة كاختلافات إدخال غير مرئية
CRLF (سطر الإرجاع + تغذية السطر، البايتات 0x0D 0x0A) هو اصطلاح نهاية السطر في نظام التشغيل Windows؛ LF (تغذية السطر وحده، البايت 0x0A) هو اصطلاح Unix. يمكن للملف النصي الذي يبدو متطابقًا عند فتحه في محرر نصوص أن يحمل نهايات أسطر مختلفة، وتشكل تلك البايتات جزءًا من مدخلات التجزئة. الملف الذي تم تحريره على Windows وتم فحصه مقابل SHA-256 المحسوب على نظام Unix لن يتطابق إذا قام أحد الأنظمة بتحويل نهايات الأسطر ولم يفعل الآخر ذلك.
علامة ترتيب البايت (BOM، البايتات 0xEF 0xBB 0xBF لـ UTF-8) هي تسلسل اختياري في بداية الملف يشير إلى التشفير. يضيفه بعض المحررين. بعض الأدوات تجرده؛ يتجاهلها البعض. إذا كان الملف يحمل BOM وقمت بتجزئته بايت مقابل بايت، فإن BOM بايت تكون جزءًا من الملخص. إذا قمت بعد ذلك بنسخ النص المرئي (الذي يخفي العارض BOM منه) إلى أداة لا تضيف BOM، فلن تتطابق الملخصات. تضيف نماذج تسوية النص (NFD مقابل NFC لللكنات المركبة والمتحللة) طبقة أخرى: يمكن تمثيل نفس الحرف المميز كحرف واحد مركب مسبقًا أو كحرف أساسي متبوعًا بلكنة مجمعة، وتكون تسلسلات البايت مختلفة.
مثال عملي - سلسلة واحدة مجزأة بسطر جديد وبدونه، ثم في ترميزين، مع إظهار اختلاف كل بايت
طريقة التشخيص الأولى: استخدم أداة تفريغ سداسي عشرية أو محول عبر الإنترنت لمعرفة وحدات البايت التي تعمل عليها أدواتك بالضبط. الصق النص في برنامج تشفير base64، وقم بتشفيره، وسيكون لديك سجل نصي بالبايتات. ثم فك تشفير base64 في سطر الأوامر باستخدام base64 -d وقم بتوجيهه إلى od -A x -t x1z لرؤية تسلسل البايت السداسي. إذا تطابقت البايتات، فإن الخوارزمية صحيحة؛ إذا لم يفعلوا ذلك، فإن الفرق سيكون مرئيا.
طريقة التشخيص الثانية: استخدم حاسبة التجزئة ToolAcre SHA لتجزئة المدخلات الأطول تدريجيًا، بدءًا من حرف واحد. أضف سطرًا جديدًا (مما يعني كتابة Enter داخل مربع النص)، وأضف مسافات، وأضف النص نفسه باستخدام تسلسلات الهروب UTF-16 إذا جاء الإدخال من مصدر غير ASCII. شاهد تغير الملخص مع كل إضافة. يخبرك عدد البايتات المعروض بجانب الملخص بعدد البايتات التي تقوم الأداة بتجزئةها، مما يضيق نطاق البحث بشكل كبير.
الحالة السداسية والمسافات البيضاء في الإخراج – الاختلافات تجميلية بحتة
التمثيل الست عشري للملخص غير حساس لحالة الأحرف. تمثل الأحرف الكبيرة والصغيرة نفس البايتات: A = 10، a = 10. تصدر بعض الأدوات أحرفًا كبيرة، وبعضها صغيرًا، والبعض الآخر يسمح بذلك أيضًا. إذا كان أحد الملخصين صغيرًا والآخر كبيرًا، فهما نفس الملخص. تعتبر المسافة البيضاء في عرض الملخص تجميلية بحتة. الملخص المعروض كـ ba78 16bf مقابل ba7816bf هو نفسه؛ المساحة هي مجرد خيار التنسيق. لا تعتبر حالات عدم التطابق الناتجة عن حالة الأحرف أو المسافة البيضاء حالات عدم تطابق حقيقية.
تكون اختلافات التنسيق ذات العرض الثابت غير مرئية أيضًا على مستوى البايت. الملخص الذي يظهر باستخدام الواصلات أو المسافات أو النقطتين (مثل ba-78-16-bf) هو عبارة عن اتفاقية تنسيق تسهل على البشر القراءة، وليس تغييرًا في وحدات البايت الفعلية. تُصدر الأداة ToolAcre دائمًا أحرفًا صغيرة بدون فواصل، وهو التنسيق الذي تطبعه معظم أدوات سطر الأوامر. إذا كنت تقارن بأداة تنبعث بشكل مختلف، فقم بالتحويل إلى نفس التمثيل أولاً.
ما لا يغطيه هذا هو ملفات التجزئة، حيث تنطبق نفس المبادئ ولكن البايتات تأتي من القرص بدلاً من حقل نصي
تقوم حاسبة التجزئة ToolAcre SHA بإجراء تحويل UTF-8 قبل التجزئة، وتعرض عدد بايت الإدخال، وتقدم نماذج الإخراج الأساسية 64 والست عشرية. يُظهر الملف المصدر apps/dev/src/lib/hash.js وظيفة hashText التي تستدعيDigestBytes، والتي تمرر bytes.slice().buffer إلى crypto.subtle.digest. توثق التعليقات الموجودة في هذا الملف بوضوح أن الخطوة UTF-8 مقصودة وتلاحظ الفرق بين الترميزات المختلفة. اختبار المدخلات الخاصة بك مقابل المتجه المعروف (تجزئات abc إلى ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad بالنظام الست عشري) يثبت أن أداة المتصفح تعمل بشكل صحيح؛ يشير أي انحراف إلى اختلاف البايت في الإدخال.
يتبع تجزئة الملف نفس المبدأ. البايتات الموجودة في الملف هي ما يهم: يمكن أن يؤدي اختلاف نهاية السطر عند التصدير من نظام والاستيراد إلى نظام آخر إلى تغيير كل ملخص. توفر بعض الأدوات خيارات للتعامل مع نهايات الأسطر أثناء المقارنة؛ يقوم الآخرون بتجزئة الملف كما هو. إن معرفة ما إذا كانت أداتك تقوم بتجزئة الملف كملف ثنائي أو تقوم بإجراء تسوية النص أولاً أمر ضروري لإمكانية التكرار.
الوجبات الجاهزة: بايتات التجزئة، وليس النص - تقوم حاسبة التجزئة ToolAcre SHA بتجزئة البايتات التي تلصقها، لذا تحقق مما لصقته أولاً
تعمل المقارنة والتحقق فقط عندما تقوم بتجزئة نفس البايتات. ابدأ بتأكيد أنك تقوم بتجزئة نفس الإدخال بالضبط: قم بتشغيل echo -n (أو printf) بدلاً من echo لتجنب السطر الجديد، وحدد ترميز UTF-8 بشكل صريح إذا كانت أداتك تسمح بذلك، وتأكد من أن CRLF لم يتم إدراجه بواسطة محرر أو أداة مساعدة للنظام. ثم قم بالتجزئة باستخدام الآلة الحاسبة ToolAcre وأداة سطر الأوامر جنبًا إلى جنب. إذا تطابقت الملخصات، كانت البايتات متطابقة. إذا لم يحدث ذلك، فاستخدم عرض عدد البايتات وأسلوب التفريغ السداسي للعثور على الفرق المخفي.
بمجرد أن تفهم أين تباعدت وحدات البايت، يمكنك اختيار ما إذا كنت تريد تطبيعها للمقارنة. تهدف بعض المجاميع الاختبارية إلى التحقق من سلامة الملف تمامًا كما هو موجود على القرص، وفي هذه الحالة يكون تجزئة البايت مقابل البايت هو الهدف. ويهدف البعض الآخر إلى التحقق من أن المحتوى المرئي هو نفسه، وفي هذه الحالة تكون تسوية نهايات الأسطر والتشفير صحيحة. لا يوجد خطأ. يجيبون على أسئلة مختلفة. خوارزمية SHA-256 صحيحة دائمًا؛ السؤال هو فقط ما إذا كنت تطلب منه تجزئة نفس الإدخال في كلتا الحالتين.