加拿大法语区Access生成文本复制至SAP偶发重音字符显示异常

• 首先明确核心事实：数据库、Access界面显示的文本完全正常，说明源数据没有损坏；出现的é是法语小写e（é）的标准HTML十进制实体编码，异常100%出在文本从Access写入剪贴板、再被SAP读取的编码转换环节，和存储层无关。
• 偶发触发、数天后重发即恢复的特性，完全匹配「第三方程序临时篡改剪贴板内容格式」的特征：Windows系统剪贴板会同时存储同一段文本的多份格式副本（Unicode纯文本、ANSI纯文本、HTML格式、RTF格式等），不少常驻工具（划词翻译、OCR插件、剪贴板增强软件、第三方输入法的云剪贴板）会给剪贴板挂监听钩子，碰到带非ASCII的重音字符时，会自动把这类字符转成HTML实体做占位，这就是é的来源。等这些工具临时退出、或者系统重启清空了剪贴板钩子，再复制就不会被篡改，和观察到的现象完全一致。
• 当前版本组合刚好踩了已知bug的重合点：
  • Win10 1909版本本身存在剪贴板格式降级的已知问题：频繁切换不同语言输入法时，会偶发丢失Unicode格式的剪贴板副本，系统自动降级生成ANSI格式的纯文本，一旦代码页匹配错误，重音字符就会被替换为异常占位值
  • SAP GUI 750是从ANSI架构向Unicode架构过渡的版本，对剪贴板内容的解析逻辑有bug：如果剪贴板里同时存在纯文本副本和HTML格式副本，SAP会优先读取HTML副本的内容，这时候副本里的实体编码会被原样写入字段，不会自动转回原字符

• 从Access侧绕开多格式剪贴板的默认写入逻辑，强制写入单格式的Unicode文本：不要使用Access自带的RunCommand acCopy复制逻辑，改用Win32 API直接操作剪贴板，流程是打开剪贴板句柄→清空所有现有格式的剪贴板内容→以CF_UNICODETEXT格式写入目标法语文本→关闭剪贴板句柄。这种方式生成的剪贴板内容没有附带HTML、RTF等额外格式，既不会被第三方钩子篡改内容，也不会触发SAP读错HTML副本的bug。
• 排查本机的剪贴板类常驻程序：梳理当前机器的开机自启列表，重点排查划词翻译、屏幕OCR、剪贴板管理工具、第三方输入法的云同步剪贴板功能，在碰到复制异常时逐个临时退出验证，找到具体篡改剪贴板内容的程序后，关闭它的剪贴板监听权限或者禁止开机自启。
• 升级SAP GUI 750的补丁版本：这个版本读取含HTML实体的剪贴板内容时不做转译的问题，已在后续补丁中修复，只要把SAP GUI补丁升级到Patch12及以上，SAP会自动把剪贴板里的HTML实体转成对应的Unicode重音字符，不会把é这类值直接写入描述字段。
• 长期稳定方案：完全绕开剪贴板流程，通过SAP Scripting接口直接给目标字段赋值。VBA代码里只要引用SAP GUI的对象模型，定位到当前打开的SAP窗口、对应描述字段的输入框，直接把正常存储的法语重音文本赋值给控件的Text属性即可，不需要走复制粘贴步骤，从流程上彻底规避所有剪贴板编码兼容问题。

内容的提问来源于stack exchange，提问作者Peter