web报表打印系统解决方案.doc

《web报表打印系统解决方案.doc》由会员分享，可在线阅读，更多相关《web报表打印系统解决方案.doc（15页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、【精品文档】如有侵权，请联系网站删除，仅供学习与交流web报表打印系统解决方案.精品文档.web打印/套打 自从开发web程序以来，web打印就一直是困饶大家的大问题。基于web的打印，难度在于要将浏览器中呈现的html，精确地打印到票据中，而且能够实现对分页位置的控制。下面就IE浏览器所能采用的打印解决方案，来个汇总分析。一、 浏览器的打印功能菜单 这种方案的优势是不需要对浏览器作任何扩充，是最简单的办法，但问题也最多，如：1 不能精确分页。 浏览器一般是根据用户设置的页面大小，web页面的内容多少，来自行决定分页位置，程序员很难控制。会有页脚页眉干扰。 2 不能准确地控制边距及打印文字。

2、3 不能解决连续打印。 比如，不是仅打印一张票据，而是连续一次打印若干个票据。二、 使用webbrowser控件+ javascript 这实际上，是浏览器打印功能菜单的一种程序调用，与打印功能菜单没什么两样。分页的问题仍然存在，只不过，可以让用户不用去点菜单，直接在网页中的一个按钮，或一个链接里面调用罢了。三、 使用print css 这是一种最理想的实现web套打的方法。这种方法通过在html文档中，嵌入打印相关的css样式，来实现对html文档输出打印的控制，比如设置纸张大小，纸张纵横方向，打印边距，分页等。显而易见，这种方式成本小，不需要下载任何插件，而且跨平台性非常好。print c

3、ss推出已经有些时日，但遗憾的是，至今没有一个厂商的浏览器很好地实现了这些标准，这使得程序员目前还不能利用print css进行实际的开发。关于打印css，参见： http:/css- 四、 使用pdf文件 用这种方式，就是从服务器端下载一个pdf文件流，在IE中用adobe插件打开，然后用adobe的打印菜单进行打印，虽然这种方案，也能实现精确套打，但需要下载adobe插件。这是国外报表工具经常推荐的一种打印方法，但在pdf不那么普及的中国，这种方案不是最好选择。 五、 采用纯ActiveX 这种方案就是下载一个控件，票据的数据不再以html方式呈现，而是呈现在ActiveX中。这种方案的优

4、点是打印的精确度高，分页的可控性好，但缺点也是很明显的，嵌入ActiveX控件破坏了web应用的整体html风格，且这样的控件比较大（一般超过1M，下载颇费时间）。六、 采用Applet方式 采用Applet方式，分页或精确打印，都可以做到完美，但缺点也很明显，表现在：1安装Applet成本巨大。需要下载十几M的文件。 Applet本身可能并不大，但运行Applet所需的jre一般至少10几M（jre1.4.2 ， 15.45M）。用户需要极大的耐心，来进行打印。 2打印报表时，需要重新向服务器检索数据，效率低。 因为Applet方案，一般采用html方式呈现数据，打印时Applet必须向服务

5、器检索同一张票据的数据，看上去，是打印了当前页的票据，实际上，Applet根本不会用当前html页的数据来打印，而是向服务器下载数据到Applet中来打印。也就是说，打印的话，必须两次请求，一次html呈现，一次用来打印。 七、 轻量级的ActiveX打印方式轻量级的ActiveX打印方案的优点是：1. 效率高； 可以直接打印指定的html文档，不必向后台再次提起请求。 2. 能做到精确打印，分页； 3. 功能丰富， 可以利用该控件，实现对当前票据文档的打印，预览，及多个html文档的连续打印。4. 下载量小， ActiveX只有75K。 e表就是采用第七种方式来实现报表的打印。e表内置了一个

6、用c+写的轻量级的ActiveX控件来精确地控制客户端的打印机。一举解决web打印问题。近期因为专注于用c# 实现web报表，积累了一些经验和心得，也写过一篇介绍文章,也有网友提出没有说清楚。现觉得想用单篇文章来说明web报表开发难免会大而空，落不到实处。因而便想到每篇文章只关注web报表开发中一方面，由多篇文章而形成一个web报表开发的系列文章，这些web报表开发的系列文章无先后次序，主从之分。每篇文章只是以一种视角来看待web报表开发而已。大家可以只选自己感兴趣的部分来看，这样也能节约大家的时间。这便是web报表开发技术专题的由来。废话少说，今天便从小小的序号说起吧！web报表开发技术专题

