Odpowiedzi:
Różnica między text / xml i application / xml jest domyślnym kodowania znaków, jeśli charset parametr jest pominięty:
Text / xml i application / xml zachowują się inaczej, gdy parametr charset nie jest jawnie określony. Jeśli domyślny zestaw znaków (np. US-ASCII) dla text / xml jest z jakiegoś powodu niewygodny (np. Złe serwery WWW), application / xml zapewnia alternatywę (patrz „Parametry opcjonalne” rejestracji application / xml w Sekcji 3.2).
W przypadku tekstu / xml :
Zgodne z [RFC2046], jeśli otrzymana zostanie jednostka text / xml z pominiętym parametrem charset, procesory MIME i procesory XML MUSZĄ użyć domyślnej wartości zestawu znaków „us-ascii” [ASCII]. W przypadkach, gdy jednostka XML MIME jest przesyłana przez HTTP, domyślną wartością zestawu znaków jest nadal „us-ascii”.
W przypadku aplikacji / xml :
Jeśli zostanie odebrana jednostka application / xml, w której pominięto parametr charset, w nagłówku MIME Content-Type nie są dostarczane żadne informacje o zestawie znaków. Zgodne procesory XML MUSZĄ spełniać wymagania zawarte w sekcji 4.3.3 dokumentu [XML], które bezpośrednio odnoszą się do tej ewentualności. Jednak procesory MIME, które nie są procesorami XML, NIE POWINNY zakładać domyślnego zestawu znaków, jeśli parametr charset został pominięty w jednostce application / xml.
Więc jeśli parametr charset zostanie pominięty, kodowanie znaków text / xml to US-ASCII, podczas gdy w przypadku application / xml kodowanie znaków można określić w samym dokumencie.
W Internecie obowiązuje praktyczna zasada: „Bądź ścisły w stosunku do danych wyjściowych, ale bądź tolerancyjny wobec danych wejściowych”. Oznacza to, że dostarczając dane przez Internet, należy w jak największym stopniu spełniać standardy. Ale wbuduj pewne mechanizmy, aby przeoczyć błędy lub zgadywać podczas odbierania i interpretowania danych przez Internet.
Więc w twoim przypadku po prostu wybierz jeden z dwóch typów (polecam application / xml ) i upewnij się, że poprawnie określiłeś użyte kodowanie znaków (polecam użyć odpowiedniego domyślnego kodowania znaków, aby grać bezpiecznie, więc w przypadku aplikacji / xml użyj UTF-8 lub UTF-16).
Zasadniczo najbezpieczniejszym sposobem na poprawne traktowanie dokumentu przez wszystkie serwery internetowe, serwery proxy i przeglądarki klientów jest prawdopodobnie:
Jeśli chodzi o specyfikację RFC 3023 , której niektóre przeglądarki nie implementują poprawnie, główna różnica w typach zawartości polega na tym, jak klienci powinni traktować kodowanie znaków, w następujący sposób:
Dla application / xml, application / xml-dtd, application / xml-external-parsed-entity lub dowolnego z podtypów application / xml, takich jak application / atom + xml, application / rss + xml lub application / rdf + xml , kodowanie znaków jest określane w następującej kolejności:
W przypadku text / xml, text / xml-external-parsed-entity lub podtypu, takiego jak text / foo + xml, atrybut kodowania deklaracji XML w dokumencie jest ignorowany, a kodowanie znaków to:
Większość parserów nie implementuje specyfikacji; ignorują HTTP Context-Type i po prostu używają kodowania w dokumencie. Przy tak wielu źle sformułowanych dokumentach jest mało prawdopodobne, aby w najbliższym czasie to się zmieniło.
oba są w porządku.
text / xxx oznacza, że w przypadku, gdy program nie rozumie xxx, warto pokazać plik użytkownikowi jako zwykły tekst. application / xxx oznacza, że nie ma sensu go pokazywać.
Należy pamiętać, że te typy zawartości zostały pierwotnie zdefiniowane dla załączników do wiadomości e-mail, zanim zostały później użyte w świecie sieci.
text / xml jest przeznaczony dla dokumentów, które byłyby znaczące dla człowieka, gdyby były przedstawiane jako tekst bez dalszego przetwarzania, application / xml jest dla wszystkiego innego
Każda jednostka XML nadaje się do użytku z typem nośnika application / xml bez modyfikacji. Nie wykorzystuje to jednak faktu, że XML można w wielu przypadkach traktować jako zwykły tekst. Agenty użytkownika MIME (i agenty użytkownika WWW), które nie mają wyraźnego wsparcia dla application / xml, potraktują go jako aplikację / strumień oktetu, na przykład oferując zapisanie go do pliku.
Aby wskazać, że jednostka XML powinna być domyślnie traktowana jako zwykły tekst, użyj typu mediów text / xml. Ogranicza to kodowanie używane w jednostce XML do tych, które są zgodne z wymaganiami dla typów mediów tekstowych, jak opisano w [RFC-2045] i [RFC-2046], np. UTF-8, ale nie UTF-16 (z wyjątkiem HTTP).
text/htmlistnieje od bardzo dawna i było trochę późno, aby to zmienić.
Inne odpowiedzi tutaj odnoszą się do ogólnego pytania, jakie jest właściwe Content-Typedla odpowiedzi XML, i kończą się (tak jak w przypadku Jaka jest różnica między tekstem / xml a aplikacją / xml dla odpowiedzi usługi sieciowej ), że oba text/xmli application/xmlsą dozwolone. Jednak żaden z nich nie dotyczy tego, czy istnieją jakieś zasady specyficzne dla map witryn .
Odpowiedź: nie ma. Specyfikacja mapy witryny to https://www.sitemaps.org , a korzystając z site:wyszukiwań Google , możesz potwierdzić, że nie zawiera ona nigdzie słów ani fraz mime , typ MIME , content-type , application / xml ani text / xml . Innymi słowy, całkowicie milczy na temat tego, czego Content-Typenależy używać do udostępniania map witryn.
Wobec braku komentarza w specyfikacji mapy witryny bezpośrednio odnoszącego się do tego pytania, możemy spokojnie założyć, że obowiązują te same zasady, co przy wyborze Content-Typedowolnego innego dokumentu XML - tj. Może to być albo text/xmlalbo application/xml.
text/htmla preferowanym typem MIME XHTML jestapplication/xhtml+xml.