I am trying to encode a JSON string on the clipboard using KM’s “filter clipboard with percent encode for URL” action . However, the result obtained is different from what I expect using other tools including Popclip and http://meyerweb.com/eric/tools/dencoder/.
I do need a (space → %20) translation, but if the characters of file:///also get percent-encoded, then my browser will choke and I have a problem.
encodeURI() just the characters which need to be percent-encoded for a URI, leaving, for example the protocol string at the start, and
encodeURIComponent() which can be a bit more ambitious, and doesn’t have to watch out for a protocol string at the start.
In other words, there are many different points on the spectrum between percent-encoding nothing, and percent-encoding every single character. Different points on that spectrum are required for different purposes.
Perhaps one could rewrite your question from:
what am I doing wrong ? (Answer: quite probably nothing)
what is the context in which you need the percent-encoding, and what, if anything, is the error that you are getting ?
What I simply want to do is to create a macro to add a clean link (devoid of referrer information) to a download manager, Maxel using this [API] (http://maxelapp.com/api.html).
Figuring out how to do an escape url for all characters before prepending “maxel://add/” is what I am finding difficult.
( If so, might be worth pointing that out to them – surprising how often this comes up … )
No, this is not accurate. I don’t believe the behaviour has changed from previous versions of Keyboard Maestro. It just does not seem to encode much of anything, but I’m not sure why. It is possible this is a system change in recent versions of OS X as the filter calls straight through to the stringByAddingPercentEscapesUsingEncoding API, but maybe that doesn’t do much of anything either/
It may be difficult to use this function to "clean up" unescaped or partially escaped URL strings where sequences are unpredictable and you cannot specify charactersToLeaveUnescaped. Instead, you can "pre-process" a URL string using CFURLCreateStringByReplacingPercentEscapesUsingEncoding then add the escape characters using CFURLCreateStringByAddingPercentEscapes
It doesn't actually look as if anything is broken to me, and I think it's producing the same output as:
i.e. only encoding enough to make a simply-formed URI compliant.
But perhaps there is an argument for providing an additional sister function which doesn't protect protocol substrings etc, and may possibly be closer to what users expect, in some contexts.