Chrome正在与NPAPI明确打破兼容性，而IE打破了ActiveX Applet的未来是黑暗的。目前，我们积极为客户组织使用安全applet，使用户只需点击一下按钮就可以将一大堆文件从文件系统上传到我们的服务器。该applet可以完全访问任何已配置的驱动器，包括网络驱动器。
随着applet即将死亡，如果我们找不到替代方案，这个功能将会丢失。我已经尝试过探索不同的解决方案，包括chrome FileSystem API，但目前只适用于Chrome（http://caniuse.com/#feat=filesystem）并且访问受限。
是否有人知道继续支持备受赞赏的功能的替代方案？不幸的是，我们有义务支持所有浏览器到IE8。
答案 0 :(得分：0)
我写了一篇关于此here的帖子。
Google Chrome是第一个宣布他们不再支持NPAPI的人，他们也是第一个提供新架构以便重写代码以便在浏览器上工作的人。您可以查看Native Messaging，它“可以使用与其他消息传递API类似的API与本机应用程序交换消息”。问题是这种方法仅适用于Chrome，不能适应其他浏览器。
更有用的方法是FireBreath，后NPAPI世界中的浏览器插件。从项目的一个伙伴处查看以下单词：
“FireBreath 2将允许您编写一个在NPAPI，ActiveX或Native Messaging中工作的插件;它已接近准备进入测试阶段。它没有任何真正的绘图支持，但可以适用于您描述的内容。安装过程有点痛苦，但它确实有效。本机消息传递组件使用的FireWyrm协议可以与允许传递文本数据的任何连接一起使用;应该可以在firefox上使用js-ctypes，或者以某种方式使用WEB-RTC甚至CORS AJAX。目前我们唯一需要解决的问题是Chrome，但我们采用的方式对其他技术来说非常便携。“
答案 1 :(得分：0)
根据Uly Marins提供的答案，我研究了建议的选项。不幸的是，这些选项对我们的应用程序来说是不可行的，因为我们的用户的市长没有足够的权限来安装第三方插件。此外，API仍处于测试阶段，在稳定的生产环境中无法发挥作用。
我们想要解决的主要问题是从访问过的文件夹中删除文件的可能性。似乎取消NPAPI支持的市长目标之一正是为了防止这种可能性。因此，我们需要将我们的目标降低到一个仍然可以为用户所接受的简单解决方案，并进行关于如何手动清除所选文件夹的额外培训（因为我们的大多数用户几乎都是计算机文盲并且需要访问网络文件夹）。
答案很长。所要求的解决方案已不再可行，必须由更简单的解决方案和其他培训来替代。