Skip to main content

모질라가 MIME 형식을 결정하는 방식

How Mozilla determines MIME Types

작성자 : Christian Biesinger <cbiesinger@web.de>

소개

Introduction

모질라에서 모든 데이타 처리는 내용의 MIME 형식에 근거합니다. url을 불러들일 때마다 모질라는 MIME 형식을 찾아내야 한다는 의미입니다. 이 방식에 대해 이 문서에서 설명하고 있습니다.

All data handling in Mozilla is based on the MIME type of the content. This means that every time an url is loaded, Mozilla must find out its MIME type. The several ways how this happens are described in this document.

내용-형식 "암시"

Content-Type "hints"

모질라는 "내용-형식 암시"라는 개념을 가지고있습니다. 예를 들어, 모질라가 <link type="text/css" type="stylesheet" href="...">요소를 만나면 text/css 형식으로 받아들이게 됩니다. 그러나 서버가 전송하는 실제 MIME 형식을 보낸다면 이를 무시해버립니다. (이런 특수한 예는, 서버 무시처리는 표준준수 방식의 경우에만 일어납니다. 모질라 쿼크방식 또는 웹개발자 FAQ를 참고하세요). 모질라 1.6 알파버전부터 <a href="..." type="foo/bar">에 대해 비슷한 처리방식이 이루어집니다.

