企业官网建设流程全解析

简介：这份资源是 Microsoft Office InfoPath 2007 的官方中文技术资料文档，面向企业信息化人员、表单设计者以及希望了解电子表单解决方案的 Office 用户，帮助其掌握以表单驱动的业务流程构建方法。压缩包内仅含 1 个 doc 文件，整体约 849KB，属于轻量级技术说明材料，便于快速查阅与存档。文档系统介绍了 InfoPath 2007 的核心能力，包括通过 Outlook 2007 电子邮件收集表单、支持 Internet Explorer、Firefox 与 Safari 等多浏览器及移动设备填写、无需编写代码即可完成数据验证与格式化条件设置，以及利用预建模板组件和拖放界面简化表单设计。同时涵盖表单模板自动版本更新、Word 2007 与 Excel 2007 文档转换为 InfoPath 模板、表单数据导出为 PDF 或 XPS 记录等实用功能，并涉及与 SharePoint Server 2007 工作流、Visual Studio 2005 及 XML 标准的集成方式。目前已有 129 人学习，适合需要评估或部署企业级电子表单方案的技术人员参考。

1. 从一份 2006 年的 InfoPath 2007 数据表说起：它到底能解决什么

如果你手里正躺着一份Microsoft InfoPath 2007 Datasheet_CN_Final.doc，别急着把它当成一份过时的产品宣传页删掉。这份文档是微软在 2006 年前后随 Office 2007 预览版一起放出的官方数据表，全文围绕一个核心命题展开：企业如何用电子表单把纸质流程搬到线上，并且让收集到的数据第一次就是对的。它讲的不是某个孤立功能，而是一整套「表单设计—数据验证—多端部署—版本管理」的闭环思路。放到今天看，这套思路依然活跃在泛微 e9 表单默认值、动态表单配置、表单校验规则这些热搜词背后——只不过载体从 InfoPath 换成了 Web 表单引擎。这份数据表的价值在于，它用最精简的篇幅把 InfoPath 2007 的定位、新功能、部署选项和集成能力讲清楚了，适合三类人：正在维护老 InfoPath 表单的运维、需要理解微软表单技术演进脉络的开发者、以及想从老方案里抄作业做现代表单设计的产品经理。它不能帮你直接建出一个能跑的表单，但能让你在选型和排错时少走弯路。

2. InfoPath 2007 的核心机制：表单模板、数据连接与 Forms Services 怎么配合

2.1 表单模板不是普通文档，它是带 XML 架构的容器

InfoPath 2007 的表单模板文件扩展名是.xsn，本质上是一个 CAB 压缩包，里面装着 XML 架构定义（.xsd）、XSLT 转换文件（.xsl）、脚本文件以及视图定义。用户看到的表单界面只是 XSLT 渲染出来的一个视图，真正决定数据结构和校验规则的是背后的 XML 架构。这意味着你不能像改 Word 文档那样直接编辑.xsn里的 XML 文件——一旦架构和视图对不上，表单打开就会报「表单模板损坏」或者「无法加载视图」。常见做法是：先用 InfoPath Designer 打开模板，在「数据源」面板里检查字段层级，确认每个字段都绑定了正确的数据类型（文本、整数、日期、布尔等）。如果你拿到的是一个已经部署过的.xsn，想改字段名，必须同时在数据源和视图里改，漏掉任何一处都会导致提交失败。

数据验证在 InfoPath 2007 里是通过「数据验证规则」实现的，不需要写代码。比如你可以给一个「年龄」字段设两条规则：值必须大于 0，值必须小于 150。规则触发时机可以选「字段更改时」或「提交时」。这里有个容易翻车的地方：如果规则里引用了其他字段，而那个字段还没被填写，验证会直接跳过而不是报错。所以复杂校验最好用「提交时」统一触发，避免用户填到一半就被弹窗打断。

2.2 数据连接决定了表单能连什么、怎么连

