易栈网-膘叔

前两天刚说为之漫笔进行了翻译《flex3实战》，今天就把试读章节放出来了。而且说“ 对反映问题最多的前3位读者，译者将于本书出版后第一时间，赠送新书一册，以为答谢。”

兄弟们加油啊。。

样章下载

• 第1章 认识Flex（PDF,1391KB）
• 第4章 布局和容器（PDF,919KB）
• 第8章 DateGrid、列表和树（PDF,793KB）
• 第11章 应用程序导航（PDF,1033KB）
• 第20章 使用效果（PDF,746KB）
• 目录（简明）
• 目录（详细）

样章下载完后，别忘了去http://www.cn-cuckoo.com/提交BUG呀

本来不想转这个的，因为原文好象不全，但我试着将原文最后一句去掉，好象也能读的通，就先转上来看看了。。。

原文：http://netsecurity.51cto.com/art/200902/112190.htm

IE有一个特性，那就是在将一个文件展示给用户之前会首先检查文件的类型，这乍看起来并没什么问题，但实际上这是相当危险的，因为这会允许IE执行 图片中的代码，即嵌入在一个图像中的JavaScript代码。引入MIME sniffing功能的初衷是用来弥补Web服务器响应一个图像请求时有可能返回错误的内容类型信息这一缺陷。

但是事不遂人愿，心怀不轨的人可以轻易滥用这一特性，如通过精心制作一个图像文件，并在其中嵌入可以被浏览器所展示和执行的HTML和JavaScript代码。本文将深入考察该问题，并为用户和网站开发人员介绍如何降低此问题带来的风险。

一、危险的MIME sniffing功能

对于Web 2.0应用程序来说，允许用户上载图像是一项基本的要求。但是，IE用户面对这些图片时却要小心了，因为IE的某些功能会为利用图片进行跨站点脚本攻击大开方便之门。

虽然许多大型站点都设法保护其访问者免受可能的JavaScript攻击，例如实现专门用于防御活动内容的过滤器等，但是他们却无法跟活动内容一刀 两断，因为对于个人简介、博客和论坛来说，JavaScript、HTML 代码和Flash小应用程序是不可或缺的活动内容。

此外，大部分交互型站点都允许用户上载和链接他们的图片，但是攻击者却可以利用此功能来颠覆IE为保证兼容性和提供额外的安全性而引入的某些功能。 攻击者只需在图像的开头部分嵌入一些HTML代码和JavaScript，那么当IE打开这个做过手脚的图像时，浏览器所做的不是显示图像，而是检测并运 行图像中嵌入的代码。

之所以出现这种情况，是因为浏览器可以用来确定文件类型的方式多种多样，例如文件扩展名jpg可以指出一个图像为JPEG格式，此外Web服务器还 可以在HTTP报头中定义Content-Type（在本例中为image/jpg），但是一般说来使用上载的文件的文件名扩展部分来指出文件的类型。

最后，大多数 Web 浏览器还会检查一个文件的开始几个字节（即通常所说的文件的“签名”），这几个字节通常为一些众所周知的字节序列，例如PNG、PK、JPEG、JFIF等等。

迄今为止，我们介绍了浏览器可以确定文件内容类型的三种方法，即通过文件本身的扩展名或文件开头部分的签名，或通过服务器响应报头Content-Type来确定文件类型。

不过，后来IE4引入了第四种方法，即通常所说的MIME sniffing或者MIME类型检测方法。所以，现在的IE版本都不自动地假定来自web的文件的内容类型就是服务器在HTTP报头中的所声明的内容类 型。IE浏览器既不信任文件名扩展部分，也不信任签名，相反，它是通过检查文件开头的256字节内容来确定文件的类型。

然而，只有当用户直接调用URL下载文件时IE才这样做。当使用IE打开HTML中的图像标签(IMG)所连接的本地存储的文件或者图像的时候，则不会进行嗅探。

