مدقق RSS للبودكاست

بنية ومتطلبات خلاصة RSS 2.0 للبودكاست

تعتمد خلاصات البودكاست على بروتوكول RSS 2.0 كبنية أساسية لنقل البيانات الوصفية للحلقات وملفات الصوت. لكي تكون الخلاصة صالحة للعمل، يجب أن تلتزم بترميز XML قياسي وخالٍ من الأخطاء الهيكلية. تبدأ عملية التحقق من فحص جذر المستند، حيث يجب أن يكون جذر المستند <rss>. كما يجب ضبط سمة version في <rss> على 2.0.

من القواعد الأساسية في بنية الخلاصة أنه يجب أن يحتوي RSS على مباشر واحد بالضبط لوسم <channel>، ويؤدي وجود أكثر أو أقل من ذلك إلى فشل التحقق. داخل هذا القناة، يتم تنظيم البيانات الأساسية التي تصف البودكاست ككل، تليها عناصر الحلقات الفردية. تضع الأداة حدًا أقصى لحجم المدخلات يبلغ 500,000 حرفًا لكل فحص لضمان سرعة المعالجة ودقتها.

متطلبات Apple Podcasts الخاصة بالخلاصات

تفرض منصة Apple Podcasts معايير محددة لضمان قبول الخلاصة وعرضها بشكل صحيح للمستمعين. أول هذه المتطلبات هو أنه يجب التصريح بمساحة أسماء Apple Podcasts على <rss>. بدون هذا الإعلان، لن تتمكن المنصات من قراءة الوسوم المخصصة للبودكاست.

تشمل المتطلبات الإضافية للقناة والحلقات ما يلي:

• الروابط والصور: يجب أن يكون الحقل المطلوب عنوان URL كامل يبدأ بـ HTTP أو HTTPS. كما يتطلب فحص الصور ضبط href الخاص بـ <itunes:image> على عنوان URL كامل يبدأ بـ HTTP أو HTTPS.
• التصنيفات: عند تحديد تصنيف البودكاست، يجب أضف سمة نصية غير فارغة إلى <itunes:category>.
• المحتوى الصريح: يجب ضبط <itunes:explicit> على true أو false.
• تنظيم الحلقات: يجب أضف حلقة واحدة على الأقل <item> إلى القناة. وفي حال كان البودكاست يتبع النمط المتسلسل، فإن العروض المتسلسلة تحتاج إلى <itunes:episode> صحيح موجب لكل حلقة.
• حدود الحلقات: تنصح المنصات بإدارة حجم الخلاصة بعناية؛ فإذا كانت الخلاصة تحتوي على عدد كبير من الحلقات، سيظهر تحذير يشير إلى أن الخلاصة تحتوي على عدد حلقات كبير، حيث تعرض Apple Podcasts أحدث 2000 حلقة فقط.

التحقق من ملفات الصوت المرفقة (Enclosures)

تمثل الحاوية <enclosure> الرابط الفعلي لملف الصوت الخاص بالحلقة، وتتطلب معايير صارمة لضمان إمكانية تشغيلها على مشغلات البودكاست. تقوم الأداة بفحص هذه العناصر بدقة وفق القواعد التالية:

1. وحدانية المرفق: يجب أن تحتوي كل حلقة على عنصر <enclosure> واحد فقط، وحافظ على <enclosure> واحدة بالضبط في هذه الحلقة.
2. السمات الأساسية: يجب وجود جميع السمات المطلوبة، وإلا سيظهر خطأ يطالب بـ أضف السمة المطلوبة ‹attribute› إلى <enclosure>.
3. رابط الملف: يجب ضبط سمة url في <enclosure> على عنوان URL كامل يبدأ بـ HTTP أو HTTPS.
4. حجم الملف: يجب ضبط سمة length في <enclosure> على عدد صحيح من البايتات. إذا تم تعيين القيمة إلى صفر، يظهر تحذير بأن قيمة length في <enclosure> هي 0. تحقق من العدد الفعلي للبايت قبل النشر.
5. نوع الملف (MIME): يجب استخدام نوع MIME صالح مثل audio/mpeg. إذا تم استخدام نوع غير مدعوم، يظهر تحذير بأن لم يُحدّد هذا كمحتوى صوتي. تأكد من أن نشر حلقة فيديو أو مستند أمر مقصود. كما يتم التحقق من تطابق الامتداد مع النوع، وفي حال الاختلاف يظهر تحذير بأن اسم ملف الوسائط ونوع MIME غير متوافقين.
6. منع التكرار: يمنع تكرار الروابط بين الحلقات، حيث يظهر خطأ إذا كان هذا الرابط المرفق يكرر القيمة في السطر المحدد.

تنسيق التواريخ والمعرفات الفريدة

