스프레드 시트와 같은 기능을 위해 사용자가 입력 한 함수를 구문 분석하기 위해 JavaScript 코드를 작성하고 있습니다. 나는 수식 구문 분석하는 데 수있는 자바 스크립트로 변환하고 실행 eval()결과를 산출하는 데에있다.

그러나, 나는 eval()그것이 악하기 때문에 피할 수 있다면 항상 사용 하지 말았습니다. ).

그렇다면 언제 사용해도 되나요?

귀하의 질문의 전제를 해결하기 위해 잠시 시간을 내고 싶습니다-eval ()은 " 악 "입니다. 프로그래밍 언어 사용자가 사용하는 " 악 " 이라는 단어 는 일반적으로 "위험한"또는보다 정확하게는 "단순한 명령으로 많은 해를 입힐 수 있음"을 의미합니다. 언제 위험한 것을 사용해도 되나요? 위험이 무엇인지, 적절한 예방 조치를 취할 때.

지금까지 eval ()을 사용할 때의 위험을 살펴 보자. 아마도 다른 모든 것과 마찬가지로 작은 숨겨진 위험이 많을 수도 있지만, eval ()이 악하다고 여겨지는 두 가지 큰 위험은 성능과 코드 삽입입니다.

• 성능-eval ()은 인터프리터 / 컴파일러를 실행합니다. 코드가 컴파일되면 런타임 중에 무거운 컴파일러를 호출해야하기 때문에 큰 타격입니다. 그러나 JavaScript는 여전히 대부분 통역 언어이므로 eval ()을 호출하는 것이 일반적인 경우에 큰 영향을 미치지는 않습니다 (그러나 아래의 특정 설명 참조).
• 코드 삽입-eval ()은 높은 권한으로 잠재적으로 코드 문자열을 실행합니다. 예를 들어, 관리자 / 루트로 실행중인 프로그램은 입력이 "rm -rf / etc / important-file"이상일 수 있으므로 사용자 입력을 eval ()하기를 원하지 않습니다. 프로그램이 사용자의 계정에서 실행되고 있기 때문에 브라우저의 JavaScript에는 문제가 없습니다. 서버 측 JavaScript에 문제가있을 수 있습니다.

당신의 특정한 경우에. 내가 이해 한 바에 따르면, 문자열을 직접 생성하고 있으므로 "rm -rf something-important"와 같은 문자열이 생성되지 않도록주의를 가정하면 코드 삽입 위험이 없습니다 (그러나 매우 중요합니다. 일반적인 경우에는 이것을 보장하기 어렵다 ). 또한 브라우저에서 실행하는 경우 코드 삽입이 매우 위험합니다.

성능에 관해서는 코딩의 용이성에 대해 가중치를 부여해야합니다. 수식을 구문 분석하는 경우 다른 구문 분석기 (eval () 내부의 구문 분석기)를 실행하지 않고 구문 분석 중에 결과를 계산할 수도 있다고 생각합니다. 그러나 eval ()을 사용하여 코딩하는 것이 더 쉬울 수 있으며 성능 저하는 눈에 띄지 않을 것입니다. 이 경우 eval ()은 시간을 절약 할 수있는 다른 함수보다 더 나쁘지 않습니다.

eval()악하지 않다. 또는 다른 언어에서는 리플렉션, 파일 / 네트워크 I / O, 스레딩 및 IPC가 "악"인 것과 같은 방식으로 악합니다.

, 경우 당신의 목적을 위해 , eval()수동 해석보다 빠르게, 또는 코드가 간단하고, 또는 더 명확하게 ... 당신은 그것을 사용해야합니다. 둘 다 아니라면 안됩니다. 그렇게 간단합니다.

출처를 신뢰할 때

JSON의 경우 소스를 제어하는 ​​웹 서버에서 제공되므로 소스를 변경하기가 다소 어렵습니다. JSON 자체에 사용자가 업로드 한 데이터가 없으면 eval을 사용하는 데 큰 결점이 없습니다.

다른 모든 경우에는 eval ()에 공급하기 전에 사용자가 제공 한 데이터가 내 규칙을 준수하는지 확인하기 위해 많은 시간을 할애합니다.

진짜 사람들을 만나자 :

