تشفير وفك تشفير روابط URL

The Developer's Guide to Percent-Encoding, RFC 3986 Standards, and URL Architecture

Uniform Resource Identifiers (URIs) and Uniform Resource Locators (URLs) are the universal addressing system of the internet. Defined by the Internet Engineering Task Force (IETF) in RFC 3986, a URL must adhere to a tightly constrained character set to ensure that web browsers, reverse proxies (Nginx, Cloudflare), web servers, and DNS routers parse addresses deterministically across every computing platform.

However, real-world web applications routinely transmit non-ASCII data, such as international alphabets, emojis, search terms containing ampersands (&), and nested callback links. Percent-encoding (often referred to as URL encoding) provides the standardized mechanism to represent arbitrary UTF-8 characters and reserved delimiters safely within URL query strings, path segments, and HTTP headers.

1. Anatomy of Percent-Encoding: The RFC 3986 Mechanism

Percent-encoding translates any character outside the permitted set into a three-character sequence: a literal percent sign (%) followed by two hexadecimal digits representing the byte's numerical value (from 00 to FF).

• Single-Byte ASCII Characters: For standard US-ASCII characters, the hex value corresponds to its ASCII table index. For example, the space character has decimal ASCII value 32, which is hexadecimal 0x20, encoding into %20. Similarly, the question mark (?) has hex value 3F, encoding into %3F.
• Multi-Byte UTF-8 Unicode: When encoding modern characters beyond basic Latin (such as accents, Arabic, Urdu, Chinese, or emojis), the character is first converted into its UTF-8 byte sequence, and each individual byte is percent-encoded. For example, the letter é consists of two UTF-8 bytes (0xC3 0xA9), encoding into %C3%A9. The rocket emoji (🚀) comprises four UTF-8 bytes (0xF0 0x9F 0x9A 0x80), producing %F0%9F%9A%80.

2. Reserved vs Unreserved Characters: The Core Rulebook

RFC 3986 divides all possible URL characters into two distinct categories:

3. encodeURI() vs encodeURIComponent(): When to Use Each

A universal pitfall in frontend web development is using the wrong JavaScript encoding function. While their names appear similar, they serve entirely different architectural purposes:

Rule of Thumb: If you are building a URL by concatenating query strings (e.g., "?search=" + val), you must always pass val through encodeURIComponent(). If you pass an entire URL into encodeURIComponent(), the browser will not recognize http%3A%2F%2F as a protocol.

4. The Space Encoding Dilemma: %20 vs Plus (+)

Engineers frequently wonder why some URLs encode spaces as %20 while others use +:

• The RFC 3986 Standard (%20): In the official URI standard, the plus character (+) is a reserved sub-delimiter, not a space. Therefore, in URL path segments (e.g., /blog/my%20first%20post), a space must strictly be encoded as %20. Using + in a path segment represents a literal plus sign.
• The HTML Form Standard (+): When HTML forms submit data via GET or POST using the media type application/x-www-form-urlencoded, spaces are converted into + characters for legacy readability (e.g., ?q=hello+world).

Toolhast provides a simple toggle allowing you to switch between standard %20 and form-encoded + based on your backend framework's expectations.

5. Security Considerations: Double Encoding and Injection Attacks

Improper handling of percent-encoding is a leading cause of severe web application security vulnerabilities:

1. Double Encoding Attacks: If an application decodes an incoming URL parameter twice, an attacker can bypass security filters. For example, if a filter blocks <script>, the attacker can submit %253Cscript%253E. The first decode yields %3Cscript%3E (passing the filter), and the secondary decode executes the unescaped script tag.
2. Open Redirect Vulnerabilities: OAuth2 and SSO workflows rely on redirect_uri parameters. If the redirect URL is unencoded or improperly validated, attackers can inject malicious destinations to steal authorization codes.
3. Parameter Pollution: Failing to encode ampersands (&) inside parameter values allows attackers to inject unexpected query keys, altering application logic.

Zero-Upload Privacy: Toolhast executes all encoding, decoding, and URL inspection 100% locally inside your web browser. Sensitive API tokens, OAuth authorization codes, and internal query strings are never transmitted across the network or stored on external servers.