3 回答
TA贡献1871条经验 获得超8个赞
如被定义在RFC 1341:
在RFC 822的扩展BNF表示法中,内容类型标头字段值定义如下:
Content-Type:=类型“ /”子类型* [“;” 参数]
类型:=“应用程序” /“音频” /“图像” /“消息” /“多部分” /“文本” /“视频” / x令牌
x-token:= <两个字符“ X-”后面没有任何空格,中间没有空格>
子类型:=令牌
参数:=属性“ =”值
属性:=令牌
值:=令牌/带引号的字符串
令牌:= 1 *
tspecials:=“(” /“)” /“ <” /“>” /“ @”; 必须在/“,” /“;”中 /“:” /“ \” / <“>;引号字符串,/” /“ /” [“ /”]“ /”?“ /”。“;在/” =“中使用;参数值
以及可以跟随它的已知MIME类型的列表(或,如Joe所言,IANA源)。
如您所见,该列表太大了,您无法针对所有列表进行验证。您可以做的是对照常规格式和type属性进行验证,以确保正确(选项集很小),并假设其后的内容正确(并且当然可以捕获放置它时可能遇到的任何异常)实际使用)。
另请注意上面的评论:
如果出于任何原因要使用其他主要类型,则必须给它一个以“ X-”开头的名称,以指示其非标准状态,并避免与将来的正式名称发生任何潜在冲突。
您会注意到,许多HTTP请求/响应都包含X-一些自定义的标头,在验证类型时请记住这一点。
TA贡献1963条经验 获得超6个赞
我的目的是覆盖可能的“内容类型”值的子集,您的问题似乎集中在识别已知的内容类型上。
@Jeroen RFC 1341参考很棒,但是对于一个相当详尽的列表,IANA 在此处保留了一个官方注册媒体类型的网页。
- 3 回答
- 0 关注
- 1036 浏览
相关问题推荐
添加回答
举报