PowerShell通过COM调用时如何确定参数类型？以HTMLFile为例

问题背景 #

我在Windows 10系统中编写兼容Windows PowerShell 5.1和PowerShell 7的脚本，通过COM创建HTMLFile实例：

$dom = New-Object -ComObject "HTMLFile"

尝试调用其write方法时，发现官方文档说明该方法接受System.String类型参数，但直接传入字符串会报类型不匹配错误。用Get-Member查看该方法，显示参数为SAFEARRAY(Variant)。最终通过资料得知需传入UTF-16LE编码的字节数组才能正常调用。

疑问与解答 #

1. 人们是如何得知要传入字节数组的？ #

主要来自三个渠道：

• 社区经验沉淀：早期VBScript、JScript与COM交互的场景中，就存在类似字符串编码不兼容的问题，开发者踩坑后分享的解决方案逐渐在PowerShell社区流传。
• 底层COM原理推导：HTMLFile是IE系的COM组件，其write方法底层实际期望UTF-16LE编码的字节流——Windows系统原生用UTF-16LE存储字符串，但PowerShell的System.String在跨COM边界调用时会触发隐式编码转换，导致类型不兼容；而字节数组能绕过这个转换，直接传递组件期望的原始字节。
• 逆向与内部文档参考：部分开发者通过反编译组件、查看COM类型库的详细定义，或参考微软未公开的内部技术文档，明确了该方法的实际参数要求。

2. SAFEARRAY(Variant)为何没直接说明这点？ #

SAFEARRAY(Variant)是COM的通用参数类型，代表可容纳任意Variant类型元素的安全数组，本身是宽泛定义。官方文档多是基于高层应用场景描述（比如从IE浏览器脚本角度，write确实接收字符串），但PowerShell作为宿主调用COM组件时处于更低层级的交互场景，需要遵循组件底层的实际要求，这类细节通常不会出现在面向应用开发者的公开文档中。

试错也是常见的解决路径：当文档与实际调用不符时，开发者会尝试转换参数类型（如字符串转字节数组、调整编码），直到找到可行方案并分享经验。

3. 未来遇到类似COM调用场景时，该如何确定参数类型？ #

• 查看COM类型库细节：使用Windows SDK工具OleView.exe查看组件的类型库，能获取比Get-Member更准确的参数类型和隐含约定（如编码、数组元素类型）。
• 参考社区实践：PowerShell、VBScript、C#等调用COM的社区中，常见组件的问题大多有现成解决方案，优先搜索类似场景的处理经验。
• 多类型参数测试：当文档与实际调用冲突时，尝试转换参数类型——比如将字符串转为不同编码的字节数组、包装成数组/变体类型，结合错误信息逐步调整。
• 掌握Windows COM编码规则：Windows平台的COM组件大多依赖UTF-16LE编码，遇到字符串相关的类型不匹配时，优先尝试将字符串转为UTF-16LE字节数组后传递。

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