JAR 文件包

JAR 文件就是 Java Archive File，顾名思意，它的应用是与 Java 息息相关的，是 Java 的一种文档格式。JAR 文件非常类似 ZIP 文件——准确的说，它就是 ZIP 文件，所以叫它文件包。JAR 文件与 ZIP 文件唯一的区别就是在 JAR 文件的内容中，包含了一个 META-INF/MANIFEST.MF 文件，这个文件是在生成 JAR 文件的时候自动创建的。

深入了解jar的详细信息，请看他的官方文档。
google或者百度是度很难搜索到官方文档，我偶然看一个开原框架的中，它使用SPI扩展协议，使用到META-INF，而且给出了一个英文链接。是oracle的官方网介绍。
https://docs.oracle.com/javase/1.5.0/docs/guide/jar/jar.html#Intro

Introduction
jar 是基于zip的，把多个文件打成一片一个包。jar本质上是一个zip文件，并且包含了一个META-INF文件夹，这是ZIP不具有的。一个jar包可以用jar命令创建，具体的API可以参见java.util.jar. 对于命名，他并没有严格的要求，可以是合法的任何名称。

在很多场合，jar包里的文件并不是简单的聚合了classes文件或者资源文件。他还可以用来blocks应用和扩展.其中META-INF目录，用于存储包和扩展信息，包括了安全，版本，护展和服务等信息。
上文提到的SPI,就跟这个目录有关。以及之前提到到一个博客，spring,schema， 其中spring.handlers，spring.schemas这些文档都存放到这个目录，为什么要放把这两个文件放到META-INF下，而不是其他目录下，是有特别处理的。

The META-INF directory
META-INF下的文件和目录，是java2平台认可的和承认的。

    MANIFEST.MF
The manifest file that is used to define extension and package related data.
举例:
用maven打成jar信息

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: Administror
Build-Jdk: 1.6.0_45

用jdk的工具，打成jar包该文件的信息：

Manifest-Version: 1.0
Created-By: 1.6.0_45 (Sun Microsystems Inc.)

    MANIFEST.MF

The manifest file that is used to define extension and package related data.

    INDEX.LIST

This file is generated by the new "-i" option of the jar tool, which contains location information for packages defined in an application or extension.  It is part of the JarIndex implementation and used by class loaders to speed up their class loading process.

    x.SF

The signature file for the JAR file.  'x' stands for the base file name.

    x.DSA

The signature block file associated with the signature file with the same base file name. This file stores the digital signature of the corresponding signature file.

    services/

This directory stores all the service provider configuration files.

上面提到的这些文件，不是瞎写的，要求支持RFC822
见下面英文描述。

Name-Value pairs and Sections
Before we go to the details of the contents of the individual configuration files, some format convention needs to be defined. In most cases, information contained within the manifest file and signature files is represented as so-called "name: value" pairs inspired by the RFC822 standard.  We also call these pairs headers or attributes.

Groups of name-value pairs are known as a "section". Sections are separated from other sections by empty lines.

Binary data of any form is represented as base64. Continuations are required for binary data which causes line length to exceed 72 bytes. Examples of binary data are digests and signatures.

Implementations shall support header values of up to 65535 bytes.

All the specifications in this document use the same grammar in which terminal symbols are shown in fixed width font and non-terminal symbols are shown in italic type face.
Specification:
  section:                       *header +newline
  nonempty-section:      +header +newline
  newline:                      CR LF | LF | CR (not followed by LF)
  header:                       name : value
  name:                         alphanum *headerchar
  value:                          SPACE *otherchar newline *continuation
  continuation:              SPACE *otherchar newline
  alphanum:                  {A-Z} | {a-z} | {0-9}
  headerchar:                alphanum | - | _
  otherchar:                  any UTF-8 character except NUL, CR and LF

; Also: To prevent mangling of files sent via straight e-mail, no
; header will start with the four letters "From".
 

Non-terminal symbols defined in the above specification will be referenced in the following specifications. 

有几点需要注意，每个mainfease信息由name和value构成，同一个文件中出现两个name,那么后一个name覆盖前面的的信息，如果不指定value,默认value与name相同.信息以空行来划分。