Applescript 2.0 (Mac OS X 10.5 'Leopard ')

[Kevin_Bradley]

Applescript finally hits version 2.0! AppleScript 2.0 was released as part of Mac OS X version 10.5 and requires Mac OS X version 10.5 or later. The number of changes isn’t perhaps as many as previous revisions, but they are major changes. Let’s take a look.

Apple provided the usual disclaimer in their release note. It states that scripts written for older versions of AppleScript will work in 2.0 and that scripts written for 2.0 will work with versions back to version 1.1 if they don’t use features added since that version.¨

Unicode Text

As we all thought might happen, all text in Leopard’s Applescript is now unicode. This means that the text, string, and unicode text classes are all functionally the same. If you test the class of any of these items, you will get back the text class and they will all compare as equal. However you will get unicode behavior whether you specify as unicode text or not, which may be different than the string behavior for some languages, especially for operations like words of.

This also means that the ascii number and ascii character commands are no longer valid. In their place, text items now have an id property that returns the unicode value for a text character or a list of values for a string longer than 1 character.

Text characters that combine characters (like é or Ã¥) will return both the text value and the combined character, and Applescript 2.0 will count them as a single character when getting the length of a string. Other changes required by the switch to unicode are (quoted from Apple’s release notes):

Now that AppleScript preserves all characters correctly worldwide, it is also stricter about the text used in scripts. AppleScript syntax uses several non-ASCII characters, such as "≠" and “¬”. These characters must be typed exactly as the AppleScript Language Guide for AppleScript 1.3.7 describes. For compatibility with Asian national encodings, “《” and “》” are allowed as synonyms for “«” and “»”, since the latter do not exist in some Asian encodings.

Matching of text item delimiters now respects considering and ignoring attributes, where previous versions ignored them. The expansion attribute is no longer supported.

The change to all-Unicode necessitated a change in the read and write commands and how they deal with text encodings. Formerly, they would write string objects using the primary encoding and Unicode text objects as UTF-16, unless instructed otherwise using an as parameter. Now that there is only one text class, the read and write commands rely solely on the as parameter to determine the encoding: with no as parameter, as text, or as string, they use the primary encoding; with as Unicode text, they use UTF-16. For the most reliable results when creating scripts that will run on both 2.0 and pre-2.0, always specify the encoding explicitly using as text or as Unicode text, as appropriate. [4421553]

Because text item delimiters now respect considering and ignoring attributes, they now are case-insensitive by default. Formerly, they were always case-sensitive. To get the same behavior with 2.0 and pre-2.0, add an explicit considering case statement.

Because AppleScript 2.0 scripts store all text as Unicode, any text constants count as a use of the former Unicode text class, which will work with any version of AppleScript back to version 1.3. A script that contains Unicode-only characters such as Arabic or Thai will run, but will not be correctly editable using pre-2.0 AppleScript: the Unicode-only characters will be lost.