windowspe详细介绍
【菜科解读】
pe文件结构图PE文件被称为可移植的执行体是Portable Execute的全称，常见的EXE、DLL、OCX、SYS、COM都是PE文件，PE文件是微软Windows操作系统上的程序文件（可能是间接被执行，如DLL） 一个操作系统的可执行文件格式在很多方面是这个系统的一面镜子。
虽然学习一个可执行文件格式通常不是一个程序员的首要任务，但是你可以从这其中学到大量的知识。
在这篇文章中，我会给出 MicroSoft 的所有基于 win32系统（如winnt,win9x）的可移植可执行（PE）文件格式的详细介绍。
在可预知的未来，包括 Windows2000 , PE 文件格式在 MicroSoft 的操作系统中扮演一个重要的角色。
如果你在使用 Win32 或 Winnt ，那么你已经在使用 PE 文件了。
甚至你只是在 Windows3.1 下使用 Visual C++ 编程，你使用的仍然是 PE 文件（Visual C++ 的 32 位 MS-DOS 扩展组件用这个格式）。
简而言之，PE 格式已经普遍应用，并且在不短的将来仍是不可避免的。
现在是时候找出这种新的可执行文件格式为操作系统带来的东西了。
我最后不会让你盯住无穷无尽的十六进制Dump，也不会详细讨论页面的每一个单独的位的重要性。
代替的，我会向你介绍包含在 PE 文件中的概念，并且将他们和你每天都遇到的东西联系起来。
比如，线程局部变量的概念，如下所述： declspec(thread) int i; 我快要发疯了，直到我发现它在可执行文件中实现起来是如此的简单并且优雅。
既然你们中的许多人都有使用 16 Windows 的背景，我将把 Win32 PE 文件的构造追溯到和它等价的16 位 NE 文件。
除了一个不同的可执行文件格式， MicroSoft 还引入了一个用它的编译器和汇编器生成的新的目标模块格式。
这个新的 OBJ 文件格式有许多和PE 文件共同的东东。
我做了许多无用功去查找这个新的 OBJ 文件格式的文档。
所以我以自己的理解对它进行解析，并且，在这里，除了 PE 文件，我会描述它的一部分。
大家都知道，Windows NT 继承了 VAX? VMS? 和 UNIX? 的传统。
许多 Windows NT 的创始人在进入微软前都在这些平台上进行设计和编码。
当他们开始设计 Windows NT 时，很自然的，为了最小化项目启动时间，他们会使用以前写好的并且已经测试过的工具。
用这些工具生成的并且工作的可执行和 OBJ 文件格式叫做 COFF （Common Object File Format 的首字母缩写）。
COFF 的相对年龄可以用八进制的域来指定。
COFF 本身是一个好的起点，但是需要扩展到一个现代操作系统如 Windows 95 和 Windows NT 的需要。
这个更新的结果就是（PE格式）可移植可执行文件格式。
它被称为"可移植的"是因为在所有平台（如x86,Alpha,MIPS等等）上实现的WindowsNT 都使用相同的可执行文件格式。
当然了，也有许多不同的东西如二进制代码的CPU指令。
重要的是操作系统的装入器和程序设计工具不需要为任何一种CPU完全重写就能达到目的。
MicroSoft 抛弃现存的32位工具和可执行文件格式的事实证实了他们想让 WindowsNT 升级并且运行的更快的决心。
为16位Windows编写的虚拟设备驱动程序用一种不同的32位文件布局--LE 文件格式--WindowsNT出现很早以前就存在了。
比这更重要的是对 OBJ 文件的替换！在 WindowsNT 的 C 编译器以前，所有的微软编译器都用 Intel 的 OMF ( Object Module Format ) 规范。
就像前面提到的，MicroSoft 的 Win32 编译器生成 COFF 格式的 OBJ 文件。
一些微软的竞争者，如 Borland 和 Symentec ，选择放弃了 COFF 格式并坚持 Intel 的 OMF 文件格式。
这样的结果是制作 OBJ 和 LIB 的公司为了使用多个不同的编译器，不得不为每个不同的编译器分发这些库的不同版本（如果他们不这么做）。
PE 文件格式在 winnt.h 头文件中文档化了（用最不精确的语言）!大约在 winnt.h 的中间部分标题为"Image Format"的一个快。
在把 MS-DOS 的 MZ 文件头和 NE 文件头移入新的PE文件头之前，这个块就开始于一个小栏。
WINNT.H提供PE文件用到的生鲜数据结构的定义，但只有很少有助于理解这些数据结构和标志变量的注释。
不管谁为PE文件格式写出这样的头文件都肯定是一个信徒无疑（突然持续地冒出Michael J. O'Leary的名字来）。
描述名字，连同深嵌的结构体和宏。
当你配套winnt.h进行编码时，类似下面这样的表达式并不鲜见： pNTHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_DEBUG] .VirtualAddress; 为了有助于逻辑的理解这些winnt.h中的信息，阅读可移植可执行和公共对象文件格式的规格说明，这些在MSDN既看光盘中是可用的，一直包括到2001年8月。
现在让我们转换到COFF格式的OBJ文件的主体上来，WINNT.H包括COFF OBJ和LIB的结构化定义和类型定义。
不幸的是，我还没有找到上面提到的可执行文件格式的类似文档。
既然PE文件和COFF OBJ文件是如此的相似，我决定是时间把这些文件带到重点上来，并且把它们也文档化。
仅仅读过了关于PE文件的组成，你自己也想Dump一些PE文件来看这些概念。
如果你用微软基于32位WINDOWS的开发工具，DUMPBIN 程序可以将PE文件和COFF OBJ/LIB文件转化为可读的形式。
在所有的PEDump器中，DUMPBIN是最容易理解的。
它恰好有一些很好的选项来反汇编它正解析的文件的代码块，Borland用户可以使用tdump来浏览PE文件，但tdump不能解析 COFF OBJ/LIB 文件。
这不是一个重要的东西因为Borland的编译器首先就不生成 COFF 格式的OBJ文件。
我写了一个PE和COFF OBJ 文件的Dump程序--PEDUMP，我想提供一些比DUMPBIN更加可理解的输出。
虽然它没有反汇编器以及和LIB库文件一起工作，它在其他方面和DUMPBIN是一样的，并且加入了一些新的特性来使它值得被认同。
它的源代码在任何一个MSJ电子公报版上都可以找到，所有我不打算在这里把他全部列出。
作为代替，我展示一些从PEDUMP得到的示例输出来阐明我为它们描述的概念。
译注：--说实话，我从这这份代码中几乎唯一学到的东西就是"如何处理命令行"，其它的都没学到。
表 1 PEDUMP.C file://--------------------/ // PROGRAM: PEDUMP // FILE: PEDUMP.C // AUTHOR: Matt Pietrek - 1993 file://--------------------/ #include #include #include "objdump.h" #include "exedump.h" #include "extrnvar.h" // Global variables set here, and used in EXEDUMP.C and OBJDUMP.C BOOL fShowRelocations = FALSE; BOOL fShowRawSectionData = FALSE; BOOL fShowSymbolTable = FALSE; BOOL fShowLineNumbers = FALSE; char HelpText[] = "PEDUMP - Win32/COFF .EXE/.OBJ file dumper - 1993 Matt Pietrek\n\n" "Syntax: PEDUMP [switches] filename\n\n" " /A include everything in dump\n" " /H include hex dump of sections\n" " /L include line number information\n" " /R show base relocations\n" " /S show symbol table\n"; // Open up a file, memory map it, and call the appropriate dumping routine void DumpFile(LPSTR filename) HANDLE hFile; HANDLE hFileMapping; LPVOID lpFileBase; PIMAGE_DOS_HEADER dosHeader; hFile = CreateFile(filename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); if ( hFile = = INVALID_HANDLE_VALUE ) { printf("Couldn't open file with CreateFile()\n"); return; } hFileMapping = CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 0, NULL); if ( hFileMapping = = 0 ) { CloseHandle(hFile); printf("Couldn't open file mapping with CreateFileMapping()\n"); return; lpFileBase = MapViewOfFile(hFileMapping, FILE_MAP_READ, 0, 0, 0); if ( lpFileBase = = 0 ) CloseHandle(hFileMapping); CloseHandle(hFile); printf("Couldn't map view of file with MapViewOfFile()\n"); return; printf("Dump of file %s\n\n", filename); dosHeader = (PIMAGE_DOS_HEADER)lpFileBase; if ( dosHeader->e_magic = = IMAGE_DOS_SIGNATURE ) { DumpExeFile( dosHeader ); } else if ( (dosHeader->e_magic = = 0x014C) // Does it look like a i386 && (dosHeader->e_sp = = 0) ) // COFF OBJ file??? // The two tests above aren't what they look like. They're // really checking for IMAGE_FILE_HEADER.Machine = = i386 (0x14C) // and IMAGE_FILE_HEADER.SizeOfOptionalHeader = = 0; DumpObjFile( (PIMAGE_FILE_HEADER)lpFileBase ); else printf("unrecognized file format\n"); UnmapViewOfFile(lpFileBase); CloseHandle(hFileMapping); CloseHandle(hFile); // process all the command line arguments and return a pointer to // the filename argument. PSTR ProcessCommandLine(int argc, char *argv[]) int i; for ( i=1; i e_lfanew; 一旦你有了PE主首部的指针，游戏就可以开始了！PE主首部是一个IMAGE_NT_HEADERS的结构，在WINNT.H中定义。
这个结构由一个双字（DWORD）和两个子结构组成，布局如下： DWORD Signature; IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER OptionalHeader; 标志域用ASCII表示就是"PE"。
如果在DOS首部中用了e_lfanew域，你得到一个NE标志而不是PE，那么这是16位NE文件。
同样的，在标志域中的LE表示这是一个Windows3.x 的虚拟设备驱动程序（VxD）。
LX表示这个文件是OS/2 2.0文件。
PE DWORD标志后的是结构 IMAGE_FILE_HEADER 。
这个域只包含这个文件最基本的信息。
这个结构表现为并未从它的原始COFF实现更改过。
除了是PE首部的一部分，它还表现在微软Win32编译器生成的COFF OBJ 文件的最开始部分。
IMAGE_FILE_HEADER的这个域显示在下面： 表2 IMAGE_FILE_HEADER Fields WORD Machine 表示CPU的类型，下面定义了一些CPU的ID 0x14d Intel i860 0x14c Intel I386 (same ID used for 486 and 586) 0x162 MIPS R3000 0x166 MIPS R4000 0x183 DEC Alpha AXP WORD NumberOfSections 这个文件中的块数目。
DWORD TimeDateStamp 连接器产生这个文件的日期（对OBJ文件是编译器），这个域保存的数是从1969年12月下午4:00开始到现在经过的秒数。
DWORD PointerToSymbolTable COFF符号表的文件偏移量。
这个域只用于有COFF调试信息的OBJ文件和PE文件，PE文件支持多种调试信息格式，所以调试器应该指向数据目录的IMAGE_DIRECTORY_ENTRY_DEBUG条目。
DWORD NumberOfSymbols COFF符号表的符号数目。
见上面。
WORD SizeOfOptionalHeader 这个结构后面的可选首部的尺寸。
在OBJ文件中，这个域是0。
在可执行文件中，这是跟在这个结构后的IMAGE_OPTIONAL_HEADER结构的尺寸。
WORD Characteristics 关于这个文件信息的标志。
一些重要的域如下： 0x0001 这个文件中没有重定位信息 0x0002 可执行文件映像（不是OBJ或LIB文件） 0x2000 文件是动态连接库，而非程序 其它域定义在WINNT.H中。
PE首部的第三个组成部分是一个IMAGE_OPTIONAL_HEADER型的结构。
对PE文件，这一部分当然不是"可选的"。
COFF格式允许单独实现来定义一个超出标准IMAGE_FILE_HEADER附加信息的结构。
IMAGE_OPTIONAL_HEADER里面的域是PE的实现者感到超出IMAGE_FILE_HEADER基本信息以外非常关键的信息。
并非 IMAGE_OPTIONAL_HEADER 的所有域都是重要的（见图4）。
比较重要，需要知道的是ImageBase 和 SubSystem 域。
你可以忽略其它域的描述。
表3 IMAGE_FILE_HEADER 的域： WORD Magic 表现为一些类别的标志字，通常是0X010B 。
BYTE MajorLinkerVersion BYTE MinorLinkerVersion 生成这个文件的连接器的版本。
这个数字以十进制显示比用十六进制好。
一个典型的连接器版本是2.23。
DWORD SizeOfCode 所有代码块的进位尺寸。
通常大多数文件只有一个代码块，所以这个域和 .TEXT 块匹配。
DWORD SizeOfInitializedData 已初始化的数据组成的块的大小（不包括代码段）。
然而，和它在文件中的表现形式并不一致。
DWORD SizeOfUninitializedData 载入器在虚拟内存中申请空间，但在磁盘上的文件中并不占用空间的块的尺寸。
这些块在程序启动时不需要指定初值，因此术语名就是"未初始化的数据"。
未初始化的数据通常在一个名叫 .bss 的块中。
DWORD AddressOfEntryPoint 载入器开始执行这个程序的地址，即这个PE文件的入口地址。
这是一个RVA，通常在 .text 块中。
DWORD BaseOfCode 代码块起始地址的RVA 。
在内存中，代码块通常在PE首部之后，数据块之前。
在微软的连接器产生的EXE文件中，这个值通常是0x1000 。
Borland 的连接器 TLINK32 也一样，把映像第一个代码块的RVA和映像基址相加，填入这个域。
译注：这个域好像一直没有什么用 DWORD BaseOfData 数据块起始地址的RVA 。
在内存中，数据块经常在最后，在PE首部和代码块之后。
译注：这个域好像也一直没有什么用 DWORD ImageBase 连接器创建一个可执行文件时，它假定这个文件被映射到内存中的一个指定的地方，这个地址就存在这个域中，假定一个载入地址可以使连接器优化以便节省空间。
如果载入器真的把这个文件映射到了这个地方，在运行之前代码不需要任何改变。
在为WindowsNT 创建的可执行文件中，默认的ImageBase 是0x10000。
对DLL，默认是0x40000。
在Window95中，地址0x10000不能用来载入32位EXE文件，因为这个区域在一个被所有进程共享的线性地址空间中。
因此，微软把Win32可执行文件的默认基址改为0x40000，假定基址为0x10000 的老程序坐在Windows95 中需要更长的载入时间，这是因为载入器需要重定位基址。
译注：这个域即"Prefered Load Address"，如果没有什么意外，这就是该PE文件载入内存后的地址。
DWORD SectionAlignment 映射到内存中时，每个块都必须保证开始于这个值的整数倍。
为了分页的目的，默认的SectionAlignment 是 0x1000。
DWORD FileAlignment 在PE文件中，组成每个块的生鲜数据必须保证开始于这个值的整数倍。
默认值是0x200 字节，也许是为了保证块都开始于一个磁盘扇区（一个扇区通常是 512 字节）。
这个域和NE文件中的段/资源对齐（segment/resource alignment）尺寸是等价的。
和NE文件不同的是，PE文件通常没有数百个的块，所以，为了对齐而浪费的通常空间很少。
WORD MajorOperatingSystemVersion WORD MinorOperatingSystemVersion 这个程序运行需要的操作系统的最小版本号。
这个域有点含糊，因为Subsystem 域（后面将会说到）可以提供类似的功能。
这个域在到目前为止的Win32中默认是1.0。
WORD MajorImageVersion WORD MinorImageVersion 一个可由用户定义的域。
这允许你有不同的EXE和DLL版本。
你可以通过链接器的 /version 选项设置这个域的值。
例如："link /version:2.0 myobj.obj"。
WORD MajorSubsystemVersion WORD MinorSubsystemVersion 这个程序运行需要的最小子系统版本号。
这个域的一个典型值是3.10 （表示WindowsNT 3.1）。
DWORD Reserved1 通常是 0 。
DWORD SizeOfImage 载入器必须关心的这个映像所有部分的大小总和。
是从映像的开始到最后一个块结尾这段区域的大小。
最后一个块结尾按SectionAlignment进位。
译注：这个很重要，可以大，但不可以小！ DWORD SizeOfHeaders PE首部和块表的大小。
块的实际数据紧跟在所有首部组件之后。
DWORD CheckSum 这个文件的CRC校验和。
在微软可执行格式中，这个域被忽略并且置为0 。
这个规则的一个例外情况是信任服务，这类EXE文件必须有一个合法的校验和。
WORD Subsystem 可执行文件的用户界面使用的子系统类型。
WINNT.H 定义了下面这些值： NATIVE 1 不需要子系统（比如设备驱动） WINDOWS_GUI 2 在Windows图形用户界面子系统下运行 WINDOWS_CUI 3 在Windows字符子系统下运行（控制台程序） OS2_CUI 5 在OS/2字符子系统下运行（仅对OS/2 1.x） POSIX_CUI 7 在 Posix 字符子系统下运行 WORD DllCharacteristics 指定在何种环境下一个DLL的初始化函数（比如DllMain）将被调用的标志变量。
这个值经常被置为0 。
但是操作系统在下面四种情况下仍然调用DLL的初始化函数。
下面的值定义为： 1 DLL第一次载入到进程中的地址空间中时调用 2 一个线程结束时调用 4 一个线程开始时调用 8 退出DLL时调用 DWORD SizeOfStackReserve 为初始线程保留的虚拟内存总数。
然而并不是所有这些内存都被提交（见下一个域）。
这个域的默认值是0x100000（1Mbytes）。
如果你在CreateThread 中把堆栈尺寸指定为 0 ，结果将是用这个相同的值（0x10000）。
DWORD SizeOfStackCommit 开始提交的初始线程堆栈总数。
对微软的连接器，这个域默认是0x1000字节（一页），TLINK32 是两页。
DWORD SizeOfHeapReserve 为初始进程的堆保留的虚拟内存总数。
这个堆的句柄可以用GetPocessHeap 得到。
并不是所有这些内存都被提交（见下一个域）。
DWORD SizeOfHeapCommit 开始为进程堆提交的内存总数。
默认是一页。
PE文件格式 1.PE文件的含义 PE文件的意思是Portable Executable(可移植,可执行),它是win32可执行文件的标准格式.它的一些特性继承unix的COFF文件格式,同时保留了与旧版MS-DOS和WINDOWS的兼容.其可移植可执行意味着是跨win32平台的. 2.PE文件的层次结构 PE文件最前面紧随DOS MZ文件头的是一个DOS可执行文件(Stub).这使得PE文件成为一个合法的MS-DOS可执行文件.DOS MZ文件头后面是一个32位的PE文件标志0x50450000(IMAGE_NT_SIGNATURE),即PE00.接下来的是PE的映像文件头,包含的信息有该程序的运行平台,有多少个节,文件链接的时间,文件的命名格式.后面还紧跟一个可选映像头,包含PE文件的逻辑分布信息,程序加载信息,开始地址,保留的堆栈数量,数据段大小等.可选头还有一个重要的域,称为:数据目录表"的数组,表的每一项都是指向某一节的指针.可选映像头后面紧跟的是节表和节.节通过节表来实现索引.实际上,节的内容才是真正执行的数据和程序.每一个节都有相关的标志.每一个节会被一个或多个目录表指向,目录表可通过可选头的"数据目录表"的入口找到.就像输出函数表或基址重定位表.也存在没有目录表指向的节. 3.PE文件层次解释 A.DOS STUB和DOS头 DOS插桩程序在大多数情况下由汇编器/编译器自动产生.通常它调用INT 21H服务9来显示上述字符串.可以通过IMAGE_DOS_HEADER结构来识别一个合法的DOS头.这个结构的头两个字节肯定是"MZ".可通过该结构的e_lfanew成员来找到PE文件的开始标志.MS-DOS头部占据了PE文件的头64个字节.在微软的WINNT.H中可以找到其内容结构的描述. B.PE文件头 在DOS STUB后是PE文件头(PE header).PE文件头是PE相关结构IMGAE_NT_HEADERS的简称,即NT映像头,存放PE整个文件信息发布的重要字段,包含了PE装载器用到的重要域.执行体在操作系统中执行时,PE装载器将从DOS MZ头中找到PE头文件的起始偏移量e_lfanew,从而跳过DOS STUB直接定位真正的PE文件.它由3部分组成: (1)PE文件标志(4H字节) PE文件标志0x50450000即PE00,标志着NT映像头的开始,也是PE文件中与windows有关内容的开始. (2)映像文件(14H字节) 是NT映像文件的主要部分,包含PE文件的基本信息 (3)可选映像头 包含PE文件的逻辑分布信息. C.节表 节表其实是紧跟NT映像文件的一个结构数组.其成员数目由映像文件头结构NumberOFSectios域的值来决定. D.节 PE文件的真正内容划分为块,称之为节.节的划分基于各组数据的共同属性.惟有节的属性设置决定了节的特性和功能.典型的windows NT应用程序可以具有9个节:.texr,.bss.rdata,.data,.rsrc,edata,idata,pdata,.debug 判断一个文件是否为PE文件 function TForm1.is_PE(FileName: string): boolean; var //检测指定文件是否有效PE文件 PEDosHead: TImageDosHeader; PENTHead: TImageNtHeaders; m_file: integer; begin Result := False; m_file := FileOpen(filename, fmOpenRead or fmShareDenyNone); //只读和其它任意 if m_File > 0 then try FileSeek(m_file, 0, soFromBeginning); //将指针挪至文件头 FileRead(m_file, PEDosHead, SizeOf(PEDosHead)); //读PEDosHead结构 FileSeek(m_file, PEDosHead._lfanew, soFromBeginning); //将指针挪至_lfanew FileRead(m_file, PENTHead, SizeOf(PENTHead)); //读PENTHead结构 finally FileClose(m_file); end; if (PENTHead.Signature = IMAGE_NT_SIGNATURE) then //检验文件头部第一个字的值是否等于 IMAGE_DOS_SIGNATURE Result := True; end; pe文件结构图
红鲫鱼是什么鱼？红鲫鱼介绍
草鱼的做法有很多，如红烧草鱼，清蒸草鱼，糖醋草鱼等等，今天我们要做的是一道非常简单的家常菜，也是我们家经常吃的一道菜，那就是酸菜鱼。
一：红鲫鱼是什么鱼,能吃吗因为阳光能杀菌，最好把红鲫鱼1、水蚤，又叫鱼虫或红虫，体棕色、红棕色、要经常换水，能增加氧气，但是换水不能用自来水，因为自来水含氯，红鲫鱼一遇到氯，几小时内就会死亡。
可以用山泉水、湖水、小溪水。
二：红鲫鱼是什么鱼图片近段时间以来，位于京杭大运河的南运河，每到农历的初一或十五，总有红色的鲫鱼从河中“冒出”，引发当地人好奇以及垂钓爱好者前来过瘾。
河中为啥频现红色的鲫鱼，而且还这么有规律。
为此，值得注意的是，不管鱼获多与少，几乎每人的水桶或鱼护中都有红色的鲫鱼。
当然，这也是钓鱼人久久不愿离开的原因。
为啥河中频现红色的鲫鱼？对此，不少钓鱼人介绍，每到农历初一或十五后的几天里，这条河中都能钓获红色的鲫鱼。
至于为啥如此有规律，其中就有钓鱼人谈到，农历初一或十五都有人来河中放生，放生鱼就包括这种红色的鲫鱼。
因此在“放生日”过后的几天里，河边站满垂钓者。
还有钓鱼人，正是摸清初一、十五有人放生的规律，不约而同来到这里垂钓。
而且不少人，对于有关部门在岸边喷刷的“水深危险，禁止垂钓”善意提醒都不顾及，甚至不顾生命危险，来到斜坡状的河岸底部垂钓。
三：红鲫鱼是什么鱼图片大全红鲫鱼~~~又名金鲫鱼，它是普通鲫鱼发生变异的红黄鲫鱼在人工饲养而形成的一个品种。
是金鱼最古老的一个品种。
颜色有火红、红白相间等，是一个很受欢迎的养殖品种。
鱼鳞是透明无色的，鱼的颜色是由鱼皮上的色素决定的，一开始是黄色的，是水底沙石的颜色。
后来发生了变异，成为红色的
朱元璋的儿子朱棣介绍 朱棣是朱元璋和马皇后儿子吗
在朱元璋建立明朝之后，李景隆被封为中山王，后来又被封为梁国公，可以说是非常厉害了。
但是他却不安分守己，经常做一些些违法乱纪的事情，最终被朱元璋下令处死。
那么李景隆究竟做了什么事情，让朱元璋如此生气呢？我们一起来看一下。
作者：萨沙本文章为萨沙原创，谢绝任何媒体转载7月30日明成祖朱棣在南京夺位登基：他的母亲其实是朝鲜人？历史上的今天，1402年7月30日明成祖朱棣在南京夺位登基。
朱棣有勇有谋，具备了一国之君的禀赋。
就中国历史来说，朱棣是可以排行前十的优秀皇帝。
然而，朱元璋却没有传位给朱棣，反而喜欢性格宽厚的太子朱标。
甚至朱标死后，朱元璋一样喜欢宽厚仁爱的孙子朱允炆。
然而无论是朱标还是朱允炆，就能力来说肯定比朱棣要差一截。
那么，为什么朱元璋会偏爱他们，不太喜欢朱棣呢？一般认为有两个原因：其一，朱棣同父亲很像，性格过于凶悍，不太讲亲情，为朱元璋所厌恶；其二，朱棣的生母是朝鲜人妃，并不受宠。
总之，朱棣被剥夺了继承权，还差点儿因为消藩送了命。
朱棣在位22年，明王朝呈现出经济繁荣、国力强盛的局面，史称“永乐盛世”。
这里就要说说朱棣的母亲。
很多人认为，朱棣的母亲是朝鲜人，妃。
南京《太常寺志》对孝陵神位的记载：“左一位，淑妃李氏，生懿文太子、秦王、晋王。
右一位妃，生成祖文皇帝。
” 太常寺是掌管皇家宗庙礼仪的机构，《太常寺志》对皇家血统的记载自然较为可靠。
朱棣上台以后销毁了《太常寺志》，这一说法仅仅是看过该书进士何乔远的回忆。
真实与否，现在很难确定。
今天听起来似乎不可思议，中国皇帝为什么会娶朝鲜妻子？其实，对历史有些了解的朋友就知道，这在元朝宫廷很正常。
元朝最后1个皇帝元惠宗，他的第三任正宫皇后奇皇后，就是高丽人。
奇皇后出生于今天的韩国京畿道高阳市，是贵族少女。
她天生丽质，被送到元朝宫廷成为惠宗的妃子，还生下了2个皇子。
北元的皇帝昭宗爱猷识理达腊，就是奇皇后所生。
在当年，蒙古贵族迎娶高丽贵族少女是寻常事。
从皇帝到王公大臣，很多高丽妻子。
当时历史记载：元朝达官贵人们都以拥有高丽女仆以炫耀，女仆少且“质量”差的，往往被人取笑。
因此，元朝不断向高丽索取女子。
1287年，元世祖下旨要求高丽的处女必须先告官登记，否则不得出嫁。
1307年，高丽王廷下令，全国13岁以上16岁以下的女子，不得擅自出嫁，以优先供元朝挑选。
自1275到1347年，高丽共遣使赴元献处女16次。
高丽的王室女子、贵族女子，更是以献给元朝皇帝或王公大臣为荣。
两家的姻亲关系也因此更加亲近，以至于元朝皇帝虽然换了不少，其中几个皇帝的家族还有相互敌对的，但与高丽的关系却一直十分亲密。
因此，元朝宫廷一度还流行了高丽热，崇尚高丽的一些风俗。
朱棣出生，是父亲朱元璋占领南京之后的事情！当时朱元璋已经是一方霸主，娶一个朝鲜妻子妃并不稀奇。
有意思的是，朱棣却并不承认自己是妃所生，而说是正宫皇后马娘娘的孩子。
一说朱棣夺位之前，明朝历史记录了他的生母是妃，马娘娘是养母。
朱棣夺位以后，为了体现自己的正统性，就将史书修改，说他和太子朱标一样都是马娘娘所生。
要知道，当年中国人对于正出和庶出，是非常看重的。
对于普通人来说，也只有正妻生的长子，才有资格继承家业。
如果是妾生的孩子，哪怕年龄比正妻的孩子年龄大，也没有继承权。
就比如袁绍和袁术兄弟，袁绍年龄大、能力强，但袁术却不服他，甚至出兵攻打他。
为啥？袁绍的母亲是小妾，袁术的母亲才是正妻。
按照当时礼法，袁绍没有资格以袁家继承人自居，袁术的狂怒可以理解。
况且，高丽妻子虽多，地位却不高。
以元惠宗的奇皇后为例，她明明生下了2个皇子，又深受皇帝宠爱。
第一任正宫皇后死掉以后，奇皇后就没有成为皇后。
原因很简单，大臣们认为她是高丽人，出生卑贱，不能做国母。
于是，奇皇后被迫又等了整整20年。
在第二任正宫皇后死了，她才成为皇后，已经50岁了。
道理也是一样。
朱棣可能是畏惧有人非议生母出生卑贱，所以并不承认这种事。
本来弄死了大哥儿子朱允炆以上位，就不太光彩。
如果还有人质疑朱棣的生母血统，就是很大的政治危险了。
其实，妃生下朱棣不久就病死了。
朱棣和妃虽然有血缘关系，但完全是马娘娘抚养长大。
而马娘娘对他非常慈爱，当做亲生儿子一样。
朱棣同马娘娘也很亲密，感情很深。
1412年，为纪念明太祖和马皇后，开始修建大报恩寺及琉璃宝塔。
历时19年，花费250万两白银，动用数十万工人，才终于完工。
该建筑，位列“中古世界七大奇观”。
自然，目前我们只能推测朱棣母亲是妃、是高丽人，并没有确切的历史资料证明。
这是历史上的一个悬案。
不过，即便朱棣母亲的高丽人，就血统来说没什么影响。
世界各国都以父系血统认定民族，朱棣仍然是标准的汉人。
