เลขที่
ประเภทเนื้อหาควรเป็นสิ่งที่เป็นที่รู้จักกันถ้าคุณรู้ว่ามัน application/octet-streamถูกกำหนดให้เป็น "ข้อมูลไบนารีโดยพลการ" ใน RFC 2046 และมีการทับซ้อนกันที่นี่ซึ่งเหมาะสมสำหรับเอนทิตีที่มีจุดประสงค์เพียงอย่างเดียวคือการบันทึกลงดิสก์และจากจุดนั้นอยู่นอกเหนือสิ่งใด "webby" หรือมองจากอีกทิศทางหนึ่ง สิ่งเดียวที่สามารถทำได้อย่างปลอดภัยกับ application / octet-stream คือการบันทึกลงไฟล์และหวังว่าคนอื่นจะรู้ว่ามันคืออะไร
คุณสามารถรวมการใช้งานContent-Dispositionกับประเภทเนื้อหาอื่น ๆ เช่นimage/pngหรือแม้กระทั่งtext/htmlเพื่อระบุว่าคุณต้องการประหยัดแทนที่จะแสดง มันเคยเป็นกรณีที่บางเบราว์เซอร์จะไม่สนใจในกรณีของtext/htmlแต่ฉันคิดว่านี่เป็นเวลานานมาแล้ว ณ จุดนี้ (และฉันจะเข้านอนเร็ว ๆ นี้ดังนั้นฉันจะไม่เริ่มทดสอบทั้งกลุ่ม เบราว์เซอร์ในขณะนี้อาจช้า)
RFC 2616 ยังกล่าวถึงความเป็นไปได้ของโทเค็นส่วนขยายและวันนี้เบราว์เซอร์ส่วนใหญ่ยอมรับinlineว่าคุณต้องการให้เอนทิตีแสดงหากเป็นไปได้ (นั่นคือถ้าเป็นเบราว์เซอร์ประเภทที่รู้วิธีแสดงมิฉะนั้นจะไม่มีทางเลือก) . นี่เป็นพฤติกรรมเริ่มต้นแน่นอน แต่หมายความว่าคุณสามารถรวมfilenameส่วนหัวของเบราว์เซอร์ที่จะใช้ (อาจมีการปรับเปลี่ยนบางอย่างดังนั้นส่วนขยายไฟล์ตรงกับบรรทัดฐานของระบบในท้องถิ่นสำหรับประเภทเนื้อหาที่เป็นปัญหาอาจไม่) เป็นข้อเสนอแนะหากผู้ใช้พยายามบันทึก
ดังนั้น:
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="picture.png"
แปลว่า "ฉันไม่รู้ว่ามันคืออะไรโปรดบันทึกมันเป็นไฟล์โดยเฉพาะชื่อ picture.png"
Content-Type: image/png
Content-Disposition: attachment; filename="picture.png"
หมายถึง "นี่คือภาพ PNG โปรดบันทึกเป็นไฟล์โดยควรตั้งชื่อ picture.png"
Content-Type: image/png
Content-Disposition: inline; filename="picture.png"
หมายความว่า "นี่เป็นภาพ PNG โปรดแสดงถ้าคุณไม่ทราบวิธีการแสดงภาพ PNG ไม่เช่นนั้นหรือหากผู้ใช้เลือกที่จะบันทึกเราขอแนะนำชื่อ picture.png สำหรับไฟล์ที่คุณบันทึกเป็น"
ในเบราว์เซอร์เหล่านั้นที่รู้จักinlineบางคนจะใช้มันเสมอในขณะที่คนอื่น ๆ จะใช้มันหากผู้ใช้เลือก "บันทึกลิงค์เป็น" แต่ไม่ใช่ถ้าพวกเขาเลือก "บันทึก" ในขณะที่ดู (หรืออย่างน้อย IE เคยเป็นเช่นนั้น อาจมีการเปลี่ยนแปลงบางปีที่ผ่านมา)