Mã hóa/Giải mã chuỗi URL – Encode/decode URL-formatted strings

Công cụ mã hóa và giải mã chuỗi URL là gì?

Công cụ mã hóa và giải mã chuỗi URL là tiện ích chuyển văn bản sang dạng percent-encoding, hoặc chuyển dạng biểu diễn đó trở lại nội dung có thể đọc được. Nhu cầu thường gặp là đọc một giá trị chứa các nhóm như %20, chuẩn bị từ khóa tiếng Việt để đưa vào tham số, hoặc đối chiếu dữ liệu trước và sau khi encode.

Trong ngữ cảnh này, “mã hóa” nghĩa là đổi cách biểu diễn dữ liệu, không phải mã hóa bảo mật. Không cần khóa để decode, và người khác vẫn có thể khôi phục nội dung nếu chuỗi được biểu diễn đúng. Percent-encoding không tạo bí mật, không xác minh chữ ký và không chứng minh dữ liệu chưa bị thay đổi.

Theo mã nguồn được cung cấp, công cụ có hai lựa chọn encode: mã hóa thành phần URL bằng encodeURIComponent và mã hóa nguyên liên kết bằng encodeURI. Chiều decode luôn dùng decodeURIComponent. Đầu vào được xem là một chuỗi, nên bạn có thể nhập văn bản thông thường mà không cần có đường link hoàn chỉnh.

Kết quả trả về là chuỗi sau chuyển đổi hoặc thông báo lỗi định dạng. Trạng thái thành công chỉ cho biết phép chuyển đổi đã hoàn tất; nó không xác nhận liên kết tồn tại, đúng cấu trúc hay an toàn. Các quy ước về URL dưới đây là kiến thức nền, còn những hành vi như cách xử lý dấu cộng, số lớp decode và điều kiện sao chép được xác định từ logic của công cụ.

Năm thuật ngữ cần hiểu khi encode và decode URL

Percent-encoding

Percent-encoding là cách biểu diễn một byte bằng dấu phần trăm và hai chữ số thập lục phân, thường viết khái quát là %HH. Chẳng hạn, %20 biểu diễn byte của khoảng trắng. Đây là định dạng đầu ra quan trọng của công cụ. Điểm dễ nhầm là một nhóm %HH không luôn tương ứng với một ký tự hoàn chỉnh: chữ tiếng Việt có thể cần nhiều byte và nhiều nhóm liên tiếp. Cách biểu diễn này cũng không che giấu nội dung như mã hóa có khóa.

UTF-8

UTF-8 là cách biểu diễn ký tự Unicode thành các byte có độ dài thay đổi. Nó xác định byte của ký tự, còn percent-encoding viết các byte cần chuyển đổi thành nhóm có dấu phần trăm. Ví dụ, chữ à có hai byte UTF-8 và được encode thành %C3%A0. Hai khái niệm này không đồng nghĩa. Với các hàm URI chuẩn mà công cụ sử dụng, một chuỗi percent-encoded theo bảng mã khác UTF-8 có thể không giải mã được đúng hoặc phát sinh lỗi.

Thành phần URL

Thành phần URL là một phần của liên kết, chẳng hạn một đoạn dữ liệu trong đường dẫn hoặc giá trị của tham số. Trong công cụ này, lựa chọn “mã hóa tham số” phù hợp khi cần xử lý một giá trị riêng trước khi ghép vào URL. Ví dụ, dấu & trong tên sản phẩm phải được phân biệt với dấu ngăn các tham số. Không nên nhầm “thành phần” với toàn bộ liên kết: encode cả URL theo cách này sẽ chuyển đổi cả nhiều dấu cấu trúc của nó.

Query string

Query string là phần truy vấn thường bắt đầu sau dấu ? của URL. Trong cách dùng phổ biến, các cặp tên và giá trị được nối bằng &, còn = ngăn tên với giá trị. Những dấu ấy có vai trò cấu trúc, khác với dấu giống hệt nằm trong nội dung một giá trị. Vì vậy, mã hóa một giá trị không đồng nghĩa với mã hóa cả query string. Công cụ không tự tách các cặp tham số để quyết định dấu nào cần giữ lại.

application/x-www-form-urlencoded

application/x-www-form-urlencoded là quy ước biểu diễn dữ liệu biểu mẫu, trong đó khoảng trắng thường được thể hiện bằng dấu +. Đây là kiến thức nền cần biết khi đọc dữ liệu từ biểu mẫu hoặc hệ thống dùng quy ước tương tự. Công cụ hiện tại không có bộ giải mã biểu mẫu riêng: nó decode bằng hàm URI chuẩn và giữ nguyên dấu cộng có sẵn. Do đó, kết quả còn dấu + không nhất thiết là lỗi; có thể dữ liệu cần được diễn giải theo một quy ước khác.

