16

URIs use percent encoding to represent characters which would otherwise be reserved (like the forward slash - %2F), not always displayable or recognizable (Unicode characters, e.g. non-Latin letters) or otherwise inconvenient (like the space character - %20).

RFC 1630 says

The choice of escape character for introducing representations of non-allowed characters also tends to be a matter of taste. An ANSI standard exists in the C language, using the back-slash character "\". The use of this character on unix command lines, however, can be a problem as it is interpreted by many shell programs, and would have itself to be escaped. It is also a character which is not available on certain keyboards. The equals sign is commonly used in the encoding of names having attribute=value pairs. The percent sign was eventually chosen as a suitable escape character.

Is there any reason that the percent sign was chosen, rather than, say, $, ^ or *, all of which (AFAIK) don't have a special function in URIs?

2
  • 2
    Guess for the reason: $ and * are also interpreted in many shell programs, and ^ may not have been available on some keyboards.
    – dirkt
    Dec 24, 2023 at 16:05
  • 7
    Even 1992 documentation presents the encoding without giving a rationale — I suspect the best approach to find the actual answer is to ask Tim Berners-Lee directly (or find an interview where the question is asked and answered). Dec 24, 2023 at 16:40

1 Answer 1

14

Looks to me as if the cited paragraph already answered that perfectly.

  1. It must be a character available on as many keyboards as possible
  2. Should not be one that gets already escaped on their own development system
  3. Should not be in otherwise common use
  4. What remains is a matter of taste.

Rule #1 eliminates all characters that are marked in IS0-646 (IA5) for national use or as potential modifiers:

enter image description here (Taken from Wikipedia)

Every character marked in above table may thus not be used - which already includes the mentioned $ and ^.

Rule #2 eliminates \, at least for unixoide systems - same goes for <, > and |. If this would have been developed on mainframes it might have been other characters like : and ..

Rule #3 eliminates other characters like = and most punctuation ., :, , which are commonly as separators or in file names.

And then there is Rule #4: Taste - Noone can argue with taste and taste doesn't need nor have any reasoning. Taste will be at best self referencing (*1).

Bottom line:

Of the characters remaining after rules 1, 2 and 3 Percent was simply the one they liked most.


*1 - I like it, because it's beautiful - Why is it beautiful? 'Cause I like it ...

12
  • 6
    The remaining non-alphanumeric characters after the listed 1/2/3 are (I think): !%&()*+-? Of those, () are not good because they are a pair - why use one by itself. ? as the start of query parameters is extremely logical. & as additional parameter separator (this parameter and the other parameter) is extremely logical, though arguably + would work there as well. So that really just leaves !%*+- - not a whole lot of choices, and I would argue that + and - are not great choices because of their usual mathematical/logical meaning, so that just leaves !%* Dec 24, 2023 at 17:16
  • 3
    If rule 2 eliminates <, > and | as shell syntax, it should also eliminate & and ;, I think. Dec 24, 2023 at 17:52
  • 1
    Yes, I know & and ; were later used in CGI - I meant that they require quoting in shell language, like < and >. Actually, & is also a nuisance for HTML. Dec 24, 2023 at 18:49
  • 3
    Rule 4 is king here. % looks very aesthetically reasonable (at least to me?). I can’t imagine anybody choosing (i.e.) , except on the direst of circumstances. Dec 24, 2023 at 19:09
  • 1
    @trlkly Yes, but those are not part of URI specification, but URL as defined in later RFC1738 which adds @ and & as reserved.
    – Raffzahn
    Dec 25, 2023 at 18:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .