下载
加入VIP
  • 专属下载特权
  • 现金文档折扣购买
  • VIP免费专区
  • 千万文档免费下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 外文翻译--Java IO 系统

外文翻译--Java IO 系统.doc

外文翻译--Java IO 系统

冒险小鬼9
2017-09-30 0人阅读 举报 0 0 暂无简介

简介:本文档为《外文翻译--Java IO 系统doc》,可适用于高等教育领域

外文翻译JavaIO系统外文翻译(英文)TheJavaIOSystemCreatingagoodinputoutput(IO)systemisoneofthemoredifficulttasksforalanguagedesignerThisisevidencedbythenumberofdifferentapproachesThechallengeseemstobeincoveringallpossibilitiesNotonlyaretheredifferentsourcesandsinksofIOthatyouwanttocommunicatewith(files,theconsole,networkconnections,etc),butyouneedtotalktotheminawidevarietyofways(sequential,randomaccess,buffered,binary,character,bylines,bywords,etc)TheJavalibrarydesignersattackedthisproblembycreatinglotsofclassesInfact,therearesomanyclassesforJava’sIOsystemthatitcanbeintimidatingatfirst(ironically,theJavaIOdesignactuallypreventsanexplosionofclasses)TherewasalsoasignificantchangeintheIOlibraryafterJavaio,whentheoriginalbyteorientedlibrarywassupplementedwithcharoriented,UnicodebasedIOclassesThenioclasses(for"newIO,"anamewe’llstillbeusingyearsfromnoweventhoughtheywereintroducedinJDKandsoarealready"old")wereaddedforimprovedperformanceandfunctionalityAsaresult,thereareafairnumberofclassestolearnbeforeyouushasbasicmethodscalledread()forreadingasinglebyteoranarrayofbytesLikewise,everythingderivedfromOutputStreamorWriterclasseshasbasicmethodscalledwrite()forwritingasinglebyteoranarrayofbytesHowever,youwon’tgenerallyusethesemethodstheyexistsothatotherclassescanusethemtheseotherclassesprovideamoreusefulinterfaceThus,you’llrarelycreateyourstreamobjectbyusingasingleclass,butinsteadwilllayermultipleobjectstogethertoprovideyourdesiredfunctionality(thisistheDecoratordesignpattern,asyoushallseeinthissection)ThefactthatyoucreatemorethanoneobjecttoproduceasinglestreamistheprimaryreasonthatJava’sIOlibraryisconfusingIt’shelpfultocategorizetheclassesbytheirfunctionalityInJavalo,thelibrarydesignersstartedbydecidingthatallclassesthathadanythingtodowithinputwouldbeinheritedfromInputStream,andallclassesthatwereassociatedwithoutputwouldbeinheritedfromOutputStreamTypeofInputStreamInputStream’sjobistorepresentclassesthatproduceinputfromdifferentsourcesThesesourcescanbe:AnarrayofbytesAStringobjectAfileA"pipe,"whichworkslikeaphysicalpipe:YouputthingsinatoneendandtheycomeouttheotherAsequenceofotherstreams,soyoucancollectthemtogetherintoasinglestreamOthersources,suchasanInternetconnection(ThisiscoveredinThinkinginEnterpriseJava,availableatwwwMindViewnet)EachofthesehasanassociatedsubclassofInputStreamInaddition,theFilterInputStreamisalsoatypeofInputStream,toprovideabaseclassfor"decorator"classesthatattachattributeorusefulinterfacestoinputstreamsTypesofOutputStreamThiscategoryincludestheclassesthatdecidewhereyouroutputwillgo:anarrayofbytes(butnotaStringpresumably,youcancreateoneusingthearrayofbytes),afile,ora"pipe"Inaddition,theFilterOutputStreamprovidesabaseclassfor"decorator"classesthatattachattributesorusefulinterfacestooutputstreamsThisisdiscussedlaterAddingattributesandusefulinterfacesDecoratorswereintroducedintheGenericschapter,onpageTheJavaIOlibraryrequiresmanydifferentcombinationsoffeatures,andthisisthejustificationforusingtheDecoratordesignpatternThereasonfortheexistenceofthe"filter"classesintheJavaIOlibraryisthattheabstract"filter"classisthebaseclassforallthedecoratorsAdecoratormusthavethesameinterfaceastheobjectitdecorates,butthedecoratorcanalsoextendtheinterface,whichoccursinseveralofthe"filter"classesThereisadrawbacktoDecorator,howeverDecoratorsgiveyoumuchmoreflexibilitywhileyou’rewritingaprogram(sinceyoucaneasilymixandmatchattributes),buttheyaddcomplexitytoyourcodeThereasonthattheJavaIOlibraryisawkwardtouseisthatyoumustcreatemanyclassesthe"core"IOtypeplusallthedecoratorsinordertogetthesingleIOobjectthatyouwantTheclassesthatprovidethedecoratorinterfacetocontrolaparticularInputStreamorOutputStreamaretheFilterlnputStreamandFilterOutputStream,whichdon’thaveveryintuitivenamesFilterlnputStreamandFilterOutputStreamarederivedfromthebaseclassesoftheIOlibrary,InputStreamandOutputStream,whichisakeyrequirementofthedecorator(sothatitprovidesthecommoninterfacetoalltheobjectsthatarebeingdecorated)ReadersWritersJavamadesignificantmodificationstothefundamentalIOstreamlibraryWhenyouseetheReaderandWriterclasses,yourfirstthought(likemine)mightbethattheseweremeanttoreplacetheInputStreamandOutputStreamclassesButthat’snotthecaseAlthoughsomeaspectsoftheoriginalstreamslibraryaredeprecated(ifyouusethemyouwillreceiveawarningfromthecompiler),theInputStreamandOutputStreamclassesstillprovidevaluablefunctionalityintheformofbyteorientedIO,whereastheReaderandWriterclassesprovideUnicodecompliant,characterbasedIOInaddition:JavaaddednewclassesintotheInputStreamandOutputStreamhierarchy,soit’sobviousthosehierarchiesweren’tbeingreplacedTherearetimeswhenyoumustuseclassesfromthe"byte"hierarchyincombinationwithclassesinthe"character"hierarchyToaccomplishthis,thereare"adapter"classes:InputStreamReaderconvertsanInputStreamtoaReader,andOutputStreamWriterconvertsanOutputStreamtoaWriterThemostimportantreasonfortheReaderandWriterhierarchiesisforinternationalizationTheoldIOstreamhierarchysupportsonlybitbytestreamsitUnicodecharacterswellSinceUnicodeisusedforanddoesn’thandlethebinternationalization(andJava’snativecharisbitUnicode),theReaderandWriterhierarchieswereaddedtosupportUnicodeinallIOoperationsInaddition,thenewlibrariesaredesignedforfasteroperationsthantheoldStandardIOThetermstandardIOreferstotheUnixconceptofasinglestreamofinformationthatisusedbyaprogram(thisideaisreproducedinsomeforminWindowsandmanyotheroperatingsystems)Alloftheprogram’sinputcancomefromstandardinput,allofitsoutputcangotostandardoutput,andallofitserrormessagescanbesenttostandarderrorThevalueofstandardIOisthatprogramscaneasilybechainedtogether,andoneprogram’sstandardoutputcanbecomethestandardinputforanotherprogramThisisapowerfultoolReadingfromstandardinputFollowingthestandardIOmodel,JavahasSystemin,Systemout,andSystemerrThroughoutthisbook,you’veseenhowtowritetostandardoutputusingSystemout,whichisalreadyprewrappedasaPrintStreamobjectSystemerrislikewiseaPrintStream,butSysteminisarawInputStreamwithnowrappingThismeansthatalthoughyoucanuseSystemoutandSystemerrrightaway,SysteminmustbewrappedbeforeyoucanreadfromitYou’lltypicallyreadinputalineatatimeusingreadLine()Todothis,wrapSystemininaBufferedReader,whichrequiresyoutoconvertSystemintoaReaderusingInputStreamReaderRedirectingTheJavaSystemclassallowsyoutoredirectthestandardinput,output,anderrorIOstreamsusingsimplestaticmethodcalls:setIn(InputStream)setOut(PrintStream)setErr(PrintStream)Redirectingoutputisespeciallyusefulifyousuddenlystartcreatingalargeamountofoutputonyourscreen,andit’sscrollingpastfasterthanyoucanreaditRedirectinginputisvaluableforacommandlineprograminwhichyouwanttotestaparticularuserinputsequencerepeatedlyNewIOTheJava"new"IOlibrary,introducedinJDKinthejavanio*packages,hasonegoal:speedInfact,the"old"IOpackageshavebeenreimplementedusingnioinordertotakeadvantageofthisspeedincrease,soyouwillbenefitevenifyoudon’texplicitlywritecodewithnioThespeedincreaseoccursbothinfileIO,whichisexploredhere,andinnetworkIO,whichiscoveredinThinkinginEnterpriseJavaThespeedcomesfromusingstructuresthatareclosertotheoperatingsystem’swayofperformingIO:channelsandbuffersYoucouldthinkofitasacoalminethechannelistheminecontainingtheseamofcoal(thedata),andthebufferisthecartthatyousendintothemineThecartcomesbackfullofcoal,andyougetthecoalfromthecartThatis,youdon’tinteractdirectlywiththechannelyouinteractwiththebufferandsendthebufferintothechannelThechanneleitherpullsdatafromthebuffer,orputsdataintothebufferTheonlykindofbufferthatcommunicatesdirectlywithachannelisaByteBufferthatis,abufferthatholdsrawbytesIfyoulookattheJDKdocumentationforjavanioByteBuffer,you’llseethatit’sfairlybasic:Youcreateonebytellingithowmuchstoragetoallocate,andtherearemethodstoputandgetdata,ineitherrawbyteformorasprimitivedatatypesButthere’snowaytoputorgetanobject,orevenaStringIt’sfairlylowlevel,preciselybecausethismakesamoreefficientmappingwithmostoperatingsystemsThreeoftheclassesinthe"old"IOhavebeenmodifiedsothattheyproduceaFileChannel:FileInputStream,FileOutputStream,and,forbothreadingandwriting,RandomAccessFileNoticethatthesearethebytemanipulationstreams,inkeepingwiththelowlevelnatureofnioTheReaderandWritercharactermodeclassesdonotproducechannels,butthejavaniochannelsChannelsclasshasutilitymethodstoproduceReadersandWritersfromchannelsReadingfromanInputStreamwithFilterlnputStreamTheFilterlnputStreamclassesaccomplishtwosignificantlydifferentthingsDatalnputStreamallowsyoutoreaddifferenttypesofprimitivedataaswellasStringobjects(Allthemethodsstartwith"read,"suchasreadByte(),readFloat(),etc)This,alongwithitscompanionDataOutputStream,allowsyoutomoveprimitivedatafromoneplacetoanotherviaastreamTheremainingFilterlnputStreamclassesmodifythewayanInputStreambehavesinternally:whetherit’sbufferedorunbuffered,whetheritkeepstrackofthelinesit’sreading(allowingyoutoaskforlinenumbersorsetthelinenumber),andwhetheryoucanpushbackasinglecharacterThelasttwoclasseslookalotlikesupportforbuildingacompiler(theywereprobablyaddedtosupporttheexperimentof"buildingaJavacompilerinJava"),soyouprobablywon’tusethemingeneralprogrammingYou’llneedtobufferyourinputalmosteverytime,regardlessoftheIOdeviceyou’reconnectingto,soitwouldhavemademoresensefortheIOlibrarytohaveaspecialcase(orsimplyamethodcall)forunbufferedinputratherthanbufferedinputWritingtoanOutputStreamwithFilterOutputStreamThecomplementtoDatalnputStreamisDataOutputStream,whichformatseachoftheprimitivetypesandStringobjectsontoastreaminsuchawaythatanyDatalnputStream,onanymachine,canreadthemAllthemethodsstartwith"write,"suchaswriteByte(),writeFloat(),etcTheoriginalintentofPrintStreamwastoprintalloftheprimitivedatatypesandStringobjectsinaviewableformatThisisdifferentfromDataOutputStream,whosegoalistoputdataelementsonastreaminawaythatDatalnputStreamcanportablyreconstructthemThetwoimportantmethodsinPrintStreamareprint()andprintln(),whichareoverloadedtoprintallthevarioustypesThedifferencebetweenprint()andprintln()isthatthelatteraddsanewlinewhenit’sdoneBufferedOutputStreamisamodifierandtellsthestreamtousebufferingsoyoudon’tgetaphysicalwriteeverytimeyouwritetothestreamOffbyitself:RandomAccessFileRandomAccessFileisusedforfilescontainingrecordsofknownsizesothatyoucanmovefromonerecordtoanotherusingseek(),thenreadorchangetherecordsTherecordsdon’thavetobethesamesizeyoujusthavetodeterminehowbigtheyareandwheretheyareplacedinthefileAtfirstit’salittlebithardtobelievethatRandomAccessFileisnotpartoftheInputStreamorOutputStreamhierarchyHowever,ithasnoassociationwiththosehierarchiesotherthanthatithappenstoimplementtheDataInputandDataOutputinterfaces(whicharealsoimplementedbyDataInputStreamandDataOutputStream)Itdoesn’tevenuseanyofthefunctionalityoftheexistingInputStreamorOutputStreamclassesit’sacompletelyseparateclass,writtenfromscratch,withallofitsown(mostlynative)methodsThereasonforthismaybethatRandomAccessFilehasessentiallydifferentbehaviorthantheotherIOtypes,sinceyoucanmoveforwardandbackwardwithinafileInanyevent,itstandsalone,asadirectdescendantofObjectEssentially,aRandomAccessFileworkslikeaDataInputStreampastedtogetherwithaDataOutputStream,alongwiththemethodsgetFilePointer()tofindoutwhereyouareinthefile,seek()tomovetoanewpointinthefile,andlength()todeterminethemaximumsizeofthefileInaddition,theconstructorsrequireasecondargument(identicaltofopen()inC)indicatingwhetheryouarejustrandomlyreading("r")orreadingandwriting("rw")There’snosupportforwriteonlyfiles,whichcouldsuggestthatRandomAccessFilemighthaveworkedwellifitwereinheritedfromDataInputStreamTheseekingmethodsareavailableonlyinRandomAccessFile,whichworksforfilesonlyBufferedInputStreamdoesallowyoutomark()aposition(whosevalueisheldinasingleinternalvariable)andreset()tothatposition,butthisislimitedandnotveryusefulTheFileclassBeforegettingintotheclassesthatactuallyreadandwritedatatostreams,we’lllookatalibraryutilitythatassistsyouwithfiledirectoryissuesTheFileclasshasadeceivingnameyoumightthinkitreferstoafile,butitdoesn’tInfact,"FilePath"wouldhavebeenabetternamefortheclassItcanrepresenteitherthenameofaparticularfileorthenamesofasetoffilesinadirectoryIfit’sasetoffiles,youcanaskforthatsetusingthelist()method,whichreturnsanarrayofStringItmakessensetoreturnanarrayratherthanoneoftheflexiblecontainerclasses,becausethenumberofelementsisfixed,andifyouwantadifferentdirectorylisting,youjustcreateadifferentFileobjectAdirectorylisterSupposeyou’dliketoseeadirectorylistingTheFileobjectcanbeusedintwowaysIfyoucalllist()withnoarguments,you’llgetthefulllistthattheFileobjectcontainsHowever,ifyouwantarestrictedlistforexample,ifyouwantallofthefileswithanextensionofJavathenyouusea"directoryfilter,"whichisaclassthattellshowtoselecttheFileobjectsfordisplayDirFilter’ssolereasonforexistenceistoprovidetheaccept()methodtothelist()methodsothatlist()can"callback"accept()todeterminewhichfilenamesshouldbeincludedinthelistThus,thisstructureisoftenreferredtoasacallbackMorespecifically,thisisanexampleoftheStrategydesignpattern,becauselist()implementsbasicfunctionality,andyouprovidetheStrategyintheformofaFilenameFilterinordertocompletethealgorithmnecessaryforlist()toprovideitsserviceBecauselist()takesaFilenameFilterobjectasitsargument,itmeansthatyoucanpassanobjectofanyclassthatimplementsFilenameFiltertochoose(evenatruntime)howthelist()methodwillbehaveThepurposeofaStrategyistoprovideflexibilityinthebehaviorofcodeTheaccept()methodmustacceptaFileobjectrepresentingthedirectorythataparticularfileisfoundin,andaStringcontainingthenameofthatfileRememberthatthelist()methodiscallingaccept()foreachofthefilenamesinthedirectoryobjecttoseewhichoneshouldbeincludedthisisindicatedbythebooleanresultreturnedbyaccept()外文翻译(中文)JavaIO系统“对语言设计人员来说创建好的输入,输出系统是一项特别困难的任务。”现有的大量不同方案已经说明了这一点。挑战似乎来自于要涵盖所有的可能性。不仅存在各种用于通信的IO源端和接收端(文件、控制台、网络连接等)而且还需要以多种不同的方式与它们通信(顺序、随机访问、二进制、字符、按行、按字等等)。Java库的设计者是通过创建大量类来攻克这个难题的。一开始可能对Java的IO系统提供了如此多的类而感到不知所措(具有讽刺意味的是javaIO设计的初衷是为了避免过多的类)。自从Java版本以来IO库的设计发生了显著的变化在原来面向字节的类中添加了面向字符和基于Unicode的类。在JDK中添加了nio类(对于“新IO”这个称呼从现在这个名字我们仍将要用若干年)用于改进性能及功能。因此在充分理解javaIO系统以便正确地用运之前我们需要学习相当数量的类。另外很有必要理解IO类库的演化过程即使我们的第一反应是“不要用历史打扰我只要告诉我怎么用。”问题是如果缺乏历史的眼光很快我们就会对什么时候该用某些类什么时候不该用他们而感到迷惑。输入和输出IO类库中通常使用“流(stream)”这个抽象概念它代表任何有能力产生数据的数据源对象或者是有能力接受数据的接收端对象。“流”屏蔽了实际的IO设备中处理数据的细节。可将Java库的IO类分割为输入与输出两个部分可以在JDK文档里的类层次结构中查看到。通过继承从InputStream(输入流)或Reader衍生的所有类都拥有名为read()的基本方法用于读取单个字节或者字节数组。类似地从OutputStream或Write()衍生的所有类都拥有基本方法write()用于写入单个字节或者字节数组。然而我们通常不会用到这些方法它们之所以存在是因为更复杂的类可以利用它们以便提供一个更有用的接口。因此我们很少用单个类创建自己的系统对象。相反我们会通过叠合多个对象来提供所期望的功能实际上Java中“流”类库让人迷惑的主要原因就在于:创建一个单一的结果流却需要创建多个对象。有必要按照功能对类进行分类。在Java中库的设计者首先决定与输入有关的所有类都从InputStream继承而与输出有关的所有类都从OutputStream继承。InputStream的类型InputStream的作用是标志那些从不同起源地产生输入的类。这些数据源包括:()字节数组()String对象()文件()“管道”它的工作原理与现实生活中的管道类似:将一些东西置入一端它们在另一端出来。()一系列其他流以便我们将其统一收集到单独一个流内。()其他数据源如Internet连接等。每一种数据源都有相应的InputStream子类。另外FilterInputStream也属于一种InputStream为“decorator”类提供基类其中“decorator”类可以把属性或者有用的接口与输入流连接在一起。OutputStream的类型这一类别包括的类决定了我们的输入往何处去:一个字节数组(但没有String假定我们可用字节数组创建一个)一个文件或者一个“管道”。除此以外FilterOutputStream为“修饰器(decor投入)”类提供了一个基础类它将属性或者有用的接口同输出流连接起来。增添属性和有用的接口利用层次化对象动态和透明地添加单个对象的能力的做法叫作“修饰器(Decorator)”方案。修饰器方案规定封装于初始化对象中的所有对象都拥有相同的接口以便利用装饰器的“透明”性质我们将相同的消息发给一个对象无论它是否已被“装饰”。这正是在JavaIO库里存在“过滤器”(Filter)类的原因。但是装饰器方案也有自己的一个缺点。在我们写一个程序的时候装饰器为我们提供了大得多的灵活性(因为可以方便地混合与匹配属性)但它们也使自己的代码变得更加复杂。原因在于JavaIO库操作不便我们必须创建许多类“核心”IO类型加上所有装饰器才能得到自己希望的单个IO对象。FilterInputStream和FilterOutputStream(这两个名字不十分直观)提供了相应的装饰器接口用于控制一个特定的输入流(InputStream)或者输出流(OutputStream)。它们分别是从InputStream和OutputStream衍生出来的。此外它们都属于抽象类在理论上为我们与一个流的不同通信手段都提供了一个通用的接口。事实上FilterInputStreamFilterOutputStream只是简单地模仿了自己的基础类它们是一个装饰器的基本要求。读和写Java对基本的IO“流”类库进行了重大的修改。当我们初次看见Reader和Writer类是可能会以为这是两个用来替代InputStream和OutputStream的类。但实际上并不是这样。尽管一些原始的“流”类库不再使用(如果使用它们则会收到编辑器的警告信息)但是InputStream和OutputStream在一面向字节形式的IO中仍可以提供极有价值的功能Reader和Writer则提供兼容Unicode与面向字符的IO的功能。另外:()Java向InputStream和OutputStream继承层次结构中添加了一些新类所以很明显在这些层次结构中的类是不会被取代的。()有时我们必须把来自于“字节”层次结构中的类和“字符”层次结构中的类结合起来使用。为了实现这个目的要用到“适配器(adapter)”类:InputStream可以把InputStream转换为ReaderOutputStreamWriter可以OutputStream转化为Writer。设计Reader和Writer继承层次结构主要是为了国际化。老的IO流继承层次结构支持为字节流并且不能很好地处理位的Unicode字符。既然Unicode是用来国际化的(Java本身的插入也是位的Unicode)因此添加Reader和Writer继承层次结构就是为了在所有的IO操作中都支持Unicode。另外新类库的设计使得它的操作比旧类库更快。标准IO“标准IO”这个术语参考的是Unix中“程序所使用的单一信息流”这个概念(在windows和其他许多操作系统中也有相似的实现)。程序的所有输入都可以来自于“标准输入”它的所有输出也都可以发送到“标准输出”以及所有的错误信息都可以发送到“标准错误”。标准IO的意义在于:我们可以很容易地把程序串联起来一个程序的标准输出可以成为另一个程序的标准输入。这真是一个强大的工具。从标准输入读取按照标准IO模型Java提供了SysteminSystemout和Systemerr。其中Systemout已经事先被包装成了printStream对象。Systemerr同样也是PrintStream但Systemin却是一个没有被包装的未经加工的InputStream。这意味尽管我们可以立即使用Systemout和Systemerr但是在读取Systemin之前必须对其进行包装。通常我们会使用readerLine()一次一行地读取输入因此我们会将Systemin包装成BufferedReader来使用。为此我们必须用InputStream把Systemin转换成Reader。标准IO重定向Java的System类提供一些简单的静态方法调用允许我们队标准输入、输出和错误IO流进行重定向:setIn(InputStream)setOut(PrintStream)setErr(PrintStream)如果我们突然开始在显示器上创建大量输出而这些输出滚动的如此之快一至于无法阅读时重定向输出就显得极为有用。对于“我们想重复测试特定用户的输入序列”的命令行程序来说重定向输入就是很有价值。新IOJDK的javanio*包中引入了Java新的IO类库其目的在于提高速度。实际上旧的IO包已经使用nio重新实现过以便充分利用这种速度提高因此即使我们不显式地用nio编写代码也能从中受益。速度的提高在文件IO和网络IO中都有可能发生。速度的提高来自于所使用的结构更接近于操作系统执行IO的方式:通道和缓冲器。我们可以把它想象成一个煤矿通道是一个包含煤层(数据)的矿藏而缓冲器则我们派送到矿藏的卡车。卡车载满煤炭而归我们再从卡车上获得煤炭。也就是说我们并没有直接和通道交互我们只是和缓冲器交互并把缓冲器派送到通道。通道要么从缓冲器获得数据要么向缓冲器发送数据。唯一直接与通道交互的缓冲器是ByteBuffer也就是说可以存储未加工字节的缓冲器。当我们查询JDK文档中的javanioByteBuffer时会发现它是相当基础的类:通过告知分配多少存储空间来创建一个ByteBuffer对象并且还有一个方法选择的集用于以未加工的字节形式或原始的数据类型输出和读取数据。但是没办法输出或读取对象即使是字符串对象也不行。这种处理虽然是低水平但却正好因为这是大多数操作系统中更有效的映射方式。旧IO类库中有三个类被改进了用以产生FileChannel它们是:FileInputStreamFileOutputStream以及用于既读又写的RandomAccessFile。注意这些是字节操纵流与低层的nio特性一致。Reader和Writer的字符模式类不能用于产生通道但是javaniochannelsChannels类能提供实用方法在通道中产生Reader和Writer。通过FilterInputStream从InputStream里读入数据FilterInputStream类要完成两件全然不同的事情。其中DataInputStream允许我们读取不同的基本类型数据以及String对象(所有方法都以“read”开头比如readByte()readFloat()等等)。伴随对应的DataOutputStream我们可通过数据“流”将基本类型的数据从一个地方搬到另一个地方。若读取块内的数据并自己进行解析就不需要用到DataInputStream。但在其他许多情况下我们一般都想用它对自己读入的数据进行自动格式化。剩下的类用于修改InputStream的内部行为方式:是否进行缓冲是否跟踪自己读入的数据行以及是否能够推回一个字符等等。后两种类看起来特别象提供对构建一个编译器的支持(换言之添加它们为了支持Java编译器的构建)所以在常规编程中一般都用不着它们。也许几乎每次都要缓冲自己的输入无论连接的是哪个IO设备。所以IO库最明智的做法就是将未缓冲输入作为一种特殊情况处理同时将缓冲输入接纳为标准做法。通过FilterOutputStream向OutputStream里写入数据与DataInputStream对应的是DataOutputStream后者对各个基本数据类型以及String对象进行格式化并将其置入一个数据“流”中以便任何机器上的DataInputStream都能正常地读取它们。所有方法都以“wirte”开头例如writeByte()writeFloat()等等。若想进行一些真正的格式化输出比如输出到控制台请使用PrintStream。利用它可以打印出所有基本数据类型以及String对象并可采用一种易于查看的格式。这与DataOutputStream正好相反后者的目标是将那些数据置入一个数据流中以便DataInputStream能够方便地重新构造它们。PrintStream内两个重要的方法是print()和println()。它们已进行了覆盖处理可打印出所有数据类型。print()和println()之间的差异是后者在操作完毕后会自动添加一个新行。BufferedOutputStream属于一种“修改器”用于指示数据流使用缓冲技术使自己不必每次都向流内物理性地写入数据。本身的缺陷:RandomAccessFileRandomAccessFile用于包含了已知长度记录的文件以便我们能用seek()从一条记录移至另一条然后读取或修改那些记录。各记录的长度并不一定相同只要知道它们有多大以及置于文件何处即可。首先我们有点难以相信RandomAccessFile不属于InputStream或者OutputStream分层结构的一部分。除了恰巧实现了DataInput以及DataOutput(这两者亦由DataInputStream和DataOutputStream实现)接口之外它们与那些分层结构并无什么关系。它甚至没有用到现有InputStream或OutputStream类的功能采用的是一个完全不相干的类。该类属于全新的设计含有自己的全部(大多数为固有)方法。之所以要这样做是因为RandomAccessFile拥有与其他IO类型完全不同的行为因为我们可在一个文件里向前或向后移动。不管在哪种情况下它都是独立运作的作为Object的一个“直接继承人”使用。从根本上说RandomAccessFile类似DataInputStream和DataOutputStream的联合使用。其中getFilePointer()用于了解当前在文件的什么地方seek()用于移至文件内的一个新地点而length()用于判断文件的最大长度。此外构建器要求使用另一个自变量(与C的fopen()完全一样)指出自己只是随机读("r")还是读写兼施("rw")。这里没有提供对“只写文件”的支持。也就是说假如是从DataInputStream继承的那么RandomAccessFile也有可能能很好地工作。很容易想象我们有时要在其他类型的数据流中搜索比如一个ByteArrayInputStream但搜索方法只有RandomAccessFile才会提供。而后者只能针对文件才能操作不能针对数据流操作。此时BufferedInputStream确实允许我们标记一个位置(使用mark()它的值容纳于单个内部变量中)并用reset()重设那个位置。但这些做法都存在限制并不是特别有用。File类File类有一个欺骗性的名字通常会认为它对付的是一个文件但实情并非如此。它既代表一个特定文件的名字也代表目录内一系列文件的名字。若代表一个文件集便可用list()方法查询这个集返回的是一个字串数组。之所以要返回一个数组而非某个灵活的集合类是因为元素的数量是固定的。而且若想得到一个不同的目录列表只需创建一个不同的File对象即可。事实上“FilePath”(文件路径)似乎是一个更好的名字。目录列表器现在假设我们想观看一个目录列表。可用两种方式列出File对象。若在不含自变量(参数)的情况下调用list()会获得File对象包含的一个完整列表。然而若想对这个列表进行某些限制就需要使用一个“目录过滤器”该类的作用是指出应如何选择File对象来完成显示。它指出这种类型的所有对象都提供了一个名为accept()的方法。之所以要创建这样的一个类背后的全部原因就是把accept()方法提供给list()方法使list()能够“回调”accept()从而判断应将哪些文件名算子”(也包括到列表中。因此通常将这种技术称为“回调”有时也称为“就是说DirFilter是一个算子因为它唯一的作用就是容纳一个方法)。由于list()采用一个FilenameFilter对象作为自己的自变量使用所以我们能传递实现了FilenameFilter的任何类的一个对象用它决定(甚至在运行期)list()方法的行为方式。回调的目的是在代码的行为上提供更大的灵活性。accept()方法必须接纳一个File对象用它指示用于寻找一个特定文件的目录并接纳一个String其中包含了要寻找之文件的名字。可决定使用或忽略这两个参数之一但有时至少要使用文件名。记住list()方法准备为目录对象中的每个文件名调用accept()核实哪个应包含在内具体由accept()返回的“布尔”结果决定

用户评价(0)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

文档小程序码

使用微信“扫一扫”扫码寻找文档

1

打开微信

2

扫描小程序码

3

发布寻找信息

4

等待寻找结果

我知道了
评分:

/22

外文翻译--Java IO 系统

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利