你要找的是不是：数组

COM 怎么会很麻烦？ VBA 和 VBS 都没用过吗？

我看了一下您的代码，就是用 Qt 帮你做的 IDispatch 包装接口去调用，使用 VBS、JScript 和 VBA 明显更简单。而且怎么也算不上 portable，毕竟你需要 host 有 Word 才行，如果你有 Word，不如直接 VBA、VBS、JScript 或者 PowerShell。

通常来说企业内的 solution 会直接从数据源（ Excel ）使用 VBA 生成可打印结果，可以参考何明科先生的知乎回答。

这个并不是 Windows 弹出来的，检查一下你的启动项

那就从你能考 85 分的年级开始学起呗

硬盘卡在海关

App 更新不都是免费的啊……所以没有一个 universal 的自动更新 app 的功能。

App 可以自己实现更新的功能，或者使用 Microsoft Store 分发。

@dorentus #5 这个说法的根据是啥？从逻辑思考这个想法不是很站得住脚，即使 Google 自己的 JavaScript 引擎解决了 Gmail 的性能问题，如果 Gmail 自己不改善代码，它在其他的浏览器上的性能也没有保障——但是 Gmail 网页版本来就是要让所有的人都能轻松访问 Gmail，如果限制在 Google 的浏览器上，何不推出 Google 自己的客户端来访问（反正，都是 Google 的软件，不差这一个）？

我没有理解您在 C++ 里的操作和 cmd/powershell 有什么关系。

如果你想让你的 C++ 代码使用 UTF-8 编码，用 cl /utf-8 编译。

如果你希望控制台接受一个特定编码的字节流，使用 chcp <code-page>。对于 cmd，当你不用重定向、管道的时候，程序向标准输出、标准错误输出的字节流会原样进入控制台。

对于 PowerShell 情况会比较复杂，因为是面向对象的 shell。分为以下两种情况：

- 如果是 <exe-name> <arg1> <arg2> ... 的形式且没有任何重定向、管道，则程序向标准输出、标准错误输出的字节流原样进入控制台；
- 如果命令是表达式的一部分，则 PowerShell 会猜测标准输出的编码，尝试把它变成一个字符串。

在后一种情况下，如果再把字符串 Write-Host 输出（或者 Write-Object 但是没有用管道、重定向），则 PowerShell 会输出那个字符串—— PowerShell 使用的是 Unicode，所以输出和编码没有关系。

下面的图展示了几种情况。

代码：UTF-8 编码的。

http://wx1.sinaimg.cn/large/8e7092e9ly1fs1v19nh6qj20ij0aw3yx.jpg

情况 1：C++ 程序输出的是 GBK，控制台代码页是 UTF-8，使用 cmd。这时程序输出的字节流直接进入控制台，也就是说会按照 UTF-8 解读 GBK 编码的文本，会是乱码。

http://wx1.sinaimg.cn/large/8e7092e9ly1fs1v42wwrej21kw0fn3zv.jpg

情况 2：C++ 程序输出的是 GBK，控制台的代码页是 GBK，使用 cmd。这时程序输出的字节流直接进入控制台，也就是说会按照 GBK 解读 GBK 编码的文本，会是正确的字符。

http://wx4.sinaimg.cn/large/8e7092e9ly1fs1v4kjruvj21kw0gkta5.jpg

情况 3：C++ 程序输出的是 GBK，控制台的代码页是 UTF-8，使用 cmd。这时程序输出的字节流直接进入控制台，也就是说会按照 GBK 解读 UTF-8 编码的文本，会是另外一种乱码。

http://wx4.sinaimg.cn/large/8e7092e9ly1fs1v4zhudfj21kw0g5mym.jpg

情况 4：C++ 程序输出的是 UTF-8，控制台的代码页是 UTF-8，使用 cmd。这时程序输出的字节流直接进入控制台，也就是说会按照 UTF-8 解读 UTF-8 编码的文本，会是正确的字符。

http://wx2.sinaimg.cn/large/8e7092e9ly1fs1v5ag794j21kw0g50u6.jpg

情况 5、6：C++ 程序输出的是 UTF-8，控制台的代码页是 UTF-8，当前系统 locale 是 2052 （就是 zh-CN，对应默认代码页 936 = GBK ），使用 PowerShell。分别用 外部程序是表达式的一部分 和 单纯启动外部程序 的语法。前者，PowerShell 需要把程序的标准输出变成字符串，程序不是 Unicode 输出，因此 PowerShell 决定使用默认代码页，也就是 936，去解读字节流（ UTF-8 ），得到的字符串（存储为 Unicode ）是乱码 [相当于 字符串 = MultiByteToUnicode(标准输出, locale 对应的编码)] ，再输出这个字符串，自然也是乱码；后者，PowerShell 让程序的标准输出字节流原样直接进入自己的控制台，因此是 UTF-8 解读 UTF-8，看到的是正确的字符。

http://wx4.sinaimg.cn/large/8e7092e9ly1fs1v6o75ssj20w709y0to.jpg

情况 7、8：C++ 程序输出的是 UTF-8，控制台的代码页是 GBK，系统默认代码页 GBK，PowerShell，分别用 表达式 和 单纯启动 语法。无论怎样都会用 GBK 解读 UTF-8，因此是一样的乱码。

http://wx3.sinaimg.cn/large/8e7092e9ly1fs1v70z3r3j20uw0a7t9n.jpg


总结：假设系统 locale 设置的默认代码页是 CPSysLocale，则默认控制台的代码页也是 CPSysLocale，但你可以用 chcp 改变，假设你改成了 CPConsole，最后，假设你的 C++ 程序输出多字节字符串，使用的代码页是 CPProg。

