今天在做一個文件上傳的功能的時候，發現我總是上傳不了png的圖片。經過調試發現，應該是在ContentType的地方判斷失誤了。後來百度了一下發現一個有意思的現象，我發現png的圖片的ContentType並不是我在註冊表中看到的image/png，而是image/x-png。也因此造成了上傳不了png文件的原因(後來看了資料才知道我找錯了註冊表的位置)。經過自己測試，得出的結果如下：
|
|
IE6 |
IE 8.0 |
Chrome |
Firefox |
|
png |
image/x-png |
image/x-png |
image/png |
image/png |
|
jpg |
image/pjpeg |
image/jpeg |
image/jpeg |
image/jpeg |
|
jpeg |
image/pjpeg |
image/pjpeg |
image/jpeg |
image/jpeg |
|
bmp |
image/bmp |
image/bmp |
image/bmp |
image/bmp |
相比較而言，Chrome和FireFox的反映出的ContentType算是比較符合真實的答案的。那麼，爲什麼會有這些差異呢?
- 首先來說一下MIME類型:
MIME類型就是設定某種擴展名的文件用一種應用程序來打開的方式類型，當該擴展名文件被訪問的時候，瀏覽器會自動使用指定應用程序來打開。多用於指定一些客戶端自定義的文件名，以及一些媒體文件打開方式。
MIME的英文全稱是"Multipurpose Internet Mail Extensions" 多功能Internet 郵件擴充服務，它是一種多用途網際郵件擴充協議，在1992年最早應用於電子郵件系統，但後來也應用到瀏覽器。服務器會將它們發送的多媒體數據的類型告訴瀏覽器，而通知手段就是說明該多媒體數據的MIME類型，從而讓瀏覽器知道接收到的信息哪些是MP3文件，哪些是Shockwave文件等等。服務器將MIME標誌符放入傳送的數據中來告訴瀏覽器使用哪種插件讀取相關文件。
MIME能夠支持非ASCII字符、二進制格式附件等多種格式的郵件消息。這個標準被定義在; RFC 2045，; RFC 2046，; RFC 2047，; RFC 2048，; RFC 2049等RFC中。 由RFC 822轉變而來的RFC 2822，規定電子郵件標準並不允許在郵件消息中使用7位ASCII字符集以外的字符。正因如此，一些非英語字符消息和二進制文件，圖像，聲音等非文字消息都不能在電子郵件中傳輸。MIME規定了用於表示各種各樣的數據類型的符號化方法。
瀏覽器接收到文件後，會進入插件系統進行查找，查找出哪種插件可以識別讀取接收到的文件。如果瀏覽器不清楚調用哪種插件系統，它可能會告訴用戶缺少某插件，或者直接選擇某現有插件來試圖讀取接收到的文件，後者可能會導致系統的崩潰。傳輸的信息中缺少MIME標識可能導致的情況很難估計，因爲某些計算機系統可能不會出現什麼故障，但某些計算機可能就會因此而崩潰。
在把輸出結果傳送到瀏覽器上的時候，瀏覽器必須啓動適當的應用程序來處理這個輸出文檔。這可以通過多種類型MIME（多功能網際郵件擴充協議）來完成。在HTTP中，MIME類型被定義在Content-Type header中。
例如，假設你要傳送一個Microsoft Excel文件到客戶端。那麼這時的MIME類型就是“application/vnd.ms-excel”。在大多數實際情況中，這個文件然後將傳送給Execl來處理（假設我們設定Excel爲處理特殊MIME類型的應用程序）。在ASP中，設定MIME類型的方法是通過Response對象的ContentType屬性。
- IE中對MIME類型的解析:
在Microsoft Internet Explorer 4.0及更高版本，MIME類型確定發生在通過URL Moniker的 FindMimeFromData 方法。 確定的MIME類型允許URL名字對象和其他組件來查找並啓動正確的對象服務器或應用程序來處理相關的內容。
The server-supplied MIME type, if available
An examination of the actual contents associated with a downloaded URL
The file name associated with the downloaded content (assumed to be derived from the associated URL)
Registry settings (file name extension/MIME type associations or registered applications) in effect during the download
Registry Locations
Location used by FindMimeFromData to find MIME type and progID from file name extension:
HKEY_CLASSES_ROOT\.***
Location used by FindMimeFromData to find application from progID:
HKEY_CLASSES_ROOT\<ProgId>\shell\open\command
Location used by URL monikers to find CLSIDs from MIME types:
HKEY_CLASSES_ROOT\MIME\Database\Content Type
The purpose of MIME type detection, or data sniffing, is to determine the MIME type (also known as content type or media type) of downloaded content using information from the following four sources:
關於具體的資料可以參考MSDN的文檔：
http://msdn.microsoft.com/zh-cn/library/ms775147(v=VS.85).aspx中關於MIME類型的檢測算法、和FindMimeFromData函數以及Uploaded MIME Types章節的內容。
- 爲什麼image/x-png前面有個x-:
Internet中有一個專門組織IANA來確認標準的MIME類型，但Internet發展的太快，很多應用程序等不及IANA來確認他們使用的MIME類型爲標準類型。因此他們使用在類別中以x-開頭的方法標識這個類別還沒有成爲標準，例如：x-gzip，x-tar等。事實上這些類型運用的很廣泛，已經成爲了事實標準。只要客戶機和服務器共同承認這個MIME類型，即使它是不標準的類型也沒有關係，客戶程序就能根據MIME類型，採用具體的處理手段來處理數據。而Web服務器和瀏覽器（包括操作系統）中，缺省都設置了標準的和常見的MIME類型，只有對於不常見的 MIME類型，才需要同時設置服務器和客戶瀏覽器，以進行識別。
這裏有一個關於image/x-png的討論
http://stackoverflow.com/questions/2086374/what-is-the-difference-between-image-png-and-image-x-png.
