昔のasearchは全角文字に弱かった
from @imo
推測ですが文字コードを8bitずつに分割しているからかもしれません
昔のasearchライブラリは8bitずつでしたが現在はUnicodeを利用しており、8bitずつの処理は無いはずです 
まじですか
はい!
てことはshokai/node-asearchは古いコードということですか
PRだそうかな～
いえ、現在のNota製品ではUnicode版が使われており、ライブラリも更新するよう言ったはずです
てことは更新忘れですかね
最終更新が5年前だ
coffeescriptを使った古のコード
げ、だとするとマズいですね
もしかするとGitHubにアップしそこねてるのかもしれません
なるほ
ちょっと確認してみます
お願いします！
やっぱり 
が更新してなかった模様
違います。さんが私にpull request出してなかっただけです
連絡はしてましたがプルリクは確かに出してませんでした
forkとか全然見ないので今まで気づかなかった
ありゃ、そうだっけ...
shokaiがcoffeescriptのメンテしたくないのかもしれませんな
まあですよねー
あれ？とするとScrapboxの検索で
spy に対して 印象 が出るのはなぜ？む、Scrapboxで古いライブラリが使われてる可能性はありますね
Helpfeelは直したはずなのだけど
とりあえずissue投げておきました
オッケーです！
試しに画像に出ている「印象」を8bitずつにばらしてみると……
印象 → \u5370\u8c61 \u0053\u0070\u008c\u0061 → Sp\u008ca うんやっぱりそうだ
入力文字列
spy と Sp\u008ca が大文字小文字無視かつ一文字間違い( y と \u008c )で部分一致しているから、 印象 が候補に入るふ～～む？文字コードについては全くの素人なのでまたもうちょい時間をかけて理解に努めるか
教えてくれてありがとう！
今まで文字コードは「それぞれの文字にはそれに対応する番号が割り振られているよ～」程度の認識だったので、今ちょい浅～く調べてUnicode一覧 0000-0FFFを眺めていたのですが、以下の認識で良いでしょうかね？
一部には1つのコードに2文字以上の組み合わせが割り振られている（
U+0000:NUL とか U+0001:SOH とか）いや、これは文字ではありません。制御文字、エスケープシーケンスと言われるもので、文字列処理において特別な命令を指し示すものです
よく使われるものが改行文字
U+000D や水平タブ U+0009 でしょうかprogram中の文字列内でよく
\n や \t と表されるやつですお、了解です
で、その中のひとつとして
Sp\u008ca があるみたいな
それでちょい気になったこととして、
u008ca というコードが上記のUnicode一覧の中に見当たらないのですが、これってどういうコードなんでしょう？あーごめんなさい。文字コード自体と、文字コードが表す文字とを混同してました
\u008c という書き方は、JavaScriptで文字コードで文字を表現するときのやり方です。e.g.
const str = '\u0053' とすると、 str==='S' となる Sp\u008ca は、文字 S , p , \u008c , a をつなげた文字列を表しているつもりでした \u008c を文字コードで表現していたのは、該当文字が存在せず文字で表しようがなかったからですあーコードの
\u0061 は文字の a としてってことですか、なるほどしかしまあこんな偶然があるもんだ
確かに
spya と入力しても出ますね～おもしろ
時間がいくらあっても理解しきれません……
なるほどな～ｗ
面白い
asearchは非アルファベット？に弱い？
文字コードをビット演算するだけのシンプルな仕組みですからね
形態素解析を導入すれば、ローマ字から非アルファベットを検索することも可能になるかもしれませんが、逆に検索速度が落ちてしまうでしょうね
上の方に書きましたが弱くないです
仕事速い
もうspyで印象が引っかからなくなった！
