常见的文件后缀名
 
.ACA：Microsoft的代理使用的角色文档
 
.acf：系统管理配置
 
.acm：音频压缩管理驱动程序,为Windows系统提供各种声音格式的编码和解码功能
 
.aif：声音文件，支持压缩，可以使用WindowsMediaPlayer和QuickTimePlayer播放
 
.AIF：音频文件，使用WindowsMediaPlayer播放
 
.AIFC：音频文件，使用WindowsMediaPlayer播放
 
.AIFF：音频文件，使用WindowsMediaPlayer播放
 
.ani：动画光标文件扩展名，例如动画沙漏。
 
.ans：ASCII字符图形动画文件
 
.arc：一种较早的压缩文件，可以使用WinZip,WinRAR,PKARC等软件打开
 
.arj：压缩文件。可以使用WinZip,WinRAR,PKARC等软件打开
 
.asf：微软的媒体播放器支持的视频流，可以使用WindowsMediaPlayer播放
 
.asp：微软的视频流文件，可以使用WindowsMediaPlayer打开
 
.asp：微软提出的ActiveServerPage,是服务器端脚本，常用于大型网站开发，支持数据库连接，类似PHP。可以使用VisualInterDev编写，是目前的大热门
 
.asx：WindowsMedia媒体文件的快捷方式
 
.au：是Internet中常用的声音文件格式，多由Sun工作站创建，可使用软件WaveformHoldandModify播放。NetscapeNavigator中的LiveAudio也可以播放.au文件
 
.avi：一种使用MicrosoftRIFF规范的Windows多媒体文件格式，用于存储声音和移动的图片
 
.bak：备份文件，一般是被自动或是通过命令创建的辅助文件，它包含某个文件的最近一个版本，并且具有于该文件相同的文件名
 
.basBasic：语言源程序文件，可编译成可执行文件,目前使用Basic开发系统的是VisualBasic
 
.bat：批处理文件，在MS-DOS中，.bat文件是可执行文件，有一系列命令构成，其中可以包含对其他程序的调用
 
.bbs：电子告示板系统文章信息文件
 
.bfc：Windows的公文包文件
 
.bin：二进制文件，其用途依系统或应用而定
 
.bmp：Bitmap位图文件，这是微软公司开发Paint的自身格式，可以被多种Windows和WindowsNT平台及许多应用程序支持，支持32位颜色，用于为Windows界面创建图标的资源文件格式。
 
.c：C语言源程序文件，在C语言编译程序下编译使用
 
.cab：Microsoft制订的压缩包格式，常用于软件的安装程序，使用Windows自带的实用程序，Extract.exe可以对其解压缩，WinZip,WinRAR等都支持这种格式
 
.cal：Windows中的日历文件
 
.cdf：InternetExplorer的频道文件
 
.cdr：CorelDraw中的一种图形文件格式，它是所有CorelDraw应用程序中均能够使用的一种图形图像文件格式
 
.cdx：索引文件，存在于Dbase,Foxbase,Foxpro系统软件环境下
 
.cfg：配置文件，系统或应用软件用于进行配置自己功能，特性的文件
 
.chm：编译过后的HTML文件，常用于制作帮助文件和电子文档
 
.clp：在Windows下剪贴板中的文件格式
 
.cmd：用于WindowsNT/2000的批处理文件，其实与BAT文件功能相同，只是为了与DOS/Windows9x下的BAT有所区别
 
.cmf：声卡标准的音乐文件，FM合成器等可以回放
 
.cnf：NetMeetting会议连接文件
 
.cnt：联机帮助文件目录索引文件，通常和同名的.hlp文件一起保存
 
.col：由AutodeskAnimator,AutodeskAnimatorPor等程序创建的一种调色板文件格式，其中存储的是调色板中各种项目的RGB值
 
.com：DOS可执行命令文件，一般小于64KB
 
.cpl：控制面板扩展文件，Windows操作系统使用
 
.cpp：C++语言源程序，非常强大的语言，在各种平台中都有相应的开发系统
 
.crd：Windows中的卡片文件
 
.crt：用于安全方面的证书认证文件
 
.cur：Windows下的光标资源文件格式，可用光标编辑软件编辑
 
.css：Text/css文件
 
.dat：数据文件，在应用程序中使用
 
.dat：VCD中的图象声音文件，VCD播放软件可调用，或是通过VCD机播放
 
.dbf：数据库文件，Foxbase,Dbase,VisualFoxPro,等数据库处理系统所产生的数据库文件
 
.dcx：传真浏览文档文件
 
.ddi：映象文件，DUP,HD,IMG等工具可展开
 
.dev：设备驱动程序
 
.dib：设备无关位图文件，这是一种文件格式，其目的是为了保证用某个应用程序创建的位图图形可以被其它应用程序装载或显示一样
 
.dir：目录文件
 
.dll：Windows动态连接库，几乎无处不在，但有时由于不同版本DLL冲突会造成败各种各样的问踢
 
.doc：是目前市场占有率最高的办公室软件MicrosoftOffice中的字处理软件Word创建的文档
 
.dos：Windows保留的MS-DOS的某些系统文件
 
.dot：MicrosoftWord的文档模板文件，通过模板可以简化一些常用格式文档的创建工作,而且可以内嵌VBA程序来实现某些自动化功能
 
.drv：设备驱动程序文件，用在各种系统中
 
.dwg：AutoCAD的图纸文件，也是许多绘图软件都支持的格式，常用于共享数据
 
.dxb：AutoCAD创建的一中图形文件格式
 
.dxf：图形交换格式，一种计算机辅助设计的文件格式，最初开发用来与AutoCAD一起使用，以便于图形文件在应用程序之间的传递,它以ASCII方式储存图形，在表现图形的大小方面十分精确
 
.der：Certiticate文件
 
.dic：Txt文件
 
.emf：由Microsoft公司开发的Windows32位扩展图元文件格式，其总体设计目标是要弥补在MicrosoftWindows3.1(Win16)中用的*.wmf文件格式的不足,使得图元文件更加易于使用
 
.eps：用PostScript语言描述的一种图形文件格式，以文本文件保存，在PostScript图形打印机上能打印出高品质的图形图象，最高能表示32位图形图象
 
