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