base64编码.docx - 冰豆网

资源描述

base64编码.docx

《base64编码.docx》由会员分享，可在线阅读，更多相关《base64编码.docx（16页珍藏版）》请在冰豆网上搜索。

base64编码.docx

base64编码

RFC3548-TheBase16,Base32,andBase64DataEncodings

faqs.org

RFC3548-TheBase16,Base32,andBase64DataEncodings

∙InternetRFCIndex

∙UsenetFAQIndex

∙OtherFAQs

∙Documents

∙Tools

∙Search

∙SearchFAQs

∙SearchRFCs

∙IFCHome

∙Cities

∙Countries

∙Hospitals

∙WebHostingRatings

窗体顶端

SearchtheRFCArchives

窗体底端

窗体顶端

OrDisplaythedocumentbynumber

窗体底端

NetworkWorkingGroupS.Josefsson,Ed.

RequestforComments:

3548July2003

Category:

Informational

TheBase16,Base32,andBase64DataEncodings

StatusofthisMemo

ThismemoprovidesinformationfortheInternetcommunity.Itdoes

notspecifyanInternetstandardofanykind.Distributionofthis

memoisunlimited.

CopyrightNotice

Abstract

Thisdocumentdescribesthecommonlyusedbase64,base32,andbase

16encodingschemes.Italsodiscussestheuseofline-feedsin

encodeddata,useofpaddinginencodeddata,useofnon-alphabet

charactersinencodeddata,anduseofdifferentencodingalphabets.

TableofContents

1.Introduction.........................2

2.Implementationdiscrepancies.................2

2.1.Linefeedsinencodeddata...............2

2.2.Paddingofencodeddata................3

2.3.Interpretationofnon-alphabetcharactersinencoded

data..........................3

2.4.Choosingthealphabet.................3

3.Base64Encoding.......................4

4.Base64EncodingwithURLandFilenameSafeAlphabet.....6

5.Base32Encoding.......................6

6.Base16Encoding.......................8

7.Illustrationsandexamples..................9

8.SecurityConsiderations...................10

9.References..........................11

9.1.NormativeReferences..................11

9.2.InformativeReferences.................11

10.Acknowledgements.......................11

11.Editor'sAddress.......................12

12.FullCopyrightStatement...................13

1.Introduction

Baseencodingofdataisusedinmanysituationstostoreortransfer

datainenvironmentsthat,perhapsforlegacyreasons,arerestricted

toonlyUS-ASCII[9]data.Baseencodingcanalsobeusedinnew

applicationsthatdonothavelegacyrestrictions,simplybecauseit

makesitpossibletomanipulateobjectswithtexteditors.

Inthepast,differentapplicationshavehaddifferentrequirements

andthussometimesimplementedbaseencodingsinslightlydifferent

ways.Today,protocolspecificationssometimesusebaseencodingsin

general,and"base64"inparticular,withoutaprecisedescriptionor

reference.MIME[3]isoftenusedasareferenceforbase64without

consideringtheconsequencesforline-wrappingornon-alphabet

characters.Thepurposeofthisspecificationistoestablishcommon

alphabetandencodingconsiderations.Thiswillhopefullyreduce

ambiguityinotherdocuments,leadingtobetterinteroperability.

Thekeywords"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT",

"SHOULD","SHOULDNOT","RECOMMENDED","MAY",and"OPTIONAL"inthis

documentaretobeinterpretedasdescribedinRFC2119[1].

2.Implementationdiscrepancies

Herewediscussthediscrepanciesbetweenbaseencoding

implementationsinthepast,andwhereappropriate,mandatea

specificrecommendedbehaviorforthefuture.

2.1.Linefeedsinencodeddata

MIME[3]isoftenusedasareferenceforbase64encoding.However,

MIMEdoesnotdefine"base64"perse,butrathera"base64

Content-Transfer-Encoding"forusewithinMIME.Assuch,MIME

enforcesalimitonlinelengthofbase64encodeddatato76

characters.MIMEinheritstheencodingfromPEM[2]statingitis

"virtuallyidentical",howeverPEMusesalinelengthof64

characters.TheMIMEandPEMlimitsarebothduetolimitswithin

SMTP.

ImplementationsMUSTNOTnotaddlinefeedstobaseencodeddata

unlessthespecificationreferringtothisdocumentexplicitly

directsbaseencoderstoaddlinefeedsafteraspecificnumberof

characters.

2.2.Paddingofencodeddata

Insomecircumstances,theuseofpadding（"="）inbaseencodeddata

isnotrequirednorused.Inthegeneralcase,whenassumptionson

sizeoftransporteddatacannotbemade,paddingisrequiredtoyield

correctdecodeddata.

ImplementationsMUSTincludeappropriatepadcharactersattheendof

encodeddataunlessthespecificationreferringtothisdocument

explicitlystatesotherwise.

2.3.Interpretationofnon-alphabetcharactersinencodeddata