InfoPath 2007 支持四种数据连接：提交到 SharePoint 库、提交到 Web 服务、通过电子邮件提交、提交到数据库（需要额外配置）。数据表里特别强调了「使用 Office Outlook 2007 电子邮件收集信息」这个新功能——它的原理是把表单模板作为 Outlook 邮件的一部分发出去，收件人填完后点「答复」，数据就以 XML 附件形式回到发件人邮箱。这个流程不需要服务器，适合小规模、跨组织的临时收集。但坑也很明显：Outlook 的安全设置可能会阻止脚本运行，而且邮件表单的版本管理完全靠人工，发出去 100 份，回来 30 份不同版本是常有的事。

如果你要用 Web 服务提交，数据表里提到支持「Web 服务、XML 架构、XSLT 以及许多其他业界的整合标准」。实际操作中，InfoPath 2007 调用 Web 服务是通过 SOAP 协议，你需要在数据连接向导里填入 WSDL 地址，然后手动做字段映射。映射时注意命名空间：InfoPath 生成的 XML 会带上自己的命名空间前缀，如果服务端对命名空间敏感，提交会返回 400 错误。解决办法是在「数据连接」属性里把「生成命名空间」选项关掉，或者让服务端做兼容处理。

2.3 Forms Services 是浏览器端运行的桥梁

Office InfoPath Forms Services 是 SharePoint Server 2007 的一个组件，它让.xsn模板能在浏览器里渲染，而不需要用户装 InfoPath 客户端。数据表里列出的支持浏览器包括 Internet Explorer、Mozilla Firefox 和 Apple Safari——这在 2006 年算是相当开放了。但浏览器渲染和客户端渲染有差异：客户端支持的一些控件（比如「重复表」里的嵌套控件）在浏览器里可能降级成纯文本输入框。设计检查器（Design Checker）就是用来提前发现这些兼容性问题的。你可以在 InfoPath Designer 里点「检查设计方案」，它会列出所有在浏览器里不支持的控件和规则，并给出替代建议。

部署到 Forms Services 的流程大致是：在 SharePoint 中央管理里上传.xsn模板 → 激活到某个网站集 → 在表单库中启用该模板 → 用户通过浏览器访问表单库填写。这里有个权限坑：如果模板里用了「用户角色」来控制字段可见性，而 SharePoint 的用户组和 InfoPath 角色没有正确映射，用户会看到空白表单或者直接报「拒绝访问」。常见做法是先在测试站点用最小权限账号走一遍完整流程，确认角色映射无误后再推到生产。

3. 从 Word/Excel 转 InfoPath 表单：转换步骤与数据完整性检查

3.1 转换前先做结构梳理，别直接导入

数据表里提到「将 Microsoft Office Word 2007 文件及 Excel 2007 工作表转换成 InfoPath 表单模板」是一个新功能。这个功能的入口在 InfoPath Designer 的「文件」→「导入」里，支持.docx、.xlsx和.xls格式。但直接导入的效果通常很差：Word 里的段落会被拆成一个个独立的文本字段，Excel 里的合并单元格会丢失结构。我一般会先做三件事：把 Word 里的表单区域改成表格，每个单元格对应一个字段；把 Excel 里的表头行和数据行分开，确保每列只有一个含义；删掉所有装饰性图片和页眉页脚。做完这些再导入，字段映射的准确率能提高一大截。

导入过程中，InfoPath 会弹出一个「导入向导」，让你选择「仅导入数据」还是「导入数据和布局」。如果你只需要数据结构，选前者，然后自己重新拖控件布局；如果你想要快速出原型，选后者，但要做好后期大改的准备。导入完成后，务必打开「数据源」面板检查字段类型：Word 里的日期文本很可能被识别成字符串，Excel 里的数字可能被识别成文本。手动改成正确的类型，否则后续的验证规则和提交逻辑都会出问题。

3.2 用 XSLT 做批量字段重命名和格式清洗

导入后的字段名通常是field1、field2这种无意义的名字，手动改几十个字段很痛苦。常见做法是导出模板里的myschema.xsd，用脚本批量替换字段名，再重新打包成.xsn。下面是一个用 Python 做批量重命名的示例：