IE引入MIME sniffing功能的初衷是用来提防服务器给出的错误内容类型指示的，但是攻击者却利用它来规避IE中的安全防御功能，即防止浏览器自动地执行所下载的文件（如hta文件）的那些功能。

此外，MIME sniffing还使得浏览器能够容忍在Content-Type声明中的偶然性错误，例如，如果服务器声明某文件类型为text/plain文件，然而实际提供的却是一个HTML文件，那么IE将它作为HTML处理。

对于常见的GIF、JPEG和PNG格式，只要文件扩展名、Content-Type和签名所指的类型相一致，那么浏览器就会对MIME sniffing所得到的结果置之不理。只有当文件扩展名、Content-Type和签名所指的类型有出入时，IE才会以MIME sniffing所确定的结果为准。

二、倒打一耙的MIME sniffing功能

现在，如何保护用户免受恶意服务器的侵害与如何为不正确地配置服务器的管理员提供有效帮助已经成为Web 2.0所面临的一大问题。 如果文件的扩展名、Content-Type和签名相抵触，那么浏览器会以内容为准。

所以，如果一幅图片的开头部分为一些HTML代码的话，虽然乍一看好像是无害的，但是实际上却可能相当危险，因为IE会执行图片中的代码。这为攻击 者把JavaScript嵌入图像提高了一个机会，所以他们可以利用这种方式执行跨站点脚本攻击，使用精心制作的图像来窃取受害者在当前访问的服务器上的 身份验证cookie，然后以受害者的身份登录到那个服务器。

三、援兵未至

微软公司已经认识到这个问题，并计划IE的新版本中加以修复。IE8不再探测图像，因此，它会忽略嵌入的HTML。此外，对于特定的下载，还可以通 过为私有的Content-Type以及authoritative指定值来关掉MIME sniffing功能，例如content-type=text/html; authoritative=true;。然后，IE会把文件当作服务器指出的类型来处理。

关键情况下，可以使用新的“X-Download-Options: noopen”头部来确保在站点上下文的外部显示相应的文件，这意味着即使HTML文件也能够安全的投递，因为浏览器只是将文件保存起来而已。遗憾的 是，IE8要想全面替代其他版本的IE尚需时日，在此之前，Web站点对此还是指望不上的。

四、急救措施

实际上，如今想要抵挡这些精心制作的文件也并非难事。自Windows XP SP2以来，用户已能禁用IE中的MIME sniffing功能，方法是打开浏览器的“工具”菜单中选择“Internet 选项”，点击“安全”选项卡，在“请为不同的区域的Web内容指定安全设置（z）”下面选择“Internet”图标，在“该区域的安全级别（L）”下面 点击“自定义级别”按钮，最后启用“基于内容打开文件，而不是文件扩展名”选项即可。然而，这样做会重新开放一些以前的古老漏洞！

这是否能够提供安全性只能够靠实践来证明。我们的重点不应该放在在用户间推广这个技巧，而是应该设法让web服务应用提供安全保障措施来保护访问者，并确保Web服务提供方的系统不向用户传送精心制作的图像。

管理员可以使用脚本检查上传到其服务器中的文件的类型的一致性。举例来说，如果某图像的文件名扩展部分为.jpg，并且文件起始字节部分的签名也指 出是相同的类型（在Linux下可以使用file image.jpg命令，而在PHP中可以使用getimagesize加以印证），经过上述验证后，服务器才能发出该文件。

这样，即使文件包含HTML 代码，IE也不会执行这些代码。然而要注意的是，通过这种方式只能保护图像的安全，同时服务器声明的Content-Type必须完全正确才行。 这个方法对其它格式均不起作用。

然而，要想达到绝对的可靠性，需要检查文件的前256字节是否HTML 代码

为之漫笔的博客是我比较喜欢订阅的博客之一，这其中有一部分是因为他关注的内容同样是我关注的对象之一，还有一部分原因是他还是我关注内容的书籍的翻译人员。比如现在的这本《Flex3实战》，现在还不知道何时能够上市，先来看看序吧。

原文地址：http://www.cn-cuckoo.com/2009/03/21/flex3-in-action-preface-532.html

