Структура и изисквания на RSS 2.0 за подкасти
Валидирането на подкаст емисия изисква стриктно спазване на спецификацията RSS 2.0. Инструментът „Валидатор на подкаст RSS“ извършва статичен анализ на предоставения XML код, за да гарантира, че структурата отговаря на техническите стандарти за разпространение на аудио съдържание.
Всеки валиден подкаст фийд трябва да започва с правилен корен на документа. Ако това изискване не е изпълнено, се задейства грешката:
- „Коренът на документа трябва да е <rss>.“
Атрибутът за версия в кореновия елемент също е строго дефиниран. Използването на по-стари или алтернативни версии води до съобщението:
- „Задайте атрибута за версия на <rss> на 2.0.“
Освен това, структурата на документа изисква точно определена йерархия. Всеки RSS фийд трябва да съдържа точно един главен канал, който описва подкаста като цяло. Наличието на повече или липсата на такива елементи предизвиква грешката:
- „RSS трябва да съдържа точно един пряк елемент <channel>; намерени са
‹count›.“
За да бъде успешно разчетен XML документът, той не трябва да съдържа външни дефиниции на типове документи. Ако бъде открита такава декларация, инструментът показва следното съобщение за грешка:
- „Премахнете декларацията DOCTYPE преди да проверите този фийд.“
Всички проверки се извършват локално. RSS емисията на подкаста се проверява във вашия браузър. BroBroGo не качва и не запазва нищо.
Специфични изисквания за Apple Podcasts
Платформата Apple Podcasts налага допълнителни правила върху структурата на RSS емисиите, които са се превърнали в стандарт за индустрията. За да се разпознават специфичните тагове за метаданни, в кореновия елемент <rss> трябва да бъде декларирано съответното именно пространство. При липса на тази декларация се извежда грешката:
- „Обявете именното пространство Apple Podcasts на <rss>:
‹namespace›“
Каналът и неговите епизоди трябва да съдържат набор от задължителни полета. Ако някое от тях липсва, инструментът показва:
- „Добавете задължителното поле
‹field›.“
Всички връзки в емисията, включително основните линкове на канала, трябва да представляват валидни уеб адреси. Неправилното форматиране на тези полета води до:
- „
‹field›трябва да е пълен HTTP или HTTPS URL.“
Изображенията на подкаста и епизодите също подлежат на строга проверка на адреса. Ако атрибутът за връзка към изображението е повреден или непълен, се показва:
- „Задайте itunes:image href на пълен HTTP или HTTPS URL.“
Категориите на подкаста трябва да бъдат правилно дефинирани чрез текстови атрибути. Празни или липсващи стойности генерират:
- „Добавете непразен атрибут text към itunes:category.“
Индикаторът за изрично съдържание (explicit) изисква булева стойност. Всяка друга стойност извън разрешените води до грешката:
- „Задайте itunes:explicit на true или false.“
При серийните подкасти (serial) се изисква стриктно номериране на епизодите. Ако липсва пореден номер, се задейства:
- „Серийните предавания трябва да имат положително цяло число в itunes:episode за всеки епизод.“
Валидиране на аудио файлове и атрибути на <enclosure>
Всеки епизод в подкаст емисията трябва да съдържа точно един медиен файл, дефиниран чрез тага <enclosure>. Наличието на няколко файла в един епизод е невалидно и задейства:
- „Оставете само един <enclosure> в този епизод; намерени са
‹count›.“
Елементът <enclosure> изисква специфични атрибути за размер, тип и местоположение. При липса на някой от тях се показва:
- „Добавете необходимия атрибут
‹attribute›към <enclosure>.“
Адресът на медийния файл трябва да бъде напълно достъпен по сигурен протокол. Невалидните адреси генерират:
- „Задайте пълен HTTP или HTTPS URL в атрибута url на <enclosure>.“
Размерът на файла трябва да бъде посочен в байтове като цяло число. Невалидни стойности за дължина водят до:
- „Задайте целия брой байтове в атрибута length на <enclosure>.“
Ако размерът е зададен като нула, инструментът показва предупреждение:
- „Атрибутът length на <enclosure> е 0. Потвърдете реалния брой байтове преди публикуване.“
Типът на медийната информация (MIME тип) трябва да съответства на поддържаните аудио формати. Използването на невалидни типове води до:
- „Използвайте валиден MIME тип като audio/mpeg.“
Ако MIME типът показва, че файлът не е аудио, се извежда предупреждението:
- „Този <enclosure> не е означен като аудио. Потвърдете, че епизодът умишлено е видео или документ.“
Инструментът също така сравнява разширението на файла в URL адреса с декларирания MIME тип. При разминаване се показва:
- „Името на медийния файл и типът MIME не се съвпадат (
‹extension›срещу‹mime›).“
Форматиране на дати и управление на епизодите
Правилното подреждане на епизодите в приложенията за подкасти зависи изцяло от датата на публикуване. Липсата на този таг води до предупреждението:
- „Добавете <pubDate>, за да могат приложенията за подкасти надеждно да подреждат и публикуват този епизод.“
Датите трябва да следват стриктно стандарта RFC 2822. Използването на неправилен формат или несъществуващи календарни дати задейства грешката:
- „Използвайте дата във формат RFC 2822 с реална календарна дата и часова зона, например: Sat, 01 Apr 2023 19:00:00 +0000.“
Използването на текстови наименования за часовите зони (например EET, GMT) вместо числови отмествания е по-малко съвместимо и предизвиква предупреждение:
- „Тази именувана часова зона се приема, но е по-малко преносима; предпочитайте цифрово отклонение, като +0000.“
За да се избегнат проблеми с производителността в платформите за разпространение, броят на епизодите в една емисия трябва да се контролира. Ако лимитът на Apple Podcasts бъде надвишен, се показва:
- „Тази емисия има
‹count›епизода; Apple Podcasts показва само последните 2 000.“
Всеки епизод трябва да има уникален идентификатор (GUID) и уникален URL адрес на медийния файл. Дублирането им води до следните грешки:
- „Този URL адрес на прикачения файл повтаря стойността на ред
‹first›.“ - „Този GUID повтаря стойността на ред
‹first›.“
Локализиране на грешки и отстраняване на проблеми
При анализ на XML структурата, валидаторът посочва точното местоположение на всеки открит проблем, за да улесни неговото отстраняване. Резултатите се показват под заглавието „Диагностика на емисията“.
Ако в документа има синтактични грешки, които пречат на неговото парсване, се извежда съобщението:
- „Поправете неправилно оформения XML и проверете отново.“
За допълнителна информация относно синтактичния анализ се предоставя детайл от софтуерния парсер:
- „Детайли за парсера:
‹detail›“
За всеки открит проблем инструментът генерира точни координати във формат:
- „Ред
‹line›, колона‹column›“
Заедно с местоположението се предоставя и XPath път до проблемния елемент:
- „Поправка:
‹path›“
Потребителят може да използва директна връзка за преминаване към съответния ред в кода:
- „Отидете на
‹path›на линия‹line›“
Ако броят на проблемите е твърде голям, списъкът се съкращава, като се извежда съобщението:
- „Показани са първите
‹shown›от общо‹total›проблема.“
При успешна проверка без открити отклонения се показва:
- „Не са открити структурни проблеми.“
Ако бъдат открити нередности, се показва обобщението:
- „
‹errors›открити грешки и‹warnings›предупреждения.“
Често задавани въпроси (FAQ)
Какво проверява този валидатор на подкаст RSS?
Проверява дали RSS 2.0 XML е правилно оформен, дали са попълнени задължителните RSS полета и обичайните полета за канали и епизоди на Apple Podcasts, както и атрибутите на <enclosure>, дубликатите и датите по RFC 2822.
Тества ли аудио файла?
Проверява URL адреса и дължината в байтове на <enclosure>, MIME типа, дубликатите и дали името на файла съответства на типа. Не изтегля и не декодира аудиото.
Ще бъде ли приета навсякъде емисия, която е преминала проверката?
Не. Приложенията за подкасти могат да добавят правила и отдалечени проверки. Успешната проверка означава, че поставеният XML покрива показаните тук статични проверки, а не че всяка директория ще го приеме или публикува.
Има ли ограничение за размера на проверявания XML файл?
Да, инструментът приема до 500 000 знака на проверка. Ако лимитът бъде надвишен, се показва съобщение за грешка. При твърде дълга обработка системата спира с предупреждение да опитате с по-малка емисия.