Antworten:
Der Unterschied zwischen text / xml und application / xml ist die Standardzeichencodierung, wenn der Zeichensatzparameter weggelassen wird:
Text / xml und application / xml verhalten sich unterschiedlich, wenn der Zeichensatzparameter nicht explizit angegeben wird. Wenn der Standardzeichensatz (dh US-ASCII) für Text / XML aus irgendeinem Grund unpraktisch ist (z. B. fehlerhafte Webserver), bietet application / xml eine Alternative (siehe "Optionale Parameter" für die Registrierung von Anwendung / XML in Abschnitt 3.2).
Für Text / XML :
In Übereinstimmung mit [RFC2046] MÜSSEN MIME-Prozessoren und XML-Prozessoren den Standard-Zeichensatzwert von "us-ascii" [ASCII] verwenden, wenn eine Text- / XML-Entität mit weggelassenem Zeichensatzparameter empfangen wird. In Fällen, in denen die XML-MIME-Entität über HTTP übertragen wird, lautet der Standardzeichensatzwert weiterhin "us-ascii".
Für application / xml :
Wenn eine application / xml-Entität empfangen wird, bei der der Zeichensatzparameter weggelassen wird, werden vom MIME-Inhaltstyp-Header keine Informationen zum Zeichensatz bereitgestellt. Konforme XML-Prozessoren MÜSSEN den Anforderungen in Abschnitt 4.3.3 von [XML] entsprechen, die diese Eventualität direkt ansprechen. MIME-Prozessoren, die keine XML-Prozessoren sind, sollten jedoch KEINEN Standardzeichensatz annehmen, wenn der Zeichensatzparameter in einer application / xml-Entität weggelassen wird.
Wenn der Zeichensatzparameter weggelassen wird, lautet die Zeichencodierung von text / xml in application / xml US-ASCII die Zeichenkodierung im Dokument selbst angegeben werden kann.
Als Faustregel im Internet gilt nun: „Seien Sie streng mit der Ausgabe, aber tolerant mit der Eingabe.“ Das heißt, stellen Sie sicher, dass Sie die Standards so weit wie möglich erfüllen, wenn Sie Daten über das Internet liefern. Bauen Sie jedoch einige Mechanismen ein, um Fehler zu übersehen oder beim Empfangen und Interpretieren von Daten über das Internet zu erraten.
Also in Ihrem Fall wählen Sie einfach eine der beiden Arten (ich empfehle application / xml ) und stellen Sie sicher , dass die verwendeten Zeichen angeben richtig kodiert (ich empfehle die jeweilige Standard - Zeichenkodierung zu verwenden , um sicher zu gehen, so im Fall von application / xml Verwendung UTF-8 oder UTF-16).
Als Faustregel gilt: Die sicherste Möglichkeit, Ihr Dokument von allen Webservern, Proxys und Client-Browsern ordnungsgemäß zu behandeln, ist wahrscheinlich die folgende:
In Bezug auf die RFC 3023- Spezifikation, die einige Browser nicht ordnungsgemäß implementieren, besteht der Hauptunterschied bei den Inhaltstypen darin, wie Clients die Zeichencodierung wie folgt behandeln sollen:
Für application / xml, application / xml-dtd, application / xml-external-parsed-entity oder einen der Untertypen von application / xml wie application / atom + xml, application / rss + xml oder application / rdf + xml wird die Zeichenkodierung in dieser Reihenfolge bestimmt:
Für text / xml, text / xml-external-parsed-entity oder einen Subtyp wie text / foo + xml wird das Codierungsattribut der XML-Deklaration im Dokument ignoriert und die Zeichencodierung lautet:
Die meisten Parser implementieren die Spezifikation nicht. Sie ignorieren den HTTP-Kontexttyp und verwenden nur die Codierung im Dokument. Bei so vielen schlecht geformten Dokumenten wird sich das wahrscheinlich nicht so schnell ändern.
Beide sind gut.
text / xxx bedeutet, dass es sinnvoll ist, die Datei dem Benutzer als einfachen Text anzuzeigen, falls das Programm xxx nicht versteht. application / xxx bedeutet, dass es sinnlos ist, es anzuzeigen.
Bitte beachten Sie, dass diese Inhaltstypen ursprünglich für E-Mail-Anhänge definiert wurden, bevor sie später in der Webwelt verwendet wurden.
text / xml ist für Dokumente, die für einen Menschen von Bedeutung wären, wenn sie ohne weitere Verarbeitung als Text dargestellt würden. application / xml ist für alles andere
Jede XML-Entität ist für die Verwendung mit dem Medientyp application / xml ohne Änderung geeignet. Dies nutzt jedoch nicht die Tatsache aus, dass XML in vielen Fällen als einfacher Text behandelt werden kann. MIME-Benutzeragenten (und Webbenutzeragenten), die application / xml nicht explizit unterstützen, behandeln sie beispielsweise als application / octet-stream, indem sie beispielsweise anbieten, sie in einer Datei zu speichern.
Verwenden Sie den Medientyp text / xml, um anzugeben, dass eine XML-Entität standardmäßig als einfacher Text behandelt werden soll. Dies beschränkt die in der XML-Entität verwendete Codierung auf diejenigen, die mit den Anforderungen für Textmedientypen kompatibel sind, wie in [RFC-2045] und [RFC-2046] beschrieben, z. B. UTF-8, jedoch nicht UTF-16 (außer) HTTP).
text/htmlgibt es schon sehr lange und es war ein bisschen spät, es zu ändern.
Andere Antworten hier befassen sich mit der allgemeinen Frage, was Content-Typefür eine XML-Antwort geeignet ist, und schließen (wie bei Was ist der Unterschied zwischen text / xml und application / xml für die Webservice-Antwort ), dass beide text/xmlund application/xmlzulässig sind. Es wird jedoch nicht angesprochen, ob es spezifische Regeln für Sitemaps gibt .
Antwort: gibt es nicht. Die Sitemap-Spezifikation lautet https://www.sitemaps.org . Mithilfe der Google- site:Suche können Sie bestätigen, dass sie keine Wörter oder Ausdrücke enthält nirgendwo mime , mimetype , content-type , application / xml oder text / xml enthält . Mit anderen Worten, es wird völlig still über das Thema, was Content-Typezum Bereitstellen von Sitemaps verwendet werden soll.
In Ermangelung eines Kommentars in der Sitemap-Spezifikation, der sich direkt mit dieser Frage befasst, können wir davon ausgehen, dass dieselben Regeln gelten wie bei der Auswahl Content-Typeeines anderen XML-Dokuments - dh, dass es sich entweder um text/xmloder handelt application/xml.
text/htmlund der bevorzugte XHTML-MIME-Typ istapplication/xhtml+xml.