文本抓取的软件调研

(包含: TSF、GetWindowText、UIA 技术等)

EmEditor 的 Grab Text

参考

• EmEditor 的 Grab Text 功能: https://zh-cn.emeditor.com/text-editor-features/more-features/grab-text/

开始方式

不过相关设置挺难找的。善用搜索功能，例如我最开始没找到在哪，我在 菜单帮助 > 搜索选项 > 抓取 中才找到这个功能，然后又搜了托盘

具体是: 菜单工具 > 快捷方式 > 勾选在任务栏显示托盘图标 并 点击自定义托盘图标 > 使用EmEditor抓取文本的快捷键处设置快捷键。快捷键如官方示例的 Ctrl + Alt + X

通用性测试

Obsidian	❌	为窗口名 文本抓取的软件调研 - MdNote_Public - Obsidian 1.12.7
Firefox	❌	为窗口名 AnyMenu Browser App — Mozilla Firefox
Chrome	❌	为窗口名 8 - Google 搜索 - Google Chrome
Notepad--	❌	为窗口名 H:\ResDefault\Downloads\csv2table.js [文本模式] - Ndd
EmEditor	✅	(暂时与软件内快捷键冲突，不过根据 SuperTextCopyer 的测试来看，应该是也成功的)
记事本	✅	成功，无需选中目标文本，写回也没有问题

SuperTextCopyer (超级文本复制器)

参考: https://www.xitongzhijia.net/soft/183130.html

通用性测试

Obsidian	❌	0x00090B6A Chrome_WidgetWin_1 Ceneric [通用] 文本抓取的软件调研 - MdNote_Public - Obsidian 1.12.7 0x0056170E Chrome Legacy Window Ceneric [通用] (无)
Firefox	❌	0x00C918A4 MozillaCompositorWindowClass Ceneric [通用]
Chrome	❌	0x01B110AA Chrome_WidgetWin_1 Ceneric [通用] 8 - Google 搜索 - Google Chrome
Notepad--	❌	0x00311CBE Qt5152QWindowIcon Ceneric [通用] H:\ResDefault\Downloads\csv2table.js [文本模式] - Ndd
EmEditor	✅	成功 0x00860592 EmEditorView Ceneric [通用] test text
记事本	✅	成功 0x00141B58 RichEditD2DPT Ceneric [通用] test text

(列表中的相关备注分别是: 句柄、子类、类型、文字(可能无))

GetWindowText

参考: https://www.52pojie.cn/thread-1958105-1-51.html
https://wxjyxlwmh.lanzouo.com/b00mop5feh 访问码 解压码 52pj

通用性测试

略，其与 SuperTextCopyer 拥有几乎相同的结果

Inspect.exe / AccessibilityInsights

在测试了前面的软件后，突然想起来两个软件: PixPin/Snipaste。
虽然这两个不是获取文本，而是获取范围。但话说他们的选框会比前面的 SuperTextCopyer 和 GetWindowText 更细致。应该是用了 UIA 而非使用 GetWindowText 作为主要 api 的原因。

然后我就找了下相关的 uia 调试插件。发现有微软官方工具:

参考: https://learn.microsoft.com/zh-cn/windows/win32/winauto/inspect-objects

其有一个提示:

Note

检查 (Inspect.exe) 是旧工具。 建议改为 辅助功能见解 (AccessibilityInsights)。

所以我们就不管 Inspect.exe 了，只看后面那个。

用起来挺方便的，也挺清晰的。能得到的选区结果和 PixPin/Snipaste 差不多。

几个快捷键:

• Shift+F7 开始/关闭录制，监听事件。
  Start or stop event recording for the selected element.
• Shift+F8
  Run tests on the selected element.
• Shift+F9
  Bring Accessibility Insights for Windows to the foreground or minimize it.

通用性测试

很难区分，也是就像截图软件那种 BoundingRectangle 识别那种应用场景中，才能相对好用。

