Re: Weird error
Re: Weird error
- Subject: Re: Weird error
- From: Walter Ian Kaye <email@hidden>
- Date: Wed, 24 Sep 2003 09:02:37 -0700
At 12:26a -0500 09/24/2003, John Fowler didst inscribe upon an
electronic papyrus:
I'm telling you, there is a problem with "get every text item
(hereinafter geti)" on my system. Further evidence follows.
Now that I have replaced my Trim handler with somebody else's fine
trim handler, I have gotten past the original error only to find
that another 3-4 year old handler of mine, which once again relies
on geti, has a flat tire - the same flat tire as in the Trim
handler, it omits the first character!!
See other messages regarding Unicode.
Does geti rely on perl in some way? Could there have been a setting
that I changed in perl that would bollix geti?
Nope, no Perl there.
Another possibility. Last week there was a problem with "sleep" on
my computer and the solution was an archive-and-install. It is
possible that Monday was the first time thereafter that I called
upon my download program in a way that would use the geti handlers.
Is there a setting or something I should activate in OS X to make
sure the text handlers (are they scripting additions? I don't
recall installing anything special to get geti to work in the past)
work?
Nope. But see below.
At 09:49a -0400 09/24/2003, Arthur J. Knapp didst inscribe upon an
electronic papyrus:
> Date: Tue, 23 Sep 2003 18:52:58 -0500
> From: John Fowler <email@hidden>
>> ... the code that creates the data in the first place? Is it producing
>> old fashioned ASCII text or has it started using UTF-8 or UTF16?
That's an interesting point. I've been out of the loop for a while,
how do the text item delimiters handle UTF-8 and UTF-16?
Apparently they assume a BOM. When you coerce "BLOW, JOE" to Unicode
text, it allocates space for a nonexistent BOM. Since Unicode text is
UTF-8, there are two separate 8-bit characters for the double-byte
BOM... which is nonexistent and so the two characters allocated are
represented by empty strings.
I assume this is done to prevent the loss of the BOM when converting
back and forth when a BOM actually does exist, so this is apparently
something that you "just have to know" when using Unicode text.
It might have been smarter of AS to default to a non-empty BOM
(FFFE?) if only to have allowed us to figure this out sooner. ;)
-Walter
_______________________________________________
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.