1. 모든 주요 브라우저에는 이제 해커가 풍부하게 사용할 수있는 콘솔이 내장되어 있습니다. 가능한 경우에도 eval 문을 사용하는 이유가 무엇입니까?

2. 2000 줄의 JavaScript를 컴파일하는 데 0.2 초가 걸리는 경우 4 줄의 JSON을 평가하면 성능이 어떻게 저하됩니까?

'eval is evil'에 대한 Crockford의 설명조차 약합니다.

eval은 악, eval 함수는 JavaScript에서 가장 많이 사용되는 기능입니다. 피하세요

Crockford 자신도 "이러한 진술은 비이성적 인 신경증을 유발하는 경향이 있습니다. 그것을 사지 마십시오."

평가를 이해하고 언제 유용한 지 아는 것이 더 중요합니다. 예를 들어, eval은 소프트웨어에서 생성 된 서버 응답을 평가하는 데 유용한 도구입니다.

BTW : Prototype.js는 eval을 직접 5 번 호출합니다 (evalJSON () 및 evalResponse () 포함). jQuery는 parseJSON에서 (함수 생성자를 통해) 사용합니다.

에 대한 Crockford의 조언 을 따르는 경향이 eval()있습니다. 그것을 요구하는 것처럼 보이는 방법조차도 필요하지 않습니다. 예를 들어, setTimeout()eval 대신 함수를 전달할 수 있습니다.

setTimeout(function() {
  alert('hi');
}, 1000);

그것은 경우에도 신뢰할 수있는 소스 JSON에 의해 반환 된 코드는 기껏 뭔가 남았습니다가, 최악의, 뭔가 나쁜 노출 할 수있는 왜곡 될 수 있기 때문에, 나는 그것을 사용하지 마십시오.

나는 사람들이 있기 때문에, 평가를 사용하지 옹호했다 악 , 그러나 나는 그들이 평가를 사용하므로 같은 사람이 동적으로 기능과의 setTimeout을 사용했다 후드 아래 : D를

BTW, 샌드 박스가 확실하지 않은 경우 (예 : 코드 삽입을 허용하는 사이트에서 작업중인 경우) eval이 마지막 문제입니다. 보안의 기본 규칙은 모든 입력이 악의적이지만 JavaScript의 경우 JavaScript 자체도 악의적 일 수 있습니다. JavaScript에서는 모든 기능을 덮어 쓸 수 있고 실제 기능을 사용하고 있는지 확신 할 수 없기 때문입니다. 악성 코드가 시작되기 전에 JavaScript 내장 기능을 신뢰할 수 없습니다 : D

이제이 게시물의 서사시는 다음과 같습니다.

당신이 정말로 그것을 필요로하고 (시간의 80 %가 필요 하지 않음 ) 당신이하고있는 일을 확신한다면, eval (또는 더 나은 기능;)을 사용하십시오. 폐쇄와 OOP는 80/90 %의 다른 종류의 논리를 사용하여 eval을 대체 할 수있는 경우 나머지는 동적으로 생성 된 코드 (예 : 인터프리터를 작성하는 경우)이며 이미 JSON을 평가한다고 말했듯이 (여기서는 Crockford 안전 평가를 사용할 수 있습니다.)

Eval은 코드 템플릿에 사용되는 컴파일을 보완합니다. 템플릿을 사용하면 개발 속도를 높이는 유용한 템플릿 코드를 생성하는 단순화 된 템플릿 생성기를 작성합니다.

개발자가 EVAL을 사용하지 않는 프레임 워크를 작성했지만 프레임 워크를 사용하므로 템플릿을 생성하려면 EVAL을 사용해야합니다.

다음 방법을 사용하여 EVAL의 성능을 향상시킬 수 있습니다. 스크립트를 실행하는 대신 함수를 반환해야합니다.

var a = eval("3 + 5");

그것은 다음과 같이 구성되어야합니다

var f = eval("(function(a,b) { return a + b; })");

var a = f(3,5);

캐싱 f는 확실히 속도를 향상시킵니다.

또한 Chrome에서는 이러한 기능을 매우 쉽게 디버깅 할 수 있습니다.

보안과 관련하여 eval 사용 여부는 거의 차이가 없습니다.

