四字符代码(又名OSType
、又名UInt32
)曾经是 Apple 事件和其他经典 Mac OS API 的基本构建块,在这些 API 中,极致的紧凑性和机器效率远比开发人员的便利性或可读性更重要。(请注意,System 7 必须在 8MHz 68030 机器上运行,并且只有几 MB 内存。)这些旧 API 中的大多数早已被取出并拍摄,或者至少被更现代的 API 大量抽象化(例如 UTI API 没有'不仅提供原生 UTI 字符串支持,而且还封装了所有旧的 MIME 类型和 4CC 废话)。
唯一一次泄露旧的废话是在使用同样古老的硬皮 API 时,比如clipboard info
现在非常痛苦和过时的 API。它返回的某些类型名称在 AS 的“chevron”语法( , 等 vs , )中显示为原始 4CC 的事实«class weba»
仅«class RTF »
反映string
了Unicode text
AppleScript 自己的内置字典中该代码缺少相应的关键字(即仅限于由 AS 开发人员手动定义的关键字代码映射)。即使您确实以其中一种替代格式检索文本剪贴板数据,它通常对您也无用,因为 AS 无论如何都无法处理该类型的数据,除非您能找到另一个同样古老的 API 也可以理解它。
UTI 系统功能强大且成熟,并且从 10.6 左右开始得到广泛支持,因此没有理由在可用时不使用它,并且有充分的理由避免它们早已取代的古老、粗糙、残缺的方案。不这样做只是在为你自己做一根棍子:这些 API 仍然存在于 AS 中仅仅反映了 AS 团队未能与 Apple 的其他部分同步地弃用/现代化/替换它们;不建议使用它们。
..
至于 JXA 和一般的符号 AE 类型的问题......
JXA 根本无法代表 4CC,这是因为它的作者是在应用程序自动化方面没有实际经验的外行,而且他们一再未能对自己的技术(Scripting Bridge、JXA 等)进行测试或从我们这些人那里获得专家建议谁做的。
事实上,JXA 根本不能表示类型和枚举名称 - Unicode text
, document
, yes
//等(即类型no
和的值) - 。由于 JS 没有原生 Symbol 类型,它的作者认为他们会很聪明,只使用 String,并让桥决定是否将这些字符串打包为/而不是描述符,然后根据什么类型在 Apple 事件中发送它们命令的字典定义说的值是必需的。ask
type class
constant
typeType
typeEnum
typeUnicodeText
这适用于微不足道的情况,例如close saving [yes|no|ask]
,字典定义包含确定实际所需的所有信息类型是必需的,但当您开始处理无法从字典中推断出所需类型或字典不够完整或不正确的更复杂用例时,这并不奇怪。对 AE 技术有深刻理解的人已经意识到这一点:应用程序字典的 AETE/SDEF 格式从来都不是完整、全面、准确的接口描述语言;仅用于将人类可读名称(又称“应用程序关键字”)映射到相应的低级 4CC 和/或从相应的低级 4CC 映射的翻译表,其他所有内容都只是作为用户文档存在,不保证完整性或正确性;因此,尝试使用后者做任何其他事情与您期望的一样可靠。
有趣的是,JXA 的 10.11 预发行说明表明他们默认禁用了这种“神奇”的转换行为(毫无疑问,因为它以许多其他令人兴奋的方式吸引用户,而其作者未能预料到)。这些注释中没有迹象表明他们已经添加了一个Symbol
类来在 JS 中正确表示 AE 类型和枚举名称,所以看看接下来还有什么问题应该很有趣。