JSON Formatter
Pretty-print, validate and minify JSON with precise error positions.
المطورون
إزالة التعليقات والمسافات من CSS وJS وHTML.
تزيل المسافات والتعليقات. ولا تعيد تسمية المتغيّرات ولا تحذف الشيفرة غير المستخدمة ولا تعيد صياغة التعبيرات.
وهذا قرار يتعلّق بالسلامة. فإعادة التسمية والصياغة هما الخطوتان اللتان قد يكسر فيهما المصغّر الشيفرة، خصوصًا مع الوصول الديناميكي عبر السلاسل النصية حيث لا تظهر العلاقة. ومن أراد ذلك فليستخدم أداة بناء تعرف الرسم البياني للوحدات كاملًا.
ولملف أنماط واحد أو نص برمجي أو قالب بريد، يكون السلوك المحافظ هو المناسب: تصغير ملموس بلا مخاطرة.
أقل مما توحي به الأرقام الخام، لأن الويب يُرسل مضغوطًا أصلًا.
| النوع | التوفير الخام | التوفير بعد gzip |
|---|---|---|
| CSS بتعليقات كثيرة | 25–40% | 5–12% |
| JavaScript منسّق | 20–35% | 3–8% |
| HTML بمسافات بادئة | 10–20% | 2–5% |
والسبب أن gzip وBrotli يضغطان التكرار بكفاءة عالية، والمسافات البادئة أكثر ما يتكرّر في الملف. فالفرق بعد الضغط صغير.
والأهم هو الضغط نفسه: ملف أنماط يُرسَل دون ضغط مشكلة أكبر بكثير من ملف غير مصغّر.
مع هذا السلوك المحافظ نادرًا، وثمة حالات.
في HTML تكون المسافة بين العناصر السطرية ذات معنى: بين وسمين متجاورين تختفي المسافة بين الكلمتين. وداخل <pre> و<textarea> كل مسافة مرئية. وكلاهما يبقى دون مساس هنا.
وفي JavaScript الخطر في الإدراج التلقائي للفاصلة المنقوطة: من يحذفها قد يحصل على تعبير مختلف بعد إزالة فاصل السطر. وهذه الأداة لا تزيل فواصل الأسطر التي تغيّر المعنى.
وفي CSS يُتعارف على إبقاء التعليق الذي يبدأ بعلامة تعجّب — /*! ... */ — لأنه يحمل بيانات الترخيص عادةً. ويبقى كما هو.
خامًا من 20 إلى 40%، وبعد gzip من 3 إلى 12% فقط — لأن الضغط يعالج المسافات أصلًا.
لا، عمدًا. هذه الخطوة التي تكسر الشيفرة عادةً، وتحتاج أداة بناء تعرف المشروع كاملًا.
عمليًا لا. المسافات ذات المعنى في HTML وJavaScript تبقى دون مساس.
نعم. التعليقات بصيغة /*! ... */ لا تُزال.
للملفات المفردة نعم. وفي مشروع فيه أداة بناء تتولّى خطوة البناء ذلك بشكل أفضل.
لا. كل شيء يبقى في هذه الصفحة.