7、一：序号问题在中国式报表中，常常会见到单元格中有 1,2,3,4 .成一行或一列排列。这便是序号。显然这些序号值在数据源中是不存在的，需要web报表开发工具根据一定的规则运算出来。报表中的序号问题常常被一些通用的web报表开发工具所忽略，有时常常会因为一个序号无法生成而被迫要写代码，使web报表开发的效率受到大大的限制。凡是总须研究，才会明白。下面就来看看中国式报表中的序号大体有哪些样式？* 固定序号：即在表格中固定好的序号值，不会随数据内容的多少而变化。这种最简单了，直接在表格上输入序号值就可以了。* 动态序号：即序号值是不固定的，是根据数据源中的数据而定的。比如：记录数为8条，则序号为从1

8、至 8。* 汉字序号：因为我们是中国人，序号常常用一，二，三，四等等来表示，这就需要必须能将数字序号转换成汉字序号。有时还会在序号的基础上加上括号（如：（1）或顿号（如：一、）等等。* 序号横向排列：序号有时会纵向排列，也常常会要求能横向排列。* 多列序号：分组报表是最常用的报表之一，由此就有根据每个分组字段都会有一个顺序号的问题。* 跨行的序号：分组报表往往会在其中有小计行，而如果这些小计行中不能要序号，就要求序号要跳过这些小计行。* 序号的延伸-序列值：有时报表中会有甲乙丙丁等序列值，这也可以看成是序号的一种吧。文字未免有些空洞，下面以几张图的形式来说明一下：在这个报表中，共有三列序号：总

9、序号，地区序号，产品序号，总序号是直接从1开始的序号值，地区序号是对于每个地区来说从1开始的序号值，产品序号是对于每个地区的每个产品来说是从1开始的序号值。这是一个典型的多列序号的报表。在这个报表中，红色字的序号是跨小计行的，即小计行中是没有序号的。这是典型的跨行的序号的报表。同时在此报表的第二行兰色字的序号是横向排列的。即有多少个地区就有多少个序号值。这是典型的动态序号和序号横向排列的报表。在这个报表中，有汉字序号：一，二等，也有(1)的序号形式。也有序号的嵌套及多个层次的问题。上述是我想到的web报表中的序号的形式，还希望大家补充。上面给出了在中国式报表中的序号的可能的形式，相当于web报

10、表开发的序号方面的需求。下面给出在e表中是如何设计并实现这些序号需求的。 在e表中解决上述复杂的序号问题还是靠提炼这些需求，总结出需要设置的报表公式，然后由用户根据自己的需要组合这些公式来实现的。当然，这些公式并不仅仅是为了解决序号的问题而特别设置的。上次从一个小小的序号开始了web报表开发技术专题，这回来讲一讲web报表开发工具的核心-数据集的变换。 1 为什么说web报表开发工具的核心是数据集的变换 数据集的变换，即报表的数据运算变换的能力。一个报表由两部分组成：数据及样式。数据一般都是从数据集而来的。样式无非就是一些静态的文字线条图片而已。对于一个web报表开发工具来说，实现样式是比较单

11、一的。而数据方面则大有门道。报表上的数据流程一般是先由SQL语句或一个程序来得到数据集，然后将数据集中的数据展现到含有静态样式的报表文件上，从而得到一个真正的报表。如何设计将变换后的数据集中的数据展现到含有静态样式的报表文件上，是每一个web报表开发工具首先必须考虑好的问题。这是web报表开发工具的主框架。它设计的好坏将直接影响web报表工具的开发效率。所以说：web报表开发工具的核心是数据集的变换。 2 数据集变换的相关问题有: A 多数据集时是否必须要设置之间的关联关系 一般来说在一个报表上常需要多个数据集给数，当一个报表上有多个数据集时是否必须要设置这多个数据集之间的关联关系，如需要设置