1. 우선, 브라우저는 샌드 박스에서 전체 스크립트를 호출합니다.
2. EVAL에서 사악한 코드는 브라우저 자체에서 사악합니다. 공격자 또는 누구나 DOM에 스크립트 노드를 쉽게 주입하고 평가할 수 있으면 무엇이든 할 수 있습니다. EVAL을 사용하지 않으면 아무런 차이가 없습니다.
3. 유해한 서버 측 보안은 대부분 열악합니다. 쿠키 유효성 검사가 불량하거나 서버에서 ACL을 잘못 구현하면 대부분의 공격이 발생합니다.
4. Java의 네이티브 코드에는 최근 Java 취약점 등이있었습니다. 자바 스크립트는 샌드 박스에서 실행되도록 설계되었으며 애플릿은 인증서 등을 사용하여 샌드 박스 외부에서 실행되도록 설계되어 취약점 및 기타 여러 가지 사항을 초래합니다.
5. 브라우저를 모방하기위한 코드 작성은 어렵지 않습니다. 즐겨 사용하는 사용자 에이전트 문자열을 사용하여 서버에 HTTP 요청을하면됩니다. 모든 테스트 도구는 브라우저를 조롱합니다. 공격자가 당신에게 피해를 입히고 싶다면 EVAL이 최후의 수단입니다. 서버 측 보안을 처리하는 다른 많은 방법이 있습니다.
6. 브라우저 DOM은 사용자 이름이 아닌 파일에 액세스 할 수 없습니다. 실제로 eval이 액세스 할 수있는 시스템은 없습니다.

서버 측 보안이 어느 곳에서나 공격 할 수있을 정도로 견고하다면 EVAL에 대해 걱정할 필요가 없습니다. 앞에서 언급했듯이 EVAL이 존재하지 않으면 공격자는 브라우저의 EVAL 기능에 관계없이 서버를 해킹 할 수있는 많은 도구를 가지고 있습니다.

Eval은 미리 사용되지 않은 것을 기반으로 복잡한 문자열 처리를 수행하기 위해 일부 템플릿을 생성하는 데만 적합합니다. 예를 들어 선호합니다

"FirstName + ' ' + LastName"

반대로

"LastName + ' ' + FirstName"

내 표시 이름으로 데이터베이스에서 가져올 수 있고 하드 코딩되지 않았습니다.

Chrome (v28.0.1500.72)에서 디버깅 할 때 변수가 클로저를 생성하는 중첩 함수에서 사용되지 않으면 클로저에 바인딩되지 않습니다. 나는 그것이 JavaScript 엔진의 최적화라고 생각합니다.

그러나 : eval()클로저를 일으키는 함수 내에서 사용될 때 , 외부 함수의 모든 변수는 전혀 사용되지 않더라도 클로저에 바인딩됩니다. 누군가 메모리 누수로 인해 테스트 할 시간이 있다면 아래에 의견을 남겨주세요.

내 테스트 코드는 다음과 같습니다.

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is visible in debugger
            eval("1");
        })();
    }

    evalTest();
})();

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is NOT visible in debugger
            var noval = eval;
            noval("1");
        })();
    }

    evalTest();
})();

(function () {
    var noval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();    // Variable "unused" is NOT visible in debugger
            noval("1");
        })();
    }

    evalTest();
})();

내가 여기서 지적하고 싶은 것은 eval ()이 반드시 기본 eval()함수를 참조해서는 안된다는 것입니다. 그것은 모두 함수의 이름에 달려 있습니다 . 따라서 eval()별칭 이름 (예 var noval = eval;: 내부 함수 noval(expression);)으로 네이티브 를 호출 expression할 때 클로저에 포함되어야하지만 실제로는 그렇지 않은 변수를 참조 할 때 평가 가 실패 할 수 있습니다.

Microsoft는 IE 블로그 ( IE + JavaScript 성능 권장 사항 2 부 : JavaScript 코드 비 효율성 )에서 브라우저의 eval ()이 느린 이유를 설명합니다 .

결론

당신이 코드를 만들었거나 위생 처리했다면 eval결코 악할 수 없습니다 .

약간 더 자세한

eval이다 악마 된 클라이언트에 의해 제출 된 입력을 사용하여 서버에서 실행중인 경우 개발자가 작성되지 또는 한 개발자에 의해 살균 없습니다 .