import re import zipfile import shutil import os # 原始 .xsn 文件路径和输出路径 src_xsn = "form_template.xsn" dst_xsn = "form_template_renamed.xsn" work_dir = "xsn_work" # 解压 .xsn（本质是 CAB 压缩包，但 InfoPath 生成的可以用 zipfile 读取） with zipfile.ZipFile(src_xsn, 'r') as z: z.extractall(work_dir) # 读取 XSD 文件，做字段名映射 xsd_path = os.path.join(work_dir, "myschema.xsd") with open(xsd_path, 'r', encoding='utf-8') as f: xsd_content = f.read() # 定义旧字段名到新字段名的映射 rename_map = { "field1": "employee_name", "field2": "department", "field3": "submit_date" } for old_name, new_name in rename_map.items(): # 替换 element name 和 attribute name 中的旧字段名 xsd_content = re.sub( r'(name=")' + re.escape(old_name) + r'(")', r'\g<1>' + new_name + r'\g<2>', xsd_content ) with open(xsd_path, 'w', encoding='utf-8') as f: f.write(xsd_content) # 重新打包成 .xsn with zipfile.ZipFile(dst_xsn, 'w', zipfile.ZIP_DEFLATED) as z: for root, dirs, files in os.walk(work_dir): for file in files: full_path = os.path.join(root, file) arcname = os.path.relpath(full_path, work_dir) z.write(full_path, arcname) # 清理临时目录 shutil.rmtree(work_dir) print("重命名完成，输出文件：", dst_xsn)

这段脚本的逻辑是：先把.xsn当成 zip 包解压，找到myschema.xsd，用正则把旧字段名替换成新字段名，再重新打包。参数说明：rename_map里按你的实际字段对应关系填写；re.escape是为了防止字段名里有正则特殊字符；重新打包时用ZIP_DEFLATED保持压缩率。注意：InfoPath 的.xsn虽然本质是 CAB，但用 zipfile 读写通常没问题，如果遇到报错，可以改用cabextract和gcab命令行工具。改完字段名后，还要同步改视图里的绑定路径，否则表单打开会提示「找不到字段」。视图绑定在view1.xsl里，搜索旧字段名替换即可。

3.3 转换后的数据完整性检查清单

转换完成不等于能用。我一般会走一遍下面这个检查清单，确认没有遗漏：

这张表里的每一项我都踩过坑。最隐蔽的是「重复表结构」：导入 Excel 时，如果原表有合并单元格，InfoPath 会把合并区域识别成一个字段，导致重复表里所有行共享同一个值。解决办法是导入前先把合并单元格拆开，每个单元格填上重复的值。

4. 部署与版本管理：SharePoint 库、Outlook 邮件和网络文件夹的取舍

4.1 三种部署方式的适用边界

数据表里列了四种部署位置：InfoPath Forms Services、Windows SharePoint Services、Outlook 2007 电子邮件、共享网络文件夹。每种方式的版本管理能力完全不同。Forms Services 和 SharePoint 库支持自动更新模板——你上传新版本后，用户下次打开表单会自动拉取最新模板。Outlook 邮件表单和网络文件夹则没有自动更新机制，用户手里可能同时存在多个版本。我一般建议：正式业务流程走 Forms Services 或 SharePoint 库；临时收集走 Outlook 邮件；内部小范围测试走网络文件夹。

网络文件夹部署有个隐藏坑：如果文件夹路径里有中文或空格，部分客户端会无法加载模板。常见做法是把模板放在纯英文路径下，比如\\server\forms\leave_request.xsn，然后在邮件或通知里给用户一个.url快捷方式。另外，网络文件夹部署的表单，如果用户没有该文件夹的读权限，打开时会报「无法访问表单模板」，而不是明确的权限错误——这个报错信息很有迷惑性，排查时先确认共享权限。

4.2 版本管理的关键参数：模板版本号和最低版本要求

