Khi nào nên sử dụng ứng dụng loại JavaScript MIME / javascript thay vì văn bản / javascript?


157

Dựa trên câu hỏi Mã jQuery không hoạt động trong IE , text/javascriptđược sử dụng trong các tài liệu HTML để Internet Explorer có thể hiểu được.

Nhưng tôi tự hỏi, khi nào bạn sẽ sử dụng application/javascript, và quan trọng hơn, tại sao bạn sẽ sử dụng nó thay vì text/javascript?


có thể bị lừa / giải thích: stackoverflow.com/questions/876561/ từ
Benn



Câu trả lời:


243

Về lý thuyết, theo RFC 4329 , application/javascript.

Lý do được cho applicationlà không liên quan gì đến việc loại này có thể đọc được hay thực thi được. Đó là bởi vì có các cơ chế xác định bộ ký tự tùy chỉnh được đặt bởi chính ngôn ngữ / loại, thay vì chỉ là charsettham số chung . Một kiểu con textnên có khả năng được chuyển mã bởi một proxy sang một bộ ký tự khác, thay đổi tham số bộ ký tự. Điều này không đúng với JavaScript vì:

a. RFC nói rằng các tác nhân người dùng nên thực hiện việc đánh hơi BOM trên tập lệnh để xác định loại (tôi không chắc liệu có trình duyệt nào thực sự làm điều này không);

b. các trình duyệt sử dụng thông tin khác, mã hóa bao gồm cả mã hóa của trang và trong một số trình duyệt, script charsetthuộc tính này để xác định bộ ký tự. Vì vậy, bất kỳ proxy nào đã cố gắng chuyển mã tài nguyên sẽ phá vỡ người dùng của nó. (Tất nhiên trong thực tế không ai từng sử dụng proxy chuyển mã, nhưng đó là ý định.)

Do đó, các byte chính xác của tệp phải được bảo toàn chính xác , làm cho nó trở thành applicationloại nhị phân và không dựa trên ký tự kỹ thuật text.

Vì lý do tương tự, application/xmlđược chính thức ưu tiên hơn text/xml: XML có các cơ chế báo hiệu bộ ký tự trong dải riêng. Và mọi người cũng bỏ qua applicationcho XML.

text/javascripttext/xmlcó thể không phải là Quyền chính thức, nhưng có những thứ mà mọi người sử dụng ngày nay vì lý do tương thích, và lý do tại sao chúng không phải là điều đúng đắn thực tế đang nói hoàn toàn không quan trọng.


4
Giải pháp "tương thích" nhất là không bao gồm bất kỳ loại nội dung nào trong phản hồi. RFC tuyên bố rằng không có loại nội dung rõ ràng, người nhận sẽ hiểu nó "theo ngữ cảnh" , đây luôn là hành vi đúng cho tất cả các trình duyệt ngay từ các trình duyệt đầu tiên
Pacerier

Hãy cẩn thận với application/javascriptvà IE chạy trên chế độ tương thích với IE=8. Có vẻ như các tập lệnh nội tuyến không được đánh giá đúng. text/javascripthoạt động tốt ở đó.
Joscha

2
@Pacerier - Tôi biết nhận xét này đã 5 tuổi, nhưng ngày nay, tốt nhất là bao gồm các loại mime, đặc biệt đối với các trang web loại diễn đàn, vì lý do bảo mật. Yêu cầu người nhận giải thích kiểu này để một người mở để tấn công bằng cách tải lên tệp javascript độc hại dưới dạng hình ảnh, sau đó trình duyệt diễn giải và chạy tập lệnh đó. Tốt hơn là để máy chủ trả về các loại mime cho tất cả các phản hồi và sử dụng tiêu đề X-Content-Type-Options: nosniffđể ngăn trình duyệt diễn giải loại.
sammy_winter

