# `email.policy`: 정책 객체

버전 3.3에 추가.

소스 코드: Lib/email/policy.py

`email` 패키지의 주요 초점은 다양한 전자 우편과 MIME RFC에 설명된 대로 전자 우편 메시지를 처리하는 것입니다. 그러나 전자 우편 메시지의 일반적인 형식(각각 이름, 콜론, 값 순으로 구성된 헤더 필드의 블록, 빈 줄과 임의의 ‘본문’ 이 뒤따르는 전체 블록)은 전자 우편 영역 밖에서도 용도가 발견되는 형식입니다. 이러한 용도 중 일부는 메인 전자 우편 RFC와 상당히 유사하지만, 일부는 그렇지 않습니다. 전자 우편으로 작업할 때에도, RFC의 엄격한 준수를 위반하는 것이 바람직할 때가 있습니다. 가령 표준을 따르지 않는 전자 우편 서버와 상호 운영되거나 표준을 위반하는 방식으로 사용하기 원하는 확장을 구현하는 전자 우편을 생성하는 경우가 그렇습니다.

정책 객체는 email 패키지에 이러한 개별 사용 사례를 모두 처리 할 수 있는 유연성을 제공합니다.

`Policy` 객체는 사용 중에 email 패키지의 다양한 구성 요소 동작을 제어하는 일련의 어트리뷰트와 메서드를 캡슐화합니다. `Policy` 인스턴스는 email 패키지의 다양한 클래스와 메서드로 전달되어 기본 동작을 변경할 수 있습니다. 설정 가능한 값과 기본값은 아래에 설명되어 있습니다.

email 패키지의 모든 클래스에서 사용되는 기본 정책이 있습니다. 모든 `parser` 클래스와 관련 편의 함수 및 `Message` 클래스의 경우, 이것은 사전 정의된 인스턴스 `compat32`를 통한 `Compat32` 정책입니다. 이 정책은 파이썬 3.3 이전 버전의 email 패키지와 완전한 과거 호환성(어떤 경우에는, 버그 호환성을 포함합니다)을 제공합니다.

`EmailMessage`에 대한 policy 키워드의 기본값은 사전 정의된 인스턴스 `default`를 통한 `EmailPolicy` 정책입니다.

`Message`나 `EmailMessage` 객체가 만들어질 때, 정책을 획득합니다. 메시지가 `parser`로 만들어지면, 구문 분석기에 전달된 정책이 만들어지는 메시지가 사용하는 정책이 됩니다. 프로그램이 메시지를 만들면, 만들 때 정책을 지정할 수 있습니다. 메시지가 `generator`에 전달될 때, 제너레이터는 기본적으로 메시지의 정책을 사용하지만, 특정 정책을 제너레이터에 전달하여 메시지 객체에 저장된 정책을 재정의할 수도 있습니다.

`email.parser` 클래스와 구문 분석기 편의 함수에 대한 policy 키워드의 기본값은 이후 버전의 파이썬에서 변경될 예정입니다. 따라서 `parser` 모듈에서 설명된 클래스와 함수를 호출할 때는 항상 사용할 정책을 명시적으로 지정해야 합니다.

이 설명서의 첫 부분은 `compat32`를 포함한 모든 정책 객체에 공통적인 기능을 정의하는 추상 베이스 클래스 인 `Policy`의 기능을 다룹니다. 여기에는 email 패키지에 의해 내부적으로 호출되는 특정 훅 메서드가 포함되며, 사용자 정의 정책은 다른 동작을 얻기 위해 재정의할 수 있습니다. 두 번째 부분에서는 표준 동작과 이전 버전과 호환되는 동작과 기능을 각각 제공하는 훅을 구현하는 구상 클래스 `EmailPolicy`와 `Compat32`를 설명합니다.

`Policy` 인스턴스는 불변이지만, 복제할 수 있는데, 클래스 생성자와 같은 키워드 인자를 받아들이고 원본의 사본이지만 지정된 어트리뷰트 값이 변경된 새 `Policy` 인스턴스를 반환합니다.

