Author: woaipingpu

  • 配置 GitPod 使用 GPG 签名 git commit

    GitPod 是一个基于浏览器的在线 IDE,它可以直接在 GitHub 上打开,无需本地安装任何软件,只需要一个浏览器就可以进行开发。GitPod 会自动为你的项目创建一个 Docker 容器,然后在容器中运行 VS Code,你可以在浏览器中使用 VS Code 进行开发,开发完成后,GitPod 会自动关闭容器,不会占用你的资源。 最近经常以本地 VS Code 的方式开发,但是在提交代码的时候,发现 GitPod 无法使用 GPG 签名 git commit。本文介绍如何配置 GitPod 使用 GPG 签名 git commit。 导出 GPG 私钥 首先列出你的 GPG 私钥: 然后导出 GPG 私钥: 以上命令已 macOS 为例,在 Linux 上可能需要使用 base64 -w 0。 输出的一长串结果就是你的 GPG 私钥,将其复制到剪贴板。 添加到 GitPod 环境变量 在 GitPod 中,点击左侧的菜单,选择…

  • Moonlight与Parsec简单对比

    不在家的时候为了打游戏,尝试远程串流方案,使用 MacBook 远程控制家里的台式机打游戏。之前尝试了多款国产远程桌面软件,效果都很差,日常办公可以,但打游戏卡的不行。最近又尝试了 Moonlight 和 Parse,发现体验还不错。 环境 在遥远的两地,并且受控方和控制方都没有外网IP,只能借助内网穿透的方式。 Parsec 之前以为至少需要一方有外网IP,但后来发现也有一定概率可以内网穿透成功(无需借助额外工具),成功后即可实现P2P直连,速度非常满意。 Parsec 做了很多优化,例如画面在相对静止的时候可以降低帧率,并且对于游戏做了很多优化,尤其是鼠标方面,感觉和在电脑前几乎没有区别。看了记录有30ms的延迟,非延迟敏感的游戏非常足够。 但 Parsec 的内网穿透非常玄学,有时候可以打洞成功,但大多数时候不行,即使反复尝试半小时,均报6023错误。 尝试使用内网穿透工具 frp,将官方宣布的几个UDP端口都映射出去后,仍然无法成功,查看端口流量均为0,无法成功。 看了官方关于 Relay 的文章,这个需要付费版才有的功能,不知道是不是因为这个原因。 使用 ZeroTier 则可以轻松的穿透成功,但看起来是使用中转服务器的,并非P2P,延迟感人,无法使用。 Moonlight Moonlight 的安装配置略微麻烦一些,不像 Parsec 毕竟是一个商业化很成熟的软件。Moonlight 的基本原理,是使用 Nvidia 内置的 Shield 功能实现串流,所以不需要一个中央服务器进行牵线搭桥。 受控端(Host)配置 根据官方文档安装 GeForce Experience 并开启 Shield。 安装官方工具Moonlight Internet Hosting Tool,以支持通过网络连接使用 Shield。这个工具只需要下载安装放着就可以了,没有界面,无需配置。 这样的状态下只能接受局域网内的连接,所以还需要进行网络穿透。有公网IP的用户直接在路由器设置端口映射即可, 我这里使用的是 frp,需要借助一台中转服务器。具体可以查看这篇教程。由于我控制端是电脑(MacBook)而非手机,所以只需要完成 frp 配置部分,不需要配置教程后半段安卓项目的支持。 控制端配置 在 MacBook 上下载 Moonlight,并输入中转服务器的IP地址,此时会请求控制,受控端的桌面上会弹出一个输入配对码的提示。这个仅在第一次的时候需要。配对完成后,随便点击一个游戏即可进入。中途退出可以按 control…

  • 以JS处理emoji表情为例简介UTF-8编码

    Emoji 表情符号是直接保存在字符中的标签,不是一张图片,而是可以理解为和一个汉字同类的东西。因此在绝大多数可以打字的地方,就能放 Emoji。但是某些地方会出现表情变成问号或者一个框框的情况,其中一个可能的原因是使用了自定义的,或者过时的 UTF-8 解码形式。 首先简单说明一下文字在计算机中是如何被存储的。毫无疑义的是,文字最终一定是以二进制的形式存储的。其中最简单的是著名的 ASCII 码,他是早期由美国指定的一个编码标准,建立了一个二进制数到字母和符号的映射关系,其中共有 128 个符号,包括了英文大小写字母和标点符号等。二进制范围从0000 0000到0111 1111,具体范围可以查看维基百科。后来互联网时代这套标准延续了下来,一直用于英语文字的存储,通常直接用 8 位二进制,即一个字节(Byte)存储。 可是问题来了,世界并不只有英文,欧洲有法语、德语等语言不全是有 26 个英文字母组成的,亚洲又有众多的象形文字,比如中文字符的数量就多了去了。所以继续拓展,一开始,欧洲国家使用一个字节中剩下的 128 个空间各自表示自己语言的符号,而中文则是以GB2312为主(如 Windows 系统),用两个字节来存储常用的 6 万多个汉字。由于各种编码之间并不是遵循同样的标准,所以有些时候我们会看到各种乱码,比如著名的手持两把锟斤拷,口中直呼烫烫烫。 Unicode 与 UTF-8 Unicode 的出现,正是为了解决文字编码问题,它建立了一张超大的映射关系表,存储各国文字符号,可以看作是 ASCII 的国际版,其数量已经远远超过了 2 个字节的范围。其中 Emoji 表情就在其中占有一段位置。 那么为什么有了 Unicode 还会出现乱码和 Emoji 的不正常显示呢?因为 Unicode 只是规定了映射关系,具体存储并不一定按照这个顺序直接对应到二进制码。除了历史原因外,还有一个问题就是长度过长引起的浪费,假设用 3 个字节作为一个文字符号,那么英语(ASCII)的存储就会出现两个字节的浪费。因此通常采用一种可以兼容 ASCII 的存储方式,使得字节数不需要固定到最大位数。 著名的UTF-8便是 Unicode 的一种实现方式,解决了上面提到的长度浪费问题。除去 ASCII 的范围,一个字节中还存在 1 开头的各种情况,UTF-8 充分利用了这部分空间,规定了一些标识位,实现了变长的编码方式,即一个字符可能由 1-4 个字节组成。这样…