Mã hóa/Giải mã URL

Công cụ mã hóa và giải mã URL online miễn phí. Mã hóa văn bản cho URL hoặc giải mã chuỗi URL đã mã hóa ngay lập tức. Chuyển đổi ký tự đặc biệt, khoảng trắng và Unicode sang định dạng percent-encoded. Hoàn hảo cho lập trình viên web làm việc với tham số query, API endpoints và xử lý URL.

Có góp ý? Báo lỗi, đề xuất tính năng, hoặc chia sẻ suy nghĩ — chúng tôi đọc tất cả

Mã hóa/Giải mã URL - Encode và Decode URL Online

Công cụ mã hóa và giải mã URL online mạnh mẽ giúp bạn mã hóa văn bản để sử dụng an toàn trong URL hoặc giải mã chuỗi URL percent-encoded về văn bản gốc. Tự động xử lý ký tự đặc biệt, khoảng trắng, Unicode và nhiều tùy chọn mã hóa. Thiết yếu cho lập trình viên web làm việc với tham số query, API endpoints, dữ liệu form và thao tác URL.

Tại sao mã hóa URL biến khoảng trắng thành %20?

URL ban đầu bị giới hạn ở một tập nhỏ ký tự ASCII bởi RFC 1738 (1994) và sau đó RFC 3986 (2005), loại trừ khoảng trắng vì chúng phá vỡ các trình phân tích phân định thành phần bằng khoảng trắng. Bất kỳ ký tự nào không nằm trong tập không dành riêng (A-Z, a-z, 0-9, và -._~) đều phải được mã hóa phần trăm: byte được viết là % theo sau bởi giá trị thập lục phân hai chữ số. Khoảng trắng là byte 0x20, do đó là %20. Trong định dạng application/x-www-form-urlencoded cũ hơn được biểu mẫu HTML dùng, khoảng trắng có thể được mã hóa là +. Cả hai dạng đều giải mã trở lại thành khoảng trắng, nhưng chúng không thể hoán đổi trong mọi ngữ cảnh: trong chuỗi truy vấn, + thường có nghĩa là khoảng trắng, nhưng trong đường dẫn hoặc đoạn, + có nghĩa là dấu + theo nghĩa đen.

Sự khác biệt giữa encodeURI và encodeURIComponent là gì?

Hai hàm JavaScript này mã hóa các tập ký tự khác nhau vì chúng nhắm vào phạm vi khác nhau. encodeURI giả định bạn đang truyền một URL đầy đủ và bảo toàn các ký tự có ý nghĩa cấu trúc: : / ? # [ ] @ ! $ & ' ( ) * + , ; = ~ vẫn nguyên trạng. encodeURIComponent giả định bạn đang truyền một giá trị thành phần đơn lẻ (một đoạn đường dẫn, một giá trị truy vấn, một đoạn) mà phải có thể nhúng được bên trong URL mà không phá vỡ cú pháp, nên nó cũng thoát tất cả các ký tự cấu trúc đó. Quy tắc chung: xây dựng khung URL bằng encodeURI, nhưng luôn bọc mỗi giá trị do người dùng cung cấp bằng encodeURIComponent trước khi nối. Dùng encodeURI cho các giá trị truy vấn là nguyên nhân phổ biến nhất gây ra liên kết tìm kiếm và theo dõi bị hỏng.

Tại sao encodeURIComponent không thoát ! * ' ( ) và làm sao để nó tuân thủ nghiêm RFC 3986?

encodeURIComponent của JavaScript được triển khai theo đặc tả RFC 2396 cũ hơn, phân loại ! * ' ( ) là các dấu không yêu cầu thoát. RFC 3986 đã phân loại lại chúng thành sub-delims dành riêng trong một số ngữ cảnh. Để tuân thủ đầy đủ RFC 3986, hãy hậu xử lý kết quả: encodeURIComponent(str).replace(/[!*'()]/g, c => '%' + c.charCodeAt(0).toString(16).toUpperCase()). Điều này quan trọng khi tạo chữ ký OAuth 1.0a (đặc tả bắt buộc mã hóa nghiêm), khi xây dựng yêu cầu canonical AWS Signature V4, hoặc khi tương tác với các thư viện nghiêm ngặt phía máy chủ. Đối với liên kết web thông thường, hàm tích hợp JavaScript là ổn. Công cụ này cung cấp chế độ nghiêm thoát toàn bộ tập dành riêng theo RFC 3986 mục 2.2.

Các ký tự không phải ASCII như tiếng Trung, tiếng Việt hoặc emoji được mã hóa như thế nào?

