博客园_STARTING UP……

重温一下CSS语法

2012-02-06T11:56:00Z

css的语法结构仅仅有三部分组成：选择符（Selector）、属性（property）、和值（value）。
使用方法：
selector {Property:value;}

选择符（Selector）指这组样式编码所要针对的对象，可以是一个XHTML标签，如body,h1；也可以是定义了特定的ID或CLASS的标签，如#main选择符表示选择<div id="main">，即一个被指定了main为id的对象。浏览器将对css选择符进行严格的解析，每一组样式均会被浏览器应用到对应的对象上。

属性（Property）是CSS样式控制的核心，对于每一个XHTML中的标签，CSS都提供了丰富的样式属性，如颜色、大小、定位、浮动方式等。

值（value）是指属性的值，形式有两种，一种是指定范围的值，如float属性，只可能应用left，right，none三种值，如width能够使用0-9999它，或其它数学单位来指定。

在实际应用中，我们往往使用以下类似的应用形式：
body {background-color:blue;}

类型选择符

在上边的body{}便是一种类型选择符。所谓类型选择符，是指以网页中已有的标签类型作为名称的选择符，body是网页中的一个标签类型，div也是，span也是。因此以下选择符都是类型选择符，而它们将控制页面中所有的body或div或span：
body{}
div{}
span{}

群组选择符

除了对单个XHTML进行样式指定，同样可以对一组对象进行相同的样式指派
h1,h2,h3,p,span{font-size:12px; font-family:arial;}
使用逗号对选择符进行分隔，使得页面中所有的h1,h2,h3,p,span都将具有相同的样式定义。这样做的好处是对于页面中需要使用同样式的地方只需要书写一次样式表即可实现，减少代码量，改善css代码的结构。

包含选择符

h1 span{font-weight:bold;}
当我们仅仅想对某一个对象中的子对象进行样式指定时，包含选择符就派上用场。包含选择符指选择符组合中前一个对象包含后一个对象，对象之间使用空格作为个分隔符。如本例子所示。我们对h1下面的span进行样式指派，最后应用到XHTML是如下的格式：
<h1>这是我们的一段文本<span>这是span内的文本</span></h1>
<h1>单独的h1</h1>
<span>单独的span</span>
<h2>被h2标签套用的文本<span>这是h2下的span</span></h2>
h1标签之下的span标签将被应用font-weight:bold的样式设置。注意，仅仅对有此结构的标签有效，对于单独存在的h1或单独存在的span及其他非h1标签下属的span均不会应用此样式。
这样做能够帮助我们避免过多的ID及CLASS的设置，直接对所需设置的过犹不及进行设置。
包含选择符除了可以二者包含，也可以多级包含，如以下选择符样式同样能够作用：
body h1 span stront{ font-weight=bold;}

标签指定式选择符

如果既想使用id或class，也想同时使用标签选择符，可以使用如下格式：
h1#content {}
表示针对所有id为content的h1标签。
h1.p1 {}
表示针对所有class为p1的h1标签。
标签指定式选择符在对标签选择的精确度上介于标签选择符及id/class选择符之间，也是一种经常使用到的选择符形式。

组合选择符

对于上述所有CSS选择符而言，无论是什么样的选择符，均可以进行组合使用。
h1 .p1 {}
表示h1标签下的所有class为p1的标签。
#content h1{}
表示id为content的标签下的所有h1标签。
h1.p1,#content h1{}
以上两种进行群组选择。
h1#content h2{}
id为content的h1标签下的h2标签。

本文链接

各浏览器下使用 OBJECT 元素和 EMBED 元素嵌入 Flash 存在差异

2012-02-06T11:51:00Z

标准参考

OBJECT 元素定义了一个嵌入的对象。其引入的初衷是取代 IMG 和 APPLET 元素。不过由于安全等各方面原因以及缺乏浏览器支持，这一初衷并未实现。浏览器的对象支持依赖于对象类型。然而，即便是相同的对象类型，各主流浏览器也都使用了不同的代码来加载。 classid 属性用于指定对象实现的 URI 地址。它可能用来替代或者配合 data 属性，这由引入的对象决定。
codebase 属性指定了一个为 classid、data、archive 属性的相对 URI 提供基本路径。缺省情况下，这个值为当前文档的基本 URI。
type 属性定义被定义在 data 属性中指定的文件中出现的数据的 MIME 类型。

关于 OBJECT 元素及其属性的详细信息，请参考 HTML4.01 规范 13.3 Generic inclusion: the OBJECT element 中的内容。

问题描述

通常情况下，IE 系列浏览器通过 ActiveX 插件使用 OBJECT 元素引入 Flash，而其他浏览器则是通过相应的 NPAPI 插件使用 EMBED 元素。这造成了各浏览器中插入 Flash 的方式的差异。

造成的影响

若仅仅使用 OBJECT 元素设置了 classid 属性引入 Flash，则可能造成在某些浏览器中 Flash 无法被引入。而若嵌套的 OBJECT 和 EMBED 元素参数不统一，也可能造成引入的 Flash 在各浏览器中出现差异。

受影响的浏览器

所有浏览器

所有浏览器

问题分析

对于 HTML4.01 规范中的 OBJECT 元素，IE 对 classid 属性有自己的解释方式：类标识符（class identifier）。格式形如：clsid:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX。由 ActiveX 组件注册在 Windows 的系统注册表中。
codebase 属性则为该类标识符所对应的 ActiveX 插件的 URI 地址。一般是一个 .cab 安装包。（更多请参考 MSDN：CLASSID Attribute | classid Property 及 Class Identifier 中的内容。）

EMBED 元素则是由 NetScape Navigator 2 引入，用于在 HTML 文档中插入符合网景插件应用程序编程接口（NPAPI）规范的插件。NPAPI 插件是跨平台的，并可以在所有实现了此接口规范的浏览器中使用。目前的主流浏览器中 IE 系列以外的浏览器均支持 NPAPI 插件。
事实上 IE3.0 就支持 NPAPI，但是在 IE5.5 SP2 后微软出于安全考虑停止了对 NPAPI 的支持，转而推荐用户使用其 ActiveX 技术作为替代。（更多请参考 MSDN：Netscape 式的插件在升级 Internet Explorer 后不工作）
EMBED 元素拥有一个名为 pluginspage 的属性，其值为 NPAPI 插件的 URL，与 IE 中 OBJECT 元素的 codebase 属性类似，它告诉了浏览器插件的下载地址。

EMBED 元素不属于 HTML4.01 规范中的元素，HTML 文档中直接使用 EMBED 元素可能无法通过 W3C 校验。不过 EMBED 元素目前已经被添加到 HTML5 草案中。（参加 HTML5 草案：4.8.3 The embed element）

至此若需要在 HTML 文档中引入一个已安装的通用的插件，如 Flash，则在 IE 中使用 OBJECT 元素，非 IE 中则使用 EMBED 元素。此外 IE 中也支持 EMBED 元素引入设置了正确 MIME 的插件。

通常，我们会使用类似如下结构的代码引入 Flash：flash.html（SWF 文件来自 Adobe 网站的 Flash 范例）

<object width="200" height="200" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#4,0,0,0">
  <param name="src" value="clock.swf" />
  <param name="quality" value="high" />
  <embed src="clock.swf" type="application/x-shockwave-flash" width="200" height="200" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer"></embed>
</object>

各浏览器中的效果均为：

将 EMBED 元素嵌套在 OBJECT 元素中，在 IE 中会优先使用 OBJECT 元素而忽略 EMBED 元素，在其他浏览器中则优先使用 EMBED 元素而忽略 OBJECT 元素。这样做虽然可以保证在所有浏览器中均能正确加载 Flash，但若 OBJECT 元素与 EMBED 元素的参数设定不统一，则很有可能造成 Flash 在各浏览器中显示效果不一致，甚至是无法正常加载。

关于如何正确地在 HTML 文档中引入 Flash，请参考 Adobe 官方知识库文档：OBJECT and EMBED syntax | Flash 与 Flash OBJECT and EMBED tag attributes中的内容。

下面将分析仅使用一种元素的引入 Flash 的情况下在所有主流浏览器中是否达到一致的效果。（假设浏览器均已正确安装 Flash 所需插件）

1. 使用 OBJECT 元素 classid 属性以及 PARAM 元素：flash_object_classid.html

<div style="border:5px solid black; padding:5px; float:left;">
  <object width="200" height="200" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#4,0,0,0">
    <param name="src" value="clock.swf" />
    <param name="quality" value="high" />
  </object>
</div>

这段代码在各浏览器中运行效果如下：

IE6 IE7 IE8 Chrome Safari	Firefox Opera

Firefox 和 Opera 由于不支持 ActiveX 技术所有无法通过 OBJECT 元素及 classid 属性引入 Flash，则此时 OBJECT 元素宽度和高度均为 0。
然而 Chrome 和 Safari 却正确的加载了 Flash 文件，这是由于 WebKit 内核对 ActiveX 提供了有限的支持，对于比较通用的 ActiveX 插件（如 Flash, Media Player, Director, QuickTime, RealAudio），浏览器会将它们的在 Windows 系统中的 classid 与其对应的 Mime-Type 相关联，所以可以和 IE 一样仅仅通过 OBJECT 元素的 classid 属性引入这些插件。

2. 使用 OBJECT 元素 type、data 属性：flash_object_type.html

<div style="border:5px solid black; padding:5px; float:left;">
  <object width="200" height="200" type="application/x-shockwave-flash" data="clock.swf">
  </object>
</div>

这段代码在各浏览器中运行效果如下：

IE6 IE7 IE8	Firefox Chrome Safari Opera

IE 对 OBJECT 元素的 data 属性设置 Flash 文件 URL 无任何效果。这种方式可以用于非 IE 浏览器。

3. 使用 OBJECT 元素 type、data 属性以及 PARAM 元素：flash_object_all.html

<div style="border:5px solid black; padding:5px; float:left;">
  <object width="200" height="200" type="application/x-shockwave-flash" data="clock.swf">
    <param name="src" value="clock.swf" />
    <param name="quality" value="high" />
  </object>
</div>

这种方式仍然仅使用 W3C 规范中标准的 OBJECT 元素，结合了上两个测试样例，使得所有浏览器均可以正常的载入 Flash 文件。

4. 使用 EMBED 元素：flash_embed.html

<div style="border:5px solid black; padding:5px; float:left;">
  <embed src="clock.swf" type="application/x-shockwave-flash" width="200" height="200" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer"></embed>
</div>

直接使用 EMBED 元素，所有浏览器均支持。

解决方案

若不考虑 W3C 校验，可统一使用 EMBED 元素嵌入 Flash，这样可以避免因参数不统一导致的兼容性问题。

若需要考虑 W3C 校验（ Markup Validation Service），则可使用第三种单独使用 OBJECT 与 PARAM 元素的方式。

若必须使用 OBJECT 嵌套 EMBED 元素这种混合方式，则要保证 Flash 文件 URL、为 Flash 传递的参数、宽度、高度、wmode 等参数保持统一。

可以使用开源的 SWFObject 引入 Flash。（请参见：）

参见

知识库

...

相关问题

BT9024：IE 中可以使用 classid 与 codebase 属性结合完成下载、安装和使用 ActiveX 插件

HO9006：Firefox Opera 不支持通过为 OBJECT 元素设置 classid 引入 Windows 下的 Media Player 或 Flash 插件

测试环境

操作系统版本: Windows 7 Ultimate build 7600

浏览器版本: IE6
IE7
IE8
Firefox 3.6.8
Chrome 6.0.472.11 dev
Safari 5.0.1
Opera 10.60

测试页面: flash.html
flash_object_classid.html
flash_object_type.html
flash_object_all.html
flash_embed.html

本文更新时间: 2010-07-31

关键字

Flash EMBED OBJECT type param classid NPAPI ActiveX 插件

原文地址：http://www.w3help.org/zh-cn/causes/HO8001

本文链接

操作系统版本:	Windows 7 Ultimate build 7600
浏览器版本:	IE6 IE7 IE8 Firefox 3.6.8 Chrome 6.0.472.11 dev Safari 5.0.1 Opera 10.60
测试页面:	flash.html flash_object_classid.html flash_object_type.html flash_object_all.html flash_embed.html
本文更新时间:	2010-07-31