.err：编译错误文件，存在于Dbase,Foxbase,Foxpro系列软件环境下
 
.exe：可执行文件，虽然后缀名相同，但具有不同的格式和版本
 
.exp：3DS使用的显示卡驱动程序
 
.exc：Txt文件
 
.flc：AutodeskAnimator和Animatorpro的动画文件，支持256色，最大的图象象索是64000*64000,支持压缩，广泛用于动画图形中的动画序列，计算机辅助设计和计算机游戏应用程序
 
.fnd：保存的搜索结果
 
.fon：点阵字库文件
 
.for：Fortran语言程序
 
.fot：指向字体的快捷键
 
.fp：配置文件，存在于Dbase,Foxbase,Foxpro系列软件的环境下
 
.fpt：备注字段文件，存在于Dbase,Foxbase,Foxpro系列软件的环境下
 
.frt：报表文件,存在于Dbase,Foxbase,Foxpro系列软件的环境下
 
.frx：报表文件,存在于Dbase,Foxbase,Foxpro系列软件的环境下
 
.fxp：编译后的程序，存在于Dbase,Foxbase,Foxpro系列软件的环境下
 
.gif：在各种平台的各种图形处理软件上均能够处理的，经过压缩的一种图形文件格式
 
.grh：方正公司的图象排版文件
 
.grp：Windows下的程序管理器产生的组窗口文件
 
.goc：Gocserve
 
.gra：MSGraph.Chart.5
 
.h：C语言源程序头文件
 
.hlp：Windows应用程序帮助文件
 
.hqx：Macintosh中使用BinHex将二进制文件编码为7位的文本文件，大多数Macintosh文件皆以.hqx出现(.bin极少使用)，在Macintosh中,可使用StuffItExpander对.hqx解码，在Windows中可使用BinHex13解码
 
.ht：超级终端
 
.htm/html：保存超文本描述语言的文本文件，用于描述各种各样的网页，使用各种浏览器打开
 
.icm：图象配色描述文件
 
.ico：Windows中的图标文件，可以包含同一个图标的多种格式，使用图标编辑软件创建
 
.idf：MIDI乐器定义
 
.idx：索引文件，存在于Dbase,Foxbase,Foxpro系列软件的环境下
 
.iff：文件交换格式文件，这种文件格式多用于Amiga平台,在这种平台上它几乎可以存储各种类型的数据，在其它平台上，IFF文件格式多用于存储图象和声音文件
 
.image：MAcintosh磁盘映象文件，常见于萍果机的FTP网点，在Macintosh中由ShrinkWrap处理
 
.ime：Windows下的输入法文件
 
.img：磁盘映象文件，用HD-COPY,WinImage等工具打开后可以恢复到一张磁盘上
 
.inc：汇编语言包含文件，类似C/C++中的.H文件
 
.inf：Windows下的软件安装信息，Windows的标准安装程序根据此文件内的安装信息对软件，驱动程序等进行安装
 
.ini：Windows中的初始化信息文件,已经用的不多了，新的应用程序将设置保存在系统的注册表中
 
.jar：一种压缩文件，ARJ的新版本，不过不太流行，可以使用WinJar,Winrar等打开
 
.jpeg：一种图片压缩文件,同.jpg
 
.jpg：静态图象专家组制订的静态图象压缩标准，具有很高的压缩比，使用非常广泛，可使用PhotoShop等图象处理软件创建
 
.lnk：快捷方式，这个文件指向另一个文件，开始菜单的程序文件夹下每条项目都是一个LNK文件
 
.log：日志文件,通常用来记录一些事件之类
 
.lzh：一种古老的压缩文件，可以使用WinRAR打开
 
.mac：Macintosh中使用的一中灰度图形文件格式，在MacintoshPaintbrush中使用，其分辨率只能是720*567
 
.mag：图形文件格式
 
.mdb：MicrosoftAccess使用的数据库格式，非常流行的桌面数据库
 
.men：内存应用文件，在Dbase，Foxbase,Foxpro系列软件环境下
 
.mid：音频压缩文件，曾经非常流行，不过在现在的软件中很少用了
 
rle：一种压缩过的位图文件格式，RLE压缩方案是一种极其成熟的压缩方案，特点是无损失压缩，既节省了磁盘空间又不损失任何图像数据，但在打开这种压缩文件时，要花费更多时间，此外，一些兼容性不太好的应用程序可能会搭不开
 
.rm：Windows下的RealPlayer所支持的视频压缩文件，网上非常流行的流式视频文件，很多实时视频新闻等都是采用这种格式的，不过，最新的WindowsMediaVideoV8已经对其发起了强大的攻势
 
.rmi：MIDI音序文件
 
.sav：存档文件
 
.rtf：丰富文本格式文件，以纯文本描述内容，能够保存各种格式信息，可以用写字版，Word等创建
 
.scp：用于Windows系统中Internet拨号用户，自动拨号登录用的脚本文件，可避免手动登录时繁琐的键盘输入
 
.scr：屏障保护文件
 
.sct：屏幕文件
 
.scx：屏幕文件
 
.set：Microsoft备份集文件，用于保存要备份的内容，设置等信息
 
.shb：指向一个文档的快捷方式
 
.snd：Mac声音文件,Apple计算机公司开发的声音文件格式，被Macintosh平台和多种Macintosh应用程序所支持，支持某些压缩
 
.sql：查询文件，在Dbase,Foxbase,Foxpro系列软件的环境下使用
 
.svg：SVG可以算是目前最火热的图像文件格式了，它是基于XML由WorldWideWebConsortium联盟开发的，SVG是可缩放的矢量图
 
.svx：Amiga声音文件，Commodore所开发的声音文件格式，被Amiga平台和应用程序所支持，不支持压缩
 
.swf：flash是Micromedia公司的产品，严格说它是一种动画编辑软件，实际上它是制作出一种后缀名为.swf的动画，这种格式的动画能用比较小的体积来表现丰富的多媒体形式，并且还可以与HTML文件达到一种"水乳交融"的境界
 
.swg：虚拟内存交换文件，由操作系统使用
 
.sys：系统文件，驱动程序等，在不同的操作系统中有不同的定义
 