예를 들어, 다음 코드를 사용하여 디스크의 파일에서 전자 우편 메시지를 읽고 유닉스 시스템의 시스템 `sendmail` 프로그램으로 전달할 수 있습니다:

    >>> from email import message_from_binary_file
    >>> from email.generator import BytesGenerator
    >>> from email import policy
    >>> from subprocess import Popen, PIPE
    >>> with open('mymsg.txt', 'rb') as f:
    ...     msg = message_from_binary_file(f, policy=policy.default)
    >>> p = Popen(['sendmail', msg['To'].addresses[0]], stdin=PIPE)
    >>> g = BytesGenerator(p.stdin, policy=msg.policy.clone(linesep='\r\n'))
    >>> g.flatten(msg)
    >>> p.stdin.close()
    >>> rc = p.wait()

여기서 우리는 `BytesGenerator`에게 `sendmail`의 `stdin`으로 공급할 바이너리 문자열을 만들 때 RFC 올바른 줄 구분자 문자를 사용하도록 지시합니다. 기본 정책은 `\n` 줄 구분자를 사용합니다.

일부 email 패키지 메서드는 policy 키워드 인자를 받아들여, 해당 메서드에 대한 정책을 대체 할 수 있도록 합니다. 예를 들어, 다음 코드는 이전 예제의 msg 객체의 `as_bytes()` 메서드를 사용하고 실행 중인 플랫폼의 기본 줄 구분자를 사용하여 메시지를 파일에 씁니다:

    >>> import os
    >>> with open('converted.txt', 'wb') as f:
    ...     f.write(msg.as_bytes(policy=msg.policy.clone(linesep=os.linesep)))
    17

더하기 연산자를 사용하여 정책 객체를 결합하여, 기본값이 아닌 설정이 합쳐진 조합으로 설정된 정책 객체를 생성할 수도 있습니다:

    >>> compat_SMTP = policy.compat32.clone(linesep='\r\n')
    >>> compat_strict = policy.compat32.clone(raise_on_defect=True)
    >>> compat_strict_SMTP = compat_SMTP + compat_strict

이 연산은 교환적(commutative)이지 않습니다; 즉, 객체가 더해지는 순서가 중요합니다. 예시하면 이렇습니다:

    >>> policy100 = policy.compat32.clone(max_line_length=100)
    >>> policy80 = policy.compat32.clone(max_line_length=80)
    >>> apolicy = policy100 + policy80
    >>> apolicy.max_line_length
    80
    >>> apolicy = policy80 + policy100
    >>> apolicy.max_line_length
    100

