Design: 읽을 수 없는 was 바이너리 인코딩에는 장점이 있습니다.

최신 버전의 Chrome은 이미 바이너리 WASM을 텍스트 형식으로 변환할 수 있습니다.

내가 갈 수 있다는 말입니까? (위키피디아 항목에서 가져옴)

20 00
42 00
51
04 7e
42 01
05
20 00
20 00
42 01
7일
10 00
7e
0b

에게

정수 계승(int n) {
만약 (n == 0)
반환 1;
또 다른
반환 n * factorial(n-1);
}

또는 그대로 크롬을 사용하여 인식할 수 있습니까?

아니요, http://webassembly.org/docs/text-format/ 에 설명된 아직 공식적으로 지정되지 않은 "WAST" 형식을 반환합니다.

get_local 0
i64.const 0
i64.eq
if i64
    i64.const 1
else
    get_local 0
    get_local 0
    i64.const 1
    i64.sub
    call 0
    i64.mul
end

웹 어셈블리는 작고 쉽고 빠르게 구문 분석할 수 있는 바이너리 형식에 최적화되어 있습니다. 원래 구문을 완전히 복구하기에 충분한 정보를 보유하지 않습니다. 함수가 더 크고 복잡할수록 디컴파일을 덜 인식할 수 있습니다. 구조체, 클래스, 템플릿 및 기타 상위 수준 기능이 처리되는 방식을 보면 특히 그렇습니다.

우수(위키피디아 기사에 나열된 "중간 표현"입니다) - 나는 당신이 그것이 이미 더 "예쁘게" 될 수 있다고 제안하고 있다고 생각했습니다. - 나는 그것이 (즉시) 될 수 없다면 더 선호합니다.

그리고 나는 모든 것이 완료되었거나 완료되지 않았거나 그런 식으로 유지하도록 설계된 것을 선호합니다.

(나는 브라우저에서 의미 있는 식별자가 없더라도 궁극적으로 합리적인 의사 코드로 다시 번역할 수 있다는 계획이 있다는 인상을 받았습니다.)

사람이 읽을 수 있는 어떤 형태의 소스에 바이너리를 금지하는 것은 WebAssembly가 금지할 수 있는 것이 아닙니다. 누구나 자신의 것을 구현할 수 있지만 예쁘고 읽기 쉽습니다. 대신 이 그룹은 웹으로 컴파일하기에 적합한 이식 가능한 크기 및 로드 시간 효율적인 형식을 지정하는 데 관심을 두고 있습니다.

우리는 또한 무언가를 사용할 수 있게 만드는 데 관심이 있습니다. 이것이 우리가 낮은 수준의 텍스트 형식을 지정하는 이유이며 디버깅 기능에 대해 작업할 가능성이 높습니다.

디컴파일, 리버스 엔지니어링 또는 기타 비기술적 문제에 대한 법적 보호를 보장하는 것은 목표가 아닙니다. 이것은 귀하의 변호사에게 맡기고 변호사가 아닌 사람들은 추측을 피하도록 촉구합니다. 우리는 법률 자문을 제공하는 사업을 하고 싶지 않습니다.

사전 논의가 귀하의 질문을 해결하는 것처럼 보입니까? 닫겠습니다. 자유롭게 다시 열거나 그렇지 않은 경우 계속 논의합니다.

chintailease.wast.zip

이 .wast 파일을 원본 소스 코드로 분해하는 방법에 대한 아이디어가 있습니까?