12、关联关系，哪么在web报表开发工具的内部程序就好做了，只需要根据关联关系来将多个子数据集中的数据展现到含有静态样式的报表文件上，这种方式不好的地方在于当报表内容和数据库物理表中的数据差异大时，往往需要写复杂的SQL语句或编程来准备数据集中的数据。而如果不需要设置这多个数据集之间的关联关系，则需要web报表开发工具内部协调好多数据集在报表上的展现。 B 数据集中的数据在报表上展开时能否变换(排序,过滤) 当一个数据集中的数据在报表上展开时是否可以再排序，设置条件过滤，以及一个数据集中的数据是否可以在报表上多次展开（当然是在不同的位置）。 C 数据集的运算函数.(带条件的sum等) 一般来说，肯定

13、需要提供全面的数据集的运算函数，如对某个字段sum，同时应可以加上条件。 D 报表计算的主流程是以数据集中的记录来循环计算还是以单元格上的公式来循环计算? 大凡写过报表开发工具的人都清楚，报表计算的过程是必须最先确定清楚的问题。这个也是评判一个web报表工具的能力的最重要的一点。以数据集中的记录来循环计算的好处是实现起来简单，报表计算的速度快；但坏处是牺牲了报表计算这一块的柔性化能力，将应对复杂报表的重担全压在生成数据集中的数据这一块了。以单元格上的公式来循环计算实现起来复杂，要处理好单元格的引用关系以及计算次序。但这种计算模式有利于应对复杂的中国式报表。 E 数据集中的数据在报表上如何放置?

14、 显然是希望数据集中的数据可以在报表上随心所欲地放置。但要达到此点需要web报表工具内部要做很多的协调工作。自然就希望将数据集中的数据限制在某些区域放置，实际上就是把报表分成明细区，分组区，标题区等等，但显然这样会大大限制web报表工具的开发能力。 F 数据集中的数据在报表上的展开次序。 一种做法是标识好哪个是主数据集（即最先展开）？哪个是子数据集（即跟随主数据集而展开）。这是条带状报表工具的常用做法。另一类做法是数据集中的数据随所在的单元格展开。而在单元格上设置主单元格，子单元格。这个是新一代web报表开发工具-润乾报表finereport( for java)和e表(for .net)的做

15、法。 3 现有报表工具的做法早期的报表工具在数据处理手段上相当单一，一般做法都是依赖于SQL语句或者存储过程，将需要的数据返回给报表系统，而报表系统能够做的仅仅是一些简单的四则运算，或通过固定函数取最大最小值等。近年来，一些报表开发工具在数据集的变换方面进行一些改良。比如数巨报表就加上了数据微引擎技术，以应对复杂的中国式报表。这种做法是在数据集上增加一层运算层，以提高数据的柔性化能力。其实质是对传统的条带状的报表工具的改良。象润乾报表finereport ( for java)以及e表(for .net)，是采用全新的数据处理模式。下面详细地介绍一下e表的报表运算原理。下面演示一个简单列表的扩

16、展过程，为了说明方便，去掉单元格的样式部分的同步：A 准备开始计算时如下图：B 计算了 ds1.get(semployeeid) 公式后。即将semployeeid的值算出来了，同时复制了多行。C 计算ds1.semployeename 公式后。D 以此类推，直到整个表都计算出来。下面演示一个分组报表的扩展过程，为了说明方便，去掉单元格的样式部分的同步：A 准备开始计算时，如下图：B 计算了 ds1.group(sarea,false) 公式后。如图所示将B3单元格的值计算出来了，同时在B3单元格中会保留一个当前组的指针，通过它能得到整个组的数据。如第一个是上海组，即ds1数据集中sarea=

17、上海的数据。（注意：一个组的数据是指一个二维表的数据，不光是一行的数据）同时也复制了多行。C 计算一个 ds1.get(id) 公式后如图所示，第一个 ds1.get(id) 就计算出来了，它的计算过程和简单数据列表的示例中的get函数的计算过程一样，只是指取sarea=上海 这一组的合同号来扩展，纵向扩展时左边的单元格拉大。D 以此类推，就得到了如下的报表。由上述可以看出，e表的报表运算主流程是以单元格上的公式来循环计算的，而不是以数据集中的记录来循环计算的。它采用多个单元格自由扩展而得到报表的思路，大大的增强了数据集的变换能力。使报表运算的柔性化能力达到了全新的高度。4 示例. 上述都是些

