本文不定时更新中……

具备 RESTful 相关知识会更有利于学习 ASP.NET Web API：RESTful API 学习笔记

ASP.NET Web API 官网：https://www.asp.net/web-api

服务 URI Pattern

HttpResponseMessage

可提供大量控制的响应消息。 例如，以下控制器操作设置的缓存控制标头。

public class ValuesController : ApiController
{
    public HttpResponseMessage Get()
    {
        HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.OK, "value");
        response.Content = new StringContent("hello", Encoding.Unicode);
        response.Headers.CacheControl = new CacheControlHeaderValue()
        {
            MaxAge = TimeSpan.FromMinutes(20)
        };
        return response;
    } 
}

IHttpActionResult

public IHttpActionResult Get (int id)
{
    Product product = _repository.Get (id);
    if (product == null)
    {
        return NotFound(); // Returns a NotFoundResult
    }
    return Ok(product);  // Returns an OkNegotiatedContentResult
}

其他的返回类型

响应状态代码为 200 （正常）。此方法的缺点是，不能直接返回错误代码，如 404。 但是，您可以触发 HttpResponseException 的错误代码。

完善 Help 页

一般都是通过元数据注释（Metadata Annotations）来实现的描述的。

显示接口和属性的描述：

打开 HelpPage 区域的 App_Start 目录下的 HelpPageConfig.cs 文件，在 Register 方法的首行取消注释行：

config.SetDocumentationProvider(new XmlDocumentationProvider(HttpContext.Current.Server.MapPath("~/App_Data/XmlDocument.xml")));

在项目右键属性“生成”页，勾选“XML 文档文件”，并填写与上述一致的路径（App_Data/XmlDocument.xml）。

给接口加上 ResponseType 显示响应描述和示例：[ResponseType(typeof(TEntity))]

在实体模型的属性上加入 RequiredAttribute 特性可提供请求或响应中的实体的属性描述，如：[Required]

推荐使用：Swashbuckle

关于格式

在 WebApiConfig.Register() 中加入以下代码以禁止以 XML 格式输出（请按需设置）：

GlobalConfiguration.Configuration.Formatters.XmlFormatter.SupportedMediaTypes.Clear();

Json 序列化去掉 k__BackingField

GlobalConfiguration.Configuration.Formatters.JsonFormatter.SerializerSettings.ContractResolver = new Newtonsoft.Json.Serialization.DefaultContractResolver { IgnoreSerializableAttribute = true };

如果属性值为 null 则不序列化该属性

config.Formatters.JsonFormatter.SerializerSettings = new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore };

工作这几年碰到的版本检测升级的接口也算是五花八门，啥样的都有，但肯定有的功能是有个 apk 的下载链接，能间接或直接提示你是强制还是非强制更新：

• 间接是指提供你后台最新版本号，让你自己与本地版本号通过比较得出是否升级；

• 直接就是后台接口直接返回个 Boolean 类型告诉你是强制或者非强制更新。

个人认为一个好的版本检测接口需要设计的更灵活更清晰用起来更方便，下面就我理解的接口设计如下（如思路有误，欢迎指正）：

总字段如下(并不是所有字段都要返回给客户端)：
  1.最新版本号 ：newVersion
  2.最小支持版本号 : minVersion
  3.apk 下载 url : apkUrl
  4.更新文案 : updateDescription
  5.是否有更新 : isUpdate
  6.是否强制更新 : forceUpdate 可选字段：
  7.apk 文件大小：apkSize
  8.apk 的文件 MD5 值：md5

方案一(后端处理逻辑)：
在客户端请求参数中添加当前版本号 currentVersion 传输给后台，由后台根据客户端传过来的当前版本号 currentVersion 做相应的判断后给出是否强制更新。
后端逻辑如下：

1. 如果 currentVersion < newVersion, 则 isUpdate = true；

• 如果 currentVersion < minVersion, 则 forceUpdate = true；

• 如果 currentVersion >= minVersion, 则 forceUpdate = false;

• 如果有特殊需求可指定某个版本必须强制更新，如 currentVersion == XXX, 则 forceUpdate = true;

2. 如果 currentVersion == newVersion，则 isUpdate = false.

