金融行业密钥详解(转)

本文来源:http://blog.csdn.net/lysheng/article/details/395480 刘永胜 2005年6月于深圳 金融行业因为对数据比较敏感,所以对数据的加密也相应的比较重视。在其中有关密钥及加密方面的文章很少,并且散发在各个银行及公司的手中,在网上没有专门对这部分进行介绍的。本文对金融行业的密钥进行较深入的介绍,包括象到底什么是主密钥(MasterKey)、传输密钥(MacKey),为什么我们需要这些东西等。 本文采取追源溯本的方式,力求让对这感兴趣的人达到知其然,同时也知其所以然,而不是模模糊糊的知道几个概念和名词。因为本文主要是针对对金融行业密钥不是很熟悉的人,所以如果你对密钥很熟悉就不必仔细看了。 好了,咱们言规正传。我们知道,金融行业有很多数据要在网络上传递,包括从前置到主机,从自助终端到前置等,这些数据在网络上传来传去,我们很容易就会想到安全性的问题,如果这些数据被人窃取或拦截下来,那我们怎么敢在银行存钱了。这个问题在计算机出现时就被前人考虑到了,所以出现了很多各种各样的加解密技术。 抛开这些不管,假设当初由我们自己来设计怎样解决数据被窃取的情况。假设我们有一段数据,是ATM取款的报文,包括一个人的磁卡号、密码、取款金额,现在需要将这些数据从一台ATM机器传到前置机处理,这些数据是比较机密的,如果被人窃取了,就可以用该卡号和密码把帐户中的钱取走。 首先,我们可以想到用专用的银行内部网络,外面的人无法获得网络的访问权。这个仔细想想显然不可行的,因为一是不能保证外人一定没办法进入银行内部网络,二是银行内部人员作案是没法防止的。 接着,我们很容易想到,既然保证数据不被窃取的可能性很小,那我们何不变换一下思路,数据避免不了被窃取,那我如果将数据处理下,让你即使窃取到数据,也是一些无用的乱码,这样不就解决问题了吗。这个想法比较接近现在的做法了,当前置机接收到了数据,它肯定是对数据进行反处理,即与ATM端完全步骤相反的数据处理,即可得到明文的数据。我们再进一步想想,如果因为某种原因,报文中的取款金额被改变了,这样就会导致ATM出的钱和前置扣帐记录的钱不一致的情况,看来我们必须加上一个验证机制,当前置机收到ATM发送的一个报文时,能够确认报文中的数据在网络传输过程中没有被更改过。 怎样实现?最简单的,象计算机串口通讯一样,对通讯数据每一位进行异或,得到0或1,把0或1放在在通讯数据后面,算是加上一个奇偶校验位,收到数据同样对数据每位进行异或,得到0或1,再判断下收到数据最后一位与算出来的是否一致。这种方式太简单了,对于上面提到的ATM到前置机的报文来说,没什么用处,不过我们可以将对数据每一位异或的算法改成一个比较复杂点的。 因为DES算法已经出来了很多年了,并且在金融行业也有广泛的应用,我们何不用DES算法进行处理,来解决上面的问题呢。我们应该了解DES算法(此处指单DES)的,就是用一个64bit 的Key对64bit的数据进行处理,得到加密后的64bit数据。那我们用一个Key对上面的报文进行DES算法,得到加密后的64bit数据,放到报文的最后,跟报文一起送到前置机,前置机收到报文后,同样用Key对数据(不包括最后的64bit加密数据)进行DES加密,得出64bit的数据,用该数据与ATM发送过来的报文最后的64bit数据比较,如果两个数据相同,说明报文没有中途被更改过。 再进一步,因为DES只能够对64bit的数据进行加密,一个报文可不止64bit,哪我们怎么处理呢?只对报文开头的64bit加密?这个是显然不够的。 我们可以这样,先对报文的开始64bit加密,接着对报文第二个64bit加密,依次类推,不过这有问题,因为每个64bit都会得到同样长度的加密后的数据,我不能把这些数据都放到报文的后面,那报文的长度不变成两倍长了。换个思路,我先对报文第一个64bit加密,得到64bit的加密后数据data1,接着再拿加密后的data1与报文第二个64bit数据进行按位异或,得到同样长64bit的数据data2,我再用Key对data2加密,得到加密后的数据data3,再拿data3与报文第三个64bit数据进行按位异或,同样的处理依次类推。直到最后会得到一个64bit的数据,将这个数据放到报文的最后发到前置机,这样报文的长度只增加了64bit而已。这个算法就叫做MAC算法。 好了,到目前为止我们已经知道了什么是MAC算法,为什么需要它,接着我们再看看经常被提起的另外一个名词。在上面说到MAC算法的时候,我们会注意到其中进行DES加密算法时提到了一个Key,这个用来参与MAC计算的Key就常被称为MacKey,也有叫工作密钥、过程密钥的。 我们继续来处理ATM和前置机间网络数据传输的问题。前面提到的MAC算法对传送的报文进行了处理,保证了在网络传输过程中数据不会被有意或无意的篡改,但是,我们再进一步想想,如果仍然是上面提到的一个取款报文,如果想作案的话,我不改报文的内容,我只是截取报文的内容,因为内容里面有卡号和密码,都是明文的形式,很容易就看出来哪些内容是卡号、哪些内容是密码。有了卡号和密码,我就好办了,找个读卡器就能够很快的制出一张磁卡,然后拿这个磁卡可以随便取钱了,根本不需要修改报文,这样你就算前置机对报文的MAC校验通过了,也只是保证了报文没改动过,对于防止作案没有实质上的帮助。 那我们很容易想到,我再加上一道加密,这次我把整个存款的报文都用DES加密,将明文全部转换成密文,然后送到前置机,这下好了吧。即使你把报文截取了也没用,你拿着这些密文也没有用,你也没有DES的密钥来解密它,只有前置机才知道密钥。这是个好主意,确实防止了卡号和密码等被人获知的危险。这也是现在普遍采取的做法,不过我们需要对这个做法进行一些改进。 首先,我们要知道用DES对数据加解密是耗时间的,尤其是使用硬加密(下一步讲什么是硬加密)的情况,速度是比较慢的。我们来想想,整个存款报文有必要每个数据都DES加密吗,象报文中的什么流水号、ATM号等信息,对它们加密没什么意义,进一步讲,取款金额加密也没意义,假设你取500块,但是你将报文改成了100块,导致主机只把你帐户扣100块钱,你白赚了400块。这个听起来挺划算的,实际上是不可行的,因为这样造成了帐务上的短款,银行当然会查账的,根据ATM记录的硬件出钞张数和主机扣款金额,肯定会把你查出来的,那这种掩耳盗铃的做法,下场显而易见,想必没人这么傻。 我们来考虑一个报文中到底什么信息是需要加密的,目前一般的做法是只对帐号和密码(也有只对密码加密的)进行加密,其他的内容不加密的,明文就明文,没什么大不了的。对帐号和密码加密有个术语,我们可能都听说过,叫PinBlock,即PIN块,就是对帐号和密码进行DES加密处理后的一个密文数据块。即然使用了DES算法来加密帐号和密码,则必然有个Key来加密,那么我们就把这个Key称为PinKey,就是专门来加密用户帐户和密码的Key。 至于怎样进行加密形成最后的密文PinBlock,有很多标准的,象IBM3624、ANSI、ISO、DIEBOLD等标准,其实它们大同小异,就是在对报文中的密码进行一个预处理,再用PinKey来DES加密,主要的差别就是怎样预处理而已,比如有的是密码后面补F,补够16位,就是类似这样的预处理。 到这里我们应该理解PinKey和PinBlock了。通过PinKey和MacKey对报文进行了两重处理,基本上报文就是安全的了。如果我们对DES算法比较了解,就会知道,如果想对加密后的密文解密,必须要知道Key才行,所以说Key一定要保密。怎样来保密Key呢?我们前面提到的无论是算MAC还是算PIN块,都是直接拿明文的Key来计算的,那么这个Key很容易被窃取的,比如有人在机器上装了个黑客程序,只要检测到你在用Key加密数据,就把明文的Key获取了。这个听起来好像挺玄乎的,不过是有这个可能性的,尤其是网上银行这些东东最容易中招了。 这样看来,我们还要对PinKey和MacKey本身进行加密,不要让人知道了。怎样实现,同样是DES算法大显身手的地方。我再找个Key对PinKey和MacKey进行一次加密,这样你就看不到PinKey和MacKey的明文了,好,解决问题了。这时用来对PinKey和MacKey进行加密的Key就被我们称为MasterKey,即主密钥,用来加密其他密钥的密钥。不过,需要等一下,那MasterKey怎么办,它是明文啊。再找个Key来加密MasterKey,那最终无论处理多少道,最后的那个Key肯定是明文,这样看来,安全的问题还没有解决啊。 既然此路不通,那我们需要换个思维角度了,仔细想想怎样处理明文的MasterKey。黑客程序只能窃取我软件上的东西,如果我把MasterKey放到硬件里面怎么样,黑客是没能力跑到我硬件里面把MasterKey取出来的,当然,不排除道高一尺、魔高一丈的情况,但至少99.9%的黑客都没这能力的。那这样不就解决了我们遇到的问题了吗,只要把MasterKey放到硬件里面(一般是键盘的加密模块里面)就好了。 好,到这里,我们已经不怕有人把报文中的关键信息获取到了,总算是安全了。 在最近,老是有人提到“硬加密”,这个有什么用呢?我上面不是已经解决了加密的问题了吗,还要这个概念干什么?看来我还是有些地方没考虑到。我一直想的是将明文的密码加密成密文,其中有个环节需要考虑下,明文的密码是怎样形成的,不就是我按键盘上面的数字形成的吗。以前我的软件处理是这样的,键盘每按一下,我就把那个数字在程序里面先存起来,等到4位或6位密码按完后,再把它们合在一起,再送给PinKey加密。那如果黑客程序直接把我的按键信息获取,那他根本不用破解报文中用PinKey加密后的密码,直接简单的就把我输入的密码得到了,我前面费尽心思对密码进行加密处理变得一点意义都没有了。 怎么办?如果我把获取按键的程序固化进入加密硬件(一般在键盘中),按键的数字根本不通过上层的软件,直接一步进入硬件里面处理,等到按键按完了后,硬件直接把经过一道处理的按键信息给我上层软件,此时已经是密文了,就相当于把前面计算PinBlock的处理移到硬件里面去了,那黑客就没法获取我的按键了。这种处理现在就被称为硬加密,伴随着EMV和3DES算法,变得越来越流行了,好像自助终端不支持硬加密就不行,连EMV也强制要求了。 最近还有个名词经常被提到,就是3DES。为什么要提出3DES的概念呢?我在一篇文章中提到了3 DES的具体算法,其实推出3DES是因为原来的单DES算法随着计算机硬件的速度提升,存在被破解的可能性,所以将算法进行了改进,改为3DES算法。但是对于我们理解金融行业的密钥及加密机制来说,用什么算法都一样。不同算法的差别只是怎样对数据进行移位变换等具体处理而已。 现在我们应该对金融行业用到的有关密钥方面的知识有了较清晰的认识,至于具体更加详细的相关问题,我们以后再讨论。 全文完

