加不加 ' 都可以的包括 x0 年代、缩写等。通常数学公式加 ' 更好，例如 以上诸 $x$ 的写法是 the $x$'s above 。

另外 native speaker 的正写法不一定很好，例如一些 native speaker 会写出 I should of done that 。

@Guys #33
我理解你的表达的意思是：cd "A B" 才能成功，cd A B 不能成功，交互式使用时 Tab 补全时会自动对带空格的目录加引号。
我没有理解你说的在 batch 里要注意是什么意思：可能是说交互式补全会帮你加引号，batch 里要自己加；也可能是说 batch 里 cd 必须用引号。
无论是 batch 还是交互式，cd A B 都可以成功，所以你关于 cd 需要引号处理空格的表达是错误的。

如果你要问 cd 不需要引号为什么 Tab 补全 cd 也会带引号，这是因为 Command Prompt 比较初级，不会考虑当前命令是什么，故采用更一般的模式。

我相信自从 Windows 支持带空格的文件名以来（也就是至少 Windows 95 以来）就不需要在 cd 里面用引号，主要是为了兼容性，比如 cd %1 这种在 Windows 95 之前写的代码（假设文件名从来都没有空格）在 Windows 95 以后仍然可以正常工作。
不过我找不到 Windows 95 时期的参考文献了，从这篇可以看出 2012 年以来就不需要了 http://dosprompt.info/commands/cd.asp

@mmdsun #28 理解了，这个限制只有 Explorer 有，我的意思用 Win32 访问时无此限制。

@Guys #2 错误，cd 是内部命令，你可以写 C:\>cd program files 进入 C:\Program Files，而且如果你的 program 和 files 之间有两个空格不会成功。

@also24 #4 微软账户的默认用户名是 ID 的前五个字母，而不是用户的名字。

@litmxs #9 文件名不能为 DOS 设备名的限制是 Win32 的而不是 Windows 的，而且通过 Win32 最大可以访问长度是 32768 的路径。

@mmdsun #13 那个点是多余的，直接建立名字是 .txt 的文件就可以得到名字是 .txt 的文件。
此外 Program Files 不一定是 PROGRA~1，而且 8.3 文件名可以被关掉甚至删除。

"要求输入凭据的受信任路径" 的作用是要求输入密码之前用 Ctrl+Alt+Delete，和 UAC 是否输入密码是两个不同的问题。如果你想要管理员也输入密码，需要设置 User Account Control: Behavior of the elevantion prompt for administrators in Admin Approval Mode 为 Prompt for credentials on the secure desktop 。

@Osk #4 既然用了 DP API 就说明结果是加密的，解密必须需要所有者的密码。其他用户即使能看到内容也只是密文。

不清楚 HKCU\Software\OpenSSH 的访问权限的设置问题，可能是因为这一块是 ssh-agent 服务管的，所以当前用户不需要读取。这应该看作一个“防手贱”的设定，因为当前用户总是可以查看和编辑自己的 ntuser.dat 。

我说的“用了 EFS 就无法在没有密码的情况下访问 HKU 子项”是因为那种情况下 ntuser.dat 是加密的，和 ACL 没关系。

@M3ng #5 @mrcn #6 这个说法很成问题，管理员并不是什么都可以做得到。

@nicevar #1 持久化和非持久化的区别。

回到楼主的问题，不知道楼主说的“加密”是什么，如果是正规的加密的话（比如使用 Windows 密码学 API ）其他用户是无法读取的（因为解密密钥是加密者的密码导出的密钥）。

如果没有可配置选项，那么最好的策略是使用 EFS，这样管理员在没有目标用户的密码时无法访问目标用户的 HKU 子项。

另外一提，unicode-range 的技巧常用于选择正确的标点字形，例如希望文本里的拉丁文本使用字体 A 、汉语文本使用字体 B 。
由于汉语字体包括拉丁文本的，你需要设置字体为 A B，但这会导致引号、省略号使用拉丁文本字形。
此时可以用 font-face + unicode-range 设置字体 C，它只包括引号、省略号，并使用字体 B 的字形。最后设置字体为 C A B 即可。

我实在找不到 7 比 Vista 不好看的地方啊，而且 7 修改了最大化窗口边框的处理，在 Vista 里最大化窗口边框没有毛玻璃。

点“排练计时”会录制新的计时，在你答辩的时候你可能是想使用已经录好的计时，所以这不是一个问题。不过答辩的时候你可能更想手工控制进度，毕竟突发状况是排练时无法预料的。