Baseencodingsuseaspecific,reduced,alphabettoencodebinary

data.Nonalphabetcharacterscouldexistwithinbaseencodeddata,

causedbydatacorruptionorbydesign.Nonalphabetcharactersmay

beexploitedasa"covertchannel",wherenon-protocoldatacanbe

sentfornefariouspurposes.Nonalphabetcharactersmightalsobe

sentinordertoexploitimplementationerrorsleadingto,e.g.,

bufferoverflowattacks.

ImplementationsMUSTrejecttheencodingifitcontainscharacters

outsidethebasealphabetwheninterpretingbaseencodeddata,unless

thespecificationreferringtothisdocumentexplicitlystates

otherwise.Suchspecificationsmay,asMIMEdoes,insteadstatethat

charactersoutsidethebaseencodingalphabetshouldsimplybe

ignoredwheninterpretingdata（"beliberalinwhatyouaccept"）.

NotethatthismeansthatanyCRLFconstitute"nonalphabet

characters"andareignored.Furthermore,suchspecificationsmay

considerthepadcharacter,"=",asnotpartofthebasealphabet

untiltheendofthestring.Ifmorethantheallowednumberofpad

charactersarefoundattheendofthestring,e.g.,abase64string

terminatedwith"===",theexcesspadcharacterscouldbeignored.

2.4.Choosingthealphabet

Differentapplicationshavedifferentrequirementsonthecharacters

inthealphabet.Hereareafewrequirementsthatdeterminewhich

alphabetshouldbeused:

oHandledbyhumans.Characters"0","O"areeasilyinterchanged,

aswell"1","l"and"I".Inthebase32alphabetbelow,where0

（zero）and1（one）isnotpresent,adecodermayinterpret0as

O,and1asIorLdependingoncase.（However,bydefaultit

shouldnot,seeprevioussection.）

oEncodedintostructuresthatplaceotherrequirements.Forbase

16andbase32,thisdeterminestheuseofupper-orlowercase

alphabets.Forbase64,thenon-alphanumericcharacters（in

particular"/"）maybeproblematicinfilenamesandURLs.

oUsedasidentifiers.Certaincharacters,notably"+"and"/"in

thebase64alphabet,aretreatedasword-breaksbylegacytext

search/indextools.

Thereisnouniversallyacceptedalphabetthatfulfillsallthe

requirements.Inthisdocument,wedocumentandnamesomecurrently

usedalphabets.

3.Base64Encoding

Thefollowingdescriptionofbase64isdueto[2],[3],[4]and[5].

TheBase64encodingisdesignedtorepresentarbitrarysequencesof

octetsinaformthatrequirescasesensitivitybutneednotbe

humanlyreadable.

A65-charactersubsetofUS-ASCIIisused,enabling6bitstobe

representedperprintablecharacter.（Theextra65thcharacter,"=",

isusedtosignifyaspecialprocessingfunction.）

Theencodingprocessrepresents24-bitgroupsofinputbitsasoutput

stringsof4encodedcharacters.Proceedingfromlefttoright,a

24-bitinputgroupisformedbyconcatenating38-bitinputgroups.

These24bitsarethentreatedas4concatenated6-bitgroups,each

ofwhichistranslatedintoasingledigitinthebase64alphabet.

Each6-bitgroupisusedasanindexintoanarrayof64printable

characters.Thecharacterreferencedbytheindexisplacedinthe

outputstring.

Table1:

TheBase64Alphabet

ValueEncodingValueEncodingValueEncodingValueEncoding

0A17R34i51z

1B18S35j520

2C19T36k531

3D20U37l542

4E21V38m553

5F22W39n564

6G23X40o575

7H24Y41p586

8I25Z42q597

9J26a43r608

10K27b44s619

11L28c45t62+

12M29d46u63/

13N30e47v

14O31f48w（pad）=

15P32g49x

16Q33h50y

Specialprocessingisperformediffewerthan24bitsareavailable

attheendofthedatabeingencoded.Afullencodingquantumis

alwayscompletedattheendofaquantity.Whenfewerthan24input

bitsareavailableinaninputgroup,zerobitsareadded（onthe

right）toformanintegralnumberof6-bitgroups.Paddingatthe

endofthedataisperformedusingthe'='character.Sinceallbase

64inputisanintegralnumberofoctets,onlythefollowingcases

canarise:

（1）thefinalquantumofencodinginputisanintegralmultipleof24

bits;here,thefinalunitofencodedoutputwillbeanintegral

multipleof4characterswithno"="padding,

（2）thefinalquantumofencodinginputisexactly8bits;here,the

finalunitofencodedoutputwillbetwocharactersfollowedbytwo

"="paddingcharacters,or

（3）thefinalquantumofencodinginputisexactly16bits;here,the

finalunitofencodedoutputwillbethreecharactersfollowedbyone

"="paddingcharacter.

4.Base64EncodingwithURLandFilenameSafeAlphabet

TheBase64encodingwithanU

展开阅读全文