天空 Blond
type: channel
link: https://skyblond.info/
description: 愿知识带给你我勇气，用那温暖的光，驱散冰冷的黑夜。
items: 【歪门邪道】从零开始部署自己的XMPP服务器
items: 【歪门邪道】用ESP32替代尼康SnapBridge - 协议篇
items: 【随便写写】79 & 我买Z8了 & 春节后的摄影
items: 【歪门邪道】博客升级、容器化、PHP 8.3
items: 【歪门邪道】本地部署LLM的初尝试
items: 【歪门邪道】使用LLM翻译超时空辉夜姬轻小说
items: 【随便写写】78 & 2026春节摄影
items: 【代码札记】改进电码转换程序
items: 【随便写写】77 & 欢度元旦 & 2025年终总结
items: 【随便写写】76 & 11月拍的照片

【歪门邪道】从零开始部署自己的XMPP服务器
type: item
date: 2026-09-01T09:16:00+08:00
description: 之前公司一直用Matrix作为即时通讯软件，但我一直不是很喜欢这个协议，总觉得它太臃肿了，而且依赖客户端同步状态，稍有不慎就会出现无法正常使用的情况。而与此同时，我一直对XMPP很感兴趣。在收拾服务器的过程中，我删掉了一直没用上的Hermes Agent，节省出了不少内存，于是决定自己部署一个XMPP服务器试试看。什么是XMPP和一些煞有介事的开源项目一样，XMPP本身不代表任何代码或实现，而只是一种标准。让事情变得更糟的是，XMPP是一系列标准。例如RFC 6120定义了XMPP的核心标准，例如XML流要怎么协商建立和关闭，流有哪些属性，干什么用的，遇到错误要怎么处理，TLS要如何协商，还有Stanza是怎么定义的，诸如此类。想要聊天功能？不好意思，还得再来个RFC 6121定义一下花名册（roster）、联系人地址格式（JID）、如何订阅消息、怎么交换信息。按道理来说，到这一步应该就能实现最基础的消息交换（聊天）了，但如果你没在线，就收不到消息，因为这只是消息交换，不隐含任何存储功能。此外，目前这些消息还全都是明文的，一个服务器内还好办，如果涉及跨服务器沟通，那你最好祈祷服务器互联没有用明文，并且两边的站长不会偷看你的信息。如果想要安全，那还得考虑加密。而且这些RFC只说了1对1交换信息，没有考虑到群聊。那么你想吧，群聊、离线消息存储、多人聊天，这些东西加在一起，基本上是所有现代即时通讯软件的门槛了，尤其是端到端加密+群聊，目前谁也没有想出一个万能的好办法，各种协议采用的方法都不同，进而有不同的优点和缺点。总之，互联网发明这么多年了，人类还没想明白要怎么样安全且优雅的聊天。于是便有了RFC之外的XMPP拓展协议，即XEP。比如XEP-0313 MAM，这个拓展协议允许服务器帮助用户中心化地暂存消息，这样用户的客户端就可以同步消息，而不必担心某个客户端离线之后收不到消息，导致消息历史和其他客户端脱节。还有XEP-0045 MUC，这个扩展协议定义了多人聊天需要由服务器提供一个类似IRC room的东西，然后转发给群聊的参与者。至于端到端加密，我们有两种尝试，一个是XEP-0373利用OpenPGP来加密，类似发邮件的PGP加密和签名；另一个是XEP-0384，创造了一个基于Signal的OMEMO协议，后者似乎更广泛一些。至于发送大文件，使用XML流传输二进制肯定是想不开了，于是人们又搞了XEP-0363，用HTTP协议传文件。。。。。。总之，XMPP的核心很轻量化，虽然没有很完美，但在我看来，要比Matrix优雅不少：没有复杂的状态同步，没有沉重的协议。大部分消息都是XML（或者说Stanza），扩展按需开启，如果你只想写一个Echo Bot，那只要实现最核心的XMPP就可以了。想要加密，就实现OMEMO（虽然目前实现不多，Java上的实现比较废物，Python上的omemo库倒是还行，但因为python这个语言本身非常糟糕，因此拖累的这个库的使用体验），想要上传文件，那就实现一下XEP 0363。就像乐高一样，你需要什么就装上什么，不需要就不用装。但话又说回来，这也就意味着不同的客户端支持的标准不一样，能力也就不一样，你可以用XEP 0363通过HTTP发文件，但对方的客户端不一定能明白。虽然比较广泛使用的协议被大多数客户端支持，但不同的客户端有自己独特的功能，可能换一个客户端就不能用了。选型由于标准是开放的，所以任何人都可以按照标准自行实现客户端和服务端。但有时候百花齐放并不是好事，很有可能出现A客户端123功能比较好，而B客户端456功能比较好。想全都要？不好意思，A和B换着用吧。因此选型其实是早期最让人摸不着头脑的事情。关于服务器，最初我有三个候选：ejabberdOpenfireProsody IM由于Openfire是Java写的，而我的服务器没多少资源，因此率先排除。而ejabberd看起来非常企业级，和RabbitMQ一样是Erlang写的，因此在性能和可拓展性上没的说，并且主打开箱即用，包含了XMPP服务器本身和用于音视频聊天的SIP服务，适合企业。但Erlang的一个问题在于，它的起步价很高，虽然天花板也很高，但我的小服务器确实承受不住。虽然从来没有跑过ejabberd，但我之前跑过RabbitMQ，起手4G内存漱漱口，我用不起。于是我将选择放在了Prosody上。当然，社区中也有一些让XMPP更加易用的尝试，例如Snikket，他们试图将Prosody和一些客户端包装起来。但我部署完prosody之后才知道他们，所以没有尝试。对我而言，我只需要文字聊天+传文件，以及端到端加密即可，因此Prosody能满足我的需求。关于客户端，虽然有一些正在开发中的客户端看起来赏心悦目，但大部分功能不全。因此最终我选择…