图片格式：光栅图片
 
BMP：Windows位图
 
Windows位图可以用任何颜色深度（从黑白到24位颜色）存储单个光栅图像。Windows位图文件格式与其他MicrosoftWindows程序兼容。它不支持文件压缩，也不适用于Web页。
 
从总体上看，Windows位图文件格式的缺点超过了它的优点。为了保证照片图像的质量，请使用PNG文件、JPEG文件或TIFF文件。BMP文件适用于Windows中的墙纸。
 
优点：BMP支持1位到24位颜色深度。BMP格式与现有Windows程序（尤其是较旧的程序）广泛兼容。
 
缺点：BMP不支持压缩，这会造成文件非常大。BMP文件不受Web浏览器支持。
 
 
 
PCX：PC画笔
 
“PC画笔”图片（也被称为Z-Soft位图）会以任何颜色深度存储单个光栅图像。画笔图片更广泛地用于较早的Windows程序和基于MS-DOS的程序。画笔图片与许多较新的程序兼容。PCX图片支持“行程长度编码”(RLE)内部压缩。
 
 
 
优点：PCX在许多基于Windows的程序和基于MS-DOS的程序间是标准格式。PCX支持内部压缩。
 
缺点：PCX不受Web浏览器支持。
 
PNG：可移植网络图形
 
PNG图片以任何颜色深度存储单个光栅图像。PNG是与平台无关的格式。
 
优点：PNG支持高级别无损耗压缩；PNG支持alpha通道透明度；PNG支持伽玛校正。PNG支持交错；PNG受最新的Web浏览器支持；GIF格式支持多图像文件和动画文件。
 
缺点：较旧的浏览器和程序可能不支持PNG文件；作为Internet文件格式，与JPEG的有损耗压缩相比，PNG提供的压缩量较少；作为Internet文件格式，PNG对多图像文件或动画文件不提供任何支持。
 
 
 
GIF：图形交换格式
 
GIF图片以8位颜色或256色存储单个光栅图像数据或多个光栅图像数据。GIF图片支持透明度、压缩、交错和多图像图片（动画GIF）。GIF透明度不是alpha通道透明度，不能支持半透明效果。GIF压缩是LZW压缩，压缩比大概为3:1。GIF文件规范的GIF89a版本中支持动画GIF。
 
 
 
优点：GIF广泛支持Internet标准；支持无损耗压缩和透明度；动画GIF很流行，易于使用许多GIF动画程序创建。
 
缺点：GIF只支持256色调色板，因此，详细的图片和写实摄影图像会丢失颜色信息，而看起来却是经过调色的；在大多数情况下，无损耗压缩效果不如JPEG格式或PNG格式；GIF支持有限的透明度，没有半透明效果或褪色效果（例如，alpha通道透明度提供的效果）。
 
 
 
JPEG：联合摄影专家组
 
JPEG图片以24位颜色存储单个光栅图像。JPEG是与平台无关的格式，支持最高级别的压缩，不过，这种压缩是有损耗的。渐近式JPEG文件支持交错。可以提高或降低JPEG文件压缩的级别。但是，文件大小是以图像质量为代价的。压缩比率可以高达100:1。（JPEG格式可在10:1到20:1的比率下轻松地压缩文件，而图片质量不会下降。）JPEG压缩可以很好地处理写实摄影作品。但是，对于颜色较少、对比级别强烈、实心边框或纯色区域大的较简单的作品，JPEG压缩无法提供理想的结果。有时，压缩比率会低到5:1，严重损失了图片完整性。这一损失产生的原因是，JPEG压缩方案可以很好地压缩类似的色调，但是JPEG压缩方案不能很好地处理亮度的强烈差异或处理纯色区域。
 
优点：摄影作品或写实作品支持高级压缩；利用可变的压缩比可以控制文件大小；支持交错（对于渐近式JPEG文件）；JPEG广泛支持Internet标准。
 
缺点：有损耗压缩会使原始图片数据质量下降；当您编辑和重新保存JPEG文件时，JPEG会混合原始图片数据的质量下降，这种下降是累积性的；JPEG不适用于所含颜色很少、具有大块颜色相近的区域或亮度差异十分明显的较简单的图片。
 
 
 
TIFF：标记图像文件格式
 
TIFF以任何颜色深度存储单个光栅图像。TIFF可以被认为是印刷行业中受到支持最广的图形文件格式。TIFF支持可选压缩，不适用于在Web浏览器中查看。TIFF格式是可扩展的格式。这意味着程序员可以修改原始规范以添加功能或满足特定的需要。修改规范可能会导致不同类型的TIFF图片之间不兼容。
 
 
 
优点：TIFF是广泛支持的格式，尤其是在Macintosh计算机和基于Windows的计算机之间；支持可选压缩。可扩展格式支持许多可选功能。
 
缺点：TIFF不受Web浏览器支持；可扩展性会导致许多不同类型的TIFF图片；并不是所有TIFF文件都与所有支持基本TIFF标准的程序兼容。
 
 
 
图片格式：矢量图片
 
CGM：计算机图形图元文件
 
CGM图元文件可以包含矢量信息和位图信息。它是由许多组织和政府机构（包括“英国标准协会”(BSI)、“美国国家标准协会”(ANSI)和美国国防部）使用的国际性标准化文件格式。
 
 
 
优点：CGM是国际标准格式。
 
DXF：AutoCAD绘图交换文件
 
DXF是AutodeskAutoCAD程序使用的基于矢量的ASCII格式。AutoCAD可以提供非常详细的完全可以缩放的图表。
 
 
 
优点：您可以使用AutoCAD创建非常详细和精确的图表和图形；AutoCAD文件在建筑、设计和雕刻行业很流行。
 
缺点：AutoCAD在Office中受到的支持很有限，Office支持R12之前的AutoCAD版本；AutoCAD具有很陡的学习曲线。请注意，其他图形程序也可以导出DXF图片。
 
 
 
CDR：CorelDRAW!
 
CorelDRAW!图元文件可以同时包含矢量信息和位图信息。
 
 
 
优点：CDR广泛用于印前行业和艺术设计行业。
 
