魑魅魍魉 发布的文章

Accept

客户端用 Accept 首部来通知服务器 可以接受哪些媒体类型,其值就是客户端支持的媒体类型列表,比如 image/gif 就是表示客户端支持 gif 格式的图片, * 则是一个特殊的值,用来通配媒体类型,比如 */* 表示所有媒体,image/* 则表示所有的图片,同时,还可以添加一个质量值 q 来告诉浏览器优先选择哪种媒体类型。

示例

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Accept-Charset

客户端用 Accept-Charset 首部来通知服务器,它可以接受哪些字符集或者哪些优选字符集,其值为多个字符集列表以及字符集可能的质量值,当服务器上有以多种可接受字符集表示的文档时,可以通过质量值告知服务器哪个字符集是优选的,该首部同样有一个 * 通配符。

示例

Accept-Charset: iso-latin-1

Accept-Encoding

客户端用 Accept-Encoding 首部来告知服务器它可以接受哪些编码方式,如果服务器的内容是经过编码的(可能是经过压缩的),那么这个请求首部可以告诉服务器客户是否会接受它。

示例

Accept-Encoding: gzip, compress;q=0.5

Accept-Language

客户端用 Accept-Language 表示可接受或者优选哪些语言。

示例

Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,zh-TW;q=0.4

Accept-Ranges

Accept-Ranges 首部与其它 Accept 首部不同——它是服务器使用的一种响应首部,用来告诉客户端它们是否接受请求资源的某个范围。如果这个首部有赋值的话,这个值就说明了服务器允许对指定资源的哪个范围类型进行访问。

客户端可以在没有收到这个首部的情况下,对某资源发起范围请求。如果服务器法巴拉圭对那个资源的范围请求,可以以适当的状态码(比如 416)进行响应,奖 Accept-Ranges 的值设置为 none ,客户端以后就不会(也不应该)再发起范围请求了。

应用场景

该首部最常见的应用场景就是断点下载,当我们从网络上下载一个大小为 4096 bytes 的文件时,可能下载到 2048 bytes时,网络中断了,这个时候,如果再次下载,我们就可以通过一个客户端的 Range 首部告诉服务器,我只需要下载 2049 bytes 之后的数据即可,前面的数据已经有了(这个在后面会讲到),当然,这需要服务器返回一个正确的 Accept-Rangesbytes

另一个常见的场景就是在做 RESTFul 接口时,比如一个用于查询所有用户列表的接口 /users,可能数据库里面总共有 10000 条记录,但是我们不可能一次性就全部返回,这个时候,服务器可以返回一个 Accept-Ranges: items ,告诉客户端,你可以以 items 类型对该资源进行部分下载。

示例

Accept-Ranges: bytes

Age

Allow

Allow 首部经用于通知客户端可以对特定资源使用哪些HTTP方法。

示例

Allow: GET, HEAD

Authorization

Authorization 首部是由客户端发送的,用来向服务器回应自己的身份验证信息,客户端收到来自服务器的 401 Authentication Required 响应后,要在其请求中包含这个首部,这个首部的值 取决非于所使用的认证方案。

示例

Authorization: Basic YnJpYW4tdG90dHk6T3ch

说明

在有一些时候,我们可能也不会使用这个首部,而是使用自己定义的相类似的首部,比如在信用生活的项目里面我们使用的就是 X-Auth-Token,这个时候,但是使用这种自定义的首部之后,通用的客户端就无法为我们进行任何建议或处理了,就像在浏览器里面,若服务器返回 401 Authentication Required,这个时候,浏览器表现为弹出一个输入用户名和密码的输入框 ,用户输入之后,浏览器会对其进行简单的 Base64 编码,然后直接重新发起一次请求(本次请求会带上如上面示例所示的首部),但是对于服务器来讲,因为认证并不是通过 Authorization 首部进行的,所以还是会返回 401 响应。

Cache-Control

Cache-Control 首部用于传输对象 的缓存信息,这个首部是 HTTP/1.1 引入的比较复杂的首部之一,它的值是一个缓存命令,给出了某个对象可缓存性有关的缓存 特有指令。

示例

Cache-Control: no-cache

Client-ip

这是一个在一些比较老的客户端和代理上面会出现的首部,用于表示运行当前客户端或者代理的计算机的IP地址。

示例

Client-ip: 10.106.4.199

Connection

Connection 首部是个多少有点过载了的首部,它可能会把你搞晕。这个首部用于 扩展了 keep-alive 连接的 HTTP/1.0 客户端keep-alive 连接用于控制信息,在 `HTTP/1.1中,能识别出大部分较老的语义,但这个首部被赋予了新的功能。

HTTP/1.1 中,Connection 首部的值 是一个标记列表,这些标记对应各种名称,应用程序收到带有 Connection 首部的 HTTP/1.1 报文后,应该对列表进行解析,并删除报文中所有在 Connection 首部列表中出现过的首部,它主要用于有代理的网络环境,这样服务器或者其它代理 就可以指定不应该传递的逐跳首部了。

比如 close 这个标记值,这个标记意味着响应结束之后,连接会被关闭,不支持持久连接的 HTTP/1.1 应用程序要在所有请求和响应中插入带有 close 标记的 Connection 首部。

示例

Connection: close

Content-Base

服务器可以通过 Content-Base 首部为响应主体部分中要解析的 URL 指定一个基础 URL ,其值是一个绝对 URL,用于解析在实体内找到的相对 URL

示例

Content-Base: http://www.onmr.com/

Content-Encoding

Content-Encoding 首部用于说明是否对某对象进行过编码,通过对内容进行编码,服务器可以在发送响应之前将其进行压缩,然后通过 Content-Encoding 首部的值告诉客户端,服务器对对象执行过哪种或者哪些类型的编码,有了这个信息,客户端就可以对报文进行编码了,这个值,理论上来讲应该是由客户端发送的 Accept-Encoding 首部中所有支持的编码类型的一个子集。

示例

Content-Encoding: compress, gzip

Content-Language

Content-Language 首部用来告诉想要理解对象的客户端,应该理解哪种自然语言,比如说,一篇用法语编写的文档就应该有一个表示法语的 Content-Language 值。

示例

Content-Language: en

Content-Length

Content-Length 首部说明了主体部分的长度或尺寸,如果对 HEAD 请求的响应报文中带上这个首部,则这个首部就告诉客户端,如果要发送内容的话,那么内容主体的长度就是这个值。

示例

Content-Length: 2417

Content-Location

Content-Location 首部包含在一个 HTTP 报文中,给出了与报文的实体部分相对应的 URL ,对可能有多个 URL 的对象来说,响应报文中可以包含一个 Content-Location 首部,说明用来产生响应的对象的 URLContent-Location 可以与所请求的 URL 不同,服务器通常会用它奖客户端导向或者重定向到一个新的 URL 上去。

如果 URL 是相对的,就应该相对于 Content-Base 首部加以解释,如果没有提供 Content-Base,则应该使用请求的 URL 进行解释。

示例

下面的示例就是信用生活中,信用卡信息管理接口 /api/v1/discovery/creditcards ,当我使用 POST 请求,向服务器发送了张新卡片详情数据之后,服务器完成数据的校验与保存,然后返回一个 Content-Location ,告诉客户端,新的内容的位置在哪里:

Content-Location:/api/v1/discovery/creditcards/1600

Content-MD5

Content-MD5 首部是服务器用来对报文主体进行报文完整性检查的,只有原始服务器或发起请求的客户端可以在报文中插入 Content-MD5 首部,首部值就是报文主体的 MD5 摘要(根据 RFC 1864 的定义,MD5 摘要值是一个 Base64 或者 128 位的 MD5 摘要。

示例

Content-MD5: YnJpYW4tdG90dHk6T3ch

Content-Range

请求传输某范围内的文档时,产生的结果由 Content-Range 首部给出,它提供了请求实体所在的原始实体内的位置(范围),还给出了整体实体的长度。如果值为 *,而不是整个实体的长度,就意味首发送响应时,长度未知(这个我们在使用浏览器下载文件的时候,绝大多数情况下,我们都是可以根据当前网速知道剩余下载时间的,但是有一些下载,我们却不知道下载时间,这就是因为,在下载时,服务器明确表示了内容长度未知引起的)。

示例

下面的示例就表示了,内容的长度单位为 bytes,总长度为 5400 bytes ,而本次响应的内容为整个主体对象第 500 - 999 bytes 间的内容。

Content-Range: bytes 500-999 / 5400

应用场景

这个首部在我来宜人贷的这段时间内,还没有看到哪个项目或者团队在使用,但是在我自己的项目里面使用到了,我自己项目的接口是完全基于 RESUful 建议的,这里面就以 /user/users 接口为例来讲讲,该接口的 GET 请求用于查询数据库中的所有用户,默认情况下,服务器会返回查询到的前20条记录,现在假如整个库中有 1000 个用户,那么, /user/users 这个资源主体大小就是 1000,因为这里面的大小单位不再是 bytes ,所以,我们自己定义了一个单位 items,当客户端 GET /user/users 时,会得到下面这样的首部:

Content-Range: items 0-19/1000

此时,客户端已经得到它所需要的所有信息了:

  1. 当前资源返回的是第0至第19个
  2. 资源总条目(items)数为 1000

在接下来的访问过程中,客户端就可以发起请求,获取其它范围的内容了,比如下面这样:

Range: items=20-39

这时,服务器就知道,此次请求需要查询的是第20至第39个条目

说明

关于 RESTful 中的分页,我现在的解决方案如下:

  • 请求格式:Range: items=start-end
  • 响应格式:Content-Range: items start-end/total
Range 首部

Range 首页由客户端发送请求时携带,用于标识此次请求需要服务器端返回哪个区间的数据,Range的取值方式如下:

  1. items=0-9:取结果集中的 第0至第9 个子集
  2. items=1000-:取结果集中 第1000及其以后所有数据 的子集
  3. items=-500:取结果集中 最后500个 子集
  4. items=0-9,20-29:取结果集中 第0-9个 以及 第20-29个 两个子集的合集
  5. items=0-9,-9:取结果集中 第0-9个 以及 最后9个 两个子集的合集
Content-Range 首部

Content-Range 首部是由服务器在返回结果的响应时,携带的首部,用于表示此次返回的数据的范围,其值如下:

Content-Range: items 0-9/100

详细的说明可以见 http://git.onmr.com/grassroots/grassroots-api-docs/blob/master/structure.md

关于 Range 首部,会在 Range 首部中专门细说一下。

Content-Type

Content-Type 首部说明了报文中对象的媒体类型。

示例

Content-Type: text/html; charset=iso-latin-1

Cookie

Cookie 首部是用于客户端识别和跟踪的扩展首部。

示例

Cookie: sessionid=IDFIOSDUFSDFLKIU@#IOL#KKJoi

Cookie2

Cookie2 首部是用于客户端识别和跟踪的扩展首部,Cookie2 用于识别请求发起者能够理解哪种类型的 Cookie1

示例

Cookie2: $version="1"

Date

Date 首部给出了报文创建的日期和时间,服务器响应中要包含这个首部,因为缓存在评估响应的新鲜度时,要用到这个服务器认定的报文创建时间和日期,对客户端来说,这个首部是可选的,但包含这个首部会更好。

HTTP 有几种特定的日期 格式,这种格式是在 RFC 822中定义的,这是 HTTP/1.1 报文的优选格式,但是在早期的HTTP规范中,没有明确说明日期的格式,因此服务器和客户端的实现者使用了一些其他 格式,为了解决这些遗留问题仍然需要支持这些格式:

Date: Tuesday, 03-Oct-14 02:15:31 GMT RFC 850 format
Date: Tue Oct 3 02:15:31 1997 asctime( ) format

示例

Date: Thu, 07 Jan 2015 15:15:15 GMT

ETag

ETag 首部为报文中包含的实体提供了实体标记,实体标记实际上就是一种标识资源的方式。

示例

ETag: "11e92a-457b-31345aa"
ETag: W/"11e92a-457b-31345aa"
W/ 前缀广播一个 实体标记,对于弱实体标记来说,只有当关联 的实体在语义上发生了重大改变时,标记才会变化 。

Expect

客户端通过 Expect 首部来告知服务器它们需求某种行为,现在此首部与响应码 100 Continue 紧密相关。

如果服务器无法理解 Expect 首部的值,就应该以状态码 417 Expectation Failded 进行响应。

示例

Expect: 100-continue

Expires

Expires 首部给出了响应失效的日期和时间,这样,像浏览器这样的客户端就可以缓存一份副本,在这个时间到期之前 ,不用去询问服务器它是否有效了。

示例

Expires: Thu, 07 Jan 2015 15:15:15 GMT

From

From 首部说明请求来自何方,其格式就是客户端用户的有效电子邮件地址。

示例

From: name@domain.com

Host

客户端通过 Host 首部为服务器提供客户端想要访问的好地台机器的因特网主机名和端口号,主机名和端口号来自客户端所请求的 URL

如果一台服务器上面服务着多个网站,每一个网站绑定了一个独立的域名,这个时候,服务器软件就需要通过 Host 首部来判断用户是需要访问当前该服务器上面的那一个网站了。

HTTP/1.1 客户端必须在所有请求中包含 Host 首部,所有的 HTTP/1.1 服务器都必须以 400 Bad Request 状态码去响应没有提供 Host 首部的请求。

示例

Host: onmr.com:80

If-Modified-Since

If-Modified-Since 请求首部用来发起条件请求,客户端可以用 GET 方法去请求服务器上的资源,而响应则取决于客户端上次请求此资源之后,该资源是否被修改过,如果对象未被修改过,服务器就会回送一条 304 Not Modified 响应,而不会回送此资源,如果对象对修改过,则服务器就会像非条件 GET 请求一样进行响应。

示例

If-Modified-Since: Thu, 07 Jan 2015 15:15:15 GMT

If-Match

If-Modified-Since 首部类似,If-Match 首部也可以用于发起条件请求,If-Match 请求使用的是实体标记(ETag)而不是日期。服务器将对比 If-Match 首部的实体标记与资源当前的实体标记,如果标记匹配就将对象返回。

服务器应该用 If-Match* 与资源拥有的所有实体标记进行匹配,除非服务器上没有这个资源了,否则 * 总会与实体标记相匹配。

示例

If-Match: "11e92a-457b-31345aa"

If-None-Match

与所有 If 首部一样,If-None-Match 首部可以用于发起条件请求,客户端为服务器提供 一个实体标记列表,服务器将这些标记与它拥有的资源实体标记进行比较,只在都不匹配的时候才将资源返回。这样缓存就可以只在资源已被修改的情况下才更新。通过 If-None-Match 首部,缓存可以用一条请求使它拥有 的实体失效,同时在响应中接收新的实体。

示例

If-None-Match: "11e92a-457b-31345aa"

If-Range

If 首部一样,If-Range 首部可以用于发起条件请求。应该程序拥有某范围内资源的副本,它要对范围进行再验证,如果范围无效的话,要获取新的资源,在这种情况下会使用这个首部。

示例

If-Range: "11e92a-457b-3134b5aa"

If-Unmodified-Since

If-Unmodified-SinceIf-Modified-Since 是一对,该首部查询时,未被修改过才返回对象。

示例

If-Unmodified-Since: Thu, 03 Oct 2015 17:17:17 GMT

Last-Modified

Last-Modified 首部试图提供这个实体最后一次被修改的相关信息,这个值可以说明很多事情,比如,资源通常都是一台服务器上的文件,因此 Last-Modified 值可能是服务器的文件系统所提供的最后修改时间;对于那些动态创建的资源,Last-Modified 的值可能就是创建响应的时间。

Location

Location 首部可以将客房端导向某个资源的地址,这个资源可能在客房端最后一次请示之后被移动过,也可能是在对请示的响应中创建的。

示例

Location: http://www.onmr.com/press/http-headers

Max-Forwards

这个首部必须和 Trace 方法一同使用,以指定请示所经过的代理或者其它中间节点的最大数目,它的值是一个整数,所有收到带有此首部的 Trace 请示,都需要在请示转发出去之前,将该值减1。如果应用程序在收到请示时,这个首部的值为0,就要向请示回应一条 200 OK响应,并在实体的主体部分包含原始请示。

示例

Max-Forwards: 5

MIME-Version

MIME-Version 用于提供服务器支持的 MIME 版本,老服务器才可能存在,没有进入标准中。

Pragma

Pragma 首部用于随报文传送一些指令,这些指令几乎可以包含任何内容,但通常会用这些指令来控制缓存的行为。Pragma 首部的目标可以是接收这条报文的所有应用程序,因为此理和网关一定不能将删除。

最常见的形式,比如用户点击刷新按扭或者重新加载时,浏览器一般都会带上 Pragma: no-cache 首部,用于强制在有新鲜副本可用的情况下,向原始服务器请示文档或对其进行再验证。很多服务器也会向客户端发送 Pragma: no-cache 首部的响应(作用与 Cache-Control: no-cache 等价)

规范中唯一一个被定义的指令就是 no-cache

Proxy-Authenticate

Proxy-AuthenticateWWW-Authenticate 类似,当代理服务器发送了一条 407 Proxy Authentication Required 响应时,发起请示的应用程序就必须包含 Proxy-Authenticate 首部。

示例

Proxy-Authenticate: Basic realm="Yirendai Super User"

Proxy-Authorization

Proxy-Authorization 被客户端用来响应代理服务器的 Proxy-Authenticate 声明

Proxy-Connection

Proxy-ConnectionHTTP/1.0 Connection 首部类似,

Public

Public 首部可让服务器告知客户端其支持哪些方法,今后客房端就可以在发起的请示中使用这些方法了。

示例

Public: OPTIONS, GET, HEAD, TRACE, POST

Range

在请示某个实体的部分内容时,会使用到这个首部

示例

Range: bytes=500-1000

Referer

在客户端的请求中插入 Referer 首部,可以使服务器知道客房端是从哪里获取到其请示的 URL的,这是一种对服务器有益的自愿行为,这样服务器就可以更好的记录请求,或执行其它任务。

浏览器所做的工作非常简单,如果在主页A上点击了一个金田白立,进入主页B,那么浏览器就会在请求B的请求中带有一个 Referer 首部,其值为主页A的URL。

Retry-After

服务器通过 Retry-After 首部告知客房端在什么时候可以重新发送某资源的请求。

Server

ServerUser-Agent 类似,服务器使用该首部来标识自己。

Set-Cookie

Set-Cookie 用于告知客户端设置 Cookie

Set-Cookie2

Set-Cookie 首部的扩展

TE

Accept-Transfer-Encoding ,类似于 Accept-Encoding,只不过它用于定义传输编码。

Trailer

Trailer 首部用于说明报文拖挂中提供了哪些首部。

示例

Trailer: Content-Length

Title

Title 发送 HTML 文档的标题(非标准)

Transfer-Encoding

Transfer-Encoding 定义报文的传输编码。

示例

Transfer-Encoding: chunked

UA-(CPU,Disp,OS,Color,Pixels)

非标准

Upgrade

User-Agent

Vary

Via

Warning

WWW-Authenticate

X-Cache

X-Forwarded-For

X-Pad

X-Serial-Number

分层系统穿衣法能够优化服装的交通和通用性,更能够适应山区气温的波动,便于登山者根据所需进行调整,以最轻的重量让身体保持最大的舒适感。大多数有经验的登山者都会总结出套自己的穿衣方法,在野外根据特定的环境或者个人爱好做相应的培养,要么改变内层朵么多带或者少带几件保暖衣,要么带不同的外套(检验该产品),但有一点始终不会改变,那就是分层穿衣原则。分层穿衣原则的“分层”是指贴身内层,保暖层和外层。

分层穿衣典型范例.jpg

贴身内层

内层衣服应该选择排污性较强的内衣,以保持身体的干爽。排污对于保暖来说非常重要,因为湿衣服在皮肤上会加剧体温的流失。选择什么质地、品牌的贴身内层衣物因人而异,但一定要满足透气、保暖、排污的需求。

长内衣

合适的长内衣能够起到良好的保暖作用。聚丙烯和聚酯纤维是多数人的选择,当然也有些人偏爱毛织品。深色的长内衣吸热性强,能让身体保持温暖,在阳光下也容易干。浅色的长内衣吸热性能一般,适合在夏天穿,同时还能防晒伤和防蚊虫叮咬。

攀岩时,攀登者偶尔会用弹性织物和聚酯纤维混纺的紧身衣来代替长内衣,因为前者有更好的延伸性,活动自如,但保暖性不如后者。

T恤和短裤

虽然T恤、短裤、普通内衣、运动衣等并未在身体周围形成一层真正的保护层,但它们也扮演着非常重要的角色。

在酷暑里,因为不需要靠衣物排污,所以棉质T恤或者无袖的上衣比较好。如果要防晒,最好穿长袖衣服。需要注意的是,在凉爽的山区,不适合穿棉质T恤,因为微风容易让棉质T恤被汗水浸透。在休息时,湿衣服会让人冷得浑身发抖。在这种环境中,不吸尘的合成纤维比棉质衣服更合适。T恤最好选择浅色、不紧身的,才能凉爽和通风。

短裤必须且有耐磨性和透气性。一件宽松的尼龙短裤,加上​一件尼龙网眼内裤就能达到这种效果,登山者不宜穿棉内裤,这是因为汗湿的棉质内裤容易擦伤皮肤,感觉不适。在气候宜人时,轻抚聚酯纤维长内衣加上一条尼龙短裤是登山者最爱的组合。可拆解成短裤的轻抚尼龙长裤也是非常受欢迎的。

保暖层

保暖层应该包住人体周围的温暖空气,这层空气越厚,人就会感觉越温暖。穿数件宽松的薄衣服虽然不如穿一件羊绒大衣保暖,但可以一层一层的保住明空气,也方便调节。

天气寒冷时,就需要穿上数层衣物保暖。上身可选择较厚的长内衣,毛料或合成纤维衬衫、毛衣、羽绒夹克或者人造纤维填充料的夹克。腿部可选择厚卫生裤、毛料长裤或者弹性较好的尼龙裤。在严寒时,建议穿连身的保暖衣物,市场上的保暖衣服品种丰富,它们可以确保登山者的衣服在涅槃的情况下仍能保持身体温暖。

衬衫和毛衣

衬衫和造谣要足够长,这样才能把它们指扎进裤腰或者拉出来盖到腰部。长裤和上半身衣物间的空隙会散失宝贵的温暖空气,高领内衣和造谣的保暖效果很不错,而且也较轻。

保暖长裤

比较宽松或者具有伸缩性的长裤是首选,这种长裤有利于自由伸展。长裤的面料质地应紧密,并经过防风或耐磨处理。毛料裤或毛料与聚酯纤维混纺裤做长裤也很好,羊毛裤虽然轻但不防风,也不耐磨,请选购臀部和膝部有加强设计、腿侧有拉链的款式,这样的款式在使用冰爪或滑雪板时能顺利穿脱。

七分裤

有不少的登山者比较喜欢及膝的七分登山裤加绑腿的搭配,本分裤便于活动和通风,裤腿也不会被雪或露水沾湿,便于保持干爽。

皮质大衣

在非常寒冷的环境下,皮质大衣是登山队员尤其是确保队员非常适合的保暖衣服,它中以把大个子衣服都包裹进去。这种皮质大衣有头套,且质量轻、可压缩,还有不错的防水性能。

外层

外层衣物一定要能够防风、防雨和防晒。

理想的外层衣服应该具有防风、完全防水及完全透气的功能。在现实中,虽然没有一件衣物能够完全达到这些要求,但我们可以用不同的穿衣方法来达到上述目的。

一种方法是穿上一层多功能的防水透气外层,如果这层衣物透气性足够好,那么它就是最好的选择。

另一种方法是穿两层外层衣物:一层轻质透气的风衣和一层轻抚雨衣(不管是否透气)。在轻风细雨时可穿风衣,雨势较大时再穿上雨衣。这种穿衣方法比较省钱,在不下雨时穿风衣也利于通风,但不透气的雨衣没有防水透气雨衣舒适,且携带两件衣物也增加了负重。

连帽雨衣

连帽雨衣款式众多,标准连帽雨衣前面有可调节通风度的全开式拉链。有的人偏爱套头式雨衣,因为这种雨衣质量轻、体积小,防风性也比较好。不论雨衣的材料是否具有透气功能,选购时要考虑的关键因素都相同。

雨裤

雨裤的侧边最好要有拉链,可以在穿鞋或者冰爪时轻松穿脱。雨裤的穿着频率较雨衣低,而且在穿越灌木丛或从雪滑降时容易磨损,所以选择比较便宜的非透气型雨裤比较实用。

有些登山者采用防水透气型吊带裤作为下身外层,这种选择适合较冷的山区。有些吊带裤内有保暖填充料,非常适合进入严寒山区。这种裤子比一般雨裤伸腰,因为它包裹住了大部分身体,可以避免雪从腰部裤子的缝隙中掉入裤管,但这种吊带裤夏季穿时就会太热。此外,也有一部分登山者倾向于选择具有单一保暖性的雨衣裤。

_DSC3720.jpg

  • 将登山行程表交给营地留守人员;
  • 带足上山的衣物、食物和装备;
  • 一个登山队至少应有三人,除非事先做了足够的准备;
  • 在攀登冰河时,建议至少组建两个绳队;
  • 在没有任何遮蔽物的冰河上行进时,请用绳索确保,并固定所有的确保点;
  • 集体行动,听众领队或者服从多数人的决定;
  • 不要攀登超出你知识水平和能力范围的路线;
  • 选择走哪条路或者考虑是否返回时,别因冲动作决定;
  • 遵照公认较好的登山指南介绍的登山守则;
  • 任何时候都要以友好的态度对待山林,严格遵守“不留痕迹”原则。

人类正以惊人的速度消耗着大自然,对自然造成无法挽回的破坏。山林并不是为了登山者而存在,它不欠人类任何东西,对人类也无所欲求。

按阳历算,又是新的一年了,今年元旦跟温新泽同学两个人过的,去年在蓝色港湾和三里屯,今年在后海,近两点才回到家。尔后白天去了798,陪小泽同志去了一躺中关村买了个35的定焦头,认识了张老师(玩摄影玩了40多年,从高中时代就开始玩,现在已经退休,烧设备也烧了40多年,我只想问一下下,算下来在北京有多少套房子了?只是业余爱好哦),然后接着去了躺鸟巢,好好的拍了几张,还算有一两张满意的吧。

听了张老师的一段教导,记录下:

  1. 拍下来的任何照片,都存好源始档案,胶片机的话,就存好胶片,数码机的话,相机出出来的文件保存到电脑上之后就再也不要动,所有的操作都使用复本,然后,记录好每一张照片的拍摄地点,时间,以及当时相关的一些场景;
  2. 任何照片,当你按着自己的构图拍好了之后,后退一段距离(定焦的话)或者焦距小一点,拍一张比自己构图视角要宽一点的图片,以防万一一张好的照片因为构图时候的不注意少了点什么;
  3. 如果想要提高出片率,任何时候,都请使用三脚架,即使是炎炎夏日,即使天气好得不了,即使太阳当空照,不要相信自己手持有多稳当,放大之后都是扯蛋;
  4. 如果想要提高出片率,照片可以一次加减1、2、3、4、5档曝光,也就是一张照片有11个曝光(如果相机支持的话,不支持一般也支持上下三档即共七档),这可以让你永远都有更多的机会选出一张正常曝光的照片;
  5. 不要还没开拍就想着怎么后期,一张好的照片应该是拍出来的时候的,只有在因为某些技术原因,拍的时候产生一些瑕疵的时候,再使用后期技术做一些修复,但记住,只是修复,不是修改;
  6. 胶片相片影响出片率的主要是镜头,但不要相信所谓摄影大师说所说的,数码时代,机身很关键,远远超过镜头,2000W像素和4000像素就是差很多,不要在技术进步之后,还把自己局限在古老的时代,我以四十年设备发烧玩家的经验告诉你这些;
  7. 我长住山西,“十年中国看深圳,百年中国看上海,千年中国看北京,三千年中国看陕西,五千年中国看山西”,有时间,去山西太原找我,我可以带你好好玩玩。

IMG_8518.jpg

IMG_8517.jpg

IMG_8357.jpg

IMG_8355.jpg

IMG_8350.jpg

IMG_8351.jpg

IMG_8352.jpg

IMG_8353.jpg

IMG_8356.jpg

IMG_8357.jpg

IMG_8460.jpg

IMG_8458.jpg

IMG_8469.jpg

IMG_8465.jpg

IMG_8467.jpg

IMG_8463.jpg

IMG_8462.jpg

IMG_8461.jpg

上几张今天拍的照片

北京鸟巢夜景

北京鸟巢夜景

IMG_8309.jpg

IMG_8311.jpg

展望

今天是2015年12月31日,2015年最后一天了,似乎又到了总结与规划的时间了。

回首今年:

  • 3月10号,时隔四年半之后,又回到北京,去了一家改变我自己的职业方向的工作——玖富 叮当钱包前端开发,第一次确定自己以后的主要职业方向是前端开发,而不再像以前那像各种都做了;同时,也是第一次真正的进入了如火如荼的互联网金融行业;
  • 3月13号,入了一台小蚁相机,从此开始了自己的运动相机玩家生涯,后改了GoPro4,小蚁送给发小胡文潇同志
  • 3月24号,感觉是在自己的强力推动下,叮当钱包在运行了半年之久之后终于算是正式上线,这也是自10年10月回湖南之后,再一次以打工者的身份自己参与的一个项目上线;
  • 3月26号,自己人生第一次从P2P平台借了一笔款,虽然只有50元,但是这是第一次;
  • 4月2号,这么多年第一次有一台运行时间超过300天的服务器关闭,自己第一次感觉我是在用而不是在玩;
  • 5月17号,人生第一次参与了一次足球比赛,虽然只是公司内部的,但确实是我人生中的第一次;
  • 6月29号与7月1号,自己策划的一个P2PApp正式上线,本来叫一麻贷,后来公司非要改成叮当贷,但至少还是上线了;
  • 8月1号,第一次给奔驰这样的大公司做了外包项目,一口气做了五个SmartForTwo的宣传项目,其中包括官方网站上面的两个页面(PCMobile),这一次的外包经历对自己的成长有着转折点的作用,从此不再是大而全,而是小而精,精后再精;
  • 8月13号,因为各种原因,离开玖富;
  • 8月17号-8月23号,爷爷,姑,表弟他们来北京玩,第一次以一个导游的身份带家人玩了北京,也是第一次与爷爷一起在外地,希望以后还能再多有机会陪陪家人;
  • 8月25号,正式入职宜信宜人贷;
  • 9月1号,整了一个个人介绍
  • 9月3号,国家大事,我去了泰山
  • 9月13号,又去了一躺故宫,捡了一妹纸,其实是被一妹纸捡,我当她的摄影师,她当我的模特,配合还算不错;
  • 12月6号,参加了北京古迹群年聚会,第一次和群友们见了个面;
  • 12月12号,人生第一次真正的户外,我站在本坨长城山顶的时候,知道了外公于当天凌晨3时许过世,这件事情对我的影响算是特别大吧,虽然我从来不会表现出来什么,但是,外公是我从懂事起,最亲近的人里面的一个,太爷爷太奶奶虽然也都才走没过十年,但是他们毕竟与我隔了两代人,虽然也很伤心,但是却不如此般,这让我越来越害怕时间一年又一年的流失,害怕自己最亲的人离开自己;
  • 12月18号,自已送了外公最后一程,我唯一能做的就是祝他一路走好,我用相机记录下了他离开家之后的每一个片段,也记录了他的入土为安,如果有来世,我还是做您的孙子;我把外公的二胡带上了,做了一个决定,每有见过你最后一面,希望自己能花一年的时间,学会二胡,以后有时间,就过去给你拉拉二胡,这是您生前最喜欢的事情了,这么多年说要跟您学,也没来得及;
  • 12月31号,15年的最后一天。

展望明年:

  • 想想其实也没有什么可展望的,自从13年离开木木,去了珠峰之后,这一连串的事情让自己这三年的经历超过了以前的所有,如果说2015年是自己在疗伤的话,那2016年最多也只能算是自己静心休养的一年,我也不太可能有太多的大动作,毕竟,我现在不再是一个人;
  • 让自己真正的不再是一个负翁,这应该是2016年的头等大事,这除了14年创业自己欠的钱之外,还有爸爸妈妈因为我欠的钱,还有欠别人的情,还有自己心态的调整;
  • 踏踏实实做好自己的工作,以后推动一些自己力所能及的进步,这是我对工作的要求;
  • 把北京的那些没有走过的长城片段在2016年都尽可能的走一遍;
  • 带老婆、孩子一起来一次长途的自驾游;
  • 为2017年打好坚实的基础。

人经历过一些事情之后,想法会变得现实很多,比如我。

如果在安装 npm 的各种包时,总是需要 sudo 才能完成安装的话,那是因为你的 npm 包安装目录的权限问题,你可以通过下面两种方式的任何一种解决:

方法一:修改 npm 默认安装目录的权限

  1. 找到 npm 默认安装目录:

    npm config get prefix

    很多系统都应该是 /usr/local ,如果目录是 /usr 的话,请不要使用此方法,改用方法二。

  2. 将该目录的所有者改成当前用户即可(就是你啦):

    sudo chown -R `whoami` <directory>

如果你不想修改目录的权限,你可以单独修改下面这些子目录即可:

  • lib/node_modules
  • bin
  • share

方法二:修改 npm 默认的安装目录至另一个目录

很多时候,可能因为各种各样的原因,你并不想或者根本就不能修改默认目录的所有者,那么,改变 npm 的默认安装目录将是最好的选择了:

  1. 创建一个新的目录,比如下面这样:

    make ~/.npm-global
  2. 设置 npm 使用刚才新建的目录:

    npm config set prefix '~/.npm-global'
  3. 创建或者打开现有的 ~/.profile 文件,添加下面这一行:

    export PATH=~/.npm-glopbal/bin:$PATH
  4. 保存之后返回至命令行,更新系统变量:

    source ~/.profile

现在你可以直接通过下面这行命令全局安装一下 jshint 试试。

npm install -g jshint

安装

全局安装

如果你希望以命令行的方式在任何一个目录启动 Browsersync,那么需要你全局安,使用下面这行命令即可:

npm install -g browser-sync

本地安装

本地安装则是直接将 Browsersync 直接安装至你的项目中,这是应该优先选择的方式,安装完成之后,便将 Browsersync 作为你的项目的一个依赖添加至 package.json 文件中,这样所有的人都会在使用你的项目时,自动安装 Browsersync。

npm install browser-sync --save-dev
不管是全局安装,还是本地安装,请都不要使用 sudo,如果你在安装过程中告诉你需要使用 sudo,你可以通过 《修复 npm 的权限》这篇文章修复,很简单,只需要一分钟不到。

Gulp.js 配合

安装

在你的项目中安装 browsersyncgulp

npm install browser-sync gulp --save-dev

然后在 gulpfile.js 中添加如下代码:

var gulp = require('gulp');

var browserSync = require('browser-sync').create();

// 服务本地静态文件
gulp.task('browser-sync', function() {
    browserSync.init({
        server: {
            baseDir: './www/'
        }
    })
});

// 代理你的其它的项目
gulp.task('browser-sync', function() {
  browserSync.init({
      proxy: "yourlocal.dev"
  })
});

之后,在你的项目中即可以使用以下方式直接打开开发服务器了:

gulp browser-sync

SASSCSS 注入

Browsersync 支持数据流,所以你可以在一个特定的时间点重载页面,比如你修改了某个CSS文件或者HTML(注意,你需要在 gulp.dest 之后再调用 .stream)。

var gulp = require('gulp');
var browserSync = require('browser-sync').create();
var sass = require('gulp-sass');

// 服务本地静态文件
gulp.task('browser-sync', function() {
    browserSync.init({
        server: {
            baseDir: './www/'
        }
    });

    gulp.watch('./scss/*.scss', ['sass']);
    gulp.watch('./www/*.html').on('change', browserSync.reload);
});

gulp.task('sass', function() {
    return gulp.src('scss/*.scss')
    .pipe(sass())
    .pipe(gulp.dest('www/css'))
    .pipe(browserSync.stream());
});

gulp.task('default', ['browser-sync']);

与比对应的项目目录结构如下:

project/
    scss/
        main.scss
    www/
        index.html
        css/
            main.css
    gulpfile.js

ruby-sasssourcemap

如果使用了 gulp-ruby-sass ,并且开启了 sourcemap: true ,附加的 .map 文件也会被生成,如下:

var gulp = require('gulp');
var browserSync = require('browser-sync').create();
var sass = require('gulp-ruby-sass');
var sourcemaps = require('gulp-sourcemaps');

// 服务本地静态文件
gulp.task('browser-sync', ['sass'], function() {
    // 初始化 browser-sync
    browserSync.init({
        // 设置服务器
        server: {
            // 根目录为 ./www/
            baseDir: './www/'
        }
    });

    // 观察 ./scss 目录下所有 scss 文件的变更,同时将变更通知给 sass task
    gulp.watch('./scss/*.scss', ['sass']);
    // 观察 ./www 目录下的所有 .html 文件,当其修改时, browser-sync 重新加载(reload)
    gulp.watch('./www/*.html').on('change', browserSync.reload);
});

// sass 任务
gulp.task('sass', function() {
  return sass('scss/*.scss', {
      sourcemap: true
  }).on('error', function(err){
      console.error('Error!', err.message);
  }).pipe(sourcemaps.write('./www/css', {
      includeContent: false,
      sourceRoot: 'scss'
  })).pipe(browserSync.stream({
      match: '**/*.css'
  }))
});

