(Hint: if the last character is not alphanumeric, put a # (a blank URL fragment) to work around HN's autodetection of punctuation)
(Edit: I don't recommend percent-encoding URLs, mainly because certain web servers react differently to percent-encoded URL, like https://www.google.com/search?q=world+dog and https://www.google.com/search?q=world%2bdog (first one is interpreted by Google search server as space, second one as a plus sign) while a blank URL fragment is guaranteed to be safe.)
> Hint: if the last character is not alphanumeric, put a # (a blank URL fragment) to work around HN's autodetection of punctuation
I usually use URL encoding (aka percent encoding) [0] in this case but that’s a pretty neat trick and certainly more convenient than for example pasting the URL into https://meyerweb.com/eric/tools/dencoder/ and pressing the encode button and copying the encoded URL.
So, fun fact about percent-encoding: the space character can be percent encoded as %20 or +, and a literal plus must always be percent encoded as %2b. When you put plusses in Google Search those are actually pre-percent encoded spaces, which is why it treats them as spaces. Of course, if you chuck it into a percent encoding script again it treats them as literal spaces since presumably the input isn't already percent encoded (just as it'd encode the % in other encoded characters).
At least that's if I recall correctly and it wouldn't surprise me if other servers do handle things in zany ways.
(Hint: if the last character is not alphanumeric, put a # (a blank URL fragment) to work around HN's autodetection of punctuation)
(Edit: I don't recommend percent-encoding URLs, mainly because certain web servers react differently to percent-encoded URL, like https://www.google.com/search?q=world+dog and https://www.google.com/search?q=world%2bdog (first one is interpreted by Google search server as space, second one as a plus sign) while a blank URL fragment is guaranteed to be safe.)