You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if there is no ;base64 token, and the datauri is in urlencode, then you can presume that anything after , is going to be purely in percent encoding (especially newline and spacebars).
So to deal with that, we will need to urlencode anything after the ,.
Why should this be done? Well people may want to put in plain markdown files, and do not want to do urlencoding for the datauri content. So the normal datauri setup may be on the first QR code, but subsequent content may be in in standard UTF-8 mode.
The danger with doing a urlencode of the datauri, is that it may replace other % urlencode characters (like when you do a double pass of urlencoding).
It maybe safer to only replace the newline characters, and any non ASCII character that would throw up an error. This is because newer browsers are smart enough to interpret space and standard ascii characters without percent encoding. It just mainly have issues with newline character and spaces. Since uris are ment to be able to be written down on paper via pens (well at least that's the intention behind the url/uri specification).
if there is no
;base64
token, and the datauri is in urlencode, then you can presume that anything after,
is going to be purely in percent encoding (especially newline and spacebars).So to deal with that, we will need to urlencode anything after the
,
.Why should this be done? Well people may want to put in plain markdown files, and do not want to do urlencoding for the datauri content. So the normal datauri setup may be on the first QR code, but subsequent content may be in in standard UTF-8 mode.
The danger with doing a urlencode of the datauri, is that it may replace other
%
urlencode characters (like when you do a double pass of urlencoding).It maybe safer to only replace the newline characters, and any non ASCII character that would throw up an error. This is because newer browsers are smart enough to interpret space and standard ascii characters without percent encoding. It just mainly have issues with newline character and spaces. Since uris are ment to be able to be written down on paper via pens (well at least that's the intention behind the url/uri specification).
The text was updated successfully, but these errors were encountered: