Oracle APEX Report中JS匹配带特殊字符label的optgroup返回0的问题

• 硬写属性选择器匹配带非ASCII变音字符的label值时，存在两个极易触发匹配失效的场景：
  • 字符串编码不一致：视觉上完全一致的Privé，在底层存在两种不同的Unicode编码形式：单字符预组合的é（U+00E9）、e加独立重音组合符号的双字符形式（U+0065 + U+0301），两种形式的字符串做严格相等判断时结果为false。手动输入的选择器里的é，和DOM中optgroup标签实际存储的label属性编码对不上时，无论加不加反斜杠转义，都无法匹配到节点。
  • 误加无意义转义：代码里写的Priv\é里的反斜杠，是CSS选择器用来转义#、.、[这类特殊语法字符的，对普通Unicode字符加这类转义，不仅没有增强兼容性，还可能导致jQuery解析器中断后续选择逻辑，进一步降低匹配成功率。

• 完全绕开硬编码字符串的严格匹配逻辑，改用宽松过滤的方式获取目标节点，从根源规避编码差异问题：
  1. 先选中容器下所有optgroup，通过内置过滤方法筛选目标组，同时对字符串做编码归一化处理，彻底消除不同é编码形式的差异：

     // 获取目标optgroup下的option数量
     const optionCount = $('#obs_ir_oot_objecten_saved_reports optgroup')
       .filter(function () {
         // 归一化所有字符为统一编码格式，再做包含判断
         const normalizedLabel = $(this).attr('label').normalize('NFD');
         return normalizedLabel.includes('Priv');
       })
       .find('option')
       .length;
     prompt(optionCount);
     

  2. 如果必须使用原生属性选择器做匹配，不要手动输入带特殊字符的选择字符串，直接从浏览器DevTools的Elements面板复制optgroup的实际label值粘贴到选择器中，确保两边的编码完全一致。
• 注意：不要在非ASCII字符前手动加反斜杠转义，这类操作对Unicode字符的匹配没有任何正向作用，反而容易引入解析错误。

内容的提问来源于stack exchange，提问作者Gerben Jan Dijkman