eval이다 악하지 클라이언트에서 실행중인 경우 클라이언트에 의해 만들어진 unsanitized 입력을 사용하는 경우에도 .

분명히 코드가 소비하는 것을 약간 제어하기 위해 항상 입력을 위생 처리 해야 합니다.

추리

클라이언트는 개발자가 코드를 작성하지 않더라도 원하는 임의의 코드를 실행할 수 있습니다. 이뿐만 아니라 마찬가지입니다 무엇 evaled되지만 를 호출 eval자체 .

eval ()을 사용해야하는 유일한 경우는 동적 JS를 즉시 실행해야하는 경우입니다. 서버에서 비동기 적으로 다운로드하는 JS에 대해 이야기하고 있습니다 ...

... 10 회 중 9 회는 리팩토링을 통해이를 피할 수 있습니다.

eval거의 올바른 선택이 아닙니다. 연관 배열 표기법 (: 당신은 당신이 함께 스크립트을 연결하고 즉석에서 그것을 실행하여 달성하기 위해 필요한 수행 할 수있는 다양한 경우가있을 수 있지만, 일반적으로 훨씬 더 강력하고 귀하의 처분에 유지 관리 기술이 obj["prop"]와 동일 obj.prop) , 클로저, 객체 지향 기술, 기능적 기술-대신 사용하십시오.

클라이언트 스크립트가 진행되는 한, 보안 문제는 논란의 여지가 있다고 생각합니다. 브라우저에로드 된 모든 내용은 조작이 가능하므로 처리해야합니다. 브라우저의 URL 표시 줄과 같이 DOM에서 JavaScript 코드를 실행 및 / 또는 객체를 조작하는 훨씬 쉬운 방법이있는 경우 eval () 문을 사용할 위험이 없습니다.

javascript:alert("hello");

누군가 자신의 DOM을 조작하고 싶다면 스윙을 멀리하십시오. 모든 유형의 공격을 방지하는 보안은 항상 서버 응용 프로그램의 책임입니다.

실용적인 관점에서 볼 때 상황이 다른 경우 eval ()을 사용하면 이점이 없습니다. 그러나 eval을 사용해야하는 특정한 경우가 있습니다. 그렇다면 페이지 폭파 위험없이 확실히 수행 할 수 있습니다.

<html>
    <body>
        <textarea id="output"></textarea><br/>
        <input type="text" id="input" />
        <button id="button" onclick="execute()">eval</button>

        <script type="text/javascript">
            var execute = function(){
                var inputEl = document.getElementById('input');
                var toEval = inputEl.value;
                var outputEl = document.getElementById('output');
                var output = "";

                try {
                    output = eval(toEval);
                }
                catch(err){
                    for(var key in err){
                        output += key + ": " + err[key] + "\r\n";
                    }
                }
                outputEl.value = output;
            }
        </script>
    <body>
</html>

서버 측 eval은 sql 또는 influxdb 또는 mongo와 같은 외부 스크립트를 처리 할 때 유용합니다. 서비스를 다시 배포하지 않고 런타임시 사용자 지정 유효성 검사를 수행 할 수있는 위치

예를 들어 다음 메타 데이터가 포함 된 업적 서비스

{
  "568ff113-abcd-f123-84c5-871fe2007cf0": {
    "msg_enum": "quest/registration",
    "timely": "all_times",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/registration:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/registration\"}`"
  },
  "efdfb506-1234-abcd-9d4a-7d624c564332": {
    "msg_enum": "quest/daily-active",
    "timely": "daily",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" WHERE time >= '${today}' ${ENV.DAILY_OFFSET} LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/daily-active:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/daily-active\"}`"
  }
}

그런 다음 허용

• JSON에서 리터럴 문자열을 통해 객체 / 값을 직접 주입하여 텍스트 템플릿에 유용

• CMS에서 퀘스트 또는 이벤트의 유효성을 검사하는 방법을 규칙이라고 말하면 비교기로 사용할 수 있습니다.

이것의 단점 :

• 완전히 테스트되지 않은 경우 코드에 오류가 발생하여 서비스의 문제가 발생할 수 있습니다.

• 해커가 시스템에 스크립트를 작성할 수 있다면 거의 망할 수 있습니다.

• 스크립트의 유효성을 검사하는 한 가지 방법은 스크립트 해시를 안전한 곳에 보관하여 실행하기 전에 확인할 수 있습니다.

