dcw@ATHENA.MIT.EDU ("Dave Whitney Third year undergraduate student in Computer Science at MIT") (02/17/89)
The original question was: "Dave, your statement about what I do or do not have to do in order uncode BinSCII files was unclear." Here's the deal. Essentially, with BinSCII, you don't have to worry about anything at all. With the version that went out, CRLFs will throw it off, but I'm fixing that. A valid BinSCII file has one or more segments in it. Each segment has: a filestart tag - FiLeStArTfIlEsTaRt <NL> a conversion alphabet <NL> filename stored uncoded and unchecked (ie, you could change the name of the upacked file by just editing in the header there.) then in coded form: the length of the output file, the byte offset in the file of the first coded byte in the segment, the file info (create date, etc), # bytes coded in this segment, CRC of this info <NL> 1 or more lines of 64 characters representing 48 bytes of the file <NL> CRC of all data coded in this segment <NL> Where <NL> currently is a one character line seperator - soon to be an n-character line seperator where the n chars are not in the xlation alphabet. After explaining all this, it should be clear that any text file containing a BinSCII segment can be run through BinSCII without modification to the text file and BinSCII will locate and decode that segment and any other segment present in the text file. Because BinSCII inserts the data into the output file exactly where it's supposed to go, it doesn't matter what order you process the segments of any one file. Dave