Ruby中gsub使用$1/$2/$3插值失效的解决方法求助

问题场景 #

用户编写的Ruby代码中，使用gsub进行正则替换时，替换字符串里的$1、$2等捕获组占位符未被正确解析，直接输出了原占位符文本。相关代码及运行结果如下：

原代码 #

$str = '909090 aa bb cc dd ee ff 00 12345678 aa bb 12345678 aa bb cc dd ee ff 00 11 22 33 123456 FE 89'
puts $str
$str.gsub!(/\s+/, '')

search_1  = 'aa bb cc dd ee ff 00 (\S{8} aa bb \S{8} aa bb cc dd ee ff 00 11 22 33 \S{6}) (FF|FE) (89)'
puts search_1
search_1.gsub!(/\s+/, '')
replace_1 = '11 22 33 44 55 66 77 $1 $2 $3'
puts replace_1
replace_1.gsub!(/\s+/, '')

repls_1 = [
  [search_1, replace_1],
]

repls_1.each do |x|
  abc = $str.gsub(Regexp.new(x[0])) {
    x[1]
  }
  puts abc
end

原运行结果 #

909090 aa bb cc dd ee ff 00 12345678 aa bb 12345678 aa bb cc dd ee ff 00 11 22 33 123456 FE 89
aa bb cc dd ee ff 00 (\S{8} aa bb \S{8} aa bb cc dd ee ff 00 11 22 33 \S{6}) (FF|FE) (89)
11 22 33 44 55 66 77 $1 $2 $3

90909011223344556677$1$2$3

用户核心需求：

• 必须使用$1、$2这类占位符，禁止使用\1、\2格式
• 支持多组替换模式批量处理
• 适配捕获组数量、位置不固定的场景（比如出现$1...$3...$5这类跳号的情况）

解决方法 #

问题本质是：当gsub使用块形式时，Ruby不会自动解析替换字符串中的$n占位符，需要手动结合Regexp.last_match获取捕获组内容，完成占位符的替换。

修改后的代码如下：

$str = '909090 aa bb cc dd ee ff 00 12345678 aa bb 12345678 aa bb cc dd ee ff 00 11 22 33 123456 FE 89'
$str.gsub!(/\s+/, '')

# 多组替换模式示例，可按需扩展
repls = [
  [
    'aabbccddeeff00(\S{8}aabb\S{8}aabbccddeeff00112233\S{6})(FF|FE)(89)',
    '11223344556677$1$2$3'
  ],
  # 新增带跳号捕获组的测试模式
  [
    '(\d{6})(\S{8})(\S{8})',
    '替换后$3$1'
  ]
]

repls.each do |pattern, replacement|
  regex = Regexp.new(pattern)
  $str = $str.gsub(regex) do
    result = replacement.dup
    # 匹配所有$数字格式的占位符，替换为对应捕获组内容
    result.gsub!(/\$(\d+)/) do
      group_num = $1.to_i
      Regexp.last_match[group_num] || $& # 捕获组不存在则保留原占位符
    end
    result
  end
end

puts $str

代码说明 #

1. 捕获组插值逻辑：在gsub的块中，通过Regexp.last_match获取当前匹配的所有捕获组内容，再用嵌套gsub!遍历替换字符串中的$n占位符，将其替换为对应的捕获组值。
2. 适配跳号场景：通过正则/\$(\d+)/匹配所有$加数字的占位符，即使出现跳号（如$1和$5共存），也能精准定位对应的捕获组内容。
3. 多模式支持：将替换规则以数组形式存储，遍历即可批量处理多组替换需求，扩展性强。

预期运行结果 #

执行代码后，原字符串中的目标片段会被正确替换，$1、$2等占位符会被对应的捕获组内容替代，比如第一组替换后，原$1$2$3会变成匹配到的12345678aabb12345678aabbccddeeff00112233123456、FE、89，最终输出符合预期的替换结果。

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