Tariq Ahmed

多年来，我一直都在找寻一种方式，一种能够带给用户更好的在线体验的方式。而且，这个找寻历程从Google革命性的Google Maps站点引起轰动之前就已经开始了。我的意思是说，Web用户在很长一段时间里，都不知道还能有什么更好的在线体验。

在把Web当作文档发布系统使用的若干年里，用户体验曾一度在强大的本地桌面应用和乏善可陈的HTML应用之间摇来摆去。但是，贫乏的用户体验并没 有对HTML和Web构成冲击——Web作为平台中立的文档发布系统，事实上是非常名符其实的。开发人员和公司专注于Web是因为它支持快速应用程序开 发，而用户之所以接受眼前的一切则是由于——嗨！Web应用程序就是这个样子的。真的就是这个样子吗？

有件事曾令我百思不得其解。每次点击都会导致后台系统执行许多代码，而结果反映到UI上却只是一点点变化。而比这更糟的则是对数据库服务器频繁密集 的访问。对一名技术人员来说，解决这个问题最简便的办法就是多加内存、使用虚拟机装载，或者少花钱多采购一些杂牌服务器，然后大功告成。但是，我更关心用 户要为此付出什么代价。他们会对Web应用程序中常见的点击加等候习以为常；而且，对UI也没有多大的操作自由。不错，可以使用JavaScript；然 而，这只是在掌握更高级技术之前的选择。从投入产出角度讲，这样做往往得不偿失。

这时候，Java Applet和Flash问世了，而且乍一看它们正是我要找寻的东西。实际上，Applet作为一个解决方案并不合适，它的体积太大，下载也很慢，况且不 能跨平台使用。Flash挺有希望的，可是在设计师的工作环境中创建企业级应用程序，仍然不免有缘木求鱼的味道。

我在eBay的知识管理部门工作期间，也遇到了相同的问题。我需要找到一种方式，能够抽象出数据的复杂性，并且能让用户在可视的环境中方便地操作这些数据。

既而，Flex在2004年发布了（最初是V1，很快就是V1.5）。我当时有权作出采用它的决定，我们的团队也因使用它而感受到了完全不一样的体验。当时，我就知道Flex前途无量。因为Flex应用程序既具有桌面应用程序的强大特性，又能满足软件团队快速开发的需求。

作为Flex支持者，我把推动Flex社区发展当作自己的一项使命。我创建了CFLEX.Net（www.cflex.net），并坚信这个社区的规模越大，通过知识和代码共享产生的反推力也将越大，借此就可以促进这项技术的更快普及。毕竟，强有力的支持网络可以降低在组织中引入新技术的风险。

作为较早采用Flex的人，我在学习Flex的过程中走过不少弯路。主要原因是当时缺少相关书籍和参考资料。这种局面在Flex 2发布后得到了改观，大量的学习资源开始涌现。

我在2005年底离开eBay加入Amcom Computer Services，并在那里创建和管理一个开发团队。同学习任何新技术一样，要熟练掌握Flex也不容易。因此，最好的办法就是不断提升技能。在培训开发 人员使用Flex的过程中，我发现市面上的某些图书常常言不及义，很多显而易见的问题都没有提到。

为了进一步推动Flex社区的发展，我决定写作本书，希望它能解决读者经常会遇到的问题。本书一反按功能特性布局谋篇的常见模式，改为按创建应用程 序的自然进程组织内容。我只在必要时介绍必要的知识，不会过早地讨论复杂主题。同时，着意缩短的示例代码，也将有助于读者理解和上手。另外，我还发现把新 事物与已知事物联系起来，可以增强学习效果。因此，在适当的情况下，我会尽可能拿其他技术的实现原理来进行类比。

希望读者通过阅读本书能够深入理解Flex，并最终加入到Flex社区中——因为届时你也能够向周围的人共享自己的知识和经验。

而现在，则是准备学习Flex的时候。随着社区逐步发展壮大，越来越多第三方厂商会发布与Flex有关的技术，Flex用户组也会在世界各地不断涌现。

