"UTF-8 percent encode c using the path percent-e..."

[Hixie]

https://url.spec.whatwg.org/commit-snapshots/488c459d9e4245a3f6bf087e7dcd2c7e91487ac5/#url-parsing

UTF-8 percent encode c using the path percent-encode set, and append the result to buffer.

It's not at all clear when reading the parser how a path segment consisting of "%62[" should end up. If I'm reading it right, it should end up as "%25%36%32%5B", which doesn't seem right.

[TimothyGu]

None of %, 6, 2, [ are part of the path percent-encode set, so they will get appended to buffer verbatim.

[zcorpan]

Would it be clearer if the step

If codePoint is not in percentEncodeSet, then return codePoint.

was taken out of "UTF-8 percent encode" algorithm? And the places that call UTF-8 percent encode first check if c is in the relevant encode set?

[Hixie]

Oh wow yeah that's really unclear. The "UTF-8 percent encode" algorithm, in normal operation, generally does not encode? Very confusing. :-)

[GPHemsley]

The "UTF-8 percent encode" algorithm also appears to be unclear as to whether it's operating on code points or bytes. What's its return type?

To UTF-8 percent encode a codePoint, using a percentEncodeSet, run these steps:

1. If codePoint is not in percentEncodeSet, then return codePoint.
2. Let bytes be the result of running UTF-8 encode on codePoint.
3. Percent encode each byte in bytes, and then return the results concatenated, in the same order.

[TimothyGu]

Well codePoint should be self-evidently a code point. UTF-8 encode converts the code point into a byte sequence bytes. Percent encode then converts every byte into a scalar value string (in fact a percent-encoded byte, a special type of string). So the return type of UTF-8 percent encode is a string, while it takes in a code point.

[GPHemsley]

Ah, OK, I follow now. Although codePoint is just the name of the variable; there is nothing self-evident about its type other than human intuition. It should say "code point codePoint".

Also, is there a reason these steps are not explicitly using another variable to keep track of the output? It seems unnecessarily convoluted to implicitly keep track of "the results concatenated".

[annevk]

I think it's fair that some of the names are confusing a bit but this stems from the concept being known as percent-encoding. Anyone have suggestions for how to rename these but keep the type signatures if we did something here? (More elaborate suggestions welcome if you're interested in taking into account all callers in URL and HTML.)

• percent-encoded byte (a type of string)
• percent encode (byte -> string)
• percent decode (byte sequence -> byte sequence)
• string percent decode (string -> byte sequence)
• UTF-8 percent encode ((code point, code point set) -> string)

[annevk]

Oh, I guess OP is mostly about UTF-8 percent encode not always doing something, not about the type signature.

Would "conditionally-UTF-8-percent encode" work?

[annevk]

#503 has the direction we're taking this. We'll keep the existing name, but we'll add a table to clarify the operations and use more overloading to reduce the high-level number of operations.