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