InfoPath 2007 的版本管理靠两个参数：模板版本号（Template Version）和最低版本要求（Minimum Version）。你可以在「表单选项」→「版本控制」里设置。模板版本号是一个四段式数字，比如1.0.0.0，每次发布新版本时递增。最低版本要求决定了用户至少需要哪个版本才能提交。如果用户手里的模板版本低于最低版本，提交时会被拒绝，并提示「表单模板已过期，请更新」。

这里有个容易翻车的地方：如果你把最低版本设得和当前版本一样，那么所有旧版本用户都会立刻无法提交，包括那些正在填一半的用户。我一般会把最低版本设成比当前版本低一个版本号，给用户一个缓冲期。另外，自动更新只在 Forms Services 和 SharePoint 库环境下生效，网络文件夹和邮件表单不会自动更新——你需要在通知里明确告诉用户去哪个路径下载新模板。

4.3 用 SharePoint 工作流串联表单提交后的审批

数据表里提到「使用 Office SharePoint Server 2007 的工作流管理工具来加强信息收集流程的效率」。实际操作中，你可以在 SharePoint 表单库上挂一个审批工作流，当用户提交 InfoPath 表单后，工作流自动把数据推给下一级审批人。配置步骤：在表单库设置里启用「三态工作流」或「审批工作流」→ 设置审批人 → 设置任务标题和说明 → 发布。审批人会在 Outlook 或 SharePoint 任务列表里收到待办，点开就能看到表单数据。

但要注意：工作流读取的是表单提交后生成的 XML 数据，如果表单里用了「重复表」且行数不固定，工作流里的字段引用需要做特殊处理。常见做法是在表单提交时，把重复表数据拼接成一个长文本字段，工作流只读这个文本字段，避免解析复杂 XML。这个拼接动作可以用 InfoPath 的「规则」实现：在提交按钮上挂一条规则，把重复表里的某个字段用分号连接起来，赋值给一个隐藏字段。

5. 避坑与排查：InfoPath 2007 表单最常见的五类翻车现场

5.1 表单打开报「无法加载视图」

现象：用户双击.xsn文件后，InfoPath 客户端打开但界面空白，底部状态栏显示「无法加载视图」。原因通常是视图文件（view1.xsl）里的字段绑定路径和myschema.xsd里的定义不一致，常见于手动改过字段名但漏改了视图。解决：用 InfoPath Designer 打开模板，在「视图」面板里逐个检查控件的数据绑定，找到显示为「绑定错误」的控件，重新选择正确字段。如果视图文件损坏严重，可以从备份的.xsn里提取view1.xsl覆盖回去。

5.2 提交到 SharePoint 库时报「拒绝访问」

现象：用户填完表单点提交，弹出「拒绝访问。您没有执行此操作的权限」。原因可能是表单库权限没配好，也可能是表单模板里的「提交」数据连接用了错误的身份验证方式。解决：先确认用户在表单库所在网站集有「参与讨论」权限；再检查数据连接属性里的「身份验证」设置，如果是「使用当前用户凭据」，确保 SharePoint 开启了 Kerberos 或 NTLM 认证。如果用的是「使用表单作者凭据」，则所有提交都以模板发布者身份执行，需要确保发布者有写入权限。

5.3 浏览器里重复表无法增删行

现象：在浏览器中打开表单，重复表的「插入项」按钮灰色不可点，或者点了没反应。原因是浏览器渲染模式对某些控件事件支持不完整。解决：在设计检查器里查看该重复表是否被标记为「浏览器兼容」。如果不兼容，把重复表换成「重复节」或者用「文本框+按钮+规则」模拟增删行。另外，Forms Services 对 JavaScript 的支持有限，如果重复表的增删逻辑用了自定义脚本，在浏览器里会直接失效。

5.4 邮件表单回复后数据丢失

