sky91.cn

use `ngnix base auth`

大体想了一下，也不尽然是需要汉字匹配的。 因为按照需求的角度来说。 completion suggester 所完成的是一个“快速建议”的 工作。 目的是为了把用户输入的内容进行一个快速过滤，仅仅是过滤一遍有没有类似的内容，一般是通过前缀匹配的方式。 而当使用completion suggester和pinyin插件结合之后，汉字转为pinyin，在pinyin维度，已经没有汉字的识别性，所以也就不存在“像”和“想”不同，只是“xiang”和“xiang”的匹配。 如果你需要在completion suggester的基础确定要加一个类似于前缀匹配汉字的步骤，可以看下 [context suggeter](https://www.elastic.co/guide/en/elasticsearch/reference/current/suggester-context.html)

不过我还是得提醒，suggester的目的是通过找寻一个专有词库来抛出用户可能想要搜索的内容。。而不是用户一定要搜索的内容。。 这句话的意思是说，假设用户拼音打对了，但是汉字选错了。 比如他想搜索“二级”，结果输入“erji”后输入法选择了“耳机”，这时候你因为完全匹配，推荐的都是“耳机的内容”，与用户期望不符合。 所以，关于这一步，我不建议去强制完全匹配。你只需要给出默认completion suggester的结果即可。 更应该关注的不是suggester的过程，而是结果的反馈，用户选择的什么才是更为关键的。。 你的目的是帮助用户快速的选择符合他心里预期的，而不是你以为他要的。 收集用户在你建议后的行为，诸如选择某个你推荐的值，或者重新输入了内容。 前者你应该把你推荐的那个值的weight提升，后者你应该考虑用户输入的内容是确实没有，还是你推荐的有问题。。 --- 反馈，往往的判断搜索结果的更为靠谱的指标。。 而不是“我以为”。

之前写过的一个分析。可以参考下。 https://github.com/occultskyrong/zzone/blob/master/doc/3.0_ElasticSearch/3.0_/ik%2Bpinyin.md

至于这个建议的词库从何而来，不建议直接把内容进行suggester，而是采集用户输入的内容，根据他的反馈。 尤其是第二步的反馈，当某个用户输入pinyin，选择某个建议词进行搜索后，在搜索结果页进行操作，此时需要采集他的信息，比如他点击了第n个，是否产生了跳页行为。 这个时候，先收集他选择的关键词和这个关键词对应的有意义的结果的数量。 前者关键词作为词库的一个元素，后者作为weight的衡量指标。通过分析用户的搜索日志，比如分时，每7、30、90、180天进行一个分数的运算。 比如180天A这个词搜了10遍，90天A这个词搜了5遍，30天搜了3遍，7天搜了1遍，那`weight = 10*1+5*2+3*5+7*10`来运算，具体的公式可以自己调整。 然后把A这个词收集起来形成一个专有的词库，以后的suggester根据这个词库来。 则更为准确，因为这是用户自己去搜索的内容。

In markdown file config like this ... ```config ``` also not working

i think it's something wrong with 'Markdown All in One' Just search "Markdown › Extension › Toc: Update On Save" in "Extension" config Set it "false" , problem solving

对了，补充两句，你这个css最后版本是在‘2015-02-09 v2.8’发布的，所以时间较长，不知道这一年你是否兴趣不在此，在鼓捣一些其他的东西，接下来这个css是否还有兴趣去维护？ 其次是css转sass的问题，必然会产生对过往版本的兼容考虑。。。。 最后，感谢。

哦

看了下，这个好像只有中国国内的，我之前国内的边界，也是从高德接口拿到的