DOCX, PPTX, XLSX 및 EPUB은 모두 동일한 매직 바이트로 시작한다 — 자동 감지는 ZIP에게 물어보는 것을 의미한다

제가 범용 문서 변환기에 자동 감지 기능을 추가했을 때, 파일 확장자와 Content-Type 헤더가 모든 것을 책임질 것이라고 생각했습니다. 하지만 둘 다 첫 주 안에 저를 속였습니다.

contract.pdf라는 이름의 계약서가 도착했습니다. 확장자는 PDF였고, 상위(upstream) 헤더는 application/pdf였습니다. 제 PDF 파서는 바이트 0에서 작동을 멈췄습니다. 실제로는 DOCX 파일이었기 때문입니다. 누군가가 내보낸 파일을 이름을 변경했고, 배송 체인의 프록시가 파일 이름에 기반하여 헤더를 찍어 놓은 것입니다. 외부적으로 보이는 것과 내부의 내용물 사이에 일치하는 것이 아무것도 없었습니다.

매직 바이트(Magic bytes)가 명백한 해결책처럼 보였고, PDF는 %PDF로 선언되어 있어 그 부분은 즉시 작동했습니다. 그러다가 불편한 사실이 드러났습니다: DOCX, PPTX, XLSX, 그리고 EPUB은 모두 ZIP 아카이브라는 것입니다. 이들은 정확히 동일한 PK̄̈ 시그니처를 공유합니다—하나의 매직 넘버가 네 가지 포맷을 담고 있습니다.

구별(disambiguation)은 컨테이너 안에 존재합니다:

• EPUB은 첫 번째 항목으로 mimetype이라는 이름의 파일을 압축되지 않은 상태로 저장하는 것이 필수이며, 이 파일에는 application/epub+zip이 포함되어야 합니다. 두 번 읽기만 하면 끝납니다.
• Office 포맷들은 아카이브 루트에 [Content_Types].xml을 가지고 있습니다. 선언된 경로를 살펴보세요: word/는 DOCX를, ppt/는 PPTX를, xl/은 XLSX를 의미합니다.

순수 HTML과 텍스트가 가장 까다로운 경우입니다—물어볼 컨테이너가 없기 때문에, 이들은 잘못 추측하는 대신 명확하게 실패하는 보수적인 휴리스틱(heuristics)으로 대체됩니다.

제게 남은 두 가지 교훈이 있습니다. 첫째: 파일 이름은 절대 신뢰하지 말고, 헤더는 절반만 신뢰하세요—프록시가 어느 한쪽을 다른 쪽으로 기꺼이

이 모든 것을 https://x402.freeq.one/tools/document_to_markdown.html의 하나의 자동 감지 엔드포인트로 패키징했습니다 — 바이트 또는 URL을 입력하면, 감지된 형식을 처리하고 마크다운(Markdown)을 출력하며, 다섯 개의 별도 변환기 간에 분배하는 대신 처리합니다.