URL/NSURL Double-Encodes Characters Unnecessarily
The older, simpler API
[NSURL URLWithString:URLString]behaves the same as[NSURL URLWithString:URLString encodingInvalidCharacters:YES]when your code is compiled with the iOS 17 or macOS 14 SDK. So much for backward compatibility![NSURL URLWithString:URLString]continues to work fine with example 1, leaving the URL string untouched, but it mangles example 2:https://example.org?url=https%253A%252F%252Fexample.org%253Ffoo%5B0%5D%253DbarNotice that the brackets are encoded as
%5Band%5D, which is good, but the preexisting%characters are also encoded as%25, thereby transforming%3A(an encoded:character) into%253A, which is bad, indeed bonkers! The%characters did not need to be encoded, because they are already valid characters in a URL query.
I’ve seen other weird behavior, even using an old SDK, such as NSURLComponents returning nil instead of a valid URL.
Previously:
- EagleFiler 1.9.13
- Mail Links and Percentages
- URL Path Retrieval Cheat Sheet
- What Every Web Developer Must Know About URL Encoding
1 Comment RSS · Twitter · Mastodon
Now, inevitably, this will take a while to be fixed, if ever, and some poor developer is going to put in a work-around that finds an unencoded %25 into just %, but then there will be edge cases where that double-encoding was intentional. That will break other code, which will need to support a special extra flag that says "Hey, don't do the un-encode work-around." Then, maybe, if all the developers who have to work with that system are lucky, the API bug will be fixed, and then a few years after that, a new version of the software with the annoying, but understandable, work-around will come out. Then, the developers working with that system will have the joy of removing all of their work-around code.
Ugh.
For the record, this particular bug doesn't affect me, but I think you can tell the description above is autobiographical.
