2011-02-02 4 views
3

У меня есть куча изображений из десятка источников, и я загружаю их в фоновый поток. Большинство изображений загружаются без проблем, но есть 2 источника, которые вызывают проблемы. Все изображения с них не загружаются.InputStream.bytesRemaining меньше, чем должно быть

Я использую следующий код для загрузки (и сохранить) изображения:

File f=new File(cacheDir, urlHash); 
Bitmap bitmap=null; 
InputStream is=new URL(url).openStream(); 
OutputStream os = new FileOutputStream(f); 
Utils.CopyStream(is, os); 
os.close(); 
bitmap = BitmapFactory.decodeStream(new FileInputStream(f), null, null); 

Utils.CopyStream:

public static void CopyStream(InputStream is, OutputStream os) 
{ 
    int counter = 0; 
    final int buffer_size=1024; 
    try 
    { 
     byte[] bytes=new byte[buffer_size]; 
     for(;;) 
     { 
      int count=is.read(bytes, 0, buffer_size); 
      if(count==-1) { 
       Log.d("tag", counter + " bytes copied"); 
       break; 
      } 
      os.write(bytes, 0, count); 
      counter += count; 
     } 
    } 
    catch(Exception ex) { 
     ex.printStackTrace(); 
    } 
} 

, когда я пытаюсь скачать этот файл http://www.zapakatel.cz/static/deal/7193-1057b.jpg, чем выходит из строя. BitmapFactory.decodeStream возвращает NULL. Все, что я мог узнать об этом, может вызвать проблему: is.bytesRemaining не хватает нескольких тысяч байтов: 162721 против 179845 в соответствии с загруженным размером файла. Когда я вручную загружаю изображение с этого URL-адреса и загружаю его в другое место, все работает отлично.

Любая идея, что может вызвать проблемы? Возможно ли, что сервер, размещающий этот образ, сокращает меня до завершения загрузки? Эта загрузка изображения прекрасна на любом ПК и даже в моем приложении iphone (я знаю, что это совершенно другая платформа и что это, вероятно, не важно, я просто нахожу это странным)

+0

Есть ли какая-то особая причина, по которой вы не используете буферизованные потоки? –

+0

Я тоже это пробовал, с такими же результатами – Lope

ответ

6

У меня нет абсолютно никакого опыта работы с Android, но эта проблема, похоже, связана с кодированием GZIP ответа.

Файл, на который вы указали, возвращается с применением кодировки GZIP. 162721 bytes - размер кодированных данных, 179845 - размер после декодирования, вы можете проверить его с помощью любого инспектора HTTP. Похоже, что new URL(url).openStream() не декодирует GZIP-кодированные ответы автоматически.

+1

wow, я понятия не имел, что что-то подобное возможно. Ты был прав. Теперь я chceck, если контент GZIP-кодирован, и если я использую GZIPInputStream. Все работает как прелести ... большое спасибо! – Lope

+1

И это только одна причина НЕ использовать URL.openStream. Он также будет использовать неопределенный (навсегда) тайм-аут - это означает, что если хост не там, он будет сидеть там, ожидая. Для надежной и полной обработки HTTP используется материал HttpClient, в который входит Android. –

Смежные вопросы