各种浏览器差异悬殊，开发者应如何在网页中嵌入flash才是最佳方案？本文介绍的原理亦被应用在swfobject2.0中。 
　　“怎样才是最佳的flash嵌入方式呢？” 
　　本来应该是一个简单的问题，但是应该会引起很多不同的看法和争论，因为可用的嵌入技术很多，而每种都有其支持和反对者。这篇文章里，我将详述嵌入flash的复杂性和技巧性，并且对最流行的嵌入方法加以考察，看看它们到底好不好。 
　　好的flash嵌入方法的关键 
　　在进入本质性讨论之前，让我们先定义一下理想的flash嵌入方法。在我看来，下面这些因素是最重要的： 
　　遵循标准 
　　web标准为浏览器厂商、工具软件程序员以及网页作者提供了一种易于理解的通用语言，使得所有的用户都得以避免兼容性、垄断和专利侵权的问题。他们也让你——开发者——能够创建出项目所需的正确的网页。 
　　跨浏览器支持 
　　支持所有主流浏览器和常见操作系统是很关键的需求。为了支持我进行的研究，我创建了一个flash嵌入测试套件来评估浏览器对于各种嵌入方法的支持。该套件对各种不同的flash发布设置、流加载和脚本类型作了相应测试。 
　　对替换内容的支持 
　　无论何时你想要创建对搜索引擎和对未安装插件的浏览者友好的网页时，替换内容都是你最好的朋友。 
　　避免flash和播放器的不匹配 
　　不幸的是，对所有人来说，flash播放器总是试图去播放flash内容，不管flash播放器的版本和flash内容发布时的版本是什么。如 果使用老版本播放器的flash没有用到新版本播放器才支持的功能的话还好，否则你的用户将会看到不完整的内容或者完全就没有内容。 
　　对活动内容的自动激活[1] 
　　由于Eolas专利侵权问题，微软更新了它的浏览器，以至于浏览者再也不能直接与“活动内容”，也就是用object和embed标签嵌入的ActiveX控件进行交互。 
　　简而言之，微软浏览器要求用户先点击才能跟活动内容交互。为了避免被起诉，Opera也引入了类似的点击激活机制。这些机制就像公路上的减速带，你需要刹个车，慢慢开过去。它会让一般用户搞不清状况，让有经验的用户感到恼火。 
　　容易实现 
　　简单就是胜利。轻松就能做到的事情为什么要去费尽力气？

Flash嵌入基础：embed和object 
　　有两个标签可以让你在网页上嵌入flash。一个是已有的embed，所有的浏览器都支持它。（raquo; 表示连接换行 -Ed） 
　　 
　　src="myContent.swf" width="300" height="120" raquo; 
　　pluginspage="http://www.adobe.com/go/getflashplayer" /> 
　　 
　　另一个是W3C建议的object. 因为W3C规范给如何实现插件内容留了相当大的空间，结果出现了两种不同的object实现方式。 
　　大多数现代浏览器实现了遵循标准的方式，将embed标签替换为object的MIME类型，以此来确定插件的类型。 
　　这种方式是各种浏览器通用的，所以是比较好的实现。 
　　第二种实现来自Windows的IE，其中需要定义object的classid属性，这样浏览器才能正确载入Flash播放器的ActiveX控件。这种实现是有效的，但不是浏览器通用的。 
　　 
　　 
Alternative content
　　注意：这两个例子中我都故意省略了codebase参数，这个参数通常指向Adobe的Flash插件安装包位置，用来在浏览器没有安装插件的时候自动下载。但这是和标准中禁止文档访问跨域资源的精神相违背的，而且有些现代浏览器并不支持。 
　　为什么还有embed 
　　从web标准的观点来看，可能会觉得直接砍掉embed标签就可以了，但这从来没有也永远不会成为一个W3C建议，因为专利问题。但是实际上它 确实比单独的object标签拥有更好的跨浏览器支持。所以它现在成了许多流行的站点诸如Google Video和Brightcove的选择。 
　　尽管web标准是为了避免兼容性问题而建立的，但embed却比W3C支持的object更为明确。embed的严格实现规范和良好支持已经把 它变成了一项事实上的标准，它会一直阴魂不散，直到object标签得到广泛并且足够长时间支持，长到已经可以忽略那些不喜欢它的浏览器版本。 
　　那么现在所谓的浏览器支持性的问题到底是什么？ 
　　web标准不被支持的地方 
　　object的两种实现并没有摧毁web标准，但它是很多问题的根源。后果之一是，我们需要找一个方法去把两种object实现联合在一起构成一个统一的技术。更糟糕的是，我们不得不处理那些（曾经）对object不完全支持的浏览器。来看下这些问题： 
　　* 一般的object实现在Windows IE下是不行的，IE加载了插件和swf文件，但却根本不显示flash内容。 
　　* 我们加入movie参数，以部分地联合这两种方案的时候，IE可以显示flash内容了，但却不进行流加载。 
　　* 当我们完全把两种方案联合在一起的时候，IE正常了，但是Gecko核心的浏览器忽略了Flash内容并且显示替换内容。 
　　object的一个特性是，你可以把不同的实现方案嵌套放在一起： 
　　 
　　不幸的是，老版本的IE在处理嵌套的object的时候存在bug：试图去渲染两个flash。 
　　更糟的是，Mac OS 10.3上，版本在1.2.2以下（含1.2.2）的Safari会忽略object里面嵌套的param标签，虽然他们支持embed标签的同样属性。 
　　注意：你可能会问你自己，上面的方法里把同样的内容、参数、属性写两遍到底有多大意义。比如说，这种联合方法让JavaScript跟Flash内容通信更困难，因为你要先测试你到底在跟哪个object通信。 
　　我们朝着一个更好的世界缓慢的进步：这些bug中有的正在被逐渐解决，但是bug到无以复加的IE的object实现仍然使得object的采用困难重重。我们只能将解决的希望寄予在不久的将来了。