gulp.task('default', ['browser-sync']);

Phalcon 是一个用 C 语言编写的,号称是速度最快、占用资源最少的 PHP 框架。它以一个 PHP 扩展的形式安装,与 CodeIgniter、CakePHP 等框架有显著的不同。

Phalcon 在 Windows 上的安装很简单,只要在官方网站上找到对应 PHP 版本的 DLL,放进 PHP 目录,然后在 php.ini 里加上就行了。但在 Linux 和 Mac 上需要自己编译。

在 Mac 上做 PHP 开发,很多人都用 MAMP。情况比较麻烦,因为除了 MAMP 以外,OS X 还自带了一个 PHP;而且 MAMP 没有自带 PHP 的源码。所以需要一些额外的步骤。

准备编译环境

首先,你得有一个包管理器,比如 Homebrew,用来安装一些工具。另外,还要安装 Xcode 或者只安装它的命令行工具,才能进行编译。

接下来,用 Homebrew安装一些工具:

$ brew install autoconf automake libtool

修改环境变量

现在,如果你在终端使用 PHP,实际上用的是 OS X 自带的那个:

$ which php
/usr/bin/php

修改环境变量,让终端调用 MAMP 里的 PHP:

$ export PATH=/Applications/MAMP/bin/php/php5.6.10/bin:$PATH
$ which php
/Applications/MAMP/bin/php/php5.6.10/bin/php