@sammy_winter Tôi thấy những cảnh báo như thế này ở mọi nơi và co rúm mỗi lần. Nếu tôi cho phép người dùng tải lên nội dung, có lẽ tôi sẽ xác thực nhiều hơn là "oh yeah, tên phù hợp với regex cho tệp png, tôi có thể tin điều đó", phải không? Nếu tiêu đề không chính xác trở thành "vấn đề bảo mật", vấn đề có thể ở đâu đó sâu hơn, bạn có nghĩ vậy không? Điều này giống như với ẩn Server: nginxhoặc bất cứ điều gì nginx gửi. Như thể bất cứ ai có khả năng tìm ra lỗ hổng đều cần tiêu đề rõ ràng để biết máy chủ nào bạn chạy ...
Sahsahae

17

Vấn đề với loại MIME của Javascript là đã không có tiêu chuẩn trong nhiều năm. Bây giờ chúng tôi đã có ứng dụng / javascript là một loại MIME chính thức.

Nhưng thật ra, loại MIME hoàn toàn không thành vấn đề, vì trình duyệt có thể tự xác định loại. Đó là lý do tại sao thông số kỹ thuật HTML5 nói rằng điều đó type="text/javascript"không còn cần thiết nữa.


5

applicationbởi vì .js-Files không phải là thứ mà người dùng muốn đọc mà là thứ nên được thực thi.


Đó là câu trả lời chính thức nhưng IE bóp nghẹt nó.
Benn

20
@Benn: Có lẽ vì người dùng IE phải đọc tất cả các tệp JS vì họ không thực thi đúng cách? Ít nhất, đó là trung thực bởi Microsoft;)
thejh

Rất thích nhận xét của bạn, nhưng thật không may, những người không thể đọc javascript vẫn sử dụng IE nên chúng tôi phải xử lý nó :(.
Đánh dấu Baijens

1
Tôi không nghĩ liệu bạn có muốn đọc hay không có liên quan gì đến lý do tại sao. Nó liên quan đến việc làm thế nào dữ liệu được chuyển mã - hay đúng hơn, cho dù nó có thể.
Zenexer

về mặt kỹ thuật, HTML và CSS cũng được trình duyệt "thực thi" (phân tích cú pháp) để tạo ra kết quả của mã dưới dạng nội dung trực quan và không có nghĩa là người dùng "đọc" nó, vì vậy, câu trả lời này không có nhiều ý nghĩa. Tôi đoán có sự nhầm lẫn lớn về "văn bản" và "ứng dụng" là gì. Nếu tôi có thể bỏ phiếu trong vấn đề này, tôi muốn nói IETF nên cân nhắc "text" nội dung như text, và binarylà một trong hai application-Hoặc các "mục đích" của loại nói như trong "hình ảnh", hay "tài liệu", vv

1

application / javascript là loại chính xác để sử dụng nhưng vì nó không được IE6-8 hỗ trợ nên bạn sẽ bị mắc kẹt với văn bản / javascript. Nếu bạn không quan tâm đến tính hợp lệ (loại trừ HTML5) thì đừng chỉ định một loại.


Bạn lấy cái này ở đâu? Tôi khá chắc chắn rằng nó được hỗ trợ. Hoặc, ít nhất, nó sẽ bị bỏ qua.
Zenexer

@Zenexer đọc câu trả lời của anh ấy cho một câu hỏi khác . Dường như khả năng tương thích IE có nghĩa là không application/javascript.
Camilo Martin

@CamiloMartin Tôi sử dụng nó tốt với IE xuống còn 6 lần. Họ chỉ mặc định cho JavaScript.
Zenexer

@Zenexer Hừ, lạ. Tôi tự hỏi vấn đề trong các câu hỏi và trả lời khác là gì.
Camilo Martin

@Zenexer Đã được một thời gian kể từ khi tôi phải giải quyết vấn đề này nhưng đây là một số tài khoản khác gây ra sự cố với IE6-8. Không hoàn toàn chắc chắn tại sao điều này dường như chỉ quan trọng một số lần nhưng theo kinh nghiệm của tôi, nó đã gây ra vấn đề.
Radu
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.