中国煤炭行业信息化软件系统应用分析

2012-01-06T03:30:00Z

ccjvl 2011-12-31
声明：本文为本人在煤炭自动化及信息化领域的基础上，从监控软件市场的拓展角度来做出的市场及技术分析，仅为个人观点，对任何厂商和个人均无故意诋毁之意，文中某些观点难免有失偏颇，如有不足之处还望指正。
转载请附上本文原创地址：http://www.cnblogs.com/CCJVL/archive/2012/01/06/2314173.html

1. 概述
由于目前煤矿信息化软件系统包含的内容很广泛，覆盖了从底层的数据信息采集、自动化监控系统、信息管理系统直到最上层数据分析挖掘及专家辅助决策系统等几大方面的内容，现分几个方面分别描述。
首先，煤矿的信息化软件系统按市场产品应用可分为安全监控系统、生产监控系统、人员定位系统、信息化管理系统、企业数据分析挖掘及专家辅助决策系统，这些系统在不断的发展中有进一步融合的趋势，但从目前的应用状况，还是各自为政，兼容性及集成度很低，最上层的专家辅助决策的应用更是很少。

2. 安全监控软件系统
安全监控系统包括瓦斯、井下局扇通风、井下排水等重要的安全相关的控制系统，市场份额为各大设计院、各安全监控系统硬件供应商所垄断（有竞争实力的厂商列表见附表），因为其硬件大部分捆绑软件销售，而且硬件通讯协议不公开，因此，这一块市场别的软件公司（包括组态软件公司）很难介入，除非生产出足够实力的安全监控系统硬件包括传感器、防爆监控分站、防爆备用电源及周边设备，别的公司只能在其安全监控系统软件之上取其公开的数据，再构建一套综合监控系统，但是效率大打折扣。鉴于安全监控系统的重要性，众多软件厂商虽然也想进入该市场分得一块蛋糕，但是无奈硬件开发水平有限，矿井井下条件恶劣，加之防爆硬件的开发及安全标准的审核，无疑更加提高了该领域的门槛，各公司只好纷纷转向不太重要的人员定位系统的市场，因此也有许多集成商也推出自家研制的人员定位系统软硬件。
由于各大设计院及硬件开发商的软件实力相对较弱，因此其开发的安全监控软件系统难免包含一些不足之处，粗略归纳为以下几点：
 非基于组态软件开发，部署实施的项目以及后期修改维护不如组态软件灵活快速。
 数据参数仅以列表形式，无图形开发和展示功能（流程图，布置图等）或图形开发及展示功能很弱，功能缺失等。
 项目不能分布式部署，不能实现负载均衡。
 程序一旦随项目部署，其后有程序功能级别的维护，只有在客户实际应用中才会发现，需要重新编译软件，重新安装部署，给安全生产带来极大的不便，而组态软件如果有程序功能级别的维护在开发工程时就会发现，不会带入到客户的工程应用当中，如果工程需要部署后维护则可直接在工程运行时进行修改，不必中止系统的运行影响正常的监控。此处功能级别的维护包括各类插件的修正（菜单、按钮、界面）、程序的各种Bug修复及功能(计算公式及脚本等)升级更新。
 与其他厂商开发的组态监控系统兼容性差，接口及协议不兼容，难以完成数据共享，难以集成。软硬件只兼容自家系统接入，很少支持别的厂商的系统接入。选购了一家的产品，就要一直选购下去，包括各种周边系统及硬件，如果想换，就得全部拆除重新部署。
 基于关系数据库存储的数据，随着历史数据的存储时间越来越长，数据越来越多，查询、存储性能均会大幅下降，而组态厂商则大部分以及推出自己研发的工业实时历史数据库，以应对生产过程的海量过程数据并以优异的查询存储速度完胜关系数据库。
 用户管理没有权限以及角色的控制，非相关的登录人员也能看到全部系统的数据。
 组件式开发，各组件并非由一个公司开发维护，容易出现漏洞，一个组件出问题，整个系统都无法使用。
 SQL Server数据库是否是正版？如果客户没有要求正版的话，大部分安装的系统有可能均为网上查找的序列号安装的个人版数据库系统。

3. 生产监控软件系统
生产监控系统主要包括井下皮带监控、井下车场信集闭系统、井下视频监控、煤矿电力系统、井下矿压监测系统、综采工作面监控系统、部分井下排水系统、架空乘人系统、主副井提升系统、主扇通风系统，这些系统中除了井下皮带、井下车场信集闭系统、井下排水、架空乘人系统、主副井提升系统、主扇通风系统、洗选煤系统、装车地磅系统外，目前其他系统绝大多数均不能稳定可靠的实现集中远程控制功能，大部分煤矿只做到采集数据的功能。
这一部分的监控软件系统主要为组态软件系统供应商所占领，但是因为监控的系统个数多，加上国家政策的影响，业主对单个子系统的客观重视程度相对安全监控系统较小、系统较简单（洗选煤系统较复杂），而且更受到自动控制系统推广普及程度及某些子系统自动化需求不迫切等因素的影响，大部分煤矿仅实现集中监控几个主要的子系统，其他则全部依赖原始的现场控制及检测，缺乏集中控制，综合自动化系统进程参差不齐，所以这一部分的监控系统市场份额较安全监控系统比较零散，在被煤矿重视程度上占劣势，但在数量上占优势，单个系统可能比不上安全监控系统重要，但是全部集成为一个大生产监控系统，其重要性不言而喻，随着自动化控制水平的不断提升以及可以集成展示安全监控系统的数据，大部分煤矿业主还是希望能够通过一套统一的系统看到各个子系统的状况，因此，通过不断的控制及通信效率和可靠性水平的提升，相信很多大多数煤矿很愿意投资升级改造。
相比之下，煤炭领域较权威和业务关系及实力较强的设计院和硬件供应商在此领域所占有的市场明显不如组态软件厂商，而集成商借助其高度的软硬件融合实力，承担起大部分此领域的项目实施和部署，但在实施过程中，大部分采用的是国外品牌的组态软件。
在全行业中，组态软件各厂商的近几年的市场占有率如下表：

2008年中国组态监控软件主要供应商业绩与市场份额

2010年中国组态监控软件主要供应商业绩与市场份额（来自睿工业的2010年市场报告）

在煤矿行业中，占有市场份额最多的前三甲则为GE(IfIX)、Wonderware(InTouch)、Siemens(WinCC)。

4. 人员定位软件系统
人员定位系统由于涉及到定位标签及定位传感器、分站等硬件设备，因此，大部分市场也被生产这些设备的厂商所占领，包括各大设计院、生产安全监控系统硬件的厂商等（有竞争实力的厂商列表见附表），部分集成商（如富力通等）也借助自己开发的硬件（开发实力仍有待提高）或某些没有软件开发能力的硬件厂商的硬件，搭配自己开发的软件产品，冠名为KJ**，如果未采用组态软件开发的话，其软件系统所使用的图形技术如出一辙，但是同安全监控系统一样，各厂家的硬件系统数据接口及协议不对外公开，只能使用其配套软件，造成部署安装了一家的系统软硬件后就要一直使用其厂家的设备及软件系统，要想更换，只能在其基础上开发或重新搭建系统。
技术方面，安全监控系统和人员定位系统的硬件供应商所提供的配套软件大部分采用编程方式实现，软件功能单一，部署缺乏灵活、虽能做到冗余备份的功能，但是在网络部署及分布式负载均衡、图形开发及展示方面跟组态软件明显不在一个等级之上，虽然其软件系统也宣称有基于组态技术开发的图形系统，但是，只不过是集成的一个名字叫Visual Graph的组件式软件，此软件起初是因个人兴趣及志向开发，通过不断宣传和商业策略，逐步为各硬件供应商嵌入其软件系统中作为图形开发系统，包括安全监控及人员定位系统。
但是Visual Graph软件与组态软件的图形开发系统相比，目前看来至少在开发项目的能力上还有待进一步提升，其之所以应用的如此广泛得益于它灵活的兼容性以及高度的开放性、自由公开的继承和嵌套等接入技术，它可以以组件的形式嵌入目前主流的编程语言开发的任何软件中，实现图形的开发以及后期维护不需要重新编译软件这一组态软件独有的技术，而图形系统的开放性恰恰是组态软件所缺失的（组态软件的图形文件不能为外部程序所调用，也不能导入其他程序的矢量图文件如AutoCAD、CorDraw、GIS等）。但是，从软件功能及图形支持上，Visual Graph所支持的动画以及图形效果只能是模拟组态软件，无论从丰富程度还是图形脚本支持方面，均需要不断的扩充及深入，就目前看来，软件的Bug数量多的随处可见（如2011版的软件中实现鼠标点击组合图形改变某文本的功能等）。因此，其要想成为有实力的图形开发系统，还需要不断的研发投入和较长时间的发展。

5. 信息化管理系统
信息化管理系统即为建立于自动化系统数据采集系统之上的所有信息管理的软件系统，主要包括各煤矿设计研究院以及大的信息化软件开发商所开发的整套信息化系统，如煤科院开发的“煤炭企业生产调度管理系统”，常州天地开发的“基于3DGIS的数字矿山基础信息平台”，宝信软件开发的“宝信矿井安全生产管控信息系统CI-MES”，富力通研发的“安全管理信息系统”等，重庆煤科院方面由于偏重于硬件研发，软件研发实力有限，目前还未发现有类似软件系统。
由于煤炭行业信息化进程缓慢，管理水平有待进一步提高，因此这一部分市场还未被完全打开，众多煤炭行业业主信息化需求不明确，管理水平难以通过一套软件的实施得到根本的转变，因此只有在整个行业的管理水平整体提升后，客户管理需求迫切之时，信息化系统才能被大规模应用，目前只能称之为初级阶段，各家厂商群雄逐鹿，市场占领方面暂时伯仲难分，至于实力，那就要取决于各厂商的煤炭行业知识经验积累以及软件开发水平，但是有实力并不代表市场的占有率，实力加推广力度才是决胜的砝码。

6. 企业数据分析挖掘及专家辅助决策系统
此部分的软件系统目前由科研院所及部分煤炭专业实力较雄厚的高校进行算法及模型的研究发掘。因为煤矿为粗放型行业，很难有精确的算法及模型应用于整个行业的分析，因此诸如煤矿产量分析及专家预测系统、煤矿井下险情预警及辅助决策系统以及整个行业的辅助决策系统的应用及开发也只停留在原始的试验摸索阶段，有极个别的在煤矿现场进行实验研究，还有一些软件系统冠以此类名称，实际上只是一个信息管理及数据初步分析的软件系统，称不上专家预测及辅助决策系统，更没有此类功能的实用价值。

7. 附表：

本文链接

中国煤矿历年事故死亡人数及分析

2011-12-26T01:48:00Z

中国煤矿历年事故死亡人数及分析

中国历年煤矿事故死亡人数

年份矿山死亡人数
2000年 5,798人
2001年 5,670人
2002年 6,995人
2003年 6,702人
2004年 6,027人
2005年 5,491人

2007年 3786人

2008年 3210
2010年 2433

资料来源：国家安全生产监督管理总局历年颁布数据。
上述矿工死亡人数是官方公布，其实已经比真实死亡人数少了许多。有媒体报道政府主管部门在2004年年初曾声称，2003年大陆煤矿企业事故死亡6,702人，比2002年减少293人，死亡率下降4.2%；而2004年准备按照下降4.0%的幅度控制死亡人数。而煤矿百万吨死亡率2003年为4.17，比2002年下降16.6%。2004年百万吨死亡率准备按照3.8控制。这种在政府控制状态下公布的数字，其真实性当然值得怀疑。根据意大利安莎通讯社2006年8月29日消息，中国每年发生的劳动安全死亡事故接近1.6万起。远比中国官方公布的2000多起故难事故及死亡人数高得多。

