PowerShell处理wsl输出时IndexOf可匹配但-match失效问题

这个现象是两个逻辑叠加导致的，和你猜测的编码问题直接相关：

• 解码错误引入NUL空字符：wsl.exe有个已知行为：当检测到输出被重定向（不是直接打印到控制台窗口，比如被PowerShell捕获到变量、通过管道传递）时，会默认使用UTF-16LE编码输出内容。而Windows PowerShell 5.1默认使用系统OEM代码页（简体中文环境为CP936，英文环境为CP437）解码原生命令的输出流，解码错误会在生成的字符串中（通常是靠前的位置）混入不可见的NUL空字符（ASCII码0，对应转义字符\0）。
• 两个匹配方法的逻辑差异：
  • PowerShell的-match运算符底层调用.NET正则表达式引擎，在Windows PowerShell 5.1版本中，正则匹配扫描到字符串中的NUL空字符时会直接终止，不再扫描后续内容。你测试时kernel子串出现在字符串偏移412的位置，而NUL字符在更靠前的位置，所以匹配直接终止返回False。
  • String.IndexOf()方法是逐字符遍历字符串的完整内存长度，不会被NUL字符截断，因此可以正常扫描到字符串靠后位置的kernel子串，返回正确的位置索引。

你之前修改[Console]::OutputEncoding、调用转码方法没生效，核心原因是没有在捕获WSL输出前就把解码编码设置为和WSL输出一致的UTF-16LE（即.NET里的Unicode编码），后续对已经解码错误的字符串做转码，无法消除已经混入的NUL字符。

• 方案1：正确捕获wsl --status输出
  临时修改控制台输出编码为Unicode，捕获完输出后还原原有配置，即可正常匹配：

  # 保存原有编码配置
  $oldOutputEncoding = [Console]::OutputEncoding
  # 设置为WSL重定向输出使用的UTF-16LE编码
  [Console]::OutputEncoding = [System.Text.Encoding]::Unicode
  # 捕获输出，注意wsl --status默认输出到stderr，需要用2>&1合并流
  $wslStatusText = wsl --status 2>&1 | Out-String
  # 还原原有编码
  [Console]::OutputEncoding = $oldOutputEncoding
  
  # 此时可以正常匹配，兼容中英文系统
  if ($wslStatusText -match '(内核版本|Kernel version)\s*[:：]\s*(?<version>[^\r\n]+)') {
      $kernelVersion = $matches.version.Trim()
  }
  

• 方案2：直接读取WSL内核文件版本（无编码问题，不受系统语言影响）
  WSL2的内核文件默认存放在系统目录，直接读取文件版本信息不需要解析命令输出，兼容性最好：

  $kernelFilePath = Join-Path $env:WINDIR 'System32\lxss\tools\kernel'
  if (Test-Path $kernelFilePath) {
      $kernelVersion = (Get-Item $kernelFilePath).VersionInfo.ProductVersion
  }
  

• 方案3：直接调用WSL内的uname命令获取
  直接通过wsl执行Linux原生命令获取版本，不需要解析状态文本：

  $kernelVersion = wsl uname -r
  

内容的提问来源于stack exchange，提问作者Zé Cláudio