Az RSS 2.0 struktúra és a podcast-hírfolyamok követelményei
A podcastok terjesztésének alapja az RSS 2.0 specifikáció, amely egy strukturált XML-formátum. Ahhoz, hogy a különböző kliensprogramok és könyvtárak hibátlanul feldolgozzák a hírfolyamot, az XML-dokumentumnak szigorú szerkezeti szabályoknak kell megfelelnie.
A validálás során az első és legfontosabb követelmény, hogy a dokumentum gyökere <rss> kell legyen. Ezen felül az <rss> elem version attribútumát pontosan "2.0" értékre kell állítani. A hírfolyam nem tartalmazhat DOCTYPE deklarációt; ha a rendszer ilyet észlel, a következő hibaüzenetet jeleníti meg: "Távolítsa el a DOCTYPE deklarációt a feed ellenőrzése előtt.". Amennyiben az XML-kód szerkezetileg sérült, a folyamat leáll, és a "Javítsa a hibás XML-t, majd ellenőrizze újra." hibaüzenet figyelmezteti a felhasználót a javítás szükségességére.
Az RSS-struktúrán belül a hírfolyamnak pontosan egy közvetlen <channel> elemet kell tartalmaznia. Ha ez hiányzik, vagy egynél több szerepel a kódban, a rendszer hibát jelez. A csatornának kötelezően tartalmaznia kell legalább egy epizódot is, különben az ellenőrző az "Adjon legalább egy <item> epizódot a csatornához." hibaüzenetet adja vissza.
Speciális Apple Podcasts követelmények
Az Apple Podcasts platformja határozza meg a modern podcast-terjesztés legfontosabb kiegészítő szabályait. Ahhoz, hogy a hírfolyam megfeleljen ezeknek az elvárásoknak, az Apple Podcasts névterét kötelezően deklarálni kell az <rss> gyökérelemen.
A csatorna és az epizódok szintjén számos kötelező mező meglétét ellenőrzi az eszköz. Ha egy kötelező mező hiányzik, az "Adja hozzá a szükséges ‹field›-t." hibaüzenet jelenik meg. A hivatkozásoknak és a képeknek is szigorú szabályoknak kell megfelelniük: a csatorna- és epizódlinkek esetében a "‹field›-nak teljes HTTP vagy HTTPS URL-nek kell lennie." hiba lép fel érvénytelen címeknél, míg a képeknél az "Állítsa a itunes:image href-jét teljes HTTP vagy HTTPS URL-re." utasítás figyelmeztet a hibára.
Az Apple specifikus elemei közül a kategóriáknak érvényes formátumúaknak kell lenniük, azaz kötelező egy nem üres text attribútumot adni az elemhez. Az explicit tartalomra vonatkozó <itunes:explicit> tag értéke kizárólag "true" vagy "false" lehet. Sorozatos (serial) típusú műsorok esetén minden egyes epizódhoz kötelező megadni egy pozitív egész számú <itunes:episode> értéket.
A médiafájlok (enclosure) ellenőrzése
A podcast-epizódok lényegi eleme a <enclosure> tag, amely a letölthető vagy lejátszható médiafájlra mutat. Minden egyes epizódnak pontosan egy <enclosure> elemmel kell rendelkeznie. Ha egy epizódban több is található, vagy egy sem szerepel, a rendszer hibát jelez.
Az ellenőrzés során a következő attribútumok megléte és helyessége kritikus:
- URL: Az url attribútumnak teljes HTTP- vagy HTTPS-URL-nek kell lennie.
- Hossz (bájtszám): Az length attribútumban egész számként kell megadni a bájtok számát. Ha ez az érték 0, a rendszer a következő figyelmeztetést küldi: "Az <enclosure> length attribútuma 0. Közzététel előtt ellenőrizze a tényleges bájtszámot.".
- MIME típus: Érvényes MIME típust kell használni, például audio/mpeg-at. Ha a megadott típus nem audio jellegű, a "Ez az <enclosure> nincs hangként megjelölve. Ellenőrizze, hogy a videó- vagy dokumentumepizód szándékos-e." figyelmeztetés jelenik meg.
Az eszköz ellenőrzi a fájlnév kiterjesztése és a megadott MIME típus közötti összhangot is. Amennyiben eltérés van, a "A média fájlnév és MIME típus nem egyezik (‹extension› vs ‹mime›)." figyelmeztetés lép életbe. Emellett a rendszer kiszűri a duplikált média-URL-eket is; ha egy fájl hivatkozása már szerepelt korábban, a "Ez a csatolmány URL megismétli az értéket a(z) ‹first› sorban." hibaüzenet jelzi a problémát. Fontos megjegyezni, hogy az eszköz nem tölti le és nem dekódolja a tényleges hangfájlt, kizárólag az XML-ben megadott metaadatokat ellenőrzi.
Dátumformátumok és egyedi azonosítók
A podcast-alkalmazások az epizódok időrendi sorrendbe állításához és megbízható közzétételéhez igénylik a közzétételi dátumot. Ha egy epizódnál hiányzik a <pubDate> elem, a rendszer figyelmeztetést küld: "Adja hozzá a(z) <pubDate>-t, hogy a podcast alkalmazások megbízhatóan tudják sorba rendezni és közzétenni ezt az epizódot.".
A dátumok formátumának szigorúan követnie kell az RFC 2822 szabványt, valós naptári dátummal és időzónával. Hibás formátum esetén a következő hibaüzenet jelenik meg: "Használjon RFC 2822 dátumot valódi naptári dátummal és időzónával, például: Sat, 01 Apr 2023 19:00:00 +0000.". Bár a szövegesen megnevezett időzónák (például EST vagy GMT) technikailag elfogadottak, kevésbé hordozhatóak, ezért ilyenkor a "Ez a nevezett időzóna elfogadott, de kevésbé hordozható; előnyben részesítendő a numerikus eltérés, például +0000." figyelmeztetés látható.
Az epizódok egyedi azonosítására szolgáló GUID (Globally Unique Identifier) értékeknek egyedinek kell lenniük a teljes hírfolyamon belül. Ha egy GUID már korábban előfordult, a rendszer a "Ez a GUID megismétli az értéket a(z) ‹first› sorban." hibaüzenettel jelzi a duplikációt.
Hibakeresés XML útvonalak és pozíciók alapján
A hibák gyors kijavítását nagyban segíti, hogy az ellenőrző pontos helymeghatározást ad minden egyes felismert problémához. A diagnosztikai listában minden tétel mellett szerepel a pontos helyszín "‹line›. sor, oszlop ‹column›" formátumban.
A pontos XML-struktúrán belüli elhelyezkedést egy XPath-szerű útvonal mutatja meg, amely a "Javítás: ‹path›" címke alatt olvasható. A felhasználó közvetlenül a hiba helyére ugorhat a "Ugrás ide: ‹path›, ‹line›. sor" link segítségével. Ha a hírfolyam rendkívül sok hibát tartalmaz, a lista csonkolásra kerülhet, amelyet a "Az összesen ‹total› problémából az első ‹shown› látható." üzenet jelez.
Az ellenőrzés korlátai és adatkezelés
A Podcast RSS-ellenőrző egy statikus struktúra-ellenőrző eszköz. Ez azt jelenti, hogy a sikeres validálás nem garantálja automatikusan, hogy egy külső podcast-könyvtár (például az Apple Podcasts vagy a Spotify) azonnal el fogja fogadni vagy közzé fogja tenni a hírfolyamot. A külső könyvtárak saját hálózati ellenőrzéseket, kép- és média-elérhetőségi teszteket, valamint egyéb egyedi szabályokat is alkalmazhatnak.
Az eszköz használata során a következő technikai korlátok érvényesek:
- Karakterlimit: Az ellenőrző egyszerre legfeljebb 500 000 karakter hosszúságú XML-bemenetet képes feldolgozni. Ennél nagyobb méret esetén a "Ez az eszköz ellenőrzésenként legfeljebb
‹max›karaktert fogad el." hibaüzenet jelenik meg. - Időtúllépés: Ha a folyamat túl sokáig tart, a rendszer a "Az ellenőrzés túl sokáig tartott. Próbáljon kisebb feedet." üzenettel leáll.
- Általános hiba: Ha a validálás egyéb okból nem tud befejeződni, a "Az ellenőrzés nem tudott befejeződni." üzenet látható.
- Epizódok száma: Ha a hírfolyam több mint 2000 epizódot tartalmaz, a rendszer figyelmeztetést küld: "Ennek a feednek
‹count›epizódja van; az Apple Podcasts csak a legfrissebb 2 000-et jeleníti meg.".
Ami az adatvédelmet illeti, a podcast feed ellenőrzése teljes egészében a felhasználó böngészőjében történik. A BroBroGo semmit nem tölt fel és nem ment el a szervereire, így a feldolgozás helyben, kliensoldalon valósul meg.
Gyakran Ismételt Kérdések
Mit ellenőriz ez a Podcast RSS Validátor? Ellenőrzi, hogy az RSS 2.0 XML jól formázott-e, megvannak-e a kötelező RSS-mezők és az Apple Podcasts gyakori csatorna- és epizódmezői, továbbá az <enclosure> attribútumait, a duplikátumokat és az RFC 2822 dátumokat.
Teszteli a hangfájlt? Ellenőrzi az <enclosure> URL-jét és bájthosszát, a MIME-típust, a duplikátumokat, valamint hogy a fájlnév megfelel-e a típusnak. A hangot nem tölti le és nem dekódolja.
Elfogadják mindenhol egy átmenő feedet? Nem. A podcast alkalmazások szabályokat és távoli ellenőrzéseket is hozzáadhatnak. Az átadás azt jelenti, hogy a beillesztett XML megfelelt az itt mutatott statikus ellenőrzéseknek, nem pedig azt, hogy egy könyvtár elfogadja vagy közzéteszi azt.