允许使用(+)登录用户名的用户登录的API [英] API to allow user with a (+) signed in their username to log in

问题描述

当前，由于(+)号，使用[e-mail]之类的电子邮件的用户无法通过API.当使用这样的用户ID进行数据库调用时，它将带来结果.但是，在进行这样的api调用时.

Currently right now, user with an email such as [e-mail] are not getting through are API because of the (+) sign. When making a database call with such a user ID, it brings results. However, when making an api call such as this.

api.hq.org/user?token=1234567&username=[e-mail]

它不会带来任何结果.我正在尝试找到一种方法来允许此类用户返回结果.我知道它的URL编码，但我想知道是否有人在某个时候遇到过此问题?

it does not bring any results. I am trying to find a way to allow such users to return results. I know its an URL encoding but I am wondering if anyone has encounter this at one point?

推荐答案

+是URL中的元字符，并转换为空格.

The + is a metacharacter in a URL and is converted to a space.

这不太正确.

RFC 3986标准化URI，并在附录A 中包含增强的Bachus-Naur格式描述. +(U + 002B)是sub-delims的成员，这意味着它是pchar的成员，因此是要包含在query中的候选对象.

RFC 3986 standardizes URI, and includes in appendix-A the Augmented Bachus-Naur Form description of the URI syntax. + (U+002B) is a member of sub-delims which means that it is a member of pchar and therefore a candidate to be included in a query.

从历史上看，您遇到的问题很可能是堆栈的某些部分假设您的序列化步骤，该步骤将替换空间(U + 0020)加上plus(U + 002B)，以及带有百分比编码形式的plus.

It is historically more likely that the problem you are encountering is that some part of stack is assuming that your query is application/x-www-form-urlencoded, which is one of the options for submitting form data in HTML. The rules for this type include a serializing step which replaces space (U+0020) with plus (U+002B), and plus with its percent encoded form.

反序列化器自然会在从URL中提取数据时用空格替换URL中的加号.

A deserializer would, naturally, replace the plus in the URL with a space when extracting the data from it.

但是基本原理是正确的-如果您的序列化器和反序列化器的平衡不正确，则表示不好天.

But the basic sketch is correct - if your serializers and deserializers aren't correctly balanced, you are in for a bad day.

这篇关于允许使用(+)登录用户名的用户登录的API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！