18、报表运算原理方面的设计问题。下面还是来看看两个示例吧！这是一个动静相结合的横向分片的报表示例，它要web报表开发工具具有支持分片能力，即一个报表无论多复杂，都可以分成一片片来分别处理，片数的增加报表的工作量不能呈指数增加。上述这个员工简历如果去掉下边的主要工作经历的话，就是一个标准的主从表了。但现在因为有两个从表同时循环展开。这就要求数据集在报表上展开时能够再进行数据的处理了。想详细看看这两个示例的朋友可以到北京方成公司的网站上在线试用或下载到本地试用。 5 一个梦想 比如拿到一个报表，先看看分哪几块，每一块的数据来源如何，块与块之间的联系。能象人脑的思维一样来设置报表文件，定义数据集，设置简

19、单的公式便可做出报表，只有这样的报表开发工具才能真正地把程序员解放出来。 6 小结 本专题主要讲web报表开发工具的数据运算原理，即数据集的变换。大凡原理一类东西，总难免大而空。但它又确实是一个web报表开发工具的核心所在。按个人的感觉，基于条带状的报表开发工具必将慢慢的退出中国市场。相关链接： 上一个专题讲了报表数据运算原理方面的取舍。一个报表是由行和列组合而成的，因而一定要从报表运算原理上达到行和列方向上计算模式是一样的才好。即行列对称。不能象条带状报表工具一样，在行方向上的计算能力大大强于列方向上的计算能力。最好让行与列方向上的计算是统一的，不要为列方向上设立特定的交叉表计算模式。实际上

20、交叉表即是列方向上的分组报表而已。一个行列对称的web报表工具就不用专门考虑如何做交叉表了，只要将分组报表做好，交叉表也就做好了。所以本专题将深入地探究一下报表的分组问题。 数据分组，就是相同值放在一起。比如按部门分组，就是将部门字段相同的记录放在一起。对于标准的分组比较简单，因为SQL语句中就提供GROUP命令。但现实中有时会有一些不规则分组的情况。下面列举一下：1 随机分成多个区间，比如年龄字段分成：0到15，15到30，30到40，40到50，50以上。如下图所示：当然这种分成多个区间的情况也可以通过写复杂的SQL语句来实现，考虑到SQL语句还要实现其它一些逻辑，所以这样的话会大大的加大

21、写SQL语句的工作量。实际上这种分多个区间的不规则分组还是有些规律的。所以最好还是象e表这样专门做一个函数来解决这种情况比较好。下面列出这个函数的说明： scope 函数说明： 根据完全划分进行分组 语法: datasetName.scope( selectExp, listExp, filterExp, eqExp, ascExp ) 参数说明： selectExp 取值表达式 ListExp 返回同valueExp数据类型相同的数组，要求其中元素从小到大排列 filterExp过滤表达式 eqExp 返回布尔值的表达式，缺省为false，表示与元素比较时不包含等于 ascExp 返回布尔值

22、的表达式，缺省为true，表示listExp返回的数组按从小到大排，否则为从大到小排 特别说明： ascExp为true(即listExp从小到大排列)时，eqExp为true时，与元素比较时采用=，eqExp为false时，采用=，eqExp为false时，采用 示例：ds1.scope(age,15,30,40,50)2 前面枚举几个固定值，最后来一个其它。比如产品分组为：CPU，内存，硬盘，其它。即其它类中的内容为除CPU，内存，硬盘这三个之外的所有内容。这也是中国式报表中的一种常见的不规则分组。3 地区分组时，象这样：北京，河北，山东，其中：青岛，江西。即在山东后面要加上一个青岛，其它

23、都是正常的分组。如下图所示：加一个青岛后可就比较麻烦了。往往会被迫要写程序来准备特定的数据集来实现。e表是如何在不用写代码的情况下解决此问题的呢？ e表内部有一个内建数据集的工具，有人往大了说它是一个小数据库。实际上只是一个简单的编辑表数据的工具而已。最早设计内建数据集的初衷是为了方便自己做e表的技术支持，因为有它后，用户只需要将一个出了错的报表文件发给我们，我们就可以在e表中打开并运行它。而不需要用户把数据库发给我们。后来发现内建数据集可以作数据词典用，正好可以相对简单（不用编程）地解决这个问题。即只要将 北京，河北，山东，其中：青岛，江西 作成一个数据词典，保存在内建数据集中即可解决此问题