Đầu vào, đầu ra và cách hiểu trạng thái kết quả

Những dữ liệu có thể đưa vào

Đầu vào là chuỗi ký tự, không có đơn vị đo hay trường số. Nội dung có thể gồm tiếng Việt, khoảng trắng, ký tự đặc biệt, một giá trị tham số hoặc liên kết đầy đủ. Công cụ không yêu cầu chuỗi phải có giao thức hay tên miền.

Khoảng trắng đầu và cuối không bị tự cắt bỏ. Chuỗi rỗng được xử lý riêng, còn chuỗi chỉ chứa khoảng trắng vẫn được chuyển đổi. Khi decode, các escape phải đúng dạng và các byte được encode phải tạo thành dữ liệu UTF-8 hợp lệ.

Kết quả và trạng thái nói lên điều gì?

Vùng kết quả chỉ đọc và tự cập nhật khi đầu vào, chế độ hoặc cấp độ encode thay đổi. Khi xử lý đầu vào rỗng, kết quả được làm trống và trạng thái chuyển sang chờ nhập liệu. Trạng thái “đã mã hóa” hoặc “đã giải mã” chỉ xác nhận phép chuyển đổi thành công. Nếu phát sinh ngoại lệ, vùng kết quả hiện thông báo lỗi và trạng thái lỗi định dạng.

Ý nghĩa của sao chép và hoán đổi

Chức năng xóa làm trống đầu vào và cập nhật đầu ra. Sao chép đưa nội dung kết quả vào clipboard nếu trình duyệt cho phép. Hoán đổi không trao đổi nguyên trạng hai vùng văn bản: nó đổi chiều encode/decode, lấy kết quả cũ làm đầu vào mới rồi chuyển đổi lại. Khi quay về Encode, lựa chọn cấp độ trước đó vẫn được dùng. Cả sao chép và hoán đổi đều không thực hiện nếu đầu ra rỗng hoặc chứa cụm chữ LỖI.

Quy tắc chuyển đổi khoảng trắng, tiếng Việt và ký tự đặc biệt

Từ ký tự đến các nhóm %HH

Công cụ dùng các hàm URI chuẩn để chuyển đổi chuỗi; không có phép tính số, đơn vị đo hay quy tắc làm tròn. Với ký tự cần encode, hàm biểu diễn ký tự thành byte UTF-8, rồi viết mỗi byte dưới dạng phần trăm và hai chữ số thập lục phân. Khoảng trắng trở thành %20. Chữ tiếng Việt thường cần nhiều byte, nên chuỗi sau encode có thể dài hơn đáng kể dù nội dung vẫn như cũ.

Mã hóa tham số không chuyển đổi mọi ký tự ngoài chữ và số. encodeURIComponent giữ nguyên chữ cái ASCII, chữ số và các ký tự - _ . ! ~ * ' ( ). Vì vậy, thấy một dấu chấm hoặc dấu ngoặc còn nguyên không có nghĩa công cụ bỏ sót. Phạm vi giữ nguyên phụ thuộc hàm được chọn, không phụ thuộc việc ký tự trông có vẻ “đặc biệt” hay không.

Một lần chuyển đổi và nhiều lớp encode

Mỗi lần xử lý chỉ gọi hàm chuyển đổi một lần. Dấu phần trăm được encode thành %25, nên encode một chuỗi đã có percent-encoding sẽ tạo thêm lớp biểu diễn. Chẳng hạn, chuỗi ký tự %20 trở thành %2520 khi encode lại; đây không còn là cùng một lớp biểu diễn khoảng trắng.

Ở chiều ngược lại, decode chỉ gỡ một lớp, không lặp đến khi hết dấu phần trăm. Điều này quan trọng vì một phần dữ liệu có thể vốn cần giữ nguyên dạng %20. Công cụ cũng không tự sửa escape hỏng. Nếu hàm chuyển đổi phát sinh ngoại lệ, cả lần xử lý trả thông báo lỗi, không có phần kết quả đã giải mã trước vị trí lỗi.

Dấu cộng không tự trở thành khoảng trắng

Trong logic hiện tại, encode khoảng trắng tạo %20, không tạo dấu cộng. Decode giữ nguyên dấu + có sẵn, nhưng chuyển %2B thành +. Đây là hành vi của decodeURIComponent, khác với việc đọc dữ liệu biểu mẫu theo quy ước dùng dấu cộng cho khoảng trắng.

