![6THX~65%RJ]74O2WR2FJ7NC](https://ccloli.com/wp-content/uploads/2020/10/6THX65%25RJ74O2WR2FJ7NC.png)
![]V%LZ~ZKYNJP(~NI0U_]HE8](https://ccloli.com/wp-content/uploads/2020/10/V%25LZZKYNJPNI0U_HE8-e1603609329312.png)
又名 679 事件
1. 页面的背后是什么？
2. 真正的秘密只有特殊的设备才能看到
ロリ节存活报告
又到了惯例的「ロリの日」，虽然只剩最后一个小时了，而且这两天也并没有看点兔三期，不过还是来扯些和ロリ相关或者不相关的东西吧。
去年提到了购入了个 lolicon.icu 的米，毕竟当时注册价格才不到两刀，而且 icu 也算好记，既有萝莉控 ICU 病房的意思，又有 lolicon I see you 的意思，所以还算有点意思，也因此 loli.icu 直接被人抢注了 10 年。然而今年年初续费前收到了 Namesilo 即将自动续费域名的邮件，顺带登帐号上去看了下，发现续费价格居然涨了，不再是 2 刀了，而是 6 刀了。虽然其实还好，但是当时脑抽感觉被背刺了，于是就把自动续费的开关关了，想着反正之后域名放出再注册价格还是两刀。于是……如你所见，这个域名当然已经不是我的了，现在想想好像有点小亏，而且这域名比那个完全摸不着头脑的 uno 好记多了……不说了，血亏。
同样血亏的还有上个月忘了续费 loli.io 的 某人，等他发现的时候域名已经被挂在 park 页面上竞价了。顺带去围观了下，域名起价 99 刀。竞价嘛，肯定要高出域名价格的，不过考虑到 .io 域名本身就三十多刀，所以其实这个起价应该还好。park.io 的竞价周期是 10 天，而竞价嘛，肯定前几天没什么人起价，所以前几天域名基本就是在 100 刀这样。直到最后一天，价格竞价到了 1000 刀……
总之 loli.io 大概就这么没了，虽然不知道为什么 NAS 上的 CrystalDiskInfo 还是能用这个域名的邮箱发警告邮件，难道网易企业邮箱不会重复校验 MX 合法性？
查了下 MX 记录，也没数据，不过看这 DNS 信息，看来是被 Snowfom 拐走了（
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
C:\Users\ccloli>nslookup -type=MX loli.io a.dns.sb 服务器: a.dns.sb Address: 188.244.98.132 loli.io primary name server = a.dns.sb responsible mail addr = sb.sb.sb serial = 2020092417 refresh = 3600 (1 hour) retry = 600 (10 mins) expire = 604800 (7 days) default TTL = 180 (3 mins) |
不过现在想想，1000 刀是不是其实也还好，比如 Namesilo 里挂着的另一个 loli 域名竞价是这样的：
这么一想倒是有点担心之前瞎注册的 loli.uno 了，于是趁着近期域名到期续费时提前把 loli.uno 也续费了。顺带看了下近期 Namesilo 的域名价格，发现 .uno 现在注册费居然也只要 2 刀，血亏……虽然续费价格还是 18 刀。然而在订单页面结算时，发现这个域名居然被标记为了 Premium Domain，而且一次只能续费 1 年。啊这，NIC 这算趁火打劫吗？？？不过虽然是 Premium Domain 但是为什么价格居然还比标称价格便宜了，迷惑。
总之大概就先这样吧，这又是没啥萝莉属性的存活报告，不如再塞张ロリ？
萌节存活报告
秋天的最后一份冰淇淋
不知不觉又一年过去了呢，嗯，暂时没什么想说的，毕竟只是日年常报平安罢了。
和过去差不多，浑浑噩噩又过去了一年，估计也早就离所谓「萌」的道路越来越远了吧。
先这样流水账吧，今晚来集点兔打个鸡血吧，明天再说些和「萝莉」相关的事好了（？
通过 Verdaccio 自建 npm 仓库测试 npm 包
在开发会被其他项目依赖的 npm 包时，有时需要在其他项目下安装测试。为了方便测试，我们通常会将包本地安装或者发布到 npm 仓库下再安装。但是实际上前者会有很多 npm 处理依赖的坑，而后者即便可以用 canary 通道，某些精神洁癖的同学还是会不太乐意。
那么我们可以换种思路，为何我们不在本地自建一个 npm registry？这样可以随意发布测试，不会踩到本地安装 npm 的坑，还不会影响到线上包。Verdaccio 就是一个随开随用甚至无需配置的 npm 仓库，用户不需要自己搭建数据库，只需要一行指令即可在本地启动一个 npm 仓库。
太长不看版
解决 QQ 8.x 下同步聊天记录时无法输入独立密码
TL;DR. 本地搭建一个转发 http 与 https 请求到 https 的代理服务器，并签发一个
*.qq.com与*.vip.qq.com的自签证书并信任，然后本地修改 hosts 将proxy.vip.qq.com与verify.qq.com指向代理服务器即可
本着「又不是不能用」的原则，本地的软件基本不保持更新，所以本地 QQ 也保持在了 8.9.3 版本。
结果某一天作死开了个 QQ SVIP，再次登录时 QQ 提示需要输入独立密码同步信息，结果输入密码后点击确认，没有任何反应。
于是接下来就是喜闻乐见的作死环节了，为了尝试恢复同步消息，在 QQ 的设置里将「同步最近消息到本地」的勾选框取消了。结果重新勾选的时候，弹出了需要输入独立密码，同样无法输入，甚至还无法改变聊天记录同步时间，提示服务器超时。
估计是 API 服务器不兼容旧版 QQ 了，于是在虚拟机上装了个最新的 QQ，结果大片的空白和间距感觉要吐了，老年人审美决定还是不升级了，于是问题回到了怎么折腾 8.x 上的独立密码的问题，唯一的收获是在新版 QQ 上是没问题的。顺带查了下版本号才发现原来 8.9.6 就是 8 的最后一个版本。
[AD] 网易云音乐社招内推
名为年度总结的季度存活报告
hi，好久不见，不知还有多少人记得这里。其实说是年度总结，倒不如说是年末总结，毕竟前几个月已经基本忘得一干二净了，那么就权当是季度总结了。
败了个显示器
10 月末的时候入手了个显示器作为外接屏幕（虽然其实可能并不用得上），主要看的是几个廉价 4K 显示器，虽然 Windows 的高分辨率即便在 Windows 10 下还是比较屎。最终确定了两个型号，一个是三星的 U32J590UQC，一个是优派的 VX2780-4K-3。二手东上在最优惠时的价格差不多，而三星的价格一般会更高一些，再加上也没体验过 VA 的效果，所以决定先试试看三星。
三星的这个显示器是 32 寸的 VA 面板，上市时间是 2017 年，据说当年在某外媒被列入了最佳 4K 游戏显示器之一，因为相比较之下是最便宜的 4K 显示器还有完整的 FreeSync 支持。从 displayspecifications 上看，使用的是 群创的 VA 面板，最大 60Hz 带完整 FreeSync，亮度标称大约有 270 nit，8 bit FRC 抖 10 bit。由于是 VA 所以拥有较高的 3000:1 静态对比度，虽然亮度比较低，但是由于静态对比度比较高，所以在低亮度场景下可以看到更深的层次（此处存疑，也有说这与对比度无关，而与面板本身的色深有关）以及更艳丽的场景（此处同样存疑，这有可能是显示器出场校准偏色，至少从 RTINGS 的评测来看色准不行，实际也是如此，画面整体偏红）。而且对于 4K 来说，32 寸刚好是个比较良好的尺寸，像素密度大概和 1080P 的 15.6 寸笔记本屏幕差不多，所以其实是个挺不错的显示器。
实际到手使用的时候，发现色彩确实非常艳丽，观感效果也非常棒，检查了一下也没什么问题。但是问题也就出现在艳丽上，整个画面明显偏红，而且有些红的不自然。而且由于屏幕比较大，在一下子看不了整个屏幕的情况下是有 VA 自带的泛白偏色的。虽然比垃圾 TN 的上下反色好很多，可视角度也好不少，不过如果注意到的话还是会有点奇怪，大概就像下面这样。
不过偏色和泛白其实还好，熟悉两三天后就习惯了，所以其实不算什么大问题，毕竟人眼更喜欢艳丽的色彩，哪怕不真实（校色？不存在的），而且泛白至少比 TN 的偏色好。低亮度下（< 30%）是 PWM 调光，所以在高帧率拍摄下是能看到摩尔纹的（顺带一提居然还是红色的摩尔纹），不过其实一般不会调低亮度（况且亮度本身就比较低），所以也可以忽略不计，毕竟大学 4 年用的 Acer E5-572G 就是垃圾 TN 屏 + PWM 调光。 但是这回就到这个显示器最大的问题了，亮度不够。虽然 VA 在全黑或者暗画面下效果非常出色，但是在屏幕全白时亮度明显比不过 G3 笔记本自带的 300nit 屏幕。而且在之前提到的评测网站 RTINGS 上，测试人员测试出来的屏幕亮度居然其实只有 200nit 左右……未免也太寒酸了。在尝试游玩 ~~盗版的~~ 莱莎与炼金工房时，使用 OBS 复制画面到笔记本屏幕，虽然感觉显示器的色彩非常饱满，但是也明显感觉在较高的亮度下笔记本的视觉效果反而更好，谁让 HDR 是趋势呢。
最后折腾了三天，还是再在二手东上购入了优派的 VX2780-4K-3 做对比，~~毕竟京东 7 天无理由退货呢~~。
显示器到手明显感觉 27 寸比 32 寸小了一圈，像素密度比 14 寸的 1080P 屏幕还要高。而且虽然这款显示器之前爆出使用的是 LG 的面板，而且在京东商品页和官网的参数是 IPS 的 1300:1 对比度，在屏库网上这个对比度也只对应上了 LG 的面板。但是其实从京东评论区的反馈来看，这款 LG 面板后来爆出了四角泛红的雷，所以这个系列的新产品，包括 LG 自己的低端 4K 显示器都换成了京东方的面板（京东评论里还有人晒出了工厂模式的图），自然对比度也变成了垃圾 IPS 的 1000:1，~~不知道是不是能告欺诈消费者~~。最后到手进入工厂模式，果然是京东方的面板，不知没有泛红但是对比度不高算是好还是坏。不过除此之外其他的参数没什么问题，典型亮度标称 350nit，比三星的那个 VA 不知高到了哪里去。其他的参数倒是有细微差别，虽然是 8bit 抖 10bit，但是是全程 DC 调光，最大 60Hz 但没有 FreeSync（不过 N 卡也不支持在 HDMI 2.0 下运行 G-Sync 兼容），而且 IPS 也没有 VA 的泛白问题，还附带了一个比较鸡肋的 HDR10……额，350nit 的 HDR 能好到哪去，HDR400 都达不到，而且这个菜单未免也太简陋了……
实际上机测试，会发现高亮度下带来的视觉效果真的好太多了，如果莱莎里正午的光照在优派的显示器上作为参照的话，三星的显示效果就像午后太阳开始偏西一样。但是在较暗的图片下（比如使用了 Bing 首页的各类背景图做对比），会发现 VA 的暗部细节比 IPS 好不少，毕竟 IPS 漏光比较可怕，画面全黑的时候屏幕还是比较亮的，这也算是 IPS 通病了，如果在暗室使用对亮度也没要求，VA 无疑是更好的选择。
当然 VA 最大的问题就是黑白电平转换过慢，在 testufo 的文字滚动测试下，VA 有更明显的视觉残留，而提升响应时间而引入的 overdrive 又让画面出现了过载虚影，显示的效果反而更糟糕了。相比较之下 IPS 只需要较低的 overdrive 就能达到不错的显示效果。
不过最后就是真正纠结的地方了，为了测试游戏的效果选择了使用巫师 3 来测试游戏画面，结果发现巫师 3 其实非常适合用来测试屏幕素质。巫师 3 的里可以方便的控制日夜转换，因此可以测试显示器在高亮度画面和低亮度画面下的显示效果，而且血与酒 DLC 里的新地图是一个非常好的测试环境，因为游戏画面里的景色拥有非常高的对比度，可以直观的看到显示器本身的色彩素质。结果也正如之前说的那样，三星的 VA 面板可以看得到非常艳丽的色彩，再加上 32 寸的屏幕，色彩效果很有冲击感。但是问题还是出在低亮度上，和优派的 IPS 对比，画面就像有一层遮罩，尤其是在白天使用猫头鹰魔药时，优派的 IPS 屏幕相比较之下更白更刺眼（真实闪瞎），而三星的 VA 面板看起来明显不够亮，白光的区域反而显得看着像灰色。但是 VA 在暗景下还是有优势的，暗景下屏幕本身就比较黑效果自然也更好，而且在游戏黑夜里骑马奔跑时 VA 的高对比度（也有可能是响应时间过慢）使得屏幕能更清晰地展示远景的轮廓。
总之……两者还是难分伯仲，两者都有各自的优点，VA 相比之下优点更多缺点也更多，但是抛开这些不谈，两者的屏幕素质都非常不错……最后考虑了很久，还是选择了优派的 IPS 屏幕……啊，要是有同时结合两者的优势的屏幕（包括便宜）该多好……
350nit 真亮！（？
从 Fetch 到 Streams —— 以流的角度处理网络请求
Title image of Streams API by Mozilla Contributors is licensed under CC-BY-SA 2.5.
此文章的略微润色版可前往 知乎、掘金、SegmentFault、专栏 查看
在服务端开发中，流是一个很常见的概念。有了流我们就不再需要等待整个数据获取完毕后才处理数据，而是可以一段一段地拿到数据，在获得数据的同时直接解析数据。这样既可以高效利用 CPU 等资源，还减少了存放整个数据的内存占用。不过在过去，客户端 JavaScript 上都没有流的概念，而随着 Streams API 在各大浏览器上的逐步实现，我们终于可以使用原生的 API 以流的角度来看待数据了，例如从 fetch 请求上可以得到一个网络流。
既然标题是「从 Fetch 到 Streams」，那么首先让我们来看看既熟悉又陌生的 Fetch API。相比较于 XMLHttpRequest，fetch() 的写法简单又直观，只要在发起请求时直接将整个配置项传入就可以了。fetch() 方法接受一个 Request 实例，或者是大家更常使用的方法——传入需要请求的 URL 以及一个可选的初始化配置项对象，然后就可以从 Promise 中取得返回的数据：
|
1 2 3 4 5 6 7 8 9 10 11 |
fetch('https://example.org/foo', { method: 'POST', mode: 'cors', headers: { 'content-type': 'application/json' }, credentials: 'include', redirect: 'follow', body: JSON.stringify({ foo: 'bar' }) }).then(res => res.json()).then(...) |
如果你不喜欢 Promise 的链式调用的话，还可以用 async/await：
|
1 2 3 |
const res = await fetch('https://example.org/foo', { ... }); const data = await req.json(); |
看起来相当的直观，在请求时直接将所有的参数传入 fetch() 方法即可，甚至相较于 XHR 还提供了更多的控制参数，例如是否携带 Cookie、是否需要手动跳转等；取出数据也只需要调用 Response 对象上的方法就能拿到格式化的数据（例如 res.json()）。而直接使用 XMLHttpRequest 看起来就没那么方便了，初始化时既有方法的调用又有参数的赋值，看着还挺混乱的：
|
1 2 3 4 5 6 7 8 9 10 11 |
const xhr = new XMLHttpRequest(); xhr.open('POST', 'https://example.org/foo'); xhr.setRequestHeader('Content-Type', 'application/json'); xhr.responseType = 'json'; xhr.withCredentials = true; xhr.addEventListener('load', () => { const data = xhr.response; // ... }); xhr.send(JSON.stringify({ foo: 'bar' })) |
而随着 AbortController 与 AbortSignal 在各大浏览器上完整实现，Fetch API 也能像 XHR 那样中断一个请求了，只是稍微绕了一点。通过创建一个 AbortController 实例，我们就得到了一个可以控制中断的控制器。这个实例的 signal 参数提供了一个 AbortSignal 实例，还提供了一个 abort() 方法用于发送中断信号。我们将 signal 传递进 fetch() 的初始化参数中，就可以在 fetch 请求之外控制请求的中断了：
|
1 2 3 4 5 6 |
const controller = new AbortController(); const { signal } = controller; fetch('/foo', { signal }).then(...); signal.onabort = () => { ... }; controller.abort(); |
只可惜提出这个解决方案并实装的时间还是有点晚，Fetch API 早在 就在 Firefox 上实现，并且最早于 在 Chrome 上实装。而该功能最早也是 Edge 浏览器在 2017 年 4 月实现，Safari 直到 2018 年末才被发现 AbortController 不能中断请求的 bug，最后在 2019 年 3 月的 Safari 12.1 中才正式解决。算下来从 Fetch API 在浏览器上实装开始，到主流现代浏览器全部支持，跨越了整整四年。
Image of AbortController & AbortSignal Support Table by caniuse.com is licensed under CC-BY 4.0.
晚归晚，但是看起来现在的 Fetch API 已经无所不能了，不过在「真香」之前，我们来考虑一个很常见的场景：浏览器需要异步请求一个比较大的文件，由于可能比较耗时，希望在下载文件时展示文件的下载进度。XHR 提供了很多的事件，其中就包括了传输进度的 onprogress 事件，所以使用 XHR 可以很方便地实现这个功能：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
const xhr = new XMLHttpRequest(); xhr.open('GET', '/foo'); xhr.addEventListener('progress', (event) => { const { lengthComputable, loaded, total } = event; if (lengthComputable) { console.log(`Downloaded ${loaded} of ${total} (${(loaded / total * 100).toFixed(2)}%)`); } else { console.log(`Downloaded ${loaded}`); } }); xhr.send(); |
但是 Fetch API 呢？你打开了 MDN，仔细地看了 fetch() 方法的所有参数，都没有找到类似 progress 这样的参数，毕竟 Fetch API 并没有什么回调事件。难道 Fetch API 就不能实现这么简单的功能吗？这里就要提到和它相关的 Streams API 了——不是 Web Socket，也不是 Media Stream，更不是只能在 Node.js 上使用的 Stream，不过和它很像。
萝莉节存活报告
嗯，今天也还活着，不过倒也没什么想说的。
要说和今天相关的事情的话，其实，除了 xn--eekf.xn--q9jyb4c 这个域名以外，在半年前还买了个 loli.uno。当然，买了并不代表用上了，所以暂时就重定向到 xn--eekf.xn--q9jyb4c 上了。结果大概上个月的时候 IP 被墙了，所以其实你们现在直接连接也访问不了了。
traceroute 断在了 Multacom 机房的路由，ssh 后 traceroute 到国内的 IP 断在了骨干网，ping 其他邻居的 IP 基本没有事。所以应该不是屏蔽网段，而是直接针对 IP 屏蔽了。不过也奇怪应该没有什么大流量之类的，发现出问题的时候还在公司走 ss 用 Telegram，并没有什么大流量，不是很懂。嗯……难不成之前是瞎玩写的 xn--eckxj725iv5g.xn--eekf.xn--q9jyb4c 被发现了，然后就被屏蔽了？反正不是很懂，目前暂时靠 CloudFlare 续命，十一回家的时候发现家里的联通网络相性非常好，还能流畅在 YouTube 看阅兵（？
另外上个月折腾了下 Oracle Cloud，选择了日本线路，延迟感人，绕道到 ping ~200ms，speedtest 到东京的测试服务器上行 48Mbps 下行 4Mbps，iperf3 也就 10Mbps。由于羊毛被褥的太狠，想开第二台机器做内网 iperf3 测试，结果开通的时候提示已经售罄了，所以至今不知道这玩意的网络配置是什么样，感觉或许还不如美西节点，美国节点还有免费邮件额度。相比之下韩国节点可是在公司跑到了 500Mbps 的，不过韩国基本不能访问 porn 也没什么用，日本节点再慢，至少还能看个 DMM（虽然也不知道能买什么，也不玩页游，所以……好像也没用）。
或许之后会试着在那个东京节点上做一份 mirror，有时间再折腾吧。对速度感兴趣的同学可以访问这个对象存储的链接，看看速度有多渣：https://objectstorage.ap-tokyo-1.oraclecloud.com/p/VdT8VdFqkU-e4Tex4GnHK-VA6XwCnH_7zjpnM_Xtnr4/n/nrzblovvku9x/b/bucket-ccloli/o/76825905_p0.jpg 。总之，这个东京节点路由不行，虽然 traceroute 机器的上一个路由是从广州出口直接到 Tata 的，不过还是很慢，对东亚用户来说还不如美国线路（韩国用户和日本用户除外？），反正现在的 ping 值比到位于西海岸 LA 的 Multacom 机房的 200ms 还高，夜间高峰期线路干扰更可怕，丢包率 50%……除了能访问只有日本 IP 能打开的网站外，还不如美西节点。
嗯，总之，大概就这样吧，明年的存活报告或者明天见。
嗯，先赶在 23:59 前先发布了，然后再来编辑（
萌节存活报告
嗯，我还活着。
感觉每年十月十日发文章就当是存活报告好了。
嗯，就这样，明年见。