近日由于工作原因，需要把SWF文件放在一个子目录，而根目录内的index.html则把处于子目录的SWF文件嵌入并显示出来。很简单，只需要把movie这个参数做相应的修改便可。
但是接下来的问题确出现了，由于SWF文件是一个类似ViewPoint这样的程序，需要动态加载图片，文本，音乐，以及视频，在数据方面还需要调用AMFPHP方法，需要执行上传下载服务。结果许多涉及到网络请求的很多服务都无法使用，经过一个下午的仔细研究终于得出答案：
1、基于NetConnection的所有链接必须使用相对SWF文件的路径地址。
2、FLV播放由于也是基于NetConnection所以同上。
3、Upload服务虽然不是基于NetConnection上，但是也同上。
4、那么剩下的例如MP3，图片，URLLoader读取文本文档或者PHP脚本返回的数据，这些都是相对HTML页面的路径。
这样疑问就出来了，为什么在Flash里面的相对路径机制这么混乱呢？我一开始也是有点觉得奇怪。但是仔细一想，并测试了几个小程序之后终于发现这里面的小秘密了。
首先，常规的读取Flash Player会依靠我们的浏览器来请求和读取，他只是监控当中的数据进度。所以相对路径的计算则是交付给浏览器来完成，浏览器根据当前页面的URL来计算要请求的位置。
其次，由于安全机制FlashPlayer并不能完全访问浏览器里面的数据，我估计其中就包括当前的URL位置（这也是为什么Flash自身的包里面没有提供获取当前地址栏的URL的相关类），连Flex都是利用JavaScirpt来获取当前地址的。
既然Flash Player无法获取当前的URL地址，那么怎么来计算相对路径呢？唯一的方法就是通过嵌入Flash文件的时候浏览器传入给Flash Player容器的参数，这里面当然是只有SWF的原始地址是唯一有用的了，所以Flash Player只能通过这个救命稻草来或许有限的路径信息。
这样，事情就变得很明了了，NetConnection是基于Flash自家的技术，当然建立的连接也是由Flash Player自身来完成的了，所以我们的AMF数据是无法被浏览器缓存的，而Upload服务就更不用说了，在Flash Player 8 以前，Flash 压根就没有文件上传下载的API，之前的解决方法都是通过调用JavaScirpt来解决，而自从Flash 8 问世以后 Flash才能方便的监控上传和下载，但是这个监控必须是通过其自身的API来完成。而这一步和浏览器也完全没有任何关系。所以其地址的计算也是相对SWF本身的路径来完成。 |
