Name Description Size
comi18n.cpp end of extern "C" 1779
comi18n.h __cplusplus 1406
components.conf 3667
jsmime.sys.mjs This file exports the JSMime code, polyfilling code as appropriate for use in Gecko. 1615
mime.def 226
mimebuf.cpp mimebuf.c - libmsg like buffer handling routines for libmime 8001
mimebuf.h _MIMEBUF_H_ 1651
mimecms.cpp SEC_PKCS7DecoderContentCallback for SEC_PKCS7DecoderStart() 26276
mimecms.h The MimeEncryptedCMS class implements a type of MIME object where the object is passed through a CMS decryption engine to decrypt or verify signatures. That module returns a new MIME object, which is then presented to the user. See mimecryp.h for details of the general mechanism on which this is built. 1189
mimecom.cpp MimeObject (abstract) 1924
mimecom.h XP-COM Bridges for C function calls 1306
mimecont.cpp This is an abstract class; it shouldn't be directly instantiated. 6693
mimecont.h MimeContainer is the class for the objects representing all MIME types which can contain other MIME objects within them. In addition to the methods inherited from MimeObject, it provides one method: int add_child (MimeObject *parent, MimeObject *child) Given a parent (a subclass of MimeContainer) this method adds the child (any MIME object) to the parent's list of children. The MimeContainer `finalize' method will finalize the children as well. 1400
mimecryp.cpp (Mostly duplicated from MimeLeaf, see comments in mimecryp.h.) Initialize a decoder if necessary. 18503
mimecryp.h The MimeEncrypted class implements a type of MIME object where the object is passed to some other routine, which then returns a new MIME object. This is the basis of a decryption module. Oddly, this class behaves both as a container and as a leaf: it acts as a container in that it parses out data in order to eventually present a contained object; however, it acts as a leaf in that this container may itself have a Content-Transfer-Encoding applied to its body. This violates the cardinal rule of MIME containers, which is that encodings don't nest, and therefore containers can't have encodings. But, the fact that the S/MIME spec doesn't follow the groundwork laid down by previous MIME specs isn't something we can do anything about at this point... Therefore, this class duplicates some of the work done by the MimeLeaf class, to meet its dual goals of container-hood and leaf-hood. (We could alternately have made this class be a subclass of leaf, and had it duplicate the effort of MimeContainer, but that seemed like the harder approach.) The MimeEncrypted class provides the following methods: void *crypto_init(MimeObject *obj, int (*output_fn) (const char *data, int32 data_size, void *output_closure), void *output_closure) This is called with the MimeObject representing the encrypted data. The obj->headers should be used to initialize the decryption engine. NULL indicates failure; otherwise, an opaque closure object should be returned. output_fn is what the decryption module should use to write a new MIME object (the decrypted data.) output_closure should be passed along to every call to the output routine. The data sent to output_fn should begin with valid MIME headers indicating the type of the data. For example, if decryption resulted in a text document, the data fed through to the output_fn might minimally look like Content-Type: text/plain This is the decrypted data. It is only two lines long. Of course, the data may be of any MIME type, including multipart/mixed. Any returned MIME object will be recursively processed and presented appropriately. (This also imples that encrypted objects may nest, and thus that the underlying decryption module must be reentrant.) int crypto_write (const char *data, int32 data_size, void *crypto_closure) This is called with the raw encrypted data. This data might not come in line-based chunks: if there was a Content-Transfer-Encoding applied to the data (base64 or quoted-printable) then it will have been decoded first (handing binary data to the filter_fn.) `crypto_closure' is the object that `crypto_init' returned. This may return negative on error. int crypto_eof (void *crypto_closure, bool abort_p) This is called when no more data remains. It may call `output_fn' again to flush out any buffered data. If `abort_p' is true, then it may choose to discard any data rather than processing it, as we're terminating abnormally. char * crypto_generate_html (void *crypto_closure) This is called after `crypto_eof' but before `crypto_free'. The crypto module should return a newly-allocated string of HTML code which explains the status of the decryption to the user (whether the signature checked out, etc.) void crypto_free (void *crypto_closure) This will be called when we're all done, after `crypto_eof' and `crypto_emit_html'. It is intended to free any data represented by the crypto_closure. output_fn may not be called. int (*parse_decoded_buffer) (const char *buf, int32 size, MimeObject *obj) This method, of the same name as one in MimeLeaf, is a part of the afforementioned leaf/container hybridization. This method is invoked with the content-transfer-decoded body of this part (without line buffering.) The default behavior of this method is to simply invoke `crypto_write' on the data with which it is called. It's unlikely that a subclass will need to specialize this. 6235
mimecth.cpp These calls are necessary to expose the object class hierarchy to externally developed content type handlers. 1038
mimecth.h This is the definitions for the Content Type Handler plugins for libmime. This will allow developers the dynamically add the ability for libmime to render new content types in the MHTML rendering of HTML messages. 4310
mimedrft.cpp 588595FE-1ADA-11d3-A715-0060B0EB39B5 75588
mimeebod.cpp 0 14057
mimeebod.h The MimeExternalBody class implements the message/external-body MIME type. (This is not to be confused with MimeExternalObject, which implements the handler for application/octet-stream and other types with no more specific handlers.) 1272
mimeenc.cpp Which encoding to use 30869
mimeeobj.cpp 8029
mimeeobj.h The MimeExternalObject class represents MIME parts which contain data which cannot be displayed inline -- application/octet-stream and any other type that is not otherwise specially handled. (This is not to be confused with MimeExternalBody, which is the handler for the message/external-object MIME type only.) 1547
mimefilt.cpp mimefilt.c --- test harness for libmime.a This program reads a message from stdin and writes the output of the MIME parser on stdout. Parameters can be passed to the parser through the usual URL mechanism: mimefilt BASE-URL?headers=all&rot13 < in > out Some parameters can't be affected that way, so some additional switches may be passed on the command line after the URL: -fancy whether fancy headers should be generated (default) -no-fancy opposite; this uses the headers used in the cases of FO_SAVE_AS_TEXT or FO_QUOTE_MESSAGE -html whether we should convert to HTML (like FO_PRESENT); this is the default if no ?part= is specified. -raw don't convert to HTML (FO_SAVE_AS); this is the default if a ?part= is specified. -outline at the end, print a debugging overview of the MIME structure Before any output comes a blurb listing the content-type, charset, and various other info that would have been put in the generated URL struct. It's printed to the beginning of the output because otherwise this out- of-band data would have been lost. (So the output of this program is, in fact, a raw HTTP response.) 10184
mimehdrs.cpp DEBUG 24627
mimehdrs.h This file defines the interface to message-header parsing and formatting code, including conversion to HTML. 3218
MimeHeaderParser.cpp 7454
mimei.cpp MimeObject (abstract) 66966
mimei.h 16089
mimeiimg.cpp Can't happen? Close enough. 7498
mimeiimg.h The MimeInlineImage class implements those MIME image types which can be displayed inline. 985
MimeJSComponents.sys.mjs If we get XPConnect-wrapped objects for msgIAddressObjects, we will have properties defined for 'group' that throws off jsmime. This function converts the addresses into the form that jsmime expects. 16565
mimeleaf.cpp Default `parse_buffer' method is one which line-buffers the now-decoded data and passes it on to `parse_line'. (We snarf the implementation of this method from our superclass's implementation of `parse_buffer', which inherited it from MimeObject.) 6706
mimeleaf.h MimeLeaf is the class for the objects representing all MIME types which are not containers for other MIME objects. The implication of this is that they are MIME types which can have Content-Transfer-Encodings applied to their data. This class provides that service in its parse_buffer() method: int (*parse_decoded_buffer) (const char *buf, int32_t size, MimeObject obj) The `parse_buffer' method of MimeLeaf passes each block of data through the appropriate decoder (if any) and then calls `parse_decoded_buffer' on each block (not line) of output. The default `parse_decoded_buffer' method of MimeLeaf line-buffers the now-decoded data, handing each line to the `parse_line' method in turn. If different behavior is desired (for example, if a class wants access to the decoded data before it is line-buffered) the `parse_decoded_buffer' method should be overridden. (MimeExternalObject does this.) 2168
mimemalt.cpp BACKGROUND ---------- At the simplest level, multipart/alternative means "pick one of these and display it." However, it's actually a lot more complicated than that. The alternatives are in preference order, and counterintuitively, they go from *least* to *most* preferred rather than the reverse. Therefore, when we're parsing, we can't just take the first one we like and throw the rest away -- we have to parse through the whole thing, discarding the n'th part if we are capable of displaying the n+1'th. Adding a wrinkle to that is the fact that we give the user the option of demanding the plain-text alternative even though we are perfectly capable of displaying the HTML, and it is almost always the preferred format, i.e., it almost always comes after the plain-text alternative. Speaking of which, you can't assume that each of the alternatives is just a basic text/[whatever]. There may be, for example, a text/plain followed by a multipart/related which contains text/html and associated embedded images. Yikes! You also can't assume that there will be just two parts. There can be an arbitrary number, and the ones we are capable of displaying and the ones we aren't could be interspersed in any order by the producer of the MIME. We can't just throw away the parts we're not displaying when we're processing the MIME for display. If we were to do that, then the MIME parts that remained wouldn't get numbered properly, and that would mean, for example, that deleting attachments wouldn't work in some messages. Indeed, that very problem is what prompted a rewrite of this file into its current architecture. ARCHITECTURE ------------ Parts are read and queued until we know whether we're going to display them. If the first pending part is one we don't know how to display, then we can add it to the MIME structure immediately, with output_p disabled. If the first pending part is one we know how to display, then we can't add it to the in-memory MIME structure until either (a) we encounter a later, more preferred part we know how to display, or (b) we reach the end of the parts. A display-capable part of the queue may be followed by one or more display-incapable parts. We can't add them to the in-memory structure until we figure out what to do with the first, display-capable pending part, because otherwise the order and numbering will be wrong. All of the logic in this paragraph is implemented in the flush_children function. The display_cached_part function is what actually adds a MIME part to the in-memory MIME structure. There is one complication there which forces us to violate abstrations... Even if we set output_p on a child before adding it to the parent, the parse_begin function resets it. The kluge I came up with to prevent that was to give the child a separate options object and set output_fn to nullptr in it, because that causes parse_begin to set output_p to false. This seemed like the least onerous way to accomplish this, although I can't say it's a solution I'm particularly fond of. Another complication in display_cached_part is that if we were just a normal multipart type, we could rely on MimeMultipart_parse_line to notify emitters about content types, character sets, part numbers, etc. as our new children get created. However, since we defer creation of some children, the notification doesn't happen there, so we have to handle it ourselves. Unfortunately, this requires a small abstraction violation in MimeMultipart_parse_line -- we have to check there if the entity is multipart/alternative and if so not notify emitters there because MimeMultipartAlternative_create_child handles it. - Jonathan Kamens, 2010-07-23 When the option prefer_plaintext is on, the last text/plain part should be preferred over any other part that can be displayed. But if no text/plain part is found, then the algorithm should go as normal and convert any html part found to text. To achieve this I found that the simplest way was to change the function display_part_p into returning priority as an integer instead of boolean can/can't display. Then I also changed the function flush_children so it selects the last part with the highest priority. (Priority 0 means it cannot be displayed and the part is never chosen.) - Terje Bråten, 2013-02-16 21055
mimemalt.h The MimeMultipartAlternative class implements the multipart/alternative MIME container, which displays only one (the `best') of a set of enclosed documents. 1554
mimemapl.cpp #### This method is identical to MimeExternalObject_parse_begin which kinda s#$%s... 5607
mimemapl.h The MimeMultipartAppleDouble class implements the multipart/appledouble MIME container, which provides a method of encapsulating and reconstructing a two-forked Macintosh file. 1037
mimemcms.cpp #### MimeEncryptedCMS and MimeMultipartSignedCMS have a sleazy, incestuous, dysfunctional relationship. 15759
mimemcms.h The MimeMultipartSignedCMS class implements a multipart/signed MIME container with protocol=application/x-CMS-signature, which passes the signed object through CMS code to verify the signature. See mimemsig.h for details of the general mechanism on which this is built. 1195
mimemdig.cpp 749
mimemdig.h The MimeMultipartDigest class implements the multipart/digest MIME container, which is just like multipart/mixed, except that the default type (for parts with no type explicitly specified) is message/rfc822 instead of text/plain. 1048
mimemmix.cpp 634
mimemmix.h The MimeMultipartMixed class implements the multipart/mixed MIME container, and is also used for any and all otherwise-unrecognised subparts of multipart/. 962
mimemoz2.cpp for MIME_RichtextConverter 61522
mimemoz2.h __cplusplus 8548
mimempar.cpp 646
mimempar.h The MimeMultipartParallel class implements the multipart/parallel MIME container, which is currently no different from multipart/mixed, since it's not clear that there's anything useful it could do differently. 1044
mimemrel.cpp Thoughts on how to implement this: = if the type of this multipart/related is not text/html, then treat it the same as multipart/mixed. = For each part in this multipart/related = if this part is not the "top" part = then save this part to a tmp file or a memory object, kind-of like what we do for multipart/alternative sub-parts. If this is an object we're blocked on (see below) send its data along. = else = emit this part (remember, it's of type text/html) = at some point, layout may load a URL for <IMG SRC="cid:xxxx">. we intercept that. = if one of our cached parts has that cid, return the data for it. = else, "block", the same way the image library blocks layout when it doesn't yet have the size of the image. = at some point, layout may load a URL for <IMG SRC="relative/yyy">. we need to intercept that too. = expand the URL, and compare it to our cached objects. if it matches, return it. = else block on it. = once we get to the end, if we have any sub-part references that we're still blocked on, map over them: = if they're cid: references, close them ("broken image" results.) = if they're URLs, then load them in the normal way. -------------------------------------------------- Ok, that's fairly complicated. How about an approach where we go through all the parts first, and don't emit until the end? = if the type of this multipart/related is not text/html, then treat it the same as multipart/mixed. = For each part in this multipart/related = save this part to a tmp file or a memory object, like what we do for multipart/alternative sub-parts. = Emit the "top" part (the text/html one) = intercept all calls to NET_GetURL, to allow us to rewrite the URL. (hook into netlib, or only into imglib's calls to GetURL?) (make sure we're behaving in a context-local way.) = when a URL is loaded, look through our cached parts for a match. = if we find one, map that URL to a "cid:" URL = else, let it load normally = at some point, layout may load a URL for <IMG SRC="cid:xxxx">. it will do this either because that's what was in the HTML, or because that's how we "rewrote" the URLs when we intercepted NET_GetURL. = if one of our cached parts has the requested cid, return the data for it. = else, generate a "broken image" = free all the cached data -------------------------------------------------- How hard would be an approach where we rewrite the HTML? (Looks like it's not much easier, and might be more error-prone.) = if the type of this multipart/related is not text/html, then treat it the same as multipart/mixed. = For each part in this multipart/related = save this part to a tmp file or a memory object, like what we do for multipart/alternative sub-parts. = Parse the "top" part, and emit slightly different HTML: = for each <IMG SRC>, <IMG LOWSRC>, <A HREF>? Any others? = look through our cached parts for a matching URL = if we find one, map that URL to a "cid:" URL = else, let it load normally = at some point, layout may load a URL for <IMG SRC="cid:xxxx">. = if one of our cached parts has the requested cid, return the data for it. = else, generate a "broken image" = free all the cached data 37362
mimemrel.h The MimeMultipartRelated class implements the multipart/related MIME container, which allows `sibling' sub-parts to refer to each other. 2049
mimemsg.cpp XP_UNIX 28937
mimemsg.h The MimeMessage class implements the message/rfc822 and message/news MIME containers, which is to say, mail and news messages. 1296
mimemsig.cpp This is an abstract class; it shouldn't be directly instantiated. 26830
mimemsig.h The MimeMultipartSigned class implements the multipart/signed MIME container, which provides a general method of associating a cryptographic signature to an arbitrary MIME object. The MimeMultipartSigned class provides the following methods: void *crypto_init (MimeObject *multipart_object) This is called with the object, the object->headers of which should be used to initialize the dexlateion engine. NULL indicates failure; otherwise, an opaque closure object should be returned. int crypto_data_hash (const char *data, int32_t data_size, void *crypto_closure) This is called with the raw data, for which a signature has been computed. The crypto module should examine this, and compute a signature for it. int crypto_data_eof (void *crypto_closure, bool abort_p) This is called when no more data remains. If `abort_p' is true, then the crypto module may choose to discard any data rather than processing it, as we're terminating abnormally. int crypto_signature_init (void *crypto_closure, MimeObject *multipart_object, MimeHeaders *signature_hdrs) This is called after crypto_data_eof() and just before the first call to crypto_signature_hash(). The crypto module may wish to do some initialization here, or may wish to examine the actual headers of the signature object itself. int crypto_signature_hash (const char *data, int32_t data_size, void *crypto_closure) This is called with the raw data of the detached signature block. It will be called after crypto_data_eof() has been called to signify the end of the data which is signed. This data is the data of the signature itself. int crypto_signature_eof (void *crypto_closure, bool abort_p) This is called when no more signature data remains. If `abort_p' is true, then the crypto module may choose to discard any data rather than processing it, as we're terminating abnormally. char * crypto_generate_html (void *crypto_closure) This is called after `crypto_signature_eof' but before `crypto_free'. The crypto module should return a newly-allocated string of HTML code which explains the status of the dexlateion to the user (whether the signature checks out, etc.) void crypto_free (void *crypto_closure) This will be called when we're all done, after `crypto_signature_eof' and `crypto_emit_html'. It is intended to free any data represented by the crypto_closure. 5197
mimemult.cpp This is an abstract class; it shouldn't be directly instantiated. 26833
mimemult.h The MimeMultipart class class implements the objects representing all of the "multipart/" MIME types. In addition to the methods inherited from MimeContainer, it provides the following methods and class variables: int create_child (MimeObject *obj) When it has been determined that a new sub-part should be created, this method is called to do that. The default value for this method does it in the usual multipart/mixed way. The headers of the object- to-be-created may be found in the `hdrs' slot of the `MimeMultipart' object. bool output_child_p (MimeObject *parent, MimeObject *child) Whether this child should be output. Default method always says `yes'. int parse_child_line (MimeObject *obj, const char *line, int32_t length, bool first_line_p) When we have a line which should be handed off to the currently-active child object, this method is called to do that. The `first_line_p' variable will be true only for the very first line handed off to this sub-part. The default method simply passes the line to the most- recently-added child object. int close_child (MimeObject *self) When we reach the end of a sub-part (a separator line) this method is called to shut down the currently-active child. The default method simply calls `parse_eof' on the most-recently-added child object. MimeMultipartBoundaryType check_boundary (MimeObject *obj, const char *line, int32_t length) This method is used to examine a line and determine whether it is a part boundary, and if so, what kind. It should return a member of the MimeMultipartBoundaryType describing the line. const char *default_part_type This is the type which should be assumed for sub-parts which have no explicit type specified. The default is "text/plain", but the "multipart/digest" subclass overrides this to "message/rfc822". 3804
mimeobj.cpp Way to destroy any notions of modularity or class hierarchy, Terry! 10814
mimeobj.h MimeObject is the base-class for the objects representing all other MIME types. It provides several methods: int initialize (MimeObject *obj) This is called from mime_new() when a new instance is allocated. Subclasses should do whatever setup is necessary from this method, and should call the superclass's initialize method, unless there's a specific reason not to. void finalize (MimeObject *obj) This is called from mime_free() and should free all data associated with the object. If the object points to other MIME objects, they should be finalized as well (by calling mime_free(), not by calling their finalize() methods directly.) int parse_buffer (const char *buf, int32_t size, MimeObject *obj) This is the method by which you feed arbitrary data into the parser for this object. Most subclasses will probably inherit this method from the MimeObject base-class, which line-buffers the data and then hands it off to the parse_line() method. If this object uses a Content-Transfer-Encoding (base64, qp, uue) then the data may be decoded by parse_buffer() before parse_line() is called. (The MimeLeaf class provides this functionality.) int parse_begin (MimeObject *obj) Called after `init' but before `parse_line' or `parse_buffer'. Can be used to initialize various parsing machinery. int parse_line (const char *line, int32_t length, MimeObject *obj) This method is called (by parse_buffer()) for each complete line of data handed to the parser, and is the method which most subclasses will override to implement their parsers. When handing data off to a MIME object for parsing, one should always call the parse_buffer() method, and not call the parse_line() method directly, since the parse_buffer() method may do other transformations on the data (like base64 decoding.) One should generally not call parse_line() directly, since that could bypass decoding. One should call parse_buffer() instead. int parse_eof (MimeObject *obj, bool abort_p) This is called when there is no more data to be handed to the object: when the parent object is done feeding data to an object being parsed. Implementors of this method should be sure to also call the parse_eof() methods of any sub-objects to which they have pointers. This is also called by the finalize() method, just before object destruction, if it has not already been called. The `closed_p' instance variable is used to prevent multiple calls to `parse_eof'. int parse_end (MimeObject *obj) Called after `parse_eof' but before `finalize'. This can be used to free up any memory no longer needed now that parsing is done (to avoid surprises due to unexpected method combination, it's best to free things in this method in preference to `parse_eof'.) Implementors of this method should be sure to also call the parse_end() methods of any sub-objects to which they have pointers. This is also called by the finalize() method, just before object destruction, if it has not already been called. The `parsed_p' instance variable is used to prevent multiple calls to `parse_end'. bool displayable_inline_p (MimeObjectClass *class, MimeHeaders *hdrs) This method should return true if this class of object will be displayed directly, as opposed to being displayed as a link. This information is used by the "multipart/alternative" parser to decide which of its children is the ``best'' one to display. Note that this is a class method, not an object method -- there is not yet an instance of this class at the time that it is called. The `hdrs' provided are the headers of the object that might be instantiated -- from this, the method may extract additional information that it might need to make its decision. 8267
mimeParser.sys.mjs Determine an arbitrary "parameter" part of a mail header. @param {string} headerStr - The string containing all parts of the header. @param {string} parameter - The parameter we are looking for. 'multipart/signed; protocol="xyz"', 'protocol' --> returns "xyz" @return {string} String containing the value of the parameter; or "". 9916
mimepbuf.cpp See mimepbuf.h for a description of the mission of this file. Implementation: When asked to buffer an object, we first try to malloc() a buffer to hold the upcoming part. First we try to allocate a 50k buffer, and then back off by 5k until we are able to complete the allocation, or are unable to allocate anything. As data is handed to us, we store it in the memory buffer, until the size of the memory buffer is exceeded (including the case where no memory buffer was able to be allocated at all.) Once we've filled the memory buffer, we open a temp file on disk. Anything that is currently in the memory buffer is then flushed out to the disk file (and the memory buffer is discarded.) Subsequent data that is passed in is appended to the file. Thus only one of the memory buffer or the disk buffer ever exist at the same time; and small parts tend to live completely in memory while large parts tend to live on disk. When we are asked to read the data back out of the buffer, we call the provided read-function with either: the contents of the memory buffer; or blocks read from the disk file. 8292
mimepbuf.h This file provides the ability to save up the entire contents of a MIME object (of arbitrary size), and then emit it all at once later. The buffering is done in an efficient way that works well for both very large and very small objects. This is used in two places: = The implementation of multipart/alternative uses this code to do a one-part-lookahead. As it traverses its children, it moves forward until it finds a part which cannot be displayed; and then it displays the *previous* part (the last which *could* be displayed.) This code is used to hold the previous part until it is needed. 2445
mimesun.cpp Sun messages always have separators at the beginning. 11211
mimesun.h MimeSunAttachment is the class for X-Sun-Attachment message contents, which is the Content-Type assigned by that pile of garbage called MailTool. This is not a MIME type per se, but it's very similar to multipart/mixed, so it's easy to parse. Lots of people use MailTool, so what the hell. The format is this: = Content-Type is X-Sun-Attachment = parts are separated by lines of exactly ten dashes = just after the dashes comes a block of headers, including: X-Sun-Data-Type: (manditory) Values are Text, Postscript, Scribe, SGML, TeX, Troff, DVI, and Message. X-Sun-Encoding-Info: (optional) Ordered, comma-separated values, including Compress and Uuencode. X-Sun-Data-Name: (optional) File name, maybe. X-Sun-Data-Description: (optional) Longer text. X-Sun-Content-Lines: (manditory, unless Length is present) Number of lines in the body, not counting headers and the blank line that follows them. X-Sun-Content-Length: (manditory, unless Lines is present) Bytes, presumably using Unix line terminators. 1914
mimetenr.cpp All the magic for this class is in mimetric.c; since text/enriched and text/richtext are so similar, it was easiest to implement them in the same method (but this is a subclass anyway just for general goodness.) 992
mimetenr.h The MimeInlineTextEnriched class implements the text/enriched MIME content type, as defined in RFC 1563. It does this largely by virtue of being a subclass of the MimeInlineTextRichtext class. 1057
mimetext.cpp 17047
mimetext.h The MimeInlineText class is the superclass of all handlers for the MIME text/ content types (which convert various text formats to HTML, in one form or another.) It provides two services: = if ROT13 decoding is desired, the text will be rotated before the `parse_line' method it called; = text will be converted from the message's charset to the "target" charset before the `parse_line' method is called. The contract with charset-conversion is that the converted data will be such that one may interpret any octets (8-bit bytes) in the data which are in the range of the ASCII characters (0-127) as ASCII characters. It is explicitly legal, for example, to scan through the string for "<" and replace it with "&lt;", and to search for things that look like URLs and to wrap them with interesting HTML tags. The charset to which we convert will probably be UTF-8 (an encoding of the Unicode character set, with the feature that all octets with the high bit off have the same interpretations as ASCII.) #### NOTE: if it turns out that we use JIS (ISO-2022-JP) as the target encoding, then this is not quite true; it is safe to search for the low ASCII values (under hex 0x40, octal 0100, which is '@') but it is NOT safe to search for values higher than that -- they may be being used as the subsequent bytes in a multi-byte escape sequence. It's a nice coincidence that HTML's critical characters ("<", ">", and "&") have values under 0x40... 3007
mimeTextHTMLParsed.cpp Most of this code is copied from mimethsa. If you find a bug here, check that class, too. 6508
mimeTextHTMLParsed.h _MIMETEXTHTMLPARSED_H_ 948
mimethpl.cpp TODO: - If you Save As File .html with this mode, you get a total mess. - Print is untested (crashes in all modes). 6246
mimethpl.h The MimeInlineTextHTMLAsPlaintext class converts HTML->TXT->HTML, i.e. HTML to Plaintext and the result to HTML again. This might sound crazy, maybe it is, but it is for the "View as Plaintext" option, if the sender didn't supply a plaintext alternative (bah!). 1281
mimethsa.cpp Most of this code is copied from mimethpl; see there for source comments. If you find a bug here, check that class, too. 4936
mimethsa.h _MIMETHPL_H_ 971
mimethtm.cpp If this HTML part has a Content-Base header, and if we're displaying to the screen (that is, not writing this part "raw") then translate that Content-Base header into a <BASE> tag in the HTML. 8217
mimethtm.h The MimeInlineTextHTML class implements the text/html MIME content type. 1140
mimetpfl.cpp force out any separators... 20916
mimetpfl.h The MimeInlineTextPlainFlowed class implements the text/plain MIME content type for the special case of a supplied format=flowed. See ftp://ftp.ietf.org/internet-drafts/draft-gellens-format-06.txt for more information. 1874
mimetpla.cpp 15036
mimetpla.h The MimeInlineTextPlain class implements the text/plain MIME content type, and is also used for all otherwise-unknown text/ subtypes. 1253
mimetric.cpp This function has this clunky interface because it needs to be called from outside this module (no MimeObject, etc.) 11554
mimetric.h The MimeInlineTextRichtext class implements the (obsolete and deprecated) text/richtext MIME content type, as defined in RFC 1341, and also the text/enriched MIME content type, as defined in RFC 1563. 1111
mimeunty.cpp Oops, those shouldn't still be here... 17008
mimeunty.h The MimeUntypedText class is used for untyped message contents, that is, it is the class used for the body of a message/rfc822 object which had no* Content-Type header, as opposed to an unrecognized content-type. Such a message, technically, does not contain MIME data (it follows only RFC 822, not RFC 1521.) This is a container class, and the reason for that is that it loosely parses the body of the message looking for ``sub-parts'' and then creates appropriate containers for them. More specifically, it looks for uuencoded data. It may do more than that some day. Basically, the algorithm followed is: if line is "begin 644 foo.gif" if there is an open sub-part, close it add a sub-part with type: image/gif; encoding: x-uue hand this line to it and hand subsequent lines to that subpart else if there is an open uuencoded sub-part, and line is "end" hand this line to it close off the uuencoded sub-part else if there is an open sub-part hand this line to it else open a text/plain subpart hand this line to it Adding other types than uuencode to this (for example, PGP) would be pretty straightforward. 2505
modlmime.h Opaque object describing a block of message headers, and a couple of routines for extracting data from one. 17421
modmimee.h mimeenc.c --- MIME encoders and decoders, version 2 (see mimei.h) Copyright (c) 1996 Netscape Communications Corporation, all rights reserved. Created: Jamie Zawinski <jwz@netscape.com>, 15-May-96. 2145
moz.build 1679
nsMimeObjectClassAccess.cpp The following macros actually implement addref, release and query interface for our component. 2261
nsMimeObjectClassAccess.h This interface is implemented by libmime. This interface is used by a Content-Type handler "Plug In" (i.e. vCard) for accessing various internal information about the object class system of libmime. When libmime progresses to a C++ object class, this would probably change. 1979
nsMimeStringResources.h Note that the negative values are not actually strings: they are error codes masquerading as strings. Do not pass them to MimeGetStringByID() expecting to get anything back for your trouble. 1477
nsSimpleMimeConverterStub.cpp 5855
nsSimpleMimeConverterStub.h NS_SIMPLE_MIME_CONVERTER_STUB_H_ 563
nsStreamConverter.cpp 32791
nsStreamConverter.h nsStreamConverter_h_ 3297