Re: Weird
Re: Weird
- Subject: Re: Weird
- From: Paul Berkowitz <email@hidden>
- Date: Thu, 17 Oct 2002 12:44:11 -0700
On 10/17/02 12:11 PM, "Chris Espinosa" <email@hidden> wrote:
>
On Thursday, October 17, 2002, at 11:00 AM, Paul Berkowitz
>
<email@hidden> wrote:
>
>
> AS 1.9 in OS 10.2.1:
>
>
>
> ((ASCII character 32) as Unicode text) contains (ASCII character 202)
>
> --> true
>
>
>
> ASCII character 202 is the large option-space. ASCII character 32 is a
>
> normal space.
>
>
>
> I have a routine that checks for and removes option-spaces from
>
> strings and
>
> Unicode text. I discovered that every Unicode name (usually "firstName
>
> lastName" with a space in between) was being tagged as "containing" an
>
> option space and was sent to the handlers for removing it, but there
>
> was
>
> nothing to remove.
>
>
>
> It turns out that the Unicode space between firstName and lastName
>
> "contains" option-space, all by itself. I certainly hope this is a
>
> bug. If
>
> not, what exactly is it?
>
>
>
> is there any AppleScript team person reading the list who can answer
>
> this?
>
>
Yep.
>
>
Note that
>
(ASCII character 32) contains ((ASCII character 202) as Unicode
>
text)
>
is false.
>
>
The 'contains' operator does an equality comparison on each element of
>
the list or string in turn. As is usual with binary operators, the
>
right-hand operand is coerced to the same type as the left-hand operand
>
before the comparison.
>
>
So your expression compares two Unicode strings (the LHO being
>
explicitly coerced and the RHO being implicitly coerced). The latter
>
compares two ASCII strings.
>
>
One of two things is happening. Either the string-to-Unicode coercion
>
is promoting ASCII character 202 to the same Unicode character that
>
ASCII character 32 coerces to (so the space characters are in fact
>
identical, therefore one does contain the other); or the underlying
>
Unicode string comparison utilities that AppleScript uses are being
>
liberal and considering all spaces to be equal. That may not be what
>
you want in this particular circumstance, but in many other
>
circumstances, it is -- others may not want a script to fail when it's
>
looking for a space between two names just because it happens to be a
>
wider or thinner space than normal.
>
Thanks for responding, Chris.
bill fancher has already drawn my attention to the fact that
(ASCII character 32) as Unicode text = ASCII character 202
-->true
which is even worse. After all, equality is taken pretty seriously in
AppleScript: we can't even get unresolved list items to be equal to their
value unless we resolve them explicitly first.
Taking what you said about the coercion of both sides to the type of the
left side (Unicode text), why should all spaces be considered _equal_ as
Unicode, when they're not equal as string? that's inconsistent:
(ASCII character 32) = ASCII character 202
--> false
(ASCII character 32) as Unicode text = (ASCII character 202) as Unicode
text
--> true
That's not right. It's a bug. i realize that there are some really nifty
coercions for spaces, punctuation, etc. when using Unicode, but this is
going to far IMO. Equals should mean equals. No?
--
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.
| References: | |
| | >Re: Weird (From: Chris Espinosa <email@hidden>) |