瓦斯爆炸
　　瓦斯爆炸是一种热一链式反应（也叫链锁反应）。当爆炸混合物吸收一定能量（通常是引火源给予的热能）后，反应分子的链即行断裂，离解成两个或两个以上的游离基（也叫自由基）。这类游离基具有很大的化学活性，成为反应连续进行的活化中心。在适合的条件下，每一个游离基又可以进一步分解，再产生两个或两上以上的游离基。这样循环不已，游离基越来越多，化学反应速度也越来越快，最后就可以发展为燃烧或爆炸式的氧化反应。所以，瓦斯爆炸就其本质来说，是一定浓度的甲烷和空气中的氧气在一定温度作用下产生的激烈氧化反应。
　　即方程式为 CH4+2O2→CO2+2H2O条件点燃
　　瓦斯爆炸的条件是：一定浓度的瓦斯、高温火源的存在和充足的氧气。
　　(1)瓦斯浓度
　　瓦斯爆炸有一定的浓度范围，我们把在空气中瓦斯遇火后能引起爆炸的浓度范围称为瓦斯爆炸界限。瓦斯爆炸界限为5％～16％
　　当瓦斯浓度低于5％时，遇火不爆炸，但能在火焰外围形成燃烧层，当瓦斯浓度为9．5％时，其爆炸威力最大(氧和瓦斯完全反应)；瓦斯浓度在16％以上时，失去其爆炸性，但在空气中遇火仍会燃烧。
　　瓦斯爆炸界限并不是固定不变的，它还受温度、压力以及煤尘、其它可燃性气体、惰性气体的混入等因素的影响。
　　(2)引火温度
　　瓦斯的引火温度，即点燃瓦斯的最低温度。一般认为，瓦斯的引火温度为650℃～750℃。但因受瓦斯的浓度、火源的性质及混合气体的压力等因素影响而变化。当瓦斯含量在7％一8％时，最易引燃；当混合气体的压力增高时，引燃温度即降低；在引火温度相同时，火源面积越大、点火时间越长，越易引燃瓦斯。
　　高温火源的存在，是引起瓦斯爆炸的必要条件之一。井下抽烟、电气火花、违章放炮、煤炭自燃、明火作业等都易引起瓦斯爆炸。所以，在有瓦斯的矿井中作业，必须严格遵照《煤矿安全规程》的有关规定。
　　(3)氧的浓度
　　实践证明，空气中的氧气浓度降低时，瓦斯爆炸界限随之缩小，当氧气浓度减少到12％以下时，瓦斯混合气体即失去爆炸性。这一性质对井下密闭的火区有很大影响，在密闭的火区内往往积存大量瓦斯，且有火源存在，但因氧的浓度低，并不会发生爆炸。如果有新鲜空气进入，氧气浓度达到12％以上，就可能发生爆炸。因此，对火区应严加管理，在启封火区时更应格外慎重，必须在火熄灭后才能启封。
　　瓦斯爆炸产生的高温高压，促使爆源附近的气体以极大的速度向外冲击，造成人员伤亡，破坏巷道和器材设施，扬起大量煤尘并使之参与爆炸，产生更大的破坏力。另外，爆炸后生成大量的有害气体，造成人员中毒死亡。
　　防止瓦斯爆炸
　　预防瓦斯爆炸的有效措施，主要从防止瓦斯积聚和消除火源两方面着手。
　　1.防止瓦斯积聚的措施
　　（1）加强通风。使瓦斯浓度降低到《煤矿安全规程》规定的浓度以下，即采掘工作面的进风风流中不超过0.5％，回风风流不超过1％，矿井总回风流中不超过0.75％。
　　（2）加强检查工作。及时检查各用风地点的通风状况和瓦斯浓度，查明隐患进行处理，是日常进行瓦斯管理的重要内容。我国20世纪80年代所用的甲烷检查仪器有：光学甲烷检定器、热放式甲烷检定器、甲烷警报器和甲烷遥测警报仪等。90年代以后使用比较先进的TX系列智能便携式气体监测仪和遥测仪器等。
　　（3）对瓦斯含量大的煤层，进行瓦斯抽放，降低煤层及采空区的瓦斯涌出量。
　　2.防止瓦斯引燃的措施
　　（1）井口房、瓦斯抽放站及主要通风机房周围20m内禁止使用明火。
　　（2）瓦斯矿井要使用安全照明灯，井下禁止打开矿灯，禁止携带烟草及点火工具下井。
　　（3）严格管理井下火区。
　　（4）严格执行放炮制度。
　　（5）严格掘进工作面的局部通风机管理工作，局部通风机要设有风电闭锁装置。
　　（6）瓦斯矿井的电气设备要符合《煤矿安全规程》关于防爆性能的规定。
　　（7）随采矿机械化程度的提高，防止机械摩擦火花引燃瓦斯显得日益重要。煤矿井下由于摩擦火花而引起的瓦斯爆炸事故占有相当的比例，因此不少国家对这个问题进行了研究，并提出，在摩擦部件的金属表面溶敷一层活性小的金属（如铬），使形成的摩擦火花不能引燃瓦斯；在铝合金的表面涂各种涂料，以防止摩擦火花的发生和金属中加入少量的铍，降低摩擦火花的点燃性等。
矿难是指矿山发生的灾难.常见的矿难有：瓦斯爆炸、煤尘爆炸、瓦斯突出、透水事故、矿井失火、顶板塌方等等。
　　矿难矿难对矿山有着毁灭性的破坏。严重威胁矿工的生命安全。
　　中国是一个产煤大国，是一个严重依赖煤炭能源的国家，同时也是矿难大国。各次矿难事故说明：煤矿存在非法超层越界开采问题，煤矿劳动组织、安全管理严重混乱等一系列问题。解决这些问题需要各级部门的统一协调。
　　只有不断加强矿山开采的管理力度，才能有效的减少矿难事故的发生。
　　矿难频发，反映了一个社会中工人权利难以得到保护。
2.主要事故种类
　　
2.1瓦斯爆炸
　　瓦斯与空气混合，在高温下急剧氧化，并产生冲击波的现象，是煤矿生产中的严重灾害。1675年英国莫斯廷（Mostyn）矿发生大规模瓦斯爆炸，其后各主要采煤国家都曾多次发生重大的瓦斯或瓦斯与煤尘爆炸事故。1942年 4月26日，日本侵占下的中国本溪煤矿发生瓦斯与煤尘爆炸，当场死亡1527人，伤268人，为世界上最大的煤矿爆炸事故。随煤矿生产技术的发展和防治瓦斯措施的改进，这类事故已逐渐减少。
　　中国煤矿瓦斯爆炸的火源主要是电火花和爆破，主要发生地点是采掘工作面。煤矿瓦斯爆炸产生的瞬间温度可达1850～2650℃，压力可达初压的9倍，爆源附近气体以每秒几百米以上的速度向外冲击，使人员伤亡，巷道和器材设施毁坏。爆炸后氧浓度降低，生成大量CO2和CO，有窒息和中毒危险。
　　预防措施主要有：
　　①用矿井通风和控制瓦斯涌出等方法，防止瓦斯浓度超过规定；
　　②控制火源，杜绝非生产需要的火源，如吸烟、火柴、明火照明等。对生产中不可避免的高温热源，采用专门措施严加控制，如只准使用特制的矿用安全炸药和电气设备，加强井下火区的管理，禁止井下拆开矿灯等；
　　③定期或自动连续检查工作地点的CH4浓度和通风状况。
2.2煤尘爆炸
　　煤尘爆炸同瓦斯爆炸一样都属于矿井中的重大灾害事故。我国历史上最严重的一次煤尘爆炸发生在1942年日本侵略者统治下的本溪煤矿，死亡1549人，残246人，死亡的人员中大多为CO中毒，事故发生前，巷道内沉积了大量煤尘，是由于电火花点燃局部聚积的瓦斯而引起的重大煤尘爆炸事故。
2.3瓦斯突出
　　瓦斯突出是煤与瓦斯突出的简称，煤与瓦斯突出是指在压力作用下，破碎的煤与瓦斯由煤体内突然向采掘空间大量喷出，会给采矿者带来危险的一种现象。也是矿难地主要类型之一。
2.4矿井火灾
　　矿井发生的火灾(包括危及井下的地面火灾)，常招致人员伤亡，设备损失，矿井停产，资源破坏，甚至引起瓦斯、煤尘或硫化矿尘爆炸。1894年俄斯特拉发-卡尔维纳地区(Ostrav-Karvina)拉瑞什(Larisch)煤矿(位于今捷克斯洛伐克境内)因火灾引起瓦斯爆炸，当场死亡235人，处理事故时又发生第二次瓦斯爆炸，矿山救护队员大部分牺牲。矿井火灾按引起的热源不同分内因火灾和外因火灾两类。
　　内因火灾分煤自燃、硫化矿石自燃两种。外因火灾指一切产生高温或明火的器材设备，如果使用管理不当，可点燃易燃物，造成火灾。在中、小型煤矿中，各种明火和爆破工作常是外因火灾的起因。
[编辑本段]2.5矿井水灾
　　矿山突然涌水所造成的灾害。1935年中国山东鲁大公司北大井，在巷道掘进到与朱龙河连通的周瓦庄断层附近时，河水突然灌入井巷，涌水量达578～648m3/min，78小时后，全矿淹没。
　　矿井水灾的水源有大气降水(雨、雪)、地表水、含水层水、断层水和旧巷或采空区积水等。大气降水可能从地表低洼地通过塌陷区裂隙或井口灌入井巷，造成灾害。地表水指河、湖、塘、沟及水库的积水。含水层水如砂砾层含水、石灰岩溶洞水，两者可能通过裂隙、断层、旧巷等通道进入井巷。断层破碎带常大量积水，特别是断层与含水层或地表水沟通时，补给丰富，威胁更大。旧巷或采空区积水，往往静水压力大，来势猛，且常含有害气体，易造成人身事故。矿山水灾的主要原因是：水文地质情况不明；缺乏附近老窖、旧巷的积水资料；未及时采取有效的探、防水措施；排水系统不完善以及排水设备能力过小或设备故障等。
2.6顶板事故
　　顶板事故是指在井下采煤过程中，顶板意外冒落造成的人员伤亡、设备损坏、生产中止等事故。在实现综合机械化采煤以前，顶板事故在煤矿事故中占有极高的比例，随着支护设备的改进及对顶板事故的研究、预防技术的提高和逐步完善，顶板事故所占的比例有所下降，但仍然是煤矿生产中的主要灾害之一。

本文链接

装Office 2010提示Error 1406的解决方法

2011-11-21T11:12:00Z

安装office 2010的时候，提示“error 1406”，并且一路只能点忽略，选重试的话也没用。

Google了一下，很多人都说是由于安装了360安全卫士，导致注册表被保护起来，所以安装office 2010的时候提示error 1406。

可是，俺木有装360安全卫士啊，何来的注册表被360安全卫士保护起来之说。。

好在功夫不负有心人，经过研究发现，打开注册表，找到“Image File Execution Options”，该项默认只给了system一个“默认权限”。

解决方法很简单，步骤如下：

1、打开开始菜单，选择“运行”，或者按快捷键：win+r

2、输入“regedit”，打开注册表

3、按Ctrl+F，打开查找，输入“Image File Execution Options”，然后点：查找下一个

4、找到后，右键点“Image File Execution Options”，选择倒数第二项“权限”，将“system”用户组选择“完全控制”，然后点添加，输入你当前的系统用户名，然后点确定，并给予完全控制的权限。

这些步骤完成之后，再回到office 2010的安装目录，选择重试即可解决安装Office 2010时提示Error 1406错误的问题。

本文链接

实时数据库的事务处理

2011-06-30T03:28:00Z

刘云生--李国徽--卢炎生

实时事务模型

----

1 ．系统模型与传统数据库系统相类似，实时数据库系统的操作也是以事务的形式出现。事务就是包含在BEGIN/COMMIT/ABORT 之间的操作序列。系统以事务为单位分配CPU、数据等资源，进行优先级的分配、调度处理等。

---- 实时数据库系统中的事务与传统事务有很大的不同，其事务可以有定时限制（典型地为截止期），系统追求的目标不是系统的吞吐量，而是单个事务定时限制的满足，以使满足定时限制的事务比率最大；传统事务的原子性、一致性、隔离性及永久性在实时环境下变得太严格或不可能；要求采用" 识时" 机制来处理事务的调度或并发控制，而不是传统的先来先服务方式。

----2 ．结构模型