全面掌握ISO8583报文协议(转)

来源于:http://blog.csdn.net/lysheng/article/details/412724 刘永胜 2005年于广州 我刚进入金融行业时,就知道了IS08583报文协议,我想可能我还没进入这个行业都已经听过了,可知ISO8583的影响力有多大了。最初刚接触它时,确实对其中的一些细节概念不是很清晰,对有些地方比较迷惑。鉴于此,我想很多同行也必然会经历同样得阶段,所以我写下本文,以便大家能够少走一些弯路。同时,我在网上(http://blog.csdn.net/lysheng/archive/2005/03/03/309914.aspx)写下我要写“全面掌握ISO8583报文”和“符合CEN/XFS(即WOSA/XFS)规范的SP编写”两篇文章时,很多人都询问我什么时候能够写出来,可知许多人是需要了解这方面的知识的,即使我时间不是很多,也得尽量将这两篇文章写出来,给需要的人提供一些参考。 如果单纯的讲IS08583那些字段的定义,我觉得没有什么意思,标准中已经对每个字段解释的非常详细了,如果你觉得理解英文版的ISO8583规范有些困难,网上也有同行为我们翻译好的中文版ISO8583规范,所以我的目的是达到阅读本文后能够对ISO8583知其然,亦知其所以然,使以前基本没有接触它的人也能够达到掌握ISO8583报文规范。 好了,我们该转入正题了。 最开始时,金融系统只有IBM这些大的公司来提供设备,象各种主机与终端等。在各个计算机设备之间,需要交换数据。我们知道数据是通过网络来传送的,而在网络上传送的数据都是基于0或1这样的二进制数据,如果没有对数据进行编码,则这些数据没有人能够理解,属于没有用的数据。起初的X.25、SDLC以及现在流行的TCP/IP网络协议都提供底层的通讯编码协议,它们解决了最底层的通讯问题,能够将一串字符从一个地方传送到另一个地方。但是,仅仅传送字符串是没有太大意义的,怎样来解析字符串代表什么内容是非常重要的,否则传送一些“0123abcd”的字符串也是无用的乱码。 让我们随着时光回到几十年前的某个时刻,假设我们被推到历史的舞台上,由我们来设计一个通用报文协议,来解决金融系统之间的报文交换,暂且称该协议叫做ISO8583协议。此时,技术是在不断的前行,当初IBM一支独秀的局面好像已经不妙了,各种大小不一的公司都进入金融行业以求能有所斩获,呈一片百花齐放的局面。我们怎样来设计一个报文协议,能够将这些如雨后春笋般出现的所有公司都纳入进来,其实也不是一件很简单的事。 我们还是先一步步的来考虑吧。金融行业其实涉及到的数据内容并不是成千上万,无法统计,恰恰相反,是比较少的。我们都可以在心底数得过来,象交易类型、帐号、帐户类型、密码、交易金额、交易手续费、日期时间、商户代码、2磁3磁数据、交易序列号等,把所有能够总结出来的都总结起来不过100个左右的数据。那我们可以首先简单的设计ISO8583,定义128个字段,将所有能够考虑到的类似上面提到的“帐号”等金融数据类型,按照一个顺序排起来,分别对应128个字段中的一个字段。每个数据类型占固定的长度,这个顺序和长度我们都事先定义好。这样就简单了,要发送一个报文时,就将128个字段按照顺序接起来,然后将接起来的整串数据包发送出去。 任何金融软件收到ISO8583包后,直接按照我们定义的规范解包即可,因为整个报文的128个字段从哪一位到哪一位代表什么,大家都知道,只要知道你的数据包是ISO8583包即可,我们都已经定义好了。比如第1个字段是“交易类型”,长度为4位,第2个字段位是“帐号”,为19位等等。接收方就可以先取4位,再取接着的19位,依次类推,直到整个数据包128个字段都解完为止。 其实这种做法真是简单直接,基本上就可以满足需要了。不过我们有几个问题要思考下: 1、 我怎么知道每个字段的数据类型呢,是数字还是字符? 2、 每个传送的报文都把128个字段都传过去,那网络带宽能够承受得了,有时候我可能只需要其中5个字段,结果多收到了123个无用的字段。 3、 如果我某些字段的长度不固定,属于变长怎么办,因为你现在解包是当作数据包每个字段都是固定的,用C语言解包时直接依靠指针取固定长度的一串字符做为一个字段。 我们来一一解决这些问题。 第一个问题简单,我在定义ISO8583时除了定义每个字段表示什么,还规定其内容是数字或是字符等即可。考虑可能出现的类型不过有以下几种:字母、数字、特殊字符、年月日等时间、二进制数据。比如我对128个字段中的“商户类型”字段定义其长度是15,同时定义其类型为字母。再精细点,如果“商户类型”里面的数据同时包括数字和字母呢?那我们就定义其类型为字母也可,为数字也可,即一个字段可以同时属于多个类型。 第二个问题稍微复杂点。其本质就是如果我只传128个字段的5个字段,接收方怎么知道我传了哪几个字段给它了。要是我们把剩下的123全部填成0或其他特殊标识,标明该字段不需要使用?这种处理方法没有半点用处,没有解决网络带宽的本质问题,还是要传128个字段。 换个思路,我在报文前面加上个包头,包头里面包含的信息能够让别人知道只传了5个字段。怎样设计这个包头,可以这样,我们用16个字节,即128个bit(一个字节等于8bit)来表示128个字段中的某个字段是否存在。每个bit在计算机的二进制里面不是1就是0,如果是1就表示对应的字段在本次报文中存在,如果是0就是不存在。这样好了,如果别人接收到了ISO8583报文,可以先根据最前面的报文头,就知道紧接着报文头后面的报文有哪些字段,没有哪些字段了。比如,我要发送5个字段,分别属于128个字段中的第2、3、6、8、9字段,我就可以将128bit的报文头填成011001011000000000………..,一共128个bit,后面就全是0了。注意其中第2、3、6、8、9位为1,其他都为0。 有了这个128bit的报文头,我们就可以只发送需要的5个字段了。怎样组织报文?先放上这128bit,即16个字节的头,然后在头后面放2、3、6、8、9字段,这些字段紧挨在一起,3和6之间也不需要填上4、5这两个字段了。接收方收到这个报文,它会根据128bit的报文头来解包,它自然知道把第3个字段取出后,就直接在第3字段的后面取第6个字段,每个字段的长度在ISO8583里面都定义好了,很轻松就把数据包解出来了。 这下好了,为了解决上面的第二问题,我们只是在报文中增加了16个字节的数据,就轻松搞定了,我们把这16个字节称为bit map,即位图,用来表示某个位是否存在。不过我们再稍微优化一下,考虑到很多时候报文不需要128个字段这么多,其一半64个字段都不一定能够用完。那我可以将报文头由128bit减到64bit,只有在需要的时候才把剩下的64bit放到报文里面,这样报文长度不又少了8个字节吗? 是个好主意。我们把ISO8583的128个字段中最常见的都放到前64个字段中,那我们可以将处理缩小一倍。这样我一般发送报文时只需发送64bit,即一个字节的报文头,再加上需要的几个字段就可以了。如果有些报文用到64到128之间的字段呢?这个也好办,我把64bit报文头的第一位bit用来代表特殊含义,如果该bit为1,则表示64bit后面跟了剩下的64bit报文头;如果第一位bit为0,则表示64bit后面没有跟剩下的64bit报文头,直接是128个字段中的报文了。那们,接收方会判断一下报头的第一个bit是1还是0,从而知道报文头是64bit还是128bit了,就可以做相应处理。因为报文头第二个64bit属于有时候有,所以我们叫它Extended bit map扩展位图,相应的报文头最开始的64bit我们叫它Primary bit map主位图。我们直接把扩展位图固定放到128个字段的第一个字段,而主位图每个数据包都有,就强制性放在所有128个字段的前面,并不归入128个字段中去。 第三个问题可以考虑这样解决。比如第2个字段是“帐号”,是不定长的,可能有的银行帐号是19位,有的是17位等。我们定ISO8583规范时可以规定第2个字段是25位,这下足够将19和17的情况都包含进来,但是如果以后出现了30位的怎么办?那我们现在将字段定为100位。以后超过100位怎么办,况且如果你只有19位的帐号,我们定义了100位,那81位的数据不是浪费了网络的带宽。看来预先定义一个我们认为比较大的位数是不太好的。 我们这样,对于第2个字段“帐号”,在字段的开头加上“帐号”的长度。比如帐号是0123456789,一共10位,我们变成100123456789,注意前面多了个10,表示后面的10位为帐号。如果你接触过COM里面的BSTR,应该对这种处理比较熟悉了。接收方收到该字段后,它知道ISO8583规定第2个字段“帐号”是变长的,所以会先取前面的2位出来,获取其值,此时为长度,然后根据该长度值知道应该拷贝该字段后面哪几位数据,才是真正的帐号。如果你觉得长度如果只有两位最多只能表示99位长,不太够,我们也定义可以允许前面3位都为长度的变长字段,这样就有999位长,应该够了吧。在规范里面如果我定义某个字段的属性是“LLVAR”,你注意了,其中的LL表示长度,VAR表示后面的数据,两个LL表示两位长,最大是99,如果是三位就是“LLLVAR”,最大是999。这样看我们定义的ISO8583规范文档时直接根据这几个字母就理解某个变长字段的意思了。 该解决的几个问题到这里都解决了,我们来回顾下自己设计的ISO8583规范。其实没有什么,无非是把金融行业可能出现的数据分门别类,排好顺序,接着把它们连接起来,组成一个报文发送出去而已。其中针对该报文的设计进行了一些优化,引入了bit map位图的概念,也算是一个不错的想法。 剩下的工作就简单了,我们就直接收集金融行业可能出现的数据字段类型,分成128个字段类型,如果没有到128个这么多就先保留一些下来,另外考虑到有些人有特殊的要求,我们规定可以将128个字段中的几个字段你自己来定义其内容,也算是一种扩展了。 这样,最后我们就得到了ISO8583规范的那张字段描述表了。想要详细的知道每个字段的含义直接对着表看就可以,比较简单。

