it-swarm.dev

Jaką wartość typu zawartości należy wysłać dla mojej mapy witryny XML?

Myślałem, że powinienem wysłać „text/xml”, ale potem przeczytałem, że powinienem wysłać „application/xml”. Czy to ma znaczenie? Czy ktoś może wyjaśnić różnicę?

119
Kyle

Różnica między text/xml i application/xml jest domyślnym kodowaniem znaków, jeśli parametr charset jest pominięty:

Text/xml i application/xml zachowują się inaczej, gdy zestaw znaków parametr nie jest wyraźnie określony. Jeśli domyślny zestaw znaków (np. US-ASCII) dla tekstu/xml jest z jakiegoś powodu niewygodny (np. Złe serwery internetowe ), Application/xml stanowi alternatywę (patrz „Opcjonalne Parametry” z rejestracja aplikacji/xml w sekcji 3.2).

Dla text/xml :

Zgodny z [RFC2046], jeśli obiekt tekstowy/xml zostanie odebrany z pominięto parametr charset, procesory MIME i procesory XML MUSI użyć domyślnej wartości zestawu znaków „us-ascii” [ASCII]. W przypadkach gdzie obiekt XML MIME jest przesyłany przez HTTP, domyślnie wartość zestawu znaków to nadal „us-ascii”.

Dla application/xml :

Jeśli aplikacja/xml zostanie odebrana, gdy zestaw znaków parametr jest pominięty, brak informacji na temat zestaw znaków przez nagłówek Content-Type MIME. Zgodny XML procesory MUSZĄ postępować zgodnie z wymaganiami sekcji 4.3.3 [XML] które bezpośrednio odnoszą się do tej przygodności. Jednak procesory MIME które nie są procesorami XML NIE POWINIEN zakładać domyślnego zestawu znaków, jeśli parametr charset jest pominięty w encji aplikacji/xml.

Jeśli więc pominięto parametr charset, kodowanie znaków text/xml to US-ASCII, natomiast z application/xml kodowanie znaków można określić w samym dokumencie.

Obecnie w Internecie obowiązuje zasada: „Bądź surowy w stosunku do danych wyjściowych, ale bądź tolerancyjny w stosunku do danych wejściowych”. Oznacza to, że podczas dostarczania danych przez Internet upewnij się, że spełniają standardy w jak największym stopniu. Ale wbuduj niektóre mechanizmy, aby przeoczyć błędy lub odgadnąć, kiedy odbierasz i interpretujesz dane 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żywane kodowanie znaków (zalecam użycie odpowiedniego domyślnego kodowania znaków, aby grać bezpiecznie, więc w przypadku application/xml używa UTF-8 lub UTF-16).

150
Gumbo

Zgodnie z ogólną zasadą, najbezpieczniejszym zakładem na poprawne traktowanie dokumentu przez wszystkie serwery WWW, serwery proxy i przeglądarki klientów jest prawdopodobnie:

  1. Użyj typu treści aplikacji/xml
  2. Dołącz kodowanie znaków w typie zawartości, prawdopodobnie UTF-8
  3. Dołącz pasujące kodowanie znaków w atrybucie kodowania samego dokumentu XML.

Jeśli chodzi o specyfikację RFC 3023 , której niektóre przeglądarki nie implementują poprawnie, główna różnica w typach treści polega na tym, w jaki sposób klienci powinni traktować kodowanie znaków w następujący sposób:

W przypadku application/xml, application/xml-dtd, application/xml-external-parsed-entity lub dowolnego podtypu aplikacji/xml, takiego jak application/atom + xml, application/rss + xml lub application/rdf + xml , kodowanie znaków jest określone w następującej kolejności:

  1. kodowanie podane w parametrze charset nagłówka HTTP Content-Type
  2. kodowanie podane w atrybucie kodowania deklaracji XML w dokumencie,
  3. utf-8.

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:

  1. kodowanie podane w parametrze charset nagłówka HTTP Content-Type lub
  2. us-ascii.

Większość analizatorów składni nie implementuje specyfikacji; ignorują typ kontekstu HTTP i po prostu używają kodowania w dokumencie. Przy tak wielu źle ukształtowanych dokumentach jest mało prawdopodobne, że wkrótce się to zmieni.

24
nas

obie są w porządku.

text/xxx oznacza, że ​​w przypadku, gdy program nie rozumie xxx, sensowne jest pokazanie pliku użytkownikowi jako zwykły tekst. application/xxx oznacza, że ​​pokazywanie tego nie ma sensu.

Pamiętaj, że te typy zawartości zostały pierwotnie zdefiniowane dla załącznika do wiadomości e-mail, zanim zostały później wykorzystane w świecie sieci.

9

text/xml jest dla dokumentów, które byłyby znaczące dla człowieka, gdyby były prezentowane jako tekst bez dalszego przetwarzania, application/xml jest dla wszystkiego innego

Każda encja XML nadaje się do użycia z aplikacją/xml media typ bez modyfikacji. Ale to nie wykorzystuje faktu, że XML może w wielu przypadkach być traktowany jako zwykły tekst. Programy użytkownika MIME (i agentów internetowych), które nie mają wyraźnej obsługi application/xml potraktuje go jako aplikację/strumień oktetu, dla przykład, oferując zapisanie go w pliku.

Aby wskazać, że encja XML powinna być traktowana jako zwykły tekst przez domyślnie użyj typu nośnika tekstowego/xml. To ogranicza kodowanie używane w encji XML do tych, które są zgodne z wymagania dotyczące typów nośników tekstowych opisane w [RFC-2045] i [RFC-2046], np. UTF-8, ale nie UTF-16 (z wyjątkiem HTTP).

- http://www.ietf.org/rfc/rfc2376.txt

6
Quentin

Inne odpowiedzi tutaj odnoszą się do ogólnego pytania o to, czym jest odpowiedni Content-Type dla odpowiedzi XML i zawarcia (jak z Jaka jest różnica między text/xml vs application/xml dla odpowiedzi usługi sieciowej ), że oba text/xml i application/xml są dopuszczalne. Jednak żaden nie określa, czy istnieją jakieś reguły specyficzne dla sitemaps.

Odpowiedź: nie ma. Specyfikacja mapy witryny to https://www.sitemaps.org i za pomocą wyszukiwania Google site: możesz potwierdzić, że nie zawiera ona słów lub zwrotów mime, mimetype, content -type, application/xml, lub text/xml w dowolnym miejscu. Innymi słowy, całkowicie milczy na temat tego, co Content-Type powinien być używany do wyświetlania map witryn.

Wobec braku jakiegokolwiek komentarza w specyfikacji mapy witryny bezpośrednio odnoszącej się do tego pytania, możemy bezpiecznie założyć, że obowiązują te same zasady, co przy wyborze Content-Type dowolnego innego dokumentu XML - tzn. Że może to być text/xml lub application/xml.

0
Mark Amery