24、。 在上一个专题中重点分析了数据集中的数据应如何在静态的报表上展开。在展开后，往往还应能在报表上找到哪些展开了的数据，以便进行再计算。这一阶段的报表运算中最典型的部分就是跨行组运算了。 跨行组运算，直观来理解就是跨行（指记录行）或跨组（指分组的组，一个数据集的所有记录合起来也可认为是一个组）的运算了。下面来详细说明一下： 跨行运算，即需要取到别的记录行的数据，典型例子是要取上一记录行的数据。比如：财务软件中常有的当前行的余额等于上一行的余额+本行的借方金额-本行的贷方金额。即累积运算。如下图所示：其中累积金额列应等于上一行的累积金额加上本行的合同金额。要实现此累积运算，只需要设置公式为：E3公

25、式 = D3+E3-1 /其中 E3-1 表示取E3扩展出的上一行的单元格的值,是单元格的扩展坐标中相对坐标的概念。 跨组运算，在多级分组的情况下，常常需要取得某一级下的当前组的单元格集合来进行计算。如计算排名，占比，上期比同期比等等。下图为上期比同期比的示例。想详细看看本文的报表示例的朋友可以到北京方成公司的网站上在线试用或下载到本地试用。总结：本专题主要讲了讲报表数据运算的后续部分，即不规则分组和跨行组运算。在下一专题中，将讲一些轻松的话题。下周一将发布web报表开发技术专题四：开发报表设计器的背后故事。前面的几个web报表开发技术专题都是一些纯技术性的东西，本专题就讲一些轻松一点的话题吧

26、！ 要论开发web报表系统最麻烦的是哪一部分，我会自然地想到应该是报表设计器了。因为报表设计器包含了很多交互性的操作。一般来说，交互性多的程序的bug会比较多，且一下子难于稳定下来。这是报表设计器麻烦的一个方面。另外还有一点是因为要做web报表工具，即b/s的报表工具。显然报表是在web页面上运行的。而报表设计器的界面需不需要也在web页面上运行呢？ 模式一：报表设计器用一个c/s程序实现。这种模式需要熟悉c/s程序的开发，报表设计器无法当作一个模块集成到用户的web程序中。给用户部署web报表系统时要麻烦一些，因为同时有b/s和c/s程序要部署。 模式二：报表设计器做成一个activeX控件

27、。这种模式和第一种模式差不多。ActiveX控件有第一次下载及控件注册等问题。 模式三：用js+dhtml+xml等网页技术实现纯web页面的报表设计器。这种模式的好处是都是b/s程序，集成方便。也可以将报表设计器当作一个模块集成到用户的web系统中。坏处是用js等纯网页技术实现复杂的报表设计器比较麻烦。而且由于js是解释运行的，速度比较慢。每种模式都有各自的优缺点。采用第一种或第二种模式的web报表系统有很多，而采用第三种模式的web报表系统就只有e表。报表设计器除了上述模式的选择问题外，还有是条带状还是类excel方式的选择问题。相比而言，条带状的报表设计器比类excel式的报表设计器的开

28、发要容易一些。e表采用的是类excel式的报表设计器。如下图所示： 远在六年以前，我便用js+dhtml做了一个纯页面的类excel报表设计器。哪时做这个的目的是因为想做纯页面的财务软件，而财务软件中必须要有报表。所以便不知天高地厚地踏了进来。现在想来哪简直是误入歧途。记得哪时做的纯页面的e表1.0给华表的作者唐爱平看的时候，把唐爱平吓了一跳，说：页面上竟然能做出这么复杂的东西？但我自己心里清楚，因为哪时已经把js+dhtml的功能用得差不多了，但还是有一些基本的问题未能突破。象大数据量的问题，还有一个就是合并单元格的计算问题。象合并单元格的计算可是花了我大量的心血，真是数易其稿，但还是不太理