ISO8583规范说明

ISO8583接口的详细资料   ISO8583包(简称8583包)是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,并有定长与变长之分。8583包前面一段为位图,用来确定包的字段域组成情况。其中位图是8583包的灵魂,它是打包解包确定字段域的关键,而了解每个字段域的属性则是填写数据的基础。   1、 位图描述如下:   位图位置:1   格式:定长   类型:B16(二进制16位,16*8=128bit)   描述:   如将位图的第一位设为’1′,表示使用扩展位图(128个域),否则表示只使用基本位图(64个域)。   如使用某数据域,应在位图中将相应的位设位’1′,如使用41域,需将位图的41位设为’1′。   选用条件:如使用65到128域,需设位图域第一位为’1′   2、每个域的定义如下:   typedef struct ISO8583   {     int   bit_flag;      /*域数据类型0 — string, 1 — int, 2 — binary*/     char  *data_name;     /*域名*/     int   length;       /*数据域长度*/     int   length_in_byte;   /*实际长度(如果是变长)*/     int   variable_flag;   /*是否变长标志0:否 2:2位变长, 3:3位变长*/     int   datatyp;      /*0 — string, 1 — int, 2 — binary*/     char  *data;       /*存放具体值*/     int   attribute;     /*保留*/   } ISO8583;      [...]

