我正在构建一个允许用户通过网页打开word文档的应用程序。此Web应用程序将使用计算机上的本地字实例打开word文档。
我有两个有效的解决方案。
第二种架构就是我现在所关注的。它基于Web服务，通过Javascript / jquery调用接收机器名称。后来在web方法中我使用PsTools远程执行远程机器上的MS Word实例。
这两种架构都有效，但两者都有局限性。使用ActiveX我可以在IE上使用它，它还需要更改网络策略以允许ActiveX。使用PsTools，它工作得很好，但我无法获得Word.Exe的路径，我只能假设它始终位于\\machinename\C$\Program Files(x86)\....。
我们也可以将此应用程序公开，在这种情况下，我们的PsTools解决方案将不再适用。
我只是想知道是否还有其他更适合/跨浏览器的方式通过网络应用程序打开本地文字实例？
必须在远程位置修改文档，一个选项是让用户下载文档，然后修改它并将其上传到服务器，这是不可能的，因为我们要更换厚客户并希望保持用户体验相同
答案 0 :(得分：1)
当你说：＆＃34;我们也可以公开这个应用程序＆＃34;，你在谈论什么样的规模？只是来自团队的几个人，或者作为一个需要处理编辑冲突，事务，锁定，性能等的真实Web应用程序？即使是你提到的内部网解决方案，只要有2-3人开始编辑同一个文档，就会很头疼。
对于这种类型的文档共享，您基本上有两个选项：
如果您可以将有问题的文档转换为某种形式，那么这将是一个非常简单的问题。可能有一百种不同的服务提供嵌入式表单功能，具有出色的报告和数据库管理功能。如果需要Word格式的文档，那么您的应用程序只会将存储的数据转换为.doc / .docx文档，供用户随意下载。
无论您采用何种方向，都要尝试摆脱基于PsTools的当前设置。它就像一个rinkydink的纸牌屋，正如@ Matt-Burland所提到的那样，很快就会引发安全灾难。
答案 1 :(得分：1)
我正在构建一个允许用户打开单词的应用程序 通过网页记录文件。
如果是Intranet方案，那么您可以使用具有Office URI方案的应用程序协议来获取文档的链接，这些文档随后将在本地安装的客户端中打开。
Office URI架构如下所示：
<scheme-name>:<command-name>"|"<command-argument-descriptor> "|"<command-argument>
对于Word，具体来说，例如：
<a href='ms-word:ofe|u|https://example.com/example.docx'>Edit</a>
其中，ms-word:是方案，ofe命令代表 open-for-edit ，u是的命令描述符使用后面的URI ，最后使用文档本身的URI。还有其他命令，如ofv（ open-for-view ）和nft（ new-from-template ），以及其他命令-descriptors如s用于保存。
以下是完整的参考资料：https://msdn.microsoft.com/en-us/library/office/dn906146.aspx
安装Office客户端时，协议已在Windows中注册。
您可以在IIS服务器上轻松启用WebDAV。 WebDAV客户端内置于客户端的Windows。
您还可以使用属于SharePoint Foundation的FFWinPlugin Plug-in等组件，或者与Office客户端一起安装的OpenDocuments Control组件。
我们也可以将此应用程序公开
除非您的公司拥有或处理 OneDrive 或 Office.com 等服务，否则我会阻止您这样做。如其他答案所述，这很快就会变得棘手。此外，无论如何，在公众中执行专有客户并不是一个好主意。此外，即使是微软自己的解决方案也无法在浏览器中可靠地运行，并且只能与IE一起使用（甚至Edge也存在此问题），这会迫使特定浏览器向普通公众开放。不是个好主意。
但是，如果你真的需要，那么如果你可以使用一些围绕WebDAV构建的解决方案会更好。 Alfresco ECM（企业内容管理）是公开发行的一个例子，它使用类似于您的用例的WebDAV。
IT Hit 还有另外一个，现场演示在这里：http://www.ajaxbrowser.com。他们还有一个基本教程，介绍如何在与用例相同的行上设置自己的WebDAV服务器。您需要找到他们的文档。