Home Sign Up Sign In
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member  Sign In
V2EX  ›  geelaw  ›  全部回复第 58 页 / 共 189 页
回复总数  3778
1 ... 54  55  56  57  58  59  60  61  62  63 ... 189  
❮ ❯
2020 年 6 月 6 日
回复了 kuanng 创建的主题 › Windows › Windows 下有哪些程序员平时不太了解，却很重要的知识？
@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 访问时无此限制。
2020 年 6 月 6 日
回复了 kuanng 创建的主题 › Windows › Windows 下有哪些程序员平时不太了解，却很重要的知识？
@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 。
2020 年 6 月 1 日
回复了 Osk 创建的主题 › 微软 › 一口老血, 微软把 ssh-agent 添加的 key 存在注册表里面
@Osk #4 既然用了 DP API 就说明结果是加密的，解密必须需要所有者的密码。其他用户即使能看到内容也只是密文。

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

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

@M3ng #5 @mrcn #6 这个说法很成问题，管理员并不是什么都可以做得到。
2020 年 6 月 1 日
回复了 Osk 创建的主题 › 微软 › 一口老血, 微软把 ssh-agent 添加的 key 存在注册表里面
@nicevar #1 持久化和非持久化的区别。

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

如果没有可配置选项，那么最好的策略是使用 EFS，这样管理员在没有目标用户的密码时无法访问目标用户的 HKU 子项。
2020 年 5 月 25 日
回复了 GeekSky 创建的主题 › 程序员 › 前端能不能实现只更改数字的字体？
另外一提，unicode-range 的技巧常用于选择正确的标点字形，例如希望文本里的拉丁文本使用字体 A 、汉语文本使用字体 B 。
由于汉语字体包括拉丁文本的，你需要设置字体为 A B，但这会导致引号、省略号使用拉丁文本字形。
此时可以用 font-face + unicode-range 设置字体 C，它只包括引号、省略号，并使用字体 B 的字形。最后设置字体为 C A B 即可。
2020 年 5 月 20 日
回复了 20015jjw 创建的主题 › Windows › 有人跟我一样觉得 Windows Vista 是最好看/好听的 Windows 吗
我实在找不到 7 比 Vista 不好看的地方啊，而且 7 修改了最大化窗口边框的处理，在 Vista 里最大化窗口边框没有毛玻璃。
2020 年 5 月 18 日
回复了 hanliu 创建的主题 › macOS › [急] Mac powerpoint 排练计时 打开是演示者视图！
点“排练计时”会录制新的计时，在你答辩的时候你可能是想使用已经录好的计时，所以这不是一个问题。不过答辩的时候你可能更想手工控制进度，毕竟突发状况是排练时无法预料的。

