تاريخ النشر: 29 أكتوبر 2025
يخطّط Chrome لإيقاف ميزة XSLT نهائيًا وإزالتها من المتصفّح. يوضّح هذا المستند كيفية نقل الرمز البرمجي قبل إزالته في أواخر عام 2026.
أوقف Chromium نهائيًا ميزة XSLT، بما في ذلك واجهة برمجة التطبيقات XSLTProcessor JavaScript وتعليمات معالجة XSLT. ننوي إيقاف الدعم عن الإصدار 158 (17 نوفمبر 2026). أشارت مشاريع Firefox و WebKit أيضًا إلى خطط لإزالة XSLT من محركات المتصفّحات الخاصة بها. يقدّم هذا المستند بعض المعلومات الأساسية والسياقية، ويوضّح كيفية إزالة XSLT لجعل Chrome أكثر أمانًا، كما يقدّم طريقة لنقل البيانات قبل إزالة هذه الميزات من المتصفّح. للاطّلاع على آخر التحديثات، يُرجى أيضًا الاطّلاع على إدخال حالة النظام الأساسي Chrome.
ما الذي ستتم إزالته؟
هناك واجهتا برمجة تطبيقات في المتصفّح تنفّذان XSLT، وسيتم إزالة كلتيهما:
- فئة
XSLTProcessor (على سبيل المثال،
new XSLTProcessor()). - تعليمات معالجة XSLT (على سبيل المثال،
<?xml-stylesheet type="text/xsl" ... ?>).
Timeline For Chrome
يتضمّن Chrome الخطة التالية:
- Chrome 142 (28 أكتوبر 2025): تمت إضافة رسائل وحدة التحكّم الخاصة بالتحذير المبكر إلى Chrome.
- Chrome 143 (2 ديسمبر 2025): الإيقاف النهائي الرسمي لواجهة برمجة التطبيقات، حيث ستبدأ رسائل التحذير بشأن الإيقاف النهائي في الظهور في وحدة التحكّم وفي Lighthouse.
- الإصدار 145 من Chrome (2 ديسمبر 2025 Canary): ستبدأ إصدارات Canary وDev وBeta في إيقاف ميزة XSLT نهائيًا تلقائيًا، وذلك كتحذير مبكر.
- الإصدار 146 من Chrome (10 مارس 2026): سيتم إطلاق سياسة المؤسسة (EP) للاختبار. يتيح ذلك للمؤسسات اختبار إيقاف XSLT مبكرًا، كما يتيح لها مواصلة استخدام الميزات بعد تاريخ الإزالة.
- الإصدار 152 من Chrome (25 أغسطس 2026): سيتم إطلاق التجربة الأصلية لاختبارها. ويسمح هذا للمواقع الإلكترونية بمواصلة استخدام الميزات بعد تاريخ الإزالة.
- Chrome 154 (22 سبتمبر 2026): ستبدأ إصدارات Canary وDev وBeta من Webview في إيقاف XSLT تلقائيًا، وذلك كتحذير مبكر.
- Chrome 158 (17 تشرين الثاني (نوفمبر) 2026): يتوقف XSLT عن العمل في الإصدارات الثابتة لجميع المستخدمين باستثناء المشاركين في "مرحلة التجربة والتقييم" و"سياسة المؤسسة".
- Chrome 176 (17 أغسطس 2027): تتوقف "مرحلة التجربة والتقييم" و"سياسة المؤسسة" عن العمل. يتم إيقاف XSLT لجميع المستخدمين.
ما هي XSLT؟
XSLT، أو تحويلات لغة أوراق الأنماط القابلة للامتداد، هي لغة تُستخدم لتحويل مستندات XML، وعادةً إلى تنسيقات أخرى مثل HTML. يستخدم هذا التنسيق ملف أوراق أنماط XSLT لتحديد قواعد التحويل، وملف XML يحتوي على البيانات المستخدَمة كمدخلات.
في المتصفّحات، عندما يتم تلقّي ملف XML يرتبط بورقة أنماط XSLT، يستخدم المتصفّح القواعد الواردة في ورقة الأنماط هذه لإعادة ترتيب بيانات XML الأولية وتنسيقها وتحويلها إلى صفحة منظَّمة (غالبًا ما تكون بتنسيق HTML) يمكن عرضها للمستخدم.
على سبيل المثال، يمكن أن تأخذ ورقة أنماط XSLT إدخال XML التالي:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
وورقة أنماط XSL هذه:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/page/message">
<body>
<p>Message: <xsl:value-of select="."/></p>
</body>
</xsl:template>
</xsl:stylesheet>
ومعالجتها في HTML هذا ليتم عرضها في المتصفّح: HTML
<body>
<p>Message: Hello World.</p>
</body>
بالإضافة إلى تعليمات معالجة XSL المعروضة في المثال السابق، تتوفّر أيضًا واجهة برمجة تطبيقات JavaScript XSLTProcessor التي يمكن استخدامها لمعالجة مستندات XML محلية باستخدام أوراق أنماط XSLT محلية.
تاريخ XSLT
أوصت رابطة الشبكة العالمية (W3C) باستخدام XSLT في 16 نوفمبر 1999 كلغة لتحويل مستندات XML إلى تنسيقات أخرى، وأكثرها شيوعًا هو HTML لعرضها في متصفحات الويب. قبل إصدار التوصية الرسمية 1.0، اتخذت Microsoft مبادرة مبكرة من خلال توفير تطبيق خاص يستند إلى مسودة عمل W3C في Internet Explorer 5.0، الذي تم إصداره في مارس 1999. وفقًا للمعيار الرسمي، أتاحت Mozilla إمكانية استخدام XSLT 1.0 الأصلية في Netscape 6 في أواخر عام 2000. تضمّنت المتصفّحات الرئيسية الأخرى، بما في ذلك Safari وOpera والإصدارات الأحدث من Chrome، معالجات XSLT 1.0 أصلية، ما جعل عمليات تحويل XML إلى HTML من جهة العميل تكنولوجيا ويب قابلة للتطبيق في أوائل الألفية الثانية.
استمر تطوّر لغة XSLT نفسها، وتم إصدار XSLT 2.0 في عام 2007 وXSLT 3.0 في عام 2017، وقد تضمّن الإصداران ميزات قوية مثل التعبيرات العادية وأنواع البيانات المحسّنة وإمكانية معالجة JSON. ومع ذلك، لم يتم إحراز أي تقدّم في ما يتعلّق بتوافق المتصفّحات. في الوقت الحالي، لا توفّر جميع محركات متصفّحات الويب الرئيسية سوى التوافق المحلي مع XSLT 1.0 الأصلية منذ عام 1999. وقد أدت قلة التطوير (إلى جانب انتشار استخدام JSON كتنسيق نقل البيانات، ومكتبات وأُطر عمل JavaScript، مثل jQuery وReact وVue.js، التي توفّر طرقًا أكثر مرونة وقوة للتعامل مع نموذج DOM وإنشاء النماذج) إلى تراجع كبير في استخدام XSLT من جهة العميل. وحلت تقنيات تستند إلى JavaScript محل دور XSLT داخل متصفح الويب إلى حد كبير.
لماذا يجب إزالة XSLT؟
إنّ استمرار تضمين الإصدار 1.0 من XSLT في متصفحات الويب يمثّل خطرًا أمنيًا كبيرًا وغير ضروري. إنّ المكتبات الأساسية التي تعالج عمليات التحويل هذه، مثل libxslt (التي تستخدمها متصفحات Chromium)، هي قواعد رموز برمجية قديمة ومعقدة مكتوبة بلغة C/C++. ويُعرف هذا النوع من الرموز البرمجية بقابليته للتأثر بثغرات سلامة الذاكرة، مثل تجاوز سعة المخزن المؤقت، والتي قد تؤدي إلى تطبيق رموز برمجية عشوائية. على سبيل المثال، رصدت عمليات تدقيق الأمان وأدوات تتبُّع الأخطاء بشكل متكرّر ثغرات أمنية خطيرة في أدوات التحليل هذه (مثل CVE-2025-7425 وCVE-2022-22834، وكلاهما في libxslt). ونظرًا إلى أنّ XSLT من جهة العميل أصبحت ميزة متخصصة ونادرة الاستخدام، تحظى المكتبات المرتبطة بها بمستوى صيانة وتدقيق أمني أقل بكثير مقارنةً بمحركات JavaScript الأساسية. ومع ذلك، فإنها تشكل مساحة هجوم مباشرة وخطيرة عند معالجة محتوى ويب غير موثوق به. في الواقع، كانت ميزة XSLT مصدرًا لعدد من الثغرات الأمنية البارزة في الآونة الأخيرة، والتي لا تزال تُعرّض مستخدمي المتصفحات للخطر. إنّ المخاطر الأمنية المرتبطة بالحفاظ على هذه الوظيفة القديمة الهشة تفوق بكثير فائدتها المحدودة في الوقت الحالي.
علاوةً على ذلك، تم استبدال الغرض الأصلي من XSLT من جهة العميل، وهو تحويل البيانات إلى HTML قابل للعرض، بواجهات برمجة تطبيقات JavaScript أكثر أمانًا وسهولة في الاستخدام وأفضل من حيث الصيانة. تعتمد عملية تطوير الويب الحديثة على عناصر مثل Fetch API لاسترداد البيانات (عادةً JSON) وDOMParser API لتحليل سلاسل XML أو HTML بأمان إلى بنية DOM ضمن بيئة الاختبار المعزولة الآمنة في JavaScript الخاصة بالمتصفح. وتتولّى أُطر العمل، مثل React وVue وSvelte، إدارة عرض هذه البيانات بكفاءة وأمان. يتم تطوير سلسلة الأدوات الحديثة هذه بشكل نشط، وهي تستفيد من الاستثمار الكبير في الأمان في محركات JavaScript، وهي ما يستخدمه جميع مطوّري الويب تقريبًا اليوم. في الواقع، لا يستخدم سوى 0.02% من عمليات تحميل صفحات الويب اليوم XSLT، ويستخدم أقل من 0.001% تعليمات معالجة XSLT.
هذا الإجراء ليس مقتصرًا على Chrome أو Chromium، بل إنّ محركَي المتصفّحات الرئيسيين الآخرَين يتيحان أيضًا إزالة XSLT من منصة الويب، وهما WebKit وGecko.
لهذه الأسباب، سيؤدي إيقاف ميزة XSLT نهائيًا وإزالتها إلى تقليل مساحة الهجوم في المتصفح لجميع المستخدمين، وتبسيط منصة الويب، والسماح بتركيز موارد الهندسة على تأمين التقنيات التي تشغّل الويب الحديث فعليًا، بدون أي فقدان عملي للقدرات بالنسبة إلى المطوّرين.
تحسين أمان تحليل XML
على غرار المشاكل الخطيرة المتعلقة بالأمان في libxslt، تم مؤخرًا الإبلاغ عن مشاكل خطيرة متعلقة بالأمان في libxml2، وهي مكتبة مستخدَمة في Chromium لتحليل XML وتسلسله واختبار صحة تنسيقه. لمعالجة مشاكل الأمان المستقبلية المتعلقة بتحليل XML في Chromium، نخطّط لإيقاف استخدام libxml2 تدريجيًا واستبدال تحليل XML بمكتبة آمنة للذاكرة لتحليل XML مكتوبة بلغة Rust. من المهم الإشارة إلى أنّنا لن نزيل XML من المتصفّح، بل سنزيل XSLT فقط. نحن نهدف إلى ضمان أن يكون استبدال libxml2 شفافًا تمامًا لمطوّري الويب.
لا تتم إزالة XML وCSS
من المهم التمييز بين إيقاف XSLT
(<?xml-stylesheet type="text/xsl" ... ?>) نهائيًا وتعليمات المعالجة
<?xml-stylesheet ... ?> نفسها، والتي ستظل متاحة
عند استخدامها مع CSS. سيظل بإمكانك استخدام تعليمات المعالجة مع
type="text/css" لتطبيق قواعد التنسيق والتصميم العادية على بياناتك الأولية،
تمامًا كما يمكنك فعل ذلك مع HTML. على سبيل المثال:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
<item>Content here</item>
</root>
كيفية نقل البيانات
تتوفّر بعض المسارات البديلة لنقل البيانات.
JSON
بالنسبة إلى المواقع الإلكترونية التي تم إنشاؤها بالكامل باستخدام XML وXSL، ليس هناك طريقة واحدة تناسب الجميع لإجراء عملية الانتقال. تشمل خيارات نقل البيانات نقل مسار معالجة XSLT إلى جهة الخادم وإرسال HTML المعروض إلى العميل، أو نقل نقاط نهاية XML API من جهة الخادم إلى JSON، وتنفيذ العرض من جهة العميل باستخدام JavaScript لتحويل JSON إلى HTML DOM وCSS.
XSLT من جهة العميل في JavaScript
تتوفّر بعض مكتبات XSLT من جهة العميل (المستندة إلى JavaScript)، ولكن المكتبة الأكبر على الإطلاق هي تلك التي تنتجها شركة Saxonica (يمكنك الاطّلاع على المستندات الشاملة الخاصة بشركة Saxonica). يتجاوز التنفيذ بكثير تنفيذ XSLT 1.0 في متصفحات الويب، ويوفّر دعمًا كاملاً لمعيار v3.0 الأحدث، وفي النهاية لمعيار v4.0 الذي لا يزال قيد التطوير.
Polyfill
يتوفّر رمز polyfill يحاول السماح للرمز الحالي، الذي يعتمد على عمليات تنفيذ XSLT 1.0 في متصفّحات الويب، بمواصلة العمل، مع عدم استخدام ميزات XSLT الأصلية من المتصفّح. يمكنك العثور على رمز polyfill على GitHub.
يحتوي Polyfill على بديل وظيفي مستند إلى WASM لصف XSLTProcessor، وبالتالي يمكن أن يستمر عمل رمز JavaScript الحالي كما هو:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
توفّر أداة التعبئة أيضًا دالة مساعدة تلقائية لتسهيل عملية استبدال مستندات XML التي تستخدم تعليمات معالجة XSLT:
بالنسبة إلى ملف demo.xml أصلي مثل هذا:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
يمكن إضافة سطر واحد لاستدعاء polyfill وتحويل المستند باستخدام ورقة أنماط XSLT المشار إليها:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
xmlns="http://www.w3.org/1999/xhtml"></script>
...content...
في هذه الحالة، يحمّل العنصر <script> الجديد رمز polyfill الذي يرصد نوع مستند XML وتعليمات معالجة XSLT ويحمّله بشكل شفاف، ما يؤدي إلى استبدال المستند.
الإضافة
يتوفّر أيضًا إضافة Chrome يمكن إضافتها إلى المتصفّحات المتوافقة، وستطبّق هذه الإضافة عملية التعبئة المتوافقة مع XSLT نفسها على جميع صفحات XML الأولية التي تحتوي على تعليمات معالجة XSLT أو طلبات إلى XSLTProcessor. يمكن استخدام ذلك للتطبيقات التي لا يمكن تغيير مصدر XML أو XSLT فيها، وذلك للحفاظ على الوظائف.
على وجه الخصوص، عندما تكون XSLT غير مفعّلة، يعرض Chrome الآن بانر تحذير يرتبط مباشرةً بصفحة بحث عن الإضافات، وذلك لمساعدة المستخدمين في العثور على إضافة:
حالات استخدام محدّدة
في المناقشة حول معايير HTML، تم تحديد عدة حالات استخدام ملموسة. يتناول هذا القسم كلّاً منها على وجه التحديد، وذلك بهدف اقتراح مسارات للمطوّرين الذين ينشرون حاليًا مراجع XML تستخدم XSLT.
خلاصات RSS وAtom
في العديد من خلاصات RSS أو Atom الحالية، يتم استخدام XSLT لجعل خلاصات XML الأولية قابلة للقراءة عند عرضها مباشرةً في المتصفّح. حالة الاستخدام الأساسية هي أنّه عندما ينقر المستخدم عن طريق الخطأ على رابط خلاصة RSS لموقع إلكتروني، بدلاً من لصق هذا الرابط في قارئ خلاصات RSS، يتلقّى استجابة بتنسيق HTML يمكنه قراءتها، بدلاً من ملف XML الأولي نفسه.
هناك طريقتان لمتابعة حالة الاستخدام هذه. الطريقة "العادية" في HTML لتنفيذ ذلك هي إضافة <link rel="alternate" type="application/rss+xml"> إلى موقع إلكتروني (مستند إلى HTML)، بدلاً من إضافة <a
href="something.xml"> صريح (مرئي للمستخدم) قد ينقر عليه المستخدمون عن طريق الخطأ. يسمح هذا الحلّ لقارئات RSS بالعثور على الخلاصة إذا لصق المستخدم عنوان URL الخاص بالموقع الإلكتروني فقط، كما يسمح للمستخدمين العاديين برؤية محتوى HTML العادي بدون أن يرتبكوا بسبب رابط يؤدي إلى مصدر XML. يتّبع ذلك أيضًا نموذج الويب العادي الذي يتيح للبشر استخدام HTML وللآلات استخدام XML. بالطبع، لا يحلّ ذلك المشكلة في حال كان المستخدم "يملك" رابط RSS من مكان ما، ولصقه في متصفّح الويب (بدلاً من قارئ RSS).
وعندما لا يكون هذا الحلّ مطلوبًا، يوفّر رمز polyfill مسارًا آخر. كما ذكرنا سابقًا، يمكن تحسين خلاصة RSS/Atom XML بإضافة سطر واحد، وهو <script
src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>، ما سيحافظ على السلوك الحالي للتحويل المستند إلى XSLT إلى HTML.
ولن يؤثر ذلك في قدرة قارئ RSS على مواصلة تحليل XML، لأنّ <script> هو عنصر فرعي مباشر للعنصر الجذر.
ناتج واجهة برمجة التطبيقات للأجهزة المضمّنة
تقيس بعض الأجهزة التجارية المضمّنة بيانات XML أو تنشئها بطريقة أخرى ليستخدمها المستخدمون على الشبكة المحلية. وتنفّذ بعض هذه الأجهزة ذلك من خلال إنشاء خلاصة بيانات XML واحدة تستخدم XSLT لتحويلها إلى تنسيق HTML يمكن قراءته. ويتيح ذلك عرض واجهة برمجة التطبيقات مباشرةً في المتصفّح بدون الحاجة إلى رمز إضافي على الجهاز أو في المتصفّح.
بما أنّ هذه الحالة من حالات الاستخدام خاصة جدًا بالتطبيق، قد يختلف شكل الحلّ. بالنسبة إلى التطبيقات التي يمكن تعديل الرمز المصدر للجهاز المضمّن فيها، يمكن استخدام أي من الخيارات الموضّحة سابقًا (JSON أو Polyfill). ومع ذلك، يصعب أو يستحيل تحديث العديد من هذه الأجهزة لأسباب مختلفة. في هذه الحالة، من المرجّح أنّ يكون
الامتداد
هو الخيار الأفضل، لأنّه يتيح لمتصفّحات العملاء مواصلة قراءة
البيانات بالطريقة نفسها تمامًا، بدون تعديل الجهاز.
النماذج الكسولة للمواقع الإلكترونية
يستخدم مطوّرو الويب أحيانًا XSLT من جهة العميل لتطبيق ترميز العرض التقديمي على الترميز الدلالي، ما يجعله يعمل كلغة نماذج كسولة منفصلة عن نظام JavaScript المتكامل.
هناك حلّان لهذه المشكلة الأكثر عمومية. بالنسبة إلى موقع إلكتروني حالي تم إنشاؤه بهذه الطريقة، من المرجّح أنّ أسهل حلّ هو مجرد إضافة polyfill للحفاظ على الوظائف الحالية. أو ربما يمكنك إجراء عملية تحويل XSLT على جانب الخادم، وعرض HTML الناتج على العميل، بدلاً من XML الأولي. الحلّ الأفضل على المدى الطويل لهذه المشاكل هو الانتقال إلى إطار عمل أحدث يستند إلى JavaScript أو JSON.
إذا واجهت مشكلة معيّنة في Chrome مرتبطة بإيقاف XSLT نهائيًا، يمكنك الإبلاغ عن خطأ هنا.
كيفية رصد استخدام XSLT
بشكل عام، يمكن رصد الميزات المتوقّفة نهائيًا، مثل XSLT، في قاعدة الرموز البرمجية بعدة طرق. يوضّح هذا القسم اثنين منهما.
Reporting API
Reporting API هي آلية عامة لإعداد التقارير يمكن لتطبيقات الويب استخدامها للإبلاغ عن مختلف ميزات النظام الأساسي وشروطه، بما في ذلك إيقاف الميزات نهائيًا. لإعدادها للإبلاغ عن إيقاف XSLT نهائيًا، يمكن استخدام مقتطف رمز برمجي على النحو التالي:
new ReportingObserver((reports, observer) => {
reports.forEach((report) => {
if (report.body.id === "XSLT") {
// XSLT usage was detected - report it back here.
}
});
}, {types: ["deprecation"],buffered: true}).observe();
تقرير التكنولوجيا القديمة في المؤسسة
بالنسبة إلى مشرفي المؤسسات، يمكن استخدام "تقرير استخدام تكنولوجيا قديمة" لجمع بيانات استخدام الميزات المتوقّفة نهائيًا تلقائيًا وإعداد تقارير عنها بطريقة سهلة الاستخدام. يمكنك الاطّلاع على مقالة فريق الدعم في Google هذه للحصول على مزيد من المعلومات حول كيفية تفعيل هذه الميزة.