email — 전자 메일과 MIME 처리 패키지¶
소스 코드: Lib/email/__init__.py
The email package is a library for managing email messages. It is
specifically not designed to do any sending of email messages to SMTP
(RFC 2821), NNTP, or other servers; those are functions of modules such as
smtplib. The email package attempts to be as
RFC-compliant as possible, supporting RFC 5322 and RFC 6532, as well as
such MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, RFC 2183,
and RFC 2231.
email 패키지의 전체 구조는 세 가지 주요 구성 요소와 다른 구성 요소의 동작을 제어하는 네 번째 구성 요소로 나눌 수 있습니다.
패키지의 중심 구성 요소는 전자 메일 메시지를 나타내는 “객체 모델”입니다. 응용 프로그램은 주로 message 서브 모듈에 정의된 객체 모델 인터페이스를 통해 패키지와 상호 작용합니다. 응용 프로그램은 이 API를 사용하여 기존 전자 메일에 대해 질문을 하거나, 새 전자 메일을 작성하거나, 같은 객체 모델 인터페이스를 사용하는 전자 메일 하위 구성 요소를 추가하거나 제거할 수 있습니다. 즉, 전자 메일 메시지와 MIME 하위 구성 요소의 특성에 따라, 전자 메일 객체 모델은 모두 EmailMessage API를 제공하는 객체의 트리 구조입니다.
패키지의 다른 두 가지 주요 구성 요소는 parser와 generator입니다. 구문 분석기(parser)는 직렬화된 전자 메일 메시지(바이트 스트림)를 가져와 EmailMessage 객체의 트리로 변환합니다. 생성기(generator)는 EmailMessage를 받아서 직렬화된 바이트 스트림으로 다시 변환합니다. (구문 분석기와 생성기는 텍스트 문자의 스트림도 처리하지만, 이 사용법은 유효하지 않은 메시지로 끝나기 쉬우므로 사용하지 않는 것이 좋습니다.)
제어 구성 요소는 policy 모듈입니다. 모든 EmailMessage, 모든 generator 및 모든 parser에는 그것의 동작을 제어하는 연관된 policy 객체가 있습니다. 일반적으로 응용 프로그램은 EmailMessage가 만들어질 때 정책을 지정하기만 하면 되는데, EmailMessage를 직접 인스턴스로 만들어서 새 전자 메일을 만들거나, parser를 사용하여 입력 스트림을 구문 분석할 때입니다. 그러나 메시지가 generator를 사용하여 직렬화될 때 정책을 변경할 수 있습니다. 이것은, 예를 들어, 범용 전자 메일 메시지를 디스크에서 구분 분석하지만, 전자 메일 서버로 보낼 때 표준 SMTP 설정을 사용하여 직렬화할 수 있도록 합니다.
The email package does its best to hide the details of the various governing RFCs from the application. Conceptually the application should be able to treat the email message as a structured tree of Unicode text and binary attachments, without having to worry about how these are represented when serialized. In practice, however, it is often necessary to be aware of at least some of the rules governing MIME messages and their structure, specifically the names and nature of the MIME “content types” and how they identify multipart documents. For the most part this knowledge should only be required for more complex applications, and even then it should only be the high level structure in question, and not the details of how those structures are represented. Since MIME content types are used widely in modern internet software (not just email), this will be a familiar concept to many programmers.
The following sections describe the functionality of the email package.
We start with the message object model, which is the primary
interface an application will use, and follow that with the
parser and generator components. Then we cover the
policy controls, which completes the treatment of the main
components of the library.
다음 세 절에서는 패키지에서 발생할 수 있는 예외와 parser가 감지할 수 있는 결함(RFC를 준수하지 않는)에 관해 설명합니다. 그런 다음 headerregistry와 contentmanager 하위 구성 요소를 다룹니다. 이것들은 각각 헤더와 페이로드를 보다 자세하게 조작할 수 있는 도구를 제공합니다. 이 두 구성 요소는 모두 단순하지 않은 메시지를 소비하고 생성하는 것과 관련된 기능을 포함하지만, 고급 응용 프로그램이 관심을 가질 확장 API를 설명하기도 합니다.
그다음은 이전 절에서 다룬 API의 기본 부분들을 사용하는 일련의 예제입니다.
The foregoing represent the modern (Unicode friendly) API of the email package.
The remaining sections, starting with the Message
class, cover the legacy compat32 API that deals much more
directly with the details of how email messages are represented. The
compat32 API does not hide the details of the RFCs from
the application, but for applications that need to operate at that level, they
can be useful tools. This documentation is also relevant for applications that
are still using the compat32 API for backward
compatibility reasons.
버전 3.6에서 변경: 새로운 EmailMessage/EmailPolicy API를 홍보하기 위해 설명서가 재구성되고 다시 작성되었습니다.
Contents of the email package documentation:
레거시 API: