Account Unknown (S-一大串 = SID) 单纯是那个 SID 没有知名的名字，这在 Windows 8 以来非常正常——因为新 app 模型（所谓 Windows 应用商店应用）里面，每个 app 、每个 app 权限都有自己的 SID ，而且这种 SID 可以分布式生成（通过字符串的 hash ），而 hash 不可逆，只有几个固定的 SID 是“知名”的，所以很多 SID 无法显示“名字”。当然，不显示名字不代表这个 SID 在当前系统里没有被使用。

删除这种 SID 会导致新类型的 app 运行不正常，包括无法启动或启动后立刻崩溃（因为无法正常访问那些文件）。

RESTRICTED 、SYSTEM 等是操作系统级别的 security principal ，理解成虚拟用户即可。

如果当前用户是管理员，那么它可以访问任意文件，设置的安全信息对于管理员来说只能防止意外误操作。最简单的方法是打开需要访问的文件的 properties ，在 security 里面把 owner 改成自己，然后重新打开 properties ，重新打开 security ，给当前用户加上权限，应用或递归应用（文件夹的情况），然后就可以访问了。

这样做对 accessibility 很糟糕，因为原理是把文本转换为 Unicode 里面的数学符号（对于数学来说，是否斜体、粗体、使用了什么字体族，都算完全不同的符号），很多读屏器会一个字母一个字母地念（是审定的正确念法，因为它们的含义就是每个字母）。

更好的做法是使用格式化的功能（例如网页技术的 CSS ），当然对于很多社交网络来说不存在这样的功能，那就没有好方法了。

想要编码新的字并不困难，了解一下 Unicode 表意文字描述字符。

𤭢 = ⿰卒瓦

我的建议是 CEO 赶紧使用“拒绝做出可能令自己有罪的供述”之权利拒绝听证（ doge

如果你是说 annual paid monthly 受害者的情况，实操可能是可以的（效果上 Adobe 没有继续收钱并在月末停止了服务，即使年度合同还没到期），但是支付失败不会消灭合同，理论上 Adobe 可以催收。

简单的做法是和客服谈心。

>公司就让我帮忙用我的美国信用卡来刷。

你没有义务借钱给公司。

>但是我这么做的话，会导致我的 ITIN 掉 credit 。

不一定会，单纯 dispute 只是会导致商户账户被银行取回资金，不会影响信用报告。当然，dispute 并取回资金这一行为并不会消灭商户和客户之间的债务关系，商户可能会把此债委托给催收公司，并把催收信息提交给信报机构，这是可能会影响信用的——我不确定商户会提交到付款卡主人的信报上还是公司的商务信报（当然，这对于你公司可能就是不存在的）上。

>我应该怎么做，才能拒绝公司的这一请求，保住信用分，还能拿到报销款而不用自己承担经济和信用分损失？

你和公司或许从未约定过你有义务配合公司 dispute ，或者你需要为公司提供 dispute 服务，的条款。这个问题到现在可以简单理解为公司要求你代为付款，那么结果当然是公司欠你钱，应该支付。

如果公司不听劝，建议找律师。

“老外”不止是说英语的……英语读 see-elleye ，法语读 cé-elle-i ，汉语读 cê-êl-yi 。

@hez2010 #9 现象和规范是两码事，单纯做一个实验就认为 Windows 支持超长变量无异于依赖于 C++ undefined behavior 编程。

应该注意 Win32 环境变量有两个存在的形式：在注册表里存储的系统/用户级变量、在每个进程里存储的进程级变量。

考虑下面的每个实验，每个实验开始之前都不存在名字叫做 verylong 的系统、用户、进程级环境变量。

————

实验 1：在 PowerShell 里运行

[System.Environment]::SetEnvironmentVariable('verylong', '1'*40000, 'User')

然后通过 explorer 打开一个新的 PowerShell ，并在新的 PowerShell 里运行

$env:verylong.Length

在 Windows 10 (build 19045.4651) x64 里得到的结果是 4095 ，这说明 explorer.exe 把 %verylong% 截断为 4095 个字符了。

————

实验 2：在 PowerShell 里运行

[System.Environment]::SetEnvironmentVariable('verylong', '1'*40000, 'User')
$cred = Get-Credential
Start-Process powershell -cred $cred -arg '-Command start powershell'

输入当前用户的用户名和密码，然后等待新的 PowerShell 启动（注意这里需要两次跳转，似乎有不知名的 bug 导致单纯打开一次 PowerShell 无法输入），在新的 PowerShell 里面运行

$env:verylong.Length

得到 40000 ，这说明“什么都不做”似乎是可以自动读取超长环境变量，然而……

————

实验 3：在 PowerShell 里运行

[System.Environment]::SetEnvironmentVariable('verylong', '1'*40000) # 默认的范围是进程

会得到

Exception calling "SetEnvironmentVariable" with "2" argument(s): "Environment
variable name or value is too long."

查阅 PowerShell 的源代码，发现这个异常是从 Win32 API SetEnvironmentVariable https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setenvironmentvariable 来的（而不是 PowerShell 自己检查的），文档明确指出超过 32767 个字符是不支持的，实际调用也会返回 FALSE 并用 GetLastError 指示变量过长。

