另外一提，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 被破解的一天。

这个不能真的用来管理密码，因为它实际上就是 multi-time pad，非常不安全。

你的加密算法（不是说密钥生成算法）没有任何随机性，同一个密码的加密多次总是相同的，这表示你的加密方法不具有选择明文攻击下的安全性。默认情况下，使用的加密算法应该具有选择密文攻击下的安全性。

如果你知道密码 A 和密码 B 的密文，你可以算出 A xor B 。一个非常严重的推论是：如果你知道密码 A 、密码 A 的密文和密码 B 的密文，如果 B 的长度不超过 A，则可以完整还原密码 B 。假设你在网站 A 的密码因为网站 A 的失误泄露了，而你的密码的密文也泄露了，好巧不巧，网站 A 的密码还是最长的，那么你所有网站的密码就都泄露了。

@lcandy #2 如果文本框是进程自己的，那么用户主动粘贴的实现就是进程在用户粘贴的时候读，至于是操作系统默认实现的读，还是软件自己实现的读，这无法区分。即使可以，另一个问题是很多文本编辑器都需要复杂功能，无法使用操作系统默认的实现。

如果你希望按进程控制剪贴板的权限，首先要做的是把所有“默认可以让用户粘贴”的文本框都由操作系统的特殊进程提供，并跨进程合成完整 UI 。这仍然不能解决复杂文本编辑器第一次粘贴需要被打断的问题。

举个例子：在 macOS 里，如果你用“打开”对话框导航到 Documents，并且拒绝提供权限，那么“打开”对话框无法显示里面的内容。在 Windows 里，如果 UWP 用 FileOpenPicker，它不需要具有访问本地文件系统的权限也可以让用户自由选择该用户有权限访问的内容。这个区别在于，macOS 里每个 app 的“打开”对话框都是进程内代码，自然不能访问被拒绝的文件夹；而 Windows UWP 里的“打开”对话框是一个专门的进程（该进程有权限访问文件系统，并且可以把权限提供给 UWP ）完成的，该进程确保打开文件是用户自己的操作。

在文本框的例子里上述解决方案仍然不好，因为通常一个 app 可以要求自己的文本框执行一些操作，那么它可以要求文本框粘贴，然后读取内容。此外，进程隔离仍然不能解决复杂、非系统实现文本框的粘贴问题。

1. 这个东西叫“剪贴板”，至少 Windows 和 macOS 都是这么叫的。
2. 通常来说你不希望在每个程序里第一次按 Ctrl/Cmd+V 的时候弹出一个对话框。

Cloaking 的概念和 UWP 没关系，如果你用虚拟桌面的话，不在当前桌面显示的窗口都会被 cloaked 。

输出为 HTML 之后用 Word 打开好像就行了吧。如果你想要不同的格式可以打开之后在“设计”选项卡里更换。

如果要设置表格风格可以在文件最开始添加 inline CSS 。

如果要纯天然渲染结果可以随便找个开源的 Markdown 解析器，用 COM 访问 Word 进行输出，或者输出 Office XML 。