从 WAR 中复制 DLL 会导致 LF 变成 CRLF

Question

我正在使用 Java 本机接口在我的 Java 应用程序中包含一些静态编译的代码。特别是，我有一个 DLL 文件，其中包含我的应用程序的 WAR 中的编译代码。

不幸的是，类加载器无法从 WAR 内部加载 DLL（根据初步研究...如果这是错误的，请务必告诉我！）。所以我必须将 DLL 复制到临时文件夹，然后从那里加载它。

但是，当我尝试加载复制的 DLL 时，出现 java.lang.UnsatisfiedLinkError: C:\path\to\dll\VIX.dll: %1 不是有效的 Win32 应用程序。文件大小看起来相同（根据 Windows，均为 401K），但就是行不通。下面是执行复制的代码：

InputStream ReadDLL = Thread.currentThread().getContextClassLoader().getResourceAsStream("/VIX.dll");

File file = new File(workDir, "VIX.dll");
OutputStream WriteDLL = null;
try {
    WriteDLL = new FileOutputStream(file);
} catch (FileNotFoundException e1) {
    // TODO Auto-generated catch block
    e1.printStackTrace();
}

byte[] buffer = new byte[1024];
int numchars;
try {
    while((numchars = ReadDLL.read(buffer)) > 0) {
        WriteDLL.write(buffer, 0, numchars);
    }
    ReadDLL.close();
    WriteDLL.close();
} catch (IOException e) {
    e.printStackTrace();
}

比较 DLL 的原始版本和复制版本，我发现原始版本中字节 0x0A（ASCII 换行符）的每个实例都被替换为两个字节：0x0D0A（ASCII CRLF） 。当然，这是一个 DLL，0x0A 实际上并不是换行符，只是一个二进制操作码。但出于某种原因，Java 坚持为我做这个有用的翻译。

最后，通过调用 Thread.currentThread().getContextClassLoader().getResourceAsStream(fileName); 获取 ReadDLL InputStream，显然，fileName 是我的文件的名称。

Answer 1

两个假设：

1. 也许 DLL 是通过使用默认 ASCII 模式（使用 bin 模式进行 FTP 传输）的 UNIX 到 Windows FTP 传输修改的。
2. 也许 DLL 在修订控制系统中被视为 ASCII 文件，并在 Windows 系统上检出。

尝试解压 WAR 并查看它是原始版本还是修改版本。

我没有看到任何 Java 或 webapp 服务器会在你背后执行该转换的情况。