Основа 64 кодирует по сравнению с загрузкой файла изображения
Для JPA 2.2 вам необходимо использовать:
compile("javax.persistence:javax.persistence-api:2.2")
, поскольку mvnrepository.com говорит:
Примечание. Этот артефакт был перемещено в:
javax.persistence »javax.persistence-api» $ {jpa-api.version}
blockquote>JPA 2 - 2.1 по-прежнему доступны в разделе «org.hibernate. javax.persistence».
6 ответов
Well I don't agree with anyone of you. There are cases when you've to load more and more images. Not all the pages contain 3 images at all. Actually I'm working on a site where you've to load more than 200 images. What happens when 100000 users request that 200 images on a very loaded site. The disks of the server, returning the images should collapse. Even worse you've to make so much request to the server instead of one with base64. For so much thumbnails I'd prefer the base64 representation, pre-saved in the database. I found the solution and a strong argumentation at http://www.stoimen.com/2009/04/23/when-you-should-use-base64-for-images/. The guy is really in that case and made some tests. I was impressed and make my tests as well. The reality is like it says. For so much images loaded in one page the one response from the server is really helpful.
- кодирование Base64 делает файл больше и поэтому медленнее для передачи.
- включением изображения на странице, это должно быть загружено каждый раз. Внешние изображения обычно только загружаются однажды и затем кэшируются браузером.
- Это не совместимо со всеми браузерами
Почему повторно создают изображение снова и снова, если оно не будет изменено. Гипотетически, даже если существует 1000 различные возможные изображения, которые покажут на основе 1 000 различных условий, я все еще думаю, что 1 000 изображений на дисках лучше. Помните, находящиеся на диске изображения могут кэшироваться браузером и сохранить пропускную способность и т.д. и т.д.
Не думайте data:// работы в IE7 или ниже.
, Когда изображение требуют, Вы могли сохранить его к файловой системе, затем служат этому с тех пор. Если данные изображения в изменениях базы данных затем просто удаляют файл. Служите ему от другого домена также как img.domain.com. Можно извлечь всю пользу из измененных в последний раз или завершающие теги бесплатно от веб-сервера, не имея необходимость запускать PHP, если Вам не нужно также.
, Если Вы используете апача:
# If the file doesn't exist:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/(image123).jpg$ makeimage.php?image=$1
Обычно использование base64 кодирование собирается увеличить размер байта приблизительно 1/3. Из-за этого Вы оказываетесь перед необходимостью перемещать 1/3 байта от базы данных в сервер и затем перемещать дополнительных те же 1/3 байта по проводу к браузеру.
, Конечно, когда размер изображения растет, упомянутые издержки увеличатся пропорционально.
Однако я думаю, что это - хорошая идея изменить файлы в их представления байта в дб и передать их.
Если Вы хотите самую быструю скорость, то необходимо записать им в диск, когда они загружаются/изменяются и позволяют веб-серверу служить статическим файлам. Предложения Rojoca хороши также, так как они минимизируют вызов php. Дополнительная выгода обслуживания от другого домена (большинство), браузеры выпустят запросы параллельно.
Запрет всего этого, когда Вы запрашиваете для данных, проверка, если это было в последний раз изменено, затем запиши это в диск и подачу оттуда. Вы захотите удостовериться, что Вы уважаете заголовок If-Modified-Since, таким образом, Вы не передаете данные напрасно.
, Если бы Вы не можете записать в диск или некоторый другой кэш, затем это было бы самым быстрым, чтобы сохранить его как двоичные данные в базе данных и передать его потоком. Корректировка буферных размеров поможет в той точке.