缺点：CDR在Office中受到的支持很有限，Office支持CorelDRAW!6版和更早版本。
 
 
 
WMF：Windows图元文件
 
“Windows图元文件”是16位图元文件格式，可以同时包含矢量信息和位图信息。它针对Windows操作系统进行了优化。
 
 
 
优点：WMF是Windows标准格式，可很好地在Office中使用。
 
EPS：EncapsulatedPostScript
 
“EncapsulatedPostScript”格式是一种专用的打印机描述语言，可以描述矢量信息和位图信息。
 
优点：EPS可在任何PostScript打印机上进行准确的效果呈现。
 
EPS是行业标准格式。
 
缺点：屏幕显示可能与输出的显示不一致。屏幕呈现可能会是低分辨率的，可能会是不同图像，或只是占位符图像；EPS文件旨在用于输出。它们不是用于在屏幕上显示信息的最适合的格式。
 
 
 
EMF：增强型图元文件
 
“增强型图元文件”是32位格式，可以同时包含矢量信息和位图信息。此格式是对“Windows图元文件格式”的改进，包含了一些扩展功能，例如，下面的功能：内置的缩放比例信息；与文件一起保存的内置说明；调色板和设备独立性方面的改进。
 
 
 
EMF格式是可扩展的格式，这意味着程序员可以修改原始规范以添加功能或满足特定的需要。此修改可能会导致不同类型的EMF图片之间不兼容。
 
 
 
优点：可扩展的文件格式；与WMF相比，经过功能改进。
 
缺点：可扩展性会导致许多不同类型的EMF图片，并不是所有EMF文件都与所有支持EMF标准的程序兼容。
 
PICT：Macintosh图片
 
PICT文件是用于Macintosh计算机的32位图元文件格式。PICT文件使用“行程长度编码”(RLE)内部压缩，该内部压缩工作相当良好。如果安装了QuickTime，则PICT文件支持JPEG压缩（仅限Macintosh）。
 
 
 
优点：PICT是用于Macintosh计算机屏幕显示的最佳文件格式；当您从Macintosh计算机输出到非PostScript打印机时，PICT是要使用的最佳输出格式。
 
缺点：在平台间移动它们时，字体可能显示得不正确；必须安装QuickTime才能正确查看某些PICT文件。
 
 
 
 
 
分辨率和颜色深度
 
光栅图片应有适当的颜色深度和分辨率。如果您保存图片时使用了正确的分辨率和颜色设置，您就会创建出较小的文件。较小的文件意味着更小、更快的文档和演示文稿。您最感兴趣的是：让您的图片在图片使用要求范围内尽可能小。
 
颜色数目—Internet使用非Internet使用
 
（黑白）GIF、（16）*GIF、（256简单图片）*GIF、（256复杂图片）*JPEG、超过256JPEG、PNG或TIFF，分辨率为72ppi
 
注意：Microsoft推荐的分辨率为72像素/英寸，因为大多数监视器的分辨率位于60像素/英寸与80像素/英寸之间。使用较高的分辨率保存不会产生较高的显示质量，因为您的监视器无法显示比监视器中实际存在的像素更多的像素。您应该根据图片已完成的大小而不是原始大小来计算每英寸的点数。例如，如果您在扫描一个8.5x2英寸的信头以便在Web页上使用，已完成的宽度是2英寸，您可以使用72ppi来扫描这2英寸，总计为144像素。当它的大小被设置为2英寸并在显示视器上显示时，最终的文件看起来效果会非常好。
 
 
 
注意：在256色，JPEG文件可提供比GIF文件高的压缩级别。但是，在压缩某些简单文件时，JPEG压缩不如GIF压缩有效。
 
 
 
注意：如果您的图片是灰度图片，具有一大块纯色区域，或者具有高对比度（浅色区域和深色区域之间具有强烈差异）的区域，请选择GIF格式。
 
 
 
注意：如果您的图片是彩色图片，并包含多种不同的颜色（色调），这些颜色（色调）的亮度或暗度（值）类似，请选择JPEG格式，因为JPEG格式可以提供更好的压缩。JPEG压缩根据色调工作，适用于处理值类似的不同色调。JPEG压缩不能很好地处理具有不同值的类似色调。
 
 
 
打印输出
 
如何创建良好的打印输出是一个复杂的主题，因为可供使用的打印机数量众多，而且每台打印机生成彩色输出和灰度输出的功能是不同的。产生良好打印输出的主要因素是您的打印机能够打印的每英寸行数(LPI)。
 
要以彩色或灰度模式打印，打印机必须在中间色调中打印。中间色调是排列在网格中的点的阵列，这些点将每个图像像素表示为一个灰色阴影。对于深灰色，网格中的大多数点会被填充。对于浅灰色，网格上只有很少的点被填充。打印机的LPI设置决定了此网格的大小。LPI越高，网格就越小，打印机能够呈现的灰色阴影就越少。
 
要以彩色打印，打印机必须打印彩色点的重叠行。每个点都是在不同于其他点的角度上设置的，会略有偏移，所以这些点不能完全相互覆盖。这种度量单位称为“屏幕频率”，以组成该颜色的点的行旋转度数表示。
 
下表可帮助您选择用于扫描的最佳分辨率，以点/英寸(dpi)为单位。
 
打印机类型———输出dpi—输出LPI—扫描ppi
 
Laserprinter300———55———65———120
 
Laserprinter600———65———85———150
 
Ink-Jetprinter300———50———60———110
 
Dye-Subprinter300——55———70———125
 
Imagesetter1250+——120——150———300
 
 
 
要计算您的目标扫描分辨率，您可以将打印机的LPI乘以2。这是一般规则。要弄清楚您的打印机的LPI，请参阅您的打印机文档。
 
 
 
注意：当您应用LPI乘以2的一般规则时，您必须进行试验。有些打印机支持非常高的分辨率。如果您使用大于300ppi的分辨率保存图片，较大的图片可能会占用大量的磁盘空间，而且会减慢您的计算机上的其他操作。文档中的多个大图片可能会导致某个程序停止响应，或者可能会导致Windows停止响应。
 