---- 传统数据库中事务就是一个平坦的操作序列，事务的执行要么顺利执行到提交，要么夭折而不在系统的任何部分留有痕迹。在实时应用环境下则不同：

应用语义有时显式地要求结构上的一个事务为另一个事务的子事务。例如，在CAD 工程中，一个工程事务划分成若干个设计事务，而每一设计事务又可分成若干个子任务而分配给各设计者。
实时应用中被触发的活动依应用要求可以是触发它的事务的子事务。在过程控制、自动化等领域这种情形很普遍。
在分布式应用环境中，一个事务可能要分出若干在不同节点上执行的代理事务，它们分工合作且都作为原事务的子事务。
在工程应用中，普遍存在长寿事务或开端事务。这种事务会造成系统资源需求的瓶颈。为此，可将这种事务划分成若干逻辑相对独立的子事务，以便当其结束时能提前释放占用的资源。

---- 所以，实时应用要求系统提供事务嵌套机制。包含其他事务的事务称为" 父事务"，被包含的事务称为 " 子事务"，没有父事务的事务为" 根事务"。事务之间可以形成嵌套关系。

实时事务的特征

----

1 ．定时性

---- 实时应用中事务的定时性来源于两方面：一是外部环境显式给出的反应时间要求，如截止期等；二是由于系统中的数据随时间变化而转嫁来的。

---- 定时性包括了两方面的含义：

---- 定时限制 事务的执行具有显式的时限，如期限、截止时间等。这是由于控制系统要随时紧紧地跟踪被控系统而引起的，它要求RTDB 必须有时间处理机构。时限还可有软硬之分。

---- 定时正确性 事务能按合适的时间要求正确执行。这是由于要求数据对于控制系统的各种决策活动随时有效而引起的，它要求权衡定时限制与数据一致性等多方面因素，提供合适的调度算法。

---- 实时事务有不同的定时限制，其中最重要的有：

---- 截止时间 实时事务完成的最后期限。它可以有硬、软之分，具有硬截止时间的事务（称为硬实时事务），必须在其截止时间以前完成，否则将带来灾难性的后果，故到达其截止时间还不能完成的硬实时事务必须夭折。具有软截止时间的事务（称为软实时事务），应该在其截止期完成，但超过其截止时间也还有一定意义（尽管不断下降），故软实时事务到达其截止时间后不必立即夭折它。

---- 到达时间 事务在系统中生成的时间。它可以是可预报的，也可以是不可预报的。可预报的到达时间可显式地给出或者作为一个导出函数，如周期事务的到达时间是可预报的。不可预报的到达时间是指当相应事务到达系统时才能知道，非周期事务的到达时间就是不可预报的。

---- 期望执行时间 估算的最坏情况执行时间。由于各种不可预报性因素，它很难做到准确，估算的最坏情况执行时间可能与实际情况相差很大。然而，为了合理地得到事务的截止时间及适当地调度以使其满足，又必须事先较准确地估算其执行时间。

----2 ．语义相关性

---- 实时数据库事务之间存在着各种关系，包括结构关系、数据与通信关系、时间关系等，这些关系带来了事务间的各种相关性。

----(1) 结构相关

---- 它来自于复杂事务模型的结构特征，用来建模复杂事务内部并发事务行为的一种约束。不同的复杂事务模型有不同的结构相关性，但它们可以通过事务间的" 执行依赖性" 来定义，实时嵌套事务中基本的事务依赖有：

