Question

我注意到Windows上的Java环境（通过System.getenv（）调用获得）包含一些在真实环境中不存在的变量。这些以＆equals-sign开头并包含＆＃34; = ExitCode＆＃34;映射到在此java invokation之前运行的进程的退出代码;以及各种驱动器号的默认目录，例如＆＃34; = C：＆＃34;，＆＃34; = D：＆＃34;。在所有Windows版本上运行的Sun的所有Java版本似乎都是这种情况。这是在任何地方记录的，还是纯粹仅供Sun内部使用？

修改这是一个简单的示例应用程序来显示我的意思。在命令行上编译并运行它：

import java.util.Map;
class ShowEnv {
    public static void main(String[] args) {
        for (Map.Entry v : System.getenv().entrySet())
            System.out.printf("%-23s= %.54s%n", v.getKey(), v.getValue());
    }
}

然后将变量与SET命令（来自cmd.exe）或用C编写的类似命令行程序进行比较。您将找到以= don＆t; t开头的变量：

=ExitCode              = 00000000
=::                    = ::\
=C:                    = C:\Temp

这些变量显然是在执行JVM期间添加的。

Answer 1

以等号开头的系统变量是真实的。你观察到的不是Java 添加更多的环境变量;它是SET命令隐藏的一些变量。

Windows禁止在用户可以设置的环境变量名称中使用等号，因此在其中保留=的变量供内部使用。这些变量can be retrieved through windows APIs，例如GetEnvironmentStringsW。 Java库不会过滤此列表，因此特殊变量可用于您的代码。另一方面，Windows的SET命令将它们过滤掉，造成差异。

根据this answer，这些＆＃34;魔法＆＃34;变量用于向后兼容ms-dos目录处理，因此您可以安全地忽略它们。

Answer 2

Java的System.getenv（）显示了Java看到的环境变量。如果它与“真实”环境不同，那么运行Java和“真实”环境的方式就不同了。

首先，对你来说什么是“真实的”？它是cmd窗口吗？然后启动cmd需要一些步骤（例如非常过时但仍然有效的autoexec.bat）然后你有你的变量。如果“真实”对您来说意味着开始 - >计算机 - >属性 - >高级系统设置 - >环境变量，那么您仍然必须意识到这个特定过程如何开始以及如何获得它的变量。至少你可以看到系统变量和用户变量，并了解这不是一个简单的过程。就个人而言，我更喜欢cmd方式，因为在这里我使用命令SET并在当前时刻查看当前进程的实变量。当前时刻是另一个因素，因为变量可以根据某些行为及时改变，并且它们取决于流程何时开始，并且在此过程中保留它们直到它死亡。

这个小讲座的目的是表明Java过程很复杂并且取决于很多因素，所以它与你的“真实”不同。根据您提供的值，我猜他们可能是处理Java运行过程中的一些遗留物。例如，您在Eclipse中运行应用程序，它有自己的环境设置，每个进程也有自己的设置。某些变量可能适用于Java中使用的其他变量。 _JAVA_OPTIONS就是一个很好的例子。

底线 - 如果您在环境方面存在差异 - 找到它们但不要责怪Java提供它们。您正在管理您的环境，而不是Java。

java System.getenv环境名称以＆＃34; =＆＃34;开头

2 个答案: