2012-08-16 28 views
5

Đoạn mã bên dưới tải xuống tệp từ một số URL và lưu tệp đó vào tệp cục bộ. Miếng bánh. Điều gì có thể sai ở đây?Ai đang giả mạo luồng dữ liệu của tôi?

protected long download(ProgressMonitor montitor) throws Exception{ 
    long size = 0; 
    DataInputStream dis = new DataInputStream(is); 
    int read = 0; 
    byte[] chunk = new byte[chunkSize]; 
    while((read = dis.read(chunk)) != -1){ 
     os.write(chunk, 0, read); 
     size += read; 
     if(montitor != null) 
      montitor.worked(read); 
    } 

    chunk = null; 
    dis.close(); 
    os.flush(); 
    os.close(); 
    return size; 
} 

Lý do tôi đăng một câu hỏi ở đây là bởi vì nó hoạt động trong 99,999% thời gian và không hoạt động như mong đợi bất cứ khi nào có một chống virus hoặc một số phần mềm bảo vệ khác được cài đặt trên máy tính chạy mã này. Tôi mù quáng chỉ một ngón tay như vậy bởi vì bất cứ khi nào tôi dừng lại (hoặc vô hiệu hóa) nó, mã hoạt động hoàn hảo một lần nữa. Kết quả cuối cùng của sự can thiệp đó là MD5 của tệp đã tải xuống không khớp với mong đợi và một câu chuyện hoàn toàn mới bắt đầu.

Vì vậy, câu hỏi đặt ra là - có thực sự là một số phần mềm "bảo vệ" thông minh có thể thay đổi luồng thực tế đến từ URL mà tôi không biết về nó không? Và nếu có - làm thế nào để bạn đối phó với điều này? (đã xác minh với sản phẩm Kasperksy và Norton).


EDIT-1: Rõ ràng tôi đã có một tổ chức về vấn đề này và nó có liên quan gì đến antiviruses. Quá trình tải xuống diễn ra từ máy chủ FTP (đặc biệt là FileZilla) và chúng tôi sử dụng apache commons ftp ở phía máy khách. Những gì tôi đã làm là đi đến máy chủ FTP và chấm dứt kết nối (đá nó ra) ở giữa tải xuống. Tôi hy vọng rằng is.read (..) sẽ ném một IOException về phía khách hàng, nhưng điều này không bao giờ xảy ra. Thay vào đó, is.read (..) trả về -1 có nghĩa là không có thêm dữ liệu đến từ luồng. Điều này chắc chắn là không mong muốn và giải thích tại sao đôi khi tôi nhận được một phần tệp. Tuy nhiên, điều này không giải thích tại sao đôi khi dữ liệu cũng bị thay đổi.

+1

Xác định 'barfs'. – EJP

+1

Làm thế nào để bạn xử lý các ngoại lệ? Nếu 'dis.close()' ném ngoại lệ, luồng đầu ra sẽ không đóng đúng cách chẳng hạn. – dacwe

+0

@dacwe - bất cứ điều gì được ném từ phương pháp này là một thất bại, mọi thứ đều bị hủy bỏ. Bí ẩn là không có gì bị ném ra, mọi thứ đều được tải xuống tốt. Vấn đề là nó không phải là dữ liệu tôi mong đợi, phần lớn thời gian nó bị cắt làm đôi, đôi khi bị thay đổi .. – Dima

Trả lời

1

Điều này xảy ra với tôi mọi lúc. Trong trường hợp của tôi, nó được gây ra bởi proxy HTTP trong suốt bởi Websense trên mạng công ty của tôi. Vấn đề tồi tệ nhất là do trang chặn được trả lại với 200 OK.

Bạn có nhận được tham nhũng tương tự hoặc tương tự mỗi lần không? Ví dụ: bạn có nhận được một số HTML giải thích lý do yêu cầu bị chặn không? Điều tốt nhất bạn có thể làm là so sánh vài byte đầu tiên của dữ liệu đã tải xuống với một số văn bản trong trang chặn và ném một ngoại lệ trong trường hợp này.

Chỉnh sửa: dựa trên bản cập nhật của bạn, bạn đã đặt máy khách FTP thành chế độ hình ảnh/nhị phân chưa?

+0

Trong trường hợp của tôi nó không phải là một văn bản, tôi đã có thể nhận thấy những gì chính xác bị giả mạo. Tôi tải xuống gói cài đặt nhị phân, vì vậy thật khó để nói phần nào của nó được thổi. Kết quả cuối cùng là một lỗi nhị phân và sự nhầm lẫn hoàn toàn của người dùng cuối mà chỉ một ngón tay vào tôi khi nó thực sự là một cái gì đó mà ngồi trên mạng của họ. – Dima

+0

Bạn cần ghi ra các byte không chính xác vào đĩa và xem chúng. – artbristol

+0

có lẽ đó là một ý tưởng hay .. – Dima

Các vấn đề liên quan