Изпращане на поща със средствата на PHP. Част 3

Първоначално, когато пощата се заражда, никакъв MIME не съществува. Появява се по-късно като разширение към стандарта RFC-822. В настоящият момент всяко изпращано писмо, дори и да не съдържа никакви вложения, така или иначе използува MIME.


5.3 Как да изградим WEB-достъп към пощата

Посетете един от следните ресурси:

http://www.squirrelmail.org/
http://www.horde.org/
Там ще откриете всички необходими скриптове и детайлни инструкции по инсталация и настройка.

6. MIME в разрез

По подробно за MIME можете да прочетете тук http://book.itep.ru/4/4/mime.htm.

Отначало писмото се е възприемало като линейно текстово послание, съдържанието на което може да се прочете, преглеждайки изходният му код. Разширението MIME позволява да се определят вътре в писмото специфични атрибути като: тип на предаваната информация, способа на неговото кодиране и препоръки към възпроизвеждането. Така също позволява да се разбие писмото на независими секции и задаване на индивидуални атрибути за всяка от тях.

За нагледно показване на разликите, разглеждаме два примера, съдържащи едно и също писмо в две различни представяния: обикновено писмо по стандарта RFC-822 и същото писмо, но с използване на MIME
From: "John Coggeshall" <john@zend.com>
To: Joe Users <joe@user.net>
Subject: Hello from John!
Date: Wed, 20 Jun 2001 20:18:47 -0400
Message-ID: <1234@local.machine.example>
Урок по PHP!

___________________________________________

From: "John Coggeshall" <john@zend.com>
To: Joe Users <joe@user.net>
Subject: Hello from John!
Date: Wed, 20 Jun 2001 20:18:47 -0400
Message-ID: <1234@local.machine.example>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Урок по PHP!



Разликата в приведените писма е очевидна: във втория пример се използуват три допълнителни заглавни части. Задължителна от тях е само първата: MIME-Version. Най-голям интерес за нас представлява заглавната част Content-Type, с изменението на която ние можеме



Ако пред Вас възниква задачата да изпратите няколко различни обекта в едно писмо (например, текстова част и прикрепена картинка) е необходимо да се използва заглавната част Content-Type:multipart/mixed, обозначаващ, че писмото се състои от няколко сегмента. Така също е необходимо да се определи параметъра boundary, който ще обозначава границата между фрагментите. В преобладаващите случаи неговото реално значение може да се избере произволно. Всеки фрагмент се комплектова с отделен набор заглавни части. Забелязваме, че заглавната част MIME-Version е длъжна да бъде една за цялото писмо и не може да се среща в нито една от неговите части. Следва пример на писмо, състоящо се от две части: текстово съобщение и прикрепено изображение:


Това е опростен пример на MIME-писмо, състоящо се от няколко части. Първата от тях има типа text/plain и съдържа реалното съдържание на писмото. Втората част има типа image/jpeg и съдържа закодираната в base64 картинка, с името zendlogo.j p g

При използване на съставно писмо, следва да се помни:

Първичната заглавна част content-type има значението multipart/mixed. То съобщава на клиентската пощенска програма, че писмото се състои от няколко сегмента, всеки от които има своя заглавна част content-type;
Стойността на атрибута boundary определен в първичната заглавна част content-type се използува за разделяне на писмото на сегменти (така наречения маркер на границата).
При използването на атрибута boundary се постарайте, да бъде максимално уникален и да не се среща в тялото на самото писмо, защото в противен случай писмото неправилно ще бъде разбито на съставните му части. Освен това, граничният маркер е длъжен да започва с двойно тире, а в последното свое въвеждане, завършвайки писмото, също трябва да завършва с двойно тире. Заглавната част, съдържаща атрибута boundary, е длъжна да предшествува два преводни реда, а последния маркер, означаващ край на MIME-писмото,е длъжен да завършва двата преводни реда.

