Validatore RSS per Podcast

Struttura e requisiti dello standard RSS 2.0 per i podcast

Un feed podcast si basa sullo standard XML RSS 2.0, una specifica che richiede una struttura rigida e ben definita per consentire alle piattaforme di indicizzare correttamente i contenuti. Il documento deve aprirsi obbligatoriamente con la radice <rss>. Qualsiasi elemento precedente, come una dichiarazione DOCTYPE, compromette la lettura del feed; in presenza di tale dichiarazione, lo strumento restituisce l'errore "Rimuovi la dichiarazione DOCTYPE prima di controllare questo feed.".

La radice <rss> deve includere l'attributo version impostato esattamente sul valore "2.0". Se questo attributo è assente o presenta un valore differente, viene segnalato l'errore "Imposta su 2.0 l’attributo version di <rss>.". Al di sotto della radice, il feed deve contenere esattamente un elemento <channel> diretto. La presenza di più elementi di questo tipo genera l'errore "RSS deve contenere esattamente un <channel> diretto; Trovato ‹count›.". All'interno del canale devono essere definiti i metadati generali del podcast e i singoli episodi, ciascuno rappresentato da un blocco <item>. Un canale valido deve contenere almeno un episodio, altrimenti il sistema mostrerà l'errore "Aggiungi almeno un episodio <item> al canale.".

Requisiti specifici per Apple Podcasts

Le specifiche di Apple Podcasts estendono lo standard RSS 2.0 introducendo uno spazio di nomi (namespace) dedicato e regole di validazione restrittive per i metadati del canale e dei singoli episodi. Per consentire l'uso dei tag personalizzati, la radice <rss> deve dichiarare lo spazio di nomi Apple Podcasts. In caso contrario, viene visualizzato l'errore "Dichiara lo spazio di nomi Apple Podcasts su <rss>: ‹namespace›".

I requisiti per i canali e gli episodi includono la presenza di campi obbligatori, la correttezza dei collegamenti ipertestuali e la formattazione dei metadati:

• Campi obbligatori: La mancanza di elementi essenziali per il canale o per gli episodi genera l'errore "Aggiungi il ‹field› richiesto.".
• Collegamenti e immagini: I collegamenti generici devono essere URL completi che utilizzano i protocolli HTTP o HTTPS, pena l'errore "‹field› deve essere un URL HTTP o HTTPS completo.". Per le immagini, l'attributo href deve rispettare lo stesso standard, altrimenti viene restituito l'errore "Imposta itunes:image href su un URL HTTP o HTTPS completo.".
• Categorie: Le categorie del podcast devono essere strutturate correttamente. Se un tag non contiene testo valido, viene mostrato l'errore "Aggiungi a itunes:category un attributo text non vuoto.".
• Contenuto esplicito: Il tag <itunes:explicit> non ammette valori arbitrari. Deve essere impostato esclusivamente su "true" o "false", altrimenti si incorre nell'errore "Imposta itunes:explicit su true o false.".
• Podcast seriali: Se il podcast è impostato come seriale, ogni singolo episodio deve includere un numero identificativo valido. La mancanza di questo dato genera l'errore "I podcast di tipo seriale richiedono un numero intero positivo in itunes:episode per ogni episodio.".
• Limite episodi: Apple Podcasts impone un limite massimo di visualizzazione pari a 2.000 episodi. Se un feed supera questa soglia, lo strumento genera l'avviso "Questo feed ha ‹count› episodi; Apple Podcasts visualizza solo i più recenti 2.000.".

Validazione degli allegati multimediali (Enclosure)

Il cuore di un feed podcast è l'elemento <enclosure>, che definisce il file multimediale associato a ciascun episodio. Ogni blocco <item> deve contenere esattamente un elemento <enclosure>. Se un episodio presenta più allegati, viene restituito l'errore "Mantieni un solo <enclosure> in questo episodio; ne sono stati trovati ‹count›.".

La convalida dell'elemento <enclosure> analizza i seguenti attributi:

Se il tipo MIME inserito non è di tipo audio, viene generato l'avviso "Questo <enclosure> non è contrassegnato come audio. Verifica che l’episodio video o documento sia intenzionale.". Inoltre, lo strumento confronta l'estensione del file presente nell'URL con il tipo MIME dichiarato. Se non corrispondono, viene mostrato l'avviso "Il nome del file media e il tipo MIME non concordano (‹extension› contro ‹mime›).".

Per garantire l'integrità del feed, non sono ammessi duplicati. Se lo stesso URL viene riutilizzato in più episodi, il sistema segnala l'errore "Questo URL dell'allegato ripete il valore alla linea ‹first›.". Lo stesso controllo di unicità si applica all'identificativo globale dell'episodio, generando l'errore "Questo GUID ripete il valore alla linea ‹first›." in caso di duplicazione.

Formattazione delle date secondo lo standard RFC 2822