29、想。到后来勉强做到e表2.x，就做不下去了。感觉是呈强拏之末，撞到墙了。当然也正是哪时的误入歧途，积累了相当多的经验。为做e表3.0的报表设计器铺平了道路。前几天，看见新闻说google升级了它的在线office软件spreadsheets，我便又到google上去看了看，发现还是不支持跨行合并单元格，即只能把同一行（同一个tr）的单元格合并，而无法支持把前三行的第一个单元格合并之类的跨行合并。即无法让td的rowSpan1，大家可能会想：google怎么会做得这么差，无法纵向合并单元格的电子表格软件怎么用啊？我心里很清楚，一旦支持跨行合并的话，其难度和工作量将增大了很多很多。为什么我还敢做纯

30、页面的报表设计器呢？因为当初的两大问题基本上被我解决了。一个是大数据量的问题，即当网格的行列数较多时的问题。因为e表3.0采用扩展单元格来得到报表的思路，所以在报表设计器中的行列数是不会特别大的，在真正的报表中的一行或一列单元格在报表设计器中时常常只有一个。也就是说，对于e表3.0的这种采用扩展单元格得到报表的web报表软件来说，在报表设计器中时报表的行列数是不会很多的，自然在报表设计器中就不会要求过多地考虑大数据量了。另一个问题就是合并单元格的问题。因为做e表1.0时吃尽了计算合并单元格的苦，所以长久以来一直在考虑如何解决此问题。终于在IE中偶得一个方法可以快速算出。真是又快又无bug。想当

31、初，我花了多少时间，却还是有bug，而且行列数一多的话，速度就奇慢。这两个关键问题解决了，余下的就好办了，再加上报表设计器中的表单界面用eform自定义web表单工具来设计，真是又快又方便。值得一提还有一个问题，因为要在网格（即html的table元素）上能输入，一般都是弄一个编辑框，点到哪个td就将编辑框移到哪个td上来实现输入。因为输汉字时，按第一个字母时就会发生onkeydown事件。所以就让这个移动的编辑框一直显示着，以免输汉字时会丢失第一个字母。当然google的spreadsheets会存在这样的问题，即移动的编辑框由隐藏切换到显示时，而此时是输汉字的话会丢失第一个字母。上面说的是

32、纯页面的类excel的报表编辑器的设计，纯页面的条带状的报表设计器我也做过，把它定位为完成web套打功能用，含在eprint产品中，如下图所示：想要试用这两个纯页面技术实现的报表设计器的朋友请到北京方成公司的网站上去下载。总结：本专题主要讲报表设计器的设计，但因本人经验所限，只讲了纯页面的报表设计器的设计过程。自从n年前Excel击败Lotus，独霸电子表格软件市场以来。所有的表格类软件都不能不充分考虑Excel，寻找Excel照顾不到的功能点。所有的表格类软件都要被迫考虑和Excel兼容，能够导入导出Excel文件。实际结果就是，只要能和表格沾上边的软件无一不是在Excel的阴影下艰难度日。

33、国内的web报表工具市场就更是如此，能不能很好地导入导出Excel文件，成了web报表工具软件的杀手锏。 总之，能不能不失真地导入导出Excel文件，是决定web报表工具软件成败的大事。是大意不得的。实现导入导出Excel文件功能，大体有以下几类做法：1 只导出数据，不导出样式2 调用Excel软件中的com组件来导出3 用纯c#程序在二进制层面上读写excel文件第一种做法最简单，但功能最弱，基本上无法满足用户的要求。无法将样式导出是根本不会被用户接受的。第二种做法，我感觉是国内的.net平台上用得最多的一种。其原理就是利用MS Excel软件里的一组com组件来直接控制Excel文件，所以

34、，这种做法是很依赖于Excel软件的。采用此法感觉也象正中微软的圈套。在.net程序（如c#）中，以这种做法来实现导入导出Excel文件，有以下的弱点： A 要求安装MS Excel软件。 B 要求安装MS Excel软件的某些版本，或要求Excel软件的版本的统一性。 C MS Excel的com组件数量众多，内存等资源消耗太大。 D 因为MS Excel是设计成一个有界面的电子表格软件，因而当在后台运行时也会因此而慢很多。 E 因为.NET程序是通过COM组件的方式调用Excel，而.NET程序是托管的代码，它调用非托管的COM组件时（对于调用.NET的托管程序）会增加一些额外的开销。 F

