|
锁定老帖子 主题：在浏览器中解析Base64编码图像
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-10-21
最后修改：2010-10-22
原文发表在：blogs.ejb.cc 作者: Ray_Linn
上一篇介绍中，我们将二进制文件(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编码后文件大小增加的问题？留着思考吧。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2010-10-21
ray_linn 写道 原文发表在：blogs.ejb.cc 作者: Ray_Linn
上一篇介绍中，我们将二进制文件(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组件，代码如下：
package cc.ejb.arabic.controller;
import java.awt.Image;
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.IOException;
import org.apache.commons.codec.binary.Base64;
import com.opensymphony.xwork2.ActionSupport;
import com.sun.jimi.core.Jimi;
import com.sun.jimi.core.JimiException;
import com.sun.jimi.core.JimiReader;
public class Base64ImageAction extends ActionSupport {
private final static String galleryName = "gallery";
private static String parent = null;
private String fileName = null;
private String encodeString = null;
public String getEncodeString() {
return encodeString;
}
public void setEncodeString(String encodeString) {
this.encodeString = encodeString;
}
public String getFileName() {
return fileName;
}
public void setFileName(String fileName) {
this.fileName = fileName;
}
private String getImageFullPath() {
if (parent == null) {
parent = new File(this.getClass().getClassLoader().getResource(
File.separator).getPath()).getParent();
}
return parent + File.separator + galleryName + File.separator
+ this.fileName;
}
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编码后文件大小增加的问题？留着思考吧。 不明白的是： “更直接的想法，是否能用Javascript直接在浏览器中，对Base64文本进行解码呢？” js能生成png？ |
| 返回顶楼 | |
|
发表时间：2010-10-21
最后修改：2010-10-21
kimmking 写道 不明白的是： “更直接的想法，是否能用Javascript直接在浏览器中，对Base64文本进行解码呢？” js能生成png？ 真的是生成~~的，用一个个div生成的哈 |
| 返回顶楼 | |
|
发表时间：2010-10-22
ray_linn 写道 kimmking 写道 不明白的是： “更直接的想法，是否能用Javascript直接在浏览器中，对Base64文本进行解码呢？” js能生成png？ 真的是生成~~的，用一个个div生成的哈 这个。。。图片多点的话，性能会很低吧？随便一个字都有近百个象素了 |
| 返回顶楼 | |
|
发表时间：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开发者了，不需我多说理由了 |
| 返回顶楼 | |
|
发表时间：2010-10-22
最后修改：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开发者了，不需我多说理由了 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. |
| 返回顶楼 | |
|
发表时间：2010-10-22
最后修改：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。 |
| 返回顶楼 | |
|
发表时间：2010-10-22
最后修改：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。 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有潜在风险，那规避风险才是明智的。 |
| 返回顶楼 | |
|
发表时间：2010-10-22
最后修改：2010-10-22
打印出jai image io错误的信息，一堆堆的libx，你在windows怎么玩都没问题，windows的gdi是不可去除的，但linux的libx则是另一回事了。
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++库 |
| 返回顶楼 | |
|
发表时间：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）不受此模式影响。 |
| 返回顶楼 | |