【歪门邪道】用ESP32替代尼康SnapBridge - 协议篇
type: item
date: 2026-08-01T09:56:00+08:00
description: 天下苦SnapBridge久矣，因此我决定用ESP32做一个替代它的硬件。本篇介绍SnapBridge的配对和下发数据的过程。前言上文提到我买Z8了，满心欢喜地设置好SnapBridge之后发现，Z502和Z8不能同时用，也就是说，如果我出门拍鸟想要双持，那么至少有一个相机收不到GPS数据。更何况尼康这个App做的，又费电又容易被杀后台，切出去看一眼地图再切回来，蓝牙就断了，十分不稳定。我没有用App下载照片的用途，我唯一需要的就是这个App把手机的GPS数据传给相机，这样拍摄的照片就有位置信息，方便日后回忆。关于实现方式，我想了几种方案。第一个就是自己重新写一个App，虽然安卓的蓝牙相关API不好用，但至少是最稳定的。可是我无法解决三星杀后台的问题，更何况三星一直不舍得给电池，弄这么一个App常住后台，怕不是半天就给手机整没电了。Z8和Z9机身上有个10pin针脚，一番搜索之后发现这个10pin针脚可以用NMEA-0183协议给相机传输GPS，但问题有二：首先，这个10pin针脚不好买，好多快门线并没有连GPS的数据线，你把它剪开只会发现没有要用的线；其次则是国行系统在相机菜单内屏蔽了GPS设置，插上了10pin接口的GPS也无法启动，这是国内法律要求的。虽然淘宝上可以给相机刷地区，但我没找到公开资料，自己做不了。我有精神洁癖，所以不打算让别人远程到我电脑上给我的相机搞奇怪的东西。于是只剩下一种办法，利用SnapBridge的协议给相机写数据。好在我不是第一个觉得尼康App难用的，隔壁gkoh/furble利用M5Stack的设备针对各家厂商做了替代品，是基于ESP32的，虽然尼康设备的支持很有限，但社区已经基本上把握手和消息的格式都逆向出来了，唯一的问题在于这个项目用了NimBLE，它不支持传统蓝牙，因此无法完成尼康的配对。由于我并没有ESP32的开发经验，所以在购买ESP32和GNSS模块之前，我准备先在借助其他平台验证一下蓝牙握手的部分。概念验证一开始我想到了安卓，但安卓的蓝牙栈API实在是太糟糕了，从PoC的角度来讲，整理握手的流程被API搞得很零碎，反而让其他人摸不到头脑。相比之下，Linux的Bluez就好了不少。目前安卓和Linux Bluez（使用Kotlin编写）的代码可以在以下地方找到：安卓：https://github.com/hurui200320/nsg/tree/7bbe7a45f7ef3f0fd2dbe6772181e40c4fa149c7/androidBluez：https://github.com/hurui200320/nsg/tree/7bbe7a45f7ef3f0fd2dbe6772181e40c4fa149c7/kotlin-poc这两个代码都不算完整，但全都实现了完整的握手和下发时间以及位置数据，位置数据是随机生成的。下面来说说我测试过、能跑通的SnapBridge协议。智能设备蓝牙协议 时效性提示 以下内容纯靠社区逆向和我的探索及尝试。只保证在2026年7月上旬时有效，未来尼康可能会通过更新修改握手流程，因此不保证以下内容总是能用。建议首先做概念验证确保以下内容仍然可用。 尼康相机在菜单中对SnapBridge的叫法是智能设备，所以我的项目名字也选用了类似的命名方法：NSG，全称Nikon Smart GPS，但为了避免吃Nikon的版权炮，名字里没有用Nikon，而是只取了首字母N。智能设备首先需要配对，配对过程涉及BLE和传统蓝牙双栈，因此对于ESP32设备来说，你必须购买原版的ESP32，不能带任何后缀，什么S3啊P4啊C6啊这些全都是只有BLE没有传统蓝牙的。隔壁nRF52系列也说了硬件不支持传统蓝牙，就算你实现了传统蓝牙栈也没用。BLE UUID尼康相机的握手和数据下发主要依靠BLE，其中：相机的Service UUID：0000de00-3dd4-4255-8d62-6dc7b9bd5561握手（PAIR）用的Characteristic UUID：00002000-3dd4-4255-8d62-6dc7b9bd5561握手成功后写入智能设备名称（ID）的Characteristic UUID：00002002-3dd4-4255-8d62-6dc7b9bd5561写入TIME的Characteristic UUID：00002006-3dd4-4255-8d62-6dc7b9bd5561写入GEO的Characteristic UUID：00002007-3dd4-4255-8d62-6dc7b9bd5561相机的BLE广播相机在BLE广播的时候根据情况调整Manufacture Data，但总会宣告Service UUID。如果相机当前处于配对模式，则Manuf…

