10/5
2015
今天看到了一张不错的图，照例谷歌搜图找出来了原图，出处是《(C86) [40010壱号 (40010試作型)] Hitasura Summer (ToLOVEる-とらぶる-)》。
磁力链接：
magnet:?xt=urn:btih:C1AD1FF8C91ECFE86CF1C8264AAB2ABAD2C14C0A
ToLove本子 Hitasura Summer (ToLOVEる-とらぶる-)
10/3
2015
昨天去收傲娇千夜的初音图，看到了他最新的一张作品，当我读到描述的时候我已经跪了。这个比装的，我给10分。
大触的装逼日常
10/2
2015
前言： 和好（壕）伙伴的约定，高考之后送我一个抱枕~今天兑现了呢。
其实是因为自己拖沓，怕花钱也没有主动去淘宝找，毕竟是朋友送给我的嘛，总不能太坑人辣！！
进驻saber酱的空间已经好几个月了，第一次投稿有些小鸡冻呢。
我老婆的抱枕⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄
10/2
2015
谨以此图表达我对国庆只过三天并且两天调休并且最后也没能休并且宿舍一直断网的深切的感受。
命运石之门资源提取工具（补档在2L
CG里并没有包含游戏里的全部图片，有些图片应该是属于背景图这组资源里的。
前几天把《命运石之门》通关了，游戏超赞。好想再玩玩别的路线，可是最近又开始玩别的游戏了。
Read More →
命运石之门通关记录
09/29
2015
虽然本站看起来和以前一模一样，不过已经换了空间重新装了一次哦~在这里总结下经验吧~
首先要备份的是数据库，建议从phpmyadmin里直接备份，导出sql格式。但这样的话一定要询问下客服，导入时限制的文件上限是多大。因为默认情况下mysql只支持2M以下的sql文件的导入。
其次去备份WordPress的文件，需要备份的是wp-content里面的plugins、themes、uploads文件夹。此外如果你修改了WordPress的文件，也备份出来。
最后检查其他需要备份的文件，例如.htaccess、favicon.ico、robot.txt、网站地图等文件。
恢复的时候先装上WordPress，然后把网站的文件传上来。最后去数据库里，清空WordPress的所有数据表，再导入之前的数据库备份。
当然域名解析和空间绑定也要改，这个就不多说了。
备份和恢复WordPress的记录
09/28
2015
上面的这张图片是一个ico图标。在chrome中可以显示为它的最大尺寸256*256，在Firefox中会显示为最小尺寸16*16，在IE中无法显示←_←
昨天搜人物素材，无意间看到了这张图。当时一愣，美女你谁啊？你不是沙耶加吗，什么时候去客串saber了？
去年看了小圆的TV动画，剧场版却是前几天才去看的。看完没两天就见到了沙耶加的图，不得不说这是命运石之门的选择啊。
说到命运石之门，正好最近在玩石头门的游戏。这巧合……难道说，这是未来的我改变了过去，故意要让我看到这张图的吗？那么“他”是要提醒我做些什么呢？是不是要让我感到遇到了极大的巧合，然后去买一张彩票呢？噫……姑且去买一个看看
于是我就打开了手机淘宝，结果找不到彩票选项。百度了一下，噫————
马萨卡，这一切都是“机关”的阴谋吗？我顿时不寒而栗——
回到正题，五色战队怎么会只有一张图呢，剩下的四个请继续往下看。
Read More →
FZ和小圆结合的人物图标
09/27
2015
米娜桑，中秋快乐~
其实我这个人对过节没什么感觉的，不过好歹还是发篇文章纪念下吧。
到北京一周了，现在真可谓独在异乡为异客了。工作好忙，也没出去转转（虽然我怀疑就算有空我也不会出去转）。白天上班忙的连发篇文章的时间都没有，晚上回了宿舍还没网——等到十月一才能有网。文章断更的时候我很不爽啊（虽然发出来也没几个人看←_←
Read More →
诸君中秋快乐
09/26
2015
本站以前有篇文章——《saber美图》。以前我看到了saber的美图就会发上来，频繁的更新。可是自从逛了P站之后这篇文章基本就没更新过了。这也算告一段落了吧，于是我想把这篇文章里的图片下载下来，这就有了下面的代码：
window.stop();
var allimg=$(".post_t img");
var downa=document.createElement("a");
document.body.appendChild(downa);
downa.download="";
var imgno=0;
function downimg () {
downa.href=allimg.eq(imgno).attr("src");
downa.click();
imgno++;
if (imgno>=allimg.length) {
window.clearInterval(downimgt);
};
return imgno;
}
var downimgt=setInterval("downimg()", 1000);
使用方法：
打开文章页面，在文档加载完成之后（不必等待图片加载完成），在控制台执行上面的代码。
执行之后，将会停止页面加载，然后创建一个下载用的链接（所以此代码照例是chrome only）。最后，每一秒创建一个下载链接，以下载图片。
如果chrome询问是否允许此网站下载多个文件（应该是在地址栏上显示的提示），点击允许。
下载本站图片的js代码
09/24
2015
刚才排了一个手机页面，完了之后发现页面底部总是有个间隙，审查元素也找不到是哪里来的，因为body和html标签内都没有包含这个间隙。后来一点点查找，发现是after伪类引起的。
在清除浮动时，我们经常会使用伪类，例如：
.clearfix:after{content:".";display:block;height:0; clear:both; visibility:hidden;}
虽然可以给after和before设置宽高为0，但是它仍然是占据空间的。如果加了这两个伪类的元素后面没有其他元素了，就会造成空隙。如果后面有其他元素，伪类占据的空间就会被后面的元素占掉，不会产生空隙。
请看以下代码：
<body>
<div id="a">
<div></div>
<div></div>
<div></div>
<div></div>
</div>
<div id="b"></div>
<style>
body{margin: 0;padding: 0;background: #aaa;}
#a{height: 1000px;background: #fff;}
#a div{float: left;width: 25%;height: 100%;}
#a:after{content:".";display:block;height:0; clear:both; visibility:hidden;}
#b{height: 200px;background: #0c0;}
</style>
</body>
如果把元素b删掉，可以看到网页底部产生了空隙。不删除元素b的话，空隙就看不到了。
要解决空隙的问题，也很简单，给清除浮动的元素加上overflow: hidden;就行了。
使用after和before伪类可能使网页底部产生空隙
09/23
2015
所谓的传送图片，就是需要对方接收并存储起来使用的图片。注意，本文所探讨的问题没有得出准确的结论，所以你可以跳到底部直接看结论（伪）就行了。
先说个题外话吧。今天经理给我了个医生的照片，让我做个小尺寸的证件照。做了之后经理不满意，说你这缩小到这么小了，怎么看起来图片质量还这么差？我只好说这不是我的锅，原图就是光线暗，人物皮肤上噪点很多，皮肤上也有老年斑什么的，图片缩小之后这些问题更突出了……但总之是得再改。一番折腾之后，噪点不明显了，人物皮肤光滑了（当然也感觉模糊了）。本来就很渣、很小的素材，强行美容，最后变得有点模糊了。这时候我只好存成png（因为png是无损压缩），然后通过QQ聊天框发给了经理。
这时，一个困扰我多年的问题再度浮上心头，QQ会不会对图片进行压缩呢？
于是我找别人进行测试。首先测试jpg，我发送了一张700多K的jpg风景图，然后我另存下来，发现只剩下100多K了。对于jpg来说，这个结果并不意外，因为另存为jpg的时候图片肯定会被压缩。那压缩比是多少呢，经过测试，图片经过QQ另存之后的体积，比xnview以80质量另存为jpg时的体积略小一点。可以粗略的认为QQ的压缩比也是80。
注意，你发送的图片，当你在图片上操作的时候，其实操作的是本地图片。这样的话，需要两个人测试发送的结果了，自己是不行的。
经过小w的提醒，我从缓存文件夹查看接收到的文件。然后我让基友帮我测试，首先他发送了一个100多K和200多K的图片，缓存文件夹里的图片大小和他发送的一致。然而当他发送1M多和6M多的图的时候，我接收到的图却只有几百K。是否可以说明QQ会对体积大（可能是超过1M）的图进行压缩呢？
但是还有个环节不能忽略，当别人收到你发的图片的时候，是不是已经被QQ压缩过了呢？当他进行另存的时候，实际上已经是第二次压缩了吗？
对于上面的问题，当我把大图另存之后，发现另存的图片体积居然比QQ发给我的图片（即已经被QQ压缩过的）要大。6M的图是张照片，QQ发给我，缓存文件夹里是400多K，可是我另存的时候居然是1M多。又测试了另一个大图，也是如此。于是我猜测，从QQ里面另存jpg图片的时候，是从原图进行另存的，不是从聊天框里面的图另存的。
对于png图片，发生了一点有意思的事。我让别人发给我了一张png，然后我存的时候发现只能选择jpg和bmp格式。我发给别人一个png，别人却可以选择存成png的。经过几次测试，我认为这和图片的透明区域有关：如果png里面不包含透明区域，发送到别人那里就变成jpg了，如果包含透明区域，则会保留png的格式（其实不完全对）。
然后我去测试我开头说到的医生的png，这张图片没有透明区域，体积才7K。发给同学之后，他仍然可以存为png。这我就纳闷了，说好的不透明就压缩成jpg呢？难道只对大图压缩，对小图放行？
实验到此结束，发现了一点有用的东西，但是真相仍然扑朔迷离。总结一下我的猜测：
图片是否会被QQ压缩，都是和体积有很大关系的。
jpg的话，几百K的一般不会被压缩，再大的就有较大可能被压缩了。但是当你另存的时候，其实是从源文件另存的，和QQ发送给你的图片（即使可能被压缩过）并没有关系。所以你存了之后只是一次压缩，不是二次压缩。
png的话，小图一般不会被压缩；中图（我猜测是几百K到一M左右）较大可能会根据有无透明区域进行压缩。无透明区域的会压缩后发给你，变成了jpg，有透明区域的则不压缩；大图则极大可能会被压缩，不管是否存在透明区域。一旦被压缩，就变成了jpg格式，会丢失透明通道。当你另存没有被压缩过的图的时候，保存的就是源文件。另存被压缩的图的时候，也是从源文件进行另存的，但是存储的是jpg，体积就相当于你把png原图以80质量转换成了jpg。
到最后，我能说的也只有这些：
jpg文件另存下来肯定会受损（即使QQ发给你的时候没有压缩），所以传文件吧。png图片如果在另存的时候仍然能保存成png格式，那就是原图。
对于jpg和png通用的：想要不被QQ压，体积不要超过1M。
