Workarounds for database-saved binary images that cannot be displayed in the Colorbox plugin

Colorbox is a very good picture display plug-in, but recently wanted to use it to display the binary picture saved in the database but found that the problem is not displayed correctly, the display is a number of garbled characters, what is the problem?

So follow the example Baidu a bit, is someone also encountered this problem, but did not propose a solution! It seems that I can only analyze the reason ...

First of all, my development environment: ASP. Mvc+colorbox, the problem is not in MVC is Colorbox.

1. MVC Analysis:

Whether the picture is saved in the database or saved in the catalog file, is nothing more than converting to binary stream return than the browser, so I try to display the picture saved in a directory with Colorbox, enter the test URL: http://localhost:6234//Images/ 010806cjierech73n727j2.jpg, the result is a complete problem! Then through the browser input URL: http://localhost:6234/Mminfor/GetThereImageToView/34251, display saved in the database of the picture, also completely no problem!

Therefore, the problem is not very likely in MVC.

2, Colorbox Analysis:

Why is there no problem directly on the browser, and the plugin Colorbox on the Jqurey shows the problem?

First, from the HTTP response header to analyze it.

The HTTP response headers saved directly under the catalog file are displayed as follows:

server:asp.net Development server/10.0.0.0
date:sun, Sep 07:44:00 GMT
cache-control:public
etag: " 1cfcfef4f346180 "
content-type:image/ JPEG
content-length:155988
connection:close

The HTTP response header that displays the binary picture saved in the database is as follows:

http/1.1 OK
Server:ASP.NET Development server/10.0.0.0
Date:sun, Sep 07:46:03 GMT
x-aspnet-version:4.0.30319
x-aspnetmvc-version:4.0
Content-type:image/jpeg
content-length:155988
Connection:close

In contrast, the difference between the two is a response header identification: ETag. So with the Response.appendheader method to the head logo plus re-test, but still no AH (later Baidu, "ETag" This identity header is used for caching).

Since the response head did not find the problem, then from the sending head analysis it!

Direct display of the HTTP send headers saved under the directory file is as follows:

get http://localhost:6234/Images/ 010806cjierech73n727j2.jpg http/1.1
host:localhost:6234
connection: Keep-alive
accept:image/webp,*/*;q= 0.8
user-agent:mozilla/5.0 (Windows NT 6.1) applewebkit/537.36 (khtml, like Gecko) chrome/37.0.2062.120 safari/537.36
referer:http://localhost:6234/mminfor/editforumdata
ACCEPT-ENCODING:GZIP,DEFLATE,SDCH
accept-language:zh-cn,zh;q=0.8,en;q=0.6,zh-tw;q=0.4

get http://localhost:6234/Mminfor/ getthereimagetoview/34617 http/1.1
host:localhost:6234
connection: Keep-alive
x-requested-with:xmlhttprequest
user-agent:mozilla/5.0 (Windows NT 6.1) applewebkit/537.36 (khtml, like Gecko) chrome/37.0.2062.120 safari/537.36
referer:http://localhost:6234/mminfor/editforumdata
ACCEPT-ENCODING:GZIP,DEFLATE,SDCH

Holy shit! Finally found the problem:

The difference between the original in this send head identification: Accept, since the problem is found, the remaining problem is how to send the head logo Accept into: accept:image/webp,*/*;q=0.8 problem.

Here's a way for me to solve the problem (maybe not a good one, but you can refer to it for a moment):

Change the original URL of the display image: http://localhost:6234/Mminfor/GetThereImageToView/34617 to:

Http://localhost:6234/Mminfor/GetThereImageToView/34617.jpg (of course, you want to display the image format is GIF, PNG, BMP can also be changed to corresponding), as to the server side how to extract the parameter value " 34617 "I'm not going to be able to be a string intercept, a type conversion," he said.

Why add a ". jpg" extension to the URL to change the "Accept" header to: accept:image/webp,*/*;q=0.8? I think it is the browser's intelligence to judge the purpose of the URL is to get the picture, so that the "Accept" the identity header into: accept:image/webp,*/*;q=0.8, so that the image binary data returned Colorbox know by the picture instead of the character display.

From another point of view, this is a colorbox to improve, because it is not as smart as a browser, can be returned by the binary stream (file header) to determine whether the display picture or character.

Workarounds for database-saved binary images that cannot be displayed in the Colorbox plugin