Those Darn Email Character Mappings
Those Darn Email Character Mappings
- Subject: Those Darn Email Character Mappings
- From: Richard 23 <email@hidden>
- Date: Thu, 4 Jan 2001 09:45:55 -0800
>
> Note: the list server will mangle the script a bit. The + character should
>
> be double left brackets (like <<), and the ; character should be double
>
> right brackets (like >>).
>
>
>
JR means the chevrons you make by typing option-\ and shift-option-\
>
(option-backslash and shift-option-backslash).
This comes up so often on the list and as far as I'm concerned is
completely preventable if only there was someone who cared enough
to address and fix it. But nobody in a position to deal with it
has.
Well it's been over a month now since I last brought this up and as
far as I can tell nothing has changed so it's about time for another
tirade on the matter. I officially renew my unreasonable request
for an adjustment in the way the list server mangles email.
It was bad enough before the switch to the new server back at the
end of October:
10/27/2000 V1 #1838
10/28/2000 Vol 1 #1
10/30/2000 Vol 3 #1
11/01/2000 Vol 2 #5
As you all may be aware characters whose ascii code is greater than
127 get remapped per a scheme which seems to follow no logical pattern.
Fortunately in the previous incarnation of the list server the special
symbols like "not equal", "greater than or less than", "less than or
equal",
chevrons (the double-angle brackets used to denote raw apple events)
and continuation characters (option-l) mapped to characters which weren't
commonly used, so decoding a mangled script was a straightforward matter
of direct character substitution. I wrote a script which performs such
substitutions and run it before I send any script snippet to the list.
see the following for more info:
http://homepage.mac.com/richard23/docs/ConvertScript.html
http://homepage.mac.com/richard23/applescript03.html#ConvertScript
http://homepage.mac.com/richard23/rants02.html
Last time I checked (I ran the full ascii set through the list server,
applescript-users digest, Vol 2 #79, msg 5), it appeared that simple
translation was no longer possible (in addition to being unreadable)
due to a few of the unfortunate character mappings.
I also ran the same set though the MACSCRPT list server. I'll put the
character mappings into a text file and make them available on my site
later today.
Once again I have summarized the worst in a table, this time including
it as as script so you can see the character mappings as originally sent.
copy and run the following to get a translated version of the table:
Note: if the "as sent" and "maps to" characters as they appear in this
posting look the same, that means my info is still up to date.
If it turns out they have been adjusted I'll be pleasantly surprised.
-- ----------------------------------------------------------------------
"
as sent maps to symbol description alternate notes
------- ------- ------------------ --------- -----
173 [] 2 [] not equal (opt =) /= compiles
178 [>] 62 [>] less than or equal <= compiles
179 [] 4 [] greater than or equal >= compiles
194 [,] 44 [,] continuation character none tilde may be ok
199 [+] 43 [+] left chevron << doesn't compile
200 [;] 59 [;] right chevron >> but is readable
215 [W] 87 [W] lozenge (shift-opt-v) none uncommon anyway
"
set theStr to result
set {AppleScript's text item delimiters} to {"["}
set {theList, theChar} to {theStr's text items, "a"}
tell theList to repeat with theIdx from 1 to length - 1
set item theIdx to theChar & item theIdx's text 2 thru -1
set theAsc to item theIdx's last word
tell me to set theChar to ASCII character theAsc
end repeat
set {AppleScript's text item delimiters, newStr} to {"", theList as
string}
return newStr
-- ----------------------------------------------------------------------
Now I do realize that this is a free no-frills service and I do
appreciate
that Apple provides it to us. It may come as a shock to some that
AppleScript is discussed here and occasionally people post code snippets
and those snippets invariably use the Macintosh character set.
You'd think that a server which carries such text where a few special
characters which are significant for a script to compile would be
taken into consideration. It's inconvenient but acceptable for these
characters to be incorrectly translated, but allowing them to map to
other commonly used characters is very annoying and unnecessary.
I would really appreciate it if something were done to at least make
translation feasable. Modifying the translation script which used to
work fine to figure out whether a comma is really a comma or is actually
a continuation character or whether a greater than sign is really supposed
to be less than or equals is a little beyond my current knowledge of
text processing.
I think I've figured out a method for distinguishing between a '+' which
is really a '+' vs one that's supposed to be '<<' but I don't think it's
possible for a script to know whether '>' is supposed to be '>' or '=<'.
That would take AI and psychic ability that I can't endow upon a script.
But I don't think I should be expected to do be able to do this....
It seems to me it would be a lot easier to fix the problem by altering
the mappings (which don't have any logical pattern I can discern)
performed by the server.
Apple set up the ASCII table used by Macintosh computers. I'd think
they'd be able to find a way to translate it properly through email.
** CAUTION: Editorializing and personal opinion follows **
I suppose I could start griping about how difficult it is to write
modular reusable code which would make the copy and paste method of
scripting we communicate here less necessary but I guess I'll save
it for later. But it would sure be nice and a lot easier to manage
and write scripts if one could simply reference an external file or
two and have the sum of the included files execute in the same context.
As it works now, script objects loaded from external files aren't
even aware of other script objects and getting them to communicate
at all, much less inherit properties and handlers is so difficult
and non-intuitive that writing scripts involves more copy and paste
or reinventing of the wheel than it really needs to be.
Take a look at www.cpan.org to see what happens when a scripting
community has the option of writing and sharing modular reusable
code. You wind up with powerful modules that perform everything
under the sun.
Then we'd be exchanging libraries of like handlers, making scripts
much easier for the novice and more powerful (and a shorter
development cycle) for more advanced users. It sure seems like
load script should perform that function but since it does not
we really need or some form of import command to make AppleScript
more convenient for end users.
Whenever I write anything in Perl or JavaScript I have ready
access to just about every routine I've ever written available
to me with a simple import method and I know when I last updated
a function because it's in one place, not existing as several
incarnations strewn about the 400mb or so of applescript code
I have generated over the years.
I've been working on such a system for building scripts from a
central library of common routines selecting the most recent
version from a core set and will probably end up with an app
that builds stand-alone copies for distribution. Too bad about
the 32k text limit though...some finished projects won't be
viewable in Script Editor...another issue that should have been
fixed years ago.
Rant mode off.
So much for saving my second rant for later. Am I alone in this?
R23