天天看點

快來測試下你的輸入法正不正經 - 一個@引發的血案正在上映~

事情是這樣式兒滴~~~~

在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位址:​​不正經位址傳送門​​

上效果圖:

繼續閱讀