Ако изпращате поща, често е необходимо да се включи в писмото друго писмо. За да направите това, както и да използвате тип "съобщение".
Основната подтип - "Rfc822" - не изисква настройки в Content-Type. Допълнителни подтипове - "частично" и "Външно тяло" - предполагат, настройките за присъствие.
"Съобщение / Rfc822" Основната подтип
Този подтип показва, че тялото на съобщението съдържа прикачен файл в стандартния RFC 822, обаче, за разлика от по-горен слой RFC 822 хедър за всяко парче, което е писмо RFC 822, не изисква поле "От", "Тема", а в поне един от полето "До".
Въпреки използването на "822", тялото като подтип на "съобщение / Rfc822", може да включва допълнителна информация в съответствие с MIME стандарт. С други думи, като "послание / Rfc822" може да бъде MIME-мейл.
Подтип "съобщение / частично"
Този подтип е определен, за да се даде възможност на прехвърляне на много големи обекти под формата на няколко отделни части, avtomatichski "залепени" програма за електронна поща на получателя. Този механизъм може да бъде полезно, когато вратите на междинните поща ограничават размера на индивидуални имейли, изпратени. по този начин този подтип се посочва, че писмото съдържа само част от по-голям съобщение.
За да направите това, трябва да укажете подтипа на три параметъра:
- "Id" - уникален идентификатор, който позволява да се открият останалата част от съобщението.
- "Number" - цяло число, което показва броя на съобщенията.
- "Общо" - цяло число, което представлява общия брой части. Тя изисква само в последната част, и не е необходимо (въпреки че се препоръчва) за предходните части. Тези параметри могат да бъдат в произволен ред.
Пример: Част 2 3 глава лично съобщение има следните възможности:
Но част 3 трябва да съдържа параметър "общото":
Трябва да се отбележи, че numiratsiya често започва с една, а не 0.
Когато по този начин счупените части се събират заедно, те формират пълен MIME-писмо, съдържанието на които могат да бъдат от всякакъв друг вид, а следователно и неговата заглавната част Content-Type, който описва този тип.
Семантика частичен писмо трябва да са същите като при нормално писмо със съдържанието на този тип, а не като писмо, съдържащо "вътрешен" имейл. Това позволява, например, за да изпратите голям аудио файл vvide няколко по-малки, оставайки обаче видимо за получателя като нормални аудио букви, а не като под-аудио букви.
Когато "сглобяването" на тези съобщения на летището за местоназначение трябва да бъдат взети под внимание следните правила:
(1) Всички хедърите на част 1, с изключение като се започне с "към съдържанието" и специалната "Message-ID", "Encrypted" и "MIME-Version" трябва да бъде копиран в заглавната част на новите (общо) букви.
(2) Само хедърите вложени букви, започващи с "към съдържанието", както и полето "Message-ID", "Encrypted" и "MIME-Version", трябва да се добавят към заглавието на нови общи писма, всички други области трябва да бъдат игнорирани.
(3) Заглавията на втория и следващите части изцяло игнорирани.
Например, ако писмото с аудио данни е разделен на две части, като първата от тях може да изглежда така:
Вторият може да изглежда така:
След разделен съобщение пресъздадени за показване на получателя, той трябва да изглежда така:
Коментари по кодиране тяло MIME-писмо, сключени в рамките на съобщение / частично тяло: като тип данни "съобщение" може никога да не бъде кодиран в Base64 или Цитиран-печат, може да се появи следния проблем, ако съобщение / частично типа на буквите на тялото, създадени в система, която поддържа 8-битов транспорт. Двоични данни ще бъдат разбити в множество съобщения / частично-обекти, всеки от които се изискват транспорт в двоичен вид. Ако тези обекти е трябвало да премине през врата към транспортната среда 7-битов, те не биха могли да бъдат рекодират seimbitnuyu форма, без да чака пристигането на всички части на съобщението, като ги събират заедно, а след това кодирането на съобщението в 7-битово кодиране (Base64 или цитира-печат) , Posklku има възможност, че различните части ще бъдат използвани по различни начини (чрез различни портали), след такова решение не е приемливо. Затова MIME определя този тип писане на съобщение / частично трябва да има 7-битов набор от символи и съответната стойност на полето съдържание пренасяща кодиране. Дори и системи с транспорта поддържа "8-битови" и "двоичен", забранява използването му за съобщения / частични данни.
Много поща агенти може автоматично да водят до фрагментиране на големи съобщения.
Включването на полето "Литература" в заглавията на втория и следващите части, отнасящи се до идентификацията на предишния раздел, може да е полезно да се програми за електронна поща, разбиране и обработка на връзки. Въпреки това, не е необходимо присъствието на тази област.
хедър поле "Encrypted" отпаднал от употреба,, но по-горе правила гарантират правилното тълкуване на това, ако това се случи при обработката на фрагменти частични тип на съобщението /.
Подтип "Message / Външно-Body"
Letter (написването част) на този подтип се състои от глава, краищата на две последователни редове и заглавката вложени съобщение. Ако сте намерили друг чифт за край на ред, това означава края на заглавието на вградения съобщение. Въпреки това, тъй като тялото е извън затвореното писмото, от това не следва края на заглавната си част. Например,
Районът в края, което може да се нарече "фантом тяло", се игнорира за повечето подтипове на външния тяло "букви. Въпреки това е възможно да се постави допълнителна информация, като например в случая, когато параметъра "достъп тип" е "мейл-сървър". Във всички останали случаи, фантомното тяло се игнорира.
Единствената задължителна параметър е винаги да се "съобщение / външно тяло" - "достъп тип". Други параметри може или не може да се изисква в зависимост от стойността "достъп тип".
Стойността на този параметър - с една дума, главни и малки букви, което означава механизъм за достъп, чрез който могат да бъдат получени на файл или данни. Стойностите могат да бъдат следните (но не само в близост до): "FTP", "ANON-FTP", "TFTP", "AFS", "МЕСТЕН-FILE" и "MAIL-сървър". Възможни бъдещи стойности, но експериментално, като се започне с "Х", трябва да бъдат регистрирани в IANA.
В допълнение, следните три параметри не са задължителни за всички методи за достъп:
EXPIRATION - дата (RFC 822 "дата време" синтаксис позволява 4 цифри в тази област), след което съществуването на външни данни не е гарантирана.
РАЗМЕР - размер (в байтове) на данни. Тя позволява на получателя да реши дали да изразходват ресурси, за да се чете външни данни. Размер е показан за каноничните форми на данни (т.е. преди прилагането на промените).
РАЗРЕШЕНИЕ - нечувствително поле, което казва, че се очаква или не, че клиентът може да пренапише данни. По подразбиране, или когато е настроен да "четат", се приема, че клиентът няма право да го прави, и че ако данните се чел, толкова повече те не се нуждаят. Ако имате разрешение е настроен на "четене и запис", който и да е локално копие може да се разглежда не повече от кеш. "Прочетете" и "пиша" - единствените предварително зададени стойности за разрешение.
Вложените заглавията във всички тела тип поле съобщение / външно тяло ТРЯБВА да включват Content-ID с глава, за да посочите уникален идентификатор показателно за външните данни.
Означението, описващ типа данни външно тяло, като например имена на файлове или команда мейл-сървър трябва да е в набора от символи на US-ASCII.
Що се отнася до вида на съобщение / частично, тип тяло съобщение / външно тяло трябва да има стойност на съдържание трансфер кодиращи "7-битов" (по подразбиране). По-специално, дори и в системите за podderzhiavyuschih 8-битов транспорт, прилагане на съдържание трансфер кодиращи "8-битов" и данни / външно тяло "двоичен" забранена тип съобщения.
Видове "FTP" достъп и "TFTP"
Тип на достъп чрез FTP или TFTP показва, че тялото на съобщението се предлага като външен файл FTP чрез съответно [RFC-959] или TFTP [RFC-783]. Следните допълнителни параметри са задължителни за тези видове достъп:
ИМЕ - име на файла, съдържащ данните за тялото съобщение.
Преди да започнете да четете данните чрез FTP, потребителят обикновено трябва да се попита за вашето потребителско име и парола за машината, посочена в опцията "сайт". От съображения за безопасност, така и паролата не са определени като параметър Content-Type и трябва да бъде получена от получателя на съобщението.
Следните допълнителни параметри се определят по-нататък:
Directory - указател, съдържащ текста на съобщението на отдалечената машина.
MODE - нечувствително поредица от букви, указващи режима на данни. Приемливо enacheniya за вид достъп TFTP:
NETASCII, OCTET и поща. За FTP видове достъп: ASCII, EBCDIC, изображението и LOCALn, където п - знак число, обикновено 8. Тези стойности съответстват на видовете представителни А, Е, I и LN. някои FTP протокол. Имайте предвид, че "двоичен" и "TENEX" не са валидни стойности за параметъра MODE. Вместо това, те трябва да се използва "OCTET", "образ" или "LOCAL8". Ако параметърът MODE отсъства, стойността по подразбиране е "NETASCII" за ППФТ и "ASCII" за FTP.
Метод dosupa "Anon-FTP"
Методи за достъп "на местно файлове" и "AFS"
Начин за достъп до "местен-файл" означава, че тялото на писмото е достъпно като файл на локалната машина. "AFS" означава, че тялото е на разположение като файл в глобалната файловата система AFS. И в двата случая, единствената задължителна параметъра:
ИМЕ - име на файла, съдържащ данните за тялото съобщение.
Метод за достъп "мейл-сървър"
Той се използва, когато тялото на писмото е достъпна чрез сървър за електронна поща. Изисква се за този метод на достъп:
Тъй като сървърите за електронна поща изисква разнообразие от различни синтаксиса, някои от които могат да бъдат няколко реда, пълен команда, за да бъде изпратена на пощата сървъра не е включена като параметър в един ред поле "тип на съдържанието". Вместо това, той се поставя в един въображаем тяло, когато стойността на полето "тип съдържание" а "съобщение / външно тяло" и параметъра "достъп-tyoe" е на стойност "мейл-сървър".
Като опция се предлага параметър за този метод за достъп:
MIME стандарт не определя позоваването синтаксис на сървъра за електронна поща. Поради това дава възможност за включване на пълен отбор за мейл-сървър в един въображаем тяло.
За разлика от другите методи за достъп, достъп чрез мейл-сървър не е в синхрон, а данните могат да бъдат получени по непредсказуем момент в бъдещето. Поради тази причина е важно да разполагат с механизъм за вкарване на данни, получени от пощата сървъра към оригиналното писмо. Mail-сървър при изпращане на исканите данни трябва да използвате една и съща стойност на полето Content-ID в заглавката на съобщението с върнатите данни, която е в оригиналната "безплътен", писмото за да се улесни работата на този механизъм.
Примери и допълнителни обяснения
Ако външното тяло на буквата е на разположение от няколко различни механизми, подателят може да включва множество части от тип тип съобщение / външно тяло в писмо съставното / алтернатива.
Горен и общите инвестиции (им) букви (с външното тяло) трябва да отговарят на същите изисквания, както за вида на съобщение / частично, за да се избегне объркване.
От външното тяло не се изпраща под формата на мейл, той не е длъжен да отговаря на изискванията на дължината на линиите и имат форма на 7-битов, тя може да бъде само двоичен файл. Ето защо, област Content-Transfer-Encoding не е необходимо, въпреки че се допуска присъствието си.
писмо тип "съобщение / външно тяло" тяло обработва в прагове и казахме на стандартния RFC 822, по-специално, всичко, което отива на първо последователно двойката линия завършваща (CRLF), заглавката, и всичко, което идва след " въображаем "тялото на писмото, което се игнорира в повечето видове достъп.
"Content-Type" тип "съобщение" Официално удар с глава на данни поле синтаксис - следното:
Свързани статии