实际上作为 Windows 用户很希望微软赶紧允许 Windows 上排练计时使用演示者视图，为此我还专门写了脚本实现在 Windows 上使用演示者视图下的排练计时，参见 https://geelaw.blog/entries/powerpnt-tricks-ec20/#rehearse-timings-presenter-view
2020 年 5 月 11 日
回复了 vevlins 创建的主题 › Electron › electron 中 nls.localize({ key: 'miUndo', comment: ['&& denotes a mnemonic'] 这种"&&"是什么用处？
@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 进行回答，无论是否有下划线。
2020 年 5 月 11 日
回复了 vevlins 创建的主题 › Electron › electron 中 nls.localize({ key: 'miUndo', comment: ['&& denotes a mnemonic'] 这种"&&"是什么用处？
注释里提示了是助记按键，即键盘快捷方式。

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

举个例子，在 Windows 上打开记事本，然后按 Alt+O 再按 F 可以打开字体对话框。
2020 年 5 月 8 日
回复了 fgwmlhdkkkw 创建的主题 › 问与答 › 为什么 ctrl+w 是关闭标签呢？ w 对应哪个单词呀？
@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 。
2020 年 5 月 7 日
回复了 frmongo 创建的主题 › 问与答 › 如何做到在 win server 上定时截图
这个和安全没关系，单纯是因为没有输出图形必要时程序根本不会去画窗口。
2020 年 5 月 7 日
回复了 pscl 创建的主题 › 前端开发 › 请教前端中预览和编辑 docx 文件的问题
自托管 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 ？
2020 年 4 月 30 日
回复了 zzfra 创建的主题 › 微软 › OneNote 有第三方客户端吗？
理论上可以有
2020 年 4 月 28 日
回复了 JustSong 创建的主题 › 程序员 › 遇到了一个玄学问题， C++ 修改类的数据成员后其值又自己变了回去
Filesystem 会复制到 execute 里面，自然不会对外面的对象产生影响
2020 年 4 月 28 日
回复了 darrh00 创建的主题 › Apple › macOS 下程序监视剪切板不需要任何权限的吗？
@lizhuoli #12 MAS app 不可能有剪贴板隔离，否则无法解释复制数据后到处都可以粘贴。Paste Helper 的作用是直接把数据放到另一个进程里（不需要手动粘贴），和把内容放入剪贴板、读取剪贴板无关。
2020 年 4 月 27 日
回复了 darrh00 创建的主题 › Apple › macOS 下程序监视剪切板不需要任何权限的吗？
@XDDD #9 10.15 的改变是所有的 app 都会得到进程外的对话框（不仅仅是 sandboxed ）。我找了一下，是不能显示被拖拽的文件夹，见第三张图 https://apple.stackexchange.com/a/332686 不过我以为 macOS 的权限限制对所有的进程都有效，比如 Terminal 似乎不是 sandboxed app 但是仍然受到个人文件夹访问限制。
2020 年 4 月 27 日
回复了 darrh00 创建的主题 › Apple › macOS 下程序监视剪切板不需要任何权限的吗？
@XDDD #7 看了一下，这个是 10.15 引入的改变。这个和 UWP 的情况不一定一样，如果打开文件对话框的进程仍然被原来程序的权限限制，进程隔离的意义就不在于权限隔离了，而是比如稳定性、兼容性等。现在打开文件对话框是否还受程序本身能否访问某个文件夹的限制？

程序想自己画对话框和安全问题无关，UWP 无法自己读文件然后自己画对话框，它通常没有权限读文件系统。
2020 年 4 月 25 日
回复了 zackZhong 创建的主题 › 分享创造 › 做了一个密码加密的小工具, 用于加密密码生成器的密码（大家平时会用密码管理器管理密码不）
@zackZhong #2 > MD5...
我没说过 MD5 是选择明文安全的加密算法。实际上单纯 MD5 三个字符并不代表任何一种加密算法。

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

@koswu #4 这个想法的问题在于这个加密工具的 key 不泄露也很容易攻击，不需要等到 AES 被破解的一天。
2020 年 4 月 25 日
回复了 zackZhong 创建的主题 › 分享创造 › 做了一个密码加密的小工具, 用于加密密码生成器的密码（大家平时会用密码管理器管理密码不）
这个不能真的用来管理密码，因为它实际上就是 multi-time pad，非常不安全。

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

如果你知道密码 A 和密码 B 的密文，你可以算出 A xor B 。一个非常严重的推论是：如果你知道密码 A 、密码 A 的密文和密码 B 的密文，如果 B 的长度不超过 A，则可以完整还原密码 B 。假设你在网站 A 的密码因为网站 A 的失误泄露了，而你的密码的密文也泄露了，好巧不巧，网站 A 的密码还是最长的，那么你所有网站的密码就都泄露了。
2020 年 4 月 25 日
回复了 darrh00 创建的主题 › Apple › macOS 下程序监视剪切板不需要任何权限的吗？
@lcandy #2 如果文本框是进程自己的，那么用户主动粘贴的实现就是进程在用户粘贴的时候读，至于是操作系统默认实现的读，还是软件自己实现的读，这无法区分。即使可以，另一个问题是很多文本编辑器都需要复杂功能，无法使用操作系统默认的实现。

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

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

在文本框的例子里上述解决方案仍然不好，因为通常一个 app 可以要求自己的文本框执行一些操作，那么它可以要求文本框粘贴，然后读取内容。此外，进程隔离仍然不能解决复杂、非系统实现文本框的粘贴问题。
1 ... 54  55  56  57  58  59  60  61  62  63 ... 189  
❮ ❯
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   906 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 40ms · UTC 22:29 · PVG 06:29 · LAX 15:29 · JFK 18:29
♥ Do have faith in what you're doing.