class `email.policy.``Policy`(**kw)

  모든 정책 클래스의 추상 베이스 클래스입니다. 불변 속성, `clone()` 메서드 및 생성자 시맨틱의 구현뿐만 아니라 몇 가지 간단한 메서드에 대한 기본 구현을 제공합니다.

  정책 클래스의 생성자에는 다양한 키워드 인자가 전달될 수 있습니다. 지정할 수 있는 인자는 이 클래스의 메서드 이외의 프로퍼티, 그리고 구상 클래스의 메서드 이외의 프로퍼티입니다. 생성자에 지정된 값은 해당 어트리뷰트의 기본값을 재정의합니다.

  이 클래스는 다음 프로퍼티를 정의합니다. 따라서, 모든 정책 클래스의 생성자에 다음에 대한 값이 전달될 수 있습니다:

  `max_line_length`

    줄 종료 문자를 포함하지 않고, 직렬화된 출력에서 줄의 최대 길이. RFC 5322에 따라 기본값은 78입니다. `0`이나 `None` 값은 줄 바꿈을 전혀 수행하지 않아야 함을 나타냅니다.

  `linesep`

    직렬화된 출력에서 줄을 종료하는 데 사용되는 문자열입니다. RFC는 `\r\n`을 요구하지만, 기본값은 파이썬에서 사용하는 내부 줄 종료 규칙을 따라 `\n`입니다.

  `cte_type`

    사용해야 하는 콘텐츠 전송 인코딩(Content Transfer Encoding) 유형을 제어합니다. 가능한 값은 다음과 같습니다:

    `7bit` | 모든 데이터는 “7비트 클린”(ASCII 전용)이어야 합니다. 즉, 필요하면 quoted-printable이나 base64 인코딩을 사용하여 데이터를 인코딩합니다.
    `8bit` | 데이터는 7비트 클린으로 제한되지 않습니다. 헤더의 데이터는 여전히 ASCII 전용이어야 하므로 인코딩되지만 (예외는 아래 `fold_binary()`와 `utf8`을 참조하십시오), 본문 부분은 `8bit` CTE를 사용할 수 있습니다.

    `8bit` `cte_type` 값은 문자열이 바이너리 데이터를 포함할 수 없어서 `Generator`가 아닌 `BytesGenerator`에서만 작동합니다. `Generator`가 `cte_type=8bit`를 지정하는 정책에 따라 작동하면, `cte_type`이 `7bit`인 것처럼 동작합니다.

  `raise_on_defect`

    `True`이면, 만나는 모든 결함을 에러로 발생시킵니다. `False`(기본값)이면, 결함은 `register_defect()` 메서드로 전달됩니다.

  `mangle_from_`

    `True`이면, 본문에서 “From “으로 시작하는 줄은 `>`를 앞에 배치하여 이스케이프 됩니다. 이 매개 변수는 제너레이터가 메시지를 직렬화할 때 사용됩니다. 기본값: `False`.

    버전 3.5에 추가: mangle_from_ 매개 변수.

  `message_factory`

    새로운 빈 메시지 객체를 생성하기 위한 팩토리 함수. 메시지를 구축할 때 구분 분석기가 사용합니다. 기본값은 `None`이며, 이때 `Message`가 사용됩니다.

    버전 3.6에 추가.

  다음 `Policy` 메서드는 email 라이브러리를 사용하여 사용자 정의 설정으로 정책 인스턴스를 만드는 코드가 호출하기 위한 것입니다:

  `clone`(**kw)

    키워드 인자로 새로운 값이 부여되는 어트리뷰트를 제외하고, 어트리뷰트가 현재 인스턴스와 같은 값을 갖는 새로운 `Policy` 인스턴스를 반환합니다.

  나머지 `Policy` 메서드는 email 패키지 코드에 의해 호출되며, email 패키지를 사용하는 응용 프로그램에 의해 호출되는 용도가 아닙니다. 사용자 정의 정책은 이 모든 메서드를 구현해야 합니다.

  `handle_defect`(obj, defect)

    obj에서 찾은 defect를 처리합니다. email 패키지가 이 메서드를 호출할 때, defect는 항상 `Defect`의 서브 클래스입니다.

    기본 구현은 `raise_on_defect` 플래그를 확인합니다. `True`이면, defect가 예외로 발생합니다. `False`(기본값)이면 obj와 defect가 `register_defect()`로 전달됩니다.

  `register_defect`(obj, defect)

    obj에 defect를 등록합니다. email 패키지에서, defect는 항상 `Defect`의 서브 클래스입니다.

    기본 구현은 obj의 `defects` 어트리뷰트의 `append` 메서드를 호출합니다. email 패키지가 `handle_defect`를 호출할 때, obj는 일반적으로 `append` 메서드가 있는 `defects` 어트리뷰트가 있습니다. email 패키지와 함께 사용되는 사용자 정의 객체 형(예를 들어, 사용자 정의 `Message` 객체)도 이러한 어트리뷰트를 제공해야 합니다, 그렇지 않으면 구문 분석된 메시지의 결함이 예기치 않은 에러를 발생시킵니다.

  `header_max_count`(name)

    name이라는 헤더의 최대 허용 개수를 반환합니다.

    헤더가 `EmailMessage`나 `Message` 객체에 추가될 때 호출됩니다. 반환 값이 `0`이나 `None`이 아니고, 반환 값보다 크거나 같은 수의 이름이 name인 헤더가 이미 있으면 `ValueError`가 발생합니다.

    `Message.__setitem__`의 기본 동작은 값을 헤더 리스트에 추가하는 것이므로, 깨닫지 못하는 사이에 중복 헤더를 만들기 쉽습니다. 이 메서드는 특정 헤더를 `Message`에 프로그래밍 방식으로 추가할 수 있는 인스턴스의 수를 제한할 수 있도록 합니다. (이 제약은 구문 분석기가 보지 않습니다, 구문 분석기는 구문 분석 중인 메시지에 존재하는 수 만큼 헤더를 충실하게 생성합니다.)

    기본 구현은 모든 헤더 이름에 대해 `None`을 반환합니다.

  `header_source_parse`(sourcelines)

    email 패키지는 문자열 리스트로 이 메서드를 호출하며, 각 문자열은 구문 분석 중인 소스에서 발견된 줄 구분 문자로 끝납니다. 첫 번째 줄에는 필드 헤더 이름과 구분자가 포함됩니다. 소스의 모든 공백이 유지됩니다. 이 메서드는 구문 분석된 헤더를 나타내기 위해 `Message`에 저장될 `(name, value)` 튜플을 반환해야 합니다.

    구현이 기존 email 패키지 정책과의 호환성을 유지하기 원한다면, name은 대소 문자를 유지한 이름( ‘`:`’ 구분자까지의 모든 문자)이어야 하지만, value는 선행 공백이 제거되고 펼쳐진(unfolded) 값(모든 줄 구분자 문자는 제거하지만, 공백은 그대로 유지한)이어야 합니다.

    sourcelines는 서로게이트 이스케이프 된 바이너리 데이터를 포함할 수 있습니다.

    기본 구현이 없습니다

  `header_store_parse`(name, value)

    email 패키지는 (구문 분석기가 만든 `Message`가 아니라) 응용 프로그램이 `Message`를 프로그래밍 방식으로 수정할 때, 응용 프로그램이 제공한 name과 value로 이 메서드를 호출합니다. 이 메서드는 헤더를 나타내기 위해 `Message`에 저장될 `(name, value)` 튜플을 반환해야 합니다.

    구현이 기존 email 패키지 정책과의 호환성을 유지하기 원한다면, name과 value는 전달된 인자의 내용을 변경하지 않는 문자열이나 문자열의 서브 클래스여야 합니다.

    기본 구현이 없습니다

  `header_fetch_parse`(name, value)

    email 패키지는 응용 프로그램이 해당 헤더를 요청할 때 `Message`에 현재 저장된 name과 value로 이 메서드를 호출하며, 메서드가 반환하는 것은 꺼내는 헤더의 값으로 응용 프로그램에 다시 전달됩니다. `Message`에 같은 이름을 가진 헤더가 두 개 이상 있을 수 있음에 유의하십시오; 이 메서드로는 응용 프로그램으로 반환될 헤더의 특정 이름과 값이 전달됩니다.

    value는 서로게이트 이스케이프 된 바이너리 데이터를 포함할 수 있습니다. 이 메서드가 반환하는 값에는 서로게이트 이스케이프 된 바이너리 데이터가 없어야 합니다.

    기본 구현이 없습니다

  `fold`(name, value)

    email 패키지는 지정된 헤더에 대해 `Message`에 현재 저장된 name과 value로 이 메서드를 호출합니다. 이 메서드는 name을 value와 합치고 적절한 위치에 `linesep` 문자를 삽입하여 (정책 설정에 따라) 올바르게 “접힌(folded)” 헤더를 나타내는 문자열을 반환해야 합니다. 전자 우편 헤더 접기 규칙에 대한 설명은 RFC 5322를 참조하십시오.

    value는 서로게이트 이스케이프 된 바이너리 데이터를 포함할 수 있습니다. 메서드가 반환한 문자열에는 서로게이트 이스케이프 된 바이너리 데이터가 없어야 합니다.

  `fold_binary`(name, value)

    반환 값이 문자열이 아니라 바이트열 객체여야 한다는 점을 제외하고는 `fold()`와 같습니다.

    value는 서로게이트 이스케이프 된 바이너리 데이터를 포함할 수 있습니다. 이들은 반환된 바이트열 객체에서 바이너리 데이터로 다시 변환될 수 있습니다.