Vì thế, cần biết dữ liệu đến từ đâu trước khi kết luận kết quả đúng với ý định ban đầu. Một dấu cộng có thể là ký tự thực trong tên hoặc biểu thức, cũng có thể đại diện cho khoảng trắng theo quy ước của hệ thống tạo dữ liệu. Công cụ không tự phân biệt hai trường hợp ấy.

Mã hóa tham số và mã hóa nguyên liên kết khác nhau thế nào?

So sánh phạm vi giữ nguyên ký tự

Khác biệt chính là cách xử lý dấu có thể thuộc cấu trúc URL, không phải mức độ bảo mật. Hai lựa chọn đều là chuyển đổi biểu diễn có thể đảo ngược.

Chọn theo vai trò của dữ liệu

Nếu chuỗi là một giá trị chứa & hoặc =, mã hóa thành phần giúp các dấu ấy không bị hiểu thành ranh giới tham số khi ghép vào liên kết. Nếu chuỗi là URL đã có cấu trúc, encode nguyên liên kết giữ lại nhiều dấu phân cách cần thiết. Tuy nhiên, encodeURI không tự biết dấu & nào thuộc dữ liệu; bạn vẫn phải xác định đúng phạm vi cần xử lý.

Percent-encoding cũng khác Base64 về cách biểu diễn và mục đích sử dụng. Nếu cần phân biệt hai dạng này, công cụ mã hóa và giải mã Base64 là một tác vụ khác, không phải cấp độ encode URL bổ sung.

Vì sao chiều decode không hoàn toàn đối xứng?

Công cụ chỉ dùng decodeURIComponent, không có lựa chọn decodeURI riêng. Vì vậy, decode có thể phục hồi cả các dấu cấu trúc từng được encode. Kết quả dễ đọc hơn chưa chắc phù hợp để dùng ngay làm liên kết, nhất là khi dữ liệu bên trong chứa dấu phân cách.

Ví dụ encode và decode URL có kết quả đối chiếu

Văn bản tiếng Việt và một giá trị có dấu phân cách

Các ví dụ sau dùng dữ liệu giả định, với đơn vị dữ liệu là chuỗi ký tự. Kết quả được suy ra từ nhánh xử lý và quy tắc của hàm URI chuẩn, không phải báo cáo chạy thử công cụ.

Với đầu vào xin chào, chọn Encode tham số sẽ cho xin%20ch%C3%A0o. Các chữ ASCII giữ nguyên, khoảng trắng thành %20, còn chữ à có hai byte UTF-8 C3 và A0 nên thành %C3%A0. Chuỗi dài hơn nhưng không chứa thêm ý nghĩa mới.

Với đầu vào a&b=c/d?e, hai phạm vi cho kết quả khác nhau:

• Mã hóa tham số: a%26b%3Dc%2Fd%3Fe.
• Mã hóa nguyên liên kết: a&b=c/d?e.

Ví dụ này minh họa phạm vi giữ nguyên dấu, không khẳng định đầu vào là URL hợp lệ. Nếu toàn bộ chuỗi là nội dung của một giá trị, lựa chọn tham số giữ được ranh giới giữa dữ liệu và cấu trúc khi ghép vào URL.

Liên kết đầy đủ và dấu cộng

Giả sử đầu vào là https://example.com/tim?q=a b&lang=vi và chọn mã hóa nguyên liên kết. Kết quả là https://example.com/tim?q=a%20b&lang=vi: các dấu cấu trúc được giữ, khoảng trắng giữa hai chữ được chuyển đổi. Không có bước truy cập tên miền hay kiểm tra liên kết trong phép chuyển đổi này.

Ở chiều Decode, chuỗi a+b%20c%2Bd trở thành a+b c+d. Dấu cộng ban đầu còn nguyên, %20 trở thành khoảng trắng và %2B trở thành dấu cộng. Vì thế, không nên đọc mọi dấu cộng trong kết quả như một khoảng trắng bị xử lý thiếu.

Chuỗi nhiều lớp và dữ liệu không hợp lệ

Với %2520, một lần Decode trả %20. Chỉ khi lấy kết quả ấy làm đầu vào cho một lần Decode nữa thì đầu ra mới là một khoảng trắng. Việc có cần bước thứ hai hay không phụ thuộc nội dung dự kiến, không chỉ phụ thuộc việc còn thấy dấu phần trăm.