나는 eval이 정당화되는 경우는 거의 없다고 생각한다. 실제로 정당화 될 때 사용하는 것보다 정당하다고 생각하여 사용할 가능성이 높습니다 .

보안 문제가 가장 잘 알려져 있습니다. 그러나 JavaScript는 JIT 컴파일을 사용하며 eval과는 잘 작동하지 않습니다. Eval은 컴파일러의 블랙 박스와 다소 비슷하며 JavaScript는 성능 최적화 및 범위 지정을 안전하고 올바르게 적용하기 위해 코드를 어느 정도 미리 예측할 수 있어야합니다. 경우에 따라 성능 영향은 평가 외부의 다른 코드에도 영향을 줄 수 있습니다.

자세한 내용을 보려면 https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closures/ch2.md#eval

eval함수에 전달 된 코드를 완전히 제어 할 수 있으면이를 사용하는 것이 좋습니다 .

가능하면 테스트 중에 만 가능합니다. 또한 eval ()은 다른 특수 JSON 등 평가 기보다 훨씬 느립니다.

코드 소스가 사용자 또는 실제 사용자로부터 온 것임을 확신 할 수있는 한 eval ()을 사용하지 않는 이유는 없습니다. eval () 함수로 전송 된 내용을 조작 할 수 있지만 웹 사이트의 소스 코드를 조작 할 수 있고 JavaScript 코드 자체를 변경할 수 있기 때문에 보안 문제는 아닙니다.

그렇다면 ... eval ()을 사용하지 않을 때? Eval ()은 타사가 변경할 수있는 경우에만 사용해서는 안됩니다. 클라이언트와 서버 간의 연결을 가로채는 것처럼 (문제가있는 경우 HTTPS 사용) 포럼에서와 같이 다른 사람들이 작성한 코드를 구문 분석하기 위해 eval ()을 사용해서는 안됩니다.

실제로 필요한 경우 평가는 악이 아닙니다. 그러나 내가 우연히 발견 한 eval 사용의 99.9 %는 필요 하지 않습니다 (setTimeout을 포함하지 않음).

나에게 악은 성능이나 보안 문제가 아닙니다 (간접적으로 둘 다입니다). eval을 불필요하게 사용하면 유지 보수가 더 어려워집니다. 리팩토링 도구가 폐기되었습니다. 코드 검색이 어렵습니다. 이러한 회피의 예기치 않은 영향은 군단입니다.

JavaScript의 eval ()은 언제 사악하지 않습니까?

나는 항상 eval 사용 을 권장하지 않습니다 . 거의 항상 더 깨끗하고 유지 보수가 쉬운 솔루션을 사용할 수 있습니다. JSON 구문 분석에도 Eval 이 필요하지 않습니다 . Eval 은 유지 보수 지옥에 추가합니다 . 이유없이, 더글러스 크로포드 (Duglas Crockford)와 같은 주인이 눈살을 찌푸립니다.

그러나 사용해야하는 한 가지 예를 찾았습니다 .

식을 전달해야 할 때.

예를 들어, 나는 google.maps.ImageMapType나를 위해 일반적인 객체를 구성하는 함수를 가지고 있지만, 레시피를 알려 주어야합니다. zoom그리고 and coord매개 변수 에서 타일 URL을 어떻게 구성해야합니까 ?

my_func({
    name: "OSM",
    tileURLexpr: '"http://tile.openstreetmap.org/"+b+"/"+a.x+"/"+a.y+".png"',
    ...
});

function my_func(opts)
{
    return new google.maps.ImageMapType({
        getTileUrl: function (coord, zoom) {
            var b = zoom;
            var a = coord;
            return eval(opts.tileURLexpr);
        },
        ....
    });
}

내 사용 예 eval: import .

일반적으로 수행되는 방법

var components = require('components');
var Button = components.Button;
var ComboBox = components.ComboBox;
var CheckBox = components.CheckBox;
...
// That quickly gets very boring

그러나 eval작은 도우미 기능을 사용하면 훨씬 더 잘 보입니다.

var components = require('components');
eval(importable('components', 'Button', 'ComboBox', 'CheckBox', ...));

importable 이 버전은 콘크리트 멤버 가져 오기를 지원하지 않습니다.