————

实验 2 、3 表明实际上超过 32767 个字符的环境变量是不支持的，因为用于访问之的 Win32 API 拒绝设置超长变量。至于“什么都不做”的时候可以读到超长环境变量，单纯是 Windows 从注册表读取的时候、通过 GetEnvironmentVariable 返回的时候，忘记验证了。

考虑不变式

LPCTSTR name = T("verylong");
TCHAR value[40001];
DWORD size = 40001;
DWORD actualSize = GetEnvironmentVariable(name, value, size);
BOOL couldSet = SetEnvironmentVariable(name, value);

自然期待单线程环境下 actualSize > 0 && actualSize < size （这表明获取名字是 verylong 的环境变量成功了）蕴涵着 couldSet （这表示可以做无意义且无害的赋值），但这个不变式因为 Windows 的实现很不小心所以不一定成立。

然后，在做了上面的实验之后，我会认为日常使用的时候应该避免变量内容超过 4095 个字符，因为 Windows 最常见的 shell 即 explorer.exe 不支持超长的变量。

@hez2010 #6 我对英语的解读和你的不同，原文

> The maximum size of a user-defined environment variable is 32,767 characters. There is no technical limitation on the size of the environment block. However, there are practical limits depending on the mechanism used to access the block. For example, a batch file cannot set a variable that is longer than the maximum command line length.

说的是

1. 一个环境变量不能超过 32767 个字符。
2. 环境块没有限制。注意每个环境块是多个环境变量赋值的双空结尾字符串，这里说的是可以有任意多个环境变量。
3. 访问环境块的方法会带来其他限制，
4. 比如批处理文件不能设置环境变量的值为超过单行最大字符数长度的字符串。这个数是几千。

待会儿我到电脑附近的时候可以试试。

@hez2010 #3 然而这和文档说的相反，根据

https://learn.microsoft.com/en-us/windows/win32/procthread/environment-variables

环境变量的长度不能超过 32767 个字符。

@FengMubai #1 那个是去掉一些 API 里面路径长度的限制，和环境变量长度是两码事。

这个问题比较无解，因为 PATH 是知名变量，如果希望 PATH 里面有所需要的路径，但需要的路径太多，则必然会超过长度限制。所谓回到 PATH 内，是指进程里面的 PATH 变长，还是用户级别的 PATH 变长，还是系统级别的 PATH 变长？第一种解决方法是时不时从一个干净的根进程重启其他进程；第二种、第三种要找出来是谁（哪个进程）在随意修改环境变量。

代码的书写方向就是代码所用字符的书写方向，如果是 Latin 字母的代码，那就是从左到右。

在 RTL 环境里插入一段 LTR 文字，LTR 文字本身是从左到右书写的，比如

.言语的写书左到右从 is a 文伯拉阿

然而如果 LTR 文字本身需要超过一行，我想应该是每一行都要按 RTL 环境插入 LTR 文字书写，比如

is written from 文伯拉阿
.惯习太不会以所 right to left

最近翻看 Wikipedia 知道的：阿拉伯文本里面书写西阿拉伯数字，是从右到左书写的，但低位在前，所以看起来和中午里的阿拉伯数字是一样的，比如

.3.1415926 字文语伯拉阿些一有里这装假

@drymonfidelia #42 和 Edge 保护不保护隐私没啥关系，觉得幽默是因为通常会假设 MS 会把各种 Google 专有的东西删除或者换成 MS 专有的。

@zhangdp #47 对 Google 有用。

这件事情的幽默之处在于 MS Edge 也给 google.com 高权限。来源是 https://x.com/lcasdev/status/1810753964020773316 但我没有验证

@CRVV #78 你可能没有理解“总”能耗的含义。考虑发送电子邮件给 N 个人，自然期待 N 个人分别需要解密一次。

考虑 N 时间 1 长度的方案，那么每个收件人需要下载长度是 1 的密文，然后用 N 的时间运行解密算法，因此总能耗是 1*N+N*N = Theta(N^2)。

考虑 1 时间 N 长度的朴素方案，每个收件人需要下载的密文长度不是 N ，因为在 1 的解密所需时间内，整个长度是 N 的密文只有常数个位置被访问，因此每个收件人的下载是 1 ，解密时间是 1 ，总能耗是 1*N+1*N = Theta(N)。

两种情况里存储 O(N) 的密文以及在 O(N) 时间内加密所消耗的能量都被 Omega(N) 的下载、解密所吸收。

@CRVV #75 环保的考虑里面是计算了存储和传输数据需要的能量的，请注意“总能耗”的“总”字。

>要获得 “密文长度和收件人数无关” 这个性质，还是需要折腾一些花样进去。

获得这个性质所需要的技巧，我称之为“繁琐但常规的体操”。从技巧评判，这篇文章比较有趣的是环保问题，毕竟证明不可能性比证明可能性困难一些。至于问题本身是否有趣，每个人有不同的想法很正常。

您所谓“科研的玩法”，不可否认科研用作赖以生存的职业会有那种考量，但我的建议是晚一会儿想这个问题是一会儿。