مولّد سجل التغييرات — أداة إنشاء CHANGELOG.md وفق معايير Keep a Changelog و SemVer

## 1. نظرة عامة شاملة وأهمية توثيق التغييرات البرمجية وفق المعايير العالمية في هندسة البرمجيات المعاصرة، لا تقل أهمية التواصل الواضح بين فرق التطوير والمستخدمين والمستثمرين شأناً عن جودة الكود البرمجي ذاته. يُمثل سجل التغييرات (Changelog) المصدر المرجعي الموحد والحاسم لتتبع التطور التاريخي للتطبيقات ومكتبات الأكواد والواجهات البرمجية (APIs). وفي غياب سجل منظم، تتحول التغييرات الجذرية إلى أعطال غير متوقعة في الأنظمة، وتصبح ترقيات الحزم البرمجية مغامرة معقدة، ويعجز المستخدمون عن معرفة الأخطاء التي تم إصلاحها أو الثغرات الأمنية التي جرى سدها. يُعد **مولّد سجل التغييرات** استوديو توثيقي متطور يعمل بالكامل داخل المتصفح، صُمم خصيصاً لتمكين المطورين ومديري المنتجات والفرق التقنية من إنشاء ملفات `CHANGELOG.md` احترافية ومتوافقة بدقة مع معيار **Keep a Changelog (1.1.0)** العالمي ومبادئ **الترقيم الدلالي للإصدارات (SemVer 2.0.0)**. تستبدل هذه الأداة رسائل Git العشوائية بسجل تاريخي أنيق ومصنف بعناية وموثق بالتواريخ الدقيقة. تعمل الأداة محلياً بنسبة 100% داخل جلسة متصفحك دون الحاجة إلى أي خوادم وسيطة، مما يتيح لك بناء إصداراتك وتنظيم تعديلاتك عبر 6 فئات معيارية وتصدير كود Markdown في أجزاء من الثانية. وبفضل هذا التصميم الآمن، تبقى خططك المستقبلية وميزاتك غير المعلنة وتفاصيل الترقيعات الأمنية الحساسة محمية تماماً داخل جهازك دون أي مخاطر لتسريب البيانات. --- ## 2. حالات الاستخدام العملية وإدارة إطلاقات البرمجيات يُعد الاحتفاظ بسجل تغييرات احترافي ركيزة أساسية في كافة بيئات ومراحل دورة حياة البرمجيات: - **المكتبات وحزم الأكواد العامة للمطورين:** يحتاج مطورو الحزم والمكتبات المفتوحة إلى تقديم مسارات ترقية واضحة لزملائهم المطورين. يوضح سجل التغييرات القياسي بدقة متى كُسرت التوافقية (إصدار رئيسي)، ومتى أضيفت ميزات جديدة دون كسر (إصدار فرعي)، ومتى تم إصلاح أخطاء برمجية (إصدار ترقيعي). - **منصات البرمجيات كخدمة (SaaS) وفرق النشر المستمر:** تحتاج الشركات الناشئة وفرق المنتجات الرقمية التي تطلق تحديثات أسبوعية إلى توثيق منسق. يسهم سجل التغييرات المنظم في توحيد لغة التواصل بين مهندسي الواجهات الخلفية وفرق الدعم الفني والعملاء النهائيين. - **واجهات برمجة التطبيقات (REST & GraphQL APIs):** عند إدارة الخدمات السحابية والأنظمة الموزعة (Microservices)، يجب إخطار المطورين بأي معاملات برمجية أصبحت مهملة أو تعديلات في هياكل الاستجابة تفادياً لتعطل التطبيقات المرتبطة بها. - **الحوكمة والامتثال والتدقيق الأمني:** تفرض القطاعات الحساسة—مثل التقنية المالية، الرعاية الصحية، والأنظمة الدفاعية—توثيقاً صارماً لكل تحديث برمجي يطرح في الإنتاج. يوفر سجل التغييرات سجلاً تدقيقياً معتمداً يثبت معالجة الثغرات الأمنية (CVEs) وتواريخ نشرها الدقيقة. - **تحديثات تطبيقات الهواتف الذكية (App Store و Google Play):** يمكن لفرق تطوير تطبيقات iOS وأندرويد صياغة ملخصات احترافية خالية من العبارات المبتذلة لعرضها على صفحات المتاجر لتعزيز ثقة المستخدمين وفرق مراجعة التطبيقات. - **التنسيق الداخلي بين فرق الشركات الكبرى:** في المنظمات التقنية الضخمة ذات المستودعات البرمجية المتعددة، يمنع السجل الموحد تضارب المعرفة ويسمح للمهندسين بفهم تأثير التحديثات عبر الأنظمة المختلفة بسرعة فائقة. --- ## 3. خطوات الاستخدام العملية ودليل عناصر التحكم التفاعلية توفر واجهة الأداة بيئة عمل مزدوجة فائقة السلاسة تضمن سرعة الإدخال والمعاينة اللحظية: 1. **إدخال اسم المشروع:** ابدأ بكتابة اسم تطبيقك أو مكتبتك في حقل **اسم المشروع**. تقوم الأداة فورياً بتضمين هذا الاسم في ترويسة ملف Markdown والمقدمة القياسية المعيارية. 2. **إدارة معالم الإصدارات:** تبدأ الأداة بإصدار أولي افتراضي. يمكنك تعديل رقم الإصدار (مثل `1.0.0` أو `غير منشور`) واختيار تاريخ الإطلاق عبر منتقي التواريخ المدمج. لإضافة إصدارات سابقة أو قادمة، انقر على زر **+ إصدار**؛ حيث تقوم الأداة آلياً باقتراح الإصدار الترقيعي التالي. 3. **اختيار فئات التغيير المعيارية:** انقر على **+ إضافة** داخل أي إصدار لإدراج بند تعديل جديد، ثم استخدم القائمة المنسدلة الملونة لتصنيف التغيير وفق الفئات الست المعتمدة عالمياً: - ✨ **مُضاف (Added):** ميزات جديدة كلياً، أو واجهات مستخدم، أو نقاط اتصال API حديثة. - 🔄 **مُعدَّل (Changed):** تعديلات في سلوك ميزات قائمة، أو تحسينات في الأداء، أو تحديث الإعدادات الافتراضية. - ⚠️ **مهمَل (Deprecated):** ميزات قديمة يُنصح بعدم استخدامها تمهيداً لإزالتها في الإصدارات الرئيسية المقبلة. - 🗑️ **محذوف (Removed):** خصائص أو دوال برمجية تم حذفها نهائياً من المشروع في هذا الإصدار. - 🐛 **مُصلَح (Fixed):** إصلاح أخطاء برمجية، ومعالجة الحالات الحدية، وإزالة الأعطال غير المتوقعة. - 🔒 **أمان (Security):** ترقيع ثغرات أمنية، وتحديث مكتبات لسد نقاط ضعف، وتحصين أمان البيانات. 4. **صياغة أوصاف التغييرات:** اكتب وصفاً موجزاً ومباشراً لكل بند يركز على القيمة العملية وليس على أرقام سجلات الالتزام (Commit Hashes). يمكنك حذف أي بند بنقر زر **✕**. 5. **المعاينة الفورية لكود Markdown:** أثناء الكتابة، يعيد المحرك فورياً فرز البنود وتجميعها تحت ترويسات الفئات القياسية (`### Added`، `### Fixed`...) وعرض النتيجة في نافذة الكود الطرفية. 6. **التصدير والتحميل بنقرة واحدة:** اضغط على **نسخ Markdown** لنقل الكود بالكامل إلى حافظة جهازك مع إشعار تأكيد مرئي، أو انقر على **تحميل** لتنزيل ملف `CHANGELOG.md` حقيقي ومباشر إلى جهازك. كما يمكنك النقر على **إعادة** لبدء قالب جديد في أي وقت. --- ## 4. جدول المقارنة الشامل: مولّد السجل في المتصفح مقابل بيئات العمل البديلة | المعيار البرمجي والتقني | مولّد السجل في المتصفح | استخراج سجلات Git (`git log`) | التحرير اليدوي في برامج الأكواد | منصات إدارة الإطلاقات السحابية | | :--- | :--- | :--- | :--- | :--- | | **سهولة الإعداد والتشغيل** | **فوري وبدون أي تثبيت أو تسجيل** | يتطلب مستودع محلي وأوامر طرفية معقدة | يتطلب فتح المحرر وكتابة الهيكل يدوياً | يتطلب إنشاء حسابات وربط مفاتيح API | | **سهولة القراءة للبشر** | **فئات معيارية مصنفة وواضحة جداً** | نصوص مشوشة مليئة برسائل الالتزام الداخلية | تعتمد كلياً على دقة وانضباط المطور الفردي | واضحة ولكنها غالباً ما تكون محشوة ببيانات تسويقية | | **الامتثال لمعيار Keep a Changelog** | **تطابق قياسي بنسبة 100% مع 1.1.0** | عشوائي ولا يتبع معايير التنسيق | معرض للأخطاء اللغوية والنحوية في Markdown | تعتمد على تنسيقات HTML/JSON خاصة ومغلقة | | **الترقيم الدلالي للإصدارات** | **اقتراح آلي لرفع الإصدار وفق SemVer** | يحتاج لأدوات خارجية ملحقة ومفسرات | حساب يدوي بحت معرض للخطأ في التقدير | غالباً ما يكون مفصولاً عن الترقيم الدلالي | | **أمان وخصوصية البيانات** | **معالجة حصرية 100% في ذاكرة المتصفح** | على الجهاز المحلي فقط | على الجهاز المحلي فقط | تُخزن التغييرات على خوادم سحابية خارجية | | **الفرز والترتيب الآلي** | **فرز فوري وتجميع ذكي حسب نوع التعديل** | يحتاج لكتابة سكريبتات تعابير نمطية Regex | فرز يدوي مضنٍ ومعرض للإغفال | مؤتمت ولكنه محصور داخل النظام الخاص | | **التكلفة والاعتماديات** | **مجاني تماماً وبدون أي اشتراكات** | مجاني مدمج مع Git | مجاني مدمج مع المحرر | اشتراكات شهرية باهظة للفرق والمؤسسات | --- ## 5. المواصفات الفنية وهندسة معايير Keep a Changelog 1.1.0 تلتزم خوارزمية التوليد بالقواعد الصارمة المحددة في المواصفات القياسية الدولية لإصدارات البرمجيات: | المعيار التقني | قاعدة التنفيذ البرمجية | المتطلب الهندسي | مخرجات كود Markdown | | :--- | :--- | :--- | :--- | | **الترويسة الرئيسية** | عنوان أحادي من المستوى الأول | اسم المشروع متبوعاً بالمقدمة القياسية المعيارية | `# Changelog All notable changes...` | | **روابط التوثيق المرجعي**| إسناد رسمي للمواصفات | روابط صريحة إلى وثائق المعايير القياسية | `[Keep a Changelog](...)` و `[Semantic Versioning](...)` | | **ترويسة الإصدار والتاريخ**| عنوان من المستوى الثاني | أقواس حول الإصدار متبوعة بتاريخ قياسي ISO 8601 | `## [1.2.0] - 2026-09-19` | | **قسم المسودات غير المنشورة**| تتبع العمل الجاري | إمكانية إدراج قسم للأعمال قيد التطوير قبل النشر | `## [Unreleased]` | | **فئات التغيير الست** | عناوين فرعية من المستوى الثالث | الالتزام الصارم بأسماء الفئات الست المعتمدة عالمياً | `### Added`, `### Changed`, `### Fixed`... | | **الترتيب الزمني العكسي** | الترتيب التاريخي التنازلي | ظهور أحدث الإصدارات دائماً في قمة المستند | من الأحدث إلى الأقدم هبوطاً إلى الإصدار الأول | | **تنسيق القوائم النقطية**| نقاط غير مرقمة بشرطة | استخدام علامة الشرطة لكل تغيير وظيفي مستقل | `- إضافة نظام تجديد جلسات المصادقة OAuth2` | | **أمان الذاكرة المؤقتة** | معالجة محلية في RAM | انعدام التخزين الدائم على الأقراص أو الخوادم | تنظيف آلي للذاكرة بمجرد مغادرة الصفحة | --- ## 6. التحليل المعماري المعمق ونظرية الترقيم الدلالي وإدارة الإطلاقات لفهم الفائدة الهندسية لسجل التغييرات الاحترافي، يجب إدراك الفوارق الجوهرية بين التوثيق الداخلي وتوثيق المستخدم: ### الفارق بين سجلات Git وسجل التغييرات من الأخطاء الشائعة في بعض الفرق البرمجية الاعتماد على تصدير سجلات Git كبديل لسجل التغييرات. صُممت سجلات Git للمطورين أثناء كتابة الكود—فهي تسجل كل تعديل طفيف في سطر برمجي، وتجارب التنسيق، وتفاصيل دمج الفروع (Merge Commits). أما سجل التغييرات فقد صُمم من أجل **المستهلكين والمستخدمين**؛ فالمستخدم لا يهمه معرفة أن المطور أصلح خطأ إملائياً في متغير داخلي 10 مرات، بل يريد أن يعرف أن هناك مشكلة كانت تتسبب في تعطل تسجيل الدخول وتم حلها بنجاح. ### ميكانيكية الترقيم الدلالي (SemVer 2.0.0) يقوم الترقيم الدلالي على معادلة رياضية ثلاثية واضحة `MAJOR.MINOR.PATCH`: 1. **الإصدار الرئيسي (MAJOR):** يتم رفعه عند إدخال تعديلات جذرية تكسر التوافقية السابقة (Breaking Changes). ويتعين على المطورين حينها مراجعة شفراتهم وتعديلها لتتوافق مع الإصدار الجديد. 2. **الإصدار الفرعي (MINOR):** يتم رفعه عند إضافة ميزات ووظائف جديدة مع الحفاظ التام على التوافقية مع ما قبلها دون كسر أي شفرات قائمة. 3. **الإصدار الترقيعي (PATCH):** يتم رفعه عند إصلاح أخطاء برمجية أو تحسين الأداء أو سد ثغرات أمنية دون المساس بالواجهات البرمجية المعرفة. ### الفئات الست المعتمدة في معيار Keep a Changelog لتفادي الالتباس، حدد معيار Keep a Changelog ست فئات محددة بدقة. هذا التصنيف يمنع دفن الإشعارات الأمنية الخطيرة تحت ركام التعديلات الجمالية البسيطة. ويضمن محرك أداتنا إبراز الميزات الجديدة أولاً مع منح التحذيرات الأمنية وإشعارات الإهمال الأولوية التي تستحقها. ### ترجمة سجلات الالتزام (Conventional Commits) إلى بنود في سجل التغييرات تتبنى العديد من الفرق البرمجية الحديثة معايير الالتزام الاصطلاحي (مثل `feat:` للميزات و `fix:` للإصلاحات و `refactor:` لإعادة الهيكلة و `chore:` للأعمال الدورية). ورغم فائدة هذه المعايير، إلا أن استخراجها المباشر يتطلب تدقيقاً وصياغة بشرية واعية: - التعديلات الموسومة بـ `feat:` تُصنف مباشرة تحت قسم **مُضاف (Added)**، شريطة أن تقدم قيمة وظيفية ملموسة للمستخدمين. - الإصلاحات الموسومة بـ `fix:` تنتمي لقسم **مُصلَح (Fixed)**، ويجب صياغتها لتوضيح العطل الذي تم التخلص منه بأسلوب مفهوم. - تحسينات الأداء والتعديلات الجوهرية غير الكاسرة للتوافقية تندرج تحت قسم **مُعدَّل (Changed)**. - التغييرات التي تكسر التوافقية السابقة وتتطلب رفع الإصدار **الرئيسي (MAJOR)** تُبرز بوضوح تحت قسم **مُعدَّل** أو **محذوف (Removed)** لتنبيه المطورين إلى التعديلات الإلزامية في شفراتهم. - التعديلات الداخلية الدورية الخاصة باختبارات CI أو أدوات البناء الداخلية (`chore:` أو `test:`) يُفضل استبعادها من سجل المستخدم النهائي، ما لم تكن تفرض متطلبات تشغيل جديدة مثل رفع الحد الأدنى لإصدار بيئة التشغيل. --- ## 7. الأمان المؤسسي وضمان الخصوصية المطلقة (Zero-Knowledge) غالباً ما تشتمل سجلات التغييرات ومسودات الإطلاقات على أسرار تجارية ومعلومات حساسة تخص منتجات لم تعلن بعد أو ثغرات أمنية جرى ترقيعها داخلياً: - **تنفيذ محلي 100% داخل المتصفح:** تجري كافة عمليات معالجة النصوص، وتجميع الفئات، وتوليد كود Markdown محلياً داخل محرك جافاسكريبت المدمج في متصفحك. - **انعدام الاتصال الخارجي بالخوادم:** لا يتم إرسال أي اسم مشروع أو رقم إصدار أو تفاصيل ميزة جديدة عبر الإنترنت إلى أي خادم خارجي. يمكنك فصل جهازك عن شبكة الإنترنت بالكامل واستخدام الأداة دون أي انقطاع. - **انعدام برمجيات التتبع والتجسس:** لا تحتوي الأداة على أي برمجيات لتسجيل ضغطات المفاتيح، أو تتبع الجلسات، أو حفظ المدخلات في قواعد بيانات خارجية. وبمجرد مسح المحرر أو إغلاق الصفحة، تُمحى البيانات فورياً من الذاكرة اللحظية. - **الامتثال التام للوائح البيانات المؤسسية:** بفضل انعدام جمع البيانات أو حفظها، يمكن للمؤسسات والشركات الكبرى توثيق مشاريعها الحساسة وأنظمتها السحابية دون أدنى قلق وبما يتوافق مع تشريعات **GDPR** و **CCPA** وسياسات أمن المعلومات المؤسسية الصارمة. --- ## 8. أفضل الممارسات لتحقيق أقصى فائدة والتكامل مع المنظومة البرمجية لضمان أعلى درجات الاحترافية في توثيق مشاريعك البرمجية، نوصي باتباع الإرشادات التالية: 1. **الكتابة بلغة البشر وليس لغة الآلات:** تجنب العبارات التقنية المبهمة مثل *"تم إصلاح مؤشر null في السطر 50"*. واستبدلها بعبارات وظيفية مباشرة مثل: *"تم حل مشكلة انتهاء الجلسة التي كانت تمنع المستخدمين من تسجيل الدخول في أوقات الذروة"*. 2. **التحذير المبكر من الميزات المهملة (Deprecations):** لا تحذف أي ميزة فجأة دون إشعار مسبق. استخدم فئة `Deprecated` لإخطار المطورين بنيتك حذف الخاصية في الإصدار الرئيسي المقبل، مما يمنحهم وقتاً كافياً لتحديث تطبيقاتهم. 3. **الاحتفاظ بقسم للمسودات غير المنشورة (Unreleased):** أنشئ قسماً بعنوان `[Unreleased]` لتجميع الميزات والإصلاحات التي يتم دمجها خلال دورة التطوير. وعند اقتراب موعد الإطلاق، حوّل هذا العنوان إلى رقم إصدار وتاريخ رسمي بنقرة واحدة. 4. **التكامل مع أدوات المطورين الأخرى في المنصة:** عزز منظومة عملك البرمجية قبل إطلاق تحديثك؛ قم بمحاكاة واجهاتك البرمجية واختبار استجابتها عبر مُحاكي واجهات API، وقم بترميز وتشفير الأصول والبيانات عبر مُرمّز Base64، وحسّن ملفات التنسيق الإنتاجية عبر مُصغّر كود CSS، واضبط قواعد التوجيه وإعدادات السيرفر عبر مُوّلد ملف .htaccess. 5. **اعتماد صيغة التاريخ القياسية ISO 8601:** استخدم دائماً صيغة `YYYY-MM-DD` لكتابة التواريخ (مثل `2026-09-19`) لتفادي الالتباس الشائع بين التنسيق الأمريكي والبريطاني للتواريخ. --- ## 9. استكشاف الأخطاء الشائعة في كتابة سجلات التغيير وحلولها قد تقع بعض الفرق في أخطاء شائعة تؤثر على مصداقية واحترافية التوثيق البرمجي: - **الأوصاف المبهمة وغير المفيدة:** كتابة عبارات عامة مثل *"إصلاحات عامة وتحسينات في الأداء"* تثير استياء المستخدمين وتقلل من شفافية المشروع. إذا كان التعديل مهماً، فاشرح باختصار ما تم حله. - **رفع الإصدار الرئيسي دون مبرر:** يؤدي رفع الإصدار الرئيسي (MAJOR) لتعديلات شكلية بسيطة إلى تردد المطورين في الترقية خشية كسر مشاريعهم. احصر الترقية الرئيسية في التغييرات التي تكسر التوافقية حصراً. - **تجاهل التنبيهات الأمنية:** عند ترقيع ثغرة أمنية، لا تدمجها تحت فئة الإصلاحات العادية، بل استخدم فئة `Security` المخصصة وأشر إلى رقم التقرير الأمني أو معرّف CVE لمساعدة مديري الأنظمة في تقييم مستوى الخطورة. - **تنسيق Markdown غير المتناسق:** خلط مستويات العناوين في Markdown يربك الأدوات المؤتمتة ومحركات التوثيق. تضمن أداتنا توليد بنية نحوية سليمة وصارمة تتوافق مع محركات العرض العالمية. - **إغفال تواريخ الإصدارات:** نشر أرقام الإصدارات دون تاريخ إطلاق يترك انطباعاً بأن المشروع مهجور؛ احرص دائماً على ربط كل إصدار بتاريخه الميلادي الدقيق. --- ## 10. الأسئلة الشائعة (FAQ) ### ما هو معيار Keep a Changelog وما هي أهدافه؟ هو معيار توثيقي عالمي مفتوح ابتكره أوليفييه لاكان، يهدف إلى توحيد طريقة كتابة سجلات التغييرات في ملفات Markdown لتكون سهلة القراءة وموجهة للبشر وليست مجرد تفريغ آلي لسجلات الحفظ البرمجية. يحدد المعيار ست فئات رئيسية لتصنيف كافة أنواع التعديلات. ### لماذا يُفضل استخدام هذه الأداة بدلاً من الاعتماد على git log؟ تتضمن سجلات Git تفاصيل تقنية داخلية كثيرة تخص المطورين فقط (مثل تعديل أخطاء مطبعية أو دمج فروع فرعية). تقوم الأداة بفرز وتلخيص هذه التعديلات وتحويلها إلى نقاط قيمة تركز على الفائدة العملية للمستخدم والعميل النهائي. ### كيف يرتبط الترقيم الدلالي (SemVer) بسجل التغييرات؟ يحدد الترقيم الدلالي قواعد تغيير أرقام الإصدارات (رئيسي عند كسر التوافقية، فرعي عند إضافة ميزات جديدة، ترقيعي عند إصلاح الأعطال). ويوفر سجل التغييرات التوثيق التفصيلي والمبرر البرمجي لكل زيادة في رقم الإصدار. ### هل يمكنني تتبع التغييرات قيد التطوير قبل نشر الإصدار رسمياً؟ نعم بالتأكيد. تتيح لك الأداة إنشاء قسم بعنوان `[غير منشور]` أو `[Unreleased]` لتسجيل الميزات والإصلاحات أولاً بأول أثناء مرحلة التطوير، ثم تحويلها إلى إصدار رسمي برقم وتاريخ محدد عند الإطلاق. ### هل بيانات ومشاريع شركتي آمنة وسرية عند استخدام هذه الأداة؟ نعم، آمنة بنسبة 100%. الأداة تعمل بالكامل داخل ذاكرة متصفحك الشخصي دون أي اتصال بخوادم خارجية. لا يتم رفع أي أسماء مشاريع أو أرقام إصدارات أو تفاصيل ميزات إلى أي مكان عبر الإنترنت. ### هل أستطيع تنزيل سجل التغييرات كملف جاهز مباشرة؟ نعم، بالنقر على زر **تحميل**، تنشئ الأداة ملفاً نصياً بصيغة Markdown باسم `CHANGELOG.md` وتنزله فورياً إلى مجلد التنزيلات بجهازك ليكون جاهزاً لإضافته لمستودعك على GitHub أو GitLab. ### ما الفائدة العملية لفئة "مهمَل" (Deprecated)؟ تُستخدم هذه الفئة لإشعار المطورين والمستخدمين بأن ميزة أو دالة معينة سيتم حذفها نهائياً في الإصدار الرئيسي القادم، مما يمنحهم فرصة كافية لتعديل تطبيقاتهم وتفادي توقف أنظمتهم عند الترقية المستقبلية. --- ## 11. أدوات المطورين المتكاملة وروابط المنظومة الداخلية ارتقِ بمستوى بيئة التطوير الخاصة بك واكتشف أدواتنا المتميزة الأخرى المصممة لتسريع مهامك البرمجية: - مُحاكي واجهات API: أنشئ واختبر استجابات وهياكل واجهات REST البرمجية التفاعلية فورياً في متصفحك. - مُرمّز Base64: قم بتشفير وفك تشفير النصوص والملفات والبيانات الثنائية بأمان وسرعة فائقة. - مُصغّر كود CSS: اضغط ونسق صفحات الأنماط البرمجية لتحسين سرعة التحميل ومؤشرات Core Web Vitals. - مُوّلد ملف .htaccess: أنشئ إعدادات وتوجيهات خوادم Apache وقواعد الحماية وإعادة التوجيه بسهولة تامة.