Java와 .NET 디컴파일

컴파일된 파일에서 F3 을 누르면 바이트 대신 소스 코드가 보입니다. 이 일을 하는 플러그인은 둘입니다 — 하나는 Java용(.class, .jar, .apk, .dex), 하나는 .NET용(.dll, .exe, .winmd, .netmodule) — 그리고 동작 방식이 같으므로 이 페이지가 둘 다 다룹니다. 각각은 환경설정 ▸ 플러그인… 에서 따로 끄거나 제거할 수 있습니다.

압축 파일은 그 안의 클래스 트리로, 단일 클래스는 하나의 파일로 표시됩니다. 명령 메뉴의 소스로 디컴파일 은 결과를 써 내어 패널에 넣으므로, 다른 소스 폴더와 마찬가지로 검색하고 비교하고 복사할 수 있습니다.

엔진은 직접 설치합니다

어떤 디컴파일러도 함께 제공되지 않으며, 아무것도 대신 다운로드하지 않습니다. 여기에는 두 가지 이유가 있습니다. 가장 널리 알려진 Java 디컴파일러인 JD-Core는 GPLv3이라 Apache-2.0 앱 안에 담아 배포할 수 없었고, 엔진은 계속 좋아지므로 교체하는 데 Peach Commander의 새 버전이 필요해서는 안 되기 때문입니다.

뷰어의 엔진 폴더… 는 엔진이 들어갈 폴더를 엽니다. 그 안의 README가 각 엔진과 라이선스를 알려 줍니다.

Java	CFR, Vineflower, Procyon, jadx(안드로이드 .dex 및 .apk 용), 그리고 순수 바이트코드용 javap
.NET	ILSpy, 그리고 IL용 monodis

엔진 확인 은 각 엔진의 버전 명령을 실행해 세 가지를 구별합니다. 설치되어 동작함, 설치되지 않음, 그리고 설치되었지만 실행할 수 없음 — JDK 없는 Java 도구는 존재하면서도 시작되지 않으며, 실제로 실행해 보아야만 드러납니다.

엔진은 코드가 아니라 데이터로 기술되므로, 직접 하나 추가할 수 있습니다:

[cfr]
kinds  = class, jar
tool   = java
args   = -jar {engine} {input}
engine = ~/Library/Application Support/PeachCommander/decompilers/cfr.jar
output = stdout

한 파일을 여러 엔진이 처리할 수 있을 때는, 따로 고르지 않는 한 가장 먼저 사용 가능한 엔진을 씁니다. 두 개가 설치되어 있으면 비교 가 두 결과를 나란히 보여 줍니다 — 한 엔진이 포기한 메서드를 다른 엔진이 처리할 때 유용합니다.

컴파일된 코드 안에서 검색

모든 클래스 검색 은 바이트가 아니라 디컴파일된 텍스트를 훑으므로, JAR 안에서 문자열 리터럴이나 메서드 이름을 찾을 수 있습니다.

많은 파일에 걸친 내용 검색 중의 디컴파일은 별도 설정이며 기본값은 꺼짐입니다. 텍스트를 만들어 내려면 클래스마다 한 번씩 엔진을 돌려야 할 수 있는데, 느린 컴퓨터에서 그것을 검색에 쓰는 것은 합리적이지 않기 때문입니다. 주 검색 대화상자가 따로 묻고, 여기서도 마찬가지로 거부합니다.

캐시와 제한

결과는 캐시됩니다. 같은 클래스를 두 번 디컴파일하는 것은 순전한 기다림이기 때문입니다. 설정에는 결과를 며칠 보관할지와 캐시의 크기 제한 이 있습니다. 지금 캐시 지우기 는 캐시를 비우고 얼마나 확보했는지 알려 줍니다.

끝나지 않는 엔진에 대비해 두 가지 시간 제한이 있습니다. 하나는 클래스나 형식 하나에 대한 것, 다른 하나는 압축 파일 전체에 대한 것입니다. 둘 다 0을 받아들이며, 이는 “엔진 자체의 기본값을 쓴다”는 뜻입니다.