下载 PHP 源码

php --version 获得 PHP 的版本,然后在 php.net 下载对应的源码包。

$ php --version
PHP 5.6.10 (cli) (built: Jul  6 2015 14:28:54) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies

$ curl http://cn2.php.net/distributions/php-5.6.10.tar.bz2 | tar -xj
$ mkdir /Applications/MAMP/bin/php/php5.6.10/include
$ mv php-5.6.10/ /Applications/MAMP/bin/php/php5.6.10/php
$ cd /Applications/MAMP/bin/php/php5.6.10/php/
$ ./configure

安装 Phalcon

$ curl -L -o cphalcon-master.zip https://github.com/phalcon/cphalcon/archive/master.zip
$ unzip cphalcon-master.zip
$ cd cphalcon-master/build
$ sudo ./install

修改 MAMP PHP 配置文件模板

打开 MAMP,点击 File -> File -> Edit Template -> php 5.6.10 php.ini ,添加如下一行:

extension=phalcon.so

重启服务后,即可通过 phpinfo() 函数看到已安装的 Phalcon 信息。

介绍

很多软件都必须服务器提供了 Java 支持,本文将指导你完成在 Ubuntu 服务器如何安装与管理多版本的 Java.

安装默认的 JRE/JDK

这是被推荐的,也是最简单的方式,默认情况下,在 Ubuntu 12.04 上面,会安装 OpenJDK 6,而在 Ubuntu 12.10+ 上面,会安装 OpenJDK 7

