I'm seeing a really weird bug with exo-open 4.18.0. I have [a custom handler](https://github.com/aspiers/desktop-config/blob/master/.local/share/applications/xclip-handler.desktop) defining the `xclip://...` protocol: ``` [Desktop Entry] Name=Copy to clipboard Exec=xclip-handler %u Icon=xfce4-clipman-plugin Type=Application Terminal=false MimeType=x-scheme-handler/xclip; ``` and [the corresponding `xclip-handler` Python script](https://github.com/aspiers/desktop-config/blob/master/bin/xclip-handler) which invokes `xclip` with the data from the URL, so that `exo-open xclip://foobar` will result in `foobar` being placed in the clipboard. For the most part this works great, and it also works for encoded URLs such as `xclip://foo%20bar`. However, when the URL contains non-ASCII UTF characters, either encoded or raw, things get weird and sometimes fail with the error `Unable to detect the URI-scheme of "xclip://..."`: $ exo-open 'xclip://it’s' # U+2019 with no encoding; works $ exo-open 'xclip://it’s ' # U+2019 with no encoding and space; broken $ exo-open 'xclip://it’s+fine' # U+2019 with space encoded as plus; works $ exo-open 'xclip://it’s%20fine' # U+2019 with space encoded as %20; broken Finally, the length of the URL can also somehow play a factor! This URL of 64 bytes works: $ exo-open 'xclip://xxxxxxxxxxxxx’xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' but anything longer including this non-ASCII character breaks, again with the `Unable to detect ...` error: $ exo-open 'xclip://xxxxxxxxxxxxx’xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' and removing the non-ASCII character allows longer URLs to work fine: $ exo-open 'xclip://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' In contrast, `gio open` handles all of these flawlessly.