Hai đầu vào abc% và %C3 đều dẫn đến thông báo lỗi. Trường hợp đầu thiếu hai chữ số sau dấu phần trăm; trường hợp sau có byte mở đầu UTF-8 nhưng thiếu phần tiếp theo. Công cụ không trả abc như một kết quả giải mã từng phần và cũng không tự bổ sung dữ liệu còn thiếu.

Khi nào nên dùng công cụ chuyển đổi chuỗi URL?

Chuẩn bị giá trị tham số

Công cụ phù hợp khi bạn đã biết một chuỗi sẽ đóng vai trò giá trị tham số, chẳng hạn từ khóa tìm kiếm có tiếng Việt, khoảng trắng hoặc dấu phân cách. Mã hóa giá trị riêng giúp tránh việc nội dung bị hiểu thành tham số mới. Công cụ không tự tạo hay ghép URL; việc đặt kết quả vào đúng vị trí vẫn thuộc tác vụ của bạn hoặc hệ thống sử dụng dữ liệu.

Đọc nội dung đã percent-encode

Bạn có thể dùng Decode để đọc một giá trị lấy từ liên kết, báo cáo hoặc dữ liệu kiểm tra. Mục đích là hiểu nội dung bằng mắt và đối chiếu với văn bản dự kiến, không phải phân tích toàn bộ báo cáo. Khi dữ liệu đi qua nhiều hệ thống, việc đối chiếu từng lớp giúp nhận ra chỗ có thể đã encode lại, nhưng không tự chứng minh hệ thống nào tạo ra lớp đó.

Chọn đúng tác vụ thay vì chỉ đổi biểu diễn

Nếu cần tách giao thức, tên miền, đường dẫn hoặc từng tham số, đó là nhu cầu phân tích URL, khác với chuyển đổi chuỗi. Bạn có thể cân nhắc tác vụ như trình phân tích URL thay vì mong thao tác Decode tự cung cấp cấu trúc liên kết. Hai công cụ không được xác nhận là tự tích hợp với nhau.

Trước khi sử dụng lại kết quả, hãy xác định bạn đang cần văn bản dễ đọc hay chuỗi để truyền đi. Decode quá mức có thể đưa dấu phân cách trở lại trong dữ liệu, khiến hệ thống tiếp nhận hiểu khác ý định ban đầu.

Giới hạn, lỗi thường gặp và lưu ý với dữ liệu nhạy cảm

Khi chuỗi không thể chuyển đổi

Lỗi decode có thể do escape sai, thiếu chữ số hoặc chuỗi byte không hợp lệ theo UTF-8. Dữ liệu từ bảng mã khác cũng không được tự chuyển sang UTF-8. Ở chiều Encode, Unicode bất thường như surrogate đơn lẻ có thể gây ngoại lệ. Thông báo chung không chỉ rõ vị trí lỗi, nên không nên coi mọi lỗi đều là percent-encoding hỏng. Công cụ không có chức năng tự sửa chuỗi hay bộ xử lý biểu mẫu dùng dấu cộng riêng.

Kết quả hợp lệ chưa chắc dùng lại đúng cách

Một URL sau decode có thể xuất hiện &, = hoặc # vốn nằm trong dữ liệu đã encode. Nếu đưa nguyên kết quả sang hệ thống khác, các dấu ấy có thể bị hiểu thành cấu trúc. Thành công cũng không xác nhận URL đúng định dạng, truy cập được hay không độc hại; công cụ không thực hiện những kiểm tra đó.

Sao chép, dung lượng và quyền riêng tư

Sao chép phụ thuộc Clipboard API và điều kiện của trình duyệt. Ngoài ra, đầu ra hợp lệ chứa cụm LỖI vẫn bị chặn sao chép và hoán đổi, vì hai chức năng kiểm tra nội dung chuỗi. Mã được cung cấp không đặt giới hạn ký tự cụ thể, nhưng điều đó không chứng minh dung lượng vô hạn hoặc hiệu năng ổn định với chuỗi rất dài.

Logic chuyển đổi dùng JavaScript trong trình duyệt. Tuy nhiên, chưa có toàn bộ mã trang và cấu hình website để xác minh việc thu thập, truyền hoặc lưu dữ liệu. Vì vậy, nên tránh nhập mật khẩu, token hay thông tin riêng tư khi chưa rõ chính sách xử lý; không thể cam kết bảo mật tuyệt đối từ đoạn mã này.

Câu hỏi thường gặp

Vì sao decode xong dấu + vẫn không thành khoảng trắng?

