3.6 Decoding Articles

Large binaries files are often broken up into multi-part files when encoded and posted. These large blocks of text which make up an encoded file may be presented to WinVN by a news server out of order and with blocks of other encoded files mixed in. WinVN determines threads of blocks as they are received and decodes, caches blocks which are out of sequence and then pieces together the fragmented files. Theoretically, for example, you can select all files in an alt.binaries newsgroup article-list window, and select Decode Selected Articles from the Articles Menu; WinVN will determine which articles contain encoded material. In cases where not all blocks of an encoded file are found in the selection, WinVN will store as much of the decoded file as possible.

In non-MIME postings, there are no real standards for listing the file name, part number, and total number of parts for each encoded block. However, most encoders attempt to place this information on the subject line of each block, and/or on some informational header in the body text. WinVN attempts to determine encoded-block threads by examining the Subject line of each post, as well as non-data lines within the body text. Information found in Info Headers take precedence over subject line content.

MIME supports standard 3-to-4 encodings, and wraps articles in a very precise protocol describing content types, and multiple-part tracking information. Strictly speaking, filename and part number information are not required in the subject line for MIME attachments. But, MIME is still young and there are many news readers and posters in use that predate the MIME standard, so WinVN will use, but does not depend on MIME headers.

Application-specific info headers which the WinVN decoder understands:

Also, WinVN currently supports a limited subset of the MIME standard headers: If no recognizable Info Headers are contained in the article body text of an encoded block, WinVN relies on the subject line content.

The WinVN decoder understands the following commonly used subject line styles:

For subject lines beginning with the comment or free text, the filename is harder to guess. In these cases, WinVN chooses an identifier which it will seek in other subject lines (it prefers a word containing a dot (hopefully filename.ext), but if none, it just uses the first word). For example: 
  This is part 1/2 of filename.ext		(filename = "filename.ext")
  Another encoded file: filename.ext (1/2)	(filename = "filename.ext")
  Testing encoded files (1/2)			(filename = "testing")
This is not an infallible method but it works most of the time. Subject styles known to be incorrectly handled are: 
  filename.ext 3.4 (1/2)	(filename w/ version number) 
  filename.ext 001		(sequence w/ no # parts) 
  filename.ext1			(part number appended to filename)
There are cases in which the encoded blocks of a file are posted with with unrelated subjects, and without MIME or any useful information headers. WinVN won’t realize (how could it?!) that the articles go together. The following example Subject headers will, assuming no recognizable info headers are contained in the articles, start two decoding threads - one for an identifier "test.exe", and one for an identifier "second": In such cases, the ‘Dumb Decode’ option is available from Configure Decoding which deactivates the decoding threading algorithms. Dumb decode requires that the encoded blocks be in strict sequential order - it starts decoding when it sees a "begin" and stops decoding when it sees an "end". Note that this will not work with Base64 encodings (See Encoding Concepts. When WinVN is not smart enough to realize that encoded articles go together, you can make sure the articles are listed in order, select them all, and then use "Dumb Decode" to decode them.

See Configure Decoding for the decoding option defaults, and more detailed explanations of the options.

WinVN Documentation created by Jim Dumoulin / NASA - Kennedy Space Center.
HyperTexted by Michael Downs / NASA - Kennedy Space Center.