I am trying to find a way to create a padding for a key created using:
SecureRandom.urlsafe_base64(8). I know I can pass a second argument stating that I want a padding, but according to the docs:
The boolean argument padding specifies the padding. If it is false or
nil, padding is not generated. Otherwise padding is generated. By
default, padding is not generated because “=” may be used as a URL
delimiter.
So, my question is. How could I add a padding (that is url safe) so I know when is the string finished? (I need to concat two of those strings)
from the documentation:
The result may contain A-Z, a-z, 0-9, “-” and “_”
so you could use any other character for your delimiter, like + for example (which is a url-encoded space)
Related
I am new to SF. I have a typical problem that I have faced while loading some data. The delimiter is part of extended ascii. It does not come in 0-127. We use thorn (ascii - 254) as delimiter. My Qn is while specifying the delimiter can I give the ascii code of that delimiter instead of actual character (44 instead of comma, 9 instead of tab etc)
Thanks in advance
You can specify the hex/octal code of any valid Unicode delimiter in the FIELD_DELIMITER option of the File Format. From the documentation:
The specified delimiter must be a valid UTF-8 character and not a random sequence of bytes.
For example, for fields delimited by the thorn (Þ) character, specify the octal (\336) or hex (0xDE) value. Also accepts a value of NONE.
Part of my application relies on a HTTP client which is based on the Win32 API.
Each HTTP query is initiated with calls to WinHttpOpenRequest like
std::wstring method = L"POST";
std::wstring path = L"/foo/bar%baz";
WinHttpOpenRequest(
m_connectionHandler,
method.c_str(),
path.c_str(),
NULL,
WINHTTP_NO_REFERER,
WINHTTP_DEFAULT_ACCEPT_TYPES,
WINHTTP_FLAG_SECURE);
Until now, I was relying on the default behavior of WinHttpOpenRequest for properly percent encode the query.
I just discovered that the literal character % was left unescaped by default and that I must pass WINHTTP_FLAG_ESCAPE_PERCENT as additional flag.
I do not really get why this API encodes every reserved characters correctly except for the percent character itself. Are there any pragmatic reasons behind this choice? And can I safely use this additionnal flag, or are there any pitfalls I cannot see?
The only reason I can imagine is to avoid a double percent encoding with the default behavior, i.e I would already percent encoded my query, and the WinHttpOpenRequest cannot guess whether the percent characters it reads are the result of a percent encoding or not.
% It can also be used as an escape character, for example, you cannot print out '%' just with printf("%") but printf("%%").
If you block escape function of the %, As what does IInspectable say, You will not be able to use the escape function like %20, And other more: %2B, %2F, %3F, %3D, %21...
Description on msdn document, Flag WINHTTP_FLAG_ESCAPE_PERCENT means
The string passed in for pwszObjectName is converted from an LPCWSTR
to an LPSTR. All unsafe characters are converted to an escape sequence
including the percent symbol.
But ,by default,
all unsafe characters except the percent symbol are
converted to an escape sequence.
I just read about the \p{Assigned} selector in the Ruby Regex documentation, which sounds like a good possibility to easily generate an array of characters that it is supposed to match? The only thing it says in the documentation though is 'An assigned character'.
How do I assign one/multiple characters to this selector?
Unicode assigned characters are the whole of graphic, format, control, and private-use characters, i.e. any character that is not reserved for future assignment. You can't assign arbitrary characters to the class \p{Assigned}.
See https://bugs.ruby-lang.org/issues/3838
You need to specify that the encoding is UTF-8 by adding 'u' after the expression
/\p{Assigned}/u
Could anyone help me here to understand when we need to consider the
below 4 methods:
strict_decode64(str)
strict_encode64(bin)
urlsafe_encode64(bin)
urlsafe_decode64(str)
From the doc also I didn't get any examples. So examples with
explanation might be helpful for me to understand.
Thanks in advance
An example of usage would be:
require "base64"
Base64.strict_encode64('Stuff to be encoded')
Base64.strict_decode64("U3R1ZmYgdG8gYmUgZW5jb2RlZA==")
Strict means that white spaces / CR/LF are rejected at decode and CR/LF are not added at encode.
Note that if the folowing is accepted:
Base64.decode64("U3R1ZmYgdG8gYmUgZW5jb2RlZA==\n")
with strict the above is not accepted because of the trailing \n (linefeed) and the following line will throw ArgumentError: invalid base64 exception:
Base64.strict_decode64("U3R1ZmYgdG8gYmUgZW5jb2RlZA==\n")
So strict accepts/expects only alphanumeric characters at decode and returns only alphanumeric at encode.
Please try the following and see how one encodes wraps the lines every 60 characters with '\n' (linefeed) and the strict doesn't:
print Base64.encode64('I will not use spaces and new lines. I will not use spaces and new lines. I will not use spaces and new lines. I will not use spaces and new lines.I will not use spaces and new lines.')
print Base64.strict_encode64('I will not use spaces and new lines. I will not use spaces and new lines. I will not use spaces and new lines. I will not use spaces and new lines.I will not use spaces and new lines.')
The _encode and _decode do opposite things: the first one converts a normal string into an encoded string, and the second one converts an encoded string into a normal string.
str = "Hello!"
str == decode64(encode64(str)) # This is true
The difference between strict_ and urlsafe_ is the characters that will be used inside the encoded string. When you need to pass your string inside a URL, all characters are not allowed (like / for instance, because it has a special meaning in URLs) so you should use the urlsafe_ version.
I am stripping the padding from the end of of a base64 encoded string. I have found that I can successfully decode the string without adding the padding back on first (in php at least). Is this a result of the specification of base64 or implementation dependent?
And a related question, can a = sign exist in a base64 encoded string other than as padding, i.e. If it is not implementation dependent, is it safe just to strip the trailing equals signs or is it possible that the last "real" character could have been one?
While padding isn't necessary to decode a base64 string, there are some implementations that will throw an error if the padding has been stripped away.
The RFC states:
Implementations MUST include appropriate pad characters at the end of
encoded data unless the specification referring to this document
explicitly states otherwise.
The = character will only ever be used for padding.