getContentLengthLong က -1 ပြန်ပေးသောအခါ Java ပရောက်စီ ဒေါင်းလုဒ်များ

getContentLengthLong() == -1 ဆိုသည်မှာ ရနိုင်သော မက်တာဒေတာတွင် သိရှိထားသော အကြောင်းအရာ အရှည် မရှိခြင်း ဖြစ်သည်။ စီးကြောင်းကို ဆက်လက်ဖတ်ပြီး လက်ခံရရှိသော ဘိုက်များ သို့မဟုတ် မသေချာသော တိုးတက်မှုကို ပြပါ; ၎င်းကို အလွတ်တုံ့ပြန်မှုအဖြစ် မသတ်မှတ်ပါနှင့်၊ အနုတ်လက္ခဏာ အရွယ်အစားရှိ ဘာဖာကို မခွဲဝေပါနှင့်။

long expected = connection.getContentLengthLong();
long received = 0;
byte[] buffer = new byte[8192];
try (InputStream input = connection.getInputStream()) {
    int count;
    while ((count = input.read(buffer)) != -1) {
        output.write(buffer, 0, count);
        received += count;
    }
}

ချိတ်ဆက်မှုကို ကြိုတင်ပြင်ဆင်ထားပြီး output ကို ခေါ်သူက ပိုင်ဆိုင်သည်။ ဤကွင်းဆက်ပတ်လည်တွင် ချိတ်ဆက်မှုနှင့် ဖတ်ခြင်း အချိန်သတ်မှတ်ချက်များနှင့် အက်ပ်လီကေးရှင်း၏ အရွယ်အစား ကန့်သတ်ချက်ကို ထိန်းထားပါ။ I/O အမှားသည် မအောင်မြင်သော ဒေါင်းလုဒ်ဖြစ်သည်၊ ဘိုက်နည်းဖြင့် အောင်မြင်စွာ ပြီးဆုံးခြင်း မဟုတ်ပါ။

အရှည်များကို တူညီသော အလွှာတွင် နှိုင်းယှဉ်ပါ။ HTTP/1.1 ၏ chunked ကုဒ်ပြောင်းခြင်းသည် Content-Length ကို အစားထိုးနိုင်ပြီး HTTP အကောင်အထည်ဖော်မှုက ကုဒ်ဖျက်သည်။ ပရောက်စီက ပြန်လည်ဘောင်ခတ်နိုင်သည်။ ချုံ့ဖျက်ခြင်းကလည်း အက်ပ်၏ ကုဒ်ဖျက်ပြီး ဘိုက်အရေအတွက်ကို ကုဒ်ပြောင်းထားသော Content-Length နှင့် ကွာခြားစေနိုင်သည်။

Transfer-Encoding နှင့် Content-Length နှစ်ခုလုံး ပေါ်လာပါက အဆင်ပြေသော ကိန်းဂဏန်းကို မရွေးပါနှင့်: HTTP ဘောင်ခတ်ခြင်းသည် ပို့ဆောင်မှု ကုဒ်ပြောင်းခြင်းကို ဦးစားပေးပြီး ပေါင်းစပ်မှုကို ဖြစ်နိုင်သော အမှားအဖြစ် သတ်မှတ်သည်။ ထို ခွဲခြမ်းစိတ်ဖြာမှုကို လိုက်နာသော အကောင်အထည်ဖော်မှုထံ ထားခဲ့ပါ။

HTTP ဂိတ်ဝေးမှတစ်ဆင့် FTP URL သည် ၎င်း၏ တိကျသော URLConnection အပြုအမူကို စစ်ဆေးရန် လိုအပ်သည်; JDK တိုင်းတွင် HTTP ခေါင်းစီး ဝင်ရောက်မှုတိုင်း သာမန် HTTP URL ကဲ့သို့ ပြုမူမည်ဟု အာမမခံနိုင်ပါ။ မက်တာဒေတာ အရေးကြီးသောနေရာတွင် ရှည်သော တန်ဖိုးရှိ length API ကို သုံးပါ၊ ပြီးစီးသော ပစ္စည်းကို အမှန်တကယ် လိုအပ်သော အရှည် သို့မဟုတ် checksum နှင့် အတည်ပြုပါ။ ကိုယ်ထည်ကို ဖတ်ခြင်းက ယခင်က မရှိခဲ့သော ခေါင်းစီးကို ပေါ်လာစေခြင်း မရှိပါ။