أدوات المطور · التشفير ووحدة فك التشفير Base64
ما مدى حجم Base64 الذي يصنع بياناتك؟ تم حل الحمل الزائد 4/3
· كيف يعمل
base64 ترميز أداء
يعد إخراج Base64 أكبر بحوالي الثلث من مدخلاته، بالإضافة إلى الحشو وربما فواصل الأسطر. يستمد هذا المنشور الصيغة الدقيقة ويطبقها على أحجام واقعية حتى تتمكن من الحكم على التكلفة.
الرمز 30 KB الذي أصبح 40 KB في الحزمة - قفزة ملموسة في الحجم فاجأت مراجعة البناء
أيقونة 30 KB المضمنة كـ Base64 في ملف CSS تصبح 40 KB، ويظهر سؤال مراجعة البناء: من أين أتت 10 KB الإضافية؟ عامل التوسيع لـ Base64 هو دائمًا 4/3: كل إدخال بثلاثة بايت ينتج عنه إخراج أربعة بايت (أربعة أحرف). بالنسبة للإدخال 30 KB (30,000 bytes)، قسّم على ثلاثة للحصول على 10,000 مجموعات، واضرب في أربعة للحصول على 40,000 bytes الإخراج.
الرياضيات حتمية ولا مفر منها: Base64 ليس تنسيق ضغط. إذا كان تضمين الأصل يكلف 33% المزيد من النطاق الترددي ويتم تحميل الصفحة بشكل أسرع بسبب طلب واحد أقل HTTP، فهذه مقايضة تستحق القياس. إذا كانت التكلفة 33% أكثر وكان التحميل أبطأ، فإن التضمين لا يستحق ذلك. تأتي نسبة 4/3 من تخطيط البت. ثلاث بايتات هي 24 bits؛ أربعة أحرف Base64 تحمل 24 bits (كل منها يحمل ستة بتات).
لماذا 4/3 هي الأرضية - ستة بتات لكل حرف مقابل ثمانية لكل بايت، ومن أين يأتي الحمل المتبقي
حتى الآن، النسبة هي 1:1. لكن أحرف Base64 هي نص (ASCII 0–127)، ومتوسط ASCII حرف في UTF-8 أو ترميز 1 اللاتيني هو بايت واحد. لذا فإن أربعة أحرف Base64 هي إخراج أربعة بايتات لإدخال ثلاثة بايتات، نسبة 4/3. هذا ليس عالميًا: إذا تم إخراج Base64 كتنسيق ثنائي (بايت واحد لكل حرف، معبأة في ستة بتات)، ستكون النسبة 3/4 (ضغط).
نظرًا لأن Base64 مصمم لنقل النص، فهو يستخدم أحرفًا نصية، وتبلغ التكلفة 33% زيادة في الحجم. تضيف الحشوة هامشًا صغيرًا في النهاية. إذا كان طول الإدخال مضاعفًا لثلاثة، فلا حاجة إلى حشوة. إذا كان طول الإدخال 1 mod 3 (بايت واحد أقل من عدة)، حرفين الحشو = تمت إضافتهما، وزيادة الإخراج بمقدار 2. إذا كان 2 mod 3، فسيتم إضافة حرف حشو واحد =، وزيادة بمقدار 1.
الصيغة الدقيقة مع الحشو - ceil(n/3) × 4 حرفًا، وتأثير مدخلات 1، 2 و 3 bytes
بالنسبة للمدخلات الكبيرة، يكون الهامش ضئيلًا: 300 يحتاج الإدخال بالبايت إلى 400 حرفًا بالإضافة إلى حرفين متروكين على الأكثر، بفارق أقل من 0.5%. بالنسبة للمدخلات الصغيرة (1–3 bytes)، تهيمن المساحة المتروكة: بايت واحد ينتج YQ== (أربعة أحرف)، وتوسيع 4x. لكن متوسط الملفات تهيمن عليه الملفات الكبيرة. الصيغة الدقيقة هي ceil(n / 3) × 4 حرفًا، حيث n هو عدد بايت الإدخال.
بالنسبة لـ n = 1، السقف(1/3) × 4 = 1 × 4 = 4. بالنسبة لـ n = 2، ceil(2/3) × 4 = 1 × 4 = 4. بالنسبة لـ n = 3، ceil(3/3) × 4 = 1 × 4 = 4. بالنسبة إلى n = 4، ceil(4/3) × 4 = 2 × 4 = 8. بالنسبة لـ n = 30000، ceil(30000/3) × 4 = 10000 × 4 = 40000. تشرح حالات الإدخال الصغيرة لماذا لا يكون "حوالي الثلث" دقيقًا لكل قيمة. لا يزال البايت الواحد يشغل كتلة مكونة من أربعة أحرف، كما هو الحال مع اثنين البايتات تقترب النسبة من أربعة أثلاث فقط حيث تهيمن العديد من المجموعات الكاملة المكونة من ثلاثة بايت على الكتلة المبطنة النهائية.
مثال عملي: قياس سلسلة 20 مكونة من أحرف UTF-8 - حساب البايتات بدلاً من الأحرف، ثم طول Base64
حسابات وظيفة السقف للمجموعة النهائية غير مكتملة من مضاعفات الثلاثة. مع نمو n بشكل كبير، يقترب السقف (n/3) من n/3, لذا يقترب الإخراج (n/3) × 4 = 4n/3, نسبة 4/3.
قياس السلسلة المحددة: 20 أحرف مختلطة ASCII واللهجات والرموز التعبيرية. عدد الأحرف هو 15 في JavaScript (يحتوي الرمز التعبيري على حرف واحد). يختلف عدد البايتات UTF-8: ASCII الحروف 1 byte لكل منها، الحرف المشكل 2 bytes (0xC3 0xA9 لـ é)، الرموز التعبيرية 4 bytes (0xF0 0x9F 0x98 0x80). تقوم الأداة بتسجيل UTF-16 من الأحرف ونقاط رمز Unicode وUTF-8 بايت بشكل منفصل. يمنع هذا التمييز تسعير الجملة المكونة من عشرين حرفًا والتي تحتوي على رموز متعددة البايت بعشرين بايت. يتبع الطول المشفر عدد البايتات، وليس ما يحسبه الإنسان على الشاشة.
فواصل الأسطر والتفاف MIME - كيف يضيف تنسيق العمود 76 نسبة قليلة أخرى
مجموع حولها 18 bytes. يشفر Base64 ما يلي: ceil(18/3) × 4 = 6 × 4 = 24 الشخصيات. منذ 18 مضاعفات الثلاثة، لا حاجة للحشو. الإخراج Base64 هو 24 الشخصيات. ويضيف الترميز 24 - 18 = 6 bytes، أو 33%، مؤكدا 4/3 صيغة. MIME يقدم التفاف Base64 حملًا إضافيًا. كلاسيكي MIME يلتف عند 76 أحرف في كل سطر ويضيف سطرًا جديدًا.
يصبح إخراج Base64 المكون من 400 حرفًا 405 bytes تقريبًا مع إدراج أسطر جديدة. لكل 76 حرف من إخراج Base64، يتم إدراج بايت سطر جديد واحد. بالنسبة للملفات الكبيرة، تتم إضافة أقل من 2%. بالنسبة لمرفقات البريد الإلكتروني، تعد اتفاقية السطر الجديد قياسية ومتوقعة من قبل المحللين؛ تقبل الأداة Base64 الملتفة وتقوم بفك التشفير بشكل صحيح. تفاعلات الضغط تعقد تحليل الحجم. يتم ضغط البيانات الثنائية الأولية (الصورة والفيديو) بشكل مختلف عن نص Base64. يقوم ToolAcre بإدراج سطر جديد بعد كل شريحة أحرف مكونة من 76 ويستبعد تلك الأسطر الجديدة من قياس الأحرف المشفرة المعروض. يجب أن تقوم ميزانية التنسيق السلكي بإضافة الفواصل مرة أخرى؛ تصف مقارنة القياس المرئي وحده رموز Base64، وليس كل بايت نهاية السطر المرسل.
تفاعلات الضغط - لماذا يميل نص Base64 إلى الضغط بشكل أسوأ من وحدات البايت الأولية التي يمثلها
قد يتم ضغط سلسلة Base64 إلى 60% حجمها باستخدام gzip، وقد يتم ضغط الصورة إلى 25%. نظرًا لأن gzip يبحث عن أنماط البايت المتكررة، فإن تمثيل النص (الأحرف A–Z بالإضافة إلى + / أو - _) يكون به تكرار أقل مما تمثله البيانات الثنائية. غالبًا ما يكون تضمين الصورة بالضغط أكثر تكلفة في التعليمات البرمجية من التضمين بشكل منفصل. بالنسبة للخطوط، المعقدة بشكل خاص والتي تحتوي على العديد من الحروف الرسومية، يمكن أن يكون تضمين Base64 غير فعال.
يعتمد تحليل المقايضة على سياق محدد. قد يكون تضمين البيانات الصغيرة URI (10–50 bytes) أمرًا يستحق النفقات العامة لتجنب طلب HTTP. قد لا يتم تضمين الأصول الكبيرة (100 KB). يعتمد الضغط على الأنماط الموجودة في كل من المصدر وتمثيل Base64 الخاص به، لذا فإن النسبة المئوية العامة للحمل المضغوط ستكون غير صحيحة. قم بقياس الأصل الفعلي قبل وبعد ضغط الاستجابة المحيط. التكلفة المحددة هي عدد الأحرف غير المضغوطة الذي توفره صيغة الكتلة.
ما لا يغطيه هذا — قياس أداء العرض أو فك التشفير، والتحسينات الخاصة بالتنسيق مثل WebP
إذا كان الأصل الموجود في CDN قريبًا من المستخدم، فإن تجنب الطلب ليس مفيدًا. إذا كان الأصل الموجود على نفس الخادم والتحميل يتطلب رحلة إضافية ذهابًا وإيابًا، فقد يكون التضمين مبررًا. يعد القياس أمرًا ضروريًا: استخدم الصيغة لحساب الحجم المضمّن، وأضف عدد الأحرف إلى الملف CSS أو HTML، وقم بقياس إجمالي حجم الحزمة ووقت التحميل.
33% من النفقات العامة مؤكدة؛ فائدة الأداء ليست كذلك. URL-safe Base64 (base64url) له نفس نسبة 4/3، فقط أحرف مختلفة. تؤدي إزالة الحشوة إلى حفظ حرفين في أسوأ الحالات. بالنسبة للملفات الكبيرة، لا تذكر. بالنسبة للرموز المميزة JWT (ثلاثة أجزاء من base64url مرتبطة بنقاط)، تعد إزالة الحشو أمرًا تقليديًا ولكنها توفر مساحة صغيرة جدًا؛ الحجم الحقيقي هو محتوى الرمز المميز، وليس الترميز الزائد. تتطلب سرعة العرض وفك تشفير الصور والتنسيقات البديلة مثل WebP قياسات مختلفة. لا تعني سلسلة Base64 الأقصر رسمًا أسرع، ولا تقبل أداة النص فقط هذه ملف صورة. وتتمثل مساهمتها الموثوقة في العمليات الحسابية للنص UTF-8 الذي تم إدخاله في اللوحة.
الوجبات الجاهزة: ميزانية إضافية بمقدار الثلث - كيف يمنحك برنامج التشفير ووحدة فك التشفير Base64 الطول المشفر الحقيقي لأي نص حتى تتمكن من القياس بدلاً من التخمين
يقوم الضغط أيضًا بتشفير النص بالمثل؛ ما إذا كان الحرفان الأخيران == أو أن السلسلة أقصر لا يحدث أي فرق تقريبًا في إخراج gzip. يُبلغ برنامج التشفير ووحدة فك التشفير Base64 عن عدد بايتات الإدخال وعدد أحرف الإخراج على الفور. بالنسبة لأي ترميز نص، يمكنك رؤية زيادة الحجم بالضبط. بالنسبة للسلاسل UTF-8 ذات الأحرف متعددة البايت، تعرض الأداة أن عدد الأحرف (ما تراه) يختلف عن عدد البايتات (ما يشفره Base64).
قد تكون سلسلة الأحرف 10 15 bytes إذا كانت تحتوي على علامات تشكيل ورموز تعبيرية، مما يؤدي إلى إنتاج 20 أحرف من إخراج Base64 بدلاً من نسبة 4/3 بناءً على عدد الأحرف. يوضح فهم التمييز السبب الذي يجعل تضمين رمز مليء بالرموز التعبيرية أكثر تكلفة من ASCII الفن: ليست الرموز التعبيرية تكلف أكثر، UTF-8 بايت التي تمثلها. للحصول على قيمة سطرية مرشحة، سجل عدد البايتات UTF-8 للأداة وعدد الأحرف المشفرة جنبًا إلى جنب. ثم قم بتضمين البادئة URI، وبناء الجملة CSS وأي تغليف تطلبه الوجهة. يعد هذا القياس الكامل أكثر فائدة من تكرار النسبة المئوية المقربة دون تكاليف التأطير.