“/”应用程序中的服务器错误。
未能加载文件或程序集“XXXXXX”或它的某一个依赖项。试图加载格式不正确的程序。
说明: 执行当前 Web 请求期间,出现未经处理的异常。请检查堆栈跟踪信息,以了解有关该错误以及代码中导致错误的出处的详细信息。
异常详细信息: System.BadImageFormatException: 未能加载文件或程序集“XXXXXX”或它的某一个依赖项。试图加载格式不正确的程序。
源错误:
执行当前 Web 请求期间生成了未经处理的异常。可以使用下面的异常堆栈跟踪信息确定有关异常原因和发生位置的信息。
程序集加载跟踪: 下列信息有助于确定程序集“XXXXXX”未能加载的原因。
警告: 程序集绑定日志记录被关闭。 要启用程序集绑定失败日志记录,请将注册表值 [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD)设置为 1。 注意: 会有一些与程序集绑定失败日志记录关联的性能损失。 要关闭此功能,请移除注册表值 [HKLM\Software\Microsoft\Fusion!EnableLog]。
当使用 Visual Studio 发布网站时,可能会遇到上述黄屏报错,原因之一是引用的 dll 路径不正确,可以用 Release 模式生成一次看看;原因之二是应用程序的位数与服务器的不匹配。
一般来说用“Any CPU”的方式没有问题,但遇到上述报错的百度网友都很轻松地通过修改 IIS 应用程序池的“启用 32 位应用程序”来解决这个问题,原因是他们的服务器是 64 位操作系统。当我这次在 32 位操作系统的服务器上遇到这个问题的时候真的是手足无措了,然后一阵乱配置,偶尔还能成功跑起来,于是仔细对比了发布到服务器上的文件,发现只有 bin 目录下的 dll 文件有区别,而导致这些区别的原因是我在发布时把“Release - Any CPU”换成了“Debug - Any CPU”,所以一时找不到更好的解决办法的朋友不妨也试试这个方法,只是会有一点点担心性能问题。有更好的解决方案的朋友也不要忘了联系我。
在 vs2015 以前的版本中,我们想要在停止调试后继续能够浏览网页,只要在项目右键属性 -> Web -> 调试器,把“启用编辑并继续”前的勾去掉就可以了。但是 vs2015 中没有了这个选项,这一度让我非常困惑。(vs2017 上又有了。2018.8.4 注)
百度无果,后来在还是在 Google 的帮助下找到了解决方案。
微软说,为了整合相关的功能,我们已经把这个选项移到了菜单栏 -> 工具 -> 选项 -> 调试 -> 常规,滚动到最底,但是我试了,没效果呀!
不过 stackoverflow 提供了一种很好的办法:我们先开始调试,在菜单栏中找到“停止调试”按钮所在的工具栏右下角的小三角,点击选择“添加或移除按钮”,“自定义”,“添加命令”,“调试”,“全部分离”,确定,你可以将“全部分离”下移或下移到你喜欢的位置,一般是“停止调试”旁边,当然你也可以干脆把“停止调试”删除掉。
好了,下次启动调试后,点击这个全部分离按钮就可以停止调试而不关闭 IIS Express 继续查看网页啦!
以某论坛配置 memcache 只允许本机 IP 访问 11211 端口为例:
一句一句执行:
service iptables status // 查询当前防火墙状态 iptables -A INPUT -s 127.0.0.1/24 -p tcp --dport 11211 -j ACCEPT // 允许本地回环 iptables -A INPUT -s X.X.X.X/24 -p tcp --dport 11211 -j ACCEPT // 允许本机内网IP iptables -A INPUT -s X.X.X.X/24 -p tcp --dport 11211 -j ACCEPT // 允许本机公网IP iptables -A INPUT -p tcp --dport 11211 -j DROP // 禁止其它IP service iptables status // 查询当前防火墙状态 service iptables save // 保存规则
今天突然发现 file_put_contents 写入文件的内容缺斤少两,字符串被截断,没有完整写入到文件中。检查了文件权限,yum 也 update 了,lnmp 也 restart 了,服务器也 reboot 了,经过各种百度无果。最终发现:原来是磁盘分区满了!!
有个案例:一张矩形照片头像要用圆形加边框的方式显示到页面上,并且当鼠标移到上面时,边框不动,图像会在边框内部渐变放大一些。
很容易地,我们想到这样的布局:
<style>
#div_face { width: 100px; height: 100px; border: 3px solid #CCC; border-radius: 50%; overflow: hidden; }
#div_face img { width: 100px; height: 100px; transition: all .5s ease-out; }
#div_face img:hover { transform: matrix(1.04,0,0,1.04,0,0); }
</style>
<div id="div_face">
<img src="/App_Themes/2016/images/temp.jpg" />
</div>
可是……渐变过程中竟然变回矩形了,动画结束又恢复正常。于是改进了一下:
<style>
#div_face { position: relative; width: 100px; height: 100px; border: 3px solid #CCC; border-radius: 50%; overflow: hidden; z-index: 1; }
#div_face img { width: 100px; height: 100px; transition: all .5s ease-out; z-index: 0; }
#div_face img:hover { transform: matrix(1.04,0,0,1.04,0,0); }
</style>
搞定!
编者按:本文作者 Nick Babich 在文中介绍了几种 “提高” 加载速度的方法。
当我们设计产品的时候,我们没有办法模拟不同的加载速度。因此如果用户等待太长的时间才能看到内容,并不是我们特意的安排。
网速不稳定,尤其是当我们加载图片或音乐时,时间会较长。在这种情况下,我们不得不考虑在这种间隙向用户展示什么内容才能让他们感觉不枯燥。
加载动图(Spinner)效果不佳
加载 Spinner 并不是暗示加载或思考的正确方式。默认加载图标(例如 iOS 的加载动画效果是从中心点辐射的灰色线条)通常具有消极的含义。它们应用于多种操作系统功能之中,包括设备启动、连接到网络或者加载数据。
人们讨厌只看到加载 Spinner,但是却看不多进度或时间。让用户盯着一个下载进度条或者旋转圈会让跳出率提高。
不确定的等待时间比已知的、有限的等待时间让人觉得更长。你应该给你的用户一个清晰地等待时间。
进度条可以告诉用户这个过程需要花费多长时间,但是一般不太正确。你可以通过一些方法隐藏过程中的延迟,例如你可以在开始的时候让速度显示地快一点,在结尾的时候,显示速度慢一点。进度条不应该中断,否则用户就会认为这个 App 卡住了。
后台操作
在后台操作中包含行为有两个优点——用户可见;在用户真正发出请求时就会加载完毕。当程序在后台运营时,给用户呈现一些其他的内容。一个很好的案例是在 Instagram 中加载图片。用户一旦选择想要分享的图片,就开始加载。
在后台加载图片的过程中,Instagram 邀请用户添加标题和标签,当用户准备按 “分享” 键时,加载过程就完成了,这时候就可以立刻分享图片了。
仿真内容和 Placeholder(占位符)
如果你无法缩短加载时间,那么你应该试图让用户在等待中更高兴一点。可以利用这个时间显示一些临时的信息。为了提高用户的参与度,可以使用仿真内容作为文本和图片。
几点小建议:
1、加载屏幕不应该太亮。不需要太吸引眼球。Facebook 的灰色 Placeholder 就是一个很好的例子。当加载内容时使用模板元素,让用户熟悉将要加载的内容的整体结构。
2、如果要加载图片,你可以在 placeholder 中使用加载图片的主色调。Medium 的图片加载效果比较好。首先加载一个小型的模糊图片,然后转化成一个清晰的大图片。
使用 placeholder 和仿真内容并没有加快加载过程,但是在用户眼中加载速度好像变快了。
分散用户的注意力
为了不让用户在等待时感到枯燥,可以适当分散他们的注意力。你可以使用一些有趣的、始料未及的东西吸引用户的注意力,为 App 加载赢得充足的时间。
动画片可以分散访客的注意力,让他们忽略加载时间。
结论
用户讨厌等待,如果你让用户觉得他们没有等待,那么他们就会喜欢你的 App。一定要让用户觉得 App 的加载时间比他预计的短。
在 ASP.NET Core 或 ASP.NET 5 中部署百度编辑器请跳转此文。
本文记录百度编辑器 ASP.NET 版的部署过程,对其它语言版本也有一定的参考价值。
【2020.02.21 重新整理】
下载
从 GitHub 下载最新发布版本:https://github.com/fex-team/ueditor/releases
按编码分有 gbk 和 utf8 两种版本,按服务端编程语言分有 asp、jsp、net、php 四种版本,按需下载。
目录介绍
以 v1.4.3.3 utf8-net 为例,
客户端部署
本例将上述所有目录和文件拷贝到网站目录 /libs/ueditor/ 下。
当然也可以引用 CDN 静态资源,但会遇到诸多跨域问题,不建议。
在内容编辑页面引入:
<script src="/libs/ueditor/ueditor.config.js"></script>
<script src="/libs/ueditor/ueditor.all.min.js"></script>
在内容显示页面引入:
<script src="/libs/ueditor/ueditor.parse.min.js"></script>
如需修改编辑器资源文件根路径,参 ueditor.config.js 文件内顶部文件。(一般不需要单独设置)
如果使用 CDN,那么在初始化 UE 实例的时候应配置 serverUrl 值(即 controller.ashx 所在路径)。
客户端配置
初始化 UE 实例:
var ue = UE.getEditor('tb_content', {
// serverUrl: '/libs/ueditor/net/controller.ashx', // 指定服务端接收文件路径
initialFrameWidth: '100%'
});
其它参数见官方文档,或 ueditor.config.js 文件。
服务端部署
net 目录是 ASP.NET 版的服务端程序,用来实现接收上传的文件等功能。
本例中在网站中的位置是 /libs/ueditor/net/。如果改动了位置,那么在初始化 UE 的时候也应该配置 serverUrl 值。
这是一个完整的 VS 项目,可以单独部署为一个网站。其中:
net/config.json 服务端配置文件
net/controller.ashx 文件上传入口
net/App_Code/CrawlerHandler.cs 远程抓图动作
net/App_Code/ListFileManager.cs 文件管理动作
net/App_Code/UploadHandler.cs 上传动作
该目录不需要转换为应用程序。
服务端配置
根据 config.json 中 *PathFormat 的默认配置,一般地,上传的图片会保存在 controller.ashx 文件所在目录(即本例中的 /libs/ueditor/)的 upload 目录中:
/libs/ueditor/upload/image/
原因是 UploadHandler.cs 中 Server.MapPath 的参数是由 *PathFormat 决定的。
以修改 config.json 中的 imagePathFormat 为例:
原值:"imagePathFormat": "upload/image/{yyyy}{mm}{dd}/{time}{rand:6}"
改为:"imagePathFormat": "/upload/ueditor/{yyyy}{mm}{dd}/{time}{rand:6}"
以“/”开始的路径在 Server.MapPath 时会定位到网站根目录。
此处不能以“~/”开始,因为最终在客户端显示的图片路径是 imageUrlPrefix + imagePathFormat,若其中包含符号“~”就无法正确显示。
在该配置文件中查找所有 PathFormat,按相同的规则修改。
说到客户端的图片路径,我们只要将
原值:"imageUrlPrefix": "/ueditor/net/"
改为:"imageUrlPrefix": ""
即可返回客户端正确的 URL。
当然也要同步修改 scrawlUrlPrefix、snapscreenUrlPrefix、catcherUrlPrefix、videoUrlPrefix、fileUrlPrefix。
特殊情况,在复制包含图片的网页内容的操作中,若图片地址带“?”等符号,会出现无法保存到磁盘的情况,需要修改以下代码:
打开 CrawlerHandler.cs 文件,找到
ServerUrl = PathFormatter.Format(Path.GetFileName(this.SourceUrl), Config.GetString("catcherPathFormat"));
替换成:
ServerUrl = PathFormatter.Format(Path.GetFileName(SourceUrl.Contains("?") ? SourceUrl.Substring(0, SourceUrl.IndexOf("?")) : SourceUrl), Config.GetString("catcherPathFormat"));
如果你将图片保存到第三方图库,那么 imageUrlPrefix 值设为相应的域名即可,如:
改为:"imageUrlPrefix": "//cdn.***.com"
然后在 UploadHandler.cs 文件(用于文件上传)中找到
File.WriteAllBytes(localPath, uploadFileBytes);
在其下方插入上传到第三方图库的代码,以阿里云 OSS 为例:
// 上传到 OSS
client.PutObject(bucketName, savePath.Substring(1), localPath);
在 CrawlerHandler.cs 文件(无程抓图上传)中找到
File.WriteAllBytes(savePath, bytes);
在其下方插入上传到第三方图库的代码,以阿里云 OSS 为例:
// 上传到 OSS
client.PutObject(bucketName, ServerUrl.Substring(1), savePath);
最后有还有两个以 UrlPrefix 结尾的参数名 imageManagerUrlPrefix 和 fileManagerUrlPrefix 分别是用来列出上传目录中的图片和文件的,
对应的操作是在编辑器上的“多图上传”功能的“在线管理”,和“附件”功能的“在线附件”。
最终列出的图片路径是由 imageManagerUrlPrefix + imageManagerListPath + 图片 URL 组成的,那么:
"imageManagerListPath": "/upload/ueditor/image",
"imageManagerUrlPrefix": "",
以及:
"fileManagerListPath": "/upload/ueditor/file",
"fileManagerUrlPrefix": "",
即可。
如果是上传到第三方图库的,且图库上的文件与本地副本是一致的,那么将 imageManagerUrlPrefix 和 fileManagerUrlPrefix 设置为图库域名,
服务端仍然以 imageManagerListPath 指定的路径来查找本地文件(非图库),但客户端显示图库的文件 URL。
因此,如果文件仅存放在图库上,本地没有副本的情况就无法使用该功能了。
综上,所有的 *UrlPrefix 应该设为一致。
另外记得配置不希望被远程抓图的域名,参数 catcherLocalDomain。
服务端授权
现在来判断一下只有登录用户才允许上传。
首先打开服务端的统一入口文件 controller.ashx,
继承类“IHttpHandler”改为“IHttpHandler, System.Web.SessionState.IRequiresSessionState”,即同时继承两个类,以便可使用 Session,
找到“switch”,其上插入:
if (用户未登录) { throw new System.Exception("请登录后再试"); }
即用户已登录或 action 为获取 config 才进入 switch。然后,
else
{
action = new NotAllowedHandler(context);
}
这里的 NotAllowedHandler 是参照 NotSupportedHandler 创建的,提示语 state 可以是“登录后才能进行此操作。”
上传目录权限设置
上传目录(即本例中的 /upload/ueditor/ 目录)应设置允许写入和禁止执行。
基本用法
设置内容:
ue.setContent("Hello world.");
获取内容:
var a = ue.getContent();
更多用法见官方文档:http://fex.baidu.com/ueditor/#api-common
其它事宜
配置上传附件的文件格式
找到文件:config.json,更改“上传文件配置”的 fileAllowFiles 项,
同时在 Web 服务器上允许这些格式的文件可访问权限。以 IIS 为例,在“MIME 类型”模块中添加扩展名。
遇到从客户端(......)中检测到有潜在危险的 Request.Form 值。请参考此文
另外,对于不支持上传 .webp 类型的图片的问题,可以作以下修改:
config.json 中搜索“".bmp"”,替换为“".bmp", ".webp"”
IIS 中选中对应网站或直接选中服务器名,打开“MIME 类型”,添加,文件扩展名为“.webp”,MIME 类型为“image/webp”
最后,为了在内容展示页面看到跟编辑器中相同的效果,请参照官方文档引用 uParse
若有插入代码,再引用:
<link href="/lib/ueditor/utf8-net/third-party/SyntaxHighlighter/shCoreDefault.css" rel="stylesheet" />
<script src="/lib/ueditor/utf8-net/third-party/SyntaxHighlighter/shCore.js"></script>
其它插件雷同。
若对编辑器的尺寸有要求,在初始化时设置即可:
var ue = UE.getEditor('tb_content', {
initialFrameWidth: '100%',
initialFrameHeight: 320
});
在 ASP.NET 网站开发过程中,若提交的表单中包含有 HTML 代码,为了安全,.NET 会自动阻止提交,并抛出异常:
从客户端(......)中检测到有潜在危险的 Request.Form 值。
以前的做法是
WebFrom:在 <%@ Page %> 中加入 ValidateRequest="false"
MVC:给 Action 加上属性 [ValidateInput(false)]
显然这会给网站带来极大的风险,不推荐!
以下做法可以完美解决这个问题。
客户端把内容进行 HTML 编码,如:
content = $("<div />").text(content).html();
服务端把内容进行 HTML 解码,如:
string title = HttpUtility.HtmlDecode(Request.Form["content"]);
今天终于把大量占用论坛服务器带宽的元凶找到了!
我们的论坛使用阿里云的 ECS+RDS+OSS+CDN 架构,最近发现 ECS 的带宽怎么都不够用了,也没有什么突发事件呀,再说附件都在 OSS 上。观察了云监控控制台,发现半夜里的流量也不减呀,白天更是触顶下不来,坛友们真是不辞辛劳为 PV 作贡献啊。
我对 CentOS 还是不够熟悉的,查阅了一些资料后,终于找到方向入手了。
重点肯定是日志文件了,但是面对每天几个 G 的大块头,还真是无法下手,一条一条看估计胡子都白花花了。
那么,首先安装 GoAccess 这个好东西(yum install goaccess)
然后进入网站日志目录,用 GoAccess 来分析一下(goaccess -f xxxxxx.log -a),具体用法参官网
选择日志格式,nginx 默认为 NCSA Combined Log Format,空格选中,回车确认
稍等片刻就可以看到主界面了,统计信息丰富多彩,统计结果一目了然,看截图,如果你分析的日志文件是当前正在使用中的,它还会每秒刷新主界面,让你看到实时统计
大致分为几块内容:
按 1 定位到“按天访问量”
按 2 定位到“最多次被请求的 URL”
按 3 定位到“最多次被请求的静态文件”
按 4 定位到“最多次被请求的 404”
按 5 定位到“最多次请求的用户 IP”
按 6 定位到“用户的操作系统”
按 7 定位到“用户的浏览器”
按 8 定位到“按小时的统计”
按以上数字键后,再按回车可以查看具体或更多的信息,按 s 可以更换排序,按 q 返回或退出
那么我先找 5 最多次请求的用户 IP,排前面的全部是从 60.191.127.4 到 60.191.127.26 的 IP,每个 IP 都是几 G 级的带宽占用。
负责任的,你必须保证这些 IP 不是政府或大企业的对公 IP,而且得拿这些 IP 直接去日志文件里搜到底请求了哪些 URL。经查证,它们只请求版块的帖子列表页,没有请求任何图片、脚本、样式等,还有,UserAgent 中没有带 Spider 之类的关键字,证明不是搜索引擎的蜘蛛,那么就可以果断认为它“不是人”
啥都不说了,找到 nginx 的 conf 配置文件,在 server 中添加 deny 60.191.127.0/24;
检查配置:nginx -t
使配置生效:nginx -s reload
呵呵,马上就能在阿里云监控里看到过山车式的折线了。
另外,备注下查看各IP的连接数的命令:
netstat -an|grep :80| awk '{print $5}'| cut -d':' -f1| sort |uniq -c