实际上作为 Windows 用户很希望微软赶紧允许 Windows 上排练计时使用演示者视图，为此我还专门写了脚本实现在 Windows 上使用演示者视图下的排练计时，参见 https://geelaw.blog/entries/powerpnt-tricks-ec20/#rehearse-timings-presenter-view

@vevlins 因为最近的 Windows （大概是 Windows Vista 或者 7 开始的）默认不显示提示。这个技能也不是那么久远的故事，感觉我在回答电脑操作 101 。

Cut 的触发方式自然是按 T，例如在 VSCode 里面，打开 Edit 菜单后按 T，会在 Cut 和 Toggle Line Comment 之间反复切换高亮项，在切换到 Cut 后按 Enter 就可以触发，这是因为 Toggle Line Comment 的快捷方式也是 T ；如果是 Copy，因为 Edit 里面只有 Copy 的快捷方式是 C，所以按 C 会直接触发。

如果你使用 Alt+E 打开 Edit 菜单，则无论什么设置都会显示每个菜单项的快捷方式，这里的逻辑是用户明显表达了使用键盘导航的意愿。

如果你想永远显示快捷方式的下划线，可以在 Windows 的 Settings | Ease of Access | Keyboard 里打开 Underline access keys when available 。

同理，标准的 Yes/No 对话框可以按 Y 或者 N 进行回答，无论是否有下划线。

注释里提示了是助记按键，即键盘快捷方式。

很多菜单项、命令按钮的某个字母下会有一个下划线，这表示使用 那个字母 的按键或者 Alt+那个字母 可以激活那个菜单项、命令按钮。

举个例子，在 Windows 上打开记事本，然后按 Alt+O 再按 F 可以打开字体对话框。

@Mutoo #8 请问你是如何得出 IE 8 的 Ctrl+W 是抄了 Mac OS 的快捷键设计的？而且据我所知，Internet Explorer 4 里就有 Ctrl+W 关闭窗口的功能了。

不过目前可以找到最早的 Mac OS 上的 Cmd+W 约定是 1992 年的一本指南，Windows 世界尚不明确。

@mcluyu #20 一说来自 Verbatim insert，另一说仅仅是因为和 C 离得近（美式布局）。自古以来的粘贴是 Shift+Insert 。

这个和安全没关系，单纯是因为没有输出图形必要时程序根本不会去画窗口。

自托管 Office Online 解君愁 https://docs.microsoft.com/en-us/officeonlineserver/office-online-server

根据 https://www.zhengrongshuo.com/code/show/7685599 似乎 WPS 有兼容 Office 的 COM 访问方式，所以你可以用 COM 访问 WPS 输出 PDF ？

理论上可以有

Filesystem 会复制到 execute 里面，自然不会对外面的对象产生影响

@lizhuoli #12 MAS app 不可能有剪贴板隔离，否则无法解释复制数据后到处都可以粘贴。Paste Helper 的作用是直接把数据放到另一个进程里（不需要手动粘贴），和把内容放入剪贴板、读取剪贴板无关。

@XDDD #9 10.15 的改变是所有的 app 都会得到进程外的对话框（不仅仅是 sandboxed ）。我找了一下，是不能显示被拖拽的文件夹，见第三张图 https://apple.stackexchange.com/a/332686 不过我以为 macOS 的权限限制对所有的进程都有效，比如 Terminal 似乎不是 sandboxed app 但是仍然受到个人文件夹访问限制。

@XDDD #7 看了一下，这个是 10.15 引入的改变。这个和 UWP 的情况不一定一样，如果打开文件对话框的进程仍然被原来程序的权限限制，进程隔离的意义就不在于权限隔离了，而是比如稳定性、兼容性等。现在打开文件对话框是否还受程序本身能否访问某个文件夹的限制？

程序想自己画对话框和安全问题无关，UWP 无法自己读文件然后自己画对话框，它通常没有权限读文件系统。

@zackZhong #2 > MD5...
我没说过 MD5 是选择明文安全的加密算法。实际上单纯 MD5 三个字符并不代表任何一种加密算法。

> 但我的密码存在密码管理器上。
如果你认为存在密码管理器里面就安全了，为什么还要先加密再存呢？如果密码管理器本身是安全的，无论你对送入密码管理器的东西做什么都不会让它变得不安全（理论情况下，也假设你做的事情都是高效的），但是是否“更安全”并不是明显的事情，尤其是你做的额外操作并没有什么特别的安全性的时候。

@koswu #4 这个想法的问题在于这个加密工具的 key 不泄露也很容易攻击，不需要等到 AES 被破解的一天。