Вторият сегмент на писмото съдържа допълнителна заглавна част Content-Disposition. Използува се, за да съобщи на пощенската програма на клиента, как визуално следва да се изобрази даденият сегмент от писмото. Може да приема значението attachment (не се явява част от писмото,а прикрепен документ), така и inline (вграждане, непосредствено свързано с тялото на писмото, например картинка, внедрена в HTML). Допуска се използването на заглавната част Content-Description за кратко описание на прикрепения файл.

Значението multipart/alternative на атрибута Content-Type по синтаксис е абсолютно идентичен на multipart/mixed, описан по-горе. Предназначение - да обезпечи няколко варианта за изобразяване на едно и също съдържание (вместо съединяване на три различни документа, както в предишния случай). Да разгледаме пример на писмо, изпратено в три формата:



В приведеното писмо се съдържат три фрагмента. Първият от тях съдържа text/plain за възпроизвеждане на писмото във вид на текст. Вторият фрагмент съдържа тези данни във формат text/enriched (ако желаете да узнаете подробности за формата, обърнете се към RFC 1896). Третият фрагмент съдържа някой произволен формат application/x-myapplication с base64 съдържание на писмото. Съгласно с установената заглавна част multipart/alternative получателят ще види тази част от писмото, която неговият пощенски агент може да изобрази най-добре. Това означава, че ако потребителят има приложение, способно да изобрази тип на документа application/x-myapplication, тогава именно този фрагмент ще бъде показан на потребителя. В противен случай ще бъде произведено запитване за изобразяване на тип text/enriched. И в случай на неуспех ще бъде изобразена секцията, съдържаща писмото във формат text/plain.

Неслучайно най-примитивния способ за възпроизвеждане на писмото е поставен първи. Това е направено с отчитане на това, че пощенският клиент на потребителя е възможно да не подържа формата MIME.

Очевидно е че заглавната част multipart/alternative предоставя възможността за изпращане на писмото във формат text/plain и text/html едновременно, например:



И накрая няколко думи за изпращане на писма с вградени изображения. Съществуват няколко способа за реализиране на такава възможност. В секцията, съдържаща HTML-код може да се напише следното:


. В случай, че в момента на отваряне на такова писмо потребителя е on-line и съответното действие не е отменено в настройките на неговия пощенски клиент, картинката ще бъде извикана от сървъра, и ще бъде изобразена. Плюс на дадения способ е малкия размер на изпращаното писмо. Минус - необходимостта от наличие на on-line и зависимост от настройките на пощенския клиент. Втория способ - използване на заглавната част Content-ID. Използува се за съпоставяне на всяка секция от писмото с уникален идентификатор. В общия случай, такава заглавна част може да бъде указана за всяка секция от писмото, но на практика това има смисъл само ако Ви се налага да се обърнете към този фрагмент в тялото на писмото или към други фрагменти. За пример могат да служат картинки, flash-анимации и др.. По такъв начин получавате възможността да правите обръщение не към външен източник, а към секция от писмото според нейният идентификатор. В разрез това изглежда така:


Новото в този пример е в реда, където външния източник е заменен от указанието локалния идентификатор. Фактическото значение, указвано в заглавната част Content-ID, може да бъде произволно, както и в случая с boundary. Главното изискване - неговата уникалност в пределите на писмото. Използвайки такава методика за прикрепване на файлове, можете да комплектовате пълноценен пакет от документи, такива, като html-съдържащо писмо, файлове стилове, картинки, офис документи, текстова версия, и изпращането им като едно писмо. Не трябва да се забравя, че болшинството потребители имат канал с малка пропускателна способност и поради това не желаят да получават писма с големи размери.

7. Примери за изходни кодове

7.1 Изпращане на писма с вложения


Предлагаме линкове на някои най-използваните класове:

http://renoir.vill.edu/~ylee/mailfile.txt
http://irbp.ru/mime_mail-imgs.html
http://php.spb.ru/php/mail.html
7.2 Използване на сокети


7.3 Използване на sendmail




7.4 Използване на ActiveX


също така:

текст
Урока е изготвен от www.transcode.org

/ Трябва да сте регистриран за да напишете коментар /