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 ແມ່ນການດາວໂຫຼດທີ່ລົ້ມເຫຼວ ບໍ່ແມ່ນການສຳເລັດດ້ວຍບາຍໜ້ອຍກວ່າ.

ປຽບທຽບຄວາມຍາວໃນຊັ້ນດຽວກັນ. ການເຂົ້າລະຫັດ chunked ຂອງ HTTP/1.1 ສາມາດແທນ Content-Length ແລະ ຖືກຖອດລະຫັດໂດຍການຈັດຕັ້ງ HTTP. ພຣັອກຊີອາດຈັດກອບຄືນໃໝ່. ການຖອດບີບອັດກໍອາດເຮັດໃຫ້ຈຳນວນບາຍທີ່ຖອດລະຫັດຂອງແອັບຯແຕກຕ່າງຈາກ Content-Length ທີ່ເຂົ້າລະຫັດ.

ຖ້າທັງ Transfer-Encoding ແລະ Content-Length ປະກົດຂຶ້ນ, ຢ່າເລືອກຕົວເລກທີ່ສະດວກ: ການຈັດກອບ HTTP ໃຫ້ບຸລິມະສິດແກ່ການເຂົ້າລະຫັດການສົ່ງ ແລະ ຖືວ່າການລວມກັນນັ້ນເປັນຄວາມຜິດພາດທີ່ເປັນໄປໄດ້. ປ່ອຍການແຍກວິເຄາະນັ້ນໃຫ້ການຈັດຕັ້ງທີ່ສອດຄ່ອງ.

URL FTP ຜ່ານເກດເວ HTTP ຕ້ອງການກວດສອບພຶດຕິກຳ URLConnection ທີ່ເປັນຮູບປະທຳຂອງມັນ; ມັນບໍ່ຮັບປະກັນວ່າການເຂົ້າເຖິງຫົວຂໍ້ HTTP ທຸກອັນຈະປະຕິບັດຄືກັບ URL HTTP ປົກກະຕິໃນທຸກ JDK. ໃຊ້ length API ທີ່ມີຄ່າຍາວ ໃນຈຸດທີ່ເມຕາດາຕາສຳຄັນ, ແລະ ກວດສອບສິ່ງທີ່ສຳເລັດແລ້ວທຽບກັບຄວາມຍາວ ຫຼື checksum ທີ່ຕ້ອງການຕົວຈິງ. ການອ່ານຕົວເນື້ອບໍ່ເຮັດໃຫ້ຫົວຂໍ້ທີ່ເຄີຍຂາດຫາຍປະກົດຂຶ້ນ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