内容类型标头的 RFC？

发布于 2024-07-15 18:23:06 字数 974 浏览 2 评论 0原文

我看过@ rfc 2231 和 2183。处理多部分/相关的 mime 负载。

我试图破译以下内容在语法上是否正确，特别是第一个 Content-Type 的“start”属性，但我无法找到正确的 RFC。

Content-Type: multipart/related; boundary="=_34e1b39f5c290f66360ff510d4c38da4";  type="application/smil"; start="<cid:eaec2c30d892902b14044d57dbb6ff85>"



--=_34e1b39f5c290f66360ff510d4c38da4
Content-ID: <eaec2c30d892902b14044d57dbb6ff85>
Content-Type:  application/vnd.oma.drm.message; boundary=ihvdxymhvdhobklkqbcn;
 name="IrishJi2.dm";
Content-Disposition: attachment;
 filename="IrishJi2.dm";

--ihvdxymhvdhobklkqbcn
Content-Type: audio/mpeg
Content-Transfer-Encoding: binary

一些好奇的背景信息。 application/vnd.oma.drm.* 文件类型只是有效负载项（mp3、jpg 等）的包装器，它告诉蜂窝设备包装的文件将被视为受保护的有效负载，并且不允许其转发或转移无论如何，电话。如果不是出于合同义务，我只会撕掉包装纸，发送有效负载，然后就高兴了，但这太容易了，而且可能是非法的。

原文

I've looked @ rfc 2231 and 2183.
Dealing with a multipart/related mime payload.

I'm trying to decypher if the following is syntactically correct, specifically the "start" attribute for the first Content-Type, but I haven't been able to find the correct RFC.

Content-Type: multipart/related; boundary="=_34e1b39f5c290f66360ff510d4c38da4";  type="application/smil"; start="<cid:eaec2c30d892902b14044d57dbb6ff85>"



--=_34e1b39f5c290f66360ff510d4c38da4
Content-ID: <eaec2c30d892902b14044d57dbb6ff85>
Content-Type:  application/vnd.oma.drm.message; boundary=ihvdxymhvdhobklkqbcn;
 name="IrishJi2.dm";
Content-Disposition: attachment;
 filename="IrishJi2.dm";

--ihvdxymhvdhobklkqbcn
Content-Type: audio/mpeg
Content-Transfer-Encoding: binary

Some background information for the curious. application/vnd.oma.drm.* file types is just a wrapper around a payload item (mp3,jpg, etc) that tells cellular devices the wrapped file is to be considered protected payload and not to allow it to be forwarded or transfered off the phone in anyway. If not for contractual obligations I'd just rip the wrapper off, send the payload on, and be happy, but that is too easy and probably illegal.

分享到QQ

分享到微博