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 提交之前赋值。

本文未完成，部分测试方法、条件或结果可能有误，请谨慎参考！ :)

本文基于 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）。

索引的字段是可以指定长度的，类似字符串索引指定前面若干唯一字符就可以优化效率。

本文系个人实践总结，欢迎批评指正！

在 Global.asax 的 Application_Start() 方法中添加以下代码，作用是在应用程序启动时预先访问一遍所有动态页面，办法虽土，但很有效。

本代码适合 Web Forms 项目，不适合 MVC 项目；修改代码中的 domain 值为真实的网站域名

代码整理中……

在 IIS 中设置应用程序池最长时效或永不过期，则效果更佳。

在应用程序池中选中网站对应的应用程序池，在右侧“操作”窗口中选择“正在回收...”

取消“固定间隔”框中的所有选项，确定。

实践证明，近 200 个动态页面一次性访问需要耗时近 10 分钟，发布后 10 分钟内无法正常浏览网站是同样是无法忍受的。因此更改方案为：

做一个 Winform 应用程序来定时访问这些页面，30 秒一个，一个半小时能完成一个循环，对正常浏览的影响非常小。

更新 .edmx 文件时若提示：

生成模型时出现意外错误。有关详细信息，请参阅输出窗口。异常消息:“StrongTypingException: 表“TableDetails”中列“IsPrimaryKey”的值为 DBNull。”。

可以通过以下方法来解决：

1，控制面板中打开“服务”（或执行命令 services.msc），重新启动“MySQL57”

2，在 MySQL 中执行：

use <<database name>>;
set global optimizer_switch='derived_merge=OFF';

如果提示“1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation”，请使用超级用户进行操作。

3，搞定，试试更新 .edmx 吧。

参考资料：https://stackoverflow.com/questions/33575109/mysql-entity-the-value-for-column-isprimarykey-in-table-tabledetails-is

获取

在 NuGet 中搜索 ThoughtWorks.QRCode

Demo

简单示例

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

更多

使用 ZXing.Net 生成二维码

对比 ThoughtWorks.QRCode 和 ZXing.Net

“/”应用程序中的服务器错误。

指定的参数已超出有效值的范围。
参数名: site

说明: 执行当前 Web 请求期间，出现未经处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。 

异常详细信息: System.ArgumentOutOfRangeException: 指定的参数已超出有效值的范围。
参数名: site

解决方法：安装 IIS

jquery.barrager.js 是一款优雅的网页弹幕插件，支持显示图片，文字以及超链接。支持速度、高度、颜色、数量等自定义。

使用方法参官方网站：http://yaseng.org/jquery.barrager.js/

jquery.barrager.min.js 会报错，改用 jquery.barrager.js（版本 1.1）

实战示例：https://xoyozo.net/Demo/DanMu

该示例重写了部分 CSS 样式。

注：info 属性支持 HTML，因此要自己过滤危险标签，建议仅保留 <img /> 标签

如果要显示在指定区域，可以使用 bottom 属性，例：

bottom: (Math.random() * (0.95 - 0.5) + 0.5) * $(window).height()

建议加 loading 锁，以适应网络不通畅的环境（ajax 时间超过定时间隔会导致请求到重复的数据）

跨域环境可以使用 JSONP 来实现，服务器端需设置 Access-Control-Allow-Origin 为 *。

经常会看到这样似错非错的提示：

当前上下文中不存在名称"__o"

The name '__o' does not exist in the current context

实际上，我没有定义任何名为 __o 的变量。

发生这种情况的原因可能是使用了类似如下的代码：

<% if(true) { %>
<%= 1 %>
<% } %>
<%= 2 %>

为了在设计界面的 <%= %> 代码块中提供智能感知，ASP.NET（VB 或 C#）会自动生成一个名为“__o”的临时变量，这在页面编译器看到第一个 <%= %> 块时就完成了。但是在这里，<%= %> 块在 if 中出现，所以当关闭 if 后再使用 <%= %> 时，变量超出了定义的范围。

