MIME / Content-Type 참조

MIME 타입 참조란?#

MIME 타입(미디어 타입 또는 Content-Type이라고도 함)은 문서가 어떤 종류의 바이트를 담고 있는지 수신자에게 알려주는 짧은 라벨입니다. text/html은 웹 페이지, application/json은 JSON 데이터, image/png는 PNG 그림. 형식은 항상 type/subtype입니다. 넓은 카테고리, 슬래시, 그 다음 구체적 이름. HTTP는 이 라벨에 의존해 응답을 렌더링할지, 다운로드할지, 파싱할지, 거부할지 결정하고, 브라우저는 올바른 핸들러를 고르기 위해 의존합니다(<img>는 이미지 타입을, <script>는 JavaScript 타입을 기대). 이메일은 파일 첨부를 위해 의존합니다.

형식은 단순해 보이지만 실제 환경은 진짜로 혼란스럽습니다. 일곱 개의 최상위 카테고리(application, audio, font, image, model, text, video)가 있고, 많은 파일이 여러 확장자와 매칭됩니다(.jpg, .jpeg, .jpe는 모두 image/jpeg). 어떤 타입은 옛 형태와 현대 형태가 있고(application/javascript 대 text/javascript), 잘못 고르면 실제 버그가 생깁니다. text/plain으로 서빙된 스타일시트는 적용되지 않고 application/octet-stream으로 서빙된 글꼴은 로드되지 않습니다. 이 페이지는 항상 올바른 라벨을 고르기 위한 검색 가능한 조회표입니다.

사용 방법#

1. 무엇이든 검색하세요. 검색 상자가 전체 표를 필터링합니다. 세 가지 질의 방식이 있습니다.
   • 파일 확장자를 앞에 점과 함께 입력 — .jpg, .woff2, .mp4 — 하면 해당 확장자에 매핑된 타입만 정확히 나옵니다.
   • 타입 또는 서브타입 자체를 입력 — image, json, svg — 하면 이름으로 좁혀집니다.
   • 단어를 입력 — archive, font, spreadsheet — 하면 설명을 검색합니다.
2. 행을 읽으세요. 열은 Content-Type(전체 type/subtype), 확장자(매핑되는 일반적 파일 접미사), 카테고리(일곱 최상위 그룹 중 하나), 설명(그 타입의 용도에 대한 한 줄 메모)입니다.
3. 올바른 것을 고르세요. 어떤 확장자에는 보통 하나의 정규 타입이 있고, 두 개가 존재하는 곳에서는(JavaScript가 고전적 사례) 설명이 어느 것이 최신인지 알려줍니다.

주요 특징#

• 일곱 카테고리, 하나의 표. application, audio, font, image, model, text, video 타입이 함께 있어, 페이지를 바꾸지 않고 글꼴 질문에서 비디오 질문으로 건너뛸 수 있습니다.
• 확장자 우선 조회. 일반적인 실제 작업은 “.xlsx 파일이 있는데 Content-Type을 뭘로 설정하지?”입니다. .xlsx를 입력하면 application/vnd.openxmlformats-officedocument.spreadsheetml.sheet로 바로 갑니다.
• 현대 이름과 구형 이름 모두. 야생에서 여전히 보이는 옛 형태의 타입은 메모와 함께 둘 다 나열되어, HTTP 헤더의 어느 방향이든 인식할 수 있습니다.
• 벤더 타입 포함. Microsoft Office, ZIP, gzip, 7z, RAR, WebAssembly, Web App Manifest, GraphQL. 긴 application/vnd.*와 application/*+json/application/*+xml 형태가 모두 있습니다.
• 로컬이고 즉시. 데이터셋이 페이지에 임베드되고, 모든 검색은 요청 없는 클라이언트 측 필터입니다.

실제 예시#

JavaScript는 가장 혼란스러운 항목입니다. 타입이 몇 년에 걸쳐 이름이 바뀌었고 서버가 여전히 둘 다 보내기 때문입니다. javascript를 검색하면 두 행이 나옵니다.

• text/javascript — js, mjs — “표준 현대 MIME 타입.”
• application/javascript — js — “구형 JavaScript MIME 타입(여전히 널리 보임).”

짧은 버전: text/javascript가 현재 HTML과 Fetch 표준이 쓰라고 하는 것이자 현대 서버가 내보내는 것이고, application/javascript는 오래된 Content-Type 헤더와 오래된 문서에서 여전히 볼 옛 RFC 4329 이름입니다. 둘은 같은 것을 의미하고 브라우저는 동일하게 취급하지만, 새 서버 설정에서는 text/javascript를 선호하세요.

기억해 두면 좋은 조회 몇 가지, 모두 검색 한 번이면 됩니다.

• .json → application/json
• .svg → image/svg+xml (이미지이지만 +xml 접미사가 XML 기반임을 표시)
• .woff2 → font/woff2 (application/이 아닌 전용 font/ 최상위 카테고리)
• .wasm → application/wasm (WebAssembly 이진 — charset 없이 정확히 이렇게 서빙해야 컴파일됨)
• .pdf → application/pdf

타입을 모를 때 서버는 **application/octet-stream**으로 떨어집니다. “이건 이진 데이터야, 아무것도 가정하지 마”라는 범용 타입입니다. 브라우저는 보통 표시를 시도하는 대신 파일을 다운로드합니다.

FAQ#

text/javascript와 application/javascript 중 어느 것을 쓰나요?#

새 코드에서는 text/javascript를 보내세요. 현재 WHATWG HTML과 Fetch 명세가 요구하는 것이자, 브라우저가 <script>를 실행할지 결정할 때 실제로 검사하는 것입니다. application/javascript도 어디서나 작동하지만(오래된 표준) 구형 형태입니다. 새 서버, MIME 데이터베이스, 빌드 도구를 구성할 때는 text/javascript를 기본으로 하세요.

왜 SVG 타입에 +xml이 있나요?#

+xml 접미사는 구조화된 문법 접미사입니다. 그 타입의 직렬화가 이면에 XML임을 알려줍니다. 그래서 image/svg+xml은 “이미지, 구체적으로 XML로 기술된 것”을 뜻합니다. 같은 관행이 application/ld+json(링크드 데이터, JSON으로 직렬화)과 application/graphql+json에도 나타납니다. 접미사를 이해하는 도구는 범용 XML이나 JSON 파서로 폴백할 수 있습니다.

application/octet-stream은 뭘 위한 건가요?#

“임의의 이진 데이터, 타입 알 수 없음”을 위한 포괄 타입입니다. 서버가 파일을 식별할 수 없을 때 반환하고, 안전한 클라이언트 동작은 렌더링이나 실행을 시도하는 대신 다운로드하는 것입니다. 브라우저에서 열릴 줄 알았던 파일이 다운로드되기 시작한다면, 잘못되거나 빠진 Content-Type이(octet-stream으로 뭉개지는)가 흔한 원인입니다.

파일의 Content-Type은 실제로 어떻게 설정하나요?#

그것은 파일이 어디서 서빙되는지에 달렸습니다. 정적 파일 서버는 MIME 데이터베이스를 통해 확장자에서 읽고, 웹 프레임워크는 코드에서 설정하며(보통 response.setContentType(...) 또는 헤더 할당), CDN은 업로드나 객체 메타데이터에서 노출합니다. 정확한 호출은 스택마다 다릅니다. 맞아야 하는 유일한 것은 회선 위의 최종 문자열이며, 그것이 바로 이 조회가 주는 것입니다.