Podcast-RSS-Prüfer

Fügen Sie Podcast-RSS-XML ein und erhalten Sie eine Korrekturliste für XML-, Kanal-, Episoden-, Audio-Enclosure- und Datumsprobleme.

Podcast RSS XML

Füge den vollständigen Feed einschließlich XML-Deklaration und <rss>-Wurzelelement ein.

Dies ist eine statische Strukturprüfung. Sie ruft keine Feed-, Artwork- oder Medien-URLs ab; prüfen Sie Remote-Verfügbarkeit, Bytelänge, Audiodekodierung und Verzeichnisannahme separat.

Feed-Diagnose

Dies ist eine statische Strukturprüfung. Sie ruft keine Feed-, Artwork- oder Medien-URLs ab; prüfen Sie Remote-Verfügbarkeit, Bytelänge, Audiodekodierung und Verzeichnisannahme separat.

    Füge einen Feed ein und validiere ihn dann, um jedes Problem mit Zeile, Spalte und XML-Pfad zu sehen.

    Bereit für RSS XML.

    Dein Podcast-Feed wird in deinem Browser überprüft. Nichts wird von BroBroGo hochgeladen oder gespeichert.

    FAQ

    Was prüft dieser Podcast-RSS-Prüfer?

    Er prüft, ob das RSS-2.0-XML wohlgeformt ist, ob die erforderlichen RSS-Felder und gängigen Kanal- und Episodenfelder für Apple Podcasts vorhanden sind, außerdem <enclosure>-Attribute, Duplikate und RFC-2822-Datumsangaben.

    Testet es die Audiodatei?

    Er prüft URL und Bytelänge des <enclosure>-Elements, den MIME-Typ, Duplikate und ob Dateiname und Typ zusammenpassen. Die Audiodatei wird weder heruntergeladen noch dekodiert.

    Wird ein Feed, der durchgeht, überall akzeptiert?

    Nein. Podcast-Apps können zusätzliche Regeln und Remote-Prüfungen anwenden. Ein erfolgreicher Test bedeutet nur, dass das eingefügte XML die hier gezeigten statischen Prüfungen erfüllt, nicht dass ein Verzeichnis es akzeptiert oder veröffentlicht.

    Struktur und Anforderungen von RSS 2.0 für Podcasts

    Ein standardkonformer Podcast-Feed basiert auf dem XML-Format und muss den Spezifikationen von RSS 2.0 entsprechen. Der Podcast-RSS-Prüfer analysiert die Struktur des bereitgestellten XML-Dokuments, um sicherzustellen, dass alle syntaktischen und strukturellen Vorgaben eingehalten werden.

    Für eine erfolgreiche Validierung gelten strenge Regeln bezüglich der XML-Elemente:

    • Die Dokumentenwurzel muss <rss> sein.
    • Das Attribut version von <rss> muss zwingend auf "2.0" gesetzt sein.
    • Der RSS-Feed muss genau ein direktes <channel>-Element enthalten.
    • Eine DOCTYPE-Deklaration darf nicht im Dokument enthalten sein. Sollte eine solche Deklaration vorhanden sein, bricht die Prüfung mit der Fehlermeldung „Entfernen Sie die DOCTYPE-Deklaration, bevor Sie diesen Feed überprüfen.“ ab.
    • Das XML-Dokument muss wohlgeformt sein. Ist dies nicht der Fall, gibt das Tool die Fehlermeldung „Beheben Sie das fehlerhafte XML und validieren Sie erneut.“ aus.

    Zusätzlich muss der Kanal mindestens eine Episode enthalten, da andernfalls die Fehlermeldung „Fügen Sie mindestens eine <item> Episode zum Kanal hinzu.“ erzeugt wird.

    Spezifische Anforderungen für Apple Podcasts

    Da die meisten Podcast-Verzeichnisse auf den Standards von Apple Podcasts aufbauen, überprüft das Tool auch diese spezifischen Anforderungen. Dazu gehört zunächst, dass der Apple Podcasts-Namespace auf <rss> deklariert sein muss. Ist dies nicht der Fall, wird der Fehler „Deklarieren Sie den Apple Podcasts-Namespace auf <rss>: ‹namespace›“ ausgegeben.

    Weitere spezifische Prüfungen für Apple Podcasts umfassen:

    • Kategorien: Für die korrekte Einordnung muss ein gültiges Kategorie-Element vorhanden sein. Fehlt dieses oder ist es fehlerhaft, meldet das Tool „Füge itunes:category ein nicht leeres text-Attribut hinzu.“.
    • Explizite Inhalte: Das <itunes:explicit>-Tag muss eindeutig definiert sein. Zulässig sind hierbei nur die Werte "true" oder "false". Jede Abweichung führt zur Fehlermeldung „Setzen Sie itunes:explicit auf true oder false.“.
    • Serielle Sendungen: Wenn es sich um eine serielle Show handelt, benötigt jede einzelne Episode eine positive ganze Zahl im entsprechenden Feld. Andernfalls erscheint die Meldung „Serielle Sendungen benötigen für jede Episode eine positive ganze Zahl in itunes:episode.“.
    • Episodenlimit: Feeds mit einer extrem hohen Anzahl an Episoden stoßen an Plattformgrenzen. Bei mehr als 2.000 Episoden gibt das Tool die Warnung „Dieser Feed hat ‹count› Episoden; Apple Podcasts zeigt nur die neuesten 2.000 an.“ aus.

    Validierung von Audio-Enclosure-Attributen

    Das <enclosure>-Element verknüpft die eigentliche Mediendatei mit der Episode im RSS-Feed. Jede Episode darf exakt ein <enclosure>-Element besitzen. Werden mehrere gefunden, wird dies mit dem Fehler „Behalten Sie genau ein <enclosure> in dieser Episode; gefunden ‹count›.“ quittiert.

    Der Prüfer kontrolliert die Attribute des Enclosures im Detail, ohne jedoch die Mediendatei selbst herunterzuladen oder zu dekodieren:

    • Fehlende Attribute: Fehlt ein Pflichtattribut, erscheint die Meldung „Fügen Sie das erforderliche ‹attribute›-Attribute zu <enclosure> hinzu.“.
    • URL-Gültigkeit: Das Attribut url muss eine vollständige HTTP- oder HTTPS-Adresse sein. Ungültige Adressen erzeugen den Fehler „Setze das Attribut url von <enclosure> auf eine vollständige HTTP- oder HTTPS-URL.“.
    • Dateilänge: Das Attribut length muss die Dateigröße in Bytes als ganze Zahl angeben. Ist der Wert ungültig, meldet das Tool „Trage im Attribut length von <enclosure> die ganzzahlige Byteanzahl ein.“. Ein Wert von 0 ist zwar technisch möglich, erzeugt jedoch die Warnung „Das Attribut length von <enclosure> ist 0. Prüfe vor der Veröffentlichung die tatsächliche Byteanzahl.“.
    • MIME-Typen: Es muss ein gültiger MIME-Typ wie beispielsweise audio/mpeg angegeben werden. Ungültige Typen führen zur Fehlermeldung „Verwenden Sie einen gültigen MIME-Typ wie audio/mpeg.“. Wenn ein Nicht-Audio-MIME-Typ verwendet wird, gibt das Tool die Warnung „Dieses <enclosure> ist nicht als Audio gekennzeichnet. Prüfe, ob eine Video- oder Dokument-Episode beabsichtigt ist.“ aus. Zudem wird geprüft, ob der Dateiname und der MIME-Typ zusammenpassen. Bei Abweichungen erscheint die Warnung „Der Medien-Dateiname und der MIME-Typ stimmen nicht überein (‹extension› vs ‹mime›).“.

    Datumsformatierung nach RFC 2822

    Die zeitliche Sortierung und Veröffentlichung von Episoden in Podcast-Apps hängt direkt von der korrekten Formatierung des Publikationsdatums ab. Fehlt diese Angabe, wird die Warnung „Füge <pubDate> hinzu, damit Podcast-Apps diese Episode zuverlässig sortieren und veröffentlichen können.“ ausgegeben.

    Das Datum muss dem Standard RFC 2822 entsprechen und ein reales Kalenderdatum sowie eine Zeitzone enthalten. Ein gültiges Beispiel ist: Sat, 01 Apr 2023 19:00:00 +0000. Bei Abweichungen meldet das Tool den Fehler „Verwenden Sie ein RFC 2822-Datum mit einem echten Kalenderdatum und einer Zeitzone, zum Beispiel: Sat, 01 Apr 2023 19:00:00 +0000.“.

    Obwohl namentlich genannte Zeitzonen (wie z. B. EST oder GMT) von vielen Systemen verarbeitet werden können, sind sie weniger portabel als numerische Offsets. Daher erzeugt die Verwendung einer benannten Zeitzone die Warnung „Diese benannte Zeitzone wird akzeptiert, ist aber weniger portabel; bevorzugen Sie einen numerischen Offset wie +0000.“.

    Fehlerbehebung mithilfe von XML-Pfaden und Zeilennummern

    Bei der Analyse eines fehlerhaften Feeds gibt der Podcast-RSS-Prüfer präzise Lokalisierungshilfen aus, damit Entwickler und Podcast-Produzenten die Fehler schnell im Quellcode finden können.

    Die Diagnoseergebnisse werden unter der Überschrift „Feed-Diagnose“ zusammengefasst. Jedes gefundene Problem wird mit einer genauen Positionsangabe im Format „Zeile ‹line›, Spalte ‹column›“ ausgewiesen. Zusätzlich bietet das Tool einen direkten XPath-ähnlichen Pfad zum fehlerhaften Element an, der als „Lösung: ‹path›“ dargestellt wird. Über die Verknüpfung „Zu ‹path› in Zeile ‹line› springen“ kann direkt zur betroffenen Stelle navigiert werden.

    Sollte die Liste der Probleme extrem lang sein, wird sie gegebenenfalls gekürzt dargestellt, was durch den Hinweis „Die ersten ‹shown› von insgesamt ‹total› Problemen werden angezeigt.“ signalisiert wird. Wenn der Feed fehlerfrei ist, zeigt das Tool die Meldung „Keine strukturellen Probleme festgestellt.“ an.

    Grenzen der statischen Feed-Validierung

    Es ist wichtig zu verstehen, dass dieser Prüfer eine rein statische Strukturprüfung durchführt. Das bedeutet:

    • Es werden keine Remote-Verfügbarkeiten von URLs geprüft.
    • Es werden keine Bilddateien (Artwork) oder Medien-URLs abgerufen.
    • Die tatsächliche Audiodekodierung wird nicht getestet.

    Ein Feed, der die Validierung erfolgreich besteht, garantiert nicht, dass ein Podcast-Verzeichnis oder eine Plattform wie Apple Podcasts den Feed fehlerfrei akzeptiert oder veröffentlicht. Verzeichnisse führen oft eigene, dynamische Remote-Prüfungen durch, die über die statische XML-Analyse hinausgehen.

    Datenschutz und lokale Verarbeitung

    Die Überprüfung des Podcast-Feeds erfolgt vollständig lokal in Ihrem Webbrowser. Es werden keine XML-Daten, Feeds oder persönlichen Informationen an Server von BroBroGo übertragen oder dort gespeichert. Dies ermöglicht eine private Analyse direkt auf Ihrem Endgerät.

    Das Tool verarbeitet XML-Eingaben bis zu einer maximalen Größe von 500.000 Zeichen pro Überprüfung. Bei Überschreitung dieser Grenze wird die Fehlermeldung „Dieses Tool akzeptiert bis zu ‹max› Zeichen pro Überprüfung.“ angezeigt. Sollte die Verarbeitung aufgrund der Feed-Größe oder komplexer Strukturen zu lange dauern, bricht der Vorgang mit der Meldung „Die Prüfung hat zu lange gedauert. Versuche es mit einem kleineren Feed.“ ab.

    Häufig gestellte Fragen (FAQ)

    Was prüft dieser Podcast-RSS-Prüfer?

    Er prüft, ob das RSS-2.0-XML wohlgeformt ist, ob die erforderlichen RSS-Felder und gängigen Kanal- und Episodenfelder für Apple Podcasts vorhanden sind, außerdem <enclosure>-Attribute, Duplikate und RFC-2822-Datumsangaben.

    Testet es die Audiodatei?

    Er prüft URL und Bytelänge des <enclosure>-Elements, den MIME-Typ, Duplikate und ob Dateiname und Typ zusammenpassen. Die Audiodatei wird weder heruntergeladen noch dekodiert.

    Wird ein Feed, der durchgeht, überall akzeptiert?

    Nein. Podcast-Apps können zusätzliche Regeln und Remote-Prüfungen anwenden. Ein erfolgreicher Test bedeutet nur, dass das eingefügte XML die hier gezeigten statischen Prüfungen erfüllt, nicht dass ein Verzeichnis es akzeptiert oder veröffentlicht.