if (true)
{
    object @__o;
    @__o = 1;
}
@__o = 2;

解决方法：在页面的早期添加一个虚表达式。例如：<%= "" %>。这将不会呈现任何内容，并且它将确保在任何潜在的 if（或其他范围界定）语句之前，在 Render 方法中将 __o 声明为顶级。

当然还有一种治标不治本的方法就是隐藏这些错误提示（这并不影响程序正常运行）：

点击错误列表面板左上角的过滤器按钮，CS0103，其中包含错误代码：当前上下文中不存在名称"__o"，这些错误将不再显示，您仍然可以有其他 IntelliSense 错误和警告。

在 IIS 中编辑网站绑定时，提示“至少一个其他网站正在使用同一 HTTPS 绑定，而此绑定用另一个证书配置。确实要重用此 HTTPS 绑定并将其他网站重新指定为使用新证书吗?”，那么所有网站都必须使用同一个域名证书吗？

否。只要在绑定 https 域名的时候勾选“需要服务器名称指示”就行了。

使用证书链检测工具检测结果证书链（Certificate chain）不完整怎么办？

这个问题我在两台相同版本 CentOS 和相同版本宝塔面板的 Linux 服务器上遇到过，一台证书链完整，一台证书链不完整。

使用宝塔自带的 SSL 证书导入的方式可能出现这种情况（个例），关闭之，并手动配置 nginx 的 conf 文件；而再有一台，手动配置不生效，宝塔自带 SSL 成功，因此请自行尝试。

我也在两台相同版本的 Windows Server 2012 R2 上（IIS 8.5）遇到过，一台证书链完整，一台证书链不完整。

解决思路：在命令提示符中键入 mmc，打开：文件 - 添加/添加管理单元，选择“证书”添加，选择“计算机帐户”，确定。展开“证书”

在“个人 - 证书”中可以看到我们导入的域名证书，查看它的颁发者，确保在“中间证书颁发机构 - 证书”（或“受信任的根证书颁发机构”）中能够找到，找到后继续找该证书的颁发者，一直找到根证书。一般会有多个中间证书，形成一个完整的证书链，如果证书有缺失，那么尝试重新导入域名证书，或向供应商索要中间证书。

有任何改动后，在命令提示符中执行 iisreset 来重启 IIS（IIS 管理器中的“重新启动”可能重启得不彻底），并且找到网站 - 绑定 - 删除 https 类型的绑定并重新添加，以使证书生效。

检测证书链完整后，继续摸索过程中发现，删除某中间证书，然后在 IIS 中重新绑定，会自动生成中间证书，难道是域名证书中已经包含了中间证书和根证书等完整的证书链，还是 Windows 会自动下载安装这些证书呢？

在开发支付宝支付/微信支付时回调 Url 无法接收数据。

可能是证书链不完整，建议用工具检测：GeoCerts™ SSL Checker，并用上述方法补全。

>> 遇到新问题将不断补充本文 <<

一、概述

    重定向常常和请求转发放在一起讨论（前者是两次不相关的请求，后者是一次请求服务器端转发），然而本文并不讨论两者的区别，而是HTTP 1.0规范和HTTP 1.1规范中关于重定向的区别，以及实际使用中的情况。

    重定向实际使用是一个响应码（301或302或303或307）和一个响应头location，当浏览器收到响应的时候check响应码是3xx，则会取出响应头中location对应的url（重定向中url的编码问题，请参看点击打开链接），然后将该url替换浏览器地址栏并发起另一次HTTP事务。

    关于301、302、303、307的区别，找不到好的文章，因此打算直撸HTTP 1.0规范和HTTP 1.1规范，结合一些实际的案例和tomcat实现，来说清楚这几个状态码的差异。

1. 百度https重定向

    如下图所示，原请求访问的是http://www.baidu.com，然后返回302和location=https://www.baidu.com，从http转到https。不过关于响应行中302状态码的描述存在争议，在下文中会详细讨论。

2. tomcat重定向源码

