Re: BUG: More on C-header text files - CORRECTION
Re: BUG: More on C-header text files - CORRECTION
- Subject: Re: BUG: More on C-header text files - CORRECTION
- From: Paul Berkowitz <email@hidden>
- Date: Sun, 30 Jun 2002 15:41:41 -0700
On 6/30/02 3:18 PM, "John W Baxter" <email@hidden> wrote:
>
The Mail User Agent doing the sending gets the message into that format;
>
the Mail User Agent doing the receiving puts it into the receiving
>
machine's format. Eudora, Outlook Express, Mailsmith, etc are Mail User
>
Agents.
>
This includes attachments, which are (unless plain ASCII text, and
>
sometimes even then) encoded into such lines. The failed, unstuffed,
>
attachment clearly wasn't encoded by the sending program.
John,
Thanks for the detailed info. It explains everything. The paragraph above I
not quite what happened. The file came originally from a Windows computer,
and so it had CRLF to start with. When it came unstuffed/unzipped to a Mac,
the email User Agent (Entourage) on the Mac reassigned it CR line endings.
But the script that it was fed to expected it to have CRLF endings. So when
it used CRLF as the text item delimiter, the entire text was 'text item 1',
which was supposed to be just the first line. Then when it used {"\",\""} as
text item delimiter on this 'first item', expecting to find about 90 items,
it found about 100,000 (all of them in the whole text) and so got a 'stack
overflow'. I changed the script to look for 'paragraph 1' (in OS X) and also
to check for the next two characters after the end of paragraph 1 (in OS's
up to 9.1, paragraph 2 would start with LF if not careful here) to figure
out which line ending is really being used. In cases where the user zipped
the file on the Windows box, or is using Virtual PC (as I did in testing),
or moving the file by Zip disk or CD with no email intervention, the line
endings will indeed still be CRLF, not CR. Anyway, I've got all bases
covered.
Thank you for the proper explanation, especially this:
>
>
This is very much like ASCII mode FTP. And both procedures go back many
>
years (long enough that the CRLF comes from the way teletypes worked [the
>
LF was after the CR to give the mechanical actions time...there were NULs
>
after the LF, but the LF took up one time slot]).
I could never figure out why they needed two separate characters for marking
the ends of lines. That now makes sense. Can you, or some else, explain or
"remind" us why, when reducing that to one character, Macs (and MS Word,
even in Windows) took CR whereas Unix ("Epoch" beginning 1/1/1970) took LF?
Why so many different implementations?
--
Paul Berkowitz
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.