为什么字节码不可读？
我对一个特定的话题感到困惑：
当您编译Java或Python时，您将得到将在各自VM上运行的字节码。在前面的一个问题中，我曾经问过为什么当您在文本编辑器中打开一个.pyc或.class文件时，它看起来是胡说八道，而不像可读的字节码(加载、存储操作等)。
现在我得到的答案是基于“这就像说如果你打开了一个.exe文件并期望看到x86程序集”，他们把我看到的字节码类比为真实字节码的“程序集”版本，它是不可读的。
如果不是因为一件事，这是可以理解的。不能将exe文件与字节码文件进行比较。已将exe文件编译为机器代码。字节码文件不是。字节码文件被输入VM，然后VM解释它(通常用JIT)。
这意味着，无论是谁编写JVM (这只是软件本身的一部分)，都需要编写字节码解释器。我真的很怀疑他们写了一个解释来处理以下问题：
Java .class文件：
我可能错了，也许他们确实写了一个解释器来处理这种形式的字节码，但似乎不太可能。但是，如果JVM处理字节码的“程序集”版本，那么这意味着循环是
.java -> .class (不可读) -> .class (当它进入JVM时可读性强)--在这两者之间几乎是没有意义的一步。
我只是在这一点上很困惑。
回答 2
Stack Overflow用户
发布于 2020-07-04 18:07:30
他们确实为这种形式的字节码编写了一个解释器。当然，它们以字节的形式读取它，而不是ASCII字符，这使得它更加可用。但是，例如，each instruction code takes only one byte, not e.g. five to write store。
我们的目标是在内存使用上有一些紧凑的东西，但实际上并没有被编译成只针对一个设备的机器代码。Java字节码或多或少是它自己的机器代码形式。
但是，如果您想要阅读它，请使用javap命令将其解压缩为更具可读性的形式。
Stack Overflow用户
发布于 2020-07-04 18:56:27
字节码是虚拟机的“机器代码”。因此，它具有与“真实”机器码相同的目标和限制--紧凑、高效的解码等。
字节码是由虚拟机而不是由“真实”机器执行的这一事实与此无关。
https://stackoverflow.com/questions/62732625
复制相似问题
腾讯云开发者