二、详细

    http 1.0规范中有2个重定向——301和302，在http 1.1规范中存在4个重定向——301、302、303和307，其中302是值得讨论讨论的。

1. http 1.0

301

    301状态码在HTTP 1.0和HTTP 1.1规范中均代表永久重定向，对于资源请求，原来的url和响应头中location的url而言，资源应该对应location中的url。对于post请求的重定向，还是需要用户确认之后才能重定向，并且应该以post方法发出重定向请求。

    关于post请求重定向用户确认的问题，实际上浏览器都没有实现；而且post请求的重定向应该发起post请求，这里浏览器也并不一定遵守，所以说HTTP规范的实现并未严格按照HTTP规范的语义。

    在301中资源对应的路径修改为location的url，在SEO中并未出现问题，但是在302中就出现了302劫持问题，请往下看。

302

    在http 1.0规范中，302表示临时重定向，location中的地址不应该被认为是资源路径，在后续的请求中应该继续使用原地址。

    规范：原请求是post，则不能自动进行重定向；原请求是get，可以自动重定向；

    实现：浏览器和服务器的实现并没有严格遵守HTTP中302的规范，服务器不加遵守的返回302，浏览器即便原请求是post也会自动重定向，导致规范和实现出现了二义性，由此衍生了一些问题，譬如302劫持，因此在HTTP 1.1中将302的规范细化成了303和307，希望以此来消除二义性。

    补充：302劫持——A站通过重定向到B站的资源xxoo，A站实际上什么都没做但是有一个比较友好的域名，web资源xxoo存在B站并由B站提供，但是B站的域名不那么友好，因此对搜索引擎而言，可能会保存A站的地址对应xxoo资源而不是B站，这就意味着B站出了资源版权、带宽、服务器的钱，但是用户通过搜索引擎搜索xxoo资源的时候出来的是A站，A站什么都没做却被索搜引擎广而告之用户，B站做了一切却不被用户知道，价值被A站窃取了。

2. http 1.1

301

    和http 1.0规范中保持一致，注意资源对应的路径应该是location中返回的url，而不再是原请求地址。

302

    在HTTP 1.1中，实际上302是不再推荐使用的，只是为了兼容而作保留。规范中再次重申只有当原请求是GET or HEAD方式的时候才能自动的重定向，为了消除HTTP 1.0中302的二义性，在HTTP 1.1中引入了303和307来细化HTTP 1.0中302的语义。

303

    在HTTP 1.0的时候，302的规范是原请求是post不可以自动重定向，但是服务器和浏览器的实现是运行重定向。

    把HTTP 1.0规范中302的规范和实现拆分开，分别赋予HTTP 1.1中303和307，因此在HTTP 1.1中，303继承了HTTP 1.0中302的实现（即原请求是post，也允许自动进行重定向，结果是无论原请求是get还是post，都可以自动进行重定向），而307则继承了HTTP 1.0中302的规范（即如果原请求是post，则不允许进行自动重定向，结果是post不重定向，get可以自动重定向）。

307

    在http 1.1规范中，307为临时重定向，注意划红线的部分，如果重定向307的原请求不是get或者head方法，那么浏览器一定不能自动的进行重定向，即便location有url，也应该忽略。

    也就是307继承了302在HTTP 1.0中的规范（303继承了302在HTTP 1.0中的实现）。

3. 小结

    在HTTP 1.0规范中，302的规范并没有被服务器和浏览器遵守，即规范和实现出现了二义性，因此在HTTP 1.1中，将302的规范和实现拆分成了303和307。

三、结论

    虽然在不同版本的http规范中对重定向赋予了不同的语义，但是因为使用历史和服务器实现等原因，在实际中并不一定安全按照http规范实现，因此我个人感觉上述讨论只是一个了解，在实际写代码中302还是继续用吧···

参考：

1. 《http 1.0规范》
2. 《http 1.1规范》

3. 博客：点击打开链接

附注：

    本文如有错漏，烦请不吝指正，谢谢！