Loại MIME 'image / jpg' có giống với 'image / jpeg' không?


341

Câu hỏi khá đơn giản nhưng dường như không thể tìm thấy nó ở bất cứ đâu trực tuyến. Tôi đang cố gắng tạo một chương trình tùy thuộc vào loại tệp sẽ cung cấp cho tôi phần mở rộng.


10
AFAIK chỉ có loại "hình ảnh / jpeg" freeformatter.com/mime-types-list.html#mime-types-list
Dale


Phải là đêm khuya nhầm lẫn rồi. Tôi sẽ thử dùng "image / jpeg".
Joe Scotto

Câu trả lời:


493

Không, image/jpgkhông giống như image/jpeg, chỉ image/jpegđược công nhận là loại mime thực tế cho các tệp JPEG.

Xem https://tools.ietf.org/html/rfc3745 , https://www.w3.org/Graphics/JPEG/ .

Việc cung cấp Loại nội dung không chính xác image/jpgcho IE có thể gây ra sự cố, xem http://www.bennadel.com/blog/2609-iNET-explorer-aborts-images-with-the-wrong-mime-type.htm .


3
Chúng ta nên đặt gì trong mime.types? image/jpeg jpeg jpg;image/jpg jpeg jpg;
cyber8200

40
Chỉ hình ảnh / jpeg
James Bone

Vấn đề chính gây ra bởi điều này là Safari sẽ mở một liên kết hình ảnh trong Bản xem trước thay vì trong cửa sổ trình duyệt vì nó nghĩ rằng đó là một loại hình ảnh không xác định (về mặt kỹ thuật, đó là).
Peter Flynn

16

Đối với những người nó có thể giúp đỡ, tôi sử dụng danh sách này làm tài liệu tham khảo để xác định loại nội dung của mình khi tôi phải xử lý hình ảnh trên ứng dụng của mình.

Nó nói rằng phần mở rộng jpg có thể được khai báo với Content-type : image/jpeg

Không có image/jpgthuộc tính nào cho loại nội dung.


7

tl; dr "tiêu chuẩn" là một mớ hỗn độn; nó phụ thuộc vào người bạn hỏi là ai!

Nhìn chung, dường như không có loại MIME image/jpg. Tuy nhiên, trên thực tế, gần như tất cả các phần mềm xử lý các tệp hình ảnh có tên " *.jpg" đều ổn.
Chủ đề cụ thể này gây nhầm lẫn vì sự liên kết khác nhau của phần mở rộng tên tệp được liên kết với loại MIME phụ thuộc vào tổ chức nào đã tạo bảng phần mở rộng tên tệp cho các loại MIME. Nói cách khác, mở rộng tên tệp.jpg có thể là nhiều thứ khác nhau.

Ví dụ: đây là ba "danh sách đầy đủ" và một RFC khác nhau xung quanh các phần mở rộng tên tệp định dạng JPEG Image khác nhau và các loại MIME được liên kết.

Những "danh sách đầy đủ" và RFC không có loại MIME image/jpg! Nhưng đối với MIME gõ image/jpegmột số danh sách làm đã thay đổi phần mở rộng tên file ( .jpeg, .jpg, ...). Các danh sách khác không đề cập image/jpeg.
Ngoài ra, có các loại định dạng Hình ảnh JPEG khác nhau (ví dụ: Định dạng Hình ảnh JPEG lũy tiến , JPEG 2000 , vân vân) và "Phần mở rộng JPEG" có thể hoặc không trùng lặp trong phần mở rộng tên tệp và loại MIME được khai báo.
Một điều khó hiểu nữa là RFC 3745 dường như không khớp với các loại phương tiện truyền thông IANA nhưng RFC 3745 được cho là thông báo cho tài liệu IANA Media Type . Ví dụ: trong RFC 3745 .jpflà phần mở rộng tệp ưa thích cho image/jpxnhưng trong Loại phương tiện IANA , tên jpfnày không có (và tài liệu IANA tham chiếu RFC 3745 !).
Một điều khó hiểu khác là IANA Media Type liệt kê "tên" nhưng không liệt kê "phần mở rộng tên tệp". Đây là mục đích, nhưng nhầm lẫn nỗ lực ánh xạ các phần mở rộng tên tệp thành các loại MIME.
Một điều khó hiểu khác: đó là " mime ", hay " MIME ", hay " MIME type ", hay " mime type ", hay " mime / type ", hay " type media " 😧

