健康资讯 最近有位朋友在使用ie的时候，就出现了ie拒绝访问的情况，不知道这是为什么。其实，这种情况会遇到过，但是知道解决方法的人不多。今天，老毛桃跟大家分享下ie拒绝访问的原因和解决方法!
一般情况下，因为该网页的HTML源代码不能使用客户端脚本(如MicrosoftJScript或VisualBasic脚本)正确工作，所以才会出现ie拒绝访问的问题。原因有6个：电脑或网络上阻止了活动脚本、ActiveX控件或Java小程序、电脑系统防病毒软件配置为扫描您的“临时Internet文件”或“已下载的程序文件”文件夹、电脑的脚本引擎损坏或过时、电脑的Internet相关文件夹损坏、电脑视频卡驱动程序已损坏或者已过时、电脑DirectX组件损坏或过时。
解决方法如下：
1、清除一下IE浏览器的缓存，点IE上的工具，然后再选择最下面的Internet选项，再点Internet删除文件(记得勾上删除所有脱机内容)，确定后再重新打开IE浏览器试试，同时请确认您使用的是IE6.0及以上版本。
2、在网页上清除缓存，在网页上选择工具->Interner选项->删除Cookies和删除文件，然后再确定 。
3、点击IE浏览器中的“工具”，选择“internet选项”，进入“安全”页面，点击“自定义级别”，将您的安全设置设为“低” 。
4、最后，清空一下IE浏览器的cookies文件，在IE浏览器中设置“禁止自动脚本更新”，并不要选择“禁止运行ActiveX控件”，然后再尝试操作。
#Flash停用导致列车调度系统直接瘫痪##大连铁路昼夜攻关恢复Flash运行##flash#
关于Flash停用后的严重影响各个公司业务系统的解决办法[666]
方法一：通过AD域批量下发安装国内的新版Flush。
下载地址：Flash Player官方下载-Flash中国官网
根据自己电脑安装的操作系统选择最新的flush版本，下载即可[可爱]
安装：这里需要重点说明，如果是Windows10操作系统的话，安装之前务必卸载之前的版本，需要清理这两个目录，不然你安装完成后，依然还是无法通过IE浏览器加载出来插件[做鬼脸]。这两个目录分别是：↓
C:WindowsSysWOW64Macromed
C:WindowsSystem32MacromedFlash
关于卸载和清理这两个目录下的所有文件，可以编写脚本批量去执行，脚本如下仅供参考：
@echo off
taskkill /im FlashHelperService -f
del /F /S /Q C:WindowsSysWOW64Macromed*.*
del /F /S /Q C:WindowsSystem32MacromedFlash*.*
pause
如果进程被占用无法强制kill掉的话，那你的第一步就是需要写个简单的reboot脚本，批量执行，使所有电脑先进行重启，重启后再去执行上面的清理脚本，这样就可以成功[加油][加油]
第二步，执行完清理脚本后，使用AD域的软件分发策略，批量执行软件下发进行安装重启就可以啦[鼓掌][鼓掌]
方法二：通过修改系统的mms.cfg文件来解决Flush的问题。
ok，那如何来修改呢？看下面↓
第一步：找到mms.cfg文件，路径为：C:WindowsSystem32MacromedFlash
第二步：编辑mms.cfg，添加如下参数配置↓
EOLUninstallDisable=1
AutoUpdateDisable=1
EnableAllowList=1
AllowListURLPattern=网页链接
allowlisturlpartern=网页链接
allowlisturlpartern=网页链接
说明：allowlisturlpartern=加你们的业务地址和端口
方法三：卸载微软强制更新的flash补丁
注意：如果是win10系统的话，此方法不好意思[不看]无用。
如果您有更好的解决办法，可以在评论处分享哦，我们在头条相互探讨[灵光一闪][灵光一闪]
WPS的JSA为什么会缺少VBA的很多特性？后续会补上么？
1、WPS推出JSA，成为其默认脚本工具，让很多人喜出望外。毕竟站在JS基座上，获得全栈想象力是轻而易举的。就单凭跨平台，易于部署这条，就大有废除VBA之势。
更不用说，终于可以摆脱VBE呆板的语法风格了，从此用上现代IDE，B格一下子就上来了呀。还有，远离VB系，也终于可以在鄙视链中摘帽了，有一种让人高攀不起的得意洋洋。
2、可是当各大论坛社区修好JSA板块时，大家才发现，JSA都啥跟啥呀。官方文档一点都不像是与Office分庭抗礼的样子呀，怎么使用？整体技术框架的介绍，竟然没有介绍。找了半圈互联网，竟然没有官方交流平台。
好不容易，一通摸索下来，竟然不支持系统API的调用，JSA所谓API可不就是原对象的成员函数么。那个神秘的CreateObject竟然不再神奇，是真的哑火了。所以，结论就是，能靠的就完全只有JSA中的JS基座和WPS特性扩展部分了。
3、也就是说，跨平台的JSA，在本机上不能跨进程，甚至在跨二进制上似乎都缺胳膊少腿了。近在咫尺的资源，却只能望洋兴叹。有人说，JSA仍在初期，后续应该都会有吧。但是BtOfficer却不这么认为。
甭管VBA是不是脚本语言，VBA可以获得很高的本地权限，因此可以畅通无阻地执行本地代码。但JS却不同了，它原本就是为Web服务的，如果获得同样的本地权限，那将是非常危险的。IE被抛弃，并不仅仅因为它我行我素的格式规范，而更在于其ActiveX的风险敞口。
另外，如果JSA如果要想跨平台，就不得不放弃本地依赖。如果JSA一旦可以调用系统API，CreateObject可以跨进程通信，那能否跨平台就不是WPS能说了算的了。
所以说，要想跨平台，JSA一定也会和微软的Script Lab一样，立足于在线、轻量化，与本地化能力互为补充。届时，JSA也就是Script Lab的对标物而已。
欢迎关注BtOfficer，让我们一起学习成长！
什么是脚本语言？为何VBA不算脚本语言？
1、在前篇《居然还有不少人认为VB/VBA是脚本语言，偏见害人啊！》中普及VB的编译和解释双机制时，不少网友认为VBA仍然属于脚本语言范畴，也有网友认为VBA属于宏语言。那到底要如何才能正确定位VBA呢？本篇就继续讨论下吧。
2、首先，什么是脚本语言？如果，按网友VBA无法脱离Office环境而单独存在来看，其实所有开发语言都是脚本语言。比如：机器语言可以视为逻辑电路的脚本，汇编语言可以视为机器语言的脚本，各大编译型（二进制）语言可以视为编译器的脚本，各大解释型语言可以视为虚拟机（解释器）的脚本。很显然，这么划分是毫无意义的。
那有意义的定义依据是什么呢？自然是按源码到机器指令的生产方式来划分。无论是哪种开发语言，目的都是将人的需求转换为指令提交给机器执行。所以，编译也罢解释也好，脚本和非脚本，其实讲的都是这种生产路径，只不过承接人的需求模式（时间、地点、人物）不同而已。
因此学术界将『为了缩短传统的编写-编译-链接-运行（edit-compile-link-run）过程而创建的计算机编程语言』称之为脚本语言（Script languages）。而解释机制是缩短这一过程的有效途径，因此通常脚本语言都采用解释执行，实现源码编写到运行的一步到位。
解释器将编译和运行进行封装，为所有的脚本提供统一的运行机制，使用者不必每次都自己去编译链接成系统可识别的可执行文件，从而节约了脚本本身的使用成本。正因为如此，一般脚本适用于简单的自动化任务，最核心的目标是解决一些逻辑简单，但高度重复性的事务，从而将解放出的手放到更需要人的地方去。
3、为何VBA在脚本概念上却存在争议呢？一方面，不少脚本语言已经突破了简单自动化任务的需求，已经发展到能够写出复杂精巧的产品，非常逼近传统开发语言。比如VBS，借助COM，在IE时代以最低的门槛赋予了浏览器卓越的本地化能力。尽管随着IE的远去，在浏览器领域已显得老态，但64位的VBS依然在其他很多领域发挥着重要作用。如果说，VBA是脚本的话，那绝对是最复杂精巧的那一款。
另一方面，1995年VBA统一了Office的宏语言，而宏语言又是典型的脚本（重要的分支）。所以，很多人认为VBA就是宏语言，因此VBA就是脚本语言。而录制宏不仅符合简单自动化任务，VBA源码不能编译，也不能脱离Office而存在，就是最好的证明。
这是有一定道理的，VBA统一了Office宏语言，使用VBA的语法要素和解释机制来处理宏，表现得跟脚本并无二致。但这并不意味着VBA整个也就变成了宏语言，相反通常将VBA视为VB的子集，不仅仅是语法层面的高度相似，而是本身就从VB脱胎而来。相同的解释器、相同的内置函数实现、相同的底层封装，甚至相同的编译链接机制（VBA的编译链接机制，之前的文章已有介绍，不再赘述。但VBA不能脱离Office的说法，的确是站不住脚的），这是VBS所不具备的。这就是为什么只将VBS视为VB工具链的成员，而没有VB子集一说的原因。
如果有人仍然怀疑，继续问AuotoCAD等老牌软件的VBA也不能脱离宿主程序，那就该问问，VBA为何可以单独授权卖给诸如WPS一类的竞品而不怕泄漏的呢？要知道，直到目前为止，关于VB/VBA本身的实现原理，没有任何官方信息，但WinNT的源码却可以找得到。答案就是，VBA本身就是一款独立的开发工具，因为它本身就是定制版的VB。如果愿意付费，微软也愿意授权，各位开发者的产品，也能拥有VBA的开发环境。
VBA身上这种兼具宏（脚本）和VB（独立开发工具）的特点，才是让人迷惑的根本原因。
4、再回到『脚本』这个词，中文里这是一个日文汉词，英文里叫Script，原义是手稿，后来多用于指代戏剧表演或电影、电视摄制等所依据的底本。在计算机行业里，借过来指代某些直接可运行的文件。当然，这个文件不是可执行文件格式，而是脚本源码文件。
因此，无论是从学术定义上，还是概念释义上，脚本都是指那些源码文件无需任何处理，就可以直接参与生产的工具。而脚本使用的解释机制，也并非脚本特有。所以，将VBA视为脚本，是不利于正确认识和定位VBA应有作用的。
笔者再次强调，VBA是一款独立开发工具，Office的VBA是一款兼容了宏（脚本）的独立开发工具。Office中真正的脚本还是宏（非VBA兼容的方式），它们被保留了下来，依然可以使用。Excel中除了原始的宏，还有公式是真正的纯脚本，现在Excel的公式已经是图灵完备的了，也就是说只要各位愿意，公式也能写出非常复杂的产品。
[心]欢迎关注BtOfficer[心]（收藏、点赞、关注+转发）,更多精彩仍在继续哦（专栏文章将更系统，更全面，但需要阁下支持哦），有严肃的技术，也有轻松的唠嗑，期待你的加入！
初步聊下WPS的JSA与VBA
1、随着V8引擎的成功，JS一跃成为横跨前后端的开发工具，从此全栈成为技术员口中能力的象征。JS作为解释型语言的一员，与JAVA/Python/C#等既存在相似性，又存在明显的差异。
2、相似的地方在于：通过中间引擎实现跨平台，再通过引擎的优化，达到接近编译的性能。差异的地方在于：有些引擎转换为机器码后就执行了，而有的引擎是存储机器码后再执行，从而更具有编译特性。很显然，越来越多的引擎，尤其是新生的引擎，都是趋向于后者的。
3、而JS依赖的V8引擎就是后者，他的出现整合了以前的一些技术场景。比如IE浏览器的ActiveX的本地化能力。这也应该是微软云战略当前，放弃IE而拥抱Chromium的原因。
V8引擎通过内联缓存优化，大幅提高了JS的运行速度，虽然仍不及C那样的本地化编译语言，但绝对是动态语言里的佼佼者，这便催生了一系列富有想象力的场景。
4、所以，在2019版的WPS中，JS成为其默认脚本语言。而微软Office也在近年加入了对JS的内置支持。不过二者的目标却不一样，WPS是奔着将JS打造为替代VBA的脚本语言，而Office则更侧重于Office365云端功能的在线与轻量化，与VBA形成优劣互补。
5、WPS的前身，也即在DOS时代，作为应用程序，应该是非常成功的代表。但后继的失败，错就错在应用程序这一层上。有人将当年WPS的失败，归结为微软的险恶，认为当年格式兼容，甚至微软纵容Office盗版，摧毁了当年的WPS。
其实，底层的原因，与当年微软从CP/M的缝隙中突围成功的原因并无二致。建立在上层的逻辑，都抵不过底层根基的变动。当年基代尔还忙活于CP/M（8位处理器）成功的惯性之中，丝毫未察觉硬件体系的快速革新，结果败给了不能适应16位处理器。当年的DOS下的WPS也正是这样，还没来得及针对全新的Win系统窗口鼠标环境，就被Office捷足先登了。
Office具有系统支持的先天优势，在体验上很快将WPS按着摩擦了，为了挽留脆弱的市场份额，不得已与微软签订格式兼容条款。所以，这是一个各取所需，而非强权压迫的结果。
6、这一兼容，事实上微软获利更多，因为无论是体验，还是技术支持，都要全方位领先WPS，所以，大量的WPS客户以非常低的成本就转换为了Office的客户。
7、这一兼容，导致WPS到今天，都仍然处于追随者的地位。界面，使用习惯等等，尤其是二开领域，搞得WPS一度很被动。尽管WPS也有自己的二开接口，但除了WPS自己的专业人员，几乎没有市场。因为，门槛是专业的，得不到广大用户的响应。WPS不得不支持VBA，因为VBA是普通用户的选票。
但VBA是微软的，要想用就得给授权费。WPS本身的变现模式就很欠缺，这笔不菲的授权费又不能找用户收。所以，最终忍痛，只能单卖，所以WPS默认是没有VBA支持的，需要单独购买和安装VBA包，才能使用。当然，破解版总是不缺的。
8、结果是，转型后的WPS居然还在给Office打小工。作为民族软件的代表，岂能咽得下这口气啊。直到V8面世和成熟，终于让WPS看到了全新的希望。
时间有限，先写这么多啦。欢迎关注[心]BtOfficer[心]，办公自动化技术，咱畅聊！
