通常状况下合盖后会进入睡眠状态，我以为 macOS 进入睡眠之后 app 就不运行了？

可能 1 是程序阻止了睡眠，这样的话就不能检测睡眠事件（因为根本不发生）。
可能 2 是睡眠期间程序偶尔可以运行，此时可以检测即将睡眠的事件并进行操作。

另一种思路是检测目前有几个显示器，如果显示器的数目降低到 0 则执行程序。

不宜检测是否合盖，因为连接外置显示器、键鼠、电源时，合盖不应导致活动暂停。

我觉得把 Edge tab 作为 Alt+Tab 切换的对象确实不好，因为 Alt+Tab 切换的范围是整个桌面。更好的设计是自从 Windows 7 开始的 Internet Explorer 里的，即每个 tab 在任务栏点击合并的按钮后自己是一项，因为任务栏按钮切换的对象是一个 app，故把 tabs 展示出来是合理的。

很可惜正则表达式最小化问题是 PSPACE-complete，所以不应该期待高效算法。

另外，最小化 NFA 也是 PSPACE-complete，而最小化 DFA 则是多项式时间可解的。然而从正则表达式算出最小 DFA 的意义也不是很大，除非是做编译器的 lexer——从正则表达式到 DFA，规模可以以指数级增长，只有精心设计的正则语言才适合用 DFA 表示。

这跟领导似乎没关系吧，还是说领导是坚定的无产阶级，要消灭您？

不存在这种功能，C++ 里私有成员是接口而不是实现细节，这主要体现在字段影响内存布局、友元、可以被重写的私有虚拟成员、名字解析（私有成员会参与名字解析）。

曲线救国的思路是 pimpl 或者接口化。

@thefack #1 你可以通过 Home 按钮或侧边按钮激活 Siri，之后 Siri 不再管是谁的音色。

@uhian #3 以及楼主 https://discussions.apple.com/thread/7502104

正确的说法是 watchOS 7 支持 network extension 。

@wy315700 #7 通常应该选择先加密后认证（签名），以减少侧信道泄露。

狭义来说，常见的对称加密不但比常见的非对称加密快，而且可以做到 密文长度 = 明文长度 + 常数，而且可以同时获得保密性和完整性——即使坏者既不能看懂密文，也不能创造它（看不懂的）有效密文。

第三点是公钥加密自然不能达到的，如果要做到同时具有保密性和完整性则需要客户端、服务端分别有公钥加密算法和签名算法，需要 4 对密钥。
前两点对自然定义不成立，因为用公钥+私钥加密混合形成的混合加密也是公钥加密算法，且也可以获得前两个优点。

> 但反过来，服务器下发数据，那边用私钥加密，中间人可能有公钥，服务器传给浏览器的数据，就能被中间人解开了。

这段话“连错误都算不上”，因为它不合语法（即这句话类型检查失败）。如果一个东西“用私钥加密”，那么这个东西一定是对称加密算法而不是非对称加密算法，因此“中间人有公钥”里的“公钥”和前文的“私钥”不能存在有意义的关系，更不可能用公钥去解密东西。

如果是 LPUTF8Str，对应的非托管字段是 byte *，如果是 ByValTStr 、结构是 Unicode 、设置的 SizeConst 为 30，则对应的非托管字段是 30 个 ushort 。两个结构的非托管形式完全不同。

AllocHGlobal 出来的是一段定长内存的指针，至于怎么解读是代码的事儿。

早期 .NET 在取消封送 LPUTF8Str 时有 bug，见 https://github.com/dotnet/runtime/issues/11968

最后你的代码有内存泄露，在 FreeHGlobal 之前你应该 DestroyStructure，否则运行时不可能知道封送入 structPtr 而产生的 UTF-8 字符串需要释放。

溢出过了再转换，不会撤销溢出。

这个问题在 KB826741 解答过，存档 https://mskb.pkisolutions.com/kb/826741

现学现卖之诈骗的构成要件：以非法占有为目的；虚构事实、隐瞒真相；受害人陷入认识错误；受害人因认识错误自愿处分财产；行为人获得财产，受害人失去财产。

> 假设买了一个 1 元包邮的商品，快递丢件了，快递公司通过电话告知可以转账赔偿并询问多少钱。
> 如果故意说是 10 元买的，对方听了后二话不说直接转账，这样是否属于一般治安诈骗行为？
> 如果故意说是 10000 元买的，是否属于诈骗罪？如果快递公司不相信或者不愿意转是否属于诈骗未遂？

要看快递公司转账的理由，如果是相信了购买价格而转账，则是诈骗。前者无法达到入罪标准，后者可能达到（不同地方的数值不同，3000-10000，所以如果一个地方入罪标准是 10000，则不入罪）。

如果快递公司不相信或不愿意，则不犯罪，因为 http://www.court.gov.cn/zixun-xiangqing-2472.html 解释说明了诈骗未遂需要以数额巨大（ 30000 起跳）财务为目标，或者有其他严重情节，此处无。

至于薅羊毛诈骗和霸王餐诈骗，我机数还不行，就不献丑了。

> 2 、私钥由用户保管，不会上传到服务器。
> 3 、公钥由一定的规则生成，跟用户的微信 ID 有关，每个人的公钥都不相同。

看到这两句话我觉得要么是我太弱了，要么是楼主太强了，至于是哪种，我不知道。

问题：如何做到安全地生成一对密钥，使用户的微信 ID 可以算出公钥？

更基本的问题：在这个场景里，用户比其他人多了什么能力，使用户可以算出私钥而其他人不能（根据微信 ID ）算出这个用户的私钥？

这取决于 1 、2 、3 的含义：如果这是一个位映射枚举，则用位运算 #2 是自然的解法；如果这不具有位映射枚举的含义，则楼主本来的写法自然。

自然的表达即“本来是什么意思就表达什么”。

Windows 10 创意者更新后已经无需特殊权限即可建立符号链接，要么是有软件改变了这个设置，要么是你排查的原因错误。

要检查自己是否有权限在 %TEMP% 下建立符号链接，尝试自己运行 mklink 。

要允许普通用户创建符号链接，搜索 windows group policy symbolic link without admin rights

@huangya #13 我是根据你的贴图考虑的，不过你援引的这段话里“一般”的理解对正确性有很大影响。如果“一般”理解为“通常”“大多数情况下”（即日常理解），那么是正确的；如果“一般”理解为“恒成立”“总是有”（即数学语言的理解），那么是错误的。

两本书都有用语上的混乱，前者还有对签名理解上的混乱、对安全性解读的混乱，但经过修补之后都是正确的——即 hash 函数不是签名必备的一部分。

前者对签名理解上的混乱在于赘余表达签名不保护消息的隐秘性，其理由错误，并不是因为任何人都可以“重新加密”，而是因为消息本身总是伴随着签名发送，因而一开始就没有隐秘性。

前者对安全性解读的混乱在于它的表述让人误以为安全 = 无法恢复密钥，这是错误的，签名的安全性是不可伪造，不能还原密钥只是它的一个推论。

两者在用语上的错误在于把签名说成解密、验证说成加密，实际上无此关系。

Hash 函数并不是签名的必备要素，而且签名算法的实现也不止两者所述的样子。
签名算法的消息空间可以是固定长度的，即使想要得到无限长度的消息空间，也不需要 hash 函数（如 Lamport 签名算法加 GGM ）。
当然，后者的情况更接近真实世界里的签名算法，也就是使用 hash 函数。