for the main text of a reply to or forward of a non-ASCII message or for non-ASCII
attachments.Composed headers
When sending new mails, if header lines or the name component of an email address
in address-related lines do not encode properly as ASCII text, we first encode the
header per email Internationalization standard. This is done per UTF-8 by default,
but a mailconfig setting can request a different encoding. In email address pairs,
names which cannot be encoded are dropped, and only the email address is used.
It is assumed that servers will respect the encoded names in email addresses.
Displayed text parts
When viewing fetched mail, Unicode encoding names in message headers are used
to decode whenever possible. The main-text part is decoded into str Unicode text
per header information prior to inserting it into a PyEdit component. The content
of all other text parts, as well as all binary parts, is saved in bytes form in binary-
mode files, from where the part may be opened later in the GUI on demand. When
such on-demand text parts are opened, they are displayed in PyEdit pop-up win-
dows by passing to PyEdit the name of the part’s binary-mode file, as well as the
part’s encoding name obtained from part message headers.
If the encoding name in a text part’s header is absent or fails to decode, encoding
guesses are tried for main-text parts, and PyEdit’s separate Unicode policies are
applied to text parts opened on demand (see Chapter 11—it may prompt for an
encoding if not known). In addition to these rules, HTML text parts are saved in
binary mode and opened in a web browser, relying on the browser’s own character
set support; this may in turn use tags in the HTML itself, guesses, or user encoding
selections.
Displayed headers
When viewing email, message headers are automatically decoded per email stand-
ards. This includes both full headers such as Subject, as well as the name compo-
nents of all email address fields in address-related headers such as From, To, and
Cc, and allows these components to be completely encoded or contain encoded
substrings. Because their content gives their MIME and Unicode encodings, no
user interaction is required to decode headers.
In other words, PyMailGUI now supports Internationalized message display and com-
position for both payloads and headers. For broadest utility, this support is distributed
across multiple packages and examples. For example, Unicode decoding of full message
text on fetches actually occurs deep in the imported mailtool package classes. Because
of this, full (unparsed) message text is always Unicode str here. Similarly, headers are
decoded for display here using tools implemented in mailtools, but headers encoding
is both initiated and performed within mailtools itself on sends.
Full text decoding illustrates the types of choices required. It is done according to the
fetchEncoding variable in the mailconfig module. This user setting is used across an
1018 | Chapter 14: The PyMailGUI Client