Strukturen og kravene til RSS 2.0 for podkaster
En podkastfeed bygger på XML-standarden RSS 2.0. For at feeden skal være gyldig, må dokumentroten være <rss>. Videre må version-attributtet på <rss> være satt til "2.0". Inne i dette rotelementet må RSS-en inneholde nøyaktig ett direkte <channel>-element. Hvis dette ikke er tilfelle, vil validatoren rapportere feil.
For at feeden skal fungere i moderne avspillere, må Apple Podcasts-navneområdet være erklært på <rss>. Dette navneområdet gir tilgang til spesifikke tagger som styrer hvordan innholdet presenteres i katalogene. En gyldig feed krever også at kanalen inneholder minst én <item>-episode. Hvis du produserer en seriesending (serial), krever plattformene at det er oppgitt et positivt heltall for hver enkelt episode.
Spesifikke krav for Apple Podcasts
Apple Podcasts og andre store kataloger stiller strenge krav til metadataene i feeden din. Mangler det obligatoriske felt i kanalen eller i de enkelte episodene, vil du få feilmeldingen "Legg til den nødvendige ‹field›.".
Følgende regler gjelder for viktige elementer i feeden:
- Lenker og bilder: Felt som inneholder lenker må være fullstendige HTTP- eller HTTPS-URL-er. Hvis en lenke er ugyldig, viser verktøyet feilen "‹field› må være en fullstendig HTTP eller HTTPS URL.". For bilder må du sette href til en fullstendig HTTP eller HTTPS URL.
- Kategorier: Kategorisering av podkasten må gjøres riktig. Du må legge til et ikke-tomt text-attributt til
<itunes:category>. - Eksplisitt innhold: Taggene som markerer om innholdet er egnet for mindreårige må være presise. Tagger som
<itunes:explicit>må settes til "true" eller "false". - Antall episoder: En feed kan teknisk sett inneholde svært mange episoder, men hvis feeden har mer enn 2 000 episoder, vil du få en advarsel om at Apple Podcasts bare viser de 2 000 nyeste.
Validering av lydfiler og enclosure-attributter
I en podkastfeed er det <enclosure>-taggen som kobler episoden til selve lydfilen. Hver episode må ha nøyaktig én <enclosure>. Hvis det finnes flere, vil verktøyet gi feilmeldingen "Behold nøyaktig én <enclosure> i denne episoden; funnet ‹count›.".
Validatoren utfører en grundig sjekk av attributtene i denne taggen uten å laste ned eller dekode selve lydfilen:
- Attributter: Hvis obligatoriske attributter mangler, vises feilmeldingen "Legg til det nødvendige
‹attribute›-attributtet til<enclosure>.". - URL: Du må sette url-attributtet på
<enclosure>til en fullstendig HTTP- eller HTTPS-URL. Duplikate URL-er tillates ikke; hvis en URL gjentas, får du feilen "Denne<enclosure>-URL-en gjentar verdien på linje‹first›.". - Filstørrelse: Attributtet for filstørrelse må oppgis i byte. Du må sette length-attributtet på
<enclosure>til et helt antall byte. Hvis verdien er satt til 0, utløses advarselen "length-attributtet på<enclosure>er 0. Bekreft det faktiske antallet byte før publisering.". - MIME-type: Du må bruke en gyldig MIME-type som audio/mpeg. Hvis du bruker en ikke-lydtype, får du advarselen "Denne
<enclosure>er ikke merket som lyd. Bekreft at episoden med vilje er en video eller et dokument.". - Samsvar: Verktøyet kontrollerer om filendelsen i URL-en stemmer overens med den oppgitte MIME-typen. Ved avvik får du advarselen "Mediefilnavnet og MIME-typen stemmer ikke overens (
‹extension›vs‹mime›).".
Viktigheten av korrekt datoformat (RFC 2822)
Datoer i en podkastfeed brukes av avspillere til å sortere episodene kronologisk og publisere dem på riktig tidspunkt. Hvis en episode mangler publiseringsdato, vil du se advarselen "Legg til <pubDate> slik at podkastapper kan sortere og publisere episoden riktig.".
Datoformatet må følge spesifikasjonen RFC 2822. Hvis datoen er feilformatert eller inneholder en ugyldig kalenderdato, vil verktøyet gi feilmeldingen "Bruk en RFC 2822-dato med en ekte kalenderdato og tidssone, for eksempel: Sat, 01 Apr 2023 19:00:00 +0000.".
Tidssoner bør angis som numeriske avvik. Hvis du bruker navngitte tidssoner (som GMT eller EST), vil du få advarselen "Denne navngitte tidssonen godtas, men har dårligere støtte; bruk helst et numerisk avvik som +0000.".
Slik tolker du feilmeldinger og feilsøker feeden
Når du kjører en sjekk, vil verktøyet gi deg en detaljert feed-diagnose. Resultatet oppsummeres øverst med antall feil, advarsler og episoder som ble funnet. Hvis alt er i orden, vises meldingen "Ingen strukturelle problemer funnet.". Ved problemer vises meldingen "Fant ‹errors› feil og ‹warnings› advarsler.".
For å gjøre feilsøkingen enkel, viser verktøyet nøyaktig hvor i XML-dokumentet problemet ligger. Du vil se posisjonen angitt som "Linje ‹line›, kolonne ‹column›". I tillegg får du en XPath-lignende sti til elementet, merket med "Reparer: ‹path›". Du kan klikke på lenken "Gå til ‹path› på linje ‹line›" for å hoppe direkte til det aktuelle stedet i koden. Hvis feeden inneholder svært mange feil, kan listen bli avkortet, og du vil se meldingen "Viser de første ‹shown› av ‹total› problemer.".
Hvis XML-en har grunnleggende syntaksfeil som gjør at den ikke kan tolkes i det hele tatt, vil du få feilmeldingen "Fiks den misformede XML, og valider deretter på nytt." sammen med en teknisk detalj fra systemet: "Parser-detalj: ‹detail›". Hvis feeden inneholder en DOCTYPE-erklæring, må denne fjernes, og verktøyet vil gi feilmeldingen "Fjern DOCTYPE-erklæringen før du sjekker denne feed.".
Begrensninger ved statisk validering
Dette verktøyet utfører en statisk struktursjekk av XML-koden din. Det er viktig å forstå hva dette innebærer for publiseringsprosessen:
| Hva validatoren sjekker | Hva du må sjekke manuelt |
|---|---|
| At XML-strukturen er gyldig og følger RSS 2.0 | At eksterne servere faktisk er tilgjengelige |
| At påkrevde felt og attributter er fylt ut | At innholdet i lydfilene er intakt og kan dekodes |
| At URL-er har riktig format (HTTP/HTTPS) | Om en spesifikk podkastkatalog vil godkjenne feeden |
| At angitt filstørrelse er et heltall | At bildefiler og omslagskunst oppfyller katalogenes krav |
At en feed passerer denne valideringen betyr utelukkende at den oppfyller de statiske reglene som testes her. Det garanterer ikke at en ekstern katalog eller applikasjon vil godkjenne eller publisere feeden din.
Personvern og tekniske grenser
Når du bruker denne validatoren, foregår hele prosessen lokalt i nettleseren din. Podkastfeeden sjekkes i nettleseren din. BroBroGo laster ikke opp eller lagrer noe. Dette sikrer at dataene dine forblir på din egen maskin under hele feilsøkingen.
Verktøyet har en øvre grense for inndata på 500 000 tegn per sjekk. Hvis du limer inn en feed som overskrider denne grensen, vil du se meldingen "Dette verktøyet godtar opptil ‹max› tegn per sjekk.". Dersom prosessen tar for lang tid, avbrytes den med meldingen "Valideringen tok for lang tid. Prøv en mindre feed.". Hvis systemet støter på andre uventede problemer under kjøringen, vil meldingen "Valideringen kunne ikke fullføres." vises. Husk også at du må lime inn innhold før du starter; hvis du klikker på validering uten inndata, får du beskjed om å "Lim inn Podcast RSS XML før du validerer.".
Ofte stilte spørsmål (FAQ)
Hva sjekker denne validatoren for podkast-RSS?
Den sjekker at RSS 2.0-XML-en er riktig strukturert, at obligatoriske RSS-felt og vanlige Apple Podcasts-felt finnes, samt <enclosure>-attributter, duplikater og RFC 2822-datoer.
Tester den lydfilen?
Den sjekker URL-en i <enclosure>, antall byte, MIME-type, om URL-en er unik, og om filnavnet samsvarer med typen. Lydfilen lastes ikke ned eller dekodes.
Vil en feed som passerer bli akseptert overalt?
Nei. Podkastapper og -kataloger kan bruke flere regler og eksterne kontroller. Bestått betyr bare at XML-en du limte inn, oppfylte de statiske kontrollene som vises her.
Hvorfor får jeg feilmelding om duplikate GUID-er?
Hver episode i feeden må ha en helt unik identifikator (GUID). Hvis to eller flere episoder deler nøyaktig samme identifikator, vil verktøyet rapportere feilen "Denne GUIDen gjentar verdien på linjen ‹first›." slik at du kan rette det opp.