如果用 cmd + 重定向 /管道，则你的输出按原字节进入重定向 /管道目标，和 console 没有关系。

如果用 cmd 输出到控制台，你的输出按原字节进入控制台，CPProg 输出将按照 CPConsole 被解读并显示。

如果用 PowerShell 表达式语法，则你的 CPProg 输出将被 PowerShell 猜测编码，如果它没有 BOM，则会按照 CPSysLocale 解读，变换为 .NET 字符串；再次输出时，输出的是变换后的字符串，因为字符串已经是 Unicode，不会涉及到 CPConsole ；结果就是：CPProg 按照 CPSysLocale 解读。

如果用 PowerShell 单纯启动语法，你的输出按原字节进入控制台，CPProg 输出将按照 CPConsole 被解读并显示。

注意：自 1803 起，你可以设置 UTF-8 (65001) 为 locale 设置的默认代码页，但在 1709 及更早，不行。此外，PowerShell 的表达式语法包括任何有重定向的情况，而且 PowerShell 会帮你分行，但再次输出的时候原来的行尾信息已经丢失，因此用 PowerShell 直接调用外部命令是一个非常非常糟糕的做法。


安利：如果你要小心地操作文件编码，请使用 cmd 重定向+自己转换编码；或者你可以用我的 Use-RawPipeline PowerShell module。见这里： https://github.com/GeeLaw/PowerShellThingies/tree/master/modules/Use-RawPipeline

@geelaw #15 我删除了代码，用 UI 模拟输入是很困难的，因为 explorer 需要时间反应。

现在提出一个新的做法：启动一个程序，该程序打开数个窗口，用户分别把它们放在不同的虚拟桌面上，然后该程序监听热键，并用 SetForegroundWindow 把那个虚拟桌面上的那个窗口激活，这样就可以切换到那个虚拟桌面了。

@hljjhb #11 这个软件的方法很不好，看了一下是用 https://github.com/Ciantic/VirtualDesktopAccessor 实现的。

后面那个东西 tamper with 虚拟桌面的内部接口，虽然 COM 接口以其稳定性著称，但是 IVirtualDesktopManagerInternal 的 IID 从来没有出现在 MSDN 的文档上，所以理论上可以随时消失掉，这样写的程序随时可能在 Windows 10 的更新里面坏掉。

然后用户就会尖叫：为什么 Windows 兼容性这么差？

总结：请使用被文档化的方法，避免你的程序在下一次更新之后突然坏掉。正确的做法是这样的：

1. 注册全局热键，接收消息；
2. 使用模拟 Ctrl+Windows+Left/Right 来切换虚拟桌面。

随手写了一段：

https://gist.github.com/GeeLaw/b7972135b556d994560c798491371146

@lxy #24

关于 GVFS，我突然想不正经地吐槽一下 Linux 世界难道不是大小写敏感的吗？ GVFS 和 GVfs 明明不一样啊。此外，微软已经在考虑改名，并在 GitHub 上征集思路。

关于 IF_MS_BUYS_GITHUB_IMMA_OUT，你可以阅读 issue 8，argue 是微软审查的论据似乎并不是很 solid。

最后，solidot/slashdot 上面 troll 太多。

So scattered

我想不到有什么 universal 的解决方法。

比如可以先告诉我们，想看的是什么样的两篇文章，是 HTML、文本还是 Word 文档？

是想要编辑还是想要阅读？两篇文章之间如何标注对应关系（很明显中文和英文的一段可以不一样长）？

gmtime 的历史意义是 Greenwich Mean Time，虽然这个函数现在的“正名”应该是 cutime, Corrdinated Universal Time.

总结一下：

销售缠人
楼主用了服务不接电话微信不给钱
在工单节点发的只是牢骚，没有包括如下重要信息：谁应该接工单，应该怎么解决

@hyplddfx 虽然我觉得应该不是键盘坏了，但是 #1 认为可能是键盘坏了的原因很简单：坏的键盘可能会错误地产生改变缩放比率的按键消息。

@D3EP #29 请自觉阅读 blogs.msdn.microsoft.com/oldnewthing 了解一下历史，然后用统计推断的知识思考：在不知道其他信息的情况下，应该猜测是谁的问题？

@yhx5768 #38 我的意念力告诉我 Atom 或许在处理用户输入消息的时候有错误。一个正确处理输入消息的程序即使卡住了，也会按顺序正确处理输入，所以当你对很卡的窗口输入一串东西的时候，它会顿一段时间然后出现。

@chocotan #39 我倒是没遇到，但是我遇到了 File Explorer 打开新窗口很卡的情况。

@locktionc #35 我的意念力告诉我以下是可能情况：

- 你启用了“对每个 app 使用不同的输入法”的设置；或
- 焦点变化之后，输入控件建议输入法不要输入非拉丁字母，例如当你把焦点移动到 Edge 的地址栏，由于地址栏的建议，输入法会进入英文模式，如果你用触控键盘，则会出现一些适合输入网址的按键；或
- 你不小心切换了输入法模式。

至于为什么 Google 输入法会失效，我的意念力告诉我你的 Todoist 或许来自 Windows 应用商店并且是一个 UWP/Windows 应用商店应用，而 Google 输入法不支持 Windows Runtime 环境，所以它被取消了候选资格。一个简单的搜索表明，Google 输入法确实不支持 Windows Runtime 环境。

@geelaw *Remove the first comma, change "reboots" to "reboot".