class `email.policy.``EmailPolicy`(**kw)

  이 구상 `Policy`는 현재 전자 우편 RFC를 완전히 준수하기 위한 동작을 제공합니다. 여기에는 RFC 5322, RFC 2047 및 현재 MIME RFC가 포함되지만 이에 국한되지는 않습니다.

  이 정책은 새로운 헤더 구문 분석과 접기(folding) 알고리즘을 추가합니다. 단순한 문자열 대신, 헤더는 필드 유형에 따라 달라지는 어트리뷰트를 가진 `str` 서브 클래스입니다. 구문 분석과 접기 알고리즘은 RFC 2047과 RFC 5322를 완전히 구현합니다.

  `message_factory` 어트리뷰트의 기본값은 `EmailMessage`입니다.

  모든 정책에 적용되는 위에 나열된 설정 가능 어트리뷰트 외에도, 이 정책은 다음과 같은 어트리뷰트를 추가합니다:

  버전 3.6에 추가: 1

  `utf8`

    `False`이면, RFC 5322를 따르고 헤더에서 ASCII가 아닌 문자를 “인코딩된 단어”로 인코딩하여 지원합니다. `True`이면, RFC 6532를 따르고 헤더에 `utf-8` 인코딩을 사용합니다. 이러한 방식으로 포맷된 메시지는 `SMTPUTF8` 확장(RFC 6531)을 지원하는 SMTP 서버로 전달될 수 있습니다.

  `refold_source`

    `Message` 객체의 헤더 값이 (프로그램이 설정하는 것과 대조적으로) `parser`에서 온 것이면, 이 어트리뷰트는 메시지를 직렬화된 형식으로 다시 변환할 때 제너레이터가 그 값을 다시 접어야 하는지를 나타냅니다. 가능한 값은 다음과 같습니다:

    `none` | 모든 소스 값은 원래 접기를 사용합니다
    `long` | `max_line_length`보다 긴 줄이 있는 소스 값은 다시 접힙니다.
    `all` | 모든 값이 다시 접힙니다.

    기본값은 `long`입니다.

  `header_factory`

    `name`과 `value` 두 개의 인자를 취하는 콜러블. 여기서 `name`은 헤더 필드 이름이고 `value`는 펼쳐진 헤더 필드 값이며 해당 헤더를 나타내는 문자열 서브 클래스를 반환합니다. 다양한 주소와 날짜 RFC 5322 헤더 필드 유형과 주요 MIME 헤더 필드 유형에 대한 사용자 정의 구문 분석을 지원하는 기본 `header_factory`(`headerregistry`를 참조하십시오)가 제공됩니다. 향후 추가 사용자 정의 구문 분석에 대한 지원이 추가될 것입니다.

  `content_manager`

    적어도 두 개의 메서드가 있는 객체: get_content와 set_content. `EmailMessage` 객체의 `get_content()`나 `set_content()` 메서드가 호출될 때, 이 객체의 해당 메서드를 호출하는데, 메시지 객체를 첫 번째 인자로 전달하고 전달된 다른 인자와 키워드를 추가 인자로 전달합니다. 기본적으로 `content_manager`는 `raw_data_manager`로 설정됩니다.

    버전 3.4에 추가.

  이 클래스는 다음과 같은 `Policy`의 추상 메서드의 구상 구현을 제공합니다:

  `header_max_count`(name)

    지정된 이름의 헤더를 나타내는 데 사용되는 특수화된 클래스의 `max_count` 어트리뷰트 값을 반환합니다.

  `header_source_parse`(sourcelines)

    이름은 ‘`:`’까지의 모든 것으로 구문 분석되고 수정되지 않은 상태로 반환됩니다. 값은 첫 번째 줄의 나머지 부분에서 선행 공백을 제거한 후에 모든 후속 줄을 이어붙이고 후행 캐리지 리턴이나 줄 바꿈 문자를 제거하여 결정됩니다.

  `header_store_parse`(name, value)

    이름은 변경되지 않고 반환됩니다. 입력값에 `name` 어트리뷰트가 있고 대소 문자를 무시하고 name과 일치하면, 값은 변경되지 않고 반환됩니다. 그렇지 않으면 name과 value는 `header_factory`로 전달되고, 결과 헤더 객체가 값으로 반환됩니다. 이 경우 입력값에 CR이나 LF 문자가 포함되어 있으면 `ValueError`가 발생합니다.

  `header_fetch_parse`(name, value)

    값에 `name` 어트리뷰트가 있으면, 수정되지 않은 상태로 반환됩니다. 그렇지 않으면 name과 CR이나 LF 문자가 제거된 value가 `header_factory`로 전달되고, 결과 헤더 객체가 반환됩니다. 서로게이트 이스케이프 된 바이트열은 유니코드 알 수 없는 문자 글리프(unknown-character glyph)로 바뀝니다.

  `fold`(name, value)

    헤더 접기는 `refold_source` 정책 설정에 의해 제어됩니다. 값은 `name` 어트리뷰트가 없을 때, 그리고 그때만 ‘소스값’으로 간주합니다 (`name` 어트리뷰트가 있다는 것은 헤더 객체나 그 일종이라는 뜻입니다). 정책에 따라 소스값을 다시 접어야 할 필요가 있으면, `header_factory`에 name과 CR과 LF 문자가 제거된 value를 전달하여 헤더 객체로 변환됩니다. 헤더 객체의 접기는 현재 정책으로 `fold` 메서드를 호출하여 수행됩니다.

    소스값은 `splitlines()`를 사용하여 줄로 분할됩니다. 값을 다시 접지 않으면, 정책의 `linesep`을 사용하여 줄을 다시 이어붙인 후에 반환합니다. ASCII가 아닌 바이너리 데이터가 포함된 줄은 예외입니다. 이 경우 `refold_source` 설정과 관계없이 값이 다시 접히는데, `unknown-8bit` 문자 집합을 사용하여 바이너리 데이터가 CTE로 인코딩됩니다.

  `fold_binary`(name, value)

    `cte_type`이 `7bit`이면, 반환된 값이 바이트열인 것을 제외하고 `fold()`와 같습니다.

    `cte_type`이 `8bit`이면, ASCII가 아닌 바이너리 데이터는 다시 바이트열로 변환됩니다. 바이너리 데이터가 단일 바이트 문자와 멀티 바이트 문자 중 어는 것으로 구성되어 있는지 알 방법이 없어서, `refold_header` 설정과 관계없이 바이너리 데이터가 있는 헤더는 다시 접히지 않습니다.

