Re: ASCII vs. MacRoman (was Re: Standard Additions 'read' command - basic questions)
Re: ASCII vs. MacRoman (was Re: Standard Additions 'read' command - basic questions)
- Subject: Re: ASCII vs. MacRoman (was Re: Standard Additions 'read' command - basic questions)
- From: Christopher Nebel <email@hidden>
- Date: Tue, 20 Jan 2004 11:08:08 -0800
On Jan 20, 2004, at 4:08 AM, Axel Luttgens wrote:
[I]t's misleading for "ASCII character" to work with values above
127, which are not ASCII. ... It might be useful to rename it to
something like "MacRoman character" and provide "ASCII character" as
a synonym (so "ASCII character" could still be used, but it would
decompile to "MacRoman character").
You're absolutely right by writing that "ASCII character" (as well as
its twin "ASCII number") has been a confusing terminology choice. But
I'm not sure something like "MacRoman character" would be a better
one. After all, the whole matter had (note the past form) barely to
do with encodings. ...
Aside from the reasons Axel points out, calling it "MacRoman character"
would be wrong. It takes your number and turns it into typeText, which
is defined as bytes in your primary text encoding. This is MacRoman
for most American and European users, but if you try it with Eastern
European or Japanese, you'll get wildly different results. The "ASCII"
names were selected long before I came to Apple -- at this point, I
consider both the names and the functions themselves to be completely
morally corrupt. Some day we'll introduce proper Unicode versions, and
then hopefully we'll be able to take the "ASCII" versions out behind
the barn and shoot them.
Should the class of the delimiter define the interpretation of a file
contents?
Should the "as ..." part (defaulting to some class -which one?) induce
a coercion of the delimiter?
Should the "as... " and the delimiter mandatoryly be of the same class?
Should the idea of byte-per-byte access to any file just be abandoned?
The current rule is that the "as" parameter determines the "format"
(for lack of a better word) of the data. By default, it's typeText,
which is not perfect, but usually what people want, meshes well with
ASCII number/character (crosses self), and is as far as I know
guaranteed to work with any byte stream, unlike any of the Unicode
encodings. I have no plans to change this, as it makes more sense than
any alternative I've been able to think of. The notion of raw binary
I/O is somewhat counter to AppleScript philosophy, but undeniably
interesting. Gotta go see what the Perl people are up to on this
topic...
--Chris Nebel
AppleScript Engineering
_______________________________________________
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.