Mozilla has a concept of "content-type hints". This means that, for example, if Mozilla encounters a <link type="text/css" type="stylesheet" href="..."> element, a type of text/css will be assumed. This is, however, overridden by the actual MIME type the server sends (if any). (For this specific example, the server override only happens in standards-compliant mode. See Mozilla's quirks mode or Web developer FAQ).
Similar handling happens for <a href="..." type="foo/bar">, starting in Mozilla 1.6alpha.

HTTP, 메일 첨부파일

HTTP, Mail Attachments

메일 첨부파일뿐만 아니라 HTTP URI에 대해, 모질라는 대개의 경우 서버에서 보낸 MIME 타입을 가져와서 사용합니다. MSIE(MSIE의 MIME 형식 추측에 관한 MSDN 문서자료)와는 달리, 모질라는 일반적으로 해당 문서에서 형식을 알아내지 않습니다. 그러나 모질라 1.7알파부터 모질라는 다음과 같이 내용을 알아내는 작업을 합니다:
서버에서 전송한 내용-형식이 (대소문자구분) text/plain, text/plain; charset=ISO-8859-1 또는 text/plain; charset=iso-8859-17중의 하나이면서, 그리고 해당 서버가 내용-엔코딩 머리말 정보(Content-Encoding header)를 전송하지 않은 경우, 모질라는 데이타의 첫 구역을 알아내어 텍스트가 아닌 바이트를 점검합니다. 텍스트 바이트는 9-13, 27, 그리고 31-255입니다. 텍스트가 아닌 바이를 만날 경우, 도우미 대화창(helper app dialog)에 해당 파일의 확장자에 상응하는 mime-형식을 보여주게 됩니다.

For HTTP URIs, as well as for Mail Attachments, Mozilla usually gets a MIME type sent from the server, and uses it. Contrary to MSIE (MSDN Document on MSIE MIME type guessing), Mozilla will generally not sniff the type of the document. However, starting in Mozilla 1.7alpha, Mozilla does do content sniffing, like this:
When the Content-Type sent by the server is one of (case-sensitively) text/plain, text/plain; charset=ISO-8859-1 or text/plain; charset=iso-8859-1, and the server did not send a Content-Encoding header, Mozilla will sniff the first block of data it gets and check for non-text bytes. Text bytes are 9-13, 27, and 31-255. When encountering a non-text byte, the helper app dialog will be shown, showing the mime-type corresponding to the extension of the file.

또한 <img src>로 불러들인 이미지의 경우, 모질라의 이미지 라이브러리는 이미지의 실제 형식을 찾아내기 위해 컨텐츠를 알아내려 합니다.(이것은 확장자를 알아내는 것이 아님)

Also, for images loaded via <img src>, Mozilla's image library will do content sniffing (never extension sniffing) to find out the real type of the image.

서버가 내용-형식 헤더정보를 전송하지 않으면, 모질라는 MIME 형식을 찾아내기 위해 알려지지않은 해석기를 사용합니다.

If the server did not send a Content-Type header, Mozilla uses the unknown decoder to find a MIME type.

파일 URI

File URIs

파일 URI의 경우 모질라는 MIME 형식에 대해 외부도우미서비스(ExternalHelperAppService)를 요청하게 됩니다.

For file: URIs, Mozilla will ask the ExternalHelperAppService for a MIME type.

FTP

MIME 형식이 없는 HTTP URI의 경우, FTP uri는 알려지지않은 해석기를 거치게 됩니다.

Like HTTP URIs without a MIME type, FTP uris go through the unknown decoder.

알려지지 않은 해석기

Unknown Decoder

netwerk/streamconv/converters/nsUnknownDecoder.cpp를 보면, 287번 행에 흥미로운 부분이 있습니다. sSnifferEntries는 DetermineContentType 함수와 함께 있습니다. 이것이 하는 작업은 다음과 같습니다:

Located at netwerk/streamconv/converters/nsUnknownDecoder.cpp, the interesting part starts at line 287, the sSnifferEntries array together with the DetermineContentType function.
It does the following:

  • 파일의 시작부분에서 "마술의 숫자(magic numbers)"라고 하는 곳을 점검합니다; PDF와 포스트스크립트를 현재 감지할 수 있습니다.
  • 파일이 <?xml 로 시작한다면, uri에 맞는 MIME 형식을 외부도우미서비스(ExternalHelperAppService)에 요청합니다.
  • 내용물이 제공되면 이미지 라이브러리에 MIME 형식을 요청하게 됩니다. 모질라가 지원하는 모든 이미지의 형식을 찾아내는 데 신뢰할만한 기능을 제공합니다.
  • 일부의 공통 HTML 태그를 찾아내어 해당 데이타가 HTML인 지를 점검합니다.
  • MIME 형식 추측을 위해 URI를 외부도우미서비스(ExternalHelperAppService)에 넘깁니다.
  • 이렇게해서도 처리를 하지못하면, 임베디드널(embedded nulls)로 버퍼(예를 들어 해당 파일의 첫 몇 바이트)를 검색하여, 아무것도 없으면 text/plain을 사용하며, 그렇지않으면 application/octer-stream을 사용합니다.

　

  • Checks the start of the file for "magic numbers"; this can currently detect PDF and Postscript.
  • If the file starts with <?xml, asks the ExternalHelperAppService for a MIME type for the uri. This is done because the generic text/xml MIME type does not work for XUL files, and XHTML files get a different DOM when interpreted as text/xml.
  • The Image Library will be asked for the MIME type given the content. This should allow reliable detection of all image types Mozilla supports.
  • Checks whether the data is HTML by looking for some common HTML tags.
  • The URI is handed to the ExternalHelperAppService for MIME type guessing
  • If all else fails, the buffer (i.e. the first few bytes of the file) is searched for embedded nulls; if none are found, text/plain will be used, otherwise application/octet-stream.

외부도우미서비스

ExternalHelperAppService

(uriloader/exthandler/nsExternalHelperAppService.cpp에 있습니다)

파일 -> MIME 형식 매핑 작업은 다음과 같습니다:

The file->MIME type mapping works like this:

  • BeOS에서, 운영시스템에 파일 형식을 요청합니다 (아직 많지는 않지만, 버그(217723)가 존재한다)
  • MacOS에서, OS에서 파일 형식을 찾기위해 형식과 제작자 코드를 사용합니다.
  • 확장자의 하드코딩된 목록을 체크합니다.(현재 13개 엔트리를 가지고있다.http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#299)
  • 확장자가 목록에 없으면, 재미있어지는 데. 먼저 운영시스템에 MIME 형식을 요청합니다. 그도 안되면, 사용자제공도우미(user-supplied helper app)를 확장자로 검색하고, 그래서 지정된 MIME 형식을 사용하게 됩니다. (예를 들어, 편집/환경설정/도우미 프로그램(Edit/Preferences/Helper Applications)
    이것도 안되면, 확장자에 맞을 지 모를 "추가" MIME 형식 목록을 검색합니다. 전체 목록을 보려면 http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#336 를 참고하기 바랍니다.
  • 이것도 안되면, 이 확장자를 처리할 수 있는 플러그인이 있는 플러그인 목록을 점검하여, mime형식을 요청합니다.

　

  • On BeOS, the operating system is asked for the type of the file (not quite yet, bug 217723)
  • On MacOS, the type and creator code will be used to lookup the type of the file from the OS
  • a hardcoded list of extensions is checked (containing currently 13 entries, http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#299)
    (This is done for speed - it is faster to find data in the hardcoded list than asking the OS or looking in preferences)
  • If the extension is not listed there, it becomes interesting. Firstly, the Operating System is asked for a MIME type.
    If that fails, a user-supplied helper app is searched for by extension, and the specified MIME type will be used. (i.e. the list in Edit/Preferences/Helper Applications)
    If that failed, a list of "extra" MIME types is searched for an extension match. See http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#336 for the complete list.
  • If that also failed, the list of loaded plugins is checked for a plugin that can handle this extension, and is asked for the mimetype

도우미 프로그램

Helper Applications

다소는 연관된 문제가 도우미 프로그램입니다. 모질라가 처리할 수 없는 형식의 uri를 불러들일 때, 도우미 프로그램 대화창이 나타나는 데, 표시된 정보는 다음의 자료에서 가져온 것입니다:

A somewhat related issue are the helper applications. When loading an uri with a type that Mozilla can not handle, a helper app dialog shows up, and the displayed information comes from these sources:

  • 주어진 <확장자, mimetype>쌍의 처리자를 OS에 요청합니다. 여기서의 확장자는 내용-처리(Content-Dispotion) 머리말 정보가 있는 경우 이곳에서, 그렇지않은 경우에는 URL 자체에서 가져온 것이라는 점을 염두에 두세요.  이런 곳에서 등록된 "기본프로그램"을 가져오는 것입니다.
  • uri의 MIME 형식을 가진 엔트리를 찾기 위해 "데이타 자료"(즉 도우미 프로그램 목록)를 검색합니다. 결과가 없으면, 데이타 자료를 확장자를 통해서 검색합니다.(위에서 이야기한 내용-처리에서). 이 검색으로 결과가 나오면, 해당하는 프로그램으로 열기(Open with) 필드에, 그리고 해당 형식에 대한 설명이 나오게 됩니다.
  • 이것도 실패하면, 추가로 다시 검색하게 되며, MIME 형식의 확장자-목록과 설명을 제공하게 됩니다.

　

  • Ask the OS for a handler of the given <extension, mimetype> pair. Note that the extension here comes from the Content-Disposition header if present, and from the URL itself otherwise. This is where the listed "default application" comes from.
  • The "data source" (that is, the list of helper applications) is searched for an entry with the MIME type of the uri. If this fails, the data source is searched via the extension (Content-Disposition as above). If one of these lookups succeed, this is where the application in the "Open with" field comes from, and also where the description of the type comes from.
  • If this also failed, the extras are searched again, and will supply the extension-list and a description of the MIME type.