تعتمد تطبيقات البودكاست على التواريخ لترتيب الحلقات وعرضها تصاعديًا أو تنازليًا. يجب استخدام تاريخًا وفق RFC 2822 مع تاريخ تقويمي حقيقي والمنطقة الزمنية، على سبيل المثال: Sat, 01 Apr 2023 19:00:00 +0000. يؤدي غياب التاريخ إلى ظهور تحذير يطالب بـ أضف <pubDate> حتى تتمكن تطبيقات البودكاست من ترتيب هذه الحلقة ونشرها بشكل موثوق.

بالنسبة للمناطق الزمنية، يفضل استخدام الإزاحة الرقمية؛ حيث إن هذه المنطقة الزمنية المسماة مقبولة لكنها أقل قابلية للنقل؛ الأفضل استخدام إزاحة رقمية مثل +0000.

بالإضافة إلى التواريخ، تحتاج كل حلقة إلى معرف فريد وثابت <guid>. تكمن أهمية هذا المعرف في منع تكرار الحلقات في مشغلات المستخدمين، ويظهر خطأ مباشر إذا كان هذا المعرف GUID يكرر القيمة في السطر المحدد لحلقة أخرى.

كيفية تفسير أخطاء الخلاصة وإصلاحها

عند تشغيل أداة "مدقق RSS للبودكاست"، يتم تحليل مستند XML وعرض النتائج تحت عنوان "تشخيص الخلاصة". تعرض الأداة ملخصًا يحتوي على عدد الأخطاء، عدد التحذيرات، وعدد الحلقات المكتشفة.

لتسهيل عملية الإصلاح، توفر الأداة مسارًا دقيقًا لكل مشكلة مكتشفة:

• تحديد الموقع: يتم عرض موقع المشكلة بصيغة السطر ‹line›، العمود ‹column›.
• مسار XML: يظهر مسار العنصر المتأثر بصيغة الإصلاح: ‹path›.
• الانتقال المباشر: توفر الأداة رابطًا تفاعليًا لنص المشكلة مكتوبًا عليه اذهب إلى ‹path› في السطر ‹line›.

في حال وجود مشاكل هيكلية تمنع المحلل من قراءة الملف بالكامل، ستظهر رسائل خطأ صريحة مثل أصلح بنية XML غير الصحيحة، ثم أعد التحقق أو أزل إعلان DOCTYPE قبل فحص هذه الخلاصة. وإذا كانت الخلاصة سليمة تمامًا، تظهر رسالة تؤكد أنه لم يتم العثور على مشاكل هيكلية.

خصوصية البيانات وحدود الفحص الثابت

يتم فحص خلاصة البودكاست في متصفحك. لا يتم رفع أو حفظ أي شيء بواسطة BroBroGo. تتم العملية محليًا بالكامل لضمان خصوصية بياناتك.

يجب على مطوري ومقدمي البودكاست استيعاب طبيعة هذا الفحص؛ فهذا فحص هيكلي ثابت. الأداة لا تطلب روابط التغذية أو الأعمال الفنية أو الوسائط، كما أنها لا تقوم بتنزيل الملف الصوتي أو فك ترميزه. اجتياز الخلاصة للفحص يعني مطابقتها للمعايير الهيكلية الموضحة، ولكنه لا يضمن قبولها التلقائي في الأدلة الخارجية التي قد تفرض شروطًا ديناميكية إضافية.

---

الأسئلة الشائعة

ما الذي يفحصه مدقق RSS للبودكاست؟
يفحص سلامة بنية RSS 2.0 XML، ووجود حقول RSS المطلوبة وحقول القناة والحلقة الشائعة في Apple Podcasts، إضافة إلى سمات <enclosure> والقيم المكررة وتواريخ RFC 2822.

هل يختبر الملف الصوتي؟
يفحص عنوان URL وطول البايت في <enclosure> ونوع MIME والتكرار ومدى توافق اسم الملف مع النوع. ولا ينزّل الصوت أو يفك ترميزه.

هل الخلاصة التي تجتاز الاختبار ستُقبل في كل مكان؟
لا. يمكن لتطبيقات البودكاست إضافة قواعد وفحوصات عن بعد. النجاح يعني أن XML الملصق اجتاز الفحوصات الثابتة المعروضة هنا، وليس أن الدليل سيقبلها أو ينشرها.

ماذا أفعل إذا ظهرت لي رسالة تفيد بأن التحقق استغرق وقتًا طويلًا؟
تقبل هذه الأداة ما يصل إلى 500,000 حرفًا لكل فحص. إذا ظهرت رسالة تفيد بأن التحقق استغرق وقتًا أطول من اللازم، يجب تجربة خلاصة أصغر حجمًا لضمان إتمام الفحص بنجاح.