ENCODEURL$: Difference between revisions

Revision as of 10:35, 26 November 2024

The _ENCODEURL$ function returns the so called percent encoded representation of the given URL.

result$ = _ENCODEURL$(url$)

URL encoding may be required before trying to retrieve it using the _OPENCLIENT("HTTP:url") command.
Proper encoding is under the obligation of the application, because only that knows how the URL currently looks like and hence if encoding is required or not.
This function performs the most simple encoding according to the informations found here, which is sufficient for the most work cases.
- Chars - . _ ~ 0 to 9 Aa to Zz (not encoded).
- Chars # / : ? @ [ ] (not encoded in address part but encoded in query part, first ? is not encoded and starts the query part).
- Chars & = (not encoded as query key separator respectively query value assignment on a simple 1:1 swap base).
- Control chars, spaces and extended ASCII (>127) are always encoded, regardless in which part of the URL they are used.
- If the application uses unconventional URL notation, e.g. query parts like ?foo=bar&baz&flip=true where the use of ampersands (&) or other reserved chars is ambigous, then it must implement its own custom encoding routine, as only the application knows the correct syntax in such cases.
Note that this function performs no validation of the given URL, it expects a valid URL to be given and just does the encoding.
Note also that it does not check, if the URL is already encoded. Although multiple times encoded URLs should not be a problem for most servers, it's recommended to avoid it.

@@ Line 19: / Line 19: @@
 ** Chars & = (not encoded as query key separator respectively query value assignment on a simple 1:1 swap base).
 ** Control chars, spaces and extended ASCII (>127) are always encoded, regardless in which part of the URL they are used.
-** If the application uses unconventional URL notation, e.g. query parts like ''?foo=bar&baz&flip=true'' where the use of ampersands (&) is ambigous, then it must implement its own custom encoding routine, as only the application knows the correct syntax in such cases.
+** If the application uses unconventional URL notation, e.g. query parts like ''?foo=bar&baz&flip=true'' where the use of ampersands (&) or other reserved chars is ambigous, then it must implement its own custom encoding routine, as only the application knows the correct syntax in such cases.
 * Note that this function performs no validation of the given URL, it expects a valid URL to be given and just does the encoding.
 * Note also that it does not check, if the URL is already encoded. Although multiple times encoded URLs should not be a problem for most servers, it's recommended to avoid it.