通过 apt-get 工具安装 Java 很简单,首先更新包索引:

sudo apt-get update

安装检查你的服务器上面是否已经安装了 Java:

java -version

如果该命令返回 『The program java can be found in the following packages』,则表明你的服务器上面还没有安装任何版本的 Java,那么,执行下面这行命令即可安装默认版本的 Java:

sudo apt-get install default-jre

这会安装 Java 运行时环境(JRE),如果你需要安装 Java 开发工具包(JDK)来构建或编译 Java 程序(比如 Apache Ant,Apache Maven 等),那么执行下面这行命令:

sudo apt-get install default-jdk

这人安装 Java 需要的所有内容。

其它的步骤,都是可选的,而且应该在你需要的时候才执行。

安装 OpenJDK 7 (可选)

要安装 OpenJDK 7 ,执行下面的命令:

sudo apt-get install openjdk-7-jre 

这会安装 Java 运行时环境 (JRE),如果你需要安装 Java 开发工具包,则执行下面的命令:

sudo apt-get install openjdk-7-jdk

安装 Orache JDK (可选)

Orache JDK 是官方的 JDK,但是它现在已经不再被是 Ubuntu 的默认安装选项了。但是你还仍然可以通过 apt-get 安装它,要安装任何版本的 Oracle JDK,都需要先执行下面的命令:

