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: โปรโตคอล Multipurpose Internet Mail Extensions

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

Multipurpose Internet Mail Extensions (MIME) คือมาตรฐานอินเทอร์เน็ตที่ขยายรูปแบบอีเมลเพื่อรองรับ:

ข้อความในชุดอักขระที่ไม่ใช่ US-ASCII;
ไฟล์แนบที่ไม่ใช่ข้อความ;
ส่วนเนื้อหาข้อความหลายส่วน; และ
ข้อมูลส่วนหัวในชุดอักขระที่ไม่เป็น ASCII

SMTP รองรับเพียงอักขระ ASCII 7 บิต ซึ่งหมายความว่ารองรับเพียงภาษาจำนวนเล็กน้อย ภาษาที่ใช้ตัวอักษรละตินทำงานได้ดีกับ 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

บ่งบอกว่ามีการใช้โครงร่างการเข้ารหัสจากไบนารีเป็นข้อความบน content-type หรือไม่ หากมี ให้ระบุว่าเป็นแบบใด เราสามารถกำหนดประเภทการเข้ารหัส 7-bit, 8-bit และ binary ได้ที่นี่

Encoded-Word

ส่วนหัวของข้อความ SMTP ปกติใช้ตัวอักษร ASCII ตัวอักษรที่ไม่ใช่ ASCII จะต้องใช้ไวยากรณ์ MIME encoded word แทนสตริงตรงรูปแบบคือ:

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

Multipart-Messages

ข้อความ MIME multipart จะมี boundary ในหัวข้อ content-type boundary นี้ต้องไม่ปรากฏในส่วนใดส่วนหนึ่งและจะวางระหว่างส่วนต่างๆ และที่จุดเริ่มต้นและจบของส่วนเนื้อความดังนี้:

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 ระบุว่าทุกส่วนเป็นเวอร์ชัน "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:00 น.
ดำเนินการชำระเงินเดือนในวันทำงานสุดท้ายของทุกเดือน
ตรวจอุณหภูมิผู้ป่วยทุกวันเป็นเวลาสองสัปดาห์
ไปออกกำลังกายที่โรงยิมวันจันทร์ พุธ และศุกร์
ทำการสำรองข้อมูลทุก 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)));
}

รูปแบบการเกิดซ้ำอาจซับซ้อนอย่างมาก

ต้องการเครื่องยนต์การเกิดซ้ำที่เชื่อถือได้เพื่อทำการแยกวิเคราะห์และตรวจสอบความถูกต้องของข้อมูลนำเข้าและสร้าง

เหตุการณ์ที่เกิดซ้ำอย่างถูกต้อง.