该规则的唯一例外是，纯黑白图像，即“线型”图像。这些图像使用1位存储颜色信息。请使用1对1的比率扫描这些图像。如果您的打印机分辨率是600dpi，请在“线型”模式中使用600ppi扫描这些图像。
 
如果您希望您的图片以灰度显示或者少于256色，请使用TIFF格式或GIF格式。TIFF格式是印刷行业用于图形的标准，因为TIFF格式不使用有损耗压缩方案。其他格式，例如JPEG，使用有损耗压缩方案。TIFF还支持多层透明度，而几乎没有其他格式支持多层透明度。
 
如果图片多于256色，请用TIFF格式或PNG格式保存图片。如果您需要透明度，Microsoft建议使用PNG格式。如果您不需要透明度，请使用TIFF格式。
 
Microsoft建议您根据已完成图片大小的打印机分辨率保存图片。例如，假定您有一个8.5x2英寸的信头，您需要以2英寸的大小打印该信头。如果您的打印机支持600dpi和85LPI，请将该图片分辨率设置为2英寸时为150ppi，即可得到300x71像素的大小。
 
 
 
术语表
 
Alpha通道：Alpha通道描述图片中的透明区域。此透明区域允许通透地显示背景。Alpha通道允许超过64,000层的透明效果，这样，就可以使用半透明效果和混合效果。
 
颜色深度：颜色深度是图片中的颜色数。颜色深度按位深度划分类别。如果您使用较深的颜色深度，图片中就会有更多颜色，但是较深的颜色深度也会增加文件大小。1位：仅黑白
 
8位：256灰度阴影或256色
 
16位：高彩，65,536色
 
24位：真彩色，16,777,216色
 
32位：真彩色，4,294,967,296色
 
 
 
压缩：压缩是一种通过去除冗余信息使图片文件更小的数学方案。有两种压缩类型：无损耗压缩和有损耗压缩。
 
无损耗压缩：无损耗压缩是一种强调维护原始图片完整性的压缩方案。当图片被解压缩后，它会保持与原始的未经压缩图片相同的分辨率和图片质量。
 
有损耗压缩：有损耗压缩是一种强调生成小图片文件（甚至以图片质量为代价）的压缩方案。与无损耗压缩相比，有损耗压缩可以生成更小的图片文件；但是，当您解压缩图片时，有些原始图片数据会丢失而且无法恢复。
 
文件大小：当您处理图片文件时，文件大小是最终的限制因素。当您在MicrosoftOffice中处理图片时，文件大小是引发问题最常见的原因。文件大小由以下因素决定：图片大小、分辨率、文件格式、压缩和颜色深度。
 
伽玛校正：这是一种校正图片亮度或暗度的方法，以便图片在任何监视器上以相同的亮度显示。
 
色调：色调描述颜色中红色、绿色或蓝色的相对量。例如，粉红色和深红色中都有红色色调。
 
交错：交错是一种通过Internet发送图片数据的方法。当某个图片交错时，会发生以下情况：在下载了该图片的1/64后，您可以看到图片外观形状的总体图像。

原文地址: http://blog.csdn.net/hhhbbb/article/details/6855004
 
最近研究了一下elf文件格式，发现好多资料写的都比较繁琐，可能会严重打击学习者的热情，我把自己研究的结果和大家分享，希望我的描述能够简洁一些。
 
一、基础知识
 
     elf是一种文件格式，用于存储Linux程序. 它内部都有一些什么信息呢？大概包括编制好的计算机指令，数据，计算机在需要的时候把这个文件读取到内存中，cpu就可以从内存中一条一条的读取指令来执行了。
 
    所以说想明白elf格式，我们应该了解一下计算机执行程序需要那些信息。所以这一节，我们补充一些计算机系统的基础知识。
 
    进程和虚拟内存：
 
       Linux系统给每个进程分配了4GB的空间，其中 0xC0000000到0xFFFFFFFF 这个地址段是留给系统使用的，主要用于系统（linux 内核)和进程通信和交换数据，   用户可以使用3GB的空间从(0x00000000-0xBFFFFFFF).
 
      其实计算机的内存是没有那么大的，比如我们实际使用的计算机只有2G,以前更小，只有几百M,而且一台计算机上不只运行一个进程，一个占用4G，如果有10个进程，那就得着用40G了，哪有那么打的内存呢？其实这个不要紧，因为操作系统分配给用户的是虚拟内存，程序要可以使用3个G的内存。至于操作系统怎样把虚拟内存转化成物理内存，对于开发应用程序的工程师来说，是不需要了解的。我们直接使用虚拟内存就可以了，而不用担心其它进程会侵犯到你的内存空间。
 
    进程的创建和运行进程的创建和运行：
 
    大致经历了以下步骤
 
     1.用户请求运行程序时，操作系统会读取存储在磁盘上的可执行文件，在linux系统上这个文件就是我们的elf格式文件，为用户分配4G的虚拟内存空间，
 
     2. 根据文件的信息指示，把不同的文件内容放到为你分配的这3G虚拟内存
 
     3. 然后根据文件的指示，系统设置设置代码段和数据段寄存器
 
     4.然后根据文件的指示,    跳转到用户的代码的入口地址（一般就是我们的main函数)
 
     5.从main开始，计算机就一条一条的执行我们给的指令，处理我们的数据了，直到我们程序结束。虽然在这个过程中，系统会多次切换到其他进程，但对用户程序来说没有影响，我们可以认为计算机只为我们服务。
 
    通过以上我们多次看到计算机是根据文件指示这样的语言，所以学习elf 首先要理解elf指示了那些信息。
 
二、可执行的elf文件。
 
     elf文件分三种类型： 1、目标文件（通常是.o); 2、可执行文件(我们的运行文件)   3、动态库(.so)
 
     我们先讲一下可执行文件。
 
     可执行文件一般分成4个部分，能扩展，我们理解这4部分就够了。
 
     1、elf文件头 ，这个文件是对elf文件整体信息的描述，在32位系统下是56的字节，在64位系统下是64个字节。
 
对于可执行文件来说，文件头包含的一下信息与进程启动相关
 
e_entry      程序入口地址

e_phoff      segment偏移

e_phnum   segment数量
 
     2.   segment表， 这个表是加载指示器，操作系统（确切的说是加载器，有些elf文件，比如操作系统内核，是由其他程序加载的）,该表的结构非常重要。
 