다음 `EmailPolicy` 인스턴스는 특정 응용 프로그램 도메인에 적합한 기본값을 제공합니다. 향후 이러한 인스턴스들(특히 `HTTP` 인스턴스)의 동작은 그 들의 도메인과 관련된 RFC에 훨씬 더 가깝게 조정될 수 있음에 유의하십시오.

`email.policy.``default`

  모든 기본값이 변경되지 않은 `EmailPolicy` 인스턴스. 이 정책은 RFC 올바른 `\r\n`이 아닌 표준 파이썬 `\n` 줄 종료를 사용합니다.

`email.policy.``SMTP`

  전자 우편 RFC를 준수하도록 메시지를 직렬화하는 데 적합합니다. `default`와 유사하지만, `linesep`이 `\r\n`으로 설정되어 RFC를 준수합니다.

`email.policy.``SMTPUTF8`

  `utf8`가 `True`라는 점을 제외하고, `SMTP`와 같습니다. 헤더에 인코딩된 단어를 사용하지 않고 메시지를 메시지 저장소로 직렬화하는 데 유용합니다. SMTP 전송에는 발신자나 수신자 주소에 ASCII가 아닌 문자가 있을 때만 사용해야 합니다 (`smtplib.SMTP.send_message()` 메서드는 이를 자동으로 처리합니다).

