应该执行什么角色替换来使基础64编码URL安全？

本文介绍了应该执行什么角色替换来使基础64编码URL安全？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 29岁程序员，3月因学历无情被辞！ 在查看URL安全基础64编码时，我发现它是非常非标准的。尽管PHP拥有丰富的内置函数，但是没有一个用于URL安全基础64编码。在 base64_encode（） 的手册页面上，大多数评论建议使用该功能，用 strtr（）包装：In looking at URL safe base 64 encoding, I've found it to be a very non-standard thing. Despite the copious number of built in functions that PHP has, there isn't one for URL safe base 64 encoding. On the manual page for base64_encode(), most of the comments suggest using that function, wrapped with strtr():function base64_url_encode($input){ return strtr(base64_encode($input), '+/=', '-_,');}我可以在这个区域找到唯一的Perl模块是 MIME :: Base64 :: URLSafe （ 来源） ，它在内部执行以下替换：The only Perl module I could find in this area is MIME::Base64::URLSafe (source), which performs the following replacement internally:sub encode ($) { my $data = encode_base64($_[0], ''); $data =~ tr|+/=|\-_|d; return $data;}与上面的PHP函数不同，此Perl版本删除'=' ）字符，而不是像PHP那样用'，'（逗号）替换它。等于是一个填充字符，所以Perl模块在解码时根据需要替换它们，但是这种差异使得两个实现不兼容。Unlike the PHP function above, this Perl version drops the '=' (equals) character entirely, rather than replacing it with ',' (comma) as PHP does. Equals is a padding character, so the Perl module replaces them as needed upon decode, but this difference makes the two implementations incompatible.最后，Python函数 urlsafe_b64encode（s）保持'='填充，促使某人放下此功能删除在Google结果中显着突出显示'python base64 url​​ safe'：Finally, the Python function urlsafe_b64encode(s) keeps the '=' padding around, prompting someone to put up this function to remove the padding which shows prominently in Google results for 'python base64 url safe':from base64 import urlsafe_b64encode, urlsafe_b64decodedef uri_b64encode(s): return urlsafe_b64encode(s).strip('=')def uri_b64decode(s): return urlsafe_b64decode(s + '=' * (4 - len(s) % 4))这里的需求是将一个可以包含在URL中的字符串，而不需要进一步的编码，因此，翻译或翻译的字符'+'，'/'和'='。由于没有一个定义的标准，正确的方法是什么？The desire here is to have a string that can be included in a URL without further encoding, hence the ditching or translation of the characters '+', '/', and '='. Since there isn't a defined standard, what is the right way?推荐答案作为标准，它是 RFC 3548 ，第4节，基本64编码使用URL和文件名安全字母表：There does appear to be a standard, it is RFC 3548, Section 4, Base 64 Encoding with URL and Filename Safe Alphabet: 这个编码在技术上与前一个相同，除外 62：nd和63：rd字母，如表2所示，。 This encoding is technically identical to the previous one, except for the 62:nd and 63:rd alphabet character, as indicated in table 2. + 和 / 应替换为 - （减号）和 _（下滑）。任何不兼容的库都应该被包装，以符合RFC 3548。+ and / should be replaced by - (minus) and _ (understrike) respectively. Any incompatible libraries should be wrapped so they conform to RFC 3548.请注意，这要求您将URL编码为（pad）= 字符，但我更喜欢通过标准base64字母表中的 + 和 / 字符的URL编码。Note that this requires that you URL encode the (pad) = characters, but I prefer that over URL encoding the + and / characters from the standard base64 alphabet. 这篇关于应该执行什么角色替换来使基础64编码URL安全？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！