命名java类文件的字母来自哪里？
伙计们，我今天使用了反编译器 jd-gui，发现了一些对我来说很奇怪的东西。
假设我有一个 jar 文件 lib.jar，我对其进行了反编译。结果发现，同一个包下有一些类文件，名称如A.class、B.class、a.class等。当我尝试将反编译的源文件粘贴到eclipse项目中时，但IDE说它不接受同一文件夹下的A.class和a.class。怎么可能呢？我猜没有人将他/她的类文件从 a 到 z 命名。但反编译器告诉我的。
我还尝试在我的项目中导入lib.jar，发现我无法触及a.class和A.class所在的包下的任何公共类或接口。当我输入该包时，没有出现任何提示，例如，“导入公司工具。”
谁能告诉我原因吗？预先感谢，新年快乐！
guys, I used a decompiler jd-gui today and found something quite weird to me.
Let's say I have a jar file, lib.jar, I decompiled it. It came out that there were some class files named like A.class, B.class, a.class, etc, under same package. When I tried to paste the decompiled source files into eclipse project, but IDE said it would not accept A.class and a.class under the same folder. How could it be? I guess no one named his/her class files from a to z. But the decompiler told me so.
Also I tried to import lib.jar in my project, found that I cannot touch any public class or interface under that package where a.class and A.class resides in. No tips came out when I typed into that package, e.g., "import firm.tools."
Could anyone tell me the reason? Thanks in advance, and happy new year!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您拥有的 jar 文件可能包含混淆的类文件。混淆文件的标识符被重命名，使人类读者更难理解。 （混淆的作用不仅仅是重命名标识符，但这是混淆通常所做的事情之一。）
The jar file you have probably contains obfuscated class files. Obfuscated files have identifiers renamed to make them harder to understand by human readers. (Obfuscation does much more than just rename identifiers, but that's one of the things obfuscation usually does.)
这部分可能是由于您使用的是不区分大小写的文件系统（例如 Windows 上的 NTFS）。因此，IDE 不可能为
A.class和a.class创建不同的文件，因为操作系统将它们视为等效的文件名。并非所有系统都如此，也不适用于 Java 规范 - 因此可能定义仅在大小写上不同的 Java 类（尽管由于您刚刚说明的问题，不建议这样做） 。（至于名称本身，我同意克里斯的观点，这可能是混淆的结果。）
This part is likely due to the fact that you're using a case-insensitive filesystem (e.g. NTFS on Windows). Thus it isn't possible for the IDE to create distinct files for
A.classanda.classsince the OS views them as equivalent filenames. This is not true for all systems, nor for the Java specification - hence it is possible to define Java classes that differ only in case (though this is not recommended due to the problem you've just illustrated).(As for the names themselves, I agree with Chris that this is likely the result of obfuscation.)