人才与企业

企业之所以存在,就是因为有了一班员工,企业凝聚着这班员工的力量,就好像拔河比赛,如果每位员工出力的方向一致,目标一致,这个企业就能得到快速的上升。但一旦这个凝聚力向四面八方散发,那就意味着这个企业开始走下波路了。这个凝聚力是越滚也大,还是逐渐消失在灰烟之中,就要看这个企业的管理了。所以一个企业的成功与失败不是因为某个强人的存在与离开,而且要看这个团队的力量,如果团队都散开了,意味着企业快走到尽头了。 在企业里什么类型的人都有,为了方便管理需要把岗位划分等级,虽然在职位上有高低之分,但在工种上没贵贱之分。群龙不能无首,但首多了就容易引起派别,权位之争。中国上下5000年,哪个朝代不是因为内部的权利斗争而走向衰落。企业的发展离不开人才。怎么才是人才,每个人都有长处与短处,如果这个人的长处能够在这个企业中发挥出来,那这个人就是这个企业的人才。一旦这个员工的长处在此平台不能发挥,或者因为某种原因而受到限制,就算最好的人才也变为废物。公司与人才是相辅相成的,当双方目标一致,利益一致的时候才能达到双赢的效果,就像2个一致的齿轮,互相卡住转动。虽然公司不会因为某个人的离开而倒闭,离开的人也不会因为离开了这个公司而失业。但如果人员流动频率过高,是不是该反思、反思。得道多助 失道寡助,企业的人才都流失了,肯定是因为某个环节出了问题。进进出出,凝聚力会越来越薄弱了。一个失望,两个失望,三个失望,引起群体效应,都失望了。 古云说:“人才难得,得人才者得天下”。眼睁睁地看着自己的得力下属一个一个的离开,而自己无能为力,真是悲哀啊。无耐、无助、无语啊。为了省那几百块钱而丢失了几千块钱,小学生都明白的道理,咋我就想不明白呢!自责无能。 以上是孤叶的不才之见!