35、 如果是利用服务器端的Excel软件的话，则会有无法彻底关掉服务器端的Excel进程的问题。我曾在博客园上看到很多用奇招杀掉服务器端的Excel进程的文章，但给我的感觉应是没能很好地彻底解决这个问题，也正因为此，才使我下决心不用这种方法来解决e表中的导入导出Excel文件问题。第三种做法，这种做法是不依赖Excel软件，即客户端和服务器端都不用安装Excel软件，直接用.NET程序（比如c#的程序）来读写Excel文件，即先将Excel文件以一个二进制文件流的方式读入到内存，然后根据Excel文件格式的标准来逐字节的分析。这种方法的好处是避免了第二种方法的弱点，对于Excel软件的依赖极小。但

36、是，因为Excel文件的结构复杂，要用代码从头开始，逐字节地分析Excel文件，其工作量是非常大的。不象java平台，有一个通用且开源的POI包可以直接用来解决此问题。在.NET平台上，除了国外有一些商业化的DLL来解决此问题之外，国内好象见不着此类东西。我也试用过一些国外的，发现大多会有汉字问题。 后来想想，对于导入导出Excel功能，大家大多是在报表工具（如水晶报表）中使用，或者是用第二种做法（即调用Excel中的COM组件）。又因为第三种做法工作量太大，所以大家就都避开它了。这就是当今的国情了。可是e表是没法避开它的。怎么办？只有再次象做纯页面的报表设计器哪样硬着头皮上了。 要采用第三种

37、做法，首先要找到Excel文件的格式说明文档，还是要感谢互联网的方便，很快就找来了excelfileformat.pdf 文件（为方便大家，点这里可以下载此文件）。下面给大家看看这个文件的开头，如图所示：当初找到这个文件我可高兴了，有了它，至少是可以干了。再一看，200多页，把它变成程序可真够呛。多看几篇后，发现格式都差不多，都类似下图：无非就是介绍每个字节的意义。终于硬着头皮将这些字节的意义都对象化了，即根据一个Excel文件的二进制流，根据这个文档，得到一个Excel文件的操作类库。全部是用纯C#语句写的，生成的ebExcel.dll文件一看，也不大，才200多K。可源码挺多的，有近200

38、个.cs的文件。如下图所示：这个ebexcel.dll完成的功能就是提供一个强大而全面的操作Excel文件的类库，使用它可以在完全不依赖Excel软件的情况下读写各个版本的Excel文件，可以读写Excel文件的数据，公式，边框，样式，图片等等。此方法占有内存小，速度快，集成方便，功能定位明确，不光只用于web报表工具中，也可以很方便地把它用于各种需要读写Excel文件的场合，比如，需要从大量的Excel文件中自动提取数据保存到数据库的物理表中。e表有了ebexcel.dll，就可以很简单的实现不失真地导入Excel文件，即将Excel文件转换成e表格式的报表文件。也可以将报表运算结果导出为E

39、xcel文件，最重要的是在无须客户端或服务器端安装Excel软件的前提下。要使用读写Excel文件功能，非常简单，只需要将ebexcel.dll文件复制到bin目录即可。ebexcel.dll含在北京方成公司网站的e表试用版下载包中。想到还在为此问题而头痛的同胞们，也想过将ebExcel.dll免费开源给大家使用，但考虑到周方勇（网名：长江支流）免费开源的遭遇，只好等等再说吧！自从电脑被发明以来，将电脑中的内容打印出来是自然而然的需求。进入互联网时代后便更是如此。但要想完美地实现Web打印功能却并非易事，甚至于根本都不可能彻底地解决好这个问题。 记得很早以前田荣举（注：田荣举现任金蝶集团高级副

40、总裁兼任首席技术官）和我私下聊过：“打印功能要占到整个系统开发量的两成”。打印功能是一个系统开发的重要组成部分。中国人历来好面子，往往要求有漂亮的打印，以显露科技之高深。打印功能对于web报表工具来说就更是不可或缺的了。因为打印功能的重要性，所以进入web开发后，很快就开始关注web打印功能的开发了，web打印有下面的相关问题需要考虑清楚：1 在客户端还是服务器端打印？考虑到数据传递到客户端的速度问题，在服务器端做大数据量的打印还是不错的选择。但在后台打印必竟很不方便，所以主要还是要在客户端打印，即利用客户端的打印机打印。2 是导出为PDF或EXCEL文件后打印还是直接打印？将要打印的内容生成