sudo apt-get install python-software-properties
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update

根据你要安装的 JDK 版本的不同,选择下面不同的命令执行:

Oracle JDK 6

这是一个很古老的版本,但是同样可以安装

sudo apt-get install oracle-java6-installer

Oracle JDK 7

这是最新的稳定发布版本:

sudo apt-get install oracle-java7-installer

Oracle JDK 8

这是一个开发者预览版:

sudo apt-get install oracle-java8-installer

多版本安装 (可选)

如果你的系统中安装了多个版本的 Java,那么你可以随时设置并切换默认版本的 Java,执行下面的命令:

sudo update-alternatives --config java

如果你的系统中安装了多个版本,那么通常会有如下这样的返回结果:

There are 2 choices for the alternative java (providing /usr/bin/java).

Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-7-oracle/jre/bin/java          1062      auto mode
  1            /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java   1061      manual mode
  2            /usr/lib/jvm/java-7-oracle/jre/bin/java          1062      manual mode

Press enter to keep the current choice[*], or type selection number:

你现在就可以通过输入每一个版本前面的序号来设置默认的 Java 版本,这种默认版本的设置方法,对于 Java 编译器 javac 同样适用:

sudo update-alternatives --config javac

同样的,keytooljavadoc 以及 jarsigner 等均可以通过此种方法来设置默认版本。

