Я посмотрел @rfc 2231 и 2183. Работа с многопользовательской полезной нагрузкой.RFC для заголовка контента?
Я пытаюсь дешифровать, если следующее синтаксически правильно, в частности, атрибут «start» для первого Content-Type, но я не смог найти правильный 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 и т. д.), который сообщает сотовым устройствам, что завернутый файл должен считаться защищенной полезной нагрузкой, а не позволять ему пересылаться или переноситься телефон в любом случае. Если бы не контрактные обязательства, я бы просто разорвал упаковку, отправлю полезную нагрузку и был бы счастлив, но это слишком легко и, вероятно, незаконно.