`email.policy.``HTTP`

  HTTP 트래픽에 사용하기 위해 헤더를 직렬화하는 데 적합합니다. `max_line_length`가 `None`(무제한)으로 설정된 것을 제외하고, `SMTP`와 유사합니다.

`email.policy.``strict`

  편의 인스턴스. `raise_on_defect`가 `True`로 설정된 것을 제외하고, `default`와 같습니다. 다음과 같이 작성하여 모든 정책을 엄격하게 만들 수 있도록 합니다:

      somepolicy + policy.strict

이러한 모든 `EmailPolicy`를 통해, email 패키지의 효과적인 API가 다음과 같은 방식으로 파이썬 3.2 API에서 변경됩니다:

> - `Message`에서 헤더를 설정하면 해당 헤더가 구문 분석되고 헤더 객체가 만들어집니다.

> - `Message`에서 헤더 값을 가져오면 해당 헤더가 구문 분석되고 헤더 객체가 만들어져 반환됩니다.

> - 모든 헤더 객체나 정책 설정으로 인해 다시 접힌 모든 헤더는 인코딩된 단어가 필요한 위치와 허용되는 위치를 포함하여 RFC 접기 알고리즘을 완전히 구현하는 알고리즘을 사용하여 접힙니다.

응용 프로그램의 시각에서, 이것은 `EmailMessage`를 통해 얻은 모든 헤더가 추가 어트리뷰트가 있는 헤더 객체이며, 그것의 문자열 값은 헤더의 완전히 디코딩된 유니코드 값이 됨을 뜻합니다. 마찬가지로, 유니코드 문자열을 사용하여 헤더에 새 값이나 새로 만들어진 헤더를 대입할 수 있으며, 정책은 유니코드 문자열을 올바른 RFC 인코딩 형식으로 변환합니다.

