文件选择器是进程内的，因此当前进程不支持缩放就只能得到不支持缩放的版本（当然如果你用 WinRT 选择器，那就是进程外）。安装程序的话，Windows Installer 当然是支持缩放的，至于其他的自解压安装程序，那和其他的普通程序没啥不同。

这个东西不能叫做“开源”（我没有仔细确认，但是很明显这个许可不符合“自由软件”的要求，而大多数情况下一个许可同时是或者不是开源和自由的），只能叫做“允许别人查看源代码”。

那个表达式不是

/images/(\d{4}-\d{2}/\d{2})/\d{2}/\d+_brief/

而是

/images\/(\d{4}-\d{2}\/\d{2})\/\d{2}\/\d+_brief/

缺少 \ 会导致语言把 /images/ 理解为一个正则表达式，从而出错。

提问的时候应该链接上下文，单看一句是很难看懂的。这段代码位于

https://github.com/DIYgod/RSSHub/blob/457e8f8a41c80bbd251bf40da2dd25648270a37f/lib/v2/hnrb/index.js#L24

假设 id 是空，这里的代码先 GET https://hnrb.voc.com.cn/hnrb_epaper 然后查找响应内容里面 URL=(.*)" 匹配中对应 .* 的结果，自己访问一下这个页面发现 URL=(.*)" 会匹配 <meta equiv="http-refresh" 里面的重定向地址，因此这个 GET 是为了得到最新地址。

第二步是 GET 这个最新地址，然后用正则表达式匹配得到的是 <img src=../../../images/2023-06/24/01/2023062401_brief.jpg 里面的 images/... 的内容，第一组的内容是 2023-06/24 （这个结果当然是随着时间变化的）。

所以并不存在你说的从正则表达式直接到 _pdf.pdf 这一步，它后面还对返回数据进行了各种加工。

第一，检查你是否把本机的默认编码设置为 UTF-8 了，如果这样的话 ANSI （实际上记事本的 ANSI 是本机默认编码）等于 UTF-8 。

第二，如果你的文本文件在 UTF-8 和 ANSI 下编码一样，那么记事本可能会优先识别为其中一个编码。

第三，你可能应该考虑把 bat 保存为 Unicode (UTF-16 LE)，这样 Windows NT 系列都可以运行。

第四，检查其他问题，比如 bat 必须用 \r\n 作为行结尾，以及插入 pause 调试之。

实体卡到期通常不会影响已经绑定的安全支付方式，类似的情况是，报告实体卡被窃后换发新卡，Apple Pay 通常是无缝继续可用的。

可以致电银行询问，如果招商银行 app 里仍然显示信用账户并显示你的卡，说明已经自动续期，可以考虑挂失未收到的新卡。

过期日是过期月的最后一天，如果是 2023 年 6 月过期，那就还没过期。通常来说，除非主动关卡，否则是自动续期的。

支付应该优先选择信用卡。

https://mp.weixin.qq.com/s/6IcO3vDjbJoQUXmSQjE0Pw

在 iOS 的微信上看不到这个虚线的样式。另外别人的作品怎么排版不是读者可以决定的。

@PapaFox #11 全盘加密呀，然后禁止自动解密，防止冷冻法提取密钥。

如果害怕进出海关被扣电子设备的话可以在过境之前先抹除硬件上的数据，通过后再重新同步。

另外陈刚似乎在入境的时候拒绝提供密码。

从密码学角度考虑，口令登录相比密钥登录的问题并不在于“容易被人猜出口令”，而是：(1) 获得一次成功认证过程的明文即可反复重新认证；(2) 服务器被攻击后更容易还原口令。

使用高强度口令可以避免第二个问题，然而我的看法是发送 s 并不比发送 to_lower(sha256(s)) 更糟糕，两者口令的熵是一样的。口令长度不是安全性的源泉，只是代理指标而已，口令强是指它的熵高，而长度和熵的关系是 熵 <= 长度——好的口令一定要长，但长的口令不一定好。