设置 JAVA_HOME 环境变量

有一些程序需要系统提供一个 JAVA_HOME 环境变量,首先找到当前系统安装了哪些版本的Java。

sudo update-alternatives --config java

返回如下这样的结果:

There are 2 choices for the alternative java (providing /usr/bin/java).

Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-7-oracle/jre/bin/java          1062      auto mode
  1            /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java   1061      manual mode
  2            /usr/lib/jvm/java-7-oracle/jre/bin/java          1062      manual mode

Press enter to keep the current choice[*], or type selection number:

那么,安装路径就有下面这些:

/usr/lib/jvm/java-7-oracle

/usr/lib/jvm/java-6-openjdk-amd64

/usr/lib/jvm/java-7-oracle

复制你需要版本的路径,然后编辑:/etc/environment 文件:

sudo nano /etc/environment

在该文件中,添加下面这一行(同时将 YOUR_PATH 改为你刚才复制的路径):

JAVA_HOME="YOUR_PATH"

然后,重新加载该文件:

source /etc/environment

测试设置是否正确,可以执行下面这行命令:

echo $JAVA_HOME

如果成功显示了你设置的路径,则表示设置成功。

上周五(2015年11月23日),跟着当当网移动事业部去昌平香堂文化村团建,我就是个蹭吃蹭喝蹭玩的,租了一栋别墅,玩了一天一晚,周六就回来了,还有人留着继续玩到周日的。