function importable(path) {
    var name;
    var pkg = eval(path);
    var result = '\n';

    for (name in pkg) {
        result += 'if (name !== undefined) throw "import error: name already exists";\n'.replace(/name/g, name);
    }

    for (name in pkg) {
        result += 'var name = path.name;\n'.replace(/name/g, name).replace('path', path);
    }
    return result;
}

평가는 악한 것이 아니라 잘못 사용 된 것입니다.

코드를 작성했거나 신뢰할 수 있다면 괜찮습니다. 사람들은 평가가 어떻게 사용자 입력이 중요하지 않은지 계속 이야기합니다. 잘 ~

서버로 이동하는 사용자 입력이 있으면 클라이언트로 돌아와 해당 코드는 위생 처리되지 않고 평가판에서 사용됩니다. 축하합니다. 사용자 데이터를 누구에게나 보낼 수있는 판도라 상자를 열었습니다.

eval의 위치에 따라 많은 웹 사이트에서 SPA를 사용하므로 eval을 사용하면 쉽지 않은 응용 프로그램 내부에보다 쉽게 ​​액세스 할 수 있습니다. 이제 그들은 해당 브라우저에 가짜 브라우저 확장을 만들어 데이터를 훔칠 수 있습니다.

eval을 사용하는 요점을 파악해야합니다. 코드를 생성하는 것은 단순히 그런 종류의 작업을 수행하거나 객체를 사용하는 등의 방법을 만들 수있는 경우에는 이상적이지 않습니다.

이제 eval을 사용하는 좋은 예입니다. 서버가 작성한 swagger 파일을 읽고 있습니다. 많은 URL 매개 변수가 형식으로 만들어 {myParam}집니다. 따라서 엔드 포인트가 많으므로 URL을 읽고 복잡한 대체 작업없이 템플릿 문자열로 변환하려고합니다. 그래서 당신은 이런 식으로 할 수 있습니다. 이것은 매우 간단한 예입니다.

const params = { id: 5 };

const route = '/api/user/{id}';
route.replace(/{/g, '${params.');

// use eval(route); to do something

코드 생성. 필자는 최근 virtual-dom 과 handlebars 의 격차를 해소하는 Hyperbars 라는 라이브러리를 작성했습니다 . 핸들 바 템플릿을 파싱하고 하이퍼 스크립트 로 변환하여이를 수행 합니다. 하이퍼 스크립트는 먼저 문자열로 생성되며 반환하기 전에 실행 코드로 변환합니다. 나는 찾았다eval()eval() 이 특정한 상황에서 악의 정반대를 했다.

기본적으로

<div>
    {{#each names}}
        <span>{{this}}</span>
    {{/each}}
</div>

이에

(function (state) {
    var Runtime = Hyperbars.Runtime;
    var context = state;
    return h('div', {}, [Runtime.each(context['names'], context, function (context, parent, options) {
        return [h('span', {}, [options['@index'], context])]
    })])
}.bind({}))

의 성능 eval()생성 된 문자열을 한 번만 해석 한 다음 실행 가능한 출력을 여러 번 재사용해야하기 때문에 이와 같은 상황에서도 문제가되지 않습니다.

당신은 당신이 궁금하면 코드 생성이 달성 방식을 볼 수 있습니다 여기에 .

내 생각은 eval은 클라이언트 측 웹 응용 프로그램에 매우 강력한 기능이며 안전합니다 ... JavaScript만큼 안전하지는 않습니다. :-) Firebug와 같은 도구를 사용하면 모든 JavaScript 응용 프로그램을 공격 할 수 있으므로 보안 문제는 본질적으로 서버 측 문제입니다.

Eval은 매크로가 없을 때 코드 생성에 유용합니다.

(멍청한) 예제의 경우, Brainfuck 컴파일러를 작성하는 경우 명령 시퀀스를 문자열로 수행하는 함수를 구성하고이를 평가하여 함수를 반환하려고 할 수 있습니다.

구문 분석 함수 (예 : jQuery.parseJSON)로 JSON 구조를 구문 분석하면 JSON 파일의 완벽한 구조가 필요합니다 (각 특성 이름은 큰 따옴표로 묶임). 그러나 JavaScript는 더 유연합니다. 따라서 eval ()을 사용하여 피할 수 있습니다.