헤더 객체와 그들의 어트리뷰트는 `headerregistry`에 설명되어 있습니다.

class `email.policy.``Compat32`(**kw)

  이 구상 `Policy`는 과거 호환성 정책입니다. 파이썬 3.2에 있는 email 패키지의 동작을 흉내 냅니다. `policy` 모듈은 이 클래스의 인스턴스 `compat32`도 정의하고, 기본 정책으로 사용합니다. 따라서 email 패키지의 기본 동작은 파이썬 3.2와의 호환성을 유지하는 것입니다.

  다음 어트리뷰트는 `Policy` 기본값과 다른 값을 갖습니다:

  `mangle_from_`

    기본값은 `True`입니다.

  이 클래스는 다음과 같은 `Policy`의 추상 메서드의 구상 구현을 제공합니다:

  `header_source_parse`(sourcelines)

    이름은 ‘`:`’까지의 모든 것으로 구문 분석되고 수정되지 않은 상태로 반환됩니다. 값은 첫 번째 줄의 나머지 부분에서 선행 공백을 제거한 후에 모든 후속 줄을 이어붙이고 후행 캐리지 리턴이나 줄 바꿈 문자를 제거하여 결정됩니다.

  `header_store_parse`(name, value)

    이름과 값은 수정되지 않은 상태로 반환됩니다.

  `header_fetch_parse`(name, value)

    값에 바이너리 데이터가 포함되어 있으면, `unknown-8bit` 문자 집합을 사용하여 `Header` 객체로 변환됩니다. 그렇지 않으면 수정되지 않은 상태로 반환됩니다.

  `fold`(name, value)

    `Header` 접기 알고리즘을 사용하여 헤더를 접습니다. 이 알고리즘은 값의 기존 줄 바꿈을 유지하고, 각 결과 줄을 `max_line_length`로 줄 넘김 합니다. ASCII가 아닌 바이너리 데이터는 `unknown-8bit` 문자 집합을 사용하여 CTE 인코딩됩니다.

  `fold_binary`(name, value)

    `Header` 접기 알고리즘을 사용하여 헤더를 접습니다. 이 알고리즘은 값의 기존 줄 바꿈을 유지하고, 각 결과 줄을 `max_line_length`로 줄 넘김 합니다. `cte_type`이 `7bit`이면, ASCII가 아닌 바이너리 데이터는 `unknown-8bit` 문자 집합을 사용하여 CTE 인코딩됩니다. 그렇지 않으면 원본 소스 헤더가 사용되는데, 기존 줄 바꿈과 임의의 (RFC 유효하지 않은) 바이너리 데이터가 포함될 수 있습니다.

`email.policy.``compat32`

  파이썬 3.2 email 패키지 동작과의 호환성을 제공하는 `Compat32`의 인스턴스.

각주

1

  원래 3.3에 잠정적 기능으로 추가되었습니다.