香堂文化村夜景

本来是想着去拍星空的,但是结果,晚上还是太亮,没法儿拍,就只能拍成下面这样的了,最坑爹的是,三脚架带了,没带快装板,唉,图片中那一线一线的是灰机灰过的痕迹。

_DSC9090.jpg

_DSC9092.jpg

_DSC9093.jpg

烧烤

好吧,其实我烤得也还算可以,味道也是很不错的,不过,有胡总在,这些事儿基本上落不到我头上,我就拍照记录一下就可以了,本来计划是周六早上去的,只不过几位领导们说是要先去看看场地,所以就先去了,当天晚上把能烤的基本上也都烤完了。

_DSC9096.jpg

_DSC9097.jpg

_DSC9112.jpg

_DSC9116.jpg

周六的早上

前一天晚上玩到晚上一点多,第二天起来比较晚,都六点四十了,直接去了后山,本身就属于莽山国家森林公园,不过我们走的不是正园,而是连上的小园,其实比正园还好一些。

拍了些花花草草

_DSC9175.jpg

_DSC9206.jpg

_DSC9211.jpg

_MG_7598.jpg

_MG_7599.jpg

_MG_7600.jpg

_MG_7602.jpg

下面这几张是 iPhone 6 拍的,镜头还没调教好啊。

IMG_0706.jpg

IMG_0597.jpg

IMG_0599.jpg

IMG_0600.jpg

IMG_0602.jpg

IMG_0603.jpg

IMG_0715.jpg

IMG_0729.jpg

IMG_1410.jpg

NJBO7695.jpg

然后还有一些是 A7II 拍的。

_DSC9211.jpg

ILNF4167.jpg

IMG_1154.jpg

IMG_1158.jpg

QBTQ5663.jpg

_DSC9227.jpg

_MG_7773.jpg

AVWQ1477.jpg

BIQQ7610.jpg

FDGK2070.jpg

HOQR1973.jpg

IDML3799.jpg

JRJH9263.jpg

KOAO1652.jpg

NUBS8631.jpg

OYWO8728.jpg

PBCY8302.jpg

PSUR2487.jpg

RMUW9079.jpg

RVNG4471.jpg

SAYC7166.jpg

ULZF0945.jpg

UTTQ1407.jpg

WSIP7322.jpg

YEFW4926.jpg

YGKF9103.jpg

最后,带人的了

不得不说,以后出去必须跟玩摄影的人一起走,要不然,回到家里之后总是看不到自己的身影在哪里。

_DSC9236.jpg

_DSC9253.jpg

_DSC9256.jpg

_DSC9261.jpg

_DSC9262.jpg

_DSC9273.jpg

_DSC9281.jpg

_DSC9328.jpg

_MG_7649.jpg

_MG_7650.jpg

_MG_7657.jpg

_MG_7658.jpg

_MG_7663.jpg

_MG_7664.jpg

_MG_7665.jpg

_MG_7678.jpg

_MG_7689.jpg

_MG_7694.jpg

_MG_7701.jpg

_MG_7703.jpg

_MG_7706.jpg

_MG_7708.jpg

_MG_7713.jpg

_MG_7716.jpg

_MG_7759.jpg

_MG_7777.jpg

_MG_7779.jpg

_MG_7780.jpg

_MG_7781.jpg

_MG_7784.jpg

ACFB9078.jpg

G0059550.jpg

G0189874.jpg

G0189878.jpg

G0209889.jpg

G0209890.jpg

G0229901.jpg

G0270179.jpg

GOPR9562.jpg

GOPR9821.jpg

IMG_0326.jpg

IMG_0748.jpg

IMG_0764.jpg

IMG_0902.jpg

IMG_0955.jpg

IMG_1162.jpg

IMG_1163.jpg

IMG_1168.jpg

IMG_1170.jpg

IMG_1229.jpg

OTGA4707.jpg

SFEE7942.jpg

十一假期回家,闲得没事儿去了老婆老家的山上闲逛,遇到此妇人,跟着她去打板栗,还给我送了好多,聊了一个多小时。自己和老伴儿在老家,几个儿女现在也都在外面,最远的还在北京,都过得还很不错,儿女们也都还很孝顺,都想着接他们出去住,但是她住习惯了家里,还是待在老家吧,聊了一个多小时后,本来还想着带我去看看另外一棵树的板栗熟了没,后来想想,出来一两个小时了,再不回去,老伴儿又得担心了,下次有机会再来吧……