41、为PDF或EXCEL文件后再打印，这也是一种方式，这种方式实际上也就几乎不需要专门考虑打印功能的开发了，开发工作量少。但其缺点也很明显：需要客户端安装打开PDF的软件（或EXCEL软件），需要在另一个软件中打印，步骤多，无法实现点击后直接打印，这种打印模式也无法实现某个单据是否打印了要当作一个标志保存起来的场合。3 是利用IE的打印还是自己实现打印？如果打印功能全部由自己实现，因为要处理数据，样式，位置，图片等的打印，自然程序量小不了，往往会使第一次的下载量很大。而且往打印控件中传递要打印的数据的过程会比较复杂而且慢。4 第一次打印时需不需要下载ActiveX控件？如果不需要，则无法用java

42、script脚本程序控制客户端的打印机，无法自定义纸张，无法不弹出打印对话框就直接打印。也就是说，最终用户在每次打印时都要手工选择好打印参数（如打印方向，纸张大小等），这样显然会使最终用户的操作比较麻烦。最开始我是设想直接用javascript脚本来计算分页，直接利用IE中的打印机制来解决打印问题。后来随着IE的版本升级，安全机制不断完善。在不下载ActiveX插件的情况下，IE的安全机制是不可能让你用javascript脚本来全面控制客户端的打印机的。试想如果这样的话就有可能浏览网上的某个网页时，你连接的打印机就自动开始打印东西了。也就是说，要想弄好Web打印，必须要在客户端下载插件。在中国

43、流氓插件泛滥的情况下，大家一看到插件都怕了。要不就要下载插件，要不打印就不太方便。这成了web打印的死结。且觉得一样子无法解开，真是尴尬的Web打印。既然最佳的方式是无解的，哪就退而求其次吧。用一个小的轻量级的activeX控件来控制客户端的打印机吧，这样第一次下载这个activeX控件是也不会很慢。记得以前在卖web打印控件时，有一用户将scriptx的网站告诉我，说要能实现这样的功能就买。于是便开始研究起scriptx来。按照我以前用visual c+编程的经验，觉得大体就是用钩子函数来实现。结合IE的打印模版技术，终于基本上达到了。用visual c+的ATL（为了减少字节而没有用MFC

44、）做了一个webprint.dll，这个webprint.dll压缩成cab文件后只有75K，和一个网页的大小相当。这样在第一次下载时便不会太慢了。因为真正的打印机制还是调用IE内部的，并没有在webprint.dll里面实现具体的打印功能，所以就不需要将要打印的内容传递到webprint.dll中，这是区别于其它用activex控件实现web打印的重要一点。如果靠activex控件来实现全部的打印功能的话，就必然要求要将打印的内容传递到activex控件中，这个传递的过程会比较麻烦而且速度也慢。Webprint.dll只完成向IE的内部实现的打印功能模块传递打印的基本参数（如：页面大小，页边

45、距，打印方向，直接打印），网页上显示什么内容就打印什么内容，没有向webprint.dll传递打印内容的过程。如下图所示的打印预览界面图:实际上，打印的需求很简单，无非就是：分页，页眉页脚，页边距，打印方向，自定义纸张，直接打印，弹出打印对话框再打印，预览，放缩打印，成批打印，套打等功能，打印的需求很固定，明确而且通用。将一个多页的报表一页页地打印出来这样一个简单的需求，在网页上却相当麻烦，我也是在不久前才将它在e表中算是比较理想的实现了，即可以象cs程序一样，点一下按钮，就将多页的报表一页页地打印出来。这其中要考虑到在互联网上从服务器端向客户端传递大量数据时的分页处理，以及打印了一页数据再传递另一页数据的问题。因为如将要打印的多页内容一次从服务器端全部发送到客户端的话，在当今互联网的条件下很可能会因速度慢而受不了。只能每次从服务器端发送一页数据到客户端，打印，然后再发送下一页数据到客户端，再打印，如此下去直至打