Mã hoá / Giải mã URL
Mã hoá phần trăm văn bản cho URL và chuỗi truy vấn, hoặc giải mã URL đã được mã hoá. Chuyển đổi giữa encodeURIComponent cho từng giá trị và encodeURI cho cả
Mã hoá phần trăm văn bản để nó truyền đi an toàn bên trong một URL, hoặc giải mã một liên kết bạn sao chép từ log hay email. Những giá trị như dấu cách, dấu và, dấu hỏi và ký tự phi Latinh phải được escape trước khi đưa vào chuỗi truy vấn, và công cụ này cho bạn thấy chính xác dạng đã mã hoá trông như thế nào.
Hai chế độ đều quan trọng: mã hoá một giá trị đơn (một từ khoá tìm kiếm, một địa chỉ email, một token) sẽ escape mọi ký tự dành riêng, còn mã hoá cả liên kết sẽ giữ nguyên các ký tự cấu trúc - dấu gạch chéo, dấu hỏi, dấu và. Chọn sai chế độ là nguyên nhân kinh điển khiến một chuyển hướng bị hỏng, nên công cụ cho phép chọn chế độ.
Cách mã hoá và giải mã URL
Dán văn bản hoặc một URL
Chọn chế độ giá trị hoặc chế độ cả liên kết
Sao chép kết quả đã mã hoá hoặc giải mã
Câu hỏi thường gặp
Hai chế độ khác nhau ở điểm nào?
Chế độ giá trị escape các ký tự dành riêng như & = ? / #, đúng thứ bạn cần bên trong một tham số truy vấn. Chế độ cả liên kết giữ nguyên những ký tự đó để một URL hoàn chỉnh vẫn dùng được.
Vì sao dấu cách thành %20 hoặc +?
%20 là cách mã hoá phần trăm chuẩn. Dấu cộng là quy ước cũ từ việc gửi biểu mẫu HTML và chỉ tương đương bên trong chuỗi truy vấn, không đúng trong phần đường dẫn.
Công cụ có giải mã được không, hay chỉ mã hoá?
Có, việc giải mã chạy được theo cả hai chiều và hiển thị các ký tự gốc, kể cả chữ có dấu và văn bản CJK.
Vì sao chuỗi của tôi giải mã không được?
Một dấu % lẻ không kèm hai chữ số thập lục phân là không hợp lệ và không thể giải mã. Hãy kiểm tra xem giá trị có bị cắt cụt hay có dấu phần trăm vốn được dùng theo nghĩa đen.
Công cụ có xử lý ký tự phi Latinh không?
Có, văn bản được mã hoá theo UTF-8 trước rồi mới mã hoá phần trăm - đúng dạng mà trình duyệt và máy chủ mong đợi.
Nội dung tôi nhập có bị tải lên không?
Không, việc mã hoá và giải mã chỉ là thao tác văn bản thuần trong trình duyệt của bạn.
Tổng quan nhanh
| Đầu vào | văn bản |
|---|---|
| Nhiều tệp cùng lúc | Không |
| Chạy ở đâu | Ngay trong trình duyệt - tệp không bao giờ bị tải lên |
| Dùng được ngoại tuyến | Có — sau khi trang đã tải xong |
| Giá | Miễn phí, không đăng ký, không hình mờ |
Chọn một định dạng dữ liệu
JSON là mặc định cho mọi thứ một API trả về hoặc một chương trình đọc vào: nó xử lý cấu trúc lồng nhau, số, giá trị boolean và null một cách tự nhiên, và ngôn ngữ nào cũng phân tích được nó. CSV nhỏ hơn và mở thẳng vào bảng tính, nhưng nó không có cách nào diễn tả cấu trúc lồng nhau và không có tiêu chuẩn chung cho ký tự phân tách, cách đặt ngoặc kép hay bộ ký tự - đó chính là chỗ các phép chuyển đổi hay sai. XML dài dòng nhưng mang được thuộc tính, nội dung hỗn hợp và lược đồ, nên nó vẫn chiếm ưu thế trong các định dạng tài liệu và những hệ thống tích hợp cũ. YAML dễ đọc nhất cho phần cấu hình nhưng rất nhạy với dấu cách và có những cách ép kiểu gây bất ngờ ("no" thành false, một phiên bản như 1.10 thành 1.1). Hãy chọn định dạng mà công cụ tiếp nhận ưa dùng, chứ không phải định dạng trông đẹp nhất.
Những chỗ việc chuyển đổi âm thầm hỏng
Phần lớn lỗi chuyển đổi không nằm ở cú pháp mà ở ý nghĩa. Một cột mã bưu chính trong CSV mất các số 0 đứng đầu ngay khi bảng tính đoán rằng đó là số; một ID dài vượt quá độ chính xác của số dấu phẩy động; ngày tháng đổi nghĩa tuỳ theo nó được viết theo kiểu ngày trước hay tháng trước. Các khoá JSON không có thứ tự nhưng mảng thì có, và một công cụ sắp xếp khoá thì không đổi gì, còn công cụ sắp xếp mảng thì đổi dữ liệu. Unicode là một cái bẫy khác: văn bản có thể đến dưới dạng UTF-8, UTF-16 hoặc kèm dấu thứ tự byte, và một bộ giải mã đoán sai sẽ biến các ký tự có dấu thành chữ hỏng. Trước khi tin vào bất kỳ phép chuyển đổi nào, hãy kiểm tra nhanh hàng đầu và hàng cuối, mọi trường có số 0 đứng đầu, và mọi trường chứa dấu ngoặc kép, dấu phẩy hay ký tự xuống dòng.