结论：
返回客户端的字段仅需要 apk 下载 url : apkUrl、更新文案 : updateDescription、是否有更新 : isUpdate 、 是否强制更新 : forceUpdate 这四个字段即可。

方案二（前端处理逻辑）：
逻辑和后端处理逻辑大体上一致，只是把逻辑判断移到前台，故需要后端提供最新版本号 ：newVersion 、 最小支持版本号 : minVersion 、apk下载url : apkUrl 、更新文案 : updateDescription 这四个字段。

客户端逻辑如下：

1. 如果 currentVersion < newVersion, 则有更新信息；

• 如果 currentVersion < minVersion, 则需要强制更新；

• 如果 currentVersion >= minVersion, 则不需要强制更新;

2. 如果 currentVersion == newVersion，则没有更新信息。

总结：
细心的你可能会发现上面的可选字段 apkSize 和 md5 并没有用到，既然是可选字段也就是可用可不用，根据需要决定是否采用，这里来讲下他们的用处。

• apk 文件大小 apkSize
  这个用处可以说出于考虑用户体验，需要在升级弹框出来展示给用户将要更新的内容多大，让用户决定在非 WIFI 状态是否要更新，不能为了拉用户下载量或所谓的 UV 数直接让用户在不知道大小的情况下去直接下载（土豪用户绕路）。

• apk 的文件 MD5 值
  这个主要是出于安全考虑吧，因为文件内容固定的话对应的 md5 是一样的，我们可以通过这个 md5 值来和下载的 apk 的 md5 值进行比较去保证我们从服务器更新下载的 apk 是一个完整的未被篡改的安装包，也就是说如果我们下载的 apk 的 md5 值和服务器返回的 md5 值相等，则说明我们下载的 apk 是完整的，且没有被相关有心人处理过的 apk。

综上所述，这个版本更新的处理逻辑客户端和后端谁来做都可以，无关乎懒不懒的问题，个人感觉灵活性后端比客户端方便多了，毕竟后端可以指定 minVersion 与 newVersion 中间的任意一个版本强制更新，而客户端做起来就没有那么灵活了，个人见解，如有更好的方案，欢迎指教。

最近，空心图标和实心图标的讨论变得激烈起来，有言论指出空心图标在视觉上比实心图标看起来更复杂，更容易让用户差生疲劳感和倦怠感。对此，设计师们都各抒己见，一部分人表示赞同这种说法，而另一部分人则表示这样的言论将问题过分了放大化了，并且在证据方面有所欠缺。

图标也可以理解为是网站中的一种指引，是每个新用户都会涉及到的元素，所以无论空心或实心，一个能够令人一目了然，并且记忆深刻的图标才是用户真正喜欢的图标。

以下是小编搜寻的一些空心或实心的图标案例，看看你更倾心于哪一款呢？

1.模糊背景上覆盖着由简单线条、字体和单一的颜色组成的空心图标，这会让整个界面看起来很优雅。不仅如此，这种简易的设计手法也让设计师轻松不少，在效果和操作上都令大家很满意。

2.纯色的背景似乎搭配任何元素都能达到令人意想不到的效果，下面这个案例也不例外。正红色与白色之间的经典配搭，加以可爱的造型，成就了一个俏皮的实心图标设计。界面底部的实心按钮与幽灵按钮也与图标区域前后呼应。

3.APP底部的图标随着用户的任意切换，在空心和实心之间自由转变。实心的图标相比较空心的而言，给人一种更突出和明显的视觉效果，让用户更容易的抓到重点。而主内容左边的卡通小图案同时采用了空心的设置，尽显极简主义。

4.Line的界面似乎代表了大多数APP的图标设计方式。头部和底部的图标选用两种颜色的实心设计，下拉菜单部分使用空心图标。这样的设计虽然比较大众化，但不可否认的是，这样的做法的确让整个界面看起来格外整洁。

5.幽灵按钮虽然简洁大方，但是过多的使用会另界面很单调无味，但如果使用全部实心的图标设计又会觉得很突兀。下面这个案例就想出了一个好方法。既然空心实心都不合适，那不如尝试一下让两者结合在一起吧。