La data di pubblicazione di ogni episodio, definita tramite il tag <pubDate>, è fondamentale per consentire alle applicazioni di ordinare cronologicamente i contenuti. Se un episodio non contiene questo elemento, viene mostrato l'avviso "Aggiungi <pubDate> in modo che le app per podcast possano ordinare e pubblicare questo episodio in modo affidabile.".

Le date devono seguire rigorosamente lo standard RFC 2822, indicando un giorno della settimana valido, una data del calendario reale e un fuso orario espresso come scostamento numerico. Un esempio di formato corretto è: Sat, 01 Apr 2023 19:00:00 +0000. Se la data non rispetta questa struttura o contiene valori temporali impossibili, viene restituito l'errore "Usa una data RFC 2822 con una data del calendario reale e fuso orario, ad esempio: Sat, 01 Apr 2023 19:00:00 +0000.".

L'uso di fusi orari nominativi (come GMT o EST) è parzialmente supportato ma sconsigliato per motivi di compatibilità. In questo caso, lo strumento genera l'avviso "Questo fuso orario nominativo è accettato ma meno portabile; preferisci uno scostamento numerico come +0000.".

Diagnosi degli errori e debug del feed

Quando si esegue la convalida, l'interfaccia mostra i risultati sotto l'intestazione "Diagnosi del feed". Se il documento XML non presenta problemi di formattazione o di conformità ai requisiti descritti, viene visualizzato il messaggio "Nessun problema strutturale trovato.". In caso contrario, viene mostrato il riepilogo "Trovati ‹errors› errori e ‹warnings› avvisi." insieme al conteggio complessivo "‹count› errori", "‹count› avvisi" e "‹count› episodi".

Per facilitare la correzione, ogni problema rilevato viene localizzato con precisione:

• Viene indicata la posizione esatta tramite la dicitura "Linea ‹line›, colonna ‹column›".
• Viene fornito il percorso XPath dell'elemento interessato sotto forma di "Correzione: ‹path›".
• Un collegamento ipertestuale con il testo "Vai a ‹path› alla linea ‹line›" permette di raggiungere direttamente il punto esatto del codice.

Se l'elenco dei problemi rilevati è molto esteso, la visualizzazione viene limitata mostrando il messaggio "Mostrando i primi ‹shown› di ‹total› problemi.". Se l'XML inserito è talmente danneggiato da impedire l'analisi della struttura, viene restituito l'errore "Correggi l’XML malformato, quindi convalidalo di nuovo." accompagnato dalle informazioni tecniche del parser sotto la voce "Dettaglio del parser: ‹detail›".

Funzionamento e limiti della convalida statica

La convalida del feed avviene interamente all'interno del browser dell'utente. Il file XML inserito non viene caricato su server esterni né salvato da BroBroGo, garantendo che l'elaborazione rimanga locale.

Lo strumento accetta un input massimo di 500.000 caratteri. Se l'input supera questo limite, viene mostrato il messaggio "Questo strumento accetta fino a ‹max› caratteri per ogni prova.". Se il processo di analisi richiede risorse eccessive, il sistema si interrompe mostrando l'errore "La convalida ha richiesto troppo tempo. Prova con un feed più piccolo.". Se la procedura si interrompe per altri motivi tecnici, viene visualizzato il messaggio "Non è stato possibile completare la convalida.". Se si tenta di avviare la verifica senza aver inserito alcun testo, l'interfaccia mostra l'avviso "Incolla il XML RSS del podcast prima di convalidare.".

È importante sottolineare che questo strumento esegue esclusivamente un controllo statico della struttura del codice XML. Non effettua il download, la decodifica o la riproduzione dei file audio indicati nei tag <enclosure>, né verifica la raggiungibilità dei server remoti che ospitano i file multimediali o le immagini di copertina. Di conseguenza, il superamento dei controlli statici indica che il file XML è strutturalmente corretto, ma non garantisce che una directory esterna o una piattaforma di distribuzione accetti o pubblichi il podcast.

Domande frequenti (FAQ)

Cosa controlla questo Validatore RSS per Podcast?

Controlla che l’XML RSS 2.0 sia ben formato, che siano presenti i campi RSS obbligatori e quelli comuni di canale ed episodio per Apple Podcasts, oltre agli attributi di <enclosure>, ai duplicati e alle date RFC 2822.

Verifica il file audio?

Controlla l’URL e la lunghezza in byte di <enclosure>, il tipo MIME, i duplicati e la coerenza tra nome file e tipo. Non scarica né decodifica l’audio.

Un feed che passa il controllo sarà accettato ovunque?

No. Le app per podcast possono aggiungere regole e controlli remoti. Passare significa che il XML incollato ha superato i controlli statici mostrati qui, non che una directory lo accetterà o pubblicherà.

Quali sono i limiti di dimensione per l'analisi del feed?

Lo strumento accetta un inserimento di testo fino a un massimo di 500.000 caratteri per singola sessione di convalida.