Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã URL
URIError: URI không đúng định dạng - tại sao giải mãURIComponent lại ném và cách khắc phục
· Cách thức hoạt động
url-encoding javascript error-handling
giải mãURIComponent ném khi dấu phần trăm không được theo sau bởi hai chữ số thập lục phân hoặc khi byte được giải mã không hợp lệ UTF-8. Bài đăng này hiển thị các yếu tố đầu vào kích hoạt nó và cách giải mã một cách phòng thủ.
Dấu phần trăm bị lỗi — tại sao "100% off" lại phá vỡ giải mãURIComponent
Biểu mẫu thu thập mã giảm giá "100% off". JavaScript chuyển thông tin này tới bộ giải mãURIComponent trong bộ giải mã URL. Hàm đưa ra URIError: URI không đúng định dạng. Dấu phần trăm không được theo sau bởi hai chữ số thập lục phân. Điều này vi phạm hoàn toàn các quy tắc mã hóa phần trăm. giải mãURIComponent dự kiến mỗi % sẽ bắt đầu một bộ ba như %20 hoặc %C3. % đơn độc là một lỗi cú pháp dừng thực thi ngay lập tức và đưa ra lỗi.
Việc bắt lỗi này một cách an toàn sẽ ngăn chặn hoàn toàn sự cố ứng dụng. URL đến từ đầu vào của người dùng, chuyển hướng, mã QR và email. Lỗi chính tả xảy ra thường xuyên. Báo cáo sự cố với URIError sẽ cho bạn biết nơi cần điều tra nhanh chóng. Giải mã phòng thủ giúp ứng dụng luôn chạy và nhật ký lỗi trở nên hữu ích cho việc gỡ lỗi.
Hai loại lỗi — thoát hex không đúng định dạng và chuỗi byte UTF-8 không hợp lệ
giải mãURIComponent ném vào đúng hai tình huống. Đầu tiên: trình tự thoát không đúng định dạng. Phần trăm không có hai chữ số thập lục phân theo sau (0-9, A-F, a-f). Ví dụ: %ZZ, %2, %2g. Thứ hai: bộ ba hợp lệ như giải mã %E9 thành UTF-8 byte không hợp lệ. Đầu tiên là lỗi định dạng. Thứ hai là lỗi ngữ nghĩa. Cả hai ném và dừng thực hiện ngay lập tức.
UTF-8 có các quy tắc nghiêm ngặt về chuỗi byte. Byte 0x80–0xFF chỉ xuất hiện trong chuỗi nhiều byte. Chỉ một %E9 không thể hợp lệ UTF-8. Byte mồ côi này gây ra lỗi. Lỗi định dạng là hiển nhiên. Lỗi ngữ nghĩa rất tinh vi nhưng không kém phần thực tế. Cả hai trường hợp đều yêu cầu xử lý try/catch trong mã sản xuất.
Mã hóa một byte kế thừa — khi %E9 ném một mình nhưng %C3%A9 vẫn tồn tại
Sự nhầm lẫn bắt nguồn từ lịch sử tiêu chuẩn web. Các trang cũ sử dụng tiếng Latin-1 thay vì UTF-8. Trong tiếng Latin-1, %E9 đại diện cho é. Các trình duyệt hiện đại chỉ sử dụng UTF-8. UTF-8 mã hóa é dưới dạng %C3%A9. Bộ giải mã hiện đại mong đợi UTF-8 và từ chối %E9 vì không đúng định dạng. Đây là hành vi đúng đắn. Lỗi báo hiệu sự cố với dữ liệu nguồn.
Sự đồng thuận hiện đại: UTF-8 ở mọi nơi. Tiêu chuẩn URL chỉ định UTF-8. Tất cả các trình duyệt hiện tại đều sử dụng UTF-8. Nếu bạn gặp %E9 từ hệ thống cũ, hãy nắm bắt lỗi và chuyển về chuỗi thô. Không giải mã dưới dạng Latin-1 trong mã hiện đại. Điều tra xem dữ liệu có nguồn gốc từ đâu.
Ba đầu vào, ba thông báo lỗi - các động cơ khác nhau như thế nào trên cùng một chuỗi bị hỏng
Công cụ trình duyệt từ chối đầu vào không đúng định dạng một cách nhất quán nhưng lỗi từ thì khác nhau. Chrome báo cáo "URI không đúng định dạng". Firefox báo cáo "chuỗi URI không đúng định dạng". Safari báo cáo "không thể chuyển đổi không xác định thành đối tượng". Cả ba động cơ đều từ chối đầu vào giống hệt nhau. Từ ngữ thông báo chính xác không được chuẩn hóa trên các công cụ hoặc phiên bản khác nhau. Không bao giờ dựa vào văn bản lỗi để hướng dẫn logic mã.
Không bao giờ khớp chuỗi thông báo lỗi cho các quyết định của chương trình. Luôn bắt URIError theo loại. Hàm giải mãUrl bao bọc giải mãURIComponent và cung cấp mã nhất quán INVALID_PERCENT_ENCODING. Điều này đặt tên chính xác cho vị trí vấn đề. Nó hoạt động trong nhiều thời gian chạy vì nó không phụ thuộc vào các biến thể từ ngữ của công cụ. Cách tiếp cận này đáng tin cậy và dễ bảo trì hơn.
Đọc ngoại lệ một cách an toàn — thử/catch, xác thực và các mẫu dự phòng
Mẫu phòng thủ đơn giản nhất: bọc giải mãURIComponent trong try/catch. Nếu nó ném, hãy sử dụng chuỗi thô hoặc ký tự thay thế. Điều này ngăn ngừa sự cố đầu vào không đúng định dạng. Đối với các giá trị truy vấn, hãy hiển thị biểu mẫu được mã hóa URL. Đối với văn bản hướng tới người dùng, hãy chèn ký tự thay thế. Điều này giúp đầu vào xấu không làm hỏng ứng dụng và duy trì sự ổn định.
Xác thực trước bằng các biểu thức thông thường để đảm bảo tốc độ và an toàn. Kiểm tra xem đầu vào chỉ chứa bộ ba %XX hợp lệ trước khi giải mã. Mẫu /%[0-9A-Fa-f]{2__/g bắt các lối thoát hợp lệ; bất cứ điều gì không phù hợp đều không hợp lệ. Lỗi định dạng thất bại nhanh chóng trên rác rõ ràng. UTF-8 lỗi vẫn cần thử/catch. Điều này cùng nhau cung cấp khả năng bảo vệ phòng thủ toàn diện khỏi lỗi.
Thất bại thầm lặng che giấu lỗi - tại sao giải mã mù cũng nguy hiểm như mã hóa bị hỏng
Rủi ro tinh vi: bộ giải mã không ném ra mà âm thầm tạo ra văn bản sai. Mã cũ sử dụng unescape không được dùng nữa sẽ khiến UTF-8 trong bộ nhớ không hợp lệ. Văn bản trông ổn trên màn hình cho đến khi tiếp cận các hệ thống xác thực UTF-8 một cách nghiêm ngặt. Ném mã hiện đại thay vì tham nhũng một cách âm thầm. Một ngoại lệ rõ ràng và an toàn hơn việc tham nhũng dữ liệu thầm lặng lan rộng xuống hạ lưu.
Giả sử đầu vào của người dùng không đúng định dạng. Luôn kết thúc cuộc gọi. Ghi lại lỗi với dữ liệu đầu vào ban đầu để gỡ lỗi. Đừng bao giờ cho rằng mọi % đều hợp lệ. Lỗi đánh máy và cắt bớt tạo ra các lối thoát không đầy đủ. Hãy coi đó là lỗi dữ liệu, không phải lỗi logic. Mã phòng thủ vượt qua đầu vào xấu một cách duyên dáng và giữ cho hệ thống luôn đáng tin cậy.
Những công cụ thực tế nào bỏ qua - hành vi của khung phía máy chủ và khôi phục lỗi
Khung máy chủ xử lý mã hóa không đúng định dạng nhẹ nhàng hơn so với trình duyệt. Ruby, Python và PHP cung cấp cấu hình để xử lý các lỗi thoát không hợp lệ trong URL. Một số ký tự thay thế thay thế tự động. Những người khác thả byte một cách âm thầm. Một số trường hợp ngoại lệ được đưa ra như JavaScript. Hành vi thực tế thay đổi tùy theo cài đặt khung và cấu hình do nhà phát triển chọn.
Bài viết này chỉ đề cập đến hành vi JavaScript của trình duyệt. Nếu các giá trị đến từ API máy chủ thì máy chủ đã giải mã hoặc bỏ qua lỗi trước khi gửi. Máy chủ có thể dễ tha thứ hơn máy khách. Khi viết hợp đồng API, hãy chỉ định xem giá trị là thô hay được giải mã trước. URL chuỗi truy vấn phải được mã hóa phần trăm; JSON có thể được giải mã trước.
Xác thực sớm — sử dụng bộ mã hóa và giải mã URL để kiểm tra các chuỗi đáng ngờ trước tiên
Trước khi chuyển các URL đáng ngờ tới bộ giải mãURIComponent, hãy dán vào bộ mã hóa và giải mã URL. Công cụ này hiển thị mã hóa chính xác, phát hiện các lối thoát không đúng định dạng và giải thích các lỗi mà không làm hỏng ứng dụng của bạn. Kiểm tra với %ZZ, %E9 và 100% để xem các lỗi khác nhau và thông báo lỗi chính xác của chúng. Việc này chỉ mất vài giây và tạo dựng sự tự tin.
Xác thực sớm, phát hiện lỗi một cách khéo léo và ghi lại những gì đã xảy ra. Bộ giải mã phòng thủ cộng với công cụ kiểm tra giúp ứng dụng luôn chạy và có thể gỡ lỗi. Bộ mã hóa và giải mã URL biến "URI không đúng định dạng" thành thông tin hữu ích mà bạn có thể sử dụng ngay lập tức. Áp dụng mẫu này cho bộ giải mã của riêng bạn để có khả năng phục hồi và bảo trì trong môi trường sản xuất.