Quartz时间格式

字段 允许值 允许的特殊字符 秒 0-59 , – * / 分 0-59 , – * / 小时 0-23 , – * / 日期 1-31 , – * ? / L W C 月份 1-12 或者 JAN-DEC , – * / 星期 1-7 或者 SUN-SAT , – * ? / L C # 年(可选) 留空, 1970-2099 , [...]

win7启动文件参数修改(bcdedit.exe)

Vista之前的系统,修改启动文件是在C盘下的boot.ini文件,Vista之后(包括win7)修改启动文件是用windows/system32/bcdedit.exe来修改,windows/system32/bcdedit.exe需要管理者身份才能运行,右击开始附件中的命令提示符,选择“以管理者身份运行”才可使用,自己的电脑上装有win7,运行结果如下: Microsoft Windows [版本 6.1.7600] 版权所有 (c) 2009 Microsoft Corporation。保留所有权利。 C:\Windows\system32>bcdedit.exe Windows 启动管理器 ——————– 标识符 {bootmgr} device partition=C: description Windows Boot Manager locale zh-CN inherit {globalsettings} default {current} resumeobject {4ea87a30-b6de-11de-b0bc-bf1d12f13d12} displayorder {current} toolsdisplayorder {memdiag} timeout 30 Windows 启动加载器——————————从这里开始是我们装的系统 ——————- 标识符 {current} device partition=C: path \Windows\system32\winload.exe description Windows 7———————–我现在使用的是win7 locale zh-CN inherit {bootloadersettings} recoverysequence {4ea87a32-b6de-11de-b0bc-bf1d12f13d12} recoveryenabled [...]