【随便写写】79 & 我买Z8了 & 春节后的摄影
type: item
date: 2026-07-01T13:44:00+08:00
description: 最近工作不是很顺利，但这次是因为公司快要倒闭了，已经发了解约通知，现在正在履行30天的通知期。但好消息是，我趁着618买了Z8。最近手头上也没什么能拿出来分享的项目，于是灵机一动决定，决定来闲聊一篇，顺便分享一下春节后回昆明以来拍的乱七八糟的照片。杂谈虽然买Z8的时候就知道公司要干不下去了，但那个时候还没有正式收到公司的解约通知，所以在预期上会相对好一些，而且正赶上618，虽然今年的打折力度感觉半死不活的，但最终我还是成功以18149元的价格买到了全新国行的Z8，正好尼康还有活动，618期间买Z8还送一个蒲公英的贴牌背包，就是外面印的Nikon，里面印的PGYTech。上淘宝看了一眼，这个包自己买的话得小一千块呢。倒也不错，再后来又给Z8配个了24-120 f/4 S的挂机头（6866元全新国行），可能是人生中的第一个S line镜头。再后来为了能录视频，又配了一张1T的努米诺橙卡（1560元，可是年初才卖一千多点的）。基本上这一套下来花了2万6上下，我觉得未来五六年的摄影应该是够用了，我也不太可能一拍脑袋就非得弄个什么400mm f/2.8，或者600 f/4什么的，所以不出意外的话，之后就要和手里这些器材做伴好长一段时间了。要说最近做的事情嘛，三月四月部署的本地LLM现在已经完全闲置了，毕竟当时只考虑了算力，没有考虑功耗。而且当时还是冬天的尾巴，就算他们满功率跑，也顶多是个电暖器。可是现在不行了，现在已经六月底了，两块显卡跑起来，用不了十分钟，屋子里就待不了人了。正好最近公司也不提供API key了，我得自寻出路，前阵子抛弃OpenRouter的时候发现了zenmux.ai（提示：这个是推广链接，不想要推广的话直接访问zenmux[.]ai），一开始是完全按照按量付费用的，因为我自己的用量不多，所以还负担得起。但公司不提供API Key之后，公司的开发对LLM的消耗量比较大，我就有点绷不住了，无意间发现了他们的订阅API，定为是个人开发和非生产使用，我直接梭哈了200USD的顶配订阅，现时大约每月配额在480USD，每周配额月110USD，每5小时配额26USD，好处是你可以随便调用模型，可以用Anthropic的，也可以用OpenAI的，国产模型也可以。公司那边我基本上是Sonnet打底，之前用公司的API都是Opus站起来蹬，可是自己的订阅蹬Opus很快就烧完了。所以Sonnet打底，然后Kimi K2.6作为调度器，调用MiniMax M3审阅（review）代码，然后调用Kimi k2.7 code按照审阅结果修改，直到m3给出approval。因为我对Python不是很感兴趣，所以公司的Python项目我不怎么关心代码，只要把功能做了，代码别堆成屎山就行了。自己用的话，我还是以Gemini 3.1 Pro作为对话的主力，Kimi k2.7 code和GLM 5.2作为编码，个人认为MiniMax M3的能力有点拉，同为1M上下文，GLM 5.2更好一些。在常规任务，例如Kotlin/JVM和安卓方面，Kimi和GLM不分伯仲，平时我还是喜欢Kimi一点，因为它听话，并且不会总想着一步登天。但最近买了个ESP32的设备，对于嵌入式开发来说，GLM 5.2的能力似乎更强一点，不过GLM 5.2总想着一步到位，所以用起来有点不是很顺手，最近逐步摸索，发现你得给它一个明确的目标，而不能像kimi那样问一步看一步。不过好在ESP32用C++，我不讨厌这门语言，就是太难了。自己写了一个周末，什么堆内存占内存虚函数全都回忆起来了，又因为对C++开发没什么经验，所以就让GLM自己写，保证能用。然后让Kimi对着git的修改一步一步解释给我听，不懂就追着问，一边问一边查文档。这两周下来感觉学了不少C++的新知识，感觉大脑都要升级了。至于为什么要做ESP32的项目，那还得从最近做的事情说起。五月净忙着给网站升级了，升级完了还魔改了一下主题，但毕竟主题是闭源的，我自己偷偷魔改也不方便发出来，所以就没发。六月买了Z8之后，除了拍照之外也做了一些周边的工作。例如在Fedora上想办法安装达芬奇，毕竟之前都买了正版的，又买了显卡，得用上才行。装起来有点麻烦，毕竟官方不支持Fedora，但distrobox解决了这个问题，为了更进一步简化安装过程，有人开发了davincibox，基本上就是轮椅。虽然也有坑，但无外乎就是不能用中文路径，更新distrobox的时候会导致正版验证失效，得先取消激活才能更新。整体也没啥好写了。而另一方面则是在研究怎么给Z8加GPS，原本想用机身自带的10pin接口，但后来发现国行系统直接屏蔽了GPS菜单，你插上GPS也启动不了对应的功能。所以国行就只剩下SnapBridge一条路了。于是我就想，索性买个ESP32来…

