JMeter读取CSV参数发请求报415 Unsupported Media Type如何修复

核心排查逻辑 #

415状态码的本质是服务端无法解析请求体，你核对过请求头和Postman一致仍报错，问题100%出在实际发出的请求内容和你肉眼看到的配置不一致，按以下步骤逐一定位修复即可。

分步修复操作 #

1. 先确认实际发出的请求原文，不要靠肉眼核对配置 #

• 给报错的采样器添加查看结果树监听器，执行请求后切到请求>Raw视图，把完整请求原文和Postman成功请求的「Code>cURL」导出的原始请求逐字符对比，重点核对：
  • 请求体首尾是否存在隐形字符：最常见的是CSV文件带UTF-8 BOM头，JMeter读取变量时会把BOM标记（不可见字符\ufeff）拼在请求体最开头，服务端解析到非法前缀直接判定媒体类型不支持
  • 请求头中Content-Type是否唯一、值是否完全匹配：如果测试计划中线程组、全局配置、单个请求下挂了多个HTTP信息头管理器，JMeter会合并所有头配置，同名头出现值冲突、重复时，会出现你配了application/json但实际发出去是text/plain或者带两个Content-Type头的情况
  • 请求体是否完整：如果CSV字段值包含未转义的逗号、双引号，JMeter读取CSV时会提前截断字段，导致实际发出的JSON/XML结构残缺
• 对应修复：
  • 把CSV文件另存为UTF-8 无BOM格式，CSV数据配置元件中「文件编码」手动填UTF-8，不要留空使用系统默认编码
  • 临时禁用所有上层的HTTP信息头管理器，仅在当前报错采样器下挂载一个HTTP信息头管理器，单独配置Content-Type，确保值和Postman完全一致（包括是否带charset参数，部分服务端会做精确字符串匹配，多一个字符都会报错）
  • 如果发现BOM残留，给采样器添加JSR223预处理程序，用以下脚本清除变量中的BOM字符：

    // 把yourVarName替换成你存储请求体/参数的CSV变量名
    def reqBody = vars.get("yourVarName").replaceAll("^\uFEFF", "")
    vars.put("yourVarName", reqBody)
    

2. 排查采样器基础配置错误 #

• 如果你发的是JSON/XML类非表单请求，请求载荷必须填在HTTP采样器的消息体数据标签页，不能填在「参数」标签页：填在参数页时，哪怕你手动配了Content-Type: application/json，JMeter也会默认按application/x-www-form-urlencoded格式编码请求体，直接触发415
• 检查采样器底部「对POST使用multipart/form-data」的勾选状态，必须和Postman的配置完全一致：只要勾选了这个选项，哪怕你没传文件，JMeter也会自动把Content-Type覆盖为multipart/form-data，手动配置的JSON类Content-Type不会生效
• 如果你配置过「文件上传」标签页，要确认标签页内没有残留的空行、无效文件配置，只要该标签页有内容，JMeter就会自动切换为multipart请求格式

3. 特殊场景兜底修复 #

• 不要直接在请求体中用${__CSVRead()}函数读取CSV参数，该函数不会处理CSV转义规则，很容易拼出格式错误的请求体，统一改用CSV数据配置元件做参数化
• 给请求头补充Accept: */*配置，部分服务端会同时校验Accept头，缺失时会误返回415
• 如果你开启了请求压缩配置，确认Content-Encoding头的值和实际请求体压缩状态一致，不要出现配了gzip头但请求体未压缩、或者压缩了请求体没配对应头的情况

验证方法 #

先把Postman成功的静态请求体、请求头完整复制到JMeter中，不使用参数化直接发请求，确认可以请求成功后，再逐字段替换为CSV读取的变量，每替换一个字段执行一次请求，就能快速定位是哪个字段引入的格式问题。

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