_DSC5925.jpg

_DSC5923.jpg

_DSC5915.jpg

还是13号,在逛了一整天之后,回到望京SOHO,等到七点多,拍了夜景。

望京SOHO夜景

望京SOHO夜景

等了两个多小时,没天黑之前是下面这样的:

望京SOHO

望京SOHO

望京SOHO

望京SOHO

望京SOHO

望京SOHO

2015年9月13日,按计划,带着 Sony A7II (16-35/55定焦),扫一遍故宫,争取第一批进入故宫,一路直奔中轴线几大殿,为了在每有太多人的情况下,扫完整个中轴线,然后带着55定焦定点折返扫一遍,最后去参观一下清明上河图,最后再定焦扫回后门,出后门后,扫一次角楼,然后上景山,北海公园,入后海。

故宫三条线路

  • 中轴线:太和门三大殿→乾清门→乾清宫→交泰殿→坤宁宫→御花园→神武门(从神武门可以进入景山公园)
  • 东路:午门→太和门三大殿→乾清门→东六宫→宁寿宫→珍妃井
  • 西路:午门→太和门三大殿→乾清门→西六宫→慈宁宫→养心殿→漱芳斋

我的足迹

计划得还成吧,基本上就是按这个行程走的,不过技术有限,对于故宫,我还不知道怎么拍更好,大场景不会控制,小细节还稍稍好点儿,一个上午就逛完了,所以下午还去了雍和宫、后海、铜锣鼓巷、恭王府,最后还去了望京SOHO拍了夜景,不过这里就只发故宫的了。

照片

图片太多,可能需要几天慢慢地上。

中轴线

太和门

太和门

太和门,是紫禁城内最大的宫门,也是紫禁城外朝宫殿的正门。是自天安门南侧向北进紫禁城时经过的第四道门(前三道依次为天安门、端门、午门)。

太和门建成于明朝永乐十八年(1420年),初称“奉天门”。明朝嘉靖三十七年六月辛卯重建改称“大朝门”,嘉靖四十一年(1562年)改称“皇极门”[来源请求]。清朝顺治二年(1645年)改称“太和门”。清朝顺治三年(1646年)、嘉庆七年(1802年)均曾重修。光绪十四年,太和门西侧的贞度门失火,殃及太和门与昭德门,三门均被焚毁,光绪十五年重建。光绪十四年十二月十五日(1889年1月16日)深夜,太和门护军值班房因护军熟睡,油灯点着门柱引发火灾。虽然派出了7000多人次救火,大火依然烧了两天,太和门被焚毁。[4]光绪十五年正月二十七日(1889年2月26日),为光绪帝大婚的吉日。按照清朝制度,大婚皇后须经太和门进宫。仅剩42天时间,重修太和门已来不及,清廷遂令北京的棚匠扎彩工,搭成一座彩棚太和门,以假乱真,在光绪帝大婚时使用。震钧《天咫偶闻》载:“……大婚,不及修建,乃以札彩为之。高卑广狭无少差。至榱桷之花纹,鸱吻之雕镂,瓦沟之广狭,无不克肖。虽久执事内廷者,不能辨其真伪。而且高逾十丈,栗冽之风,不少动摇,技至此神也! ”

明朝时,太和门是“御门听政”之处,皇帝在太和门接受臣下朝拜及上奏,颁布诏令,处理政事。清朝初年,皇帝也曾在太和门听政、赐宴,后来“御门听政”改在乾清门进行。清朝顺治元年九月(1644年),清朝统治者定鼎北京之后,首位皇帝顺治帝在太和门颁布大赦令。

太和门左、右各设有一门,东为昭德门,西为贞度门。

  • 昭德门:明朝永乐十八年(1420年)建成,初称“东角门”。嘉靖四十一年(1562年)改称“弘政门”。清朝顺治二年(1645年)改称“昭德门”。明朝为考选鸿胪之地。清朝为侍卫值宿处。
  • 贞度门:明朝永乐十八年(1420年)建成,初称“西角门”。嘉靖四十一年(1562年)改称“宣治门”。清朝顺治二年(1645年)改称“贞度门”。清朝为侍卫值宿处。

1959年,进行了太和门及前三殿的油饰彩画工程。2003年,故宫大修工程启动。2007年冬,太和门的维修工程结束。2008年7月16日起,维修竣工的太和门、太和殿、神武门重新对游客开放。

太和门

太和殿

太和殿

太和殿

太和殿

太和殿

太和殿

太和殿

中和殿

中和殿

中和殿

中和殿

中和殿

中和殿

保和殿

保和殿

保和殿

保和殿

保和殿

乾清门

乾清门

乾清宫

乾清宫

乾清宫

乾清宫

交泰殿

交泰殿

交泰殿

交泰殿

交泰殿

交泰殿

坤宁宫

坤宁宫

坤宁宫

坤宁宫

东线

_DSC1959.jpg

_DSC1960.jpg

_DSC1962.jpg

_DSC1965.jpg

_DSC1966.jpg

_DSC1967.jpg

_DSC1969.jpg

_DSC1975.jpg

_DSC1977.jpg

_DSC1978.jpg

_DSC1980.jpg

_DSC1981.jpg

_DSC1985.jpg

_DSC1987.jpg

_DSC1988.jpg

_DSC1998.jpg

_DSC2007.jpg

_DSC2008.jpg

_DSC2009.jpg

_DSC2011.jpg

_DSC2012.jpg

_DSC2013.jpg

_DSC2014.jpg

_DSC2015.jpg

_DSC2016.jpg

_DSC2018.jpg

_DSC2019.jpg

_DSC2020.jpg

_DSC2022.jpg

_DSC2027.jpg

_DSC2028.jpg

_DSC2029.jpg

_DSC2030.jpg

_DSC2032.jpg

_DSC2034.jpg

_DSC2035.jpg

_DSC2036.jpg

_DSC2037.jpg

_DSC2038.jpg

_DSC2040.jpg

_DSC2042.jpg

_DSC2043.jpg

_DSC2046.jpg

_DSC2047.jpg

_DSC2050.jpg

_DSC2051.jpg

_DSC2052.jpg

_DSC2053.jpg

_DSC2059.jpg

_DSC2061.jpg

_DSC2062.jpg

_DSC2064.jpg

_DSC2066.jpg

_DSC2069.jpg

_DSC2070.jpg

_DSC2071.jpg

_DSC2072.jpg

_DSC2073.jpg

西线

_DSC2075.jpg

_DSC2076.jpg

_DSC2080.jpg

_DSC2081.jpg

_DSC2082.jpg

_DSC2092.jpg

_DSC2093.jpg

_DSC2094.jpg

_DSC2096.jpg

_DSC2097.jpg

_DSC2099.jpg

_DSC2101.jpg

_DSC2102.jpg

_DSC2103.jpg

_DSC2104.jpg

_DSC2107.jpg

_DSC2108.jpg

_DSC2109.jpg

_DSC2113.jpg

_DSC2114.jpg

_DSC2115.jpg