Theo RFC 3986 mục 2.5 (và các đặc tả IRI trước đó trong RFC 3987), văn bản không ASCII trong URL trước hết phải được chuyển đổi sang byte UTF-8 và sau đó từng byte được mã hóa phần trăm. Ký tự "é" là hai byte trong UTF-8 (C3 A9), nên nó trở thành %C3%A9 — hai dấu thoát phần trăm, không phải một. Emoji "🎉" là bốn byte UTF-8 (F0 9F 8E 89) và trở thành %F0%9F%8E%89 — bốn dấu thoát. Các hệ thống cũ đôi khi dùng Latin-1 hoặc Windows-1252 và tạo ra %E9 cho é, mà bộ giải mã UTF-8 hiện đại sẽ hiểu sai. Nếu bạn thấy ? hoặc ký tự thay thế sau khi giải mã, nguồn có lẽ dùng mã hóa byte không phải UTF-8. Công cụ này luôn mã hóa và giải mã dưới dạng UTF-8.

Mã hóa/Giải mã URL — Công cụ mã hóa và giải mã URL online miễn phí. Mã hóa văn bản cho URL hoặc giải mã chuỗi URL đã mã hóa ngay lập tức. Chu — **Mã hóa/Giải mã URL**

Những ký tự nào không bao giờ cần được mã hóa trong URL?

RFC 3986 định nghĩa tập không dành riêng: A-Z chữ hoa, a-z chữ thường, chữ số 0-9, và bốn dấu - . _ ~. 66 ký tự này được đảm bảo có cùng ý nghĩa trong mọi thành phần URL và không bao giờ yêu cầu mã hóa. Các ký tự dành riêng chia thành hai nhóm: gen-delims (: / ? # [ ] @) phân tách các thành phần URL và phải được mã hóa bên trong giá trị thành phần, và sub-delims (! $ & ' ( ) * + , ; =) có ý nghĩa đặc biệt trong một số thành phần nhất định. Việc sub-delims có cần mã hóa hay không phụ thuộc vào ngữ cảnh — = và & là quan trọng bên trong chuỗi truy vấn nhưng vô hại bên trong một đoạn đường dẫn. Lối tắt an toàn: mã hóa mọi thứ ngoài tập không dành riêng.

Tại sao việc giải mã đôi khi để lại %25 nguyên văn trong chuỗi của tôi?

Bởi vì bản thân % phải được mã hóa thành %25 để phân biệt với chuỗi thoát mã hóa phần trăm. Nếu chuỗi của bạn chứa một dấu phần trăm nguyên văn đã được mã hóa đúng cách một lần thành %25, một lần giải mã sẽ biến nó trở lại thành %. Nhưng nếu chuỗi bị mã hóa hai lần — mã hóa một lần khi lưu trữ, mã hóa lại khi nối vào URL khác — một lần giải mã để lại %25 nguyên vị, sau đó trông giống một dấu thoát lạc. Mã hóa kép phổ biến trong các pipeline nơi URL được truyền dưới dạng tham số truy vấn cho dịch vụ khác: mỗi chặng thêm một lớp. Cách chữa là giải mã chính xác một lần cho mỗi chặng mã hóa, không nhiều hơn, không ít hơn. Theo dõi mọi nơi mã của bạn gọi hàm mã hóa và đảm bảo mỗi nơi có một lần giải mã tương ứng.

Các đoạn URL (phần sau #) có được mã hóa giống đường dẫn hoặc truy vấn không?

Chủ yếu là vậy, nhưng có hai khác biệt chính. RFC 3986 mục 3.5 định nghĩa bảng chữ cái đoạn là pchar / "/" / "?", cho phép / và ? không thoát bên trong đoạn mà không gây nhập nhằng (không có dấu phân định nào nữa sau #). Điều này có nghĩa là encodeURIComponent sẽ thoát quá mức các ký tự này trong đoạn, tạo ra %2F và %3F nơi các dạng không thoát là hợp lệ. Ngoài ra, đoạn không bao giờ được gửi đến máy chủ trong các yêu cầu HTTP — nó hoàn toàn ở phía máy khách — nên các bộ giải mã phía máy chủ có thể không bao giờ thấy nó. Khi xây dựng các đoạn deep-link cho SPA chứa JSON hoặc route, việc thoát quá mức từ encodeURIComponent thường ổn. Công cụ này cung cấp chế độ nhận biết đoạn.

Độ dài tối đa của URL là bao nhiêu, và điều gì xảy ra khi vượt quá?

Không có giới hạn cứng trong các đặc tả HTTP hoặc URL — RFC 7230 khuyến nghị rõ ràng các máy chủ hỗ trợ "dòng yêu cầu ít nhất 8000 octet". Trên thực tế, các trình duyệt, máy chủ và trung gian áp đặt giới hạn riêng. Chrome chấp nhận tối đa 32 KB trong thanh địa chỉ nhưng cắt nội bộ vượt 2 MB. Apache mặc định 8 KB (LimitRequestLine), Nginx 8 KB (large_client_header_buffers), và IIS 16 KB. AWS API Gateway giới hạn 8 KB. Vượt quá giới hạn chặng thấp nhất, bạn nhận được lỗi 414 URI Too Long. Đối với dữ liệu vượt quá vài trăm byte, hãy chuyển sang thân POST hoặc phân mảnh dữ liệu qua nhiều yêu cầu. Tải truy vấn nặng cũng phá vỡ phân tích, xoay log và tiêu đề referrer — giữ URL dưới 2 KB để di động.