现象：通过 Outlook 发出的 InfoPath 邮件表单，收件人填完点「答复」后，发件人收到的邮件里没有数据，或者数据是空的。原因通常是收件人用的 Outlook 版本不支持 InfoPath 邮件表单，或者收件人直接点了「转发」而不是「答复」。解决：在发送邮件表单前，先确认收件人使用 Outlook 2007 或更高版本；在邮件正文里明确写「请点答复，不要点转发」；如果收件人用 Web 版邮箱，建议改用 Forms Services 部署，让对方通过浏览器填写。

5.5 模板自动更新后旧数据打不开

现象：管理员在 SharePoint 库上传了新版本模板，用户打开之前保存的表单数据（.xml文件）时提示「表单模板版本不匹配」。原因是新模板的 XML 架构和旧数据不兼容，比如删了字段或改了字段类型。解决：在发布新模板前，先用「表单选项」→「版本控制」里的「兼容性检查」跑一遍，确认新架构能打开旧数据。如果必须改架构，建议保留旧字段但设为隐藏，新增字段单独处理，避免直接删除。另外，可以在表单加载时加一条规则：检测到旧版本数据时，自动填充默认值并提示用户「数据已升级，请检查后重新提交」。

6. 进阶技巧：用 Visual Studio 2005 给 InfoPath 表单加托管代码

数据表里提到「使用 Office InfoPath 2007 及 Microsoft Visual Studio 2005 开发高级的表单解决方案」，并强调可以用托管代码和 .NET Framework 实现。这是 InfoPath 2007 区别于纯无代码表单的核心能力。具体做法是：在 InfoPath Designer 里创建表单时选择「启用浏览器兼容」并勾选「使用托管代码」，然后点「编辑代码」——Visual Studio 2005 会打开一个项目，里面已经引用了Microsoft.Office.InfoPath程序集。你可以在FormEvents_Loading事件里写 C# 代码，动态修改字段默认值、调用外部 Web 服务、或者做复杂的数据校验。

我一般会在三个场景下用托管代码：一是表单加载时从数据库拉取用户信息自动填充；二是提交前做跨字段逻辑校验（比如「结束日期不能早于开始日期」）；三是调用第三方 Web 服务做实时验证（比如身份证号校验）。下面是一个在Loading事件里设置默认日期的例子：

using Microsoft.Office.InfoPath; using System; using System.Xml.XPath; public void FormEvents_Loading(object sender, LoadingEventArgs e) { // 获取当前表单的根节点 XPathNavigator root = this.MainDataSource.CreateNavigator(); // 找到 submit_date 字段并设置默认值为今天 XPathNavigator dateNode = root.SelectSingleNode( "/my:myFields/my:submit_date", this.NamespaceManager ); if (dateNode != null && string.IsNullOrEmpty(dateNode.Value)) { dateNode.SetValue(DateTime.Today.ToString("yyyy-MM-dd")); } // 根据当前用户角色控制字段可见性 XPathNavigator roleNode = root.SelectSingleNode( "/my:myFields/my:user_role", this.NamespaceManager ); if (roleNode != null && roleNode.Value == "guest") { // 访客角色隐藏审批意见字段 XPathNavigator commentNode = root.SelectSingleNode( "/my:myFields/my:approval_comment", this.NamespaceManager ); if (commentNode != null) { // 通过修改字段的 nil 属性来隐藏 commentNode.SetValue(""); } } }

这段代码的逻辑是：在表单加载时，先找到submit_date字段，如果为空就填入今天日期；再根据user_role字段的值判断是否隐藏审批意见。参数说明：NamespaceManager是 InfoPath 自动生成的命名空间管理器，用来解析带前缀的 XPath；SetValue会直接修改底层 XML 数据。注意：托管代码表单必须部署到 Forms Services 或通过完全信任方式安装，否则代码不会执行。另外，Visual Studio 2005 的项目里如果引用了外部程序集，需要把这些程序集一起打包进.xsn，否则部署后会报「找不到程序集」。

从那以后我每次改 InfoPath 模板，都强制走一遍「设计检查器 → 浏览器预览 → 最小权限账号提交」这三步，宁可多花十分钟，也不想到生产环境再吃后悔药。希望帮到你。

本文还有配套的精品资源，点击获取