typedef struct
{
  Elf64_Word    p_type;            /* Segment type */
  Elf64_Word    p_flags;        /* Segment flags */  /*segment权限，6表示可读写，5表示可读可执行
  Elf64_Off    p_offset;        /* Segment file offset */     /*段在文件中的偏移*/
  Elf64_Addr    p_vaddr;        /* Segment virtual address */   /*虚拟内存地址，这个表示内存中的
  Elf64_Addr    p_paddr;        /* Segment physical address  /*物理内存地址，对应用程序来说，这个字段无用*/
  Elf64_Xword    p_filesz;        /* Segment size in file */        /*段在文件中的长度*/
  Elf64_Xword    p_memsz;        /* Segment size in memory */       /在内存中的长度，一般和p_filesz的值一样*/
  Elf64_Xword    p_align;        /* Segment alignment */                  /* 段对齐*/
} Elf64_Phdr;   
 
     3.   elf的主题，对于可执行文件来说，最主要的就是数据段和代码段
 
     4.   section表，对可执行文件来说，没有用，在链接的时候有用，是对代码段数据段在链接是的一种描述。
 
     整个elf文件的组成可以使用下图来描述:   
 
 
 
                        
 
                该图片使用的是Linux C编程作者 宋劲斌的图片
 
                上图program header table 实际上就是我们说的segment table.   segments 是从运行的角度来描述elf文件， sections是从链接的角度来描述elf文件的。
 
                本节我们只将elf文件的执行，所以我们只讲segment相关的内容。
 
      我们将通过一个例子来讲解系统加载elf的过程(64位平台)。
 
      我们编写一个简单的汇编程序
 
 .section .data
.global data_item
data_item:
.long 3,67,28
.section .text
.global _start
_start:
    mov $1,%eax
    mov $4,%ebx
    int $0x80
 
 编译链接后生成hello文件，我们分析hello文件.
 
 执行：readelf -h ../asm/hello   （readelf -h 是读取elf文件头的命令)
 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00  
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x4000b0                                       //程序的入口地址是0x4000b0
  Start of program headers:          64 (bytes into file)                    //segment表在文件64字节偏移处
  Start of section headers:          240 (bytes into file)                     
  Flags:                             0x0
  Size of this header:               64 (bytes)                                        
  Size of program headers:           56 (bytes)                                 //segment头项的长度是56字节（32系统是32字节)   
  Number of program headers:         2
  Size of section headers:           64 (bytes)
  Number of section headers:         6
  Section header string table index: 3
 
对于程序的装载，我们关心这三项：
 
 Entry point address:    0x4000b0      //程序的入口地址是0x4000b0

       Start of program headers:    64 (bytes into file)            //segment表在文件64字节偏移处

       Size of program headers:     56 (bytes)             //segment头项的长度是56字节（32系统是32字节)   
 
以上内容告诉我们segment表在文件的64字节处，我们看看64字节处有什么内容。
 
执行 readelf -l ../asm/hello  输出segments信息。(readelf -l 读取segments)
 
Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x00000000000000bc 0x00000000000000bc  R E    200000
  LOAD           0x00000000000000bc 0x00000000006000bc 0x00000000006000bc
                 0x000000000000000c 0x000000000000000c  RW     200000

 Section to Segment mapping:
  Segment Sections...
   00     .text 
   01     .data 
 
我们看到程序有两个segment ，分别叫做.text 和.data 
 
  .text的Offset是0，FileSiz是0x0,MemSiz是0xbc, VirtAddr是0x400000,Flags是R E,表示加载起将把elf文件中从0字节开始直到oxbc处的内容加载到虚拟内存中的0x400000处，占用0xbc长度的内存。设置该内存的权限是RE(可读，可执行），这一段的内容正好是elf头，segments table,和代码段。
 
       在看看elfheader 的e_entry  的地址  0x4000b0，这个地址正好是代码段的起始地址。
 
      .data的Offset是0，FileSiz是0xbc,MemSiz是0x0c, VirtAddr是0x6000bc,Flags是R W,表示加载起将把elf文件中从bc字节开始直到oxbc + 0xc处的内容加载到虚拟内存中的0x6000bc处，占用0x0c长度的内存。设置该内存的权限是RE(可读，可执行）
 
      为什么数据段的其实地址是0x6000bc,而不是0x6000000呢，这是由Align决定的，Align决定内存和磁盘以1M为单位进行映射，在文件中.data 和.text处于一个页面中，在映射的时候，直接把整个页面都映射到了0x6000000处，所以把数据段的偏移设置成了0x60000bc,0x600000到0x6000bc的内容不使用。
 
    有了以上内容，系统就可以根据elf文件创建进程了。
  
 
 
 
 

ELF文件格式
 
  在Linux下，可执行文件/动态库文件/目标文件（可重定向文件）都是同一种文件格式，我们把它称之为ELF文件格式。 
   虽然它们三个都是ELF文件格式但都各有不同： 
   可执行文件没有section header table 。 
   目标文件没有program header table。 
   动态库文件俩个 header table 都有，因为链接器在链接的时候需要section header table 来查看目标文件各个 section 的信息然后对各个目标文件进行链接，而加载器在加载可执行程序的时候需要program header table ,它需要根据这个表把相应的段加载到相应的虚拟内存（虚拟地址空间）中。 
  
   这个图中俩个header表的位置在实际中不一定这么放，只是为了好看这么画的。
 
目标文件的ELF格式组成
 
max.s 文件下述讨论的列子
 
.section .data
data_items: #These are the data items
.long 3,67,34,222,45,75,54,34,44,33,22,11,66,0
.section .text
.globl _start
_start:
movl $0, %edi # move 0 into the index register
movl data_items(,%edi,4), %eax # load the first byte of
data
movl %eax, %ebx # since this is the first item,
%eax is
# the biggest
start_loop: # start loop
cmpl $0, %eax # check to see if we've hit the
end
je loop_exit
incl %edi # load next value
movl data_items(,%edi,4), %eax
cmpl %ebx, %eax # compare values
jle start_loop 
movl %eax, %ebx # move the value as the largest
jmp start_loop # jump to loop beginning
loop_exit:
movl $1, %eax #1 is the _exit() syscall
int $0x80
找一个最大值，把它当中main函数的返回值
 
1.ELF header
 
 
 从上面我们可以看到该ELF文件的大概属性，是什么操作系统，还有是什么处理器架构。从 start of section headers 可以看出section 头表在目标文件的起始地址，从 size of section headers 可以看出来目标文件中每一个section的大小，接着这个字段的下面的字段说了该目标文件共有多少 section。再接着的字段说了，section header table 在目标文件的相对位置。 
 program headers 地址为0，说明没有那么表明这个ELF文件是个 .o文件。
 
2.section header table
 
 
  这个是 section header table ,里面详细说明了各个节的信息。我们可以看到 data , text这俩个节都是在汇编中已经有的，其他的6个节都是汇编器加的。addr那一列表明了这些节在虚拟地址空间的位置全为0，没问题因为现在还没被链接，off/size 表明了相应节在ELF文件（.o) 中的位置和长度（大小）。data段 大小 0x38, 没问题的在汇编文件中定义了14个全局变量，刚好56字节对应0x38. 
 bss 段大小为0，也没问题的，bss段记录未初始化的全局变量，我们没有定义。
 
 
 根据ELF Header 的信息可以画出各个节在ELF文件布局。上面显示了节头表中共有8个 section Header , 每个section Header 记录了相应 section 对应的信息 , 与每个节之后被加载到内存中的所对应的权限。 
 
3.strtab/shstrtab
 
接下来用hexdump把目标文件的内容打印出来。 
  
  
 对照着上面的图，可以看到0x98 shstrtab（section header str table) 对应的内容都是每个section 名字的ASCII码形式。 
 strtab 对应文件地址的0x288中，这个表中保存的是我们 .c 文件中全局变量/函数/源文件的名字。
 
