Teoretycznie, według specyfikacji RFC 4329 , application/javascript
.
Powód, dla którego ma to być, application
nie 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 charset
parametr. Podtyp text
powinien 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 charset
atrybutem - 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 application
typem binarnym, a nie technicznie opartym na znakach text
.
Z tego samego powodu application/xml
jest oficjalnie preferowany w stosunku do text/xml
: XML ma własne mechanizmy sygnalizacji zestawu znaków w paśmie. Wszyscy ignorują też application
XML.
text/javascript
i text/xml
moż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.