1、 言归正传,这次教程,解决的是AE脚本的运行问题。之前我也有一篇经验,专门归类了ExtendScriptToolkit这个拓展脚本工具包的运行异常,而这次带来的是AE脚本执行时遇到的问题。
2、 首先,分析一下下图,不知道有谁可以找到它们之间的区别呢,呵呵……
3、 以上展现的是我分别新建了两个文本文件一个是“1.txt”,内容是“alert(“abc”);”;另外一个是“2.txt”,内容是“alert(“秦时明月”);”根据图片上的显示可知,它们在ExtendScriptToolkit里面都是可以正常执行的,都有对话框显示。
4、 好的,接着仔细看这两个脚本文件在AE中的执行情况哦。
5、 看到异常了吧,为什么出现这种情况呢。请大家想一想。在揭秘之前,我再让大家看一堆组图,嘻嘻。
6、 以上组图大致的意思大家应该知道了吧,就是将文本文件“2.jsx”里面的内容“alert(“秦时明月”);”拷贝到打开的ExtendScriptToolkt界面中(当我们直接运行这个拓展脚本工具包的时候,它会默认生成一个文件名,叫“来源1.jsx”),保存这个“来源1.jsx”文件,从AE中调用这个和“2.jsx”一模一样的脚本,运行情况和脚本”2.jsx”完全不同,中文字符串可以正常显示了呢,没有出现之前的报错信息。
7、 再耐下心看看“来源1.jsx”和“2.jsx”这两个文件的大小,我们就可以发现其中的奥秘啦。
8、 从这些组图中,我们可以知道,为什么使用记事本编写的带有中文字符串的脚本代码,在AE中运行异常了吧。这都是文字编码惹得祸。从上图可知,在ExtendScriptToolkit中保存的jsx文件虽然也是一个文本文件,但是它们的编码都是默认为“UTF-8”,而我用记事本编写的代码,经过该后缀名所得到的脚本代码文件的编码都是默认为“ANSI”。众所周知,这种“ANSI”文字编码的文本文件,我们用记事本等等文本编辑软件打开是没有任何问题的,比如我之前的操作,将中文字符保存在txt里,并没有一丁点数据损失,而如果用这种编码方式来作为一个脚本文件来执行的话,那就出现问题了,由于AE、PR等其他软件本身支持的文本编码方式有自己的行业标准,因此脚本文件需要在执行前指定文本编码方式,方便AE等软件按自己所定制的标准直接调用执行。 有些人会觉得奇怪,为什么在ExtendScriptToolkit里执行没有问题呢,这个是因为,这个拓展脚本工具包里面早已定好了默认的执行规范。自动将在本工具包界面上的代码,按照“UTF-8”的方式来执行,但这并不会改变原有的文本编码方式。基于这种执行机制,拓展脚本工具包就能无视文本可能存在的多种编码方式来正常执行脚本代码了。不信的话,你可以将那个“2.jsx”的编码方式改成“Unicode”,再到ExtendScriptToolkit里面执行,看这会不会影响代码执行的最终结果。
9、 另外,由于AE、PR等软件,并没有ExtendScriptToolkit这种傻瓜式的执行机制,所以,要想让你编写好的脚本能够支持多种国家语言。最好在ExtendScriptToolkit里面编写;如果你硬要在记事本中编写的话,那么在修改后缀名的时候,记得也要把文本编码方式也修改成“UTF-8”哦。