The Pentium 4 also had a 16-bit ALU, which computed a 16-bit operation on each of the rising and falling edges of the clock to maintain 1-cycle latency. www.cs.virginia.edu/~mc2zk/cs451/mco_P4.ppt.
There's an invisible Unicode U+200E left-to-right mark at the end of the URL, probably picked up when the parent cut-and-paste the URL into HN. This in UTF-8 is E2 80 8E, which gets misinterpreted by the server as Windows-1252 character set: E2 = â, 80 = €, 8e = Ž. (It could be iso-8859-1, except that doesn't include €.) Interestingly, Chrome's DOM inspector shows this character as the HTML entity ‎ while view-source has it as the actual invisible character.
I think the poster of the URL originally mangled it, but it would be nice if the HN software filtered out invisible characters from URLs. There's not much the destination server can do about it.
(Yes, I've dealt with too many character set issues in the past.)
I copied and pasted it from a Google search result (because otherwise the file downloads without showing me the URL). Google of course has decided "copy link to" shouldn't work.
I’ve noticed this issue a lot of times. Is Google deliberately inserting Unicode crap at the end of URL:s in order to prevent copy-and-paste from their search results? Or perhaps it’s to prevent scraping, and the loss of copy and paste functionality is just collateral damage.
An addon to Firefox (mobile, too) and Chrome that prevents Google from changing the link address to a tracking address, allowing you to right click a search result, then choose Copy link address, and get the correct result.
I agree with mpyne, though, that it shouldn't be necessary.
