- 浏览: 462628 次
- 性别:
- 来自: 坚持零分
文章分类
最新评论
-
wzwahl36:
文章非常赞,http://www.atool.org/img2 ...
在浏览器中解析Base64编码图像 -
realyasswl:
ie sucks
IE9 媲美Firebug的强大的程序员开发工具 -
di1984HIT:
不错啊。呵呵。
MS的一些小工具 -
NothingCanBeDone:
楼主,你这Project,能放出来了,感激不尽。
[Ray Linn]用Visual Studio 2008开发IE BHO(浏览器帮助对象) 之三 -
烬难烬:
这就没了???我去....
IE9 媲美Firebug的强大的程序员开发工具
原文发表在:blogs.ejb.cc 作者: Ray_Linn
上一篇介绍中,我们将二进制文件(BLOB)保存为Base64编码的文本,这些文本可以内嵌在XML的标签中,因此二进制信息它可以随着XML文件被拷贝、下载而不用担心信息会缺失。这项技术也在email邮件中被广泛使用。
浏览器对Base64的支持
图像是最经常被使用的一种二进制文件。而现代的浏览器的进步日新月异,IE7,FireFox和其他浏览器为包括Base64在内各种编码的图像信息提供了很好的支持。因此图形信息可以以下面的形式呈现在页面中、
这种data: URI的格式能把Base64(或其他数据)可以内嵌在image标签的属性当中(或者CSS中)。我们可以看到在大部分浏览器中的显示效果:
这种做法有利有弊,好处是浏览器可以在一个连接中得到完成的页面内容,不好的地方时图像的大小会增加1/3。因此,这种内嵌的方法适合对小的图形元素比如图标、圆角等等进行处理,从而减少浏览器打开的连接数,但对大的照片、图片(量少而大)等等则不应该使用Base64编码以免影响下载速度。
为了得到刚才的Base64编码,我们将上一篇的Java修改成Struts Action,并借用了JIMI进行图形的读取和格式转换,Base64编码器则改为更普遍的Apache Commons组件,代码如下:
对应的View端是个十分简单的Freemarker模板:
处理古代浏览器
世界总是不是那么完美,尽管大部分现代浏览器对Base64的处理都十分完善,但是我们不能不考虑到一些“古老”的浏览器,而现在还是普遍使用的“古老”的浏览器,就当属IE6,在IE6里试图浏览上面的图片可能会得到一个红叉叉。我们不得不为IE6做一些特殊处理,利用下面的javascript,我们把Base64字串传回服务器端,重新解析成图片
服务器端的Struts可以参考上面的例子做反向操作,具体从略。
更完美的方法
将Base64传回服务器解码是不错的IE6补丁,但是违背了我们的初衷,对IE6来说,浏览器连接数并未有任何减少。更直接的想法,是否能用Javascript直接在浏览器中,对Base64文本进行解码呢?我们构思的场景如下:服务器端先将图片转换成PNG格式以方便客户端进行处理,Base64编码之后,利用JSON将文本传递给浏览器客户端进行处理。
我们选择PNG图形格式是因为PNG已经俨然成为新的Web图形标准,它格式非常简单,可以很方便的用javascript进行处理而不需要借助浏览器的支持。我们知道javascript直接不能处理二进制数据,但是现在这不是个问题,服务器端已经准备好了Base64编码的文本数据,现在我们只需要一个javascript的Base64解析器,你可以在这里找到一个notmasteryet的Base64解析器。
现在PNG图形格式采用了DEFLATE作为唯一的压缩算法,该算法也广泛应用在ZIP,GZIP等压缩格式中。PNG图像格式文件(或者称为数据流)由一个8字节的PNG文件署名(PNG file signature)域和按照特定结构组织的3个以上的数据块(chunk)组成。
PNG定义了两种类型的数据块,一种是称为关键数据块(critical chunk),这是标准的数据块,另一种叫做辅助数据块(ancillary chunks),这是可选的数据块。关键数据块定义了4个标准数据块,其中图像数据块IDAT(image data chunk):它存储实际的数据, PNG总的数据流采用DEFLAT进行压缩。此外还擦用三角过滤“delta filters”来过滤每一行的像素的未压缩数据。DEFLAT和delta压缩在其他数据和文本处理中也被广泛应用。PNG格式你可以参考<a href="http://www.libpng.org/pub/png/spec/1.1/PNG-Contents.html">官方文档</a>。
很棒的,notmasteryet也为我们提供了一个DEFLAT解压器。
最后,我们把这些组合起来:
相关的javascript请到blogs.ejb.cc下载。
还可以更完美
回顾上一篇的例子,我们用了ihard.net提供了Base64编码,它提供一个GZIP编码参数,你可以发现如此编码之后的文本大小和原来的图形大小相差无几。利用上一节提供了javascript是不是可以解决Base64编码后文件大小增加的问题?留着思考吧。
url的话,ie6 2083的长度限制
我写过data协议的ie下activex的处理,,ie啊,哎
所有是uri的地方(src/href/cite等屬性),都可以用data協議。
data協議支持base64編碼方式,但如果不是二進制數據,通常沒有必要用base64。
比如:
data:,Hello world
data:text/html,<script>alert('Hello world')</script>
gzip之后,size基本不变,而连接数在任何情况下都不会增加,缓存照样生效。
gzip整个网页是个动态过程,而gzip某个image可以是个静态过程,一次完成,永远生效。
just forgot it, 这种辩论可以互相学习。
其实这还有另一种思路也有很意思,即javascript重新构造Base64串来实现客户端的绘图 --- 一般用于绘制一些简单的数学图形,比如sin(x)
1. image io部署在文本状态下至少需要设置java.awt.headless。http://zhoumin.iteye.com/blog/152810
2。headless mode依赖于x-library (我从头到尾没有提x-service,请自行区别)。如果服务器不部署libx,那image io就可能出问题,这些从image io出错的信息就可以看出来。老外的文章也有人提到,在没有x-server的linux遇到同样的问题。
3。我需要一个自行完备的安装包,不依赖于任何外部环境的修改,原因许多提供服务空间的的供应商,根本不会帮你敲export CLASSPATH=....等等任何命令,这是out of service scope的东西,而且会影响到其他客人。每个项目应该是像php一样,拷贝上服务器,运行自己的setup后就可以独立运行。需要设置任何系统的命令都是bad的。
4。Jimi是过时的,但是不等于说它不工作了,实际上它还是一样好用,甚至据说效率还优于image io。有它就足够了,既然image io有潜在风险,那规避风险才是明智的。
1. ImageI/O依赖于X libraries,作为未可知的部署(购买服务器空间),供应商的服务器未必有安装x-service,部署Image I/O可能会导致严重错误。这个问题可以参考:http://java.itags.org/java-tech/43197/。而Jimi是pure java的。另外用Jimi也不是杀鸡用牛刀,Image I/O是基于Jimi的再发展(Jimi已经被废弃了)。作为开发者,选择库要考虑部署的方方面面。
2.3 这些代码是直接从我的ImageBase64Encoder中合并到Action里的。作为文章的示例,考虑到读者的方便理解(这个读者也包括我自己)我个人风格都是尽量把文章示例写的简单大路,能用一个类的,决不要二个类,能用不太长的面条代码说明的,决不写成OO。决不要当成Best Pratices.
上一篇介绍中,我们将二进制文件(BLOB)保存为Base64编码的文本,这些文本可以内嵌在XML的标签中,因此二进制信息它可以随着XML文件被拷贝、下载而不用担心信息会缺失。这项技术也在email邮件中被广泛使用。
浏览器对Base64的支持
图像是最经常被使用的一种二进制文件。而现代的浏览器的进步日新月异,IE7,FireFox和其他浏览器为包括Base64在内各种编码的图像信息提供了很好的支持。因此图形信息可以以下面的形式呈现在页面中、
<img src="data:image/gif;base64,R0lGODlhDwAPAKECAAAAzMzM///// wAAACwAAAAADwAPAAACIISPeQHsrZ5ModrLlN48CXF8m2iQ3YmmKqVlRtW4ML wWACH+H09wdGltaXplZCBieSBVbGVhZCBTbWFydFNhdmVyIQAAOw==" alt="Base64 encoded image" width="150" height="150"/>
这种data: URI的格式能把Base64(或其他数据)可以内嵌在image标签的属性当中(或者CSS中)。我们可以看到在大部分浏览器中的显示效果:
这种做法有利有弊,好处是浏览器可以在一个连接中得到完成的页面内容,不好的地方时图像的大小会增加1/3。因此,这种内嵌的方法适合对小的图形元素比如图标、圆角等等进行处理,从而减少浏览器打开的连接数,但对大的照片、图片(量少而大)等等则不应该使用Base64编码以免影响下载速度。
为了得到刚才的Base64编码,我们将上一篇的Java修改成Struts Action,并借用了JIMI进行图形的读取和格式转换,Base64编码器则改为更普遍的Apache Commons组件,代码如下:
public class Base64ImageAction extends ActionSupport { private final static String galleryName = "gallery"; private static String parent = null; private String encodeString = null; public String getEncodeString() { return encodeString; } public void setEncodeString(String encodeString) { this.encodeString = encodeString; } private String getImageFullPath() { parent = new File(this.getClass().getClassLoader().getResource( File.separator).getPath()).getParent()+File.separator+"flag.jpg"; } public String execute() { ByteArrayOutputStream output = new ByteArrayOutputStream(); try { JimiReader reader = Jimi.createJimiReader(this.getImageFullPath()); Image image = reader.getImage(); Jimi.putImage("image/png", image, output); output.flush(); output.close(); this.encodeString = Base64.encodeBase64String(output.toByteArray()); } catch (IOException e) { e.printStackTrace(); } catch (JimiException e) { e.printStackTrace(); } return SUCCESS; } }
对应的View端是个十分简单的Freemarker模板:
<html> <head> <title>Hello,World</title> </head> <body> <img src="data:image/png;base64,${encodeString}" /> </body> </html>
处理古代浏览器
世界总是不是那么完美,尽管大部分现代浏览器对Base64的处理都十分完善,但是我们不能不考虑到一些“古老”的浏览器,而现在还是普遍使用的“古老”的浏览器,就当属IE6,在IE6里试图浏览上面的图片可能会得到一个红叉叉。我们不得不为IE6做一些特殊处理,利用下面的javascript,我们把Base64字串传回服务器端,重新解析成图片
// a regular expression to test for Base64 data var BASE64_DATA = /^data:.*;base64/i; // path to the PHP module that will decode the encoded data var base64Path = "/my/path/base64.php"; function fixBase64(img) { // check the image source if (BASE64_DATA.test(img.src)) { // pass the data to the PHP routine img.src = base64Path + "?" + img.src.slice(5); } }; // fix images on page load onload = function() { for (var i = 0; i < document.images.length; i++) { fixBase64(document.images[i]); } };
服务器端的Struts可以参考上面的例子做反向操作,具体从略。
更完美的方法
将Base64传回服务器解码是不错的IE6补丁,但是违背了我们的初衷,对IE6来说,浏览器连接数并未有任何减少。更直接的想法,是否能用Javascript直接在浏览器中,对Base64文本进行解码呢?我们构思的场景如下:服务器端先将图片转换成PNG格式以方便客户端进行处理,Base64编码之后,利用JSON将文本传递给浏览器客户端进行处理。
我们选择PNG图形格式是因为PNG已经俨然成为新的Web图形标准,它格式非常简单,可以很方便的用javascript进行处理而不需要借助浏览器的支持。我们知道javascript直接不能处理二进制数据,但是现在这不是个问题,服务器端已经准备好了Base64编码的文本数据,现在我们只需要一个javascript的Base64解析器,你可以在这里找到一个notmasteryet的Base64解析器。
现在PNG图形格式采用了DEFLATE作为唯一的压缩算法,该算法也广泛应用在ZIP,GZIP等压缩格式中。PNG图像格式文件(或者称为数据流)由一个8字节的PNG文件署名(PNG file signature)域和按照特定结构组织的3个以上的数据块(chunk)组成。
PNG定义了两种类型的数据块,一种是称为关键数据块(critical chunk),这是标准的数据块,另一种叫做辅助数据块(ancillary chunks),这是可选的数据块。关键数据块定义了4个标准数据块,其中图像数据块IDAT(image data chunk):它存储实际的数据, PNG总的数据流采用DEFLAT进行压缩。此外还擦用三角过滤“delta filters”来过滤每一行的像素的未压缩数据。DEFLAT和delta压缩在其他数据和文本处理中也被广泛应用。PNG格式你可以参考<a href="http://www.libpng.org/pub/png/spec/1.1/PNG-Contents.html">官方文档</a>。
很棒的,notmasteryet也为我们提供了一个DEFLAT解压器。
最后,我们把这些组合起来:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Demo JavaScript PNG Viewer</title> </head> <body onload="show(gravatar);"> <script src="../Source/Base64.js" type="text/javascript"></script> <script src="../Source/Deflate.js" type="text/javascript"></script> <script src="../Source/PNG.js" type="text/javascript"></script> <script type="text/javascript"> var gravatar = 'iVBORw0KGgoAAAANSUhEUgAAA.......数据从略......55CYII='; String.prototype.padRight = function(c, n){ var txt = ''; for(var i=0;i<n-this.length;i++) txt += c; return txt + this; }; function show(data){ var png = new PNG(data); var img = document.getElementById('image'), limg = document.getElementById('largeimage'); document.getElementById('nativeimage').src = 'data:image/png;base64,' + data; img.innerHTML = ''; limg.innerHTML = ''; img.style.width = png.width + 'px'; img.style.height = png.height + 'px'; limg.style.width = (png.width * 3) + 'px'; limg.style.width = (png.height * 3) + 'px'; var line; while(line = png.readLine()) { for (var x = 0; x < line.length; x++){ var px = document.createElement('div'), px2 = document.createElement('div'); px.className = px2.className = 'pixel'; px.style.backgroundColor = px2.style.backgroundColor = '#' + line[x].toString(16).padRight('0', 6); img.appendChild(px); limg.appendChild(px2); } } } </script> <div id="image"></div> <div id="largeimage"></div> <img id="nativeimage" /> </body> </html>
相关的javascript请到blogs.ejb.cc下载。
还可以更完美
回顾上一篇的例子,我们用了ihard.net提供了Base64编码,它提供一个GZIP编码参数,你可以发现如此编码之后的文本大小和原来的图形大小相差无几。利用上一节提供了javascript是不是可以解决Base64编码后文件大小增加的问题?留着思考吧。
评论
23 楼
wzwahl36
2015-01-13
22 楼
kimmking
2010-10-28
hax 写道
我个人认为对于老浏览器还是转换为 http://example.com/data:image/png;base64,...... 比较好。返回的response可以设为永久不过期的缓存。反正它的内容只依赖于path,永远不会变。
url的话,ie6 2083的长度限制
我写过data协议的ie下activex的处理,,ie啊,哎
21 楼
hax
2010-10-28
butnet 写道
其它有src的标签也可以用base64吗?
所有是uri的地方(src/href/cite等屬性),都可以用data協議。
data協議支持base64編碼方式,但如果不是二進制數據,通常沒有必要用base64。
比如:
data:,Hello world
data:text/html,<script>alert('Hello world')</script>
20 楼
butnet
2010-10-26
其它有src的标签也可以用base64吗?
19 楼
elgs
2010-10-25
Great article, thank you!
18 楼
cloudgamer
2010-10-25
兼容是一个大问题
div拼图片太不实用感觉还不如用服务器生成的方法
div拼图片太不实用感觉还不如用服务器生成的方法
17 楼
hax
2010-10-25
我个人认为对于老浏览器还是转换为 http://example.com/data:image/png;base64,...... 比较好。返回的response可以设为永久不过期的缓存。反正它的内容只依赖于path,永远不会变。
16 楼
ray_linn
2010-10-25
night_stalker 写道
Rails 里可以写个 helper :
页面用起来就像这样:
但是,传输的数据量变大了不止 1/3,因为静态资源完全可以返回 304 让浏览器读缓存的 …… 绝大部分图片——就算很小——都会得不偿失吧 ……
另外不是总能减少打开的连接数的,现在浏览器请求网页很多都是 keep-alive 重用同一连接的 ……
再另外,对一个 img 元素进行 gzip 压缩真的有意义么 …… 还不如 gzip 整个网页 ……
require 'base64' Cache = Dir.glob("#{RAILS_ROOT}/public/img/small/*.gif").inject({}){|c, f| data = Base64.encode64 File.binread f key = File.basename f c[key] = %Q[<img src="data:image/gif;base64,#{data}"></img>] c } def base64img name Cache[name] end
页面用起来就像这样:
<%= base64img 'abc.gif' %>
但是,传输的数据量变大了不止 1/3,因为静态资源完全可以返回 304 让浏览器读缓存的 …… 绝大部分图片——就算很小——都会得不偿失吧 ……
另外不是总能减少打开的连接数的,现在浏览器请求网页很多都是 keep-alive 重用同一连接的 ……
再另外,对一个 img 元素进行 gzip 压缩真的有意义么 …… 还不如 gzip 整个网页 ……
gzip之后,size基本不变,而连接数在任何情况下都不会增加,缓存照样生效。
gzip整个网页是个动态过程,而gzip某个image可以是个静态过程,一次完成,永远生效。
15 楼
hax
2010-10-24
楼上。你的data协议的base64编码的图片也可以写在css里,css一样享受304。经过简单的gzip压缩之后,传输的数据量大不了多少。
keep-alive虽然有用,但是仍然多一些request/response的过程,而且是线性的。
不过用js解码和再造图片确实不靠谱,那只是老外做的有趣的研究性项目。
keep-alive虽然有用,但是仍然多一些request/response的过程,而且是线性的。
不过用js解码和再造图片确实不靠谱,那只是老外做的有趣的研究性项目。
14 楼
night_stalker
2010-10-22
Rails 里可以写个 helper :
页面用起来就像这样:
但是,传输的数据量变大了不止 1/3,因为静态资源完全可以返回 304 让浏览器读缓存的 …… 绝大部分图片——就算很小——都会得不偿失吧 ……
另外不是总能减少打开的连接数的,现在浏览器请求网页很多都是 keep-alive 重用同一连接的 ……
再另外,对一个 img 元素进行 gzip 压缩真的有意义么 …… 还不如 gzip 整个网页 ……
require 'base64' Cache = Dir.glob("#{RAILS_ROOT}/public/img/small/*.gif").inject({}){|c, f| data = Base64.encode64 File.binread f key = File.basename f c[key] = %Q[<img src="data:image/gif;base64,#{data}"></img>] c } def base64img name Cache[name] end
页面用起来就像这样:
<%= base64img 'abc.gif' %>
但是,传输的数据量变大了不止 1/3,因为静态资源完全可以返回 304 让浏览器读缓存的 …… 绝大部分图片——就算很小——都会得不偿失吧 ……
另外不是总能减少打开的连接数的,现在浏览器请求网页很多都是 keep-alive 重用同一连接的 ……
再另外,对一个 img 元素进行 gzip 压缩真的有意义么 …… 还不如 gzip 整个网页 ……
13 楼
ray_linn
2010-10-22
fch415 写道
Sorry,你说的是对的,我查了我们的服务器确实安装有X11,所以使用ImageIO正常。
另外查到SUN官方文档说明:
Headless mode support has been available since the J2SE 1.4 platform.
Headless mode从J2SE1.4才开始支持。
所以JIMI(since 1.1)不受此模式影响。
另外查到SUN官方文档说明:
Headless mode support has been available since the J2SE 1.4 platform.
Headless mode从J2SE1.4才开始支持。
所以JIMI(since 1.1)不受此模式影响。
just forgot it, 这种辩论可以互相学习。
12 楼
ray_linn
2010-10-22
form_rr 写道
不错。用JS解决Base64的问题。小图片,少量颜色下。用div来绘图也是可以接受的。
而且,这种方法特别适合最导出。
日后还可以把Mp3,Mp4也进行base64编码。嘿嘿!
而且,这种方法特别适合最导出。
日后还可以把Mp3,Mp4也进行base64编码。嘿嘿!
其实这还有另一种思路也有很意思,即javascript重新构造Base64串来实现客户端的绘图 --- 一般用于绘制一些简单的数学图形,比如sin(x)
11 楼
cloudgamer
2010-10-22
这东西不错
我也利用过base64做图片预览效果
我也利用过base64做图片预览效果
10 楼
form_rr
2010-10-22
不错。用JS解决Base64的问题。小图片,少量颜色下。用div来绘图也是可以接受的。
而且,这种方法特别适合最导出。
日后还可以把Mp3,Mp4也进行base64编码。嘿嘿!
而且,这种方法特别适合最导出。
日后还可以把Mp3,Mp4也进行base64编码。嘿嘿!
9 楼
fch415
2010-10-22
Sorry,你说的是对的,我查了我们的服务器确实安装有X11,所以使用ImageIO正常。
另外查到SUN官方文档说明:
Headless mode support has been available since the J2SE 1.4 platform.
Headless mode从J2SE1.4才开始支持。
所以JIMI(since 1.1)不受此模式影响。
另外查到SUN官方文档说明:
Headless mode support has been available since the J2SE 1.4 platform.
Headless mode从J2SE1.4才开始支持。
所以JIMI(since 1.1)不受此模式影响。
8 楼
ray_linn
2010-10-22
打印出jai image io错误的信息,一堆堆的libx,你在windows怎么玩都没问题,windows的gdi是不可去除的,但linux的libx则是另一回事了。
X11R6就是Image IO所要依赖的底层C++库
Dynamic libraries: 08048000-08056000 r-xp 00000000 08:03 1159188 /usr/java/j2sdk1.4.2_08/bin/java 08056000-08059000 rwxp 0000d000 08:03 1159188 /usr/java/j2sdk1.4.2_08/bin/java 2a6da000-2a6e9000 r-xp 00000000 08:03 1729982 /lib/libresolv-2.3.3.so 2a6e9000-2a6ea000 ---p 0000f000 08:03 1729982 /lib/libresolv-2.3.3.so 2a6ea000-2a6eb000 r-xp 0000f000 08:03 1729982 /lib/libresolv-2.3.3.so 2a6eb000-2a6ec000 rwxp 00010000 08:03 1729982 /lib/libresolv-2.3.3.so 2a6ee000-2a6f2000 r-xp 00000000 08:03 1729967 /lib/libnss_dns-2.3.3.so 2a6f2000-2a6f3000 r-xp 00003000 08:03 1729967 /lib/libnss_dns-2.3.3.so 2a6f3000-2a6f4000 rwxp 00004000 08:03 1729967 /lib/libnss_dns-2.3.3.so 2ad4a000-2ad5f000 r-xp 00000000 08:03 919025 /usr/X11R6/lib/libICE.so.6.3 2ad5f000-2ad60000 rwxp 00014000 08:03 919025 /usr/X11R6/lib/libICE.so.6.3 2ad62000-2ad69000 r-xp 00000000 08:03 919029 /usr/X11R6/lib/libSM.so.6.0 2ad69000-2ad6a000 rwxp 00007000 08:03 919029 /usr/X11R6/lib/libSM.so.6.0 2ad6a000-2ae2d000 r-xp 00000000 08:03 919031 /usr/X11R6/lib/libX11.so.6.2 2ae2d000-2ae31000 rwxp 000c3000 08:03 919031 /usr/X11R6/lib/libX11.so.6.2 2ae31000-2ae35000 r-xp 00000000 08:03 919077 /usr/X11R6/lib/libXtst.so.6.1 2ae35000-2ae36000 rwxp 00003000 08:03 919077 /usr/X11R6/lib/libXtst.so.6.1 2ae36000-2ae43000 r-xp 00000000 08:03 919049 /usr/X11R6/lib/libXext.so.6.4 2ae43000-2ae44000 rwxp 0000c000 08:03 919049 /usr/X11R6/lib/libXext.so.6.4 2ae44000-2ae90000 r-xp 00000000 08:03 919075 /usr/X11R6/lib/libXt.so.6.0 2ae90000-2ae93000 rwxp 0004b000 08:03 919075 /usr/X11R6/lib/libXt.so.6.0 2ae94000-2ae9b000 r-xp 00000000 08:03 923122 /usr/X11R6/lib/libXp.so.6.2 2ae9b000-2ae9c000 rwxp 00006000 08:03 923122 /usr/X11R6/lib/libXp.so.6.2 2aea8000-2aefb000 r-xp 00000000 08:03 1160360 /usr/java/j2sdk1.4.2_08/jre/lib/i386/libmlib_image.so 2aefb000-2aefc000 rwxp 00052000 08:03 1160360 /usr/java/j2sdk1.4.2_08/jre/lib/i386/libmlib_image.so 2aefc000-2b1cd000 r-xp 00000000 08:03 1160343 /usr/java/j2sdk1.4.2_08/jre/lib/i386/libawt.so 2b1cd000-2b1e3000 rwxp 002d0000 08:03 1160343 /usr/java/j2sdk1.4.2_08/jre/lib/i386/libawt.so 2b978000-2b97e000 r-xs 00000000 08:03 946769 /usr/lib/gconv/gconv-modules.cache
X11R6就是Image IO所要依赖的底层C++库
7 楼
ray_linn
2010-10-22
fch415 写道
1、”ImageI/O依赖于X libraries“
哪里得来的结论,从你发的老外这篇帖子(http://java.itags.org/java-tech/43197/)上?
这篇我从头细看了一遍:没人说过安装了X-server后该问题就解决了。
2、怎样解决在linux下使用SUN的Image I/O(简称SIIO)报出ClassNotFound的问题.
因为SIIO的代码在rt.jar(JDK自带),故在linux下配置一下ClassPath即可:
export CLASSPATH=$JAVA_HOME/jre/lib/rt.jar
3、”而Jimi是pure java“
SIIO就不是啦?SIIO可以看做是Image I/O(JDK2以后的图形接口)的SUN实现,仅支持5种图形格式而(jpg\png\gif\bmp\wbmp)
何须用过时的JIMI且还需下载安装额外的jar。你可能没用过SIIO,而把SIIO误认为了JAI-Image/IO了吧?
4、我用过以下这些Java图形包,在读取PNG时都不需要额外的C++库支持:
(JDK)JIMI
(JDK)SUN-ImageIO
(SUN)JAI
(SUN)JAI-ImageIO
(Apache)FOP
(Apache)sanselan
(3rd)iText。
哪里得来的结论,从你发的老外这篇帖子(http://java.itags.org/java-tech/43197/)上?
这篇我从头细看了一遍:没人说过安装了X-server后该问题就解决了。
2、怎样解决在linux下使用SUN的Image I/O(简称SIIO)报出ClassNotFound的问题.
因为SIIO的代码在rt.jar(JDK自带),故在linux下配置一下ClassPath即可:
export CLASSPATH=$JAVA_HOME/jre/lib/rt.jar
3、”而Jimi是pure java“
SIIO就不是啦?SIIO可以看做是Image I/O(JDK2以后的图形接口)的SUN实现,仅支持5种图形格式而(jpg\png\gif\bmp\wbmp)
何须用过时的JIMI且还需下载安装额外的jar。你可能没用过SIIO,而把SIIO误认为了JAI-Image/IO了吧?
4、我用过以下这些Java图形包,在读取PNG时都不需要额外的C++库支持:
(JDK)JIMI
(JDK)SUN-ImageIO
(SUN)JAI
(SUN)JAI-ImageIO
(Apache)FOP
(Apache)sanselan
(3rd)iText。
1. image io部署在文本状态下至少需要设置java.awt.headless。http://zhoumin.iteye.com/blog/152810
2。headless mode依赖于x-library (我从头到尾没有提x-service,请自行区别)。如果服务器不部署libx,那image io就可能出问题,这些从image io出错的信息就可以看出来。老外的文章也有人提到,在没有x-server的linux遇到同样的问题。
3。我需要一个自行完备的安装包,不依赖于任何外部环境的修改,原因许多提供服务空间的的供应商,根本不会帮你敲export CLASSPATH=....等等任何命令,这是out of service scope的东西,而且会影响到其他客人。每个项目应该是像php一样,拷贝上服务器,运行自己的setup后就可以独立运行。需要设置任何系统的命令都是bad的。
4。Jimi是过时的,但是不等于说它不工作了,实际上它还是一样好用,甚至据说效率还优于image io。有它就足够了,既然image io有潜在风险,那规避风险才是明智的。
6 楼
fch415
2010-10-22
1、”ImageI/O依赖于X libraries“
哪里得来的结论,从你发的老外这篇帖子(http://java.itags.org/java-tech/43197/)上?
这篇我从头细看了一遍:没人说过安装了X-server后该问题就解决了。
2、怎样解决在linux下使用SUN的Image I/O(简称SIIO)报出ClassNotFound的问题.
因为SIIO的代码在rt.jar(JDK自带),故在linux下配置一下ClassPath即可:
export CLASSPATH=$JAVA_HOME/jre/lib/rt.jar
3、”而Jimi是pure java“
SIIO就不是啦?SIIO可以看做是Image I/O(JDK2以后的图形接口)的SUN实现,仅支持5种图形格式而(jpg\png\gif\bmp\wbmp)
何须用过时的JIMI且还需下载安装额外的jar。你可能没用过SIIO,而把SIIO误认为了JAI-Image/IO了吧?
4、我用过以下这些Java图形包,在读取PNG时都不需要额外的C++库支持:
(JDK)JIMI
(JDK)SUN-ImageIO
(SUN)JAI
(SUN)JAI-ImageIO
(Apache)FOP
(Apache)sanselan
(3rd)iText。
哪里得来的结论,从你发的老外这篇帖子(http://java.itags.org/java-tech/43197/)上?
这篇我从头细看了一遍:没人说过安装了X-server后该问题就解决了。
2、怎样解决在linux下使用SUN的Image I/O(简称SIIO)报出ClassNotFound的问题.
因为SIIO的代码在rt.jar(JDK自带),故在linux下配置一下ClassPath即可:
export CLASSPATH=$JAVA_HOME/jre/lib/rt.jar
3、”而Jimi是pure java“
SIIO就不是啦?SIIO可以看做是Image I/O(JDK2以后的图形接口)的SUN实现,仅支持5种图形格式而(jpg\png\gif\bmp\wbmp)
何须用过时的JIMI且还需下载安装额外的jar。你可能没用过SIIO,而把SIIO误认为了JAI-Image/IO了吧?
4、我用过以下这些Java图形包,在读取PNG时都不需要额外的C++库支持:
(JDK)JIMI
(JDK)SUN-ImageIO
(SUN)JAI
(SUN)JAI-ImageIO
(Apache)FOP
(Apache)sanselan
(3rd)iText。
5 楼
ray_linn
2010-10-22
fch415 写道
这篇文章很好的解释了什么是dataURI技术细节。
dataURI可以说应用范围是很窄,但在某些场合下却是非常给力的手段。
比如:我们在服务器端只需要存储用户上传的一个产品图片(不需要存储多种大小的缩略图);当用户需要看到各种大小的图片,可以按以下方式来处理(这也是作者最后一段示例代码的用途)
1、服务端将原图编码成Base64格式返回
2、客户端JS将Base64编码的图片文本流解码,读取行列像素信息,在DOM中重新绘制。
To:作者
1、读取一个PNG的文件流用JIMI,直接用JDK中SUN的ImageI/O就足矣:杀鸡何须牛刀?
2、Java代码贴得太多了,这里是JS板块;就算是发在Java板块,你也不必贴那么多Action代码(藏拙为妙)
3、最好不要在Action中直接书写I/O代码,封装成Util一下吧:你应当是有年头的Java开发者了,不需我多说理由了
dataURI可以说应用范围是很窄,但在某些场合下却是非常给力的手段。
比如:我们在服务器端只需要存储用户上传的一个产品图片(不需要存储多种大小的缩略图);当用户需要看到各种大小的图片,可以按以下方式来处理(这也是作者最后一段示例代码的用途)
1、服务端将原图编码成Base64格式返回
2、客户端JS将Base64编码的图片文本流解码,读取行列像素信息,在DOM中重新绘制。
To:作者
1、读取一个PNG的文件流用JIMI,直接用JDK中SUN的ImageI/O就足矣:杀鸡何须牛刀?
2、Java代码贴得太多了,这里是JS板块;就算是发在Java板块,你也不必贴那么多Action代码(藏拙为妙)
3、最好不要在Action中直接书写I/O代码,封装成Util一下吧:你应当是有年头的Java开发者了,不需我多说理由了
1. ImageI/O依赖于X libraries,作为未可知的部署(购买服务器空间),供应商的服务器未必有安装x-service,部署Image I/O可能会导致严重错误。这个问题可以参考:http://java.itags.org/java-tech/43197/。而Jimi是pure java的。另外用Jimi也不是杀鸡用牛刀,Image I/O是基于Jimi的再发展(Jimi已经被废弃了)。作为开发者,选择库要考虑部署的方方面面。
2.3 这些代码是直接从我的ImageBase64Encoder中合并到Action里的。作为文章的示例,考虑到读者的方便理解(这个读者也包括我自己)我个人风格都是尽量把文章示例写的简单大路,能用一个类的,决不要二个类,能用不太长的面条代码说明的,决不写成OO。决不要当成Best Pratices.
4 楼
fch415
2010-10-22
这篇文章很好的解释了什么是dataURI技术细节。
dataURI可以说应用范围是很窄,但在某些场合下却是非常给力的手段。
比如:我们在服务器端只需要存储用户上传的一个产品图片(不需要存储多种大小的缩略图);当用户需要看到各种大小的图片,可以按以下方式来处理(这也是作者最后一段示例代码的用途)
1、服务端将原图编码成Base64格式返回
2、客户端JS将Base64编码的图片文本流解码,读取行列像素信息,在DOM中重新绘制。
To:作者
1、读取一个PNG的文件流用JIMI,直接用JDK中SUN的ImageI/O就足矣:杀鸡何须牛刀?
2、Java代码贴得太多了,这里是JS板块;就算是发在Java板块,你也不必贴那么多Action代码(藏拙为妙)
3、最好不要在Action中直接书写I/O代码,封装成Util一下吧:你应当是有年头的Java开发者了,不需我多说理由了
dataURI可以说应用范围是很窄,但在某些场合下却是非常给力的手段。
比如:我们在服务器端只需要存储用户上传的一个产品图片(不需要存储多种大小的缩略图);当用户需要看到各种大小的图片,可以按以下方式来处理(这也是作者最后一段示例代码的用途)
1、服务端将原图编码成Base64格式返回
2、客户端JS将Base64编码的图片文本流解码,读取行列像素信息,在DOM中重新绘制。
To:作者
1、读取一个PNG的文件流用JIMI,直接用JDK中SUN的ImageI/O就足矣:杀鸡何须牛刀?
2、Java代码贴得太多了,这里是JS板块;就算是发在Java板块,你也不必贴那么多Action代码(藏拙为妙)
3、最好不要在Action中直接书写I/O代码,封装成Util一下吧:你应当是有年头的Java开发者了,不需我多说理由了
发表评论
-
Sinatra 入门 一
2011-09-15 12:50 9310本系列教程分为四个部 ... -
博客搬迁启事
2010-12-01 16:03 2171鉴于Java最近的停机事件,所以有了把自己的blog搬个家的想 ... -
IE9 媲美Firebug的强大的程序员开发工具
2010-09-17 13:21 12025Javascript的调试,是开发Web应用尤其是AJAX应用 ... -
ASP.NET MVC与RAILS3的比较
2010-07-27 13:26 2518进入后Web年代之后,MVC框架进入了快速演化的时代,Stru ... -
【四】Bing Maps Silverlight 控件 之 扩展
2010-06-10 16:50 1302模式扩展 目前的Bing Maps的Silverlight控件 ... -
【三】Bing Maps Silverlight 控件 之 标注地图
2010-06-08 15:46 3508图钉标签 如果我们需要在Bing Maps中加入一个小图钉标 ... -
【二】Bing Maps Silverlight 控件 之 快速上手
2010-06-08 12:14 2567Hello,Map 最简单的地图应用莫过于只是显地图。这种快 ... -
【一】Bing Maps SilverLight控件 之 准备工作
2010-06-08 12:02 1487开发基于必应地图SilverLight控件的应用需要如下准备工 ... -
【二】ArcGIS Silverlight 客户端 1-2-3
2010-05-12 15:09 2022在ArcGIS API 里已经定义了多种类型的地图层(这里避免 ... -
【一】ArcGIS Silverlight 客户端 1-2-3
2010-05-11 16:12 2048题记 ArcGIS之所以比较 ... -
HTA,XUL技术的鼻祖
2009-06-20 19:49 1899近几年来,XUL方兴未艾,以XAML(WPF),XUL等新技术 ... -
【Ray谈项目管理】项目经理与Scrum Master
2009-06-20 19:46 1242-----------------待定------------ ... -
瓷砖的页面方案-- n个action凑一个页面。
2008-11-05 17:11 1836我刚实现的的Struts方案,用了一堆东西:struts, ... -
Sun Ruby开发人员吃醋--- IronRuby开始支持Rails
2008-09-22 09:37 1567继Rubinius第一个成功地 ... -
WPF/E is Ajax
2008-01-17 11:22 1763做一个从数据库读取数据然后在页面展示出来的矩阵图谱。 对 ... -
银光1.0快速入门之二 创建XAML
2007-09-17 09:49 3955英文原文参见:http://silverlight.net/q ... -
银光1.0 快速入门之一 创建SilverLight项目
2007-09-14 13:39 4788第一步:在HTML页面加入Javascript引用 这步主要 ...
相关推荐
JS在浏览器中解析Base64编码图像,指的是使用JavaScript在网页中嵌入和显示Base64编码的图像。 在浏览器中,图像可以通过data:URI模式嵌入到HTML中,这是一种MIME类型,允许直接在MIME头部中包含数据。Data:URI的...
而在JavaScript中,可以使用btoa()函数对字符串进行Base64编码,以及atob()函数对Base64编码的字符串进行解码。 关于浏览器对Base64编码数据的支持,当前主流浏览器如IE8、Firefox、Chrome和Opera等都已经支持Data ...
5. **在线工具**:由于描述中提到的是“在线转”,这意味着这个工具可能是一个Web应用程序,用户可以在浏览器中直接上传图片并获取Base64编码结果,无需下载和安装额外的软件。 6. **信息管理**:在Web开发中,信息...
在JavaScript中,我们可以创建FormData对象,将base64编码的图片转换回Blob,然后添加到FormData中。例如: ```javascript let formData = new FormData(); formData.append('image', b64toBlob(base64String), '...
base64,`,表示这是JPEG格式的Base64编码图像。最后,我们创建了一个隐藏的下载链接,将Base64字符串设为其`href`属性,并模拟点击事件触发下载。 需要注意的是,由于Base64编码后的字符串比原始图片文件大,因此...
在JavaScript中,Base64的加密与解密是前端开发中的常见需求,尤其在处理图像、JSON数据或者进行跨域通信时。本文将深入探讨JavaScript中的Base64原理及其在前端应用。 一、Base64编码原理 Base64编码将每3个8位...
5. **兼容性**: JavaScript运行在各种不同的环境中,`base64js`库可能会考虑浏览器兼容性问题,确保在旧版本的浏览器中也能正常工作。 6. **API设计**: `base64js`可能提供了一套简洁的API,使得开发者能够轻松地在...
1. **解析Base64字符串**: 应用程序首先会读取Base64字符串,并将其分割为适合解码的块。 2. **解码Base64**: 使用Base64解码算法,将每个4个字符的Base64块转换回原始的24位二进制数据。 3. **创建图片文件**: ...
7. **安全考虑**:虽然base64编码使图片数据变得可见,但并不能直接被浏览器解析为图片,减少了某些安全风险。然而,base64编码的图片仍然可能暴露敏感信息,因此在设计上传程序时,需要考虑防止跨站脚本(XSS)攻击...
标题“js对图片base64编码字符串进行解码并输出图像示例”和描述“主要介绍了js对图片base64编码字符串进行解码并输出图像的具体实现,大家可以...的核心内容是关于在JavaScript中将图片的base64编码字符串转换为图像...
在这个"js base46转码、保存图片到本地、img显示本地图片.zip"的压缩包中,我们聚焦于JavaScript处理图像的一些核心功能,包括Base64编码、在页面上显示本地图片以及将图片保存到用户本地。下面,我们将深入探讨这些...
在前端,我们可以通过创建一个新的`<img>`标签,将其`src`属性设置为Base64编码的data URL,这样浏览器就会解析这个编码并显示图片。例如: ```html <img id="myImage" src="" alt="Base64 Image"> ``` ```...
对于现代浏览器来说,可以直接使用`window.btoa()`和`window.atob()`函数来完成Base64的编码和解码。 **base64.js** 虽然题目中的文件没有给出具体的`base64.js`内容,但可以参考以下简单的实现方式: ```...
在PHP中,将Base64编码的数据转换为图片并输出是一项常见的任务,特别是在处理网络上传或接收的图像数据时。Base64编码是一种用于将二进制数据转换为ASCII字符串的编码方式,使得数据可以在纯文本环境中传输。下面将...
然而,由于IE8的限制,当Base64编码的字符串长度超过一定阈值时,浏览器无法正确解析并显示图像,这无疑给开发者带来了困扰。 为了解决这个问题,我们可以开发一个特定的“图像预览控件”。这个控件的核心功能是将...
概述使用您的浏览器将图像编码和解码为 base64 以将图像嵌入到 HTML 和 CSS 中。特征生成 CSS 和 HTML 代码以嵌入图像。 将 base64 图像字符串恢复为图像文件。 Vanilla Javascript(无依赖)。 仅适用于现代浏览器...
在ECharts的场景中,PhantomJS可以用来生成基于Base64编码的图表,这对于网页开发、数据可视化和无头浏览器操作等具有重要意义。 ECharts是百度开源的一款轻量级、高性能的JavaScript图表库,它提供了丰富的图表...
通过在浏览器的搜索框中输入“b64”后接一个Base64编码的URL,用户可以直接打开并浏览该编码后的网址所对应的网页,无需先解码再访问,极大地提高了工作效率。 在技术层面上,Base64编码是基于64个可打印字符的编码...
Base64编码是一种将二进制数据转化为可打印字符的表示方式,常用于在网络上传输图片或者在CSS中嵌入图片。在这个过程中,`canvas.toDataURL`方法起到了关键作用。 首先,我们需要理解`<canvas>`元素,它提供了在...
在Web中,Base64编码常用于在URL中传递图片数据,或者在CSS、JavaScript等文本格式中嵌入图像。将Canvas转换为base64编码的图片,可以方便地在浏览器中显示或通过网络传输。 5. 兼容性问题: 描述中提到,这个功能...