>>Dummy mode is basically on at this point, but can anyone point me to/provide an explanation of how AppleScript's i18n support works w.r.t. strings and string literals, especially on systems that use more exotic encodings (e.g. Japanese)?
> String literals only work for ASCII reliably, and even some ASCII characters might be tricky (tilde and backslash in Japanese). Beware that there's no round-trip fidelity when storing literals: a script that works fine after you type it in Script Editor may fail after it's saved and reopened from disk.
Yeah, thought that might be the case.
> A string is of course just an array of bytes (typeChar), so you can send these back and forth safely, as long as no conversions are performed. But each operation applied to the string will have its own ideas about encoding (usually MacRoman or the system encoding such as MacCyrillic or MacJapanese).
Righto. TC only uses strings for storing byte data so I don't figure ASers will be doing much in the way of native language operations on these values.
However, I wasn't sure if AS, when operating in one of the more exotic encodings (e.g. MacJapanese), might have done any kind of automatic conversion when packing/unpacking typeChar data at its Apple event bridge, as that's the sort of unannounced action that'd really stuff up binary data that's being stored under typeChar for sake of convenience.
The one other question would be if the 'read' and 'write' osaxen do any localization tricks when reading and writing as 'string', since that's where scripters are most likely to move binary data in and out of their scripts? Or can I safely assume that these osaxen respect the single-byte-encoding nature of typeChar data as well?
BTW, I've posted a copy of TC for feedback purposes at: