Url Decode Javascript Utf8

To correctly URL decode a JavaScript UTF-8 string, the most direct and reliable approach is to leverage JavaScript’s built-in decodeURIComponent() function. This function is specifically designed to handle URL-encoded components, including those that represent multi-byte UTF-8 characters, ensuring proper conversion back to their original form.

Here are the detailed steps to decode a URL-encoded UTF-8 string in JavaScript:

Identify the Encoded String: First, you need the URL-encoded string that contains the UTF-8 characters. This string typically has non-alphanumeric characters replaced with a % followed by two hexadecimal digits (e.g., %20 for a space) or multi-byte UTF-8 characters represented by multiple %xx sequences (e.g., %C3%B6 for ‘ö’).

Use decodeURIComponent(): Apply the decodeURIComponent() function to your encoded string. This function will automatically interpret the hexadecimal escape sequences as UTF-8 bytes and convert them into the corresponding Unicode characters.

Example Code Snippet:

0.0

0.0 out of 5 stars (based on 0 reviews)

Excellent0%

Very good0%

Average0%

Poor0%

Terrible0%

There are no reviews yet. Be the first one to write one.

Amazon.com: Check Amazon for Url decode javascript
Latest Discussions & Reviews:

const encodedString = "Hello%20World%21%20%C3%B6%C3%A4%C3%BC";
const decodedString = decodeURIComponent(encodedString);
console.log(decodedString); // Output: Hello World! öäü

Handle Potential Errors: While decodeURIComponent() is robust, it will throw a URIError if the encoded string contains malformed URI sequences (e.g., %G1 or %C3%). It’s a good practice to wrap the decoding operation in a try-catch block to handle such scenarios gracefully.

Example with Error Handling:

function safeDecodeURIComponent(encodedStr) {
    try {
        return decodeURIComponent(encodedStr);
    } catch (e) {
        if (e instanceof URIError) {
            console.error("Malformed URI sequence detected:", encodedStr, e);
            // You might return the original string, an empty string, or throw a custom error
            return null; // Or return encodedStr;
        } else {
            throw e; // Re-throw other types of errors
        }
    }
}

const malformedString = "invalid%G1sequence";
const result = safeDecodeURIComponent(malformedString);
console.log(result); // Output: null (and an error message in console)

Distinguish from unescape() and decodeURI(): It’s crucial to understand why decodeURIComponent() is the correct choice for UTF-8.
- unescape() (Deprecated): This function is deprecated and should not be used for modern URL decoding, especially with UTF-8. It decodes fewer characters and does not correctly handle multi-byte UTF-8 sequences, leading to incorrect characters or errors. It was primarily designed for older character sets like Latin-1.
- decodeURI(): This function is designed to decode an entire URI. It will not decode special characters that are part of the URI syntax (like /, ?, &, #, etc.) because those characters need to maintain their meaning within the URI structure. Use decodeURI() when decoding an entire URL except for specific components. Use decodeURIComponent() when decoding individual components of a URL, which are often the parts containing user-supplied data or international characters.

By following these steps, you can reliably and efficiently URL decode JavaScript UTF-8 strings, ensuring data integrity and proper character representation in your web applications.

Table of Contents

Understanding URL Encoding and UTF-8 in JavaScript

URL encoding is a mechanism used to translate characters that are not allowed in URLs (like spaces, &, ?, etc.) and non-ASCII characters into a format that can be transmitted safely over the internet. When we talk about “URL decode JavaScript UTF-8,” we’re specifically addressing how JavaScript handles the conversion of these encoded strings, particularly when they contain characters beyond the basic ASCII set, which are typically encoded using UTF-8. UTF-8 (Unicode Transformation Format – 8-bit) is the dominant character encoding for the web, supporting virtually all characters from all languages.

Why URL Encoding is Necessary

The internet’s infrastructure, specifically URLs, relies on a limited set of characters to define structure and parameters. Characters like spaces, &, =, ?, and many others have special meanings. If these characters appear literally in a URL where they are not intended to serve their structural purpose, they can break the URL or lead to incorrect parsing. Similarly, characters outside the ASCII range (like é, ñ, 测) need a standard way to be represented. URL encoding provides this by converting such characters into hexadecimal escape sequences (e.g., a space becomes %20). For UTF-8 characters, multi-byte characters are encoded byte by byte, resulting in sequences like %C3%B6 for ‘ö’. This ensures data integrity during transmission across different systems and environments.

The Role of UTF-8 in Web Communications

UTF-8 is the default encoding for HTML5 and is widely supported across browsers and servers. Its key advantage is its variable-width encoding, meaning ASCII characters use a single byte, while other characters use two, three, or four bytes. This makes it efficient for English text while still accommodating the vastness of Unicode. When a web application sends data containing non-ASCII characters (e.g., form submissions, query parameters in URLs), these characters are often URL-encoded using their UTF-8 byte representation. Consequently, when receiving this data in JavaScript, it must be URL decoded with a UTF-8 understanding to restore the original characters correctly. According to W3Techs, as of early 2024, 98.2% of all websites use UTF-8 as their character encoding, highlighting its critical importance.

How JavaScript Handles Encoding and Decoding

JavaScript provides built-in global functions for URL encoding and decoding:

encodeURI() and encodeURIComponent(): For encoding.
decodeURI() and decodeURIComponent(): For decoding.

These functions are designed to work with Unicode strings internally and correctly handle UTF-8 encoding/decoding when dealing with URL components. It’s crucial to use the right function for the job, as their behavior differs significantly based on what part of the URI you are processing. Misuse can lead to incorrect data or security vulnerabilities. Random hexagram

Differentiating `decodeURIComponent()` and `decodeURI()`

Understanding the distinction between decodeURIComponent() and decodeURI() is paramount for correct URL manipulation in JavaScript. While both functions aim to decode URL-encoded strings, they operate on different scopes within a Uniform Resource Identifier (URI), leading to varied results and use cases. Think of it like a chef knowing when to chop an ingredient versus preparing an entire meal – the tools and process differ based on the objective.

`decodeURIComponent()`: For Individual URL Components

The decodeURIComponent() function is specifically designed to decode individual parts of a URI. These “components” typically include query string parameters, path segments, or fragment identifiers. Its primary strength lies in its comprehensive decoding capabilities: it decodes all escape sequences (e.g., %20, %2F, %3F, %26) into their corresponding characters, including characters that have special meaning within a URI structure (like /, ?, &).

When to Use:
- Decoding a single query parameter value (e.g., name=%D9%8A%D9%88%D8%B3%D9%81).
- Decoding a path segment that might contain encoded slashes or other reserved characters.
- When you have a string that has been encoded using encodeURIComponent().
- Example: If you have a query string like ?data=Hello%20World%21%20%C3%B6%C3%A4%C3%BC&path=a%2Fb, and you want to extract and decode data or path, you’d use decodeURIComponent().

Behavior with Reserved Characters: This function decodes characters like /, ?, :, #, &, =, +, $, *, (, ), ', !, ~. This is crucial because these characters are often part of the data within a component, not the structure of the URI itself.

const encodedComponent = "https%3A%2F%2Fexample.com%2Fsearch%3Fquery%3DHello%20World";
const decodedComponent = decodeURIComponent(encodedComponent);
console.log(decodedComponent);
// Output: https://example.com/search?query=Hello World
// Notice how all special characters including '/' ':' '?' are decoded.

`decodeURI()`: For Entire URIs

In contrast, decodeURI() is meant to decode an entire URI. It decodes all escape sequences except those that represent URI structural delimiters. This means it will not decode characters like /, ?, :, #, &, =, +, $, *, (, ), ', !, ~ if they are encoded. These characters are considered “reserved” and play a role in defining the URI’s hierarchy or components. The idea is to preserve the integrity of the URI’s structure while decoding its content. Json replace escape characters

When to Use:
- When you have a complete URL string that you want to decode without altering its structural components.
- When you have a string that has been encoded using encodeURI().
- Example: If you have a full URL like http://example.com/my%20path/resource?id=123%20test, and you want to get a more human-readable version of the URL, you’d use decodeURI().
Behavior with Reserved Characters: This function preserves encoded instances of /, ?, :, #, &, =, +, $, *, (, ), ', !, ~. This is vital because these characters are separators within a URI.
```
const encodedURI = "http://example.com/my%20path/resource?id=123%20test%26data%3Dextra";
const decodedURI = decodeURI(encodedURI);
console.log(decodedURI);
// Output: http://example.com/my path/resource?id=123 test&data=extra
// Notice that '&' and '=' are still encoded because they were part of the data, but '%20' for space is decoded.
// If '/','?',etc. were encoded in the original string, they would remain encoded.
```
A common pitfall is to use decodeURI() on a query parameter value that should contain encoded slashes or ampersands. This can lead to incorrect parsing or data loss. A rule of thumb for web development is that decodeURIComponent() is generally what you need for handling user-supplied data in URLs, as individual data points are what often contain special characters that need full decoding. When dealing with full URLs, ensure your data is properly encoded before using decodeURI() if it contains reserved characters that shouldn’t be decoded.

The Pitfalls of `unescape()` and Why You Should Avoid It

In the world of web development, evolving standards mean that older functions sometimes become obsolete or even dangerous. unescape() is a prime example of such a function in JavaScript. While it might still exist in some environments for legacy compatibility, its use in modern web applications, especially when dealing with international characters and UTF-8, is highly discouraged. Relying on deprecated methods can lead to subtle bugs, unexpected behavior, and maintenance nightmares. Just like using an outdated financial scheme based on interest (riba) can lead to unforeseen complications, clinging to unescape() can introduce issues in your code.

The Historical Context of `unescape()`

The unescape() function was introduced in JavaScript 1.0, long before UTF-8 became the dominant character encoding for the web. Its primary purpose was to decode strings that were encoded using the escape() function, which applied a less comprehensive encoding scheme. escape() encoded non-ASCII characters into %xx (for characters with codes <= 255) or %uxxxx (for characters with codes > 255) sequences. This approach worked reasonably well for character sets like Latin-1, where characters typically fit within a single byte. Json what needs to be escaped

Why `unescape()` Fails with UTF-8

The fundamental problem with unescape() is its lack of UTF-8 awareness. UTF-8 is a multi-byte encoding, meaning a single Unicode character can be represented by one to four bytes. When escape() (and consequently unescape()) processes a multi-byte UTF-8 character, it treats each byte as a separate character and encodes it individually. This breaks the intended multi-byte sequence.

For example, the character ö (Unicode U+00F6) in UTF-8 is encoded as two bytes: C3 B6. If you were to incorrectly use escape() on a string containing ö, it might yield %C3%B6. When unescape() attempts to decode this, it might not correctly reassemble these bytes into the single character ö, or it might throw an error depending on the exact sequence and browser implementation. In contrast, encodeURIComponent() would correctly encode ö as %C3%B6, and decodeURIComponent() would correctly convert %C3%B6 back to ö.

Risks and Issues of Using `unescape()`

Incorrect Character Decoding: This is the most significant issue. unescape() will often produce “mojibake” (garbled characters) when processing strings that were originally UTF-8 encoded, because it doesn’t understand the multi-byte sequences.
Security Vulnerabilities: Misinterpreting character encodings can open doors to security vulnerabilities such as cross-site scripting (XSS) attacks. If an attacker can manipulate how your application interprets character data, they might bypass sanitization filters.
Inconsistency Across Browsers: While unescape() is technically deprecated in the ECMAScript standard, its exact behavior can vary subtly between different browser engines and older JavaScript runtimes, leading to inconsistent application behavior.
Lack of Maintenance: Being a deprecated function, unescape() will not receive updates or bug fixes, making it a potential weak link in your application’s compatibility and reliability.
Code Readability and Maintainability: Using outdated functions makes your codebase harder to understand for new developers and complicates future maintenance efforts. Modern JavaScript practices emphasize clear, standard, and robust solutions.

The Clear Alternative: `decodeURIComponent()`

The unequivocal recommendation for decoding URL-encoded strings, especially those containing UTF-8 characters, is to use decodeURIComponent(). It is part of the modern JavaScript standard, correctly handles UTF-8 multi-byte sequences, and is robust for the specific task of decoding URI components.

// AVOID THIS (incorrect for UTF-8)
const encodedStringBad = "Hall%F6"; // Example of a Latin-1 'ö' might be encoded this way if it were just one byte
// const decodedStringBad = unescape(encodedStringBad); // Will likely yield incorrect results or errors with modern UTF-8
// console.log(decodedStringBad);

// USE THIS (correct for UTF-8)
const encodedStringGood = "Hall%C3%B6"; // UTF-8 encoded 'ö'
const decodedStringGood = decodeURIComponent(encodedStringGood);
console.log(decodedStringGood); // Output: Hallö

By consciously avoiding unescape() and consistently opting for decodeURIComponent(), you ensure your web applications handle character encoding robustly, securely, and in line with modern web standards, reflecting good engineering practices.

Handling Special Characters and Reserved Delimiters

When you’re dealing with URL encoding and decoding, it’s not just about converting spaces or international characters. It’s also about managing “special characters” that have a specific role within the URL syntax. These characters are called reserved delimiters, and their treatment is a key differentiator between decodeURIComponent() and decodeURI(). Understanding how to handle them correctly is crucial for both data integrity and preventing unexpected behavior, much like understanding the nuanced rules of a beneficial transaction ensures fairness and clarity. Kitchen design software free for pc

What are Reserved Delimiters?

Reserved delimiters are characters that are reserved for use as separators or indicators within a URI. They include:

General Delimiters: /?#[]@: (slash, question mark, hash, square brackets, at sign, colon)
Sub-Delimiters: !$&'()*+,;= (exclamation, dollar, ampersand, single quote, parentheses, asterisk, plus, comma, semicolon, equals)

These characters are essential for defining the structure of a URL (e.g., http://domain.com/path?query=value#fragment). If any of these characters appear in a URL-encoded form (e.g., %2F for /), how they are decoded depends on whether they are part of the URL’s structure or part of the data itself.

`decodeURIComponent()` and Reserved Delimiters

As discussed, decodeURIComponent() is designed for decoding components of a URI. When applied to an encoded string, it will decode all percent-encoded characters, including those that represent reserved delimiters. This is precisely what you want when these characters are part of the data you are transmitting, not part of the URL’s structural syntax.

Example:
Suppose a user inputs “My/Folder?Name” into a form field, and this is then URL-encoded to be part of a query parameter like path=%4D%79%2F%46%6F%6C%64%65%72%3F%4E%61%6D%65.

const encodedData = "%4D%79%2F%46%6F%6C%64%65%72%3F%4E%61%6D%65";
const decodedData = decodeURIComponent(encodedData);
console.log(decodedData); // Output: My/Folder?Name

In this scenario, decodeURIComponent() correctly converts %2F back to / and %3F back to ?, because these characters were part of the user’s input data, not the URI’s structure. If you were to use decodeURI() here, it would not decode %2F or %3F, leading to an incorrect result of My%2FFolder%3FName. Tail of the dragon

`decodeURI()` and Reserved Delimiters

decodeURI() is for decoding an entire URI while preserving its structural integrity. Therefore, it will not decode percent-encoded characters that are reserved delimiters (/, ?, #, etc.). Its purpose is to make a full URL more readable by decoding general escape sequences (like spaces) but leaving the structural parts untouched.

Example:
Consider a full URL: http://example.com/my%20path/resource?id=123%20test%26param=value%2Fwith%2Fslash.

const fullEncodedURI = "http://example.com/my%20path/resource?id=123%20test%26param=value%2Fwith%2Fslash";
const decodedURI = decodeURI(fullEncodedURI);
console.log(decodedURI);
// Output: http://example.com/my path/resource?id=123 test%26param=value%2Fwith%2Fslash

Notice how %20 (space) is decoded, but %26 (ampersand) and %2F (slash) within the param value are not decoded by decodeURI(). This is because decodeURI() assumes that if they are encoded, they are encoded because they are part of the data and not structural delimiters within the main URI path. If you want to decode those specific data components, you would extract them and then use decodeURIComponent().

Best Practices for Handling Special Characters

Encode Early, Decode Late: Encode data as soon as it’s meant to be part of a URL (e.g., before adding it to a query string). Decode it only when you extract it from the URL and need to use it in its original form.
Use encodeURIComponent() for Data: Always use encodeURIComponent() when you are preparing individual pieces of data (like form field values, search terms, or API parameters) to be included in a URL. This ensures all characters, including reserved ones, are properly encoded.
Use decodeURIComponent() for Data Retrieval: Always use decodeURIComponent() when extracting individual pieces of data from a URL (e.g., parsing query string parameters). This will correctly restore all characters, including those that were originally reserved delimiters in the data.
Rarely Use encodeURI()/decodeURI(): These functions are less commonly needed in typical web development. They are suitable for encoding/decoding entire URLs that already have their components properly structured (e.g., when constructing a URL from known, safe parts or displaying a URL to a user). If you construct a URL from scratch, you usually combine literal structural elements with encodeURIComponent()-encoded data components.
Be Mindful of Server-Side Decoding: Remember that server-side languages (like Node.js, PHP, Python, Java) also have their own URL decoding mechanisms. Ensure that your server-side decoding logic is consistent with the JavaScript encoding to prevent discrepancies in data interpretation.

By meticulously handling special characters and choosing the right decoding function, you ensure robust and reliable data exchange over the web, preventing common encoding-related bugs.

Practical Examples and Common Scenarios

Let’s dive into some practical examples to solidify our understanding of URL decoding in JavaScript, especially with UTF-8. These scenarios will cover common challenges faced by developers and demonstrate how decodeURIComponent() is the go-to solution. Js check json length

Scenario 1: Decoding Query String Parameters

This is perhaps the most frequent use case. When a user submits a form or clicks a link, data is often passed via query parameters in the URL. These parameters might contain spaces, special characters, or international characters that get URL-encoded.

Example:
A URL like https://example.com/search?q=تاريخ%20الإسلام&cat=مقالات
Here, q and cat are query parameters containing Arabic characters and a space.

const queryString = "q=%D8%AA%D8%A7%D8%B1%D9%8A%D8%AE%20%D8%A7%D9%84%D8%A5%D8%B3%D9%84%D8%A7%D9%85&cat=%D9%85%D9%82%D8%A7%D9%84%D8%A7%D8%AA";

// To extract and decode 'q':
const qParamEncoded = queryString.split('&')[0].split('=')[1]; // Extracts '%D8%AA%D8%A7%D8%B1%D9%8A%D8%AE%20%D8%A7%D9%84%D8%A5%D8%B3%D9%84%D8%A7%D9%85'
const qParamDecoded = decodeURIComponent(qParamEncoded);
console.log("Decoded 'q':", qParamDecoded); // Output: Decoded 'q': تاريخ الإسلام

// To extract and decode 'cat':
const catParamEncoded = queryString.split('&')[1].split('=')[1]; // Extracts '%D9%85%D9%82%D8%A7%D9%84%D8%A7%D8%AA'
const catParamDecoded = decodeURIComponent(catParamEncoded);
console.log("Decoded 'cat':", catParamDecoded); // Output: Decoded 'cat': مقالات

Why decodeURIComponent() is best here: It correctly handles the multi-byte UTF-8 sequences for Arabic characters and also decodes %20 back to a space, preserving the original data.

Scenario 2: Decoding Path Segments

Sometimes, dynamic parts of a URL path might contain encoded characters.

Example:
A user profile URL: https://example.com/users/Dr.%20Malik%20O'Connell C# convert json to xml newtonsoft

const encodedPathSegment = "Dr.%20Malik%20O'Connell";
const decodedPathSegment = decodeURIComponent(encodedPathSegment);
console.log("Decoded path segment:", decodedPathSegment);
// Output: Decoded path segment: Dr. Malik O'Connell

Even the single quote ' is correctly decoded from its encoded form if it were %27 (which it is not in this example but decodeURIComponent would handle it).

Scenario 3: Decoding Data from `location.href` or `location.search`

When you need to parse the current page’s URL directly from the browser’s window.location object, the values fetched are already URL-encoded by the browser.

Example:
Current URL: https://mysite.com/page?product=كتاب%20جميل&promo=save%26more

// In a browser environment:
// Assuming current URL is the example above
const currentSearch = window.location.search; // Returns '?product=%D9%83%D8%AA%D8%A7%D8%A8%20%D8%AC%D9%85%D9%8A%D9%84&promo=save%26more'

// A simple way to parse:
const urlParams = new URLSearchParams(currentSearch);
const productName = urlParams.get('product'); // Returns the raw encoded string for 'product'
const promoCode = urlParams.get('promo');   // Returns the raw encoded string for 'promo'

const decodedProductName = decodeURIComponent(productName);
const decodedPromoCode = decodeURIComponent(promoCode);

console.log("Decoded Product Name:", decodedProductName); // Output: كتاب جميل
console.log("Decoded Promo Code:", decodedPromoCode);     // Output: save&more

Key Takeaway: Even with URLSearchParams, the values you get for parameters are still URL-encoded. You still need decodeURIComponent() to get the true original values, especially for those containing UTF-8 characters or reserved delimiters like &.

Scenario 4: Decoding a Base64-Encoded URL Component (and then URL-decoding)

Sometimes, developers might layer encoding. A common pattern is to Base64 encode a complex string (e.g., a JSON object) and then URL-encode that Base64 string to make it safe for URLs. To get the original data, you first URL-decode, then Base64 decode. Convert json to xml c# without newtonsoft

Example:
Original JSON: {"item":"قرآن","id":123}
Base64 encoded: eyJpdGVtIjoi2YjYp9iq2YjYpSIsImlkIjoxMjN9
URL-encoded Base64: eyJpdGVtIjoi2YjYp9iq2YjYpSIsImlkIjoxMjN9 (often, Base64 characters are URL-safe, so minimal additional URL encoding occurs unless + or / are present)

Let’s assume the string passed in a URL is: data=eyJpdGVtIjoi2YjYp9iq2YjYpSIsImlkIjoxMjN9

const encodedDataFromUrl = "eyJpdGVtIjoi2YjYp9iq2YjYpSIsImlkIjoxMjN9";

// Step 1: URL decode (if any URL encoding occurred, though Base64 is mostly URL-safe)
const urlDecoded = decodeURIComponent(encodedDataFromUrl);

// Step 2: Base64 decode
const base64Decoded = atob(urlDecoded);
console.log("Base64 Decoded (JSON string):", base64Decoded);

// Step 3: Parse JSON
try {
    const finalObject = JSON.parse(base64Decoded);
    console.log("Final Object:", finalObject);
    // Output: Final Object: { item: 'قرآن', id: 123 }
} catch (e) {
    console.error("Failed to parse JSON:", e);
}

This multi-step decoding illustrates that decodeURIComponent() is the foundational first step for any data transmitted via URLs, even if further decoding (like Base64) is required.

These examples clearly illustrate the versatility and necessity of decodeURIComponent() for handling URL-encoded strings with UTF-8 characters and special delimiters in JavaScript. Always remember its specific purpose for individual URL components.

Performance Considerations for Decoding Large Strings

While modern JavaScript engines are highly optimized, working with very large strings or performing numerous decoding operations in a loop can still have performance implications. Understanding these aspects can help you write more efficient and responsive web applications. It’s akin to optimizing your daily tasks: even small gains multiply significantly over time, leading to greater overall efficiency. Text info to 85075

Impact of String Size and Number of Operations

The decodeURIComponent() function, while efficient, still involves character-by-character processing to identify and convert escape sequences.

String Length: The longer the input string, the more processing time is required. Decoding a 1MB string will naturally take longer than decoding a 1KB string.
Number of Encoded Characters: Strings with a higher density of percent-encoded characters (especially multi-byte UTF-8 sequences) will generally take longer to decode than strings with fewer encoded characters of the same total length, as each escape sequence requires specific parsing logic.
Frequency of Operations: If you’re decoding hundreds or thousands of strings in quick succession (e.g., parsing a large dataset that came via URL parameters), the cumulative time can become noticeable.

Benchmarking `decodeURIComponent()`

While specific numbers vary greatly by browser, CPU, and string content, decodeURIComponent() is generally quite fast for typical web use cases (strings up to a few kilobytes). For example, decoding a few hundred kilobytes of URL-encoded data might take milliseconds. However, when dealing with multiple megabytes, or if you’re doing this many times per second, you might start seeing execution times in the tens or hundreds of milliseconds, which can impact UI responsiveness.

Rough estimates (highly variable):

Decoding a 1KB string: < 0.1 ms
Decoding a 100KB string: 0.1 – 1 ms
Decoding a 1MB string: 1 – 10 ms
Decoding a 10MB string: 10 – 100 ms

These are just rough benchmarks; your actual performance will depend heavily on the content of the string (e.g., number of escape characters), the browser’s JavaScript engine, and the user’s hardware.

Strategies for Optimizing Decoding Performance

Decode Only When Necessary: Avoid decoding strings unless you explicitly need their decoded form. If data is merely being passed through without being displayed or processed, keep it encoded. Ai voice changer online free no sign up
Batch Processing (If Applicable): If you receive many small encoded strings, sometimes processing them in batches (e.g., using requestAnimationFrame for UI updates) can prevent UI freezing, even if the total decoding time remains the same. This isn’t about speeding up the decode itself, but improving user experience.
Pre-processing on the Server (If Possible): For very large datasets or complex strings, consider performing the initial decoding on the server-side before sending the data to the client. This offloads the work from the browser and can significantly improve client-side performance, especially for mobile devices.
Use URLSearchParams for Query Strings: As shown in a previous example, URLSearchParams is an efficient way to parse query strings. While it returns encoded values, the parsing itself is often optimized by the browser’s native implementation compared to manual string splitting and regex.
Avoid Unnecessary Iterations: If you have a deeply nested structure of encoded data, ensure you’re not decoding the same part multiple times. Decode once, then work with the decoded string.

Web Workers for Heavy Lifting: For extremely large strings (several megabytes) that absolutely must be decoded on the client-side and would block the main thread, consider using Web Workers. Web Workers allow you to run scripts in the background, off the main thread, preventing the UI from freezing. Binary product of 101 and 10

// In your main script:
if (window.Worker) {
    const myWorker = new Worker('decoder-worker.js');
    myWorker.postMessage('large_encoded_string_here'); // Send the encoded string
    myWorker.onmessage = function(e) {
        console.log('Decoded result from worker:', e.data);
        // Update UI here with the decoded data
    };
    myWorker.onerror = function(e) {
        console.error('Worker error:', e);
    };
}

// In decoder-worker.js:
onmessage = function(e) {
    const encodedData = e.data;
    try {
        const decodedData = decodeURIComponent(encodedData);
        postMessage(decodedData); // Send decoded data back to the main thread
    } catch (error) {
        postMessage({ error: error.message }); // Send error back
    }
};

This approach effectively moves the CPU-intensive decoding process off the main thread, keeping your user interface responsive.

In summary, for most typical web applications, decodeURIComponent() is highly efficient and unlikely to be a bottleneck. However, if you find yourself dealing with very large encoded strings or performing decoding operations in high-frequency loops, consider the optimization strategies outlined above to maintain a smooth and responsive user experience.

Security Considerations in URL Decoding

Security is paramount in web development, and URL decoding is no exception. Incorrect or careless handling of URL-encoded strings can expose your application to various vulnerabilities, most notably Cross-Site Scripting (XSS) attacks. Just as a robust financial system protects against fraud and deception, your decoding logic must safeguard against malicious inputs.

Cross-Site Scripting (XSS) Attacks

XSS attacks occur when an attacker injects malicious client-side scripts into web pages viewed by other users. This can happen if user-supplied data (e.g., from a URL parameter, form input) is not properly sanitized or encoded before being displayed or processed by the browser. If a malicious script is URL-encoded by the attacker and then incorrectly decoded and rendered by your application, the script can execute in the victim’s browser, potentially leading to:

Session hijacking: Stealing cookies and session tokens.
Defacement: Altering the content of the webpage.
Redirection: Redirecting users to malicious sites.
Data theft: Stealing sensitive user data.

Example of an XSS vulnerability related to decoding:
Imagine a website displays a “welcome message” using a URL parameter: https://example.com/welcome?user=John%20Doe.
If an attacker crafts a URL like:
https://example.com/welcome?user=%3Cscript%3Ealert%28%27XSSed%21%27%29%3C%2Fscript%3E Ip address table example

If your JavaScript code directly takes the user parameter, decodes it, and then injects it into the DOM without proper sanitization:

const userParam = decodeURIComponent(new URLSearchParams(window.location.search).get('user'));
document.getElementById('welcomeMessage').innerHTML = 'Welcome, ' + userParam; // VULNERABLE!

The browser would execute alert('XSSed!'). The attacker used URL encoding (%3C for <, %3E for >, etc.) to bypass simple string matching, relying on the decodeURIComponent() call to reveal the malicious script.

Key Security Practices for URL Decoding

Sanitize Output, Not Input: The golden rule of web security is to never trust user input. Always sanitize data before rendering it to the DOM or storing it in a database, regardless of whether it came from a URL or a form. Decoding the input is often necessary to get its true value, but sanitization must happen after decoding and before display.

Correct Approach (using DOM manipulation that escapes content):

const userParam = decodeURIComponent(new URLSearchParams(window.location.search).get('user'));
const welcomeElement = document.getElementById('welcomeMessage');
welcomeElement.textContent = 'Welcome, ' + userParam; // SAFEST: textContent automatically escapes HTML

Alternative for HTML (with caution): If you absolutely must render HTML from user input, use a robust DOMPurify library.

// npm install dompurify
import DOMPurify from 'dompurify';
const userParam = decodeURIComponent(new URLSearchParams(window.location.search).get('user'));
const cleanHTML = DOMPurify.sanitize('Welcome, ' + userParam);
document.getElementById('welcomeMessage').innerHTML = cleanHTML; // Safer, but still requires careful use

Contextual Output Encoding: Understand the context in which data will be used.
- HTML Context: Use HTML entity encoding (< for <, > for >).
- JavaScript Context: Use JavaScript string literal encoding (e.g., \u003c for <).
- URL Context (if re-encoding): Use encodeURIComponent().
Validate and Whitelist Input: Beyond sanitization, validate input data against expected formats, types, and ranges. If a URL parameter is supposed to be a number, validate it as such. If it’s a specific string, check against a whitelist of allowed values. This reduces the attack surface significantly. Json escape quotes python
Avoid eval() with Decoded Input: Never pass user-supplied, decoded strings directly into eval() or similar functions (setTimeout(string), new Function(string)). This is a direct path to code injection.
Be Wary of Double Encoding/Decoding: Attackers sometimes try to bypass security filters by double-encoding malicious payloads. Ensure your application’s encoding/decoding logic is clear and consistent. For instance, if data is encoded twice, decoding it once might still leave a malicious payload encoded. Your system should only decode what it expects to be encoded.
Regular Security Audits: Regularly audit your code for potential vulnerabilities. Static analysis tools and manual code reviews can help identify improper handling of user input and decoding issues.

By adhering to these security best practices, especially the principle of sanitizing output and never directly injecting unsanitized decoded user input into the DOM, you can significantly mitigate the risks associated with URL decoding and protect your web application from common attacks like XSS.

Troubleshooting Common Decoding Errors

Even with the correct functions, you might encounter issues when URL decoding strings in JavaScript. These errors usually stem from malformed input or a misunderstanding of how the encoding happened initially. Addressing these systematically is key to robust web development. Ip address to binary

1. `URIError: URI malformed`

This is the most common error you’ll encounter with decodeURIComponent() or decodeURI(). It means the input string contains an invalid percent-encoded sequence that doesn’t conform to URI standards.

Causes:

Incomplete Escape Sequences: E.g., %A instead of %A0, or % by itself.
Invalid Hexadecimal Digits: E.g., %G1 instead of %F1.
Invalid UTF-8 Sequences: This is tricky. If a multi-byte UTF-8 character was incorrectly formed during encoding (e.g., an incomplete byte sequence like %C3 without %B6), decodeURIComponent() will throw this error because it cannot construct a valid Unicode character from the bytes.
Double Encoding/Decoding Mismatch: Sometimes data gets encoded twice, and then you try to decode it only once, leaving part of the malformed (from a single-decode perspective) or vice versa.

Troubleshooting Steps:

Inspect the Input String: Carefully examine the string you’re trying to decode. Look for obvious malformed sequences.
Check Encoding Origin: How was the string encoded in the first place? Was it encoded on the server-side, by another JavaScript function, or manually? Ensure the original encoding process was correct and followed UTF-8 standards. Paystub generator free online

Test with try-catch: Always wrap your decoding calls in a try-catch block to gracefully handle URIError. This prevents your application from crashing and allows you to log the problematic string for debugging.

const problematicString = "some%malformed%string%C3";
try {
    const decoded = decodeURIComponent(problematicString);
    console.log("Decoded:", decoded);
} catch (e) {
    if (e instanceof URIError) {
        console.error("Decoding error: URI malformed. Problematic string:", problematicString, e);
        // Provide user feedback or fall back to original string/default
    } else {
        console.error("An unexpected error occurred:", e);
    }
}

2. “Mojibake” (Garbled Characters)

This happens when the decoding process produces characters that look like gibberish (e.g., Ã¶ instead of ö). It’s a classic sign of an encoding/decoding mismatch, where the data was treated as one encoding but decoded as another.

Causes:

Using unescape(): As discussed earlier, unescape() doesn’t understand multi-byte UTF-8 sequences, leading to mojibake. If unescape() was used to decode, you’ll see this.
Server-Side Encoding Mismatch: The data was encoded on the server using a character set other than UTF-8 (e.g., Latin-1, ISO-8859-1) but JavaScript’s decodeURIComponent() (which assumes UTF-8) is trying to decode it.
Incorrect Content-Type Header: If the server doesn’t send the Content-Type: text/html; charset=utf-8 header (or similar for other data types), browsers or JavaScript might guess the encoding incorrectly, leading to issues.
Database/Storage Encoding Issues: If the data was stored or retrieved from a database with an incorrect character set, it might be corrupted before it even reaches your JavaScript.

Troubleshooting Steps:

Confirm UTF-8 Everywhere: Ensure that all parts of your application stack (database, server-side language, HTTP headers, client-side JavaScript) are consistently using and declaring UTF-8 as the character encoding. This is often the root cause of mojibake.
Verify decodeURIComponent() is Used: Double-check that you are using decodeURIComponent() and not unescape() or decodeURI() for decoding component data.
Test with Known Characters: Try decoding simple, well-known UTF-8 characters (like ö, €, ⌘, Arabic or Chinese characters) to isolate whether the issue is systemic or specific to certain data.
Raw Byte Inspection (Advanced): For complex cases, you might need to inspect the raw bytes of the encoded string to see if they genuinely represent the expected UTF-8 sequence. Tools like online URL encoders/decoders that show byte representations can be helpful.

3. Characters Not Decoding (e.g., `%2F` remains `%2F`)

This typically means you used the wrong decoding function for the task.

Causes:

Using decodeURI() instead of decodeURIComponent(): decodeURI() will not decode reserved delimiters like %2F (slash), %26 (ampersand), %3F (question mark), etc., because it assumes they are part of the URI’s structure.

Troubleshooting Steps:

Re-evaluate Function Choice: If you expect characters like /, ?, & to be decoded from their percent-encoded forms, you almost certainly need decodeURIComponent(). Review the purpose of decodeURI() versus decodeURIComponent().
Examine Encoding Process: Was the data originally encoded with encodeURI()? If so, it might not have encoded these characters in the first place, or they were encoded for a structural purpose. If the data itself contains a literal / or & and you want it decoded, it should have been encoded with encodeURIComponent().

By systematically diagnosing these common errors and ensuring consistent UTF-8 handling across your application, you can resolve most URL decoding issues in JavaScript.

Future of URL Encoding/Decoding in JavaScript (and Beyond)

The landscape of web standards is continuously evolving, and while decodeURIComponent() remains the standard and most robust solution for URL decoding in JavaScript for the foreseeable future, it’s worth considering the broader trends and potential developments. Staying informed helps you prepare your applications for upcoming changes and maintain a forward-thinking approach, just as sound planning in life ensures preparedness for what’s ahead.

Current Stability of `decodeURIComponent()`

The decodeURIComponent() and encodeURIComponent() functions are deeply entrenched in the ECMAScript standard and widely implemented across all modern browsers and JavaScript runtimes (Node.js, Deno, etc.). They are considered stable, reliable, and performant for their intended purpose. There are no current proposals or discussions within the ECMAScript committee to deprecate or significantly alter these functions. Their utility in handling URL components and UTF-8 characters is fundamental to how web applications exchange data.

Potential Areas of Evolution (Not Direct Replacement)

While the core functions are stable, improvements and new APIs often emerge that can make using these functions easier or more efficient in specific contexts:

URLSearchParams and URL API Enhancements: The URL and URLSearchParams interfaces (part of the Web APIs, not ECMAScript core) provide a more structured and ergonomic way to work with URLs and their query parameters.
- URLSearchParams automatically handles some encoding/decoding during its get() and set() operations, but it still often provides the raw encoded string for you to manually decodeURIComponent(). Future enhancements might further streamline this.
- As these APIs become more widely adopted and optimized, they indirectly simplify URL handling, reducing the need for manual string parsing and thus reducing potential for decoding errors.
Internationalized Resource Identifiers (IRIs): While URLs primarily use ASCII characters, IRIs allow non-ASCII characters directly in the URI path and query components (e.g., https://example.com/مرحبا). Browsers and servers often handle the conversion between IRIs and their underlying URL-encoded form automatically. This is a complex topic, but modern JavaScript engines and browser implementations are increasingly capable of dealing with IRIs, which implies robust internal UTF-8 handling. For developers, decodeURIComponent() will still be essential when dealing with the percent-encoded version of IRIs.
Wider Adoption of WebAssembly (Wasm): While Wasm won’t replace JavaScript’s built-in functions, for extremely performance-critical scenarios involving custom encoding/decoding schemes (e.g., highly specialized compression or encryption followed by URL-safe encoding), you could implement these algorithms in languages like Rust or C++ and compile them to Wasm. This would offer near-native performance for very complex string manipulations, but it’s overkill for standard URL decoding.
HTTP/3 and Beyond: Future HTTP protocol versions might introduce new mechanisms for data transmission, but the fundamental need to encode non-safe characters in URLs will likely remain due to historical constraints and character set limitations in the URI syntax. The encoding and decoding principles will persist, even if the exact transport layer evolves.

Developer Best Practices for the Future

Stay Updated with Standards: Keep an eye on ECMAScript proposals and Web API specifications. While major changes to core decoding functions are unlikely, new helper APIs or paradigms might emerge.
Embrace Modern APIs: Favor URL and URLSearchParams for URL manipulation where appropriate, as they offer a more structured and safer approach than manual string parsing.
Continue Using decodeURIComponent(): For the foreseeable future, decodeURIComponent() remains the standard, secure, and performant way to decode individual URL components, especially those containing UTF-8 characters.
Focus on Security: The principles of input validation and output sanitization will always be critical, regardless of specific decoding functions. Malicious inputs will continue to be a threat, and robust security practices are timeless.

In essence, the foundation laid by decodeURIComponent() is solid. While the tools around it may refine and improve, the core mechanism for handling percent-encoded UTF-8 in URLs is unlikely to change drastically, underscoring its long-term reliability in web development.

FAQ

1. What is the primary function for URL decoding in JavaScript for UTF-8?

The primary function for URL decoding in JavaScript for UTF-8 encoded strings is decodeURIComponent(). It correctly interprets multi-byte UTF-8 sequences and converts them back into their original Unicode characters.

2. When should I use `decodeURIComponent()` versus `decodeURI()`?

You should use decodeURIComponent() to decode individual components of a URL, such as query string parameters or path segments. It decodes all special characters, including reserved delimiters like /, ?, and &. Use decodeURI() only when decoding an entire, well-formed URI that you want to make more readable, as it preserves encoded reserved delimiters that are part of the URI’s structure.

3. Why is `unescape()` discouraged for URL decoding in JavaScript?

unescape() is discouraged because it is a deprecated function that does not correctly handle multi-byte UTF-8 character sequences. Using it with UTF-8 encoded strings can lead to “mojibake” (garbled characters) or unexpected behavior, and it poses security risks.

4. How does `decodeURIComponent()` handle special characters like ‘/’ or ‘&’?

decodeURIComponent() will decode all percent-encoded special characters, including reserved delimiters like %2F (for ‘/’) and %26 (for ‘&’). This is appropriate when these characters are part of the data content within a URL component, not part of the URL’s structural syntax.

5. Can `decodeURIComponent()` throw an error?

Yes, decodeURIComponent() can throw a URIError if the input string contains malformed URI sequences, such as incomplete escape sequences (e.g., %A or %) or invalid hexadecimal digits (e.g., %G1). It’s recommended to wrap calls in a try-catch block.

6. What does “UTF-8” mean in the context of URL decoding?

UTF-8 is a variable-width character encoding that represents Unicode characters. In URL decoding, it means that decodeURIComponent() is designed to correctly interpret the byte sequences that represent multi-byte Unicode characters (like ö, €, Arabic, or Chinese characters) when they are URL-encoded.

7. Is URL decoding necessary for data coming from `window.location.search`?

Yes, when you retrieve query string data using window.location.search or URLSearchParams, the values obtained for parameters are still URL-encoded. You must use decodeURIComponent() to convert them back to their original, readable form.

8. What are common causes of “mojibake” (garbled characters) after decoding?

“Mojibake” usually indicates an encoding mismatch. Common causes include: using unescape(), the original data being encoded with a character set other than UTF-8 (e.g., Latin-1) while JavaScript expects UTF-8, or incorrect Content-Type headers from the server.

9. How can I decode a URL-encoded string that was also Base64 encoded?

You would first use decodeURIComponent() to handle any URL encoding that might have occurred. Then, you would use atob() (for Base64 strings) to decode the resulting string. If the Base64 string was complex or contained + or / characters, the decodeURIComponent() step is crucial.

10. What are the security risks if I don’t correctly URL decode and sanitize user input?

Incorrect URL decoding, particularly without proper sanitization, can lead to Cross-Site Scripting (XSS) vulnerabilities. Attackers can inject malicious scripts into URL parameters (URL-encoded), which, if decoded and rendered directly, can execute in a victim’s browser, leading to data theft or website defacement.

11. Should I sanitize input before or after decoding?

You should decode the input first to get its true value, and then sanitize the output (the decoded string) immediately before rendering it to the DOM or storing it in a database. Never trust user input.

12. How can I prevent `URIError: URI malformed`?

To prevent URIError, ensure that the input string you’re decoding is valid and correctly formed. Validate the source of the string and always wrap your decodeURIComponent() calls in a try-catch block to handle potential errors gracefully, preventing your application from crashing.

13. Is there a performance impact when decoding very large strings?

Yes, decoding very large strings (multiple megabytes) or performing a high volume of decoding operations can have a performance impact, potentially blocking the main thread and making the UI unresponsive. For such scenarios, consider using Web Workers to offload the processing or decode on the server side.

14. Are there any alternatives to `decodeURIComponent()` in modern JavaScript?

While there are no direct alternative functions that replace decodeURIComponent()‘s core functionality, modern Web APIs like URLSearchParams can simplify the parsing of URL query strings, reducing the need for manual string manipulation before applying decodeURIComponent() to specific parameter values.

15. What is the difference between URL encoding and Base64 encoding?

URL encoding converts characters into a format safe for URLs (using percent-encoding like %20 or %C3%B6). Base64 encoding converts binary data into an ASCII string format, often used for transmitting binary data over text-based protocols or for slightly obfuscating data. They serve different purposes, but sometimes Base64-encoded data is then URL-encoded to be included in a URL.

16. Can I use `decodeURIComponent()` on an entire URL string?

While technically possible, it’s generally not recommended. decodeURIComponent() will decode all percent-encoded characters, including those that are reserved delimiters (/, ?, &) that define the URL’s structure. This can alter the URL’s integrity. For entire URLs, decodeURI() is more appropriate if you only want to decode non-reserved characters.

17. How do browsers typically handle URL encoding and decoding themselves?

Browsers automatically handle URL encoding for form submissions and when constructing URLs from <a> tags. They also automatically decode parts of the URL when presenting them in the address bar, but raw query string values (e.g., in window.location.search) remain encoded for your JavaScript to handle.

18. Does `decodeURIComponent()` affect the plus sign `+` for spaces?

No, decodeURIComponent() only decodes %20 to a space. It does not convert + to a space. This is a common point of confusion because form submissions sometimes encode spaces as + (as per the application/x-www-form-urlencoded content type). If you expect + to be spaces, you need to manually replace them before calling decodeURIComponent() or use URLSearchParams which handles this automatically.

19. What’s the best way to decode a full URL string in JavaScript while preserving its structure?

For a full URL string, decodeURI() is typically used as it decodes general characters but leaves reserved delimiters (like /, ?, #, &) encoded. However, if any data within the URL (like a specific query parameter value) was encodeURIComponent()-encoded, you would need to extract that component and then use decodeURIComponent() on it.

20. How can I ensure consistency of UTF-8 encoding/decoding across my entire web application stack?

To ensure consistency, explicitly declare UTF-8 at every layer:

HTML: <meta charset="UTF-8">
HTTP Headers: Content-Type: text/html; charset=utf-8 (and similar for other media types)
Server-side: Configure your web server, application framework, and database connection to explicitly use UTF-8.
Database: Ensure your database and table/column collations are set to UTF-8.
JavaScript: Consistently use encodeURIComponent() for encoding and decodeURIComponent() for decoding URL components.

Url decode javascript utf8

Understanding URL Encoding and UTF-8 in JavaScript

Why URL Encoding is Necessary

The Role of UTF-8 in Web Communications

How JavaScript Handles Encoding and Decoding

Differentiating decodeURIComponent() and decodeURI()

decodeURIComponent(): For Individual URL Components

decodeURI(): For Entire URIs

The Pitfalls of unescape() and Why You Should Avoid It

The Historical Context of unescape()

Why unescape() Fails with UTF-8

Risks and Issues of Using unescape()

The Clear Alternative: decodeURIComponent()

Handling Special Characters and Reserved Delimiters

What are Reserved Delimiters?

decodeURIComponent() and Reserved Delimiters

decodeURI() and Reserved Delimiters

Best Practices for Handling Special Characters

Practical Examples and Common Scenarios

Scenario 1: Decoding Query String Parameters

Scenario 2: Decoding Path Segments

Scenario 3: Decoding Data from location.href or location.search

Scenario 4: Decoding a Base64-Encoded URL Component (and then URL-decoding)

Performance Considerations for Decoding Large Strings

Impact of String Size and Number of Operations

Benchmarking decodeURIComponent()

Strategies for Optimizing Decoding Performance

Security Considerations in URL Decoding

Cross-Site Scripting (XSS) Attacks

Key Security Practices for URL Decoding

Troubleshooting Common Decoding Errors

1. URIError: URI malformed

2. “Mojibake” (Garbled Characters)

3. Characters Not Decoding (e.g., %2F remains %2F)

Future of URL Encoding/Decoding in JavaScript (and Beyond)

Current Stability of decodeURIComponent()

Potential Areas of Evolution (Not Direct Replacement)

Developer Best Practices for the Future

FAQ

1. What is the primary function for URL decoding in JavaScript for UTF-8?

2. When should I use decodeURIComponent() versus decodeURI()?

3. Why is unescape() discouraged for URL decoding in JavaScript?

4. How does decodeURIComponent() handle special characters like ‘/’ or ‘&’?

5. Can decodeURIComponent() throw an error?

6. What does “UTF-8” mean in the context of URL decoding?

7. Is URL decoding necessary for data coming from window.location.search?

8. What are common causes of “mojibake” (garbled characters) after decoding?

9. How can I decode a URL-encoded string that was also Base64 encoded?

10. What are the security risks if I don’t correctly URL decode and sanitize user input?

11. Should I sanitize input before or after decoding?

12. How can I prevent URIError: URI malformed?

13. Is there a performance impact when decoding very large strings?

14. Are there any alternatives to decodeURIComponent() in modern JavaScript?

15. What is the difference between URL encoding and Base64 encoding?

16. Can I use decodeURIComponent() on an entire URL string?

17. How do browsers typically handle URL encoding and decoding themselves?

18. Does decodeURIComponent() affect the plus sign + for spaces?

19. What’s the best way to decode a full URL string in JavaScript while preserving its structure?

20. How can I ensure consistency of UTF-8 encoding/decoding across my entire web application stack?

Comments

Leave a Reply Cancel reply

Differentiating `decodeURIComponent()` and `decodeURI()`

`decodeURIComponent()`: For Individual URL Components

`decodeURI()`: For Entire URIs

The Pitfalls of `unescape()` and Why You Should Avoid It

The Historical Context of `unescape()`

Why `unescape()` Fails with UTF-8

Risks and Issues of Using `unescape()`

The Clear Alternative: `decodeURIComponent()`

`decodeURIComponent()` and Reserved Delimiters

`decodeURI()` and Reserved Delimiters

Scenario 3: Decoding Data from `location.href` or `location.search`

Benchmarking `decodeURIComponent()`

1. `URIError: URI malformed`

3. Characters Not Decoding (e.g., `%2F` remains `%2F`)

Current Stability of `decodeURIComponent()`

2. When should I use `decodeURIComponent()` versus `decodeURI()`?

3. Why is `unescape()` discouraged for URL decoding in JavaScript?

4. How does `decodeURIComponent()` handle special characters like ‘/’ or ‘&’?

5. Can `decodeURIComponent()` throw an error?

7. Is URL decoding necessary for data coming from `window.location.search`?

12. How can I prevent `URIError: URI malformed`?

14. Are there any alternatives to `decodeURIComponent()` in modern JavaScript?

16. Can I use `decodeURIComponent()` on an entire URL string?

18. Does `decodeURIComponent()` affect the plus sign `+` for spaces?