【歪门邪道】博客升级、容器化、PHP 8.3
type: item
date: 2026-06-01T11:23:00+08:00
description: 博客自2017年独立设站以来，历经几次更新。最近一次还是2023年，从Debian换成了Ubuntu 2204，后来又升级到了2404。那个时候lnmp脚本还没卖给国内的公司，脚本也没有挂上后门，于是就一直用到上个月。大约是4月底，Ubuntu 2604 LTS发布，我开始盘算这次的升级。确定升级方案由于Typecho一直更新缓慢，所以我的服务器每次更新妥当之后也就没动过。升级前用的是typecho 1.2.1和php 8.1。前阵子typecho突然发布了1.3.0，但这次更新包含很多破坏性修改，按semantic versioning来说不应该继续沿用1.x版本。我之前试过更新，结果更新之后主题不兼容，导致网站爆炸。幸好服务器和数据库都有快照，分别恢复之后继续如常运行，后来为了缓解xss攻击的隐患，我在垃圾评论检查的插件中配置了一些规则，虽然不能完全防止xss攻击，但至少能防住一些靠复制粘贴搞事情的人。前几天日常检查的时候发现我这个主题难得更新了，这次更新适配了typecho 1.3.0和php 8.3，于是想着要不要就此机会升级一下服务器的系统。虽然我自己平时用OpenSUSE风滚草和Fedora，但服务器上我的日常之选还是Ubuntu LTS，主打一个更新方便，支持周期长。但那是2404到2604的升级路线还没有发布，要等2604.1发布之后才行。而另一个迫在眉睫的问题在于，lnmp脚本已经不能使用了，要升级服务器必须得自己搞一个替代品。很幸运的是，现在的我比建站时的那个17岁小伙子已经进步了不少了，有了更多的见识和经验，即便我不会写php，也能搭建出一套可持续的部署方案了。鉴于我写了那么多年Java，谈到服务器部署，自然首选是容器化。目前网站只有一台服务器，所以大可不必上什么docker swarm甚至k8s这种东西，为了确保配置能够追踪，我选择在私有repo上存储docker compose的yaml文件。这样未来我做的每一次修改都可以追踪并记录原因。同时未来迁移服务器的时候也可以直接克隆后部署，不必考虑一套配置重复写好几次的事情。另外容器化部署的好处就是不挑系统，因此未来可以直接升级后续的LTS，或者我要是突然来了性质，重装个别的系统然后重新部署docker compose，也是轻而易举的。因此正式的升级路线就确定了：重装到Ubuntu 2604 LTS使用容器化部署PHP升级主题和typecho升级到PHP 8.3虽然PHP 8.3已经结束支持了，到2027年年底，安全支持也要结束了，但这也没办法，主题还在用老的jQuery呢。先把服务器整明白了，后面再慢慢修改主题。容器化部署PHP一开始我打算每个网站一个独立的nginx + php-fpm，最外层在主机上用Caddy做反向代理。这样对于现存环境的兼容性是最高的。但想来想去总觉得别扭，一来是php不能顺利复用，二来要配置的东西重复性比较高，第三就是尽管Nginx很高效，但我并没有真正理解过它那个难写的配置文件，大部分时候都是照葫芦画瓢，能用就行了。后来请LLM评论我的计划时，LLM提到Caddy也能配合PHP使用，我喜出望外。搜索了一番发现，Caddy不光能和PHP一起用，对于typecho伪静态的支持是开箱即用（Caddy2），不需要配置什么rewrite规则。此外使用Caddy还有一个好处，就是它能够自动处理TLS证书，不需要我手动每年更新，也不需要我再花钱买专门的TLS证书了。于是根据Nginx的配置写了Caddyfile，根据旧的php配置（主要是php.ini和php-fpm.conf）编写新的php配置。Caddyfile的编写其实还挺简单的，由于不需要处理rewrite之类的东西，并且caddy自带了对php fastcgi的支持，因此不停include的nginx配置文件就简化成了这一小段：skyblond.info, www.skyblond.info { # 网站挂载到容器的/srv/目录下 root * /srv/skyblond.info # 启用gzip和zstd压缩 encode gzip zstd # 配置PHP，超时时间匹配nginx配置 php_fastcgi php-fpm:9000 { dial_timeout 30s read_timeout 5m write_timeout 5m } # 允许caddy返回静态文件 file_server # HSTS header，本站很久之前就加入HSTS preload列表了 # 这个header告诉浏览器skyblond.info以及所有子域名必须强制使用https header { Strict-Transport-Security "max-age=63072000; in…

【歪门邪道】本地部署LLM的初尝试
type: item
date: 2026-05-01T10:54:00+08:00
description: 四月初谷歌发布了Gemma 4系列的开源模型。先前我对开源模型其实一直没什么太大兴趣，因为大部分都可以在OpenRouter上用到，价格远比自己买显卡便宜。但看到网上那么多人说Gemma 4这么好那么好，我寻思，这我得尝尝咸淡。于是陆续下单了两块AMD 7900XTX，尝试了在本地部署大模型。Gemma 4虽然已经过去了一个月，但我依旧记得当时清明假期看到Gemma 4发布的时候，大家对它的赞不绝口，同时模型的尺寸也从遥不可及变成了使使劲也能用。之前我对于开源模型一直没有太大的兴趣，主要是因为他们太大了。比如Qwen3.5 397B A17B，写代码很好用，但即便是4比特的量化，光是模型自己就要吃掉大约200GB的内存或者显存。MoE结构当然有优势，即便不能全部装进显卡也能取得比较快的计算速度，但就算这样，你仍然需要显存+内存的总量大于200GB，更别说还有用于上下文的kv cache。我这屋里所有设备的内存加起来还不到200GB，更别说插到一个主板上了，更何况现在内存价格那么贵，曾经600块钱的32GB内存我嫌贵，现在一条涨到3000块还买不到，我真的悔不当初。但Gemma 4不一样。谷歌给出的口号是“Byte for byte, the most capable open models”，这个系列中最大的模型是31B，是个稠密模型，其次是26B A4B，这个是混合专家（MoE）模型。就算是我那个64GB内存+8GB显存的3070笔记本也能挑战一下，虽然只有惨兮兮的1 token/s，但确实让我领略到了这个模型的能力，它和我几年前尝试过的llama 2 70b确实不一样，进步很大（废话）。于是想要更快更好地运行本地模型的想法在我心中不断酝酿着，更别说自己部署还能体验到各种uncensored模型，这种无（弱）对齐的体验简直是任何云服务都无法提供的。当然，最大的推手还是因为谷歌的AI Studio一直不提供付费的Gemma 4 31B访问，以至于我有钱没地方花；免费的一直有额度限制，同时谷歌也明确所有数据都会拿去训练。AMD Yes！在酝酿了一周后，我先下单了第一块7900XTX。为什么是AMD呢？因为隔壁英伟达买不起。比如说同样为24GB显存的RTX 5090D v2，阉割过不说，这一张卡竟然要两万！而没有阉割的5090，虽然有32GB显存，可是价格三万，我实在是家境贫寒。至于我这块蓝宝石的7900XTX白金版，24GB显存只要6000块，两块也只要1万2，这还要什么自行车？更别说Linux上面对AMD显卡的支持是开箱自用。虽然ROCm官方只支持一些商用Linux系统，但官方也提供了基于Ubuntu的docker容器，虽然我不喜欢Ubuntu，也不会装它作为我的主力系统，但有了docker，我可以无痛把显卡透穿给容器，完全不需要在主机上安装什么依赖啊闭源驱动什么的。尽管性能不比N卡，可是省心啊。至于一周之后为什么下单了第二块显卡，那主要还是因为显存不够。一开始我以为只要把模型塞进显卡就好了，但其实这只是一部分，另一个大头是kv cache。KV Cache现代大语言模型普遍以注意力机制为基础，而大语言模型的输出又是一个字一个字往外蹦。因此当预测第N个字符的概率（logits）时，你需要将前面所有字符进行计算。为了防止计算量爆炸，人们在实现时普遍采用了一种缓存机制，即预测第N-1个字符的时候，就把注意力机制的K和V矩阵保存下来，因为这两个矩阵在不超过上下文长度的情况下是只增不减的。 这里严重简化了注意力机制的原理，请不要把这里说的当成学术入门。 简单来说注意力机制有三个矩阵：Q、K和V。他们都是由同一个输入矩阵X根据不同权重计算出来的。这里说是矩阵，其实可以理解为向量，例如X=(x1, x2, x3, x4, ..., xn)，这里的xn可以理解为第N个token对应的embedding向量，为了计算过程能够发挥显卡的能力，我们不会挨个向量进行计算，而是将向量打包成矩阵，利用线性代数帮我们自动做for循环。其中Q矩阵代表了当前的输入要查询什么样的信息，是一种需求。例如当前token是“他”，那么这个q向量就包含了对这个人称代词解引用的需求。而K矩阵则代表了每个token包含的信息的标签，例如之前一个token看着像人名，那么这个token生成的k向量就会标明自己是个人物。而V矩阵代表这个token实际包含的信息，比如文字里这个人叫“踏三山游五岳，恨天无把恨地无环，代管天津及周边各县真正大英雄王斯文”，那么这个v向量就会包含王斯文这个信息。注意力在计算的时候先要计算Q和K的乘法，这相当于用当前token的需求Q去筛选已知信息的标签K，得到的结果，某一行越大，说明这一行对应的信息就越有可能解答Q的需求。在得到这个筛选之后，再去和V…

【歪门邪道】使用LLM翻译超时空辉夜姬轻小说
type: item
date: 2026-04-01T09:59:00+08:00
description: 上个月月初看了超时空辉夜姬，非常喜欢，喜欢到每天都在b站上看各种解析和二创。听闻官方还有轻小说，于是便想办法来看。可是我一句日本话也看不懂，这怎么办呢？没事，已经2026年了，我们有LLM。前言也许是受到电影的鼓舞，我3月6号周五晚上看完的电影，紧接着那个周末就把小说给翻译了。以前我从未想过，一句日文都看不懂的我甚至还能以一种比较有参与感的方式翻译一本小说。尽管一开始我想到了LLM会让翻译工作轻松不少，但我确实没有期待什么质量。但真正做完了才知道，虽然远不比彩叶，但我也能做到我曾经没想过或者不敢想的事情。我可太喜欢这部电影了。买书所谓万事开头难，由于小说是日文的，并且目前只在日本发行，我又等不及了，所以搜了全网售卖日文电子书的网站。找到了，但全都是日文，我看不懂。最后我想起来乐天kobo，于是就跑到上面搜了一下。好消息：能买坏消息：日区是独立管理买之前网页上信誓旦旦地说提供Adobe DRM保护的EPUB，这种通常是提供一个acsm文件，然后内容服务器会根据你阅读器的密钥生成一个加密的EPUB，理论上只能在你导入acsm文件的阅读器上使用，因为只有它有密钥。但实际上Calibre的插件就可以轻而易举地破解——Adobe只提供加密服务，但并不控制最终设备，因此只要能够通过API模拟出设备的注册过程，那用我们自己持有的密钥解密自己购买的电子书，那不是轻而易举？只可惜我买之后才发现，整个kobo日区都不提供下载服务，要么直接从电子书里下载，要么下载app到手机上看。好在天无绝人之路，Kobo PC版还可以下载。虽然下载的是kobo加密的格式（Kepub），但Calibre照样有破解的插件。第一次解密发现怎么解出来全是乱码，我还以为新书用了新的加密方法，插件落后了。后来搜索了一番才只要，要把Kobo PC关掉才行。总之，我们得到了心心念念的drm-free epub文件。I have a plan!一开始我打算在OpenCode中操作。简单来说OpenCode是一个利用LLM进行编程的工具，它为LLM提供了一个环境，其中包含各种与文件和终端互动的工具。最近我司在推行这个工具，也被迫用了一段时间，感觉还行，但还是离不开人的审核。我原本打算直接让它把文件中的日语内容翻译成中文。后来觉得有三个问题：编程用的Opus 4.6或者codex 5.3都是为了编写代码而优化的，他们也许能在OpenCode中如鱼得水，但或许并不擅长翻译这类具有文学性的工作我希望大部分更改是reproducible的，也就是说我搞砸了，可以重新运行代码恢复到某一个步骤。由于LLM的随机性，我不可能做到完全的可重复，但能做一点是一点嘛Opus和Codex太贵了，虽然有公司给的key，但这毕竟是个人项目，不能用公司的资源。我尝试了GLM-5，整体算是堪用，写不出kotlin native的代码风格，更像是用kotlin写Java，整体不是很糟糕，但也没有让我很想用基于以上理由，我选择在IDEA中新建项目，将大部分操作编写成可重复运行的代码。这样不光实现了可重复性，还变相增加了稳定性。本文的代码全都是我自己手写的，但写完之后有让GLM-5检查。由于版权原因，本文尽可能不提供对小说内容的直接引用。因为我没有处理DMCA投诉的经验，所以多一事不如少一事，我希望我的博客能长存八千年。拆EPUB首先是拆解EPUB。众所周知，EPUB其实一个具有特殊格式的zip压缩包。理论上来说，想要解包的话直接把epub的后缀改成zip就可以用随便什么压缩工具解压了。但我还是想用代码处理：fun unpackEpub(epubFile: File, outputFolder: File) { require(epubFile.exists()) { "EPUB file not found: ${epubFile.path}" } if (!outputFolder.exists()) { require(outputFolder.mkdirs()) { "Cannot create output folder: ${outputFolder.path}" } } ZipInputStream(epubFile.inputStream()).use { zis -> var entry = zis.nextEntry while (entry != null) { val newFile = File(outputFolder, entry.name) // zip slip detection, to prevent entry name contains something like ../../../etc/something val canonicalDestPath = newFile.…

【随便写写】78 & 2026春节摄影
type: item
date: 2026-03-01T16:52:00+08:00
description: 突然想起来三月份的更新还没写，但好在春节的时候回家拍了拍照片。于是赶忙写一篇。今年春节一如既往地回到了家，也一如既往地没能完成什么事情。今年也带相机回家了，但架不住冬天太冷，没有拍星星，只拍了拍鸟。在家拍拍因为顾虑室内外温差而导致水汽在镜头内部凝结并导致发霉，因此春节这几天并没有频繁地把相机拿出来。但尽管如此，还是在家拍到了一些鸟，只是因为黄昏时刻光照不足，所以大部分都是废片。珠颈斑鸠在北京算是非常常见的鸟类了，而且和昆明的斑鸠不同，北京的斑鸠一点也不警觉，所以你可以看到我可以优哉游哉地近距离拍摄他们。乌鸦当然也是常见鸟类。这张照片的灵感源自于前些年用手机+望远镜拍到的一张黄昏时逆光的小鸟。因为是逆光，所以背景的天空是棕黄色的，而小鸟则因为光线不足而呈现黑色，就像剪影一样。那天在家里正好看到远处的建筑上有几只乌鸦，因此就想复刻一下当时拍的照片。但是很遗憾的是我和乌鸦之间有很多树枝，他们造成了如图所见的虚影。但整体大约就是这个效果了。北京植物园第二天和朋友约了去北京植物园。因为根据我在昆明和香格里拉的经验，想要遇到丰富的鸟类就得去当地植物园。但是北京毕竟是北方城市，大冬天除了松树一类的之外，全都秃了。难怪先前一直不喜欢冬天——太单调了，太无聊了。这么一看我还是更喜欢昆明的冬天，想起来1月中旬有天下午，我在拿快递的路上路过一个绿化带，不禁感叹这个时间还能看到书上挂着绿叶。到了2月初的时候已经有粉色的花朵挂在树上了（我一直分不清桃花樱花和梅花，所以这里就叫它粉色花朵好了），五颜六色的冬天也十分让人喜爱。言归正传，这次去植物园倒是多多少少也有些收获。我记得之前在昆明拍到过这个鸟，是北红尾鸲的雌鸟。我就想这个鸟怎么分布这么广泛？到Bird Of The World上一查，原来人家是候鸟，并且有两个亚种：Phoenicurus auroreus auroreus（指名亚种）：繁殖区（夏季）在西伯利亚中南部（从贝加尔湖以西起），蒙古北部和东北部，向东至黑龙江流域和乌苏里江流域，向南至朝鲜半岛北部和中部，以及中国东北地区（向南延伸至河北和山东北部）。非繁殖区（冬季）在朝鲜半岛中部和南部，日本（本州中部以南），台湾，中国东南部（河南东南部和安徽以南），海南岛以及越南北部。Phoenicurus auroreus leucopterus（西南亚种）：繁殖区（夏季）在中国中部和西部（青海东部，甘肃西北部和陕西，向南至西藏东南部和云南北部）。非繁殖区（冬季）在喜马拉雅山脉东部，向东至泰国北部和中南半岛（印支半岛）北部。所以同样是北红尾鸲，我在昆明看到的应该是西南亚种，而这次在北京看到的是指名亚种。这两个亚种的分布区域并不重叠，因此算是两个不同的群体。大自然，真神奇啊。黑尾蜡嘴雀，这是以前没见过的鸟。查阅Birds Of The World之后发现它的群体分布和刚才的北红尾鸲类似，同样有两个亚种。这个是Eophona migratoria migratoria亚种。而云南同样也有分布，是Eophona migratoria sowerbyi，可惜我还没见过云南这边的亚种。这个是锡嘴雀。一开始我以为是黑尾蜡嘴雀的雌鸟，因为他们一起觅食，并且这只颜色比较淡，但后来查了AI才知道认错了。至于为什么锡嘴雀会和黑尾蜡嘴雀一起在地面上觅食，Gemini说这个叫“冬季混群（Mixed-species foraging flock）” 和 “生态位分化（Niche partitioning）”。所谓冬季混群是说，在冬天，鸟类没有繁衍的任务，并且食物变得稀少，因此他们就不再争抢地盘。而混群则是鸟类的一种常用生存策略，比如城市中流浪的宠物鹦鹉可能会和麻雀一起行动。对于体形和食性都比较相近的鸟类，他们会共同行动，这样就能借助数量优势来提前发现猛禽，从而提高群体的生存率。同时出于食物稀少、难以寻找的压力，群体觅食可以提高找到食物的概率。而生态位分化则可以减少他们互相冲突的情况。锡嘴雀的嘴部鸡肉非常发达，因此可以咬碎非常剪影的果核，这样一来即便和黑尾蜡嘴雀一同行动，黑尾蜡嘴雀也咬不开锡嘴雀的食物。最后就是鸳鸯了。在植物园北园的水域里，鸳鸯和绿头鸭都有。这么一说这还是我第一次拍到鸳鸯。虽然在传统文化中，鸳鸯一直是夫妻和美的代表，但其实鸳鸯的脾气一点也不好。我甚至还看到了绿头鸭抢了鸳鸯的食物而被鸳鸯驱逐的画面（很遗憾，没拍到），而鸳鸯的体形明显比绿头鸭要小。结语以上便是春节期间在北京的摄影成果了。冬天一冷就什么都不想做，不想做事情就天天躺在床上刷手机，刷到假期结束又在懊悔为什么自己虚度光阴。好在我已经回到了昆明。暖和的天气至少不会想要让人虚度光阴。那么这篇文章大概就是这样了，我们下一篇文章再见 :)-全文完-

【代码札记】改进电码转换程序
type: item
date: 2026-02-01T08:19:00+08:00
description: 早年间写过一个utf8-ctc，用来将文字转换成中文电码表示，当时还写了一篇文章来介绍它的基本原理。但当时有几个东西让我耿耿于怀：压缩、加密和校验。终于在机缘巧合之下，本文将记述如何改进这些问题。前言简单来说，utf8-ctc这个程序已经能够做到将任意输入文本转换成一系列中文电码，以便使用者可以将其方便地（相比于base58）抄写在依赖光学进行阅读的物理媒介上（例如明信片或信纸）。在遇到中文电码表之外的字符时，这个程序可以自动以utf8编码将其转换成字节数据，然后利用base9992表示。在这个过程中，程序还会尝试使用deflate压缩算法进行压缩，如果压缩后的结果更短，则使用压缩后的结果，进一步减少用户需要抄写的电码数目。同时在输出前，还加入了对称和非对称的密钥生成机制，以密钥作为CSPRNG的种子将结果分块进行置换加密（Transposition Cipher）。但目前有三个问题：Deflate压缩算法在长文本的情况下效率不佳，而对于中文中夹杂的外文短语，几乎大部分场景下未压缩的数据量都更小一些。加密算法实质上是置换加密，虽然程序中有估计拖延时间的设计，但本质上多次置换和一次置换没有本质区别。无法校验用户的输入，因此用户输入错误一位或几位数字，程序无法判断。最好情况是对应的字变成乱码，最坏情况是utb8字符解码失败，导致整块外文引用无法解析。更换压缩算法最开始由于Java标准库内置Deflate算法（zip同款），所以我当时毫不犹豫地就使用了这个算法。但随着后续测试发现，对于中文夹杂的外文短语或emoji，由于其数据量非常小，通常不到50字节，在这种情况下几乎任何常规的压缩算法都难以发挥作用。因此大部分时候我们需要用base9992表示原始数据。而当文本中出现成片的外文引用，例如引用了一整段外文，此时的数据量使使劲能达到大约1KB的量级，此时压缩算法能够略施拳脚。而考虑最坏情况，比如一个外国人输入了一段从头到尾都没有中文的文字，那这种情况对于压缩算法来说是最好不过的了。我选取了三组数据进行测试，第一组是一段英文文字，第二组是一段日文文字，第三组是电影利兹与青鸟的台词。 DeflateLZMA2174B115122393B22122829KB102189517可以发现在文本量比较少的时候，选用LZMA2算法会导致我们比使用Deflate时多产生7个左右的字节，这对应大约4到5个电码。而对于长文本时，我们能够节省超过500个字节，大约对应300个电码。由于能够使用的符号有限，程序中只能选取一种压缩算法。经过一番思索，我认为能够在长文本上取得较好压缩效果更为重要，这样能够在处理长输入时尽可能减少用户需要抄写或处理的电码数量。其实在选择LZMA2算法之前，我更中意的是zstd算法，可惜zstd并没有纯Java实现，因此它的依赖会对便携性产生影响。由于符号有限，9992和9993分别表示未压缩的UTF8数据的开始和结束，而9994和9995表示压缩的UTF8数据的开始和结束，此外我便找不出其他可以挪用的成对的电码了。因此我不得不将Deflat替换成LZMA2，这也意味着如果有人用新程序解码了旧程序压缩的数据，由于压缩算法的变化，新的程序会直接报错，导致所有非中文段落无法解析。更换加密算法原本的置换加密就是图一乐。置换加密有点像是y=kx+b：你可以做很多次置换迭代，相当于多次洗牌，对应地，你可以在一元一次方程上迭代多次y=k( k( k ( kx + b) + b) + b )+b，但如果你化简这个式子，你会发现最终可以用一套新的参数替换这一系列迭代y=k' x + b'。这对于置换加密也是类似的：你可以多次洗牌，但本质上迭代N次和迭代1次并没有对攻击者造成实质性的困扰。由于明文本身没有变，只是打乱了顺序，因此攻击者可以根据统计学数据来做类似小学时候看词造句这样的攻击。虽然这种方法无法解析出抽象的句子，但你总不能从头到尾句句抽象吧。因此我们需要一种更安全的加密手段。但由于我们的输入输出是电码，并不是传统意义上的二进制数据。如果我们将输入转换成utf8编码进行加密，那样又会破坏使用电码的本意。因此我将目光转到了ChaCha20，TLS1.3的核心标准之一。ChaCha20本身是一个加密算法，它将明文与密钥流进行XOR运算来加密，其设计方案具有诸多特点，这里就不多赘述了。我们的问题是如何将电码这种非二进制数据利用ChaCha20进行压缩。如果从数学的角度入手，二进制的XOR或许可以被加法和取模替代。假如我们有个密钥流，它的元素是0000到9999的数字，那么我们就可以这样加密：enc = (input + key) % 10000而解密时：plain = (enc - key + 10000) % 1000虽然没有xor那么简洁对称，但…

【随便写写】77 & 欢度元旦 & 2025年终总结
type: item
date: 2026-01-04T23:37:00+08:00
description: 原本一月份是有预订的更新的，但是想着既然都新的一年了，总该写点总结。可是从12月底一直到元旦假期结束，我老实想着，却从来没开始写。因为最大的问题是不知道写点啥。但是元旦假期都结束了，总不能再拖了吧。流水帐总结翻阅了一下以往的记录，2024年没写正经的年终总结，而是把2024年拍的照片发了出来。今年当然也没落下摄影这个爱好，虽然我平日里不爱出门，不喜欢旅游（除非不花钱而且够档次），但2025年还是增加了出门的频次，并且还特意去了一趟香格里拉。并且经过大约一年的摸索，也终于得到了一个稳定处理照片的工作流。除此之外今年也试图涉足了一下星空摄影，买了赤道仪，骑着自行车在夏夜拍星星，只不过因为设备不够昂贵，并且没有覆盖范围足够远的交通工具，所以没能拍到效果不错的星空。不过花钱租远程天文台倒是取得了不错的结果，就是太贵了，家境贫寒，告辞。在游戏方面我今年也有进步，虽然switch真是一点没碰，但好歹和朋友联机玩了一阵Minecraft（还顺手水了一篇文章），年末又买了逃离鸭科夫，虽然我强烈质疑官方运营创意工坊的水平，并且强烈要求官方关闭创意工坊，让玩家自寻出路，但除了mod方面的问题，这个游戏还是好游戏，像我这种反应慢又菜的精神老年人也能乐在其中。得益于社区开发的联机mod，我和朋友也从中获取了不少的快乐。在技术方面，由于上班导致我没有太多精力可以在尝试杂七杂八的事情上，但这一年还是尽力尝试了一些新事物，例如在Unraid上使用ZFS，尽管初始设置并不完美，但这个元旦假期我也做了一些调整，花了好多不必要的时间在上面。还有我为了遏止BT吸血客户端做了一些努力。至于Kindle越狱，一开始我确实是奔着折腾去的，但是最后发现kindle的性能实在是太差了，只能看书。但看书也有看书的好，今年看完了狼与辛香料小说的正传，看完了终将成为你的漫画版。平日里狼与辛香料能让我专注于工作之外的事情，是一种十分难得的放松。但工作上的压力大到我读不进去书的时候，终将成为你这个系列漫画给予了我走下去的力气。这就是百合漫画的力量吗，太棒了。生活与工作自从2024年中搬到昆明，截至2025年底已经住了一年多了。好多生活习惯也已经成为日常惯例，几乎不需要思考就可以完成每日的吃穿用住。但随之而来的就是生活变得无聊，而工作来带的压力无处消解。也正因如此，消费主义趁虚而入，大约我每个月都得花点钱买一些新奇的玩意解解闷儿。今年的大额消费差不多就是尼康的180-600mm镜头，和在溥仪眼镜配的两幅眼镜。说起配眼镜，起因是因为原来的镜子镜框坏了，加上本身度数不准，我就想找个高档的眼镜店配个高点的。早年间在北京的时候去Alexa配过眼镜，一套下来7千多，我寻思这溥仪眼镜8千怎么还下不来呢？确实下来了，结果被导购一忽悠，又加了一副太阳镜。说是免费送一副4000元以下的镜框，结果哪知道我这慧眼识珠，一睁眼就拿了一副六千多的镜框。羊毛没抓到，自己还贴了2000多进去。除此之外就是每月买的一些小玩意儿了，比如新的显示器，一套校色仪（屏幕+打印机），一个比较专业的家庭打印机（爱普生L8168），星野赤道仪，碳纤维三脚架，kindle paperwhite 6，卡式磁带播放器这些。当然，我也反思过我的消费习惯，每个月花钱太多不好，不过转念又一想，这些也不算是吃灰浪费。挣钱早晚都要花，早花早享受嘛。不然死了留下一堆钱，我又没儿没女，留给谁呢？当然，花钱也不是生活的全部，除了上一节提到的各种科教文卫活动，我想起来这一年还和朋友一起看了一些影视作品。其中印象最深的还是芙莉莲和你的颜色。当时看完之后拿起手机就写了小作文，只不过碍于体量，只发在朋友圈了。我想既然都写了，还是应该和大伙分享一下。所以正好就在这里放上来吧。首先是芙莉莲的观后感：今天把Frieren动漫看完了，感觉做的真棒。不敢相信在京阿尼都能拉坨大的的时候还能看到这么好的动漫。（别问为什么打英文，问就是三星输入法打不出正确的词，不想挑字）既然都是寿命论，那我看过的也就只有狼辛和小林家的龙女仆了。目前正在看狼辛的小说，因为已经完结了，再续的羊皮纸那就之后再说了。龙女仆的漫画之前也看了，不过单行本一年一本等不起。现在也打算去买Frieren的漫画。感谢台湾电子书商，使我钱包旋转。我认为单从寿命论的角度来看，Frieren的氛围应该介于龙女仆和狼辛之间。龙女仆里提到过即便是托尔他爹也只能让小林活到自然死亡，但从漫画剧情来看，作者似乎并不太在意寿命的问题，故事的重点比较关注当下的冒险，非要说的话那就是享受当下的生活。而狼辛虽然结尾俩人过上了幸福生活，但就目前的进度来看，其实二人的旅途中总是蒙着随时要离别的悲伤，和二人心照不宣极力避免分别的异样。虽然这种场景能让二人经历的每一场冒险都显得尤为珍贵，但说实话，要不是我知道结局是好的，我真会越看越着急。Fr…

【随便写写】76 & 11月拍的照片
type: item
date: 2025-12-13T22:52:00+08:00
description: 其实本来早就想写这篇文章，但是因为11月底不幸感染了甲流，劲儿还挺大，给我干发烧了。所以一直拖到现在才开始写。这篇文章主要分享我11月在公园拍的一些照片。前言11月整体比较无趣，因为工作上比较心力交瘁，每天靠着百合漫画度日（终将成为你真的太好看了，我太喜欢了，感动到落泪）。而周末的两天只能说算是补偿精神，还没真正开始享受周末，它就结束了。想了许久上四修三的打算，最终也没能跟老板提。但月底的时候朋友路过我这里，那两个周末可真是太不一样了（要是第二个周末朋友没把甲流传染给我就更好了）。要不说呢，这日子怎么会跟谁过都一样呢？纵观整个11月份，一共就出门了两次，两次去的还都是同一个公园：渔浦寒泉湿地公园。虽然不知道名字为什么这么叫，但是它地理位置偏僻，风景还算是不错，偶尔还能看到一些鸟，算是还不错的去处吧。第一次第一次是本着探路的性质去的，虽然带上了相机，但是没指望拍出些什么东西。不过话虽如此，还是拍到了一些不错的照片。首先是在一个栈道上，我远远看到树上有鸟，虽然听到叫声就知道是老熟人（黄臀鹎）了，但是这次老熟人在吃树上揪来的果子，还是有点新奇的。顺着栈道继续走，就能看到一池子莲花。我问了Gemini 3，它说这是睡莲。因为我实在是不怎么认识植物，所以它说是就是呗。上图是我用600mm当微距拍的。虽然很近，但是感觉细节上还是差了一点。尼康的刀法也不比老黄差啊。这一张可能是我最喜欢的几张之一，我趴在栏杆上使用了一个相对低的角度拍摄，拍摄的时候就刻意让水下的倒影和水面上的花朵尽可能一致。而且这是整个池子里唯一一朵粉色的睡莲。等我们一周之后再去的时候，这朵花就已经谢了。在发现水面倒影的好处之后，我又尝试拍了几张手段类似的照片。这一张是白色的睡莲，后期时我故意将水面倒影提亮了。我朋友建议将这张照片竖着裁出来（后面一张），但我个人认为还是横着的好看（前面一张）。我觉得放的太大了，会有一种傻大黑粗的感觉。不过我也拿不准到底哪个更好一些，所以就都放出来了，读到这里的朋友们可以在评论区留个言，说说看你觉得哪种裁切好看一些。关于在LrC中同一张照片按照不同方式裁切，网络上似乎并没有一个同一的答案，至少我看到好多人在一个reddit帖子里说了各种不同的方案。我的方案是调色完成后，创建一个虚拟副本，这样一个按照横屏切，另一个按照竖屏切。这几位也是老朋友了。分别是普通翠鸟，白鹡鸰和小白鹭。白鹡鸰和小白鹭似乎比较常见，我们第二次去的时候就没有看到翠鸟。等等，你是？夜师傅？公园中间有一片湖，湖中间有个小屋。这一次看到一个疑似夜鹭的鸟在里面睡觉。第二次的时候我们看到黑天鹅在围栏外面睡觉。以上就是我第一次去公园探路时所拍到的照片了。第二次第二次是和朋友一起去的。我一个人出行的时候，大部分情况都是我一个人走的飞快，像是在完成什么走路任务之类的东西。而两个人的话，走走停停，要比我一个人逛公园细致很多。所以这一次拍到的内容也更丰富一些。一开始我还以为是大花蚊子（夜鹭幼鸟），但秉持着严谨的态度询问过懂鸟之后，才知道池鹭。在栈道上寻找鸟的时候忽然看到一只鸟飞过来，落在了不远处的岸边。我赶快调整角度拍摄。拍完之后却发现：这谁啊？我咋一点都不认识啊？回家查了一下懂鸟，说是扇尾沙锥。喜加一。拍完扇尾沙锥，我一个回身，走到了另一条栈道上。我一看，这又是谁啊？回家查了懂鸟，说是白腰草鹬。又是一个加新。因为很小只，而且离得很远，相机的自动对焦根本不好用。而且这只鸟动起来非常快，颇有白鹡鸰的风范。回家查了一下，您猜怎么着，人家是黄头鹡鸰，确实跟白鹡鸰论亲戚。来都来了，那就再拍个莲花吧，不过这朵有点老了。只胜在阳光的角度还行。老朋友了，就不多介绍了。近距离欣赏小䴙䴘。第一次去的时候也见到了，但是因为光线角度不对，照出来全是黑的。这次正好光线合适，就拍下来了。本来还想用高速连拍拍一下它入水捕食的动作，可惜我这机器缓存太小，而它的动作又难以预判，折腾了二十分钟也没拍下来。虽然花了很多努力却得不到想要的结果是一件很令人沮丧的事情，但我仍然要强调诱拍是每一个鸟类爱好者都应该人人喊打、积极反对并积极制止的行为。出片当然是一件好事，但我拍鸟是因为我喜欢看各种各样的小鸟，如果出片是建立在伤害他们的基础上，那这个片也就没必要出了。蒲公英，被树林间漏下的阳光照亮。同样因为不知道是横屏更好还是竖屏更好，所以就两者都尝试了。后记以上便是本月的更新了，看起来比较水，实际上也很水。值得一提的是，11月底我从法国订了一台很普通的磁带播放器（类似于早年间的磁带随身听）。我知道他们的音质当然不如卡座播放器好，但是现在想要找到高质量，还在产的磁带播放器可太难了。虽然可以收老家伙的二手，但我认为这样终究是不可持续。虽然磁带早就被时代抛弃了，但是看到人类曾经做到登峰造极的东西就此消失，还是多多少少有些难过。扯远了，就这个磁带播放…