Documentation – מידע פרוטוקול

Java: Simple Mail Transfer Protocol

Mon, 01 Jan 0001 00:00:00 +0000

Simple Mail Transfer Protocol (SMTP) משמש להעברת הודעות דוא"ל ברחבי האינטרנט. הפורט ברירת המחדל ל‑SMTP הוא 25. אנו מציינים נמען אחד או יותר, נושא, גוף והפריטים המוצפנים האחרים בהתכתבות. לאחר מכן ההודעה מועברת לשרת SMTP מרוחק. הלקוח מתחבר לשרת ה‑SMTP המרוחק באמצעות כתובת IP או שם תחום בפורט 25. האימות מתבצע עם שם משתמש וסיסמה. שרת SMTP יכול גם לקבל חיבורים אנונימיים שאינם דורשים אימות. השרת לאחר מכן מסירה את ההודעה לנמענים בשם הלקוח.

Java: פרוטוקול הרחבות דואר אינטרנט מרובות מטרות

Mon, 01 Jan 0001 00:00:00 +0000

Multipurpose Internet Mail Extensions (MIME) הוא תקן אינטרנט המרחיב את פורמט האימייל כדי לתמוך ב:

טקסט במערכות תווים שאינן US-ASCII;
קבצים מצורפים שאינם טקסט;
גופי הודעות מרובי‑חלקים; ו
פרטי כותרת במערכות תווים non-ASCII.

SMTP תומך רק בתווים של ASCII ברמת 7 סיביות, מה שאומר במעשיות שהוא תומך במגוון מוגבל של שפות. שפות המבוססות על האותיות הלatin אינן בעיה ב‑SMTP; שפות אחרות אינן מוצגות כראוי כאשר האימייל נמסר. עם זאת, MIME מרחיב את התמיכה בתווי ASCII של SMTP כך שניתן לשלוח ולהציג אימיילים המשתמשים בקבוצות תווים אחרות, תמונות וצלילים. באופן כללי, כל לקוחות האימייל ושרתי SMTP ממפים כראוי הודעות בפורמט MIME.

הבנת כותרות MIME

כותרות MIME מכילות מידע על הפרוטוקול.

MIME-Version

זה מציין שההודעה בפורמט MIME. היא נראית כך:

MIME-Version: 1.0

Content-Type

זה מציין את סוג התוכן של ההודעה, המוגדר כזוג סוג‑תת‑סוג: לדוגמה text/plain, text/html. סוג תוכן multipart יכול לכלול טקסט, HTML, קבצים מצורפים, תמונות, אודיו, וידאו ועוד.

Content-Type: multipart

Content-Transfer-Encoding

מציין האם נעשה שימוש בתכנון קידוד binary‑to‑text מעל למה שמצוין ב‑content-type. אם יש, מציין איזה. כאן ניתן לציין קידוד 7‑bit, 8‑bit וקידוד בינארי.

Encoded-Word

כותרות הודעות SMTP משתמשות בדרך כלל בתווי ASCII. תווים שאינם ASCII חייבים להשתמש בתחביר מילת‑קידוד MIME במקום מחרוזת מילולית. המבנה הוא:

"=? charset ? encoding ? encoded text ?=".

הודעות Multipart

הודעה מרובת חלקים של MIME מכילה גבול (boundary) בכותרת ה‑content-type. גבול זה, שאסור להופיע באף אחד מהחלקים, מוכנס בין החלקים, וכן בתחילת ובסוף גוף ההודעה, כמתואר להלן:

MIME-version: 1.0


 Content-type: multipart/mixed; boundary="frontier"

This is a multi-part message in MIME format.

--frontier

Content-type: text/plain

This is the body of the message.

--frontier

Content-type: application/octet-stream

Content-transfer-encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg

Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==

--frontier--

כל חלק מורכב מכותרת תוכן משלו וגוף.

תתי‑סוגים של Multipart

תקן MIME מגדיר מגוון תתי‑סוגים של הודעות מרובות חלקים. תת‑הסוג מצוין בכותרת "Content-Type" של ההודעה הכוללת.