20110624-25大丹霞山

大丹霞山精华路线 时间:2011年6月24日-25日 18人参与:车厘子(领队),孤叶,闲庭,流星,大傻,黄蓉,旺仔,阿达,小玲,小娟,赵敏,静怡,乐乐吉,将军,将军夫人,小伍,阿司匹林(财务),老王 路线:广州包车到韶关–白泥棼–东坑迳水库(营地)–巴寨–东坑迳水库–五仙岩–牛鼻村 中国红石公园——丹霞山,位于韶关市境内,面积290平方千米,是广东省面积最大、景色最美的风景区。1988年以来,丹霞山分别被评为国家风景名胜区、国家级地质地貌自然保护区、国家AAAA级旅游区、国家地质公园、世界地质公园。 丹霞山是世界“丹霞地貌”命名地。丹霞山由680多座顶平、身陡、麓缓的红色砂砾岩石构成,“色如渥丹,灿若明霞”,以赤壁丹崖为特色。据地质学家研究表明:在世界已发现1200多处丹霞地貌中,丹霞山是发育最典型、类型最齐全、造型最丰富、景色最优美的丹霞地貌集中分布区。 下图是大丹霞山的穿越图,我们这次只去精华部分:东坑迳水库、巴寨、五仙岩,轻装冲顶难度不高。 25号早上8点半岗顶C出口集合,根据车车姐的规定,阿司匹林荣幸地当上了我们的财务,并且给我们每人奖励了1个雪条。整队18个人,一部别克商务车,另外一部金杯面包,由于需要露营,车被大包包与人急得满满的。 一路狂奔,大概1点多钟我们到了仁化吃饭。吃饭的时候正好来了一阵及时雨,把蒸笼一般的热量带走了。雨过天晴后我们继续上路,在2点多的时候来到了白泥棼村。车车姐对白泥棼村里非常熟悉,认识了一户村民彭大哥家。尝过无比酸的彭哥李子,品过山水泡的铁观音,抓了5只走地鸡。一路往北走,由于是黄泥天基路,怕车托底,我们全体徒步上去(车把我们的装备拉上去),大约20分钟就到了东坑迳水库。 在东坑迳水库稍作休息15分钟,准备一些冲顶的东西,背了3个西瓜,全体队员立志冲上巴寨。下图是我们出发前的合照。登山杖指的方向就是巴寨。 巴寨的上山路口比较隐蔽,过了水库边有一条直升的小路上去,据说会快很多。我们没有走大路,直接冲进树林中。 在上巴寨的路上,土路+树荫 像不像进洞啊,绿树成荫 走到快到顶的时候,就变为楼梯了,楼梯是从岩石边琢出来的 一段上波路,大家都显得有点吃力 这个就是我啦,在快到顶上拍照留念 巴寨对面的茶壶峰,清晰吧!像不像茶壶呢? 开瓜拉,我们背了3个西瓜上来 岩石封顶,不敢大声喧哗,怕蹦了。 据说是棍棍的旁系,真正的棍棍在丹霞主峰 从巴寨山上看下去,我们上山前的那个水库 五星级的营地吧,唯一缺点就是要自己背淡水上去 偶遇刚才营地的人,原来是大有来历的,CCTV 将要下雨了,烟雾尼曼,有拍西游记的感觉 这个就是我们刚才上去的巴寨,壮观吧 开炉煮饭了,我们的晚餐–炒鸡肉 这锅老火汤鸡汤很强啊,很抢手。 这位同志偷吃,被我逮住了,以此为证 开餐了,够腐败吧,4只鸡,牛肉,青菜,豆角等,还有老火靓汤 清晨的水库,我们露营的地方 早餐—白米绿豆粥 这是我们五星级的营地,背山面向,好风水 这是我的窝,还蛮有型的 老巢被掘开了皮了,窝里都被曝光了 独自垂钓的老王 工具就是这样被发明的,猿人啊! 不负众望,老王终于搞了一条上来,不小呢,3斤吧–水库草鱼 从下面角度看的五仙岩,今天的任务就是征服它,小case啦 上五仙岩的路上,树林茂密吧 这个很像美女的哪个部位?大家慢慢品尝 灌木丛中 远眺,天气还不错吧 滴水谈,可惜被我们污染了 这个就是五仙岩顶,那是个尼姑庵,可惜上去后没见到尼姑 看到对面,昨天我们冲顶的地方了,巴寨与茶壶峰共舞 上顶上的水潭,淡水源啊。 这个就是尼姑庵了。没人 很特殊的厕所,估计是给尼姑用的,我们?向来都是唱山歌的啦 无公害菜园,纯天然 将军下陡梯 蓝天白云,我很久没见过那么晴的天了。心情开朗 路上拍的,不知道是啥峰 路上的风景不错吧 一片草丛,绿油油的,很有感觉。 草丛里是沼泽地,我们在中间穿过的地方有三根竹子垫住,踩上去软软的 [...]