理论上可以（有 API 可以查询远程桌面客户端的地址之类的），实践上不知道是否有软件会这样做。

如果你考虑的是一款“正常”且安全实现的浏览器，那么它里面的网站不能做此关联，因为在浏览器的模型里不存在远程桌面的概念，安全性表明网站无法感知它是否被显示在远程桌面上。

可以，实际上我经常不小心用余额支付，或者用余额抵扣一部分。

假设你在用美国的 PP ，则单次结账的时候可以组合付款，此时可以自由分配各个付款方式的贡献，且默认情况下当你有 PayPal Balance 账户时会优先使用余额。

注意只有有 SSN 的人才能开 PayPal Balance 账户，没有 PPB 的人在 PayPal 收到现金只能选择转入银行（或许只能是美国的银行）。

另外退款是优先退入原支付方法的，这是反洗钱要求，也用来避免无损信用卡套现。

“呼之欲出”是用来形容画像逼真的，你要说的是“暂时性失忆”。

@OutOfMemoryError #48 我眼拙，一开始看成了您的卡是中国银行 V 🤣 那这个不出现授权就很神秘了

@geelaw #8 刚刚去试了，在北京君太百货 2 楼的星巴克可以用 Apple Pay 外卡交易，具体来说是美国的银行发的 MasterCard 卡，并且立刻就收到了银行的交易通知，交易也立刻在银行的 app 里显示了。

注意君太百货是退税商店，或许配套设施比较好，但我的猜想是星巴克对国际支付的支持非常全面，哪家店都可以——我之前经常在星巴克刷外卡，但都是插芯片的（我听说过大陆没法非接触外卡支付，看来这个传言不实或者已经过时了）。

这个情况和楼主有些不同，楼主是 V 内卡 Google Wallet ，我的实验是 MC 外卡 Apple Pay 。共同点是非银联（也非 JCB 、Discover 这种和银联合作的）且是非接触交易。

另外

>但在此之前我通过 Google Wallet 充值了 Google Play (10 美元), 这笔交易已经显示在银行了（授信）

这是一笔国际交易，不受内卡外抛禁则的限制。

关于在线 /离线交易：Apple Pay 的消费提示（不是银行的）需要授权成功，离线交易在交易时还没有获得授权，所以不会有 Apple Pay 消费提示，我想 Google Wallet 是类似的，所以此交易应该是在线交易。

关于入账延迟：现在的银行都会显示最近已授权、未入账的交易，所以应该不是这个问题导致的。

@tulongtou #15 消费交易是要收手续费的，提现损失不小。银行的风控也会注意到异常交易。

@OutOfMemoryError #45 可能是这样的：$1 授权是绑定卡到订阅账户产生的，$270+ 是第一次交费产生的，这是两个分离的逻辑。当然细心的工程师应该特判来提升用户体验。

@efcndi #12 云闪付是银联服务，Visa/MasterCard 单标卡不能用的。

星巴克本来就可以直接刷外卡（目前我见到的都是插卡交易），而且 MCC 识别是正确的。

很有趣，我没试过在中国大陆的星巴克用 Apple Pay V/MC ，今天可以试一下。

我记得很久以前境内发行的 V/MC 卡可以在一些境内的 POS 以及支付宝使用，并且人民币交易是原样进入对账单的——这过程中有一些技术特判，避免两次货币转换的损失——但无论是否避免了换汇，交易数据会经过 V/MC ，但规定是禁止通过 V/MC 结算大陆地区的人民币交易，这种情况叫做“内卡外抛”。

某个时刻开始我国的监管严格起来了，中国境内发行的 Visa/MasterCard 卡不得在境内进行交易（似乎是人民币和美元都不许），包括 POS 和支付宝。

我猜 #1 @8eacekeep 猜交易没有出现的原因是内卡外抛禁则。

错误的，追求无 JavaScript 环境可用、功能丰富是非常好的极限运动。我在我的 blog https://geelaw.blog/ 里面就保证无 JavaScript 环境也几乎可以实现所有功能。