URL Decode Working Correctly?

Wappler General Need Help
1

v6.8.0, Node, MySQL here. I’m passing query parameters over $_GET, which at times will include special characters. In my server connect, I am using urldecode() on the $_GET parameter and assigning it to a new variable.

When I look at the webserver logs, I see the following:

server-connect:output varEventName: 'Special Character%2C comma'

Shouldn’t the urldecode() function have removed the %2C from the variable string?

2

I found the urldecode() function in the string.js formatter file. It does this:

urldecode: function(str) {
        if (str == null) return str;

        return decodeURI(String(str));
    },

After asking AI why it doesn’t seem to be decoding the query parameter correctly, AI’s answer was this:

Here is the explanation for why the existing code fails and the simple, direct fix for your string.js file.

The "Why": decodeURI() vs. decodeURIComponent()

The two functions are designed for slightly different purposes, and this difference is key.

  1. decodeURI() (What Wappler is using):

    • Purpose: This function is designed to decode a full Uniform Resource Identifier (URI), like https://example.com/path?query=value.

    • Behavior: It decodes most percent-encoded characters (%20 for space, etc.), but it intentionally does not decode a specific set of "reserved" characters that have special meaning within a URL's structure.

    • Reserved Characters include: ; , / ? : @ & = + $ #

    • This is the problem: When decodeURI() sees %2C (the comma), it recognizes that the comma is a reserved character and it intentionally leaves it as %2C. The same is true for the ampersand (%26) and others. It assumes these characters are part of the URL's structure, not part of the data.

  2. decodeURIComponent() (What we need):

    • Purpose: This function is designed to decode a single component of a URI, such as the value of a query parameter (...&event_name=VALUE_HERE).

    • Behavior: It decodes all percent-encoded characters, including the reserved characters listed above.

    • This is the solution: It correctly assumes that any special characters found within a component are part of the data itself and should be decoded back to their literal form.

So, I’m going to update the function of course and see what happens.

3

After the change to use decodeURIComponent(), I see the following webserver output and my query worked as desired:

server-connect:output varEventName: 'Special Character, comma'

Since I’m using the urldecode() function on individual query parameters and not the entire string, I see no reason to be concerned about this change.