随着其他厂商的先后跟进，RIA领域将迅速升温——Adobe再次证明自己走在了前列。我们正处于一个令人振奋的时代！以HTML为基础的Web应 用程序始终会占有一席之地；然而，现在是该把你的技能提升到一个新高度的时候了。因为，这个产业的向前发展不会以个别人的意志为转移。

现在请坐下，系好安全带，旅行就要开始了！

TARIQ AHMED

当然，这不是我说的话，不过，要是我说的话，我也不会升级到IE8.
身为一名WEB开发人员，要考虑的是使用量最多的浏览器的用户，那，无非就是IE6、IE7和FF、opera等用户了，甚至，chrome我们也无须过多考虑，毕竟这部分的用户太少了，而且即使要考虑也很方便，毕竟除IE外，其他浏览器都是支持W3C标准的。所以，IE8在没有占有市场份额很大前，我也是不会升级的。最多找找那种多浏览器兼容软件进行测试的时候会用用，其他时候，一概不做考虑。

这名作者又是怎么说的呢？让我们来看看：

E8发布以来，在Twitter及不少SNS都收到朋友们的留言，询问我对IE8的评价。我没有升级，也不太愿意升级，只能先求助于他人。无奈，我 目前还真没看到什么让我心动的“评测”，我想，也许是IE8正式版本身并没有带给我们（如果给您惊喜了，请留言告知）太大的惊喜吧。更何况，我很担心安装 好IE8之后，我的那些只能在IE下使用的插件、网站是否能继续正常运转。尤其是看到Fenng的一推（“各位安装了 IE8 不能用支付宝的朋友，别问我了。这事儿我决定不了”），让我还是忍住了没去点击那个已经下载完毕的安装包。

我觉得写一篇不负责任的评测毫无乐趣，而且，IE8也与我毫无吸引之力。作为一个转型回ActionScript开发（是的，AS的世界比Web开 发单纯许多，屁事儿也少很多）的开发者，我对它能多好地支持CSS、JavaScript也基本没有兴趣了（我承认在beta版时曾经很喜欢它的一些创 意，例如Debugger模块和插件开放）。作为一个用户，IE8也没有任何让我升级的理由。对于一个拥有IE6、IE7的用户来说，升级一个IE8甚至 还不如下载一个Chrome的安装包快吧（你比较过么？如果我错了，请留言告诉我测试结果）。IE8的几个新特性，我觉得在其他浏览器中已经全部都具备了。

总之，我没有升级到IE8，而且，如果你平时多用Chrome和Firefox，我觉得也毫无升级到IE8的必要。如果你仍然对IE8究竟是怎么回事充满好奇，可以推荐看看我的一位校友的博客文章（这里）。

评测都是扯淡，让我们用数据说话（为了尽量客观，数据来自Analytics，选自awflasher.com域名下下非技术类文章，如果你好奇具体如何筛选可见此文）：

以下是IE8正式发布之后，8.0版本占所有IE浏览器的百分比（占所有浏览器的比比这还要低），这还包括了相当一部分beta版用户（根据这个时间段之前三天的统计，估计能有1.34%左右），也就是说，大多数IE用户并没有太热衷升级到8.0

这是去年9月份Chrome发布时前2天的数据，Chrome已经占到所有浏览器的2.76%了：

当然，IE8的出现如果能进一步消灭IE6用户，我觉得还是颇有意义的（可以为我们Web开发者省很多时间），可是，这件连IE7都没有完成好的任务，IE8真的能做到么？

原文：http://www.awflasher.com/blog/archives/1731
是呀，在这么低的市场份额下，如果我们要考虑兼容，那么付出的代价非常大，而事实上，这部份用户，却大多是WEB开发人员，你说平时一普通人，谁TMD会去升级呀，又要考虑不稳定，说不定连网银也不能用了。你会用吗？

CB纯粹是一堆程序员发泄的地方，因此，在上面不可避免的会出现一些好的东西，比如这个：9 个基于JavaScript 和 CSS 的 Web 图表框架

