这是一个创建于 1891 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如说有这样一个 URL
/api/v1/user/NRbFH9wuGFGXjRMxy
可以理解成 NRbFH9wuGFGXjRMxy 是一个用户的 ID 了吧，怎么才能识别出 URL 中这类复杂 ID 或者是 Token 的部分呢
md5 uuid 做正则匹配，很单一算是方式之一，但是不够，会漏很多
用类似 nostril 这种库判断是不是随机字符串，但是判断效果也不是很好，而且训练好之后，如果不重新增加样本数据，就可能导致一类随机字符串上边说的 id 或者 token 是识别不出来的
想了 api，user 这种在大量 url 中出现次数肯定很高，NRbFH9wuGFGXjRMxy 出现次数肯定很低，然后利用这个做区分，但是拿到流量之后看了下，有不少接口字段出现的也是很低的很难和这类 ID 变量区分开
有什么好办法或者思路可以解决这个问题么
 |
1
ysc3839 2019-09-04 18:52:30 +08:00
先做分词，比如你给的例子可以分成 api, v1, user, NRbFH9wuGFGXjRMxy，然后建立一个“不是随机字符串”的表，比如表里面有 api, v1, user，把这些去掉，剩下的就是“随机字符串”了。
|
 |
2
to 2019-09-04 18:53:04 +08:00 via Android
你可能想复杂了。其实只要判断一个字符串不是自然文本就行。dump 个词典库，写个 rule based 的代码就行。
|
 |
3
chairuosen 2019-09-04 18:57:14 +08:00
Google 去搜，搜不到就是随机字符串。手动 doge
|
 |
4
sipangzi OP @ysc3839 做了分词，统计了 15 万条 url 的结果，前 600 个字段里没有随机字符串，随机的分布在 600-末尾 2000 之间，api 这种确实出现次数很多，但 refundModify 或者 reqRepayState 类似这种，出现次数和 NRbFH9wuGFGXjRMxy 的出现次数都是 1 和 2 左右，并且 1 和 2 的词特别多，很难自动建立这么一个表，辅助 nostril 后确实能识别出 refundModify 这种的不是随机字符串，但是也不是很理想，没想到更好的解决办法
|
 |
5
momocraft 2019-09-04 18:58:11 +08:00
不要指望一个正则搞定，不要指望 100%置信度搞定
多加些特征，比如在字典中出现 0 次加一分，匹配 /[:alpha:][:digit:]/ 2 次加一分 |
 |
6
hst001 2019-09-04 19:00:37 +08:00 via Android
突然想到个小概率问题，如果生成的随机串刚好是个单词，请问是随机的还是不随机的
|
|
7
sipangzi OP @to nostril 是检查是不是自然文本的库，单纯依赖这种可能导致样本或者词典少导致有些没有匹配到，然后数据量很大，人不会一直去看有没有漏下的，匹配出现问题的，可能就会一直有问题，所以想能不能有什么方式根据字段出现的频率或者很多 url 相似度做一些工作，让程序动态的做些调整，但是没有想出个好思路
|
|
8
sipangzi OP @momocraft 嗯，就是想能不能根据字段出现的频率或者很多 url 相似度，发现实际测试的数据不是很理想，不知道怎么把各种方式判断的结果结合起来了
|
|
9
ysc3839 2019-09-04 19:39:41 +08:00
@sipangzi 没什么好办法的，人工判断基本上也是类似的规则，只不过人脑中已经有了庞大的词汇库。对于 refundModify 可以额外加一些规则，比如不是连续大写字母。
|
 |
10
sutra 2019-09-04 20:07:44 +08:00
“ refundModify ”，在分词时，是不是分成“ refund ”和“ Modify ”就解决了？
|
|
11
momocraft 2019-09-04 20:18:10 +08:00
最簡單是加起來看看效果怎樣
如果你很閒可以訓練一個模型... |
 |
12
aguesuka 2019-09-05 00:39:33 +08:00 via Android
正常单词元音出现的几率远远高于期望值。先解码成 path /path key value 的形式，让后对每个单词判断元音几率，短单词可以自己建个库
|
Select Language