2011-10-19 2 views
4

Я нашел очень странное явление в андроиде. Я обнаружил, что при загрузке изображения через 3g вычисляемый впоследствии sha1 отличается от того, что он должен был делать с файлом, который находится на сервере. После дальнейшего исследования я обнаружил, что изображение было фактически уменьшено и перекодировано. Похоже, что мой мобильный оператор (verizon) пытается оптимизировать файлы, которые я загружаю. Вот некоторая статистика для файла original и downloaded.Почему мой мобильный оператор повторно кодирует файл при загрузке?

Мой вопрос: может ли кто-нибудь еще подтвердить, что мобильные сети могут оптимизировать ваш файл, прежде чем он приземлится на ваше устройство? И если это так, есть где-то где-то, так что я могу отключить это.

В моем приложении очень важно знать, что файл sha1 того, что я загрузил, равен тому, что говорит сервер.

Вот article найдено о verizon оптимизации 3g передач.

+0

Добро пожаловать в мир мобильных телефонов ... вы, вероятно, также обнаружите, что использование данных для оптимизированного изображения было заряжено на основе оригинального полноразмерного файла, а не оптимизированного. Они говорят, что только трафик порта 80 получает это лечение, поэтому просто настройте новый порт прослушивания для вашего сервера и перейдите через этот порт.8080, 81 и т. Д. –

+0

Их сеть, их правила, я боюсь ... Не могли бы вы создать все свои изображения с 72dpi? Таким образом, они могут не спуститься? – Eamorr

+0

@ Eamorr Я могу попробовать. Одно из решений, которое для меня работало до сих пор, - это сделать запрос «https» вместо «http». – Pzanno

ответ

0

Вы не сказали, но предположим, что это HTTP-соединение.

Короче говоря, они делают это для экономии полосы пропускания. 3G не бесплатно!

Если вы прямо запрашиваете ресурсы (GET), то вы находитесь во власти всех посредников, которые обрабатывают HTTP-запрос (т. Е. Прокси, шлюзы), и вы можете быть уверены, что они могут видеть тип MIME в заголовках, и ведут себя соответственно.

Вы можете попробовать использовать заголовок HTTP Accept в своем запросе и использовать параметр q для «подсказки», чтобы вы имели максимальную точность.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Accept: image/png;q=1 

В q находится в диапазоне от 0 до 1. Вы можете быть в состоянии уйти с более низким значением (чем 1). Пожалуйста, прочитайте связанный раздел для получения более подробной информации.

Вы также можете проверить входящий заголовок Content-Type; он может показать, есть ли «заявленное» изменение качества или даже типа MIME. Это может сказать вам, что он сделал!

Было бы замечательно, если бы «стандарт» выполнил свою работу за вас!

Если это не сработает, и вы уже управляете концом сервера, используйте для него альтернативную текстовую кодировку, такую ​​как Base64, которую посредники не могут «сжать» для вас. SOAP делает это с тех пор!

Если вам действительно нужно обходить сжатие изображений, а Accept не работает, вы должны проксировать эти виды запросов самостоятельно и перекодировать их с помощью типа MIME без изображения в ответе.

Если вы идете по прокси-серверу, вы, возможно, соскользнете со своими образами application/octect-stream, который является типом MIME для «неинтерпретированных байтов». Это позволило бы более или менее передавать данные и, надеюсь, держать посредников «помогая руками» от ваших вещей!

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

  • Нет связанных вопросов^_^