I’m trying to open a bunch of hook links from a single KM macro (as a rapid switcher from a project to another).
In KM, i use the Open Url action without problem on : https://app.asana.com/… urls (for the asana web app)
craftsdoc://open?xxxxxx … urls (from Crafts documents)
but KM fails on :
hook://file/ xxxxx xxx … urls
to open a simple folder…
It’s strange, because hook seems to be registered as a proper url scheme provider, since copy pasting that same link in Chrome or Vivaldi works as expected …
Am I missing something?
(cross post from KM forum as well, in case its a KM problem)
» Tip: when cross-posting between forums, it’s good to link each post to the other, so people can read what has already been suggested on the other site, or if it has already been solved/fixed/etc.
One thing that often trips people up with file:// URLs is that there should be three/ after file:
So if I have a file named This-Is-A-Test.txt on my Desktop, the URL for that is:
You also need to make sure that you change any spaces to %20 and may need to “URL encode” (sometimes called “Percent Encode”) other special characters as well.
Hi TJ, thanks for the tip, you’re right, I should’ve thought about linking the cross post on my own.
You’re right about the file:/// trap, but the hook link I’m looking at is well formed - it’s extracted from Hook itself, and it works if i paste it in the safari address bar, for example. And it’s already URL encoded.
@ccstone has offered a scripted test macro in the KM forum - AppleScript itself is able to open the link when called by KM.
My best bet right now is this clue:
It looks like KM is not happy about the hook link in the Open URL action. I’m guessing this may have to do with the way hook registers its URL scheme ? I’m not sure we can do anything without the developers at this point …
There seems to be a bug in the URL encoding. Thanks to gentle prodding by Peter Lewis (KM’s dev), I looked at the url encoding of the file name.
I work mostly in French, and the name of my file was “Problème Bankable”. The URL given by hook is hook://file/tSfl7TRKH?p=RG9jdW1lbnRzL3Byb2plY3RzX2FyY2hpdmU=&n=proble%CC%80me%20bankable
The issue is that the ASCII encoding of è should rightly be %E8, not %CC%80. And indeed if I replace the latter by the former in the url I pass to Keyboard Maestro, or indeed in any web browser, it works.
As Peter says:
Keyboard Maestro uses the system NSURL API to process URLs, and NSURL requires that the URL be formatted correctly. Incorrectly formatted URLs are not allowed and will not work.
Web browsers are often forgiving in the URLs they will accept, and will accept invalid URLs and translate them as best they can in to valid ones and process them after that translation. Keyboard Maestro will not - the URL must be valid.
It seems that %CC%80 is a “long form” encoding of è (at least %CC seems to be a code for “accented”) but this is the limit of my encoding knowledge. All I can say is this seems to be one of those cases where web browsers (and Hook) will manage to figure it out, but not the NSURL API.
EDIT: following a more detailed comment by Peter N. Lewis, the KM dev, it seems that the issue arises because Hook URLs use one form of accents where è is rendered as e + combined grave accent, whereas it seems that KM expects the single character form (unicode 00E8). The solution is to turn off a preprocessing toggle in KM
