From: Oleg Broytman Date: Sat, 1 Feb 2014 19:59:18 +0000 (+0400) Subject: Update documentation X-Git-Tag: v2.3.3~3 X-Git-Url: https://git.phdru.name/?p=mimedecode.git;a=commitdiff_plain;h=1d7e83e56c2d0208fd2c8e4a2d3102f339081c73 Update documentation --- diff --git a/ANNOUNCE b/ANNOUNCE index d056f98..84ba7af 100644 --- a/ANNOUNCE +++ b/ANNOUNCE @@ -6,20 +6,21 @@ WHAT IS IT Mail users, especially in non-English countries, often find that mail messages arrived in different formats, with different content types, in different encodings and charsets. Usually this is good because it allows us to -use apropriate format/encoding/whatever. Sometimes, though, some unification is -desireable. For example, one may want to put mail messages into an archive, -make HTML indicies, run search indexer, etc. In such situations converting -messages to text in one character set and skipping some binary atachmetnts is -much desireable. +use appropriate format/encoding/whatever. Sometimes, though, some unification +is desirable. For example, one may want to put mail messages into an archive, +make HTML indices, run search indexer, etc. In such situations converting +messages to text in one character set and skipping some binary attachments is +much desirable. Here is the solution - mimedecode.py. This is a program to decode MIME messages. The program expects one input -file (either on command line or on stdin) which is treated as an RFC822 mesage, -and decoded to stdout. If the file is not an RFC822 message it is just piped to -stdout one-to-one. If the file is a simple RFC822 message it is just decoded as -one part. If it is a MIME message with multiple parts ("attachments") all parts -are decoded. Decoding can be controlled by command-line options. +file (either on command line or on stdin) which is treated as an RFC822 +message, and decodes to stdout or an output file. If the file is not an RFC822 +message it is just copied to the output one-to-one. If the file is a simple +RFC822 message it is decoded as one part. If it is a MIME message with multiple +parts ("attachments") all parts are decoded. Decoding can be controlled by +command-line options. WHAT'S NEW in version 2.3.2 (2014-02-01) Fix a bug - do not generate 'From ' headers in subparts. @@ -60,7 +61,7 @@ AUTHOR Oleg Broytman COPYRIGHT - Copyright (C) 2001-2014 PhiloSoft Design + Copyright (C) 2001-2014 PhiloSoft Design. LICENSE GPL diff --git a/mimedecode.docbook b/mimedecode.docbook index 0bfaf9c..746feda 100644 --- a/mimedecode.docbook +++ b/mimedecode.docbook @@ -84,42 +84,42 @@ much desirable. - It is a program to decode MIME messages. The program expects one input file -(either on the command line or on stdin) which is treated as an RFC822 message, -and decoded to stdout. If the file is not an RFC822 message it is just piped to -stdout as is. If the file is a simple RFC822 message it is just decoded as one -part. If it is a MIME message with multiple parts ("attachments") all parts are -decoded recursively. Decoding can be controlled by the command-line options. + This is a program to decode MIME messages. The program expects one input +file (either on command line or on stdin) which is treated as an RFC822 +message, and decodes to stdout or an output file. If the file is not an RFC822 +message it is just copied to the output one-to-one. If the file is a simple +RFC822 message it is decoded as one part. If it is a MIME message with multiple +parts ("attachments") all parts are decoded. Decoding can be controlled by +command-line options. First, Subject and Content-Disposition headers are examined. If any of those -exists, it is decoded according to RFC2047. Content-Disposition header is not -decoded - only its "filename" parameter. Encoded header parameters violate -the RFC, but widely deployed anyway, especially in the M$ Ophice GUI (often -referred as "Windoze") world, where programmers are often ignorant lamers who -never even heard about RFCs. Correct parameter encoding specified by RFC2231. -This program decodes RFC2231-encoded parameters, too. + exists, it is decoded according to RFC2047. Content-Disposition header is + not decoded - only its "filename" parameter. Encoded header parameters + violate the RFC, but widely deployed anyway by ignorant coders who never + even heard about RFCs. Correct parameter encoding specified by RFC2231. This + program decodes RFC2231-encoded parameters, too. Then the body of the message (or the current part) is decoded. Decoding -starts with looking at header Content-Transfer-Encoding. If the header -specifies non-8bit encoding (usually base64 or quoted-printable), the body -converted to 8bit. Then, if its content type is multipart (multipart/related or -multipart/mixed, e.g) every part is recursively decoded. If it is not -multipart, mailcap database is consulted to find a way to convert the body to -plain text. (I have no idea how mailcap could be configured on said M$ Ophice -GUI, please don't ask me; real OS users can consult my example at -http://phdru.name/Software/dotfiles/mailcap.html). -The decoding process uses first copiousoutput filter it can find. If there is -no any filter the body just passed unconverted. + starts with looking at header Content-Transfer-Encoding. If the header + specifies non-8bit encoding (usually base64 or quoted-printable), the body + converted to 8bit. Then, if its content type is multipart (multipart/related + or multipart/mixed, e.g) every part is recursively decoded. If it is not + multipart, mailcap database is consulted to find a way to convert the body + to plain text. (I have no idea how mailcap can be configured on OSes other + than POSIX, please don't ask me; real OS users can consult my example at + http://phdru.name/Software/dotfiles/mailcap.html). + The decoding process uses the first copiousoutput filter it can find. If + there is no any filter the body just passed as is. - Then Content-Type header consulted for charset. If it is not equal to -current default charset the body text recoded. Finally message headers and body -flushed to stdout. + Then Content-Type header is consulted for charset. If it is not equal to the + current locale charset the body text is recoded. Finally message headers and + the body are flushed to stdout. @@ -338,7 +338,7 @@ is to decode whatever it is possible to decode, not to produce absolutely correct MIME output. The incorrect parts are obvious - decoded Subject headers and filenames. Other than that output is correct MIME message. The program does not try to guess whether the headers are correct. For example, if a message -header states that charset is iso8859-5, but the body is actually in koi8-r - +header states that charset is iso8859-5, but the body is actually in utf-8 the program will recode the message with the wrong charset.