• Obsidian | 特定环境下能看到大概的文本内容。当然，链接、表格等都看不到，格式和是否换行等也看不到。选中文本状态看不到。
• Firefox | 只能看到与鼠标最接近的那个元素的文本内容。细节看不出来，标题类别能区分
• 记事本 | 看不到。细节元素倒是能识别到列表元素，但内容是什么同样看不到。

AI 调研

帮我调研一下是否存在windows软件，可以获取任意其他软件中当前的编辑器环境（包括光标以外的文本内容），并显示出来或其他用途。

我主要是想判断是否存在该api，据说 windows tsf api 可以，但我持怀疑态度。所以帮我看看有没有软件能做到这点，我下载来看看是否真的能做到以及能做到什么程度，获取时延迟多少等等

---

Deepseek-v4:

你提到的用TSF API获取其他软件编辑器内容，这件事是可行的，但也存在严格限制。

✅ 现有软件实例

确实存在利用类似技术实现此功能的软件，你可以下载亲测：

• EmEditor (抓取文本功能)：专为文本编辑器设计，可抓取其他编辑器选中的文本进行编辑并自动回填。这是最接近你设想的案例，但前提是目标软件需主动选中了文本。
• WindowTextExtractor：开源免费工具，通过拖拽可提取任意窗口（按钮、文本框等）的文本。但它通常只能获取控件静态文本，不一定能拿到编辑器里动态变化的内容。
• GetWindowText：经典小工具，基于GetWindowText API，能读取标准窗口控件文本。局限同上。
• SuperTextCopyer：类似的文本提取工具。

🧠 TSF API 的原理与局限

TSF是Windows管理文本输入的高级框架，主要用于输入法、语音识别等。作为Text Service，确实可以读取（甚至写入）支持TSF的应用程序中的文本内容。

⚠️ 但关键限制在于：目标应用必须主动支持TSF接口。现代主流软件（如记事本、Office、浏览器）通常支持，但很多老旧或自定义控件软件可能不支持，此时TSF方案将完全失效。

⚡️ 关于延迟

• 用户主动触发：像EmEditor那样由快捷键触发，几乎无感知延迟。
• 后台持续监控：若想“实时”监控，性能消耗和延迟会显著增加。频繁跨进程通信获取文本对性能是考验，具体延迟高度依赖目标软件复杂度和当前系统负载。

💎 总结

这类软件确实存在，主要通过两条技术路径实现：

1. UI自动化/Accessibility API：如WindowTextExtractor，通用性强但获取内容有限。
2. TSF API：如EmEditor，能获取深层编辑器内容，但前提是目标软件必须支持TSF。

建议你先下载 EmEditor 和 WindowTextExtractor 亲测，感受它们在理想情况和通用情况下的表现差异。如果对技术细节感兴趣，可以研究微软官方文档中的 UI Automation 和 Text Services Framework。

知识补充

技术对比：UIA vs. GetWindowText

by Deepseek-v4:

• GetWindowText / 窗口句柄 (HWND) 方式
  这是SuperTextCopyer和GetWindowText等工具的基础。它通过窗口句柄（HWND）来获取信息。这种方式非常粗糙，局限性很大：
  • 它只能获取顶层窗口或标准控件（如按钮、静态文本）的标题。
  • 对于复杂应用（如浏览器、Qt 或 Electron 应用）内部的文本编辑器、菜单等，无法获取其内部结构或具体内容。
  • 你遇到的 Chrome_WidgetWin_1、Qt5152QWindowIcon 等类名无法被精确识别，正是因为 GetWindowText 只能“看到”最外层的容器窗口。
• UI Automation (UIA) 方式
  这是PixPin、Snipaste等现代工具的选择。UIA是微软为辅助功能（如屏幕阅读器）和自动化测试设计的强大框架。它的核心优势在于：
  • 不依赖窗口句柄：能直接与应用程序的逻辑UI树交互。
  • 精细的元素识别：可以将一个窗口拆解为树状结构，识别出其中每一个独立的UI元素，如按钮、输入框、菜单项，甚至是文本的特定段落。
  • 丰富的属性信息：不仅能获取文本，还能获取元素的位置、大小、类型、状态（如是否可见、是否可点击）等关键信息。