想写点咩,但又不想写点咩

心烦意乱,内心矛盾。 或许是不顺,或许是压力,或许是疲惫。 自己也说不清楚,总之乱糟糟的。 上班开会、下班开会,越开越慌张。 摸不清,看不见,路在何方,你、我都不知道。 遍地撒网的代价太高了,还有多少个百万可以烧。 思考、需要静静的思考,需要一个平心静气的地方思考,才能透过表面看清事实的真相。 淡定、镇定、从容地面对,这样的日子终是会过去的。

《1988》后感

       用了3天时间读完了期待了很久的韩寒《1988》。感觉比较失望,并没有传说中的那么神,它毕竟是一本小说,人物与事件的描述。看完后心情很平淡,但带有几分悲伤,同情小说中的娜娜,我们都同在一个社会上生活的人。为社会、为下一代所付出,真实的反应了在生活中挣扎的“某一类群体”,“有头发边个想做癞痢啊”。       这本书,我个人觉得写得很一般,并没有给我什么深刻的体会与教训,我也没有从中领会到什么高层次的精华,也没有热血沸腾的感觉。总的来说,当做是小说来看,还行吧。或许是一开始对他的期望值太高了!

expdp-impdp用法详解

一、创建逻辑目录,该命令不会在操作系统创建真正的目录,最好以system等管理员创建。 create directory dpdata1 as ’d:\test\dump’; 二、查看管理理员目录(同时查看操作系统是否存在,因为Oracle并不关心该目录是否存在,如果不存在,则出错) select * from dba_directories; 三、给scott用户赋予在指定目录的操作权限,最好以system等管理员赋予。 grant read,write on directory dpdata1 to scott; 四、导出数据 1)按用户导 expdp scott/tiger@orcl schemas=scott dumpfile=expdp.dmp DIRECTORY=dpdata1; 2)并行进程parallel expdp scott/tiger@orcl directory=dpdata1 dumpfile=scott3.dmp parallel=40 job_name=scott3 3)按表名导 expdp scott/tiger@orcl TABLES=emp,dept dumpfile=expdp.dmp DIRECTORY=dpdata1; 4)按查询条件导 expdp scott/tiger@orcl directory=dpdata1 dumpfile=expdp.dmp Tables=emp query=’WHERE deptno=20′; 5)按表空间导 expdp system/manager DIRECTORY=dpdata1 DUMPFILE=tablespace.dmp TABLESPACES=temp,example; 6)导整个数据库 expdp system/manager DIRECTORY=dpdata1 DUMPFILE=full.dmp FULL=y; 五、还原数据 1)导到指定用户下 impdp scott/tiger DIRECTORY=dpdata1 DUMPFILE=expdp.dmp SCHEMAS=scott; 2)改变表的owner impdp system/manager DIRECTORY=dpdata1 DUMPFILE=expdp.dmp  TABLES=scott.dept REMAP_SCHEMA=scott:system; 3)导入表空间 impdp system/manager DIRECTORY=dpdata1 DUMPFILE=tablespace.dmp TABLESPACES=example; 4)导入数据库 impdb system/manager DIRECTORY=dump_dir DUMPFILE=full.dmp FULL=y; 5)追加数据 impdp system/manager DIRECTORY=dpdata1 DUMPFILE=expdp.dmp SCHEMAS=system  TABLE_EXISTS_ACTION=append; —————————-Expdp/Impdp的相关参数—————————- EXPDP命令行选项 1. ATTACH 该选项用于在客户会话与已存在导出作用之间建立关联.语法如下 ATTACH=[schema_name.]job_name Schema_name用于指定方案名,job_name用于指定导出作业名.注意,如果使用ATTACH选项,在命令行除了连接字符串和ATTACH选项外,不能指定任何其他选项,示例如下: Expdp scott/tiger ATTACH=scott.export_job 2. CONTENT 该选项用于指定要导出的内容.默认值为ALL CONTENT={ALL | DATA_ONLY | METADATA_ONLY} 当设置CONTENT为ALL 时,将导出对象定义及其所有数据.为DATA_ONLY时,只导出对象数据,为METADATA_ONLY时,只导出对象定义 Expdp scott/tiger DIRECTORY=dump DUMPFILE=a.dump CONTENT=METADATA_ONLY 3. DIRECTORY 指定转储文件和日志文件所在的目录 DIRECTORY=directory_object Directory_object用于指定目录对象名称.需要注意,目录对象是使用CREATE DIRECTORY语句建立的对象,而不是OS 目录 Expdp scott/tiger DIRECTORY=dump DUMPFILE=a.dump 建立目录: CREATE DIRECTORY dump as ‘d:dump’; 查询创建了那些子目录: SELECT * FROM dba_directories; 4. DUMPFILE [...]

第 1 页,共 13 页1234510...最旧 »