Các tài liệu dường như chính thức nhất của IANA là không đầy đủ đáng ngạc nhiên. Không có loại MIME nào được đăng ký để mở rộng tập tin .jpgnhưng vẫn tồn tại số lẻ vnd.sealedmedia.softseal.jpg. Phần mở rộng tệp .JPEGchỉ được gọi là một videoloại trong khi phần mở rộng tệp .jpeglà loại hình ảnh (khi chữ in hoa và chữ in hoa bắt đầu có vấn đề!?). Đồng thời, jpeg2000là loại videochưa RFC 3745 coi JPEG 2000 là một imageloại! Danh sách IANA dường như phục vụ cho các định dạng jpeg dành riêng cho công ty (ví dụ vnd.sealedmedia.softseal.jpg).

Do những nhầm lẫn trước đó, rất khó tìm thấy một tài liệu kinh điển được ngành công nghiệp chấp nhận để ánh xạ các phần mở rộng tên tệp thành các loại MIME, đặc biệt là Định dạng tệp hình ảnh JPEG.



Câu hỏi liên quan " Danh sách TẤT CẢ MimeTypes trên hành tinh, được ánh xạ tới Phần mở rộng tệp? ".


thông thường chỉ có MỘT nguồn mô tả tiêu chuẩn liên quan, không phải 4 (!). RFC là một điểm vào tốt!
simUser

4

Điều quan trọng cần lưu ý ở đây là loại mime không giống với phần mở rộng tập tin. Đôi khi, tuy nhiên, chúng có cùng giá trị.

https://www.iana.org/assignments/media-types/media-types.xhtml bao gồm danh sách các loại Mime đã đăng ký, mặc dù không có gì ngăn bạn tự trang điểm, miễn là bạn ở cả hai lần gửi và kết thúc nhận được. Đây là nơi Microsoft đi vào hình ảnh.

Trường hợp có nhiều nhầm lẫn là thực tế là các hệ điều hành có cách nhận dạng các loại tệp riêng bằng cách sử dụng phần đuôi của tên tệp, được gọi là phần mở rộng. Trong các hệ điều hành hiện đại, toàn bộ tên là một chuỗi dài, nhưng trong các hệ điều hành nguyên thủy hơn, nó được coi là một thuộc tính riêng biệt.

Hệ điều hành gây nhầm lẫn là MSDOS, đã giới hạn phần mở rộng chỉ còn 3 ký tự. Hạn chế này được kế thừa cho đến ngày nay trong các thiết bị, chẳng hạn như thẻ SD, vẫn lưu trữ dữ liệu theo cùng một cách.

Một tác dụng phụ của giới hạn này là một số phần mở rộng tệp, chẳng hạn như .gifLoại Mime của chúng image/gif, trong khi các phần mở rộng khác bị xâm phạm. Điều này bao gồm image/jpegphần mở rộng được rút ngắn thành .jpg. Ngay cả trong Windows hiện đại, nơi giới hạn được dỡ bỏ, Microsoft không bao giờ để quá khứ trôi qua, và vì vậy phần mở rộng tệp vẫn là phiên bản rút gọn.

Cho rằng:

  1. Phần mở rộng tệp không phải là loại tệp
  2. Trong lịch sử, một số hệ điều hành có giới hạn tên tệp nghiêm trọng
  3. Một số hệ điều hành sẽ tiếp tục và tạo ra các quy tắc riêng của chúng

Câu trả lời ngắn gọn là:

  • Về mặt kỹ thuật, không có thứ gì như image/jpgvậy, vì vậy câu trả lời là nó không giống nhưimage/jpeg
  • Điều đó sẽ không ngăn một số hệ điều hành và phần mềm xử lý nó như thể nó giống nhau

Trong khi chúng tôi ở đó

Các phiên bản kế thừa của Internet Explorer có quyền tự do tải lên jpegcác tệp với Loại Mime image/pjpeg, tất nhiên, điều đó có nghĩa là nhiều công việc hơn cho mọi người khác. Họ cũng tải lên pngcác tập tin như image/x-png.


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.