天天看点

快来测试下你的输入法正不正经 - 一个@引发的血案正在上映~

事情是这样式儿滴~~~~

在IM工具、Wiki文档中我们经常使用​

​@​

​​符号来做提及人、提及文档的功能,最近胡哥就是在做这个业务需求的时候被​

​@​

​这个符号坑惨了。

PM想要的效果大概是这样:当用户输入​

​@​

​后,能够响应一系列的推荐结果。

快来测试下你的输入法正不正经 - 一个@引发的血案正在上映~

沟通完需求,PM习惯性的描述了老板催的紧,要排期,我在脸上努力挤出一副苦大仇深的样子,不情不愿的说道“我争取1天完成吧”,内心则甚是窃喜:“就这功能,监听个keydown事件,判断是@符号不就完了!半天时间足够了,还能摸鱼半天,哈哈哈~”

TIPS: 这里后端接口是已经完备的,所以没什么阻塞需求的地方。

整活,提测~

项目是vue环境下,没别的,监听键盘事件,开始整活~

<template>
  <input type="text" @keyup="atHandler" />
</template>

<script>
export default {
  methods: {
    atHandler (e) {
      // 使用e.keyCode来判断是否是@符号 ===> 50
      // 或者使用ascii码值 64表示@符号,使用charCodeAt()转为Unicode字符,ASCII码
      switch (e.keyCode) {
        case 50:
          if (e.key === '@') {
            // balabala...
            console.log('你按下了@符号');
            // 处理业务逻辑
            // 唤起提及人浮窗
          }
        break;

        default:
        break;
      }

    }
  }
}
</script>      

本地测试没问题,Call测试同学,提测,走你,开始​

​摸鱼~​

​。

附ASCII码表:

快来测试下你的输入法正不正经 - 一个@引发的血案正在上映~

测试 - 天生具备BUG体质

整摸鱼开心,忽然看到IM上,测试同学在Call,说是有BUG!输入​

​@​

​符号后,无法唤起提及人浮窗!瞬间就懵逼了!

和测试一顿拉扯,最后测试同学提交了一份视频,明明白白有这个现象,确实没有唤起浮窗!

又找了些其他同学的电脑,进行了相同的测试,发现都没有问题。而且这段代码逻辑确实非常简单呀,既然有能唤起的,说明逻辑是正确的,但是在测试同学的电脑上是100%复现的,对她来说这个功能就是100%不可用的。

本着用户体验之上原则,在测试同学电脑上专门debug了一下,打印了​

​@​

​​的​

​e.keyCode​

​​竟然不是​

​50​

​​,而且通过​

​charCodeAt​

​​转换出来的ASCII码也不是​

​64​

​!!!。

每个字符都会对应相应固定的ASCII码,Unicode字符呀,怎么还有不一致的时候呢?!

这不应该呀,这就相当于​

​1+1​

​​忽然间不等于​

​2​

​了。

这真是离了个大谱!!!

简直挑战了一个前端开发的底线了有没有~~~

坑爹的输入法

当问题出现的时候,没有任何一个环节是无辜的!

复现该测试同学的所有环境:

  1. ​windows​

    ​​电脑

    印象中也没有关于windows电脑会有这个兼容性呀!本着宁杀错,不放过原则。对照组实验搞起来!

    找了另外2台windows电脑,都没有复现这个BUG!

    说明了Windows系统没有关系呀!

这个时候,稍稍感觉今天被针对了,什么莫名其妙的BUG!
  1. 输入的@符号会有不同吗?看起来是一样的呀!

    感谢伟大的“实事求是”精神,测试出BUG的同学使用的是​

    ​QQ拼音输入法​

    ​,其他Windows电脑使用的是​

    ​搜狗拼音输入法​

    ​,现在输入法成了新的实验变量。

    快速的安装了​

    ​QQ拼音输入法​

    ​,果然,BUG必现!
为啥这个问题,这么不好找呢。是因为QQ拼音输入法不支持在Mac上用,相对搜狗比较小众些。
  1. 此时此刻,可以看到输入的都是​

    ​@​

    ​字符,肉眼无法分辨,但是从根本上来说,这个​

    ​QQ拼音输入法​

    ​输入的字符绝对不是标准的​

    ​@​

    ​对应的Unicode字符。
如果有搞测试输入法的同学,一定不吝赐教,给解释下!

问题原因定位了,既然没有办法让所有的用户都不用QQ拼音输入法,即使能,也可能存在其他输入法引起这个问题!只能做兼容性处理了,为了安全起见,让测试的同学安装测试了市面上常见的输入法!

以下是常见输入法在不同系统输出@字符的keyCode值和ASCII码值

输入法名称 系统 key值 keyCode值 ASCII码值
ABC输入法 MAC @ 50 64
简体拼音输入法 MAC @ 50 64
搜狗输入法 MAC @ 50 64
百度拼音输入法 MAC @ 50 64
百度拼音输入法 Windows Process 229 66
微软拼音输入法 MAC @ 50 64
微软拼音输入法 MAC @ 50 64
QQ拼音输入法 Windows Process 229 66
讯飞输入法 Windows Process 229 66
欢迎大家补充

兼容方案处理

在使用keyCode监听时,除了​

​50​

​​之外,同时监听​

​229​

​,保证各个输入法下都能正确响应事件。

export default {
  methods: {
    atHandler (e) {
      switch (e.keyCode) {
        case 50:
        case 229:
          if (e.key === '@' || e.key === 'Process') {
            // balabala...
            // 处理业务逻辑
            // 唤起提及人浮窗
          }
        break;

        default:
        break;
      }

    }
  }
}      

提交测试,完美通过!继续摸鱼!

快来测试下你的输入法正不正经!!!

在排查BUG的过程中,非常有意思的一个体验!我也写了个Demo程序来测一测你的输入法是不是正经输入法!希望你再遇到相同需求的时候,不会手忙脚乱!

码上掘金地址:

代码片段

CodeSandBox地址:​​不正经地址传送门​​

上效果图:

继续阅读