4.rel.text / symtab
 
 
rel.text
 
ret.text 节记录了该目标文件中，有那些位置需要链接器进行重定向。
 
symbol table
 
符号表中记录了，每一个全局符号(即源文件中的函数名/全局变量名)所处于那个section。并且显示出了每一个符号的bind 绑定属性，这个属性在链接器链接的时候有用，local属性的符号立马进行解析绑定，而GLOBAL的却不会。直到遇到一个强状态的GLOBAL属性的符号才会进行绑定，具体是否是强状态，看该全局变量是否是已初始化过的。
 
可执行文件的ELF格式
 
 
  
 把上面的 max.o 文件进行链接生成一个可执行程序后，我们再用readelf 读取它的信息如上图所示。 
 多了俩个 program headers ，少了俩个 section header。 
 少了俩个节头，那俩个一个是bss一个是rel.text , rel.text 在链接的时候被使用完就丢弃了， bss 没使用也被丢弃了。 
 多了俩个 program headers ,如上每一个program Header记录一个数据段，共俩个在这个列子中。一个数据段从 0x08048000 开始 ， 属性只读/可执行/对齐数4k。另一个大家自己看。
 
根据上面的信息我画出来了 可执行文件的格式图
 
 
  
 最后加载器根据， program Header 中的信息，把相应段加载到了虚拟地址空间对应的物理内存中。在目标文件和可执行文件中，可以看出来目标文件中所有的符号地址在链接的过程中都被替换成了确切的虚拟地址。
 
总结下各个Header 的意义
 
Section Header table ：保存了各个 Section Header的描述信息，在目标文件/可执行文件的所述位置与权限信息。 
 text :记录了目标文件/可执行文件的代码（二进制指令） 
 data :记录了目标文件/可执行文件的全局变量的数据 
 shstrtable : 记录了所有Section的名字（以文本方式记录） 
 strtable : 记录了全局变量/函数的名字/源文件的名字（以文本形式) 
 symbol table : 记录了各个全局符号(变量名/函数名)所属那个Section. 
 rel.text.table :记录了链接时需要的重定向信息（即把相应的代码/数据链接到何处. 
 bss : 记录了所属bss段的大小，并没有记录真实的数据。（bss段为未初始化全局变量的数据段） 
 ELF Header : 记录了 ELF文件的一些属性信息。 
 program Header table : 记录了 program Header 的信息。 
 program Header :记录了把那些Section合并成了同一个 Segment,它被用于加载器，加载到内存时使用。 
 所有的 Section 的Header都被记录到了 Section Header table 中。（Section 与SectionHeader 俩个东西）
 
段中的虚拟地址
 
加载首先分为三种方式，第一种绝对加载，第二种可重定位加载，第三种动态运行时加载。 
 第一种方式，提供给加载器的可执行文件的所有地址都是物理地址，这种方式很多缺点，首先程序员得知道分配到那个物理地址处，其次一个地方修改，所有地方都要修改。 
 第二种方式，可执行文件中的地址都是从0开始的，当被加载到物理内存中，对起每个地址 加上起始物理内存的地址即可。缺点不方便换入换出，无法使用虚拟内存。 
 第三种方式，动态运行时加载，即所有内存都写成虚拟地址，当确切的要访问那个虚拟地址的时候，由MMU和页表对其解释成真正的物理地址，方便换入换出，可见在我的Linux下使用的是，动态运行时加载。（换入/换出指的是 页面置换，这个是虚存机制，为了能使同一时间执行更多的进程，加入的一个概念，把阻塞态的进程的内存页中的信息写到硬盘上，然后等需要加载时，再加载到内存中，在linux中 swap区就是用来页面置换的）
 
静态链接
 
静态链接就是，在链接阶段，让链接编辑器把目标文件所用到的函数/符号在静态库文件中找到相应的 .o 文件进行链接。（链接器一般都是先找是否有 相应名的动态库文件，没有才链接 静态库文件的这点需要注意) 
 静态库文件其实就是对一堆 . o 文件的一种打包。
 
生成静态库指令
 
ar -rc libxxx.a xxx.o xxx.o
 
使用静态库文件
 
gcc -l xxx -L ./ -I xxx.h main.c -o a.out -static 
 -l（小写L） 指定库名字 -L 指定库路径 -I 指定头文件
 
动态链接
 