6.两种色差明显的颜色搭配在一起会体现出一种自然而然的时尚感，黑色背景和亮黄色的图标元素就是很典型的例子。强烈的对比色会让空心图标看起来也像实心图标一样，具有突出重点的效果。

7.Metro风格的界面设计也能运用在APP的图标模块中，案例中将各种第三方分享平台的实心图标都用方块元素连接在一起，让原本单调的图标瞬间活跃了起来，给用户一种焕然一新的感觉。

8.传统的导航图标大多会集中在一个区域内，而SevenEleven的APP在此做了很大的突破，将4个部分分别分布在界面的上下左右，简单的界面突然有了运动场的氛围，让APP充满了生命力。

9.天气类应用的看点中总会有气候图标的一席之地，正如这个案例中所表现的，这又是一个空心与实心相结合的图标设计。

10.这也是一个纯色块与实心图标搭配的案例，这个APP的界面设计其实很普通，但正因为图标的设计让网站变得可爱起来。

图标在网页设计中算是一个小单元，但它的重要性大家都有目共睹。空心图标和实心图标在不同的环境中发挥着不同的作用，美化着网页中的小细节。

删除主题时，会变更主题表 pre_forum_thread：

displayorder = -1

moderated = 1

帖子表（或分表） pre_forum_post* 该主题的所有帖子的

invisible = -1

同时 pre_forum_threadmod 会新增一条 DEL 记录，用于显示到 Discuz! 控制面板 - 内容 - 主题回收站。

删除回帖时，会变更回帖表 pre_forum_post（或分表）：

invisible = -5

屏蔽回复时，会变更回复表 pre_forum_post（或分表）：

status = 1

* 仅列出部分数据表及字段

mag_ads 广告

mag_circle 圈子（相当于 PC 版的版块）

mag_common_applaud_(n) 点赞详情表（分表）n 与 content_id 末位一致

mag_common_attachment_(n) 附件详情表（分表）n 与 aid 末位一致

mag_common_attachment_index 附件索引表

mag_common_comment_index 评论索引表（相当于 PC 版的回复表）

mag_common_content_log 对圈子内容的操作日志（点赞、评论等）

mag_show_content 圈子内容（相当于 PC 版的主题表）

mag_user 用户表

未进行完整的测试和分析，总结有误请指正。

获取

在 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

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

当前上下文中不存在名称"__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 错误和警告。

公众号的报警群中经常收到这样的消息：

Appid: *
昵称: *
时间: *
内容: 微信服务器向公众号推送消息或事件后，开发者5秒内没有返回
次数: *分钟 *次
错误样例: [OpenID=*][Stamp=*][3rdUrl=http://api.socialbase.cn/extapi/wechat/message/*/][IP=*][Event=Click Menu Url]
报警排查指引，请见: http://url.cn/ab0jnP

除此之外还有另外一个问题，就是客户端发送图片后会收到两条回复，一条是“印美图”处理打印图片链接，另一条是识脸判断年龄的图文。前者是之前与印美图公司合作的与快速打印照片设备配合吸粉的功能，后者是跳转到使用 FACE++ 的页面显示图片中人物的年龄。

几天来一直找不出原因，代码中搜索错误关键词无果，被动回复消息整个流程断点逐步调试也没有发现哪里有返回“请点击这里预览印美图 点击此处裁剪相片并打印。”

不是开发模式的问题，那一定在公众平台，登录后终于在“开发”的“基本配置”页找到了“管理已授权的第三方平台”，找到“Socialbase”取消授权即可。

整个世界安静了……

今天在逛汽车之家论坛时偶然发现，当选中帖子内容时，部分文字被空缺出来，没有被选中，一开始以为是把部分文字使用图片来代替了，审查元素发现是常见文字使用伪元素来输出，比如“大”字：

<span class="hs_kw10_mainuD"></span>

.hs_kw10_mainuD 样式：

.hs_kw10_mainuD::before {
    content: "大";
}

这样肉眼根本无法察觉，因为不管字体大小、颜色等等都与普通文字一样，这是区别于用图片代替的最大优势，其次还能减少请求数，减少带宽消耗等。