图表，我个人还是觉得用FLASH来做比较好，比较有动感，而且现在所有浏览器都支持FLASH。它还是比较有前途的。FLASH和JS在运行的时候占用CPU应该是JS相对较高吧？FLASH图表还是有一些很不错的。比如open flash chart，就是一个开源的FLASH图片控件。

不过，标题是JS的，我当然还是把CB原文贴过来喽：http://www.cnbeta.com/articles/79418.htm

原文如下：

新闻来源:woork.blogspot.com
jQuery, MooTools, Prototype 等优秀的 JavaScript 框架拥有各种强大的功能，包括绘制 Web 图表，使用这些框架以及相应插件，我们可以非常轻松地实现曲线图，圆饼图，柱状图等 Web 图表的绘制，而不必象以往那样通过复杂的 Flash 技术实现。本文介绍了9个优秀的基于 JavaScript 与 CSS  的 Web 图表框架。
jQuery, MooTools, Prototype 等优秀的 JavaScript 框架拥有各种强大的功能，包括绘制 Web 图表，使用这些框架以及相应插件，我们可以非常轻松地实现曲线图，圆饼图，柱状图等 Web 图表的绘制，而不必象以往那样通过复杂的 Flash 技术实现。本文介绍了9个优秀的基于 JavaScript 与 CSS 的 Web 图表框架。
1. Flot


Flot 是一个纯粹的 jQuery JavaScript 绘图库，可以在客户端即时生成图形，使用非常简单，支持放大缩小以及鼠标追踪等交互功能。该插件支持 IE6/7/8, Firefox 2.x+, Safari 3.0+, Opera 9.5+ 以及 Konqueror 4.x+。使用的是 Safari 最先引入的 Canvas 对象，目前所有主流浏览器都支持该对象，除了 IE, 因此在 IE中使用 JavaScript 进行模拟。这里有一些实例。
2. JS Charts


JS Charts 是一个免费的基于 JavaScript 的图表生成器，表格绘制非常简单，几乎不需要编码，也不需要插件和服务器模块，使用XML 或 JavaScript 数组缓存数据。
3. TableToChart
TableToChart 是一个 MooTools 脚本，可以将 HTML Table 对象中存储的数据绘制成图表。你可以使用 table 标签生成图表，柱状图，曲线图，圆饼图等。
4. PlotKit
PlotKit 是一个 JavaScript 绘图库，支持 HTML Canvas 标签，也支持 SVG。
5. Yahoo UI Charts Control


YUI Charts Control 可以在网页上将表格数据转换为图表，支持柱状图，曲线图以及圆饼图。支持 DataSource 工具，可设置的轴，鼠标盘旋提示，图表组合，以及皮肤等功能。
6. ProtoChart


ProtoChart 是一个基于 Prototype 和 Canvas 标签的开源库，这个库深受 Flot, Flotr, Plotkit 等启发，支持曲线图，柱状图，圆饼图等，可以在同一个图表上显示多套数据，支持可定制的图例，网格，边界以及背景图。支持 IE6/7, Firefox 2/3 以及 Safari，甚至支持 iPhone.
7. EJSChart


EJSChart 支持鼠标追踪，鼠标事件，按键追踪与事件，缩放，滚动，交互等功能，将用户体验上升到一个新高度。支持曲线图，面积图，离散图，圆饼图，柱状图等形式，拥有完备文档的属性和方法可以帮助实现很好的定制。
8. fgCharting
fgCharting 是一个很出色的 jQuery 插件，支持多种图形。
9. Pure Css Data Chart


以往的数据展示往往通过 flash 实现，现在，我们可以通过纯粹的 CSS 实现类似的功能。CSSGlobe 有一个非常实用的教程帮你实现基于 CSS 的绘图，甚至不需要 JavaScript。

本文国际来源：http://woork.blogspot.com/2009/03/useful-scripts-to-plot-charts-in-web.html
中文翻译来源：COMSHARP CMS 官方网站