Jar包分析-META-INF文件夹
前言
在我们使用Jar包的时候，有一个特殊的文件夹META-INF，那么他的作用是什么呢，我们来看一看
官网解释
JAR file is a file format based on the popular ZIP file format and is used for aggregating many files into one. A JAR file is essentially a zip file that contains an optional META-INF directory. A JAR file can be created by the command-line jar tool, or by using the java.util.jar API in the Java platform. There is no restriction on the name of a JAR file, it can be any legal file name on a particular platform.
JAR文件是一种基于流行的ZIP文件格式的文件格式，用于将多个文件聚合为一个文件。JAR文件本质上是一个zip文件，它包含一个可选的META-INF目录。JAR文件可以由命令行JAR工具创建，也可以使用Java平台中的Java .util. JAR API创建。对于JAR文件的名称没有限制，它可以是特定平台上的任何合法文件名。
In many cases, JAR files are not just simple archives of java classes files and/or resources. They are used as building blocks for applications and extensions. The META-INF directory, if it exists, is used to store package and extension configuration data, including security, versioning, extension and services.**
在许多情况下，JAR文件不仅仅是java类文件和/或资源的简单归档。它们被用作应用程序和扩展的构建块。META-INF目录(如果存在的话)用于存储包和扩展配置数据，包括安全性、版本控制、扩展和服务。
The META-INF directory
The following files/directories in the META-INF directory are recognized and interpreted by the Java 2 Platform to configure applications, extensions, class loaders and services:
以下在META-INF目录中的文件/目录被Java 2平台识别和解释，以配置应用程序、扩展、类加载器和服务:
- 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.
这个文件是由jar工具的新“-i”选项生成的，它包含在应用程序或扩展中定义的包的位置信息。它是JarIndex实现的一部分，类装入器使用它来加速类装入过程。
- x.SF
The signature file for the JAR file. ‘x’ stands for the base file name.
JAR文件的签名文件。'x’表示基本文件名。
- 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.
此目录存储所有服务提供程序配置文件。
MANIFEST.MF
我们着重来看一下这个文件，这个文件可以定义很多属性，这些属性在我们执行Jar命令的时候会被解析出来，具体解析都在java.util.jar 这个包内
以Nacos-discovery为例：
Manifest-Version: 1.0
Implementation-Title: Spring Cloud Starter Alibaba Nacos Discovery
Implementation-Version: 2.2.1.RELEASE
Built-By: mercy
Implementation-Vendor-Id: com.alibaba.cloud
Created-By: Apache Maven 3.6.0
Build-Jdk: 1.8.0_172
Implementation-URL: https://github.com/alibaba/spring-cloud-alibaba/sp
ring-cloud-alibaba-starters/spring-cloud-starter-alibaba-nacos-discov
ery
Implementation-Vendor: Pivotal Software, Inc.
这些定义就是Nacos-Discovery定义的关于此Jar包相关的定义
具体说明我就直接截图展示来
SERVICES
在META-INF/services目录中的文件是服务提供者配置文件。服务是一组众所周知的接口和(通常是抽象的)类。服务提供者是服务的特定实现。提供程序中的类通常实现在服务本身中定义的接口和类的子类。服务提供者可以以扩展的形式安装在Java平台的实现中，也就是说，将jar文件放在任何通常的扩展目录中。提供程序还可以通过将它们添加到applet或应用程序类路径，或者通过其他特定于平台的方法来提供。
服务由抽象类表示。给定服务的提供程序包含一个或多个具体类，这些类使用特定于提供程序的数据和代码扩展此服务类。这个provider类通常不是整个provider本身，而是一个代理，它包含足够的信息来决定provider是否能够满足特定的请求，以及可以根据需要创建实际provider的代码。提供者类的细节往往是高度特定于服务的;没有一个类或接口可以统一它们，因此没有定义这样的类。这里强制执行的唯一要求是，提供程序类必须有一个零参数的构造函数，以便在查找期间可以实例化它们。
Example
假设我们有一个名为java.io.si.charcodec的服务类。它有两种抽象的方法:
public abstract CharEncoder getEncoder(String encodingName);
public abstract CharDecoder getDecoder(String encodingName);
每个方法都返回一个适当的对象，如果它不能转换给定的编码，则返回null。典型的CharCodec提供程序将支持多种编码。
如果sun.io.StandardCodec是CharCodec服务的提供者，那么它的jar文件将包含文件META-INF/services/java.io.spi.CharCodec。该文件将包含一行:
sun.io.StandardCodec #Standard codecs for the platform
为一个给定的编码名称定位编码器，内部的I/O代码会做这样的事情:
CharEncoder getEncoder(String encodingName) {
Iterator ps = Service.providers(CharCodec.class);
while (ps.hasNext()) {
CharCodec cc = (CharCodec)ps.next();
CharEncoder ce = cc.getEncoder(encodingName);
if (ce != null)
return ce;
}
return null;
}
提供程序查找机制总是在调用者的安全上下文中执行。受信任的系统代码通常应该从特权安全上下文中调用该类中的方法。