Teoretycznie, według specyfikacji RFC 4329 , application/javascript.
Powód, dla którego ma to być, applicationnie ma nic wspólnego z tym, czy typ jest czytelny, czy wykonywalny. Dzieje się tak, ponieważ istnieją niestandardowe mechanizmy określania zestawu znaków określone przez sam język / typ, a nie tylko przez ogólny charsetparametr. Podtyp textpowinien mieć możliwość transkodowania przez proxy na inny zestaw znaków, zmieniając parametr zestawu znaków. Nie dotyczy to JavaScript, ponieważ:
za. RFC mówi, że agenci użytkownika powinni węszyć BOM w skrypcie, aby określić typ (nie jestem pewien, czy jakakolwiek przeglądarka faktycznie to robi);
b. przeglądarki używają innych informacji - łącznie z kodowaniem strony, aw niektórych przeglądarkach script charsetatrybutem - do określenia zestawu znaków. Zatem każdy serwer proxy, który próbowałby transkodować zasób, złamałby jego użytkowników. (Oczywiście w rzeczywistości nikt i tak nigdy nie używa transkodujących serwerów proxy, ale taki był zamiar).
Dlatego dokładne bajty pliku muszą być dokładnie zachowane , co czyni go applicationtypem binarnym, a nie technicznie opartym na znakach text.
Z tego samego powodu application/xmljest oficjalnie preferowany w stosunku do text/xml: XML ma własne mechanizmy sygnalizacji zestawu znaków w paśmie. Wszyscy ignorują też applicationXML.
text/javascripti text/xmlmoże nie być oficjalną właściwą rzeczą, ale jest to, czego wszyscy używają dzisiaj ze względu na kompatybilność, a powody, dla których nie są one właściwe, są praktycznie całkowicie nieważne.