This is something that people in English environments will probably never encounter.
However, Japanese environments have a slightly troublesome behavior, so I’m writing this as a memo.
Because of this behavior, I personally use the following workflow:
-
Development and early testing → SCPT
-
Final scripts / executable versions → saved as UTF-8 text applescript
Why do I do this?
The reason is explained below.
Exporting from Script Editor
When you use Script Editor.app and export an SCPT file containing non-ASCII characters to a text format applescript, the following usually happens for most languages.
Script Editor adds the extended attribute com.apple.TextEncoding with the value:
utf-16;256
and saves the file in UTF-16.
On the other hand, Script Debugger discards this value, converts the file to UTF-8, and saves it as UTF-8.
Since I often execute scripts from the terminal, this behavior is actually convenient for me.
But Japanese behaves differently
Only when Japanese is involved, the behavior changes.
(It may also occur in other languages, but I have confirmed it with Japanese.)
When exporting SCPT to a text applescript:
If the script contains characters not included in x-mac-japanese (such as emoji),
the behavior is the same as other languages:
com.apple.TextEncoding = utf-16;256
However, if all characters used in the script are within x-mac-japanese, the file is saved with:
com.apple.TextEncoding = x-mac-japanese;1
This is a legacy Japanese encoding, roughly similar to Shift-JIS.
Problem with Script Debugger
Script Debugger interprets x-mac-japanese as MacRoman when opening the file.
As a result:
-
ASCII characters remain readable
-
Japanese text becomes completely garbled
Because of this,
when editing in Script Editor, converting to text format can make Script Debugger very troublesome to use.
Behavior of Text Editors
Text editors such as:
-
BBEdit
-
CotEditor
-
Jedit (now discontinued)
check the com.apple.TextEncoding value when opening a file and determine the correct encoding.
When saving, they also write an appropriate com.apple.TextEncoding value.
Therefore, if you want to edit text applescript using regular expressions or batch replacements, these editors are a safe and convenient choice.
Visual Studio Code Behavior
Visual Studio Code ignores the com.apple.TextEncoding attribute entirely and tries to guess the encoding using its own logic.
In many cases it interprets:
x-mac-japanese → Shift-JIS
The real problem occurs when you convert the file to UTF-8 and save it in VS Code.
VS Code does not remove the com.apple.TextEncoding attribute, so the file may end up like this:
com.apple.TextEncoding = x-mac-japanese;1
content encoding = UTF-8
This creates a contradictory file.
When such a file is opened in applications that respect the extended attribute, such as:
-
Script Editor
-
BBEdit
the file will be interpreted as Shift-JIS, and the UTF-8 content will appear as garbled text.
At that point, it becomes very difficult to understand what actually happened.
My Workflow
Because of these issues, I use the following workflow:
-
Initial development and testing in SCPT
-
After the script is mostly complete and tested
-
Save it as a UTF-8 text applescript
-
Add execute permissions
-
Run it from the terminal
Using this method, I rarely run into encoding problems.
Also, saving scripts as text applescript has another benefit:
They appear in Spotlight search results, which is very helpful for finding scripts later.