序、扯淡
不要问笔者这消失的五月和六月，笔者不想谈……Endless work Limited life……
然后还在考虑一个问题，以后博客还是像以前一样一月一水呢，还是好好研究点技术，不定期发表。但总觉得后者会导致笔者进入无限鸽的状态，还是算了。
在文章的开始，我需要先提三个名词：Entity Framework、SQL注入和字符串插值。
谈谈EF Core是怎么将内插字符串转为参数化SQL查询的
小柊 发表于 2019年07月22日 0时45分42秒
CentOS 7 关闭透明大页
小柊 发表于 2019年04月30日 23时34分19秒
CentOS 7 Gnome桌面图标过大的问题
小柊 发表于 2019年03月31日 21时59分27秒
序、写在最前
非常抱歉三月份工作非常忙，外加整个人都提不起劲，所以没法写出有点质量的文章，只能这么水一篇。
一、背景
大概是17年年初还是什么时候的一次升级后，如果安装了Gnome桌面的CentOS 7桌面图标就会变的巨硕无比，大概就是这样的：
不过除了图标变大了，其他的倒没啥问题。所以很多时候就是凑合着用了。但对于我这样的强迫症而言，实在是看着不舒服。
C# 从byte[]里直接读取Structure
小柊 发表于 2019年02月28日 23时47分20秒
序、前言
emmmmm，首先这篇文章讲的不是用BinaryFormatter来进行结构体的二进制转换，说真的BinaryFormatter这个类其实现在的作用并不是特别大了，因为BinaryFormatter二进制序列化出来的结果只能用于.net平台，现在可能就用于如存入Redis这种情况下会在使用。
去年年尾的样子，我阅读学习某C++开发的程序源码时，发现作者用了一个很骚的操作直接将byte[]数组转为了结构体对象：
上面的data变量是一个指向unsigned char类型的指针，就只要一个简单的类型转换就可以将一堆unsigned char转换成想要的结构体，这着实有点让笔者有点羡慕。
后来，笔者想用C#开发一个流量分析程序，由于需要对IP报文进行仔细的特征提取，所以不能直接使用第三方数据包解析库（如：PacketDotNet）直接解析，会丢失部分特征，然而使用BinaryReader进行报文头解析的话，整个解析代码会写的丧心病狂的恶（e）心（xin），正在苦恼的时候，突然想起上面提到的那个骚操作时，笔者突然冒出了一个想法，C#里也支持结构体，那我能不能也像C++这样直接从字节序列中读取出结构体呢？
注：本文所有代码在.net Standard 2.0上测试通过。
《我想吃掉你的胰脏》小说与剧场版情节差异对比
小柊 发表于 2019年01月23日 21时29分19秒
写在最前
最近《我想吃掉你的胰脏》终于在国内上映了，作为原作党、漫画党的笔者，在上映后的周末挤出时间陪朋友把票补了。
总的来说动画化的非常赞，十分满分的话笔者可以为其打到九分的高分。
但看完之后发现剧场版的剧情和之前看小说留下的印象并不是特别符合，所以笔者决定水一篇文章，讲讲《胰脏》动画剧场版和原作之间的改动和删去的部分。
C# 全局异常捕获（for .net Core）
小柊 发表于 2018年12月17日 23时42分04秒
序、背景
在16年，笔者曾在博客里写了一篇《C# 全局异常捕获》的文章，里面讲了一下如何在整个项目中捕获未处理的异常，只不过当时写的时候还是以.net Framework和Asp.net为目标写的。
然而这两年里整个.net的圈子发生了非常大的变化，比如16年刚发布的还不温不火的.net Core，终于在这两年间熊熊的燃烧起来，现在去Nuget上面看，这两年内更新过的项目，基本都提供了对.net Standard的支持，而曾经的.net Framework因为各种各样的历史包袱，开始显得有些力不从心，甚至在今年.net Framework第一次将被.net Standard甩下——.net Core3.0将首先支持.net Standard 2.1，而.net Framework 4.8则还会在.net Standard 2.0上停留（可以看微软的这篇博客《Announcing.NET Standard 2.1》）
今天半夜准备睡觉的时候，收到了一位朋友的留言，希望笔者能补充一下在.net Core下，全局异常捕获的方式。
所以今天决定赶一下，讲讲在新的.net Core平台下，如何进行全局异常捕获。
Docker容器端口映射后突然无法连接的问题排查
小柊 发表于 2018年11月05日 23时30分13秒
一、背景
一般需要对外提供服务的Docker容器，我们在启动时后使用-p命令将对外访问端口暴露给外部，例如启动Docker Registry，我们将5000端口映射出来供外部访问：
|
1 |
docker run -d -p 5000:5000 registry |
但最近碰到一个非常奇怪的情况：研发组里一个CentOS 7测试环境里部署有Docker Registry，并对外暴露了端口。启动容器后一段时间内都是可以正常工作的，但在不定时间间隔后，外部主机就会出现无法从仓库中拉取镜像的情况，提示TimeOut：
CentOS Nginx官方yum源
小柊 发表于 2018年10月10日 23时35分22秒
一、背景
不知道为什么，现在上网搜 CentOS 安装 nginx 的教程，很多文章都会告诉你先安装 epel 源，然后就可以用 yum 安装 nginx 了。
其实 nginx 在自己官网的文档中是提供了自己的官方yum源地址的，只不过不是特别明显就是了。
官网源和 epel 源提供的 nginx 里，我个人更偏向官方源。因为 epel 源是 Fedora 负责维护的，所以用 epel 源安装的 nginx 跟官方源或者直接编译安装的 nginx 在一些细节部分会有一些不同，比如 epel 源里的 nginx 装完之后默认的测试页是“Welcome to nginx on Fedora!”，另外在配置文件上面也有些许不同，反正用起来不是特别舒服。
CentOS7 源码编译Python 3
小柊 发表于 2018年09月05日 0时00分46秒
序、扯淡
之前一直把CentOS7源码编译安装Python 3的命令放在钉钉的石墨文档里，并不准备把这个当作一篇博客单独放出来的。但最近要源码编译Python 3的次数实在是太多了，而且每次打开石墨文档的速度实在是太——慢——了——（还不如我的博客快），所以决定把CentOS源码编译安装Python 3的命令放到博客里来，以后需要用的时候就直接翻博客算了。
注：本文在2019年4月30日被重新编辑。
C#/Python Json序列化时控制字段顺序
小柊 发表于 2018年08月13日 22时39分49秒
一、背景
JSON(JavaScript Object Notation, JS 对象简谱) 是一种轻量级的数据交换格式。它基于 ECMAScript (欧洲计算机协会制定的js规范)的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得 JSON 成为理想的数据交换语言。 易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。
Json广泛的用于数据传输的时候（比如Web的前后端数据传输），对于这种场景我们不会刻意的去控制对象序列化后，Json字符串中的字段顺序。因为在这种场景下，我们的要求只是能用就好。但一些特殊的情况，例如需要对一个对象进行Json序列化，并对产生的Json字符串进行RSA签名，那就一定要控制Json字符串中的字段顺序了。因为如果不严格的控制字段顺序，明明是一样的对象会因为序列化后Json字符串中的字段顺序不一致，导致产生的签名结果不一致。
那么，在C#和Python里，有什么方法可以控制对象字段在Json序列化时的顺序呢？