子事务对父事务的开始依赖（BD）：子事务开始前父事务已经开始；
父事务对子事务的提交依赖(CD）：父事务提交前子事务已经结束（提交或夭折）；
子事务对父事务的夭折依赖（AD）：父事务夭折则子事务一定夭折。

----(2) 数据相关

---- 数据相关就是不同事务间的共享数据联系，但此" 共享" 概念比传统的具有更广的意义：实时嵌套事务中的子事务共享父事务数据，子事务提交时其对数据库的更改委托给父事务，只有父事务提交时才能真正地写入数据库。

----(3) 功能替代/ 结果补偿

---- 一个实时应用常常由若干任务组成，而一个任务有时可以通过不同途径来实现。一个应用建模为一个事务，一个任务则建模为一组功能等价的子事务，称为该任务的替代集。若一个任务的替代集中的子事务之一能成功执行，则该任务是可完成的。若对应一个事务的所有任务可完成，则该事务是成功的（可提交）。功能替代导致了事务执行路径的不确定性，即一个事务成功执行的路径依赖于执行过程中（子事务）失败的发生，且即使某些子事务失败了，事务仍可能顺利提交。这还体现了实时事务的健壮性，即有的事务（任务）不能失败。

---- 由于前面所述的事务的结构复杂性和功能替代性，因此，事务的执行经历不确定，一个子事务的执行直到提交时还不能确定它是否需要。若一个（子）事务提交后，发现它是不需要的，该怎么办？另一方面，一个实时事务可以物理改变现实世界的状态，换句话说，事务可以启动各种活动，这些活动在它提交前就已经影响了现实世界，因而当这种事务夭折时，不能进行传统意义下的" 还原"（Undo）。于是需要一种" 补偿" 活动来抵消它所有的影响，这种补偿活动也是事务。对于一个（子）事务，若存在能抵消它提交后所产生的所有影响的（子）事务，则称其为是可补偿的，否则是不可补偿的。当然，不是每一个（子）事务都是可补偿的，不可补偿的（子）事务在知道它确实是需要的以前，一定不能提交。

实时事务分类

----

实时事务可以从不同的侧面进行分类。

----1 ．按关键性分类

---- 也就是按事务时限（截止期）的性质，即事务超截止期对系统带来的影响分类。而这种时限的性质可以很好地用价值函数来建模，于是我们有：

---- 硬（截止期/ 实时）事务 超截止期会导致恶果（价值函数取大且可能不断增加的负值）。它对应于安全危急性活动。

---- 软（截止期/ 实时）事务 超截止期仍有一定的价值，且价值不断下降，直到某一时刻（称为最终有效时间）降到零，此后保持为零（不会为负）。

---- 固（截止期/ 实时）事务 一旦到达截止时间，其价值立即降为零，此后固定为零（也不会为负）。显然，它是软实时事务在最终有效时间与截止时间重合情况的特例。

----2 ．按功能分类

---- 一个实时数据库系统以两种方式直接与现实世界交互作用，一是关于现实世界状态或事件的信息被记录到数据库中，二是事务可以启动各种影响现实世界的活动。这就给予我们一种如下事务分类：

---- 数据接收事务 记录现实世界的状态或发生的事件到数据库中。它是简单的只写事务；为了保持数据库的" 外部一致" 和跟踪记录，它应是短的、周期的，且应是被立即执行（不能等待和阻塞）的硬实时事务。为了保证其定时限制的满足，它可能会引起对数据库一致性的破坏。

---- 数据处理事务 类似传统数据库的事务。它用来恢复已违反了一致性（可能由于数据接收事务的结果）的数据库的状态。这种事务可看作维护正常运行的监控器，它可能是" 长寿" 的。

---- 控制事务 引起现实世界中有关活动的执行。像数据接收事务一样，这种事务是很短的，尽管所引起的现实活动可能要执行很长时间。它通常也是硬实时的。这种事务还可以作为数据处理事务的子事务而被调用，而它本身也可以触发子事务，比如以一子事务来检测所引起的现实活动。

实时事务的正确性

----

1 ．正确性概念及内涵实时事务与传统事务的本质区别就在于其有定时限制，因此，事务处理必须同时满足一致性要求和定时限制。虽然实时事务的正确性与传统事务一样，也包括数据库状态正确性和事务执行正确性两个方面，但其含义与内容有很大的不同。数据库状态正确性包含内部一致和时间一致，事务执行正确性则包含其结果正确性、行为正确性、结构正确性和时间正确性。

----2 ．正确性标准

---- 传统数据库中的原子性和可串行化包含了事务正确性的所有概念。而实时嵌套事务正确性的内容更为丰富，实现的手段也就更为复杂。传统可串行化标准在实时环境下太严格或不适合，限制了系统中事务执行的并发度，对于满足事务定时限制是不利的。我们开发了一种新颖的准一致性可串行化并发控制策略，事务执行给系统带来的不一致被限定在一定的范围内，并在一定的时机恢复数据库到一致状态。而实时事务的时间正确性需要" 识时" 协议实现，结构正确性需要事务管理检查事务间的结构相关性来实现。

实时事务处理

----

1 ．实时事务优先级分配

---- 实时事务的调度和并发控制都是基于事务的优先级进行的，因此，如何分配事务的优先级是一个重要的问题。

---- 常见的事务优先级分配算法有以下几种：

---- 最早放行最优先（Earliest Release First） 该策略将最高优先级指派给具有最早" 放行"（Release）时间的事务。所谓放行时间就是事务可以开始执行的最早时间，与此相联的有事务到达（Arrive）时间、事务接纳（Admission）时间。

---- 截止期最早最优先（Earliest Deadline First） 即具有最早截止期者优先级最高。

---- 可达截止期最早最优先（Earliest Feasible Deadline First） 具有最早的可达截止期者优先级最高。所谓一个事务t 的截止期是当前时间" 可达到" 的，乃指 τ ＋（E －P） ≤d。这里 τ 为当前时间，E、P 分别为事务T 的执行时间估算和已执行时间， d 为其截止期。

---- 空余时间最短最优先（Least Slack First） 事务t 的空余时间S=d －（ τ ＋E －P），即推迟T 的执行而仍然满足其截止期的可推迟时间量估算。

---- 价值最高最优先（Highest Value First） 每一事务都有一价值函数，其值最大者最优先。问题是如何合理地构造价值函数，一个例子是：

---- V（t）=c（w₁（ τ － τ_S）－w₂d ＋w₃P －w₄S）

---- 其中 τ、d、P、S 的意义同上，c、 τs 分别为 t 的危急度、开始时间，wi 为加权因子。

---- 价值密度最大最优先（Greatest Value Density First） 价值密度函数为：

---- 即事务完成时的期望价值与实现该价值所需计算量的比最大者优先级最高。显然，对于期望价值一样的事务，该策略偏向较短者，因为它每单位消耗时间所获得的价值更大。与上面的HVF 策略一样，这里也有如何设计价值函数的问题。

----2 ．实时事务并发控制和调度

---- 在实时应用环境中，如果处理不当，可能造成" 优先级颠倒"，即优先级高的事务等待优先级低的事务，这对实现事务的定时限制是不利的。为此，我们提出了以下几种改进方案：

----(1) 优先级继承

---- 优先级继承的基本思想是：当发生优先级颠倒时，将占有者tH 的优先级提高到与tR 的一样（即继承tR 的优先级），tH 继续执行直到结束（提交或夭折）。在tH 因某种原因（如成为死锁的牺牲者）而重启动时，它恢复原来的优先级。让tH 继承 tR 优先级是为了让它尽快完成，因为tH 的进展也意味着tR 的进展。这种策略称为优先继承（PI）。

----(2) 高优先级夭折

---- 这种策略的思想是，当发生优先级颠倒时，夭折低优先级的tH 而让高优先级的tR 执行。该策略称" 高优先" 法（HP）。

---- 这种策略可以消除死锁，但它的问题是：

对那些已执行时间很长而还需执行的时间已很短的tH，夭折的代价很大。尤其是当dH（截止时间）－ct（当前时间）与tH 的" 剩余执行时间估算"el(tH) 相差不大时，重启动必然导致其超截止时间，而且浪费大量系统资源，使整个系统性能下降。
若采用像LSF 这样的动态优先级分配策略，则被夭折而重启动的tH 可能马上会有比tR 更高的优先级。为此，当重启动的tH 再次与 tR 冲突时，tR 可能又被tH 夭折，这样就导致循环夭折。

---- 为了解决上述两个问题，人们提出了不同的改进策略，在此限于篇幅不再详细叙述。

本文链接

实时数据库系统

2011-06-30T03:25:00Z

---- 数据库理论与技术的发展极其迅速，其应用日益广泛，在当今的信息社会中，它几乎无所不在。以关系型为代表的三大经典（层次、网状、关系）型数据库在传统的（商务和管理的事务型）应用领域获得了极大成功，然而它们在现代的（非传统）工程和时间关键型应用面前却显得软弱无力，面临着新的严峻的挑战，由此而导致了实时数据库（Real time Database，RTDB）的产生和发展。

实时数据库的发展

----数据库的应用正从传统领域向新的领域扩展，如CAD/CAM、CIMS；数据通信、电话交换、电力调度等网络管理；电子银行事务、电子数据交换与电子商务、证券与股票交易；交通控制、雷达跟踪、空中交通管制；武器制导、实时仿真、作战指挥自动化或C3I 系统，等等。这些应用有着与传统应用不同的特征，一方面，要维护大量共享数据和控制数据；另一方面，其应用活动（任务或事务）有很强的时间性，要求在规定的时刻和( 或) 一定的时间内完成其处理；同时，所处理的数据也往往是" 短暂" 的，即有一定的有效时间，过时则有新的数据产生，而当前的决策或推导变成无效。所以，这种应用对数据库和实时处理两者的功能及特性均有需求，既需要数据库来支持大量数据的共享，维护其数据的一致性，又需要实时处理来支持其任务（事务）与数据的定时限制。

----但是，传统的数据库系统旨在处理永久、稳定的数据，强调维护数据的完整性、一致性，其性能目标是高的系统吞吐量和低的代价，而根本不考虑有关数据及其处理的定时限制，所以，传统的数据库管理系统（DBMS）不能满足这种实时应用的需要。而传统的实时系统（RTS）虽然支持任务的定时限制，但它针对的是结构与关系很简单、稳定不变和可预报的数据，不涉及维护大量共享数据及它们的完整性和一致性，尤其是时间一致性。因此，只有将两者的概念、技术、方法与机制" 无缝集成"（Seamless Integration）的实时数据库（RTDB）才能同时支持定时和一致性。

----因此，实时数据库就是其数据和事务都有显式定时限制的数据库，系统的正确性不仅依赖于事务的逻辑结果，而且依赖于该逻辑结果所产生的时间。近年来，RTDB 已发展为现代数据库研究的主要方向之一，受到了数据库界和实时系统界的极大关注。然而，RTDB 并非是数据库和实时系统两者的简单结合，它需要对一系列的概念、理论、技术、方法和机制进行研究开发，如数据模型及其语言，数据库的结构与组织；事务的模型与特性，尤其是截止时间及其软硬性；事务的优先级分派、调度和并发控制协议与算法；数据和事务特性的语义及其与一致性、正确性的关系，查询/ 事务处理算法与优化；I/O 调度、恢复、通信的协议与算法，等等，这些问题之间彼此高度相关。

实时数据库与时间

----实时数据库系统在两方面与时间相关：

----1. 数据与时间相关

----按照与之相关的时间的性质不同又可分为两类：

----数据本身就是时间即从" 时间域" 中取值，如" 日期"，称为" 用户定义的时间"，也就是用户自己知道，而系统并不知道它是时间，系统将毫无区别地把它像其他数据一样处理。

----数据的值随时间而变化数据库中的数据是对其所服务的" 现实世界" 中对象状态的描述，对象状态发生变化则引起数据库中相应数据值的变化，因而与数据值变化相联的时间可以是现实对象状态的实际时间，称为" 真实" 或" 事件" 时间（现实对象状态变化的事件发生时间），也可以是将现实对象变化的状态记录到数据库，即数据库中相应数据值变化的时间，称为" 事务时间"（任何对数据库的操作都必须通过一个事务进行）。实时数据的导出数据也是实时数据，与之相联的时间自然是事务时间。

----2 ．实时事务有定时限制

----典型的就是其" 截止时间"。对于RTDB，其结果产生的时间与结果本身一样重要，一般只允许事务存取" 当前有效" 的数据，事务必须维护数据库中数据的" 事件一致性"。另外，外部环境（现实世界）的反应时间要求也给事务施以定时限制。所以，RTDB 系统要提供维护有效性和事务及时性的设施。

实时数据库的特征

----如上所述，RTDB 的特征主要表现在数据和事务的定时限制上，下面分别介绍。

----1.RTDB 的数据特征

----在RTDB 中，数据随外部环境状态的变化而快速变化，其值只在一定的时间内是" 流行" 的，过时则无效了，故系统除了维护数据库内部状态（数据值）的正确性、相容性外，还必须同时维护内部状态与外部环境实际状态的一致性，以及数据用来决策或推导新数据时在时间上的相互一致性。

----RTDB 中的一个数据对象d 由三个分量组成（dv，dtp，devi），它们分别为d 的当前值、采样时间、外部有效期（外部现实对象状态变化的时间间隔），有效期即自dtp 算起dv 有效的时间长度。对于RTDB 中的每一d，有内部一致性、外部一致性和相互一致性特征。

----内部一致性 dv 满足预先定义的数据库内部状态的完整性和一致性限制。这就是传统意义下的数据正确性。

----外部一致性设tc 为当前或检测时间，当且仅当（tc －dtp） ≤devi，则说d 是外部一致的，即dv 和对应的外部现实对象的状态是一样的。

----相互一致性用来决策或导出新数据的一组相关数据称为一个相互一致集，记为R，其中的数据必须尽可能地在一个允许的公共时间期内被采取（或导出），这个公共时间期就称为R 的相互有效期，记为Rmvi，对于R 中的任两个数据d 和d ′, 有|dtp －d ′tp| ≤Rmvi，则说R 中的数据是相互一致的。

----外部一致性和相互一致性都是关于时间的，故统称时间一致性。既是内部一致又是时间一致的数据才是正确的。

----2. RTDB 的事务特征

----由于实时任务往往有内部结构和相互之间的联系，传统的" 原子的、平淡的数据库操作序列" 的事务概念及模型对实时事务不适合。RTDB 事务表现出了许多不同的特征，这里只给出其标识性特征定时性，其余的在后面的文章" 实时数据库的事务处理" 中讨论。

----定时可以是绝对、相对或周期时间。 RTDB 的定时性一方面由数据的时间一致性引起，此时它往往取周期或定期性限制的形式，如" 每5 秒取样一次"、"7 ∶00 启动机器人 " 等；定时性的另一根源是对现实世界施加于系统的反应时间的要求，这时它典型地取施加于非周期事务的截止时间限制的形式，如" 若温度达到1000 度，则在5 秒内加冷却剂到反应堆"。

----定时性包含两方面的含义：

----定时限制即事务的执行有显式的时限，如指定的开始时间、截止时间等，它要求RTDB 必须有时间处理机制。

----定时正确性即事务能按指定的时间要求正确执行，它要求权衡定时限制与数据一致性要求等多方面因素，提供合适的调度与并发控制算法。

实时数据库系统的主要技术

---- 实时数据库系统与传统的数据库系统有着根本性的不同。要实现一个实时数据库系统，除了一般数据库的问题外，还要研究一系列关键理论与技术问题。主要有：

----1 ．实时数据模型及其语言

----到目前为止，研究实时数据库的文献鲜有专门讨论数据建模问题的，大多数文献，尤其是关于实时事务处理的都假定其具有有变化颗粒的数据项的数据模型。但这种方法有局限性，因为它没有使用一般的及时间的语义知识，而这对系统满足事务截止时间是很有用的。一般RTDB 都使用传统的数据模型，还没有引入时间维，而即使是引入了时间维的" 时态数据模型" 与" 时态查询语言" 也没有提供事务定时限制的说明机制。

----系统应该给用户提供事务定时限制说明语句，其格式可以为：

----< 事务事件>IS< 时间说明>

----< 事务事件> 为事务的" 开始"、" 提交"、" 夭折" 等。< 时间说明> 指定一个绝对、相对或周期时间。

----2 ．实时事务的模型与特性

----前面已说过，传统的原子事务模型已不适用，必须使用复杂事务模型，即嵌套、分裂/ 合并、合作、通信等事务模型。因此，实时事务的结构复杂，事务之间有多种交互行动和同步，存在结构、数据、行为、时间上的相关性以及在执行方面的依赖性，具体可参考后面" 实时数据库的事务处理" 一文。

----3 ．实时事务的处理

----RTDB 中的事务有多种定时限制，其中最典型的是事务截止期，系统必须能让截止期更早或更紧急的事务较早地执行，换句话说，就是能控制事务的执行顺序，所以，又需要基于截止期和紧迫度来标明事务的优先级，然后按优先级进行事务调度。

----另一方面，对于RTDB 事务，传统的可串行化并发控制过严，且也不一定必要，它们" 宁愿要部分正确而及时的数据，而不愿要绝对正确但过时的数据"，故应允许" 放松的可串行化" 或" 暂缓可串行化" 并发控制，于是需要开发新的并发控制正确性的概念、标准和实现技术。

----4 ．数据存储与缓冲区管理

----传统的磁盘数据库的操作是受I/O 限制的，其I/O 的时间延迟及其不确定性对实时事务是难以接受的，因此，RTDB 中数据存储的一个主要问题就是如何消除这种延迟及其不确定性，这需要底层的" 内存数据库" 支持，因而内存缓冲区的管理就显得更为重要。这里所说的内存缓冲区除" 内存数据库 " 外，还包括事务的执行代码及其工作数据等所需的内存空间。此时的管理目标是高优先事务的执行不应因此而受阻，它要解决以下问题：

----(1) 如何保证事务执行时, 只存取" 内存数据库"，即其所需数据均在内存（因而它本身没有I/O）。

----(2) 如何给事务及时分配所需缓冲区。

----(3) 必要时，如何让高优先级事务抢占低优先级事务的缓冲区。因此，传统的管理策略也不适用，必须开发新的基于优先级的算法。

----5 ．恢复

----在RTDB 中，恢复显得更为复杂。这是因为：

----(1) 恢复过程影响处于活跃状态的事务，使有的事务超截止期，这对硬实时事务是不能接受的。

----(2) RTDB 中的数据不一定总是永久的，为了保证实时限制的满足，也不一定是一致和绝对正确的，而有的是短暂的，有的是暂时不一致或非绝对正（准）确的。

----(3) 有的事务是" 不可逆" 的，所以，传统的还原/ 重启动是无意义的，可能要用" 补偿"、" 替代" 事务。

----因此，必须开发新的恢复技术与机制，应考虑到时间与资源两者的可用性，以确定最佳恢复时机与策略，而不致太伤害事务实时性的满足。

实时数据库应用与研究

----RTDB 无缝地集成了数据库与定时性，在对数据库能力和实时处理技术两者均有要求的各种领域有着极其广泛的应用前景，对多种工程或过程及时间关键型应用更是必要而迫切的，为国家的现代化尤其是国防现代化建设及国民经济的发展提供有力的、必不可少的支持，在信息技术、信息高速公路及信息产业的建设中必将起到重大作用。

----国外对RTDB 的研究非常关注，尤其是美国、英国、德国、瑞典等国起步较早，现已有许多成功的实验系统，有的甚至已商品化，典型的有HiPAC、Zip RTDBMS 等系统。国内的研究起步稍晚，基本上是在80 年代末、90 年代初才开始，但发展很快，目前已有成功的实验系统，但尚未形成正式产品，其主要原因是国内缺乏合适的实时操作系统，这已成为RTDB 发展的重要障碍，希望能引起有关方面的重视。
本文链接

计算机编码大全

2011-06-30T02:22:00Z

原作不祥

从基础的开始

最小的单元是位（bit），接着是字节（Byte），一个字节＝8位，英语表示是1 byte=8 bits 。机器语言的单位Byte。接着是KB，1 KB=1024 Byte; 接着是MB，1 MB=1024 KB; 接着是GB，1 GB=1024 MB ;接着是TB, 1TB=1024 GB。
接着是进制：二进制0和1，8进制0-7，十进制不用说，16进制0-9后面是A,B,C,D,E,F 他们关系如下：
Binary     Octal Decimal Hex
0          0      0       0
1          1      1       1
10         2      2       2
11         3      3       3
100        4      4       4
101        5      5       5
110        6      6       6
111        7      7       7
1000       10     8       8
1001       11     9       9
1010       12     10      A
1011       13     11      B
1100       14     12      C
1101       15     13      D
1110       16     14      E
1111       17     15      F

接着是上层建筑字符：

字符是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等。字符集是多个字符的集合，字符集种类较多，每个字符集包含的字符个数不同，常见字符集名称：ASCII字符集、GB2312字符集、BIG5字符集、 GB 18030字符集、Unicode字符集等。计算机要准确的处理各种字符集文字，需要进行字符编码，以便计算机能够识别和存储各种文字。

ASCII 字符集
ASCII（American Standard Code for Information Interchange，美国信息互换标准代码）是基于罗马字母表的一套电脑编码系统，它主要用于显示现代英语和其他西欧语言。它是现今最通用的单字节编码系统，并等同于国际标准ISO 646。

包含内容：

控制字符：回车键、退格、换行键等。

可显示字符：英文大小写字符、阿拉伯数字和西文符号

ASCII扩展字符集扩展：表格符号、计算符号、希腊字母和特殊的拉丁符号。

第0～32号及第127号(共34个)是控制字符或通讯专用字符，如控制符：LF（换行）、CR（回车）、FF（换页）、DEL（删除）、BEL（振铃）等；通讯专用字符：SOH（文头）、EOT（文尾）、ACK（确认）等；

第33～126号(共94个)是字符，其中第48～57号为0～9十个阿拉伯数字；65～90号为26个大写英文字母，97～122号为26个小写英文字母，其余为一些标点符号、运算符号等。

注意：在计算机的存储单元中，一个ASCII码值占一个字节(8个二进制位)，其最高位(b7)用作奇偶校验位。所谓奇偶校验，是指在代码传送过程中用来检验是否出现错误的一种方法，一般分奇校验和偶校验两种。奇校验规定：正确的代码一个字节中1的个数必须是奇数，若非奇数，则在最高位b7添1；偶校验规定：正确的代码一个字节中1的个数必须是偶数，若非偶数，则在最高位b7添1。

DEC   HEX CHAR CODE C 程序（转义）
0     00 　 NUL （’\0’）
1     01 　 SOH 　
2     02 　 STX 　
3     03 　 ETX 　
4     04 　 EOT 　
5     05 　 ENQ 　
6     06 　 ACK 　
7     07 　 BEL （’\a’）
8     08 　 BS （’\b’）
9     09 　 HT （’\t’）
10    0A 　 LF （’\n’）
11    0B 　 VT （’\v’）
12    0C 　 FF （’\f’）
13    0D 　 CR （’\r’）
14    0E 　 SO 　
15    0F 　 SI 　
16    10 　 DLE 　
17    11 　 DC1 　
18    12 　 DC2 　
19    13 　 DC1 　
20    14 　 DC4 　
21    15 　 NAK 　
22    16 　 SYN 　
23    17 　 ETB 　
24    18 　 CAN 　
25    19 　 EM 　
26    1A 　 SUB 　
27    1B 　 ESC 　
28    1C 　 FS 　
29    1D 　 GS 　
30    1E 　 RS 　
31    1F 　 US 　
32    20 (space，空格) 　　
33    21    ! 　　
34    22    " 　　
35    23    # 　　
36    24    $ 　　
37    25    % 　　
38    26    & 　　
39    27    ’ 　　
40    28    ( 　　
41    29    ) 　　
42    2A    * 　　
43    2B    + 　　
44    2C    , 　　
45    2D    - 　　
46    2E    . 　　
47    2F    / 　　
48    30    0 　　
49    31    1 　　
50    32    2 　　
51    33    3 　　
52    34    4 　　
53    35    5 　　
54    36    6 　　
55    37    7 　　
56    38    8 　　
57    39    9 　　
58    3A    : 　　
59    3B    ; 　　
60    3C    < 　　
61    3D    = 　　
62    3E    > 　　
63    3F    ? 　　
64    40    @ 　　
65    41    A 　　
66    42    B 　　
67    43    C 　　
68    44    D 　　
69    45    E 　　
70    46    F 　　
71    47    G 　　
72    48    H 　　
73    49    I 　　
74    4A    J 　　
75    4B    K 　　
76    4C    L 　　
77    4D    M 　　
78    4E    N 　　
79    4F    O 　　
80    50    P 　　
81    51    Q 　　
82    52    R 　　
83    53    S 　　
84    54    T 　　
85    55    U 　　
86    56    V 　　
87    57    W 　　
88    58    X 　　
89    59    Y 　　
90    5A    Z 　　
91    5B    [ 　　
92    5C    \ 　（’\\’）
93    5D    ] 　　
94    5E    ^ 　　
95    5F    _ 　　
96    60    ` 　　
97    61    a 　　
98    62    b 　　
99    63    c 　　
100   64    d 　　
101   65    e 　　
102   66    f 　　
103   67    g 　　
104   68    h 　　
105   69    i 　　
106   6A    j 　　
107   6B    k 　　
108   6C    l 　　
109   6D    m 　　
110   6E    n 　　
111   6F    o 　　
112   70    p 　　
113   71    q 　　
114   72    r 　　
115   73    s 　　
116   74    t 　　
117   75    u 　　
118   76    v 　　
119   77    w 　　
120   78    x 　　
121   79    y 　　
122   7A    z 　　
123   7B    { 　　
124   7C    | 　　
125   7D    } 　　
126   7E    ~ 　　
127   7F     　 DEL

GB2312 字符集

GB2312又称为GB2312-80字符集，全称为《信息交换用汉字编码字符集·基本集》，由原中国国家标准总局发布，1981年5月1日实施，是中国国家标准的简体中文字符集。它所收录的汉字已经覆盖99.75%的使用频率，基本满足了汉字的计算机处理需要。在中国大陆和新加坡获广泛使用。

GB2312收录简化汉字及一般符号、序号、数字、拉丁字母、日文假名、希腊字母、俄文字母、汉语拼音符号、汉语注音字母，共 7445 个图形字符。其中包括6763个汉字，其中一级汉字3755个，二级汉字3008个；包括拉丁字母、希腊字母、日文平假名及片假名字母、俄语西里尔字母在内的682个全角字符。

GB2312中对所收汉字进行了“分区”处理，每区含有94个汉字/符号。这种表示方式也称为区位码。

它是用双字节表示的，两个字节中前面的字节为第一字节，后面的字节为第二字节。习惯上称第一字节为“高字节” ，而称第二字节为“低字节”。“高位字节”使用了0xA1-0xF7(把01-87区的区号加上0xA0)，“低位字节”使用了0xA1-0xFE(把01-94加上0xA0)。

以GB2312字符集的第一个汉字“啊”字为例，它的区号16，位号01，则区位码是1601，在大多数计算机程序中，高字节和低字节分别加0xA0得到程序的汉字处理编码0xB0A1。计算公式是：0xB0=0xA0+16, 0xA1=0xA0+1。

GBK字符集
GBK字符集是GB2312的扩展(K)，GBK1.0收录了21886个符号，它分为汉字区和图形符号区，汉字区包括21003个字符。GBK字符集主要扩展了繁体中文字的支持。

BIG5 字符集

BIG5又称大五码或五大码，1984年由台湾财团法人信息工业策进会和五间软件公司宏碁 (Acer)、神通 (MiTAC)、佳佳、零壹 (Zero One)、大众 (FIC)创立，故称大五码。Big5码的产生，是因为当时台湾不同厂商各自推出不同的编码，如倚天码、IBM PS55、王安码等，彼此不能兼容；另一方面，台湾政府当时尚未推出官方的汉字编码，而中国大陆的GB2312编码亦未有收录繁体中文字。

Big5字符集共收录13,053个中文字，该字符集在中国台湾使用。耐人寻味的是该字符集重复地收录了两个相同的字：“兀”(0xA461及0xC94A)、“嗀”(0xDCD1及0xDDFC)。

Big5码使用了双字节储存方法，以两个字节来编码一个字。第一个字节称为“高位字节”，第二个字节称为“低位字节”。高位字节的编码范围0xA1-0xF9，低位字节的编码范围0x40-0x7E及0xA1-0xFE。

尽管Big5码内包含一万多个字符，但是没有考虑社会上流通的人名、地名用字、方言用字、化学及生物科等用字，没有包含日文平假名及片假字母。

例如台湾视“着”为“著”的异体字，故没有收录“着”字。康熙字典中的一些部首用字(如“亠”、“疒”、“辵”、“癶”等)、常见的人名用字(如“堃”、“煊”、“栢”、“喆”等) 也没有收录到Big5之中。

GB18030 字符集

GB18030的全称是GB18030-2000《信息交换用汉字编码字符集基本集的扩充》，是我国政府于2000年3月17日发布的新的汉字编码国家标准，2001年8月31日后在中国市场上发布的软件必须符合本标准。GB 18030字符集标准的出台经过广泛参与和论证，来自国内外知名信息技术行业的公司，信息产业部和原国家质量技术监督局联合实施。

GB 18030字符集标准解决汉字、日文假名、朝鲜语和中国少数民族文字组成的大字符集计算机编码问题。该标准的字符总编码空间超过150万个编码位，收录了27484个汉字，覆盖中文、日文、朝鲜语和中国少数民族文字。满足中国大陆、香港、台湾、日本和韩国等东亚地区信息交换多文种、大字量、多用途、统一编码格式的要求。并且与Unicode 3.0版本兼容，填补Unicode扩展字符字汇“统一汉字扩展A”的内容。并且与以前的国家字符编码标准（GB2312，GB13000.1）兼容。

编码方法：
GB 18030标准采用单字节、双字节和四字节三种方式对字符编码。单字节部分使用0×00至0×7F码(对应于ASCII码的相应码)。双字节部分，首字节码从0×81至0×FE，尾字节码位分别是0×40至0×7E和0×80至0×FE。四字节部分采用GB/T 11383未采用的0×30到0×39作为对双字节编码扩充的后缀，这样扩充的四字节编码，其范围为0×81308130到0×FE39FE39。其中第一、三个字节编码码位均为0×81至0×FE，第二、四个字节编码码位均为0×30至0×39。

按照程序员的称呼，GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。

接着是国际通用的unicode字符集

Unicode字符集（简称为UCS）

1．名称的由来

Unicode字符集编码是（Universal Multiple-Octet Coded Character Set）通用多八位编码字符集的简称，支持世界上超过650种语言的国际字符集。Unicode允许在同一服务器上混合使用不同语言组的不同语言。它是由一个名为 Unicode 学术学会(Unicode Consortium)的机构制订的字符编码系统，支持现今世界各种不同语言的书面文本的交换、处理及显示。该编码于1990年开始研发，1994年正式公布，最新版本是2005年3月31日的Unicode 4.1.0。Unicode是一种在计算机上使用的字符编码。它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。

2．编码方法

Unicode 标准始终使用十六进制数字，而且在书写时在前面加上前缀“U+”，例如字母“A”的编码为 004116 。所以“A”的编码书写为“U+0041”。

3．UTF-8 编码
UTF-8是Unicode的其中一个使用方式。 UTF是 Unicode Translation Format，即把Unicode转做某种格式的意思。

UTF-8便于不同的计算机之间使用网络传输不同语言和编码的文字，使得双字节的Unicode能够在现存的处理单字节的系统上正确传输。

UTF-8使用可变长度字节来储存 Unicode字符，例如ASCII字母继续使用1字节储存，重音文字、希腊字母或西里尔字母等使用2字节来储存，而常用的汉字就要使用3字节。辅助平面字符则使用4字节。

4．UTF-16 和 UTF-32 编码
UTF-32、UTF-16 和 UTF-8 是 Unicode 标准的编码字符集的字符编码方案，UTF-16 使用一个或两个未分配的 16 位代码单元的序列对 Unicode 代码点进行编码；UTF-32 即将每一个 Unicode 代码点表示为相同值的 32 位整数

通过一个问题了解unicode编码

问题：使用Windows记事本的“另存为”，可以在ANSI、GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件，Windows怎样识别编码方式的呢？
我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节，分别是FF、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。但这些标记是基于什么标准呢？

答案：

ANSI字符集定义：ASCII字符集，以及由此派生并兼容的字符集，如：GB2312，正式的名称为MBCS(Multi-Byte Chactacter System，多字节字符系统)，通常也称为ANSI字符集。

UNICODE 与 UTF8、UTF16

由于每种语言都制定了自己的字符集，导致最后存在的各种字符集实在太多，在国际交流中要经常转换字符集非常不便。因此，产生了Unicode字符集，它固定使用16 bits(两个字节)来表示一个字符，共可以表示65536个字符
标准的 Unicode 称为UTF-16(UTF:UCS Transformation Format )。后来为了双字节的Unicode能够在现存的处理单字节的系统上正确传输，出现了UTF-8，使用类似MBCS的方式对Unicode进行编码。(Unicode字符集有多种编码形式)
例如"连通"两个字的Unicode标准编码UTF-16 (big endian)为：DE 8F 1A 90
而其UTF-8编码为：E8 BF 9E E9 80 9A

当一个软件打开一个文本时，它要做的第一件事是决定这个文本究竟是使用哪种字符集的哪种编码保存的。软件一般采用三种方式来决定文本的字符集和编码：
检测文件头标识，提示用户选择，根据一定的规则猜测
最标准的途径是检测文本最开头的几个字节，开头字节 Charset/encoding,如下表：
EF BB BF      UTF-8
FE FF           UTF-16/UCS-2, little endian
FF FE           UTF-16/UCS-2, big endian
FF FE 00 00 UTF-32/UCS-4, little endian.
00 00 FE FF UTF-32/UCS-4, big-endian.

1、big endian和little endian
big endian和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时，究竟是将6C写在前面，还是将49写在前面？如果将6C写在前面，就是big endian。还是将49写在前面，就是little endian。
“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开，由此曾发生过六次叛乱，其中一个皇帝送了命，另一个丢了王位。
我们一般将endian翻译成“字节序”，将big endian和little endian称作“大尾”和“小尾”。

2、字符编码、内码，顺带介绍汉字编码
字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码，为了处理汉字，程序员设计了用于简体中文的GB2312和用于繁体中文的big5。
GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。
GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030，对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。
从ASCII、GB2312、GBK到GB18030，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。
有的中文Windows的缺省内码还是GBK，可以通过GB18030升级包升级到GB18030。不过GB18030相对GBK增加的字符，普通人是很难用到的，通常我们还是用GBK指代中文Windows内码。
这里还有一些细节：
GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。
在DBCS中，GB内码的存储格式始终是big endian，即高位在前。
GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析：在读取DBCS字符流时，只要遇到高位为1的字节，就可以将下两个字节作为一个双字节编码，而不用管低字节的高位是什么。

3、Unicode、UCS和UTF(UCS Transformation Format)
前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容（更准确地说，是与ISO-8859-1兼容），与GB码不兼容。例如“汉”字的Unicode编码是6C49，而GB码是BABA。

UCS规定了怎么用多个字节表示各种文字。而怎样传输这些编码，是由UTF(UCS Transformation Format)规范规定的！常见的UTF规范包括UTF-8、UTF-7、UTF-16。

4、UTF的字节序和BOM
UTF-8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”，那么这是“奎”还是“乙”？
Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：
在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。
这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。
UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF（读者可以用我们前面介绍的编码方法验证一下）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。
Windows就是使用BOM来标记文本文件的编码方式的。

写到这里对编码有了大致的了解了，就可以理解网上一些文章的话了，比如有一篇很流行的文章《URL编码与SQL注射》里面有一段是这么说的：

其实url编码就是一个字符ascii码的十六进制。不过稍微有些变动，需要在前面加上“%”。比如“\”，它的ascii码是92，92的十六进制是5c，所以“\”的url编码就是%5c。那么汉字的url编码呢？很简单，看例子：“胡”的ascii码是-17670，十六进制是BAFA，url编码是“%BA%FA”。呵呵，知道怎么转换的了吧。

这得从ASCII说起，扩展的ASCII字符集采用8bit255个字符显然不够用，于是各个国家纷纷制定了自己的文字编码规范，其中中文的文字编码规范叫做“GB2312-80”（就是GB2312)，它是和ASCII兼容的一种编码规范，其实就是用扩展ASCII没有真正标准化这一点，把一个中文字符用两个扩展ASCII字符来表示。文中说的的中文ASCII码实际上就是简体中文的编码2312GB！它把ASCII又扩充了一个字节，由于高位的第一位是0，所以会出现负数的形式，url编码就是将汉字的这个GB2312编码转化成UTF-8的编码并且每8位即一个字节前面加上%符号表示。

那为何UTF-8是进行网络的规范传输编码呢？

在Unicode里，所有的字符被一视同仁。汉字不再使用“两个扩展ASCII”，而是使用“1个Unicode”，注意，现在的汉字是“一个字符”了，于是，拆字、统计字数这些问题也就自然而然的解决了。但是，这个世界不是理想的，不可能在一夜之间所有的系统都使用Unicode来处理字符，所以Unicode在诞生之日，就必须考虑一个严峻的问题：和ASCII字符集之间的不兼容问题。

我们知道，ASCII字符是单个字节的，比如“A”的ASCII是65。而Unicode是双字节的，比如“A”的Unicode是0065，这就造成了一个非常大的问题：以前处理ASCII的那套机制不能被用来处理Unicode了

另一个更加严重的问题是，C语言使用'\0'作为字符串结尾，而Unicode里恰恰有很多字符都有一个字节为0，这样一来，C语言的字符串函数将无法正常处理Unicode，除非把世界上所有用C写的程序以及他们所用的函数库全部换掉

于是，比Unicode更伟大的东东诞生了，之所以说它更伟大是因为它让Unicode不再存在于纸上，而是真实的存在于我们大家的电脑中。那就是：UTF

UTF= UCS Transformation Format UCS转换格式，它是将Unicode编码规则和计算机的实际编码对应起来的一个规则。现在流行的UTF有2种：UTF-8和UTF-16

其中UTF-16和上面提到的Unicode本身的编码规范是一致的，这里不多说了。而UTF-8不同，它定义了一种“区间规则”，这种规则可以和ASCII编码保持最大程度的兼容，这样做的好处是压缩了字符在西欧一些国家的内存消耗，减少了不必要的资源浪费，这在实际应用中是非常有必要的。

UTF-8有点类似于Haffman编码，它将Unicode编码为：
00000000-0000007F的字符，用单个字节来表示；

00000080-000007FF的字符用两个字节表示（中文的编码范围）

00000800-0000FFFF的字符用3字节表示

因为目前为止Unicode-16规范没有指定FFFF以上的字符，所以UTF-8最多是使用3个字节来表示一个字符。但理论上来说，UTF-8最多需要用6字节表示一个字符。

在UTF-8里，英文字符仍然跟ASCII编码一样，因此原先的函数库可以继续使用。而中文的编码范围是在0080-07FF之间，因此是2个字节表示（但这两个字节和GB编码的两个字节是不同的）。

看看编码之多：ANSI,AscII,GB2312,GBK,BIG5,GB18030,Unicode,UCS（就是unicode）Utf-8,utf-16,utf-32 整整10种编码～，算是够复杂了
可是这还仅仅是个开始，应用方面变化无穷，不过现在看到这些东西起码再不会头大了！呼呼～

哦，漏了一个加密的base64编码。

什么是Base64？

按照RFC2045的定义，Base64被定义为：Base64内容传送编码被设计用来把任意序列的8位字节描述为一种不易被人直接识别的形式。（The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable.）

为什么要使用Base64？

在设计这个编码的时候，我想设计人员最主要考虑了3个问题：
1.是否加密？
2.加密算法复杂程度和效率
3.如何处理传输？

加密是肯定的，但是加密的目的不是让用户发送非常安全的Email。这种加密方式主要就是“防君子不防小人”。即达到一眼望去完全看不出内容即可。
基于这个目的加密算法的复杂程度和效率也就不能太大和太低。和上一个理由类似，MIME协议等用于发送Email的协议解决的是如何收发Email，而并不是如何安全的收发Email。因此算法的复杂程度要小，效率要高，否则因为发送Email而大量占用资源，路就有点走歪了。

但是，如果是基于以上两点，那么我们使用最简单的恺撒法即可，为什么Base64看起来要比恺撒法复杂呢？这是因为在Email的传送过程中，由于历史原因，Email只被允许传送ASCII字符，即一个8位字节的低7位。因此，如果您发送了一封带有非ASCII字符（即字节的最高位是1）的Email通过有“历史问题”的网关时就可能会出现问题。网关可能会把最高位置为0！很明显，问题就这样产生了！因此，为了能够正常的传送Email，这个问题就必须考虑！所以，单单靠改变字母的位置的恺撒之类的方案也就不行了。关于这一点可以参考RFC2046。
基于以上的一些主要原因产生了Base64编码。

鉴于算法比较让人头大，想看的人自然会有看到的办法拉，俺是头大得很，就不放上来了。

本文链接

实时数据库简介和比较

2011-06-29T09:05:00Z

      实时数据库是数据库系统发展的一个分支，它适用于处理不断更新的快速变化的数据及具有时间限制的事务处理。实时数据库技术是实时系统和数据库技术相结合的产物，实时数据库系统的主要内容包括：
     实时数据库模型；
     实时事务调度：包括并发控制、冲突解决、死锁等内容；
     容错性与错误恢复；
     内存组织与管理；
     访问准入控制；
     I/O与磁盘调度；
    主内存数据库系统；
    不精确计算问题；
    放松的可串行化问题；
    实时SQL；
     实时事务的可预测性；

    研究现状与发展。
    目前在国内比较流性的国外实时数据库产品有Wonderware公司的Industrial SQL，OSIsoft公司的PI ，AspenTech公司的 IP21 (

InfoPlus 。21 )。以5000点数据库和20客户端应用为例，几个数据库价格分别是：

PI----10万美元，每个接口6000美元，OPC接口收费；

InfoPlus.21----11万美元，每个接口1万美元，OPC接口不收费；
Industrial SQL Server----6.5万美元，每个IDAS1200美元，OPC Link免费。

     实时数据数据库产品
      PI将所有数据存于专有数据库中，对于过程数据的存储模式，每个点只有6个域可以由用户定义。PI是纯实时数据库，如果要实现企业更高级的应用还要配备关系型数据库。
      PI采用了旋转门压缩专利技术和独到的二次过滤技术，使进入到PI数据库的数据经过了最有效的压缩，极大地节省了硬盘空间。据计算，每秒1万点数据存储一年，仅需要4G的空间，即一只普通硬盘也可存贮五到十年的数据。是效率最高，使用最简单，使用最广泛的实时数据库，因为其杰出的性能，PI已经多次提高了它的价格，而且PI在其文档中公开了它的各种算法，比如上面提到的旋转门压缩和二次过滤。

    OSI公司没有提供PI服务器软件和客户端软件汉化版本，但是据说在开发中，可以看见DataLink的某个汉化版本。国内某些公司也在为客户做授权的汉化工作。

系统性能
每个PI服务器可容纳150万点(高端服务器)，在PI的高端产品服务器中可以处理每秒钟150万点的数据。在客户端软件ProcessBook上，可以在秒级时间内从2年或3年历史中取到1000点数据。

参考OSI公司提供的数据：实时信息点的数据值1天的平均变化次数为500，每个信息点所占的存储空间为3个字节，那1万个点在线存储1年所需的存储空间是：
变化次数 × 单点存储空间 × 信息点数 × 1年的天数 = 总空间要求
500 × 3 × 10000 × 365 = 5.475GB

当然，硬盘很便宜，但是节约空间不是我们的出发点，关键是快速回放数据。

设备接口支持
OSI公司提供全球600多种DCS接口软件，同时可以支持OPC数据采集，使得PI数据库成为企业生产控制系统与管理信息系统连接的桥梁。

客户端工具
PI-ProcessBook：组织和显示过程信息，提供流程图、实时和历史趋势，包含VBA编程环境。
Pi-datalink:Excel 内嵌的宏。为最终用户提供了非常灵活的过程数据分析工具。可以提供用VBA来建各种所需的数学分析，可提供了最常规分析工具，包括：平均值、移动平均、几何平均、标准偏差、累计值等等。
PI-Batch：生产批处理程序。
PI-ML：手动录入终端（提供软件或硬件两种形式）。
PI－ ACE：允许用户写方程式。在捕获相似的数据集时，可以不用费力地重复使用这些方程式。
PI ICE：适于企业级实时绩效管理的最有创新意义的web应用。
PI ActiveView：无缝地给web提供现有的PI ProcessBook显示。
PI告警视图：汇总PI 告警服务器信息，以分层次的树形结构向任意个现场客户或场外客户显示那些数据。
PI批视图：在Windows台式电脑计算机上显示PI 批数据。
PI系统管理工具：一套通过客户的PC机对PI系统实施管理的应用程序。
PI模块数据库：将PI系统中的内容分成有用的组，帮助组织实时数据，储存参数或规格，并使它们随时可以用于程序和显示中。
RLINK：生产数据（PI）与SAP R/3、JD Edwards OneWorld、MRO Software Maximo和Indus International PassPort/EMPAC等ERP或EAM（企业资产管理）系统之间的一个双向网关。

二次开发工具
PI提供API，SDK, PI ODBC & PI OLEDB二次开发工具实现从数据库读取数据或写入数据到实时数据库中。另外，PI的客户端ProceBook中内嵌了VBA，方便对ProceBook功能的扩充和客户化。

PI API (Application Programming Interface，应用程序开发接口)
PI-API是一组C语言函数，提供了对PI系统进行访问的通用编程接口，应用程序可以通过调用PI-API函数访问或操作PI系统。许多PI的客户端软件，包括PI ProcessBook、PI

DataLink、PI ProfileView等，都是通过PI-API与PI服务器通信。用户可以在UNIX,WINDOWS平台上调用。

PI SDK（Software Development Kit，软件开发包）
PI SDK是PI提供的另一个编程工具集，用以访问PI服务器以及相关子系统。它采用微软ActiveX技术，内含一个ActiveX进程内组件，一个ActiveX控件和其他一些支持代码库，如

在线文档、示例代码、支持文档等。ActiveX基于COM组件技术，在Microsoft Windows平台下具有开发语言无关性特点。用户可以在开发简便的。NET中使用PI SDK访问PI服务器，

也可以在高效的C++中使用，以及在其他所有支持COM技术的开发工具中使用PI SDK。

PI ODBC & PI OLEDB

ODBC是数据库领域的一个开放的工业标准。OLEDB是微软基于COM的一个数据库访问接口标准。使用PI ODBC和PI OLEDB，用户能够像访问关系数据库一样访问PI系统。基于PI ODBC

或PI OLEDB的数据接口程序和客户端应用程序，可利用标准的SQL语句访问PI数据库，包括PI Archive、PI Point Database或其他配置数据。

国内用户
OSI将其数据库定位于企业信息化集成平台，专注于实时数据软件的研发和服务，主要用于大型流程行业用户，如电力、石油、化工和冶金等。目前中国使用PI软件的企业达到一

百多家，主要集中在电力、石油、化工行业，国内冶金行业用户有唐山钢铁公司厂、太原钢铁集团第2炼钢厂、石家庄钢铁公司等。

本文链接

实时/历史数据库和关系型数据库的区别

2011-06-29T08:45:00Z

实时数据库

实时数据库是数据库系统发展的一个分支，它适用于处理不断更新的快速变化的数据及具有时间限制的事务处理。实时数据库技术是实时系统和数据库技术相结合的产物。实时数据库最起初是基于先进控制和优化控制而出现的，对数据的实时性要求比较高，因而实时、高效、稳定是实时数据库最关键的指标。

早期实时数据库的概念即我们所说的内存数据库，其相当于数据中枢的作用，将厂级相互孤立的DCS数据有效整合起来，在厂级应用中某个DCS的数据可为其他DCS的工艺算法提供数据支持，其有效解决了数据孤岛问题，拓展了DCS的功能，因而，实时数据库在先进控制和优化控制中起到了尤为重要的作用。

但早期的内存数据库并不能有效的解决实时数据的细时间粒度压缩存储，工业模型对象数值属性高度分类抽象，大容量数据的高效实时检索及处理等关键问题。而实时数据库在数据通信、数据组织、数据存储、数据检索、数据访问、数据处理、数据展现等方面的专业化及产品化，为构建基于大容量实时历史数据之上的分析应用提供了便捷稳定的数据支撑，使应用系统可以从更高更深层次充分利用宝贵的生产实时历史数据。

目前，实时数据库已广泛应用于电力、石油石化、交通、冶金、军工、环保等行业，是构建工业生产调度监控系统、指挥系统，生产实时历史数据中心的不可缺少的基础软件。

关系数据库

关系数据库，是指采用了关系模型来组织数据的数据库。关系模型是在1970年由IBM首先提出，在之后的几十年中，关系模型的概念得到了充分的发展并逐渐成为数据库架构的主流模型。简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。关系型数据库有着以下特点：

容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解。

使用方便：通用的SQL语言使得操作关系型数据库非常方便，程序员甚至于数据管理员可以方便地在逻辑层面操作数据库，而完全不必理解其底层实现。

易于维护：丰富的完整性（实体完整性、参照完整性和用户定义的完整性）大大降低了数据冗余和数据不一致的概率。

目前，关系数据库广泛应用于各个行业，用于构筑管理信息系统，如ERP，MIS，EAM等重要系统，是构建管理信息系统，存储及处理关系数据的不可缺少基础软件。

两种数据库之间的一些差别

? 数据的组织方式

实时数据库可以简单地理解为它是这样的数据库：由测点信息库、实时数据库、历史数据库三个数据库组成。

测点信息库含有一个测点基本信息字段的一张表，这个表以测点标签作为关键字，对应一条测点基本信息的记录包含一条测点的基本配置信息，如压缩偏差，例外偏差，测点描述等。用户可从此数据库中查询测点的基本信息。实时数据库是内存快照数据库，反映了生产实时数据的时间戳、数值、质量等秒级变化。用户可从此数据库中查询生产实时数据的实时数据值（值，时间戳，质量）。

历史数据库是含有一个以测点名称字段和时间字段为关键字的一张表，这张表的另外的一个重要的字段就是数值字段，用来存储测点的采集值，除了这些字段，还可以包含数据的状态，数据质量字段等。随着时间的变化，不断地将实时数据库中的实时数据进行压缩过滤，并更新磁盘历史数据文件中的表里的数据。用户可从此数据库中查询生产实时数据的历史样本值或历史插值数据。

而对于关系数据库则是根据各个实体之间的关系来设计数据表的。

? 系统稳定性

由于实时数据库记录的是和生产相关的数据，并且和时间相关，所以要求其必须能够长时间稳定运行，否则就会导致数据的丢失。目前一些实时数据库已经具有缓存数据的功能，当数据采集机器和实时数据库服务器之间通信出现故障时，可以把采集到的数据缓存到本地，当通信恢复正常后，把缓存的数据写入到实时数据库服务器中，极大地保证了数据的完整性。

而对于关系数据库来说，如果不是应用在关键业务，比如金融证券等，对稳定要求一般来说不是很高。

? 数据来源

针对不同的类型的企业，实时数据库的数据的来源也不尽相同。主要来源有DCS控制系统，数据采集系统（SCADA）,手工录入，关系数据库等。这些数据的主要特点就是都和生产直接相关，并且大多数的数据都是数值型数据，比如设备或介质的压力、温度、流量、位置、电压、电流、功率等。

关系数据库的来源更加多样。除了记录数值数据外，也记录描述性的数据，如姓名家庭住址等信息。

一般来说，实时数据库的数据来源一般是设备。而关系数据库的数据来源一般是来自于人。

? 数据压缩

实时数据库因为存储的数据量非常大，比如要采集10000点的数据，每5秒采集一个数据，假设采集的都是32位浮点数，那么一天的数据量（仅数值属性不含时间属性）就是10000*（60/5）*60*24*4/1024=675000K，大约675M的数据。由此可见数据量的庞大，而且占用磁盘的空间大，对数据的访问速度也会降低。因此各个数据库厂家大都开发出自己的数据压缩算法，对数据进行压缩。常用的压缩算法可以分为三类：无损压缩，有损压缩，二级压缩。其中，无损压缩一般以通用压缩理论为基础，采取huffman等经典的压缩算法；而有损压缩则更多地考虑了工业实时数据的特征，而采取的一些特殊舍点算法；二级压缩技术，则是同时利用了这两种数据压缩技术。实时数据库的无损压缩以通用压缩理论为基础。目前比较著名的有损压缩算法,有常用的旋转门压缩算法，以及一些变通压缩算法（如在旋转门算法基础上改用二次均方差作为偏差比较，以提高数据还原精度），这些算法原理都比较简单。

关系型数据库则不会对数据进行压缩。

? 数据的访问方式

实时数据库一般有以下3种方式访问数据

1) 使用自己的API,这种方式效率最高也最简单。

2) 使用ODBC或者OLEDB,这种方式不大常用，主要是给那些刚刚接触实时数据库或者以前对关系型数据库了解的用户使用的。

3) 使用Opc方式访问数据。Opc是一种广泛使用的工业标准，虽然效率不高，但是目前很多的厂家都支持。

关系数据库访问数据的方式是通过结构化查询语言（SQL）来访问的。

? 应用领域

过程控制系统是实时数据库系统最重要的应用领域之一.在生产装置运行过程中，实时数据库实时记录采集装置的运行数据，随时掌握装置的运行状况，并通过对生产过程的关键数据的监控和分析，对出现的问题及时处理，使生产的运行状态保持安全平稳,当生产状况发生变化时可以及时作出反映；通过对影响原材料用量的过程监视以及对水电汽的用量的监测分析，可以及时发现问题，特别对生产调度人员来说，可以及时地平衡物料供应，减少单耗，提高经济效益。

而关系数据库的应用则广泛的多，在各行各业基本都可以见到。大多数应用在管理方面，比如管理信息系统（MIS），客户关系管理（CRM）等。

? 客户端工具

实时数据库由于目前并没有统一的标准，各个实时数据库客户端工具基本上都是由厂商自己提供的，主要是数据展示工具，组态工具，管理工具等。因为主要是面向流程工业，所以实时数据库都带有组态和发布工具。

关系数据库因为应用范围广泛，客户工具相当丰富。除了厂商提供的工具外，第三方软件厂商也可以为关系数据库厂商开发客户端工具。

两种数据库之间的集成趋势

虽然实时数据库和关系数据库有着很多的不同，但是目前实时数据库和关系数据库集成的趋势越来越明显。将生产管理信息系统中使用的关系数据库和实时数据库集成到一起，可以同时满足控制和管理的要求，真正成为管理控制一体化的平台。例如，目前大多行业均利用实时数据库与关系数据库作为基础数据库软件构建监控中心及数据中心的基础数据库。其中实时数据库处理并存储生产实时数据，关系数据库处理并存储业务关系数据。

本文链接

博客园_STARTING UP……

重温一下CSS语法

各浏览器下使用 OBJECT 元素和 EMBED 元素嵌入 Flash 存在差异

问题描述 通常情况下，IE 系列浏览器通过 ActiveX 插件使用 OBJECT 元素引入 Flash，而其他浏览器则是通过相应的 NPAPI 插件使用 EMBED 元素。这造成了各浏览器中插入 Flash 的方式的差异。

造成的影响 若仅仅使用 OBJECT 元素设置了 classid 属性引入 Flash，则可能造成在某些浏览器中 Flash 无法被引入。而若嵌套的 OBJECT 和 EMBED 元素参数不统一，也可能造成引入的 Flash 在各浏览器中出现差异。

受影响的浏览器 所有浏览器

中国煤炭行业信息化软件系统应用分析

中国煤矿历年事故死亡人数及分析

装Office 2010提示Error 1406的解决方法

实时数据库的事务处理

实时数据库系统

计算机编码大全

实时数据库简介和比较

实时/历史数据库和关系型数据库的区别

问题描述

通常情况下，IE 系列浏览器通过 ActiveX 插件使用 OBJECT 元素引入 Flash，而其他浏览器则是通过相应的 NPAPI 插件使用 EMBED 元素。这造成了各浏览器中插入 Flash 的方式的差异。

造成的影响

若仅仅使用 OBJECT 元素设置了 classid 属性引入 Flash，则可能造成在某些浏览器中 Flash 无法被引入。而若嵌套的 OBJECT 和 EMBED 元素参数不统一，也可能造成引入的 Flash 在各浏览器中出现差异。

受影响的浏览器

所有浏览器