HTTP头中为何众多Content-Type被归类为application类型？

MIME类型的顶层分类是按照内容的处理逻辑划分的，application大类的核心定义是：无法被通用的文本、音频、视频、图像类基础程序直接处理，必须依赖特定应用程序/解析模块识别结构化语义、执行对应逻辑才能正常使用的数据，判定和内容本身是文本形态还是二进制形态没有直接关系。
你列出的这些application/*类型都符合这个核心规则：

• application/java-archive、application/zip：压缩包格式，必须用解压程序处理
• application/EDI-X12、application/EDIFACT：企业电子数据交换的专用结构化报文，需要对应EDI系统解析
• application/javascript：可执行脚本代码，需要JS引擎解析运行
• application/octet-stream：无明确标识的任意二进制流，只能下载后由用户选择对应程序打开
• application/pdf、application/x-shockwave-flash：需要专用阅读器/播放器渲染的文档/多媒体内容
• application/xhtml+xml、application/json、application/ld+json、application/xml、application/x-www-form-urlencoded：结构化数据格式，需要对应解析器提取语义，不能作为普通纯文本直接展示给终端用户

为什么JSON、XML会出现在application分类，甚至XML同时有text/xml条目？ #

首先要明确：text/*分类的判定标准从来不是“内容是文本”，而是内容是无强结构化约束的纯人类可读文本，用最基础的文本编辑器打开就能直接阅读字面含义，不需要额外解析规则。

• XML的重复条目是历史遗留问题：text/xml是早期未标准化阶段的非正式注册项，本身属于废弃条目，和你列表里标注obsolete的text/javascript性质完全一样，目前正式推荐的XML MIME类型就是application/xml，保留text/xml仅仅是为了兼容几十年前的旧系统实现，不是分类矛盾。
• JSON从来没有正式注册过text/*下的对应类型：JSON从标准化第一天起官方类型就是application/json。它虽然语法基于文本，但本质是给程序做数据交换用的严格结构化格式，普通用户直接打开未格式化的JSON内容根本无法顺畅阅读，完全符合application类的判定标准，不存在分类遗漏。
  补充说明：早年把JavaScript、XML错误放到text分类，本质是互联网早期标准不统一阶段的历史遗留问题，后续标准化过程中都已经修正到application分类下了。

为什么OGG被归入application分类，而不是audio分类？ #

这是格式特性+标准迭代共同导致的：
OGG本身不是纯音频格式，是可以同时封装音频、视频、字幕、元数据的通用多媒体容器。最早注册MIME类型的时候，还没有针对容器内不同媒体类型做细分，就统一给了application/ogg类型，指代需要OGG解析器处理的通用容器文件。
后续标准迭代才补充了更细分的专用类型：audio/ogg专门指代仅包含音频流的OGG文件，video/ogg专门指代包含视频流的OGG文件。现在application/ogg已经是兜底类型，只有服务端无法判断OGG容器内封装的具体内容类型时才会使用，不属于分类错误。

内容的提问来源于stack exchange，提问作者Oscar