RestSharp中Content-Type头boundary加引号的规范与兼容性问题

该报错的核心是HTTP头参数的生成、解析逻辑不匹配，其中第三方服务端的实现不符合HTTP规范：

• 按照HTTP 1.1的媒体类型定义规则，Content-Type头的参数（包括boundary）支持两种值格式：普通token字符可以直接书写，包含特殊字符时必须用双引号包裹为quoted-string格式。两种格式均为规范允许的合法写法，合规的解析端必须能自动识别引号包裹的格式，去掉外层引号后拿到真实参数值。RestSharp自动给boundary值加双引号的行为本身符合规范要求。
• 第三方服务端的multipart解析逻辑存在缺陷：它没有适配引号包裹的参数值格式，直接把"38b14895-fd44-4acc-8287-9f0378691da2"（包含两侧双引号）当成真实boundary值，尝试在请求体中匹配--"38b14895-fd44-4acc-8287-9f0378691da2"作为分隔符，但实际请求体里的分隔符是不带引号的--38b14895-fd44-4acc-8287-9f0378691da2，因此抛出找不到boundary的错误。
  另外代码中手动调用AddHeader强行设置Content-Type: multipart/form-data的写法，触发了RestSharp的引号拼接逻辑：这行代码会覆盖RestSharp检测到文件上传时自动生成Content-Type头的默认逻辑，后续框架自动补充boundary参数时会走通用头参数拼接流程，默认给参数值加上双引号。

不需要修改第三方服务逻辑，也不需要改动RestSharp的底层规则，调整请求构造逻辑即可绕开问题：

• 优先方案：删除手动添加Content-Type头的代码行。移除request.AddHeader( "Content-Type", "multipart/form-data" );后，RestSharp会自动识别到请求包含文件，走multipart请求的专用生成逻辑，自动生成和请求体分隔符完全匹配的Content-Type头，默认生成的boundary不会带双引号，可以直接适配存在解析缺陷的第三方服务。
• 备选方案：如果删除手动添加的头之后框架仍然自动给boundary加引号，可以手动指定固定boundary绕开自动拼接逻辑：自行生成一个不含特殊字符的boundary字符串（例如UUID），关闭RestSharp自动生成boundary的配置，直接写死完整的Content-Type头，同时指定请求体使用自定义的boundary生成分隔符，保证头里的boundary值不带引号、和请求体中的分隔符完全一致即可。

HTTP规范明确允许在请求头的参数值中使用带双引号的quoted-string转义格式，用于承载包含空格、特殊符号的参数值，所有合规的HTTP实现都必须支持该格式的解析，自动去除外层包裹的双引号、正确处理值内的转义字符。该问题的本质是第三方服务端的解析实现没有覆盖规范要求的合法格式，不属于请求构造的合规性问题。

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