להלן רשימת תתי‑הסוגים הנמצאים בשימוש הנפוץ ביותר.

Mixed: Multipart/mixed משמש לשליחת קבצים עם כותרות "Content-Type" שונות בתוך הגוף. אם נשלחות תמונות או קבצים קלים לקריאה, רוב לקוחות המייל יציגו אותם באופן מקונן.
Message: חלק הודעה מכיל הודעת אימייל.
Digest: Digest הוא דרך פשוטה לשלוח הודעות טקסט מרובות. סוג התוכן ברירת המחדל לכל חלק הוא "message/rfc822".
Alternative: תת‑הסוג Alternative מציין שכל חלק הוא גרסה "אלטרנטיבית" של אותו התוכן (או דומה לו), כל אחד בפורמט שונה המודגם על‑ידי כותרת "Content-Type" שלו.

בדרך כלל, multipart/alternative משמש להודעות אימייל עם שני חלקים, טקסט רגיל (text/plain) ו‑HTML (text/html). החלק בטקסט רגיל מספק תאימות לאחור, בעוד שחלק ה‑HTML מאפשר שימוש בעיצוב וקישורים. רוב לקוחות האימייל מציעים אפשרות למשתמש להעדיף טקסט רגיל על פני HTML; זהו דוגמה לאופן שבו גורמים מקומיים עשויים להשפיע על האופן שבו יישום בוחר את החלק "הטוב ביותר" של ההודעה להצגה.

למידע נוסף, עקבו אחרי הקישורים לארכיוני RFC.

Java: iCalendar RFC 2445

Mon, 01 Jan 0001 00:00:00 +0000

iCalendar RFC 2445 מתאר מערך של מרכיבי לוח שנה ותזמון שניתן לעשות בהם אינטראקציה, המאפשרים תזמון קבוצתי, ניהול מידע אישי ויישומי לוח שנה להחליף מידע בפורמט משותף.

Aspose.Email מממש את מרכיבי הלוח הזמנים של ה‑RFC מכיוון שלאלו יש יישום רחב מאוד. גרסאות עתידיות עשויות לממש מרכיבים נוספים של RFC 2445, בהתאם לביקוש.

מאמר זה מתאר את מרכיבי ה‑RFC הקשורים ל‑Aspose.Email. אנו ממליצים לעיין בתקן iCalendar http://www.faqs.org/rfcs/rfc2445.html לקבלת תמונה מלאה.

תבניות חזרה בעולם האמיתי

תבנית חזרה מתארת את הכללים לביצוע של אירוע. מנוע תבניות חזרה כמו Aspose iCalendar נדרש כדי לחשב תאריכים ושעות של האימותים לתבנית חזרה נתונה. אנו נתקלים בתזמונים או בתבניות חזרה במצבים רבים, לדוגמה:

עשר פגישות צוות, כל יום שני ב‑10 בבוקר.
עבד את תשלום המשכורת ביום העבודה האחרון של כל חודש.
בדוק את חום המטופל כל יום במשך שבועיים.
לך לחדר הכושר ביום שני, רביעי ושישי.
הרץ גיבוי כל 4 שעות בימי עבודה.
צור דוח מכירות על …
עדכן סטטיסטיקות אתר כל … כמעט כל אירוע שמתרחש בתדירות קבועה ניתן לייצג כתבנית חזרה. לדוגמה, הקוד שלמטה מחזיר מערך עם עשר אירועים של דוגמת פגישת הצוות הקודמת:

CalendarRecurrence recurrencePattern = new CalendarRecurrence("DTSTART:20040301T100000\nRRULE:FREQ=WEEKLY;COUNT=10;BYDAY=MO");
DateCollection expectedDates = recurrencePattern.generateOccurrences();
System.out.println("expectedDates.Count = " + expectedDates.size());
for (int i = 0; i < expectedDates.size(); i++) {
    System.out.println("DateTime = " + sdf.format(expectedDates.getItem(i)));
}

תבניות חזרה עשויות להיות מורכבות מאוד ודורשות מנוע חזרה אמין כדי לפענח ולאמת את הקלט וליצור אירועים בצורה נכונה.