为什么object比embed更好 
　　尽管object缺乏跨浏览器的支持，但是object仍然比embed提供了更多的东西，为了跟进标准，它还提供了对于替换内容的良好支持。 
　　object标签允许你在它里面包含替换内容，如果这种实现不被支持，或者插件没有安装，那么替换内容将被显示。这个内容还将被搜索引擎收录，使得它成为创建对搜索引擎友好内容的好帮手。 
　　embed标签支持noebmed标签所提供的替换内容，但是它只被那些连embed标签都不支持的浏览器支持，例如Windows Mobile上的IE。不像object，当embed被支持但是却没有安装flash插件的时候，它并不支持替换内容。它依赖于pluginurl和 pluginspage属性来显示一个谜一样的破烂图片，点一下可以去安装插件。非常的90年代。 
　　我相信提供一个关于插件内容的替换内容，并且同时给出巧妙的提示，让用户知道下载flash插件会获得更好的体验，这样的解决方案是更好的。（还有一个原因就是我们不是那么需要这个经常被用错的codebase属性） 
　　纯标签方法的局限性 
　　考虑一下我们之前定义的原则——顺应标准，跨浏览器支持，支持替换内容，避免播放器与内容不匹配，自动激活活动内容，和便于实现——显而易见的是仅靠标签能做到的太有限了。 
　　虽然标签表示了flash内容或替换内容的意义，但它没法给我们提供一种解决方案来避免flash内容和播放器不匹配或者一种变通方法来避免点击激活，而且它也并不总是最简单的实现方法。 
　　不过，还是简单的看一下现在最流行的标签“联合”方法吧。 
　　两次烹饪法 
　　如你所见，这个办法仅仅把通用的和专用的标签弄在一起，显然是只为了解决跨浏览器支持问题，并不和标准兼容。 
　　两次烹饪法显得冗余，并且使你的网页不标准，还没有提供一种显示替换内容的机制。它易用的唯一原因是Flash IDE生成了它：所以，别再让任何人就凭着记忆像这样写了。 
　　嵌套object法 
　　嵌套object法是两次烹饪法的一个不错的替代品，因为它遵循标准并且支持替换内容。我们看下： 
　　 
　　不幸的是，它支持仍然缺乏跨浏览器的支持，对于IE的嵌套object bug和Safari的嵌套param bug仍然无能为力。一个常用的方法是利用IE的条件注释来避免这个浏览器的陷阱。 
　　 
　　 
Alternative content
　　 
　　除了前面提到的冗余问题，这个方法还更麻烦，因为它使用了一个丑陋的权宜方式，会使得用来生成页面的服务器端代码更加复杂。

请亲们到原址http://www.enet.com.cn/article/2009/0408/A20090408456744_4.shtml看图片