动态链接，就是在运行的时候，当使用到动态库中的函数了，由运行时链接器把相应的动态库加载到地址空间的共享区中。在链接阶段，可执行文件并不链接动态库的内容。
 
gcc   -shared -fPIC  *.c  -o  XXXlib.so  生成动态库文件(使用gcc 直接使源文件编译生成elf格式的动态库文件）
gcc  -lxxx -L ./  -I XXX.h  -o a.out 使用动态库文件
 
我们用ldd 指令去模拟运行可执行程序，会发现动态库 not found,那是因为动态库链接器找不到相应的动态库。动态链接器的搜索路径: 
 1. 首先去 环境 变量LD_LIBRARY_PATH 中查找 
 2. 然后没有去，/etc/ld.so.cache 动态链接器的缓存中文件查找，这个文件是由 /etc/ld.so.conf生成。如果我们要给动态链接器的配置文件加路径，直接把路径写到文件后， 再 ldconfig -v 即可。 
 3. 如果还没有，去/usr/lib 或 /lib 目录下查找，在64位平台下 还有 /usr/lib64 /lib64 这俩个目录。我们可以直接把动态库添加到这个目录
 
动态链接的过程(动态链接器）
 
首先第一次加载动态库的时候，jmp 指令会跳到该相应的符号段，由于动态库相应的文件没被加载到内存中，所以就执行了一个动态链接器的函数，最终由动态链接器把相应的动态库加载进来。以后再对动态库的函数调用时，就不再次加载了，jmp 指令后的地址处中所保存的函数地址就是刚被加载到内存中的函数地址。。（上面说的jmp 指令后的地址处所包含的地址意思是，jmp * 0xXXXXXXXX 这个是间接跳转，跳转的目标地址是后面这个地址空间中所保存的函数地址，0xXXXXXXXX就可以看出一个函数指针变量的地址，而它存储的内容那个函数地址正是我们想要执行的函数。其实在这里动态连接器调用了 dlopen 函数来加载的动态库)
 
in _dl_runtime_resolve () from /lib/ld-linux.so.2
就是进入了这个函数，大家可以自己测试下，我写的这个博客图片太多了，不想再放图片了
 
dlopen 动态链接
 
用dlopen 函数就不用在使用前面所讲的，什么 LD_LIBRARY_PATH 啊什么的了。
 
  1 #include<stdio.h>
  1 #include "add.h"
  2 #include<dlfcn.h>
  3 int main()
  4 {
  5     void * dl =NULL;
  6     int(*add)(int a, int b);
  7     dl = dlopen("./libadd.so",RTLD_LAZY);
  8     if(dl==NULL)
  9     {
 10         return 1;
 11     }
 12     add = (int(*)(int,int))dlsym(dl,"ADD");
 13    // int result = ADD(10,20);
 14     int result = add(10,20);
 15     printf("hehe %d",result);
 16     return 0;
 17 }   
 
使用 dlopen 的时候，编译的时候需要加 -ldl 选项。
 
动态链接/静态链接优缺点
 
优点
 
动态链接优点： 
 1.不占可执行文件大小，在内存中只有一份实例，多个进程可共享一个动态库，节省内存。 
 2.便于升级，如果需要升级动态库模块时，可执行文件不需改变，直接升级动态库文件即可。 
 静态链接优点 
 1.可移植性好，如果把可执行文件放到其他电脑上，不用再需要动态库文件了。 
 2.运行的时候不用再把相应的库文件链接到内存，效率高。
 
缺点
 
动态库 
 1.移植性不好，如果其他电脑上运行可执行程序，没有动态库的话，会发生 not found ,导致程序无法正常运行。并且它是运行时加载，效率可能会慢些。 
 静态库 
 1.由于在链接的时候，被链接编辑器和目标文件一起链接成可执行程序，结果就是造成可执行程序过大，并且如果在内存中有多个相同的可执行程序，那么静态库文件在内存中也存在多个实例，浪费空间。（因为多个相同的静态库文件的代码段被加载到了内存） 
 2. 不便于升级，因为需要重新链接可执行程序。
 
链接期
 
 链接期，主要做了符号解析与符号重定向。 
  我们使用gcc链接程序的时候是有依赖关系的，链接器对于未解析的符号会保留先来，然后把当前 .o 文件丢弃，继续往后遍历去解析其他 .o 文件，如果找到了响应的符号，会对之前未解析的符号进行符号解析与绑定地址。 
  基于这个原理，所以链接的时候文件与文件之间也是有依赖关系的。
 
test.cc
void test()
 {
 }
main.cc
int main()
{
   test();
}
gcc  test.o main.o -o a.out 
会包 未定义 test 函数
 
 就像上面的列子，所以基础的 .o 文件在链接的时候应该往前面放。
 
动态链接/静态链接图
 
链接加载图 可参考 操作系统 精神与设计原理 第七章的图 
 上面的例子，取自于 Linux c 一站式编程中的ELF文件和动态/静态链接。
 
参考
 
深入理解操作系统 第三版 
 操作系统精髓与设计原理 第八版 
 Linux C 一站式编程

因为要处理一些医学图像，需要把dcm格式的文件转换成jpg格式。本来用Sante DICOM Editor用得挺好的，方便查看dcm文件，但是在转换上每次只能转一张（本人没有找到用该软件批量转格式的方法）。于是在网上搜集了各种软件（图片格式转换大师、DCM图片转换大师等等），要么是要付费的，要么就是有病毒。在线转换器最多只能转30张，多的就要付费。
 
最终发现一个免费的软件：MicroDicom。
 
1、下载网址：http://www.microdicom.com/downloads.html 
 
或者直接在百度上搜关键字MicroDicom，第一条就是。如下图：
 
 
 
2、windows下载MicroDicom viewer x64的那一项：
 
 

 
 

 
 
3、安装完成后，打开软件，选择File -> Scan for DICOM files... -> 选择存放图片的文件夹的路径：
 
 
 
 

 
 
4、打开图片后，再点击 File -> Export -> To a picture file...，此时弹出窗口进行转换设置：
 

 
 
5、因为是批量转换，所以Select source选择为Current series，如下设置后点击export。
 
 

 
 
6、查看转换结果所在路径，生成了jpg文件！