UEditor 的 ASP 版本在虚拟空间上传文件失败,提示“上传错误”或“上传失败,请重试”等,是因为其文件上传组件在创建目录时,没有网站目录外的访问权限。
例如上传文件的磁盘保存路径为:
D:\web\sitename\wwwroot\upload\20180523\123.jpg
百度编辑器的上传组件会依次判断以下目录是否存在,不存在则创建:
D:\
D:\web\
D:\web\sitename\
D:\web\sitename\wwwroot\
D:\web\sitename\wwwroot\upload\
D:\web\sitename\wwwroot\upload\20180523\
虚拟空间自动配置的网站根目录可能是:
D:\web\sitename\wwwroot\
所以,判断存在或创建以下目录没有问题:
D:\web\sitename\wwwroot\upload\
D:\web\sitename\wwwroot\upload\20180523\
但判断存在以下目录时会因为权限不足而失败:
D:\
D:\web\
D:\web\sitename\
解决方法是找到文件 asp/Uploader.Class.asp
找到 CheckOrCreatePath 这个 Function,替换为:
Private Function CheckOrCreatePath( ByVal path )
Set fs = Server.CreateObject("Scripting.FileSystemObject")
Dim parts
Dim root : root = Server.mappath("/") & "\"
parts = Split( Replace(path, root, ""), "\" )
path = root
For Each part in parts
path = path + part + "\"
If fs.FolderExists( path ) = False Then
fs.CreateFolder( path )
End If
Next
End Function
另外,如果服务端无法通过 Request.Form 来接收该值,把 <form /> 放到 <table /> 外面试试。
或者绑定 contentChange 事件来赋值(不推荐):
ue.addListener("contentChange", function() {
document.getElementsByName('xxxxxx')[0].value = ue.getContent();
});
此方法的缺点是,不是所有操作都能触发 contentChange 事件,比如剪切、上传图片等。
改进方法(推荐):在 form 提交之前赋值。
如果 .NET Core 项目发布到服务器上报以下错误:
HTTP Error 502.5 - Process Failure
Common causes of this issue:
The application process failed to start
The application process started but then stopped
The application process started but failed to listen on the configured port
Troubleshooting steps:
Check the system event log for error messages
Enable logging the application process' stdout messages
Attach a debugger to the application process and inspect
For more information visit: https://go.microsoft.com/fwlink/?LinkID=808681
在服务器上安装最新的 .NET Core Runtime 即可(Windows Server 选择 Hosting Bundle Installer)。
本文未完成,部分测试方法、条件或结果可能有误,请谨慎参考! :)
本文基于 MySQL 的 InnoDB BTREE 方法的索引进行测试。
以一张包含 2000 万条记录的表做实验:
CREATE TABLE `dt_read` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`time` datetime(0) NOT NULL,
`a_id` int(11) NOT NULL,
PRIMARY KEY (`id`) USING BTREE
);
这张表是用于记录文章点击量的,
`id` 为主键,int(11) 自增;
`time` 为非空 datetime,表示文章打开时间,测试数据是从 2017-03-11 至 2018-04-28;
`a_id` 为非空 int(11),表示文章 ID,在此表中不唯一,测试数据是从 1 至 260218。
体验“全表扫描”
首先来体验一下什么是全表扫描,执行下面语句:
SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' LIMIT 10
> 时间: 0.012s
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10
> 时间: 7.317s
表中数据是按主键从小到大排列的,当查询条件为 `time` < '2020-1-1' 时,能很快地从表的前端找到 10 条满足条件的数据,所以不再继续判断后面的记录,立刻返回结果,耗时 0.012 秒;但当条件改为 `time` < '2000-1-1' 时,同样逐条判断,直到最后一条也没有找到,这种情况就是所谓的“全表扫描”,耗时 7 秒。
索引对 ORDER BY 的 ASC 和 DESC 的影响
我们给 `time` 建一个索引,同样执行刚才需要全表扫描的语句:
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' LIMIT 10
> 时间: 0.012s
创建 `time` 的索引后,相当于生成了一张按 `time` 字段排列的新表,这时 MySQL 就能够很快地定位并找到符合条件的记录,避免了全表扫描。
试试按 `time` 倒序排:
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `time` DESC LIMIT 10
> 时间: 0.013s
结论:索引对 ORDER BY 的顺序(ASC)和倒序(DESC)都是有效的。
索引字段的次序对 WHERE 和 ORDER BY 的影响
删除所有索引,创建一个新的索引,字段依次为 `time`, `a_id`。
分别执行以下查询:
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10
> 时间: 0.013s
SELECT * FROM `dt_read` WHERE `a_id` < 0 AND `time` < '2000-1-1' LIMIT 10
> 时间: 0.013s
结论:MySQL 会自动优化 WHERE 条件的次序来匹配最合适的索引。
但在 ORDER BY 中却不是这么回事了:
SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10
> 时间: 0.013s
SELECT * FROM `dt_read` ORDER BY `a_id`, `time` LIMIT 10
> 时间: 14.066s
原因也很好理解,对两个字段进行排序,先后次序肯定会影响结果集,因此只能以 SQL 语句指定的字段次序来 ORDER BY,这样,按索引的字段次序进行 ORDER BY 查询无疑是更快的。
索引中的字段必须依次使用
保持上例创建的索引不变,即 `time`, `a_id`。
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' AND `a_id` < 0 LIMIT 10
> 时间: 0.013s
SELECT * FROM `dt_read` WHERE `a_id` < 0 LIMIT 10
> 时间: 6.438s
上句合理利用了索引的字段,而下句跳过了 `time`,直接 WHERE 了 `a_id`,这是不受该索引支持的。
我们可以想象一下这张由索引生成的虚拟表,其实就是一张普通的平面二维表格,按索引指定的字段次序进行了排序,所以全表中仅仅是索引指定的第一个字段是按大小排列的,第二个字段是在第一个字段值相同的区域内按大小排列,后同。所以,跳过索引指定的第一个字段直接对第二个字段进行检索,是无法应用该索引的。这个结论也同样也体现在 ORDER BY 语句中:
SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10
> 时间: 0.013s
SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10
> 时间: 29.566s
WHERE 和 ORDER BY 混合
保持上例创建的索引不变,即 `time`, `a_id`。
先来执行这两句:
SELECT * FROM `dt_read` ORDER BY `a_id` LIMIT 10
> 时间: 12.29s
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10
> 时间: 0.013s
仅仅 WHERE 了一个 `time`,对 ORDER BY `a_id` 的效率却有质的提升,是因为 WHERE 中的 `time` 和 ORDER BY 中的 `a_id` 一起找到了索引吗?答案是否定的。
我们把时间改大,让它能马上找到符合条件的数据:
SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10
> 时间: 22.34s
为什么这个语句就不走索引了呢?
其实,一个简单的 SELECT 查询语句,首先执行 WHERE,然后 ORDER BY,最后是 LIMIT。每一步都独自去找了索引,而非 WHERE 和 ORDER BY 混在一起去找索引。必须保证每一步是快的,最终才是快的。
当 `time` < '2000-1-1' 时,WHERE 用到了索引,所以很快,ORDER BY 却没有用到索引,但为什么也很快呢?因为 WHERE 的结果集非常小(示例中为 0 条)。
当 `time` < '2020-1-1' 时,WHERE 也用到了索引,但其结果集非常大(示例中为所有记录),再 ORDER BY `a_id` 就非常慢了,因为我们没有创建以 `a_id` 开头的索引。
现在把索引改成只有 `time` 一个字段。
SELECT * FROM `dt_read` WHERE `time` < '2020-1-1' ORDER BY `a_id` LIMIT 10
> 时间: 6.033s
因为索引里有 `
SELECT * FROM `dt_read` WHERE `time` < '2000-1-1' ORDER BY `a_id` LIMIT 10
> 时间: 0.013s
SELECT * FROM `dt_read` WHERE `a_id` < 0 ORDER BY `time` LIMIT 10
> 时间: 6.033s
第二句先 WHERE `a_id`,后 ORDER BY `time` 是不能匹配所建的索引的。
索引中的字段越多越好
分别在创建索引(`time`)和索引(`time`, `a_id`)的情况下执行下面语句:
本例使用 ORDER BY 而不是 WHERE 来测试是因为,在 WHERE 的多个条件下,如果符合前一条件的筛选结果集过小会导致判断第二条件时数据量不足,无法判断索引是否起作用。
SELECT * FROM `dt_read` ORDER BY `time` LIMIT 10
仅创建索引(`time`)的情况下:
> 时间: 0.013s
仅创建索引(`time`, `a_id`)的情况下:
> 时间: 0.013s
SELECT * FROM `dt_read` ORDER BY `time`, `a_id` LIMIT 10
仅创建索引(`time`)的情况下:
> 时间: 15.015s
仅创建索引(`time`, `a_id`)的情况下:
> 时间: 0.014s
可以看到,在索引字段依次使用的前提下,索引字段数不少于查询字段数才能避免全表扫描。
虽然索引中的字段越多越好,但必须依次使用,否则也是无效索引。
索引对 INSERT / UPDATE / DELETE 的效率影响
分别在创建索引(`time`)和索引(`time`, `a_id`)的情况下执行下面语句:
INSERT INTO `dt_read` (`time`, `a_id`) VALUES ('2018-4-28', 260218)
不建索引的情况下:
> 时间: 0.01s
仅创建索引(`time`)的情况下:
> 时间: 0.01s
同时创建索引(`time`)和索引(`time`, `a_id`)的情况下:
> 时间: 0.01s
UPDATE `dt_read` SET `time` = '2018-4-28' WHERE `id` = 20000000(注:存在该 id 值的记录)
不建索引的情况下:
> 时间: 0.01s
仅创建索引(`time`)的情况下:
> 时间: 0.01s
同时创建索引(`time`)和索引(`time`, `a_id`)的情况下:
> 时间: 0.01s
虽然在 INSERT / UPDATE / DELETE 时数据库会更新索引,但从实测数据来看,索引对其效率的影响可忽略不计。
一些误区
“in 语法效率很低”?
in 语法也是应用索引的,网传 in 会比一个一个 WHERE OR 要慢得多的说法是不靠谱的。in 主键和 in 索引同理。
另外:
对于字符串类型,LIKE '%abc%' 是不能应用索引的,但 LIKE 'abc%' 可以。更多关于字符串类型的索引,请查阅全文索引(FULLTEXT)。
索引的字段是可以指定长度的,类似字符串索引指定前面若干唯一字符就可以优化效率。
本文系个人实践总结,欢迎批评指正!
短信通判断了 30 天内提交错误验证码超过 5 次会有该提示,代码:
可按实际情况进行修改,涉及文件:
/source/plugin/smstong/smstong.class.php
/source/class/class_member.php
RHSA-2017:1842: kernel security, bug fix, and enhancement update (Important)
RHSA-2017:1615: kernel security and bug fix update (Important)
RHSA-2017:1372: kernel security and bug fix update (Moderate)
RHSA-2017:1308: kernel security, bug fix, and enhancement update (Important)
RHSA-2017:0933: kernel security, bug fix, and enhancement update (Important)
RHSA-2017:0892: kernel security and bug fix update (Important)
RHSA-2017:0817: kernel security, bug fix, and enhancement update (Moderate)
RHSA-2017:0307: kernel security and bug fix update (Moderate)
RHSA-2017:0036: kernel security and bug fix update (Important)
RHSA-2016:2766: kernel security and bug fix update (Important)
RHSA-2016:2105: kernel security update (Important)
RHSA-2016:2006: kernel security and bug fix update (Important)
RHSA-2016:1406: kernel security and bug fix update (Important)
RHSA-2016:0855: kernel security, bug fix, and enhancement update (Moderate)
RHSA-2016:0715: kernel security, bug fix, and enhancement update (Moderate)
修复命令:yum update kernel
修复后需要重新启动系统(阿里云技术回复:-devel 的组件涉及系统核心,必须重启才能生效),否则安骑士依然会提示漏洞待处理,漏洞依然存在。
扩展阅读:修改内核引导顺序(阿里云教程)
风险名称:系统共享配置检测
风险等级:中危
检测项说明:
检测注册表项HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\LSA\\RestrictAnonymous的值,该值控制是否允许远程操作注册表
检测项目:
远程操作注册表
建议值:
1
路径:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\RestrictAnonymous
建议:
建议禁止远程访问操作注册表,建议关闭
本文记录 Newtonsoft.Json 的用法,System.Text.Json 请参此文。
如何在序列化时间类型时以“年-月-日 时:分:秒”的格式输出?
默认时间类型将序列化为:2017-11-10T18:48:14.1685763+08:00,我们只要 new 一个 IsoDateTimeConverter 即可改变时间类型的输出格式:
var dtc = new IsoDateTimeConverter { DateTimeFormat = "yyyy-MM-dd HH:mm:ss" };
string b = JsonConvert.SerializeObject(DateTime.Now, dtc);
如何将对象序列化为可友好阅读的字符串?
序列化后的字符串默认是“紧凑型”的,如:{"a":1,"b":2}
可以将 Formatting 指定为 Indented 即可输出格式化后的字符串,例:
var obj = new { a = 1, b = 2 };
string a = JsonConvert.SerializeObject(obj, Formatting.Indented);
结果如下:
{
"a": 1,
"b": 2
}
枚举类型输出为字符串,而非索引值
[Newtonsoft.Json.JsonConverter(typeof(Newtonsoft.Json.Converters.StringEnumConverter))]
更多用法参:https://www.cnblogs.com/DomoYao/p/Json.html
不序列化属性
[Newtonsoft.Json.JsonIgnore]
当值为 null 时不序列化
[JsonProperty(NullValueHandling = NullValueHandling.Ignore)]
不序列化值为 null 的项
var jSetting = new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore };
JsonConvert.SerializeObject(obj, Formatting.Indented, jSetting);
获取
在 NuGet 中搜索 ZXing.Net
简单示例
var qr = new ZXing.QrCode.QRCodeWriter();
var matrix = qr.encode("http://xoyozo.net/", ZXing.BarcodeFormat.QR_CODE, 200, 200);
var writer = new ZXing.BarcodeWriter()
{
Format = ZXing.BarcodeFormat.QR_CODE
};
Bitmap bitmap = writer.Write(matrix);
扩展示例
string content = "http://xoyozo.net/";
var hints = new Dictionary<ZXing.EncodeHintType, object>();
hints.Add(ZXing.EncodeHintType.ERROR_CORRECTION, ZXing.QrCode.Internal.ErrorCorrectionLevel.H); // 纠错级别
hints.Add(ZXing.EncodeHintType.CHARACTER_SET, Encoding.Default.WebName); // 编码:gb2312
hints.Add(ZXing.EncodeHintType.MARGIN, 0); // 出血码元数(标准为 4,美观为 2)
var qr = new ZXing.QrCode.QRCodeWriter();
var matrix = qr.encode(content, ZXing.BarcodeFormat.QR_CODE, 200, 200, hints);
var writer = new ZXing.BarcodeWriter()
{
Format = ZXing.BarcodeFormat.QR_CODE,
Renderer = new ZXing.Rendering.BitmapRenderer
{
Foreground = Color.Black, // 前景色(默认黑色)
Background = Color.White, // 背景色(默认白色)
},
};
Bitmap bitmap = writer.Write(matrix);
将 Bitmap 写入到流
Stream stream = new MemoryStream();
bitmap.Save(stream, ImageFormat.Png);
将 Bitmap 保存到磁盘
string path = "D:\wwwroot\upload\abc.png";
bitmap.Save(path, ImageFormat.Png);
更多
对比 ThoughtWorks.QRCode 和 ZXing.Net
获取
在 NuGet 中搜索 ThoughtWorks.QRCode
简单示例
var qr = new ThoughtWorks.QRCode.Codec.QRCodeEncoder();
Bitmap bitmap = qr.Encode("http://xoyozo.net/");
扩展示例
string content = "http://xoyozo.net/";
var qr = new ThoughtWorks.QRCode.Codec.QRCodeEncoder
{
// 纠错级别,L (7%)、M (15%)、Q (25%)、H (30%)
QRCodeErrorCorrect = ThoughtWorks.QRCode.Codec.QRCodeEncoder.ERROR_CORRECTION.H,
// 码元尺寸(像素)
QRCodeScale = 4,
// 前景色(默认黑色)
QRCodeForegroundColor = Color.Black,
// 背景色(默认白色)
QRCodeBackgroundColor = Color.White,
};
// 根据内容确定 Mode,参:http://en.wikipedia.org/wiki/QR_code#Storage
if (Regex.IsMatch(content, @"^\d+$"))
{
qr.QRCodeEncodeMode = ThoughtWorks.QRCode.Codec.QRCodeEncoder.ENCODE_MODE.NUMERIC;
}
else if (Regex.IsMatch(content, @"^[0-9A-Z $%*+-./:]+$"))
{
qr.QRCodeEncodeMode = ThoughtWorks.QRCode.Codec.QRCodeEncoder.ENCODE_MODE.ALPHA_NUMERIC;
}
else
{
qr.QRCodeEncodeMode = ThoughtWorks.QRCode.Codec.QRCodeEncoder.ENCODE_MODE.BYTE;
}
Bitmap bitmap = qr.Encode(content, Encoding.Default); // 编码,简体中文系统默认为 gb2312
裁切掉多余的 1 像素
ThoughtWorks.QRCode 生成的四周没有留白的二维码图片,其右边和下边分别会多出 1 像素,使用以下方法来调整图片大小
// 创建一个新的图片(宽度和高度各缩小 1 像素)
Bitmap bitmap2 = new Bitmap(bitmap.Size.Width - 1, bitmap.Size.Height - 1);
// 以新图片来绘图
Graphics g2 = Graphics.FromImage(bitmap2);
// 新旧图片绘制到新图片中(左上角对齐)
g2.DrawImage(bitmap, 0, 0);
将 Bitmap 写入到流
Stream stream = new MemoryStream();
bitmap.Save(stream, ImageFormat.Png);
若已裁切 1 像素,请修改为 bitmap2
将 Bitmap 保存到磁盘
string path = "D:\wwwroot\upload\abc.png";
bitmap.Save(path, ImageFormat.Png);
若已裁切 1 像素,请修改为 bitmap2
更多
对比 ThoughtWorks.QRCode 和 ZXing.Net