Vì công cụ dùng decodeURIComponent, hàm không đổi dấu cộng có sẵn thành khoảng trắng. Đây là hành vi đúng với cách giải mã đang triển khai, không tự động là lỗi. Nếu dữ liệu được tạo theo quy ước biểu mẫu, dấu cộng có thể đại diện cho khoảng trắng; nhưng nếu nó thuộc nội dung thực, đổi dấu sẽ làm sai dữ liệu. Bạn cần xác định quy ước của nguồn dữ liệu. Riêng %20 được giải mã thành khoảng trắng và %2B thành dấu cộng.

Nên mã hóa cả đường link hay chỉ giá trị tham số?

Nên chọn theo vai trò của chuỗi, không theo độ dài hoặc số ký tự đặc biệt. Nếu chuỗi là một giá trị sẽ được đặt vào tham số, lựa chọn mã hóa tham số thường phù hợp để bảo vệ ranh giới dữ liệu. Nếu đó là liên kết đã có cấu trúc cần giữ, mã hóa nguyên liên kết giữ lại các dấu phân cách. Tuy nhiên, lựa chọn này không tự nhận biết dấu nằm trong giá trị. Một URL ghép sai từ trước không được tự sửa chỉ bằng encode.

Vì sao một ký tự tiếng Việt lại tạo ra nhiều nhóm %HH?

Vì nhóm %HH biểu diễn một byte, trong khi một ký tự tiếng Việt có thể cần nhiều byte UTF-8. Chẳng hạn, chữ à cần hai byte nên có hai nhóm trong dạng %C3%A0. Độ dài hiển thị tăng không có nghĩa ký tự đã biến thành nhiều chữ độc lập. Khi decode, các byte hợp lệ được đọc cùng nhau để phục hồi ký tự. Do đó, không nên cắt hoặc chỉnh riêng từng nhóm theo giả định rằng mỗi nhóm là một chữ hoàn chỉnh.

Chuỗi %2520 có cần giải mã thêm lần nữa không?

Chỉ cần nếu nội dung bạn thực sự muốn nhận là khoảng trắng và biết dữ liệu đã được encode qua hai lớp. Sau lần đầu, kết quả %20 cũng có thể chính là văn bản cần giữ nguyên, chẳng hạn một ví dụ đang mô tả percent-encoding. Công cụ không biết ý định đó và không tự decode tiếp. Hãy đối chiếu với dữ liệu gốc hoặc quy ước của hệ thống tạo chuỗi, thay vì tiếp tục giải mã chỉ để loại bỏ mọi dấu phần trăm còn thấy.

Thông báo URI malformed có nghĩa là đường link không tồn tại không?

Không. Thông báo này liên quan đến việc hàm chuyển đổi không xử lý được chuỗi, không phải kết quả kiểm tra website. Một escape thiếu hoặc chuỗi byte UTF-8 chưa hoàn chỉnh có thể gây lỗi dù tên miền vẫn tồn tại. Ngược lại, chuỗi decode thành công có thể không phải liên kết, hoặc trỏ đến địa chỉ không truy cập được. Thông báo chung còn được dùng cho ngoại lệ ở chiều Encode, nên không thể dựa vào nó để kết luận tình trạng của đường link.

Vì sao kết quả là chữ LỖI nhưng không sao chép hoặc hoán đổi được?

Vì hai chức năng này kiểm tra xem nội dung đầu ra có chứa cụm chữ LỖI hay không, thay vì chỉ dựa vào trạng thái chuyển đổi. Chẳng hạn, L%E1%BB%96I được decode hợp lệ thành LỖI, nhưng vẫn thỏa điều kiện chặn. Đây là trường hợp kết quả thành công trùng với cụm chữ dùng để nhận diện lỗi. Bạn cần phân biệt trạng thái “đã giải mã” với khả năng sử dụng nút sao chép hoặc hoán đổi; việc nút không thực hiện không tự chứng minh chuỗi bị hỏng.

Có thể khẳng định dữ liệu nhập không được gửi hoặc lưu trên website không?

Không thể khẳng định từ mã được cung cấp. Đoạn xử lý chính cho thấy việc encode và decode dùng các hàm chuẩn trong trình duyệt, nhưng chưa đủ để đánh giá toàn bộ hoạt động của website. Các phần khác của trang, script bổ sung hoặc cấu hình máy chủ chưa được xác minh. Vì vậy, không nên suy ra cam kết “không gửi” hay “không lưu” chỉ từ nơi diễn ra phép chuyển đổi. Với dữ liệu nhạy cảm, hãy cân nhắc chính sách riêng tư và môi trường sử dụng trước khi nhập.