JavaScript의 eval()이 나쁜 것은 언제입니까?
사용자가 입력한 함수를 해석하기 위해 JavaScript 코드를 작성하고 있습니다(스프레드시트와 같은 기능을 위해).수식을 구문 분석하면 자바스크립트로 변환하여 실행할 수 있습니다.eval()★★★★★★★★★★★★★★★★★」
저는 피하려고요, 피했어요.eval()만약 그것이 나쁘기 때문에 피할 수 있다면(그리고 옳든 그르든 간에, 나는 항상 자바스크립트에서 더 나쁘다고 생각해왔다. 왜냐하면 평가되는 코드가 사용자에 의해 변경될 수 있기 때문이다).
그럼 언제 사용해도 될까요?
질문의 전제에 대해 잠시 말씀드리겠습니다. eval()은 '악'입니다.프로그래밍 언어 사용자들이 사용하는 "악"이라는 단어는 보통 "위험한"을 의미하며, 더 정확히는 "단순해 보이는 명령으로 많은 해를 입힐 수 있다"를 의미합니다.그러면, 언제 위험한 것을 사용해도 괜찮을까요?위험이 무엇인지 알고 적절한 예방 조치를 취할 때.
요점은 eval()의 사용상의 위험성에 대해 살펴보자.다른 모든 것과 마찬가지로 작은 위험이 숨어있을 수 있지만, 두 가지 큰 위험, 즉 eval()이 악하다고 여겨지는 이유는 퍼포먼스와 코드 주입입니다.
- Performance - eval()은 인터프리터/컴파일러를 실행합니다.코드가 컴파일 되어 있는 경우는, 런타임중에 부하가 높은 컴파일러를 호출할 필요가 있기 때문에, 이것은 큰 히트입니다.그러나 JavaScript는 여전히 대부분 인터프리터 언어입니다.즉, 일반적인 경우 eval()을 호출하는 것은 퍼포먼스에 큰 영향을 주지 않습니다(다만, 이하를 참조해 주세요).
- 코드 주입 - eval()은 상승된 권한으로 코드 문자열을 실행할 수 있습니다.예를 들어 administrator/root로 실행되고 있는 프로그램은 사용자 입력을 평가()하고 싶어하지 않습니다.그 입력은 잠재적으로 "rm - rf /etc/important-file" 이거나 더 나쁠 수 있기 때문입니다.브라우저의 JavaScript는 사용자 자신의 계정으로 실행되기 때문에 문제가 없습니다.서버측 JavaScript에 이러한 문제가 있을 수 있습니다.
당신의 구체적인 사건으로 넘어가죠.스트링을 직접 생성하는 것으로 알고 있기 때문에 rm -rf something-important와 같은 스트링이 생성되지 않도록 주의한다면 코드 주입의 위험은 없습니다(그러나 일반적인 경우에서는 확실히 하기 어렵습니다).또한 브라우저에서 실행 중인 경우 코드 주입은 매우 작은 위험이라고 생각합니다.
성능에 대해서는 코딩의 용이성과 비교하여 평가해야 합니다.수식을 해석하는 경우에는 다른 파서(내부 eval())를 실행하는 것보다 해석 중에 결과를 계산하는 것이 좋다고 생각합니다.그러나 eval()을 사용하여 코드화하는 것이 더 쉬울 수 있으며 성능 적중률은 아마 눈에 띄지 않을 것입니다.이 경우 eval()은 시간을 절약할 수 있는 다른 함수와 마찬가지로 나쁜 함수는 아닌 것 같습니다.
eval()및다른인또는 리플렉션, 파일/네트워크 I/O, 스레드화 및 IPC가 다른 언어에서 "악"인 것과 같은 방식으로 악질입니다.
만약 당신의 목적을 위해,eval() 이렇게. 다 둘둘다다,, ,,면안안안안안안안.렇게간간 간간간다다
출처를 믿을 때.
JSON의 경우, 소스는 사용자가 제어하는 웹 서버에서 생성되기 때문에 소스를 조작하는 것은 거의 어렵습니다.사용자가 업로드한 데이터가 JSON 자체에 포함되어 있지 않은 한 eval을 사용하는 데 큰 단점은 없습니다.
그 외의 경우에는 eval()에 데이터를 보내기 전에 사용자가 제공한 데이터가 규칙에 부합하는지 확인하기 위해 많은 노력을 하고 싶습니다.
진정한 사람을 만나보자.
이제 모든 주요 브라우저에는 내장 콘솔이 있습니다.해커가 될 예정인 사용자는 어떤 가치 있는 함수를 호출할 때 풍부하게 사용할 수 있습니다.할 수 있어도 굳이 eval 스테이트먼트를 사용할 필요가 있습니까?
2000줄의 JavaScript 컴파일에 0.2초가 걸리는 경우 4줄의 JSON을 평가하면 성능이 얼마나 저하됩니까?
크로크포드의 평가는 악하다는 설명조차 약하다.
eval is Evil, eval 함수는 JavaScript의 가장 잘못된 기능입니다.피하다
크록포드 자신이 "이런 종류의 진술은 비이성 신경증을 일으키는 경향이 있다.사지 마세요.
평가를 이해하고 도움이 될 수 있는 시기를 아는 것이 훨씬 더 중요합니다.예를 들어, eval은 소프트웨어에 의해 생성된 서버 응답을 평가하는 데 유용한 도구입니다.
BTW: prototype.js는 직접 5번 호출합니다(evalJSON() 및 evalResponse()에 포함).jQuery는 parseJ에서 사용합니다.SON(함수 컨스트럭터 경유).
나는 크록포드의 충고를 따르는 경향이 있다.eval() 피하세요심지어 그것을 필요로 하는 것처럼 보이는 방법들도 그렇지 않다.를 들면, 「」는,setTimeout()를 사용하면 평가보다는 함수를 통과할 수 있습니다.
setTimeout(function() {
alert('hi');
}, 1000);
신뢰할 수 있는 소스라고 해도 사용하지 않습니다.JSON에 의해 반환된 코드가 왜곡되어 기껏해야 뭔가 이상한 일이 일어날 수 있기 때문입니다.최악의 경우 나쁜 일이 발생할 수 있습니다.
Eval은 코드 템플릿 작성에 사용되는 컴파일을 보완합니다.템플릿 작성이란 개발 속도를 높이는 유용한 템플릿 코드를 생성하는 단순 템플릿 생성기를 작성하는 것을 의미합니다.
개발자가 EVAL을 사용하지 않는 프레임워크를 작성했습니다만, 그 프레임워크는 EVAL을 사용하여 템플릿을 생성해야 합니다.
EVAL의 퍼포먼스는 다음 방법을 사용하여 향상시킬 수 있습니다.스크립트를 실행하는 대신 함수를 반환해야 합니다.
var a = eval("3 + 5");
다음과 같이 구성되어야 합니다.
var f = eval("(function(a,b) { return a + b; })");
var a = f(3,5);
f를 캐싱하면 확실히 속도가 향상됩니다.
또한 크롬은 이러한 기능을 매우 쉽게 디버깅할 수 있습니다.
보안에 관해서는 eval을 사용하든 사용하지 않든 별 차이가 없습니다.
- 먼저 브라우저는 샌드박스에서 스크립트 전체를 호출합니다.
- EVAL에서 나쁜 코드는 브라우저 자체에서 나쁜 코드입니다.공격자나 누구나 DOM에 스크립트노드를 쉽게 삽입하고 평가할 수 있는 것이 있으면 무엇이든 할 수 있습니다.EVAL을 사용하지 않아도 아무런 차이가 없습니다.
- 서버측 보안의 부실이 가장 큰 원인이 되고 있습니다.서버에서의 쿠키 검증이 불충분하거나 ACL의 실장이 불충분하면 대부분의 공격이 발생합니다.
- Java의 네이티브 코드에는 최근 Java 취약성 등이 있었습니다.JavaScript는 샌드박스 안에서 실행되도록 설계되어 있는 반면 애플릿은 취약성과 다른 많은 것들을 야기하는 인증서 등을 사용하여 샌드박스 밖에서 실행되도록 설계되어 있습니다.
- 브라우저를 모방하기 위한 코드를 작성하는 것은 어렵지 않습니다.원하는 사용자 에이전트 문자열을 사용하여 서버에 HTTP 요청을 작성하기만 하면 됩니다.모든 테스트 툴은 브라우저를 모조합니다.공격자가 당신을 해치려 할 경우 EVAL이 마지막 수단입니다.서버측의 시큐러티에 대처하는 방법은, 그 밖에도 많이 있습니다.
- 브라우저의 DOM 에서는, 파일이나 유저명에 액세스 할 수 없습니다.실제로 평가 대상 머신에서는 어떤 액세스도 할 수 없습니다.
서버측의 시큐러티가, 누구라도 어디에서라도 공격할 수 있을 만큼 견고하다면, EVAL에 대해 걱정할 필요는 없습니다.말씀드렸듯이 EVAL이 존재하지 않는 경우 공격자는 브라우저의 EVAL 기능에 관계없이 많은 툴을 사용하여 서버를 해킹할 수 있습니다.
Eval은 일부 템플릿을 생성하여 사전에 사용되지 않은 문자열에 기초하여 복잡한 문자열 처리를 수행할 수 있습니다.예를 들어, 저는
"FirstName + ' ' + LastName"
와는 반대로
"LastName + ' ' + FirstName"
내 표시명으로, 데이터베이스에서 가져올 수 있고 하드코드가 되어 있지 않습니다.
결산
를 또는 eval결코 악하지 않다.
조금 더 상세하게
eval개발자에 의해 작성되지 않은 클라이언트 또는 개발자에 의해 삭제되지 않은 클라이언트가 제출한 입력을 사용하여 서버에서 실행 중인 경우 유해합니다.
eval클라이언트에 의해 조작된 비위생화된 입력을 사용하더라도 클라이언트에서 실행 중인 경우 악의는 없습니다.
코드 소비량을 어느 정도 제어할 수 있도록 입력을 항상 삭제해야 합니다.
추리
개발자가 코드를 작성하지 않았더라도 클라이언트는 원하는 임의의 코드를 실행할 수 있습니다.이것은 평가 대상뿐만 아니라 콜 자체에도 해당됩니다.
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()기능.모두 함수의 이름에 따라 달라집니다.그래서 원어민에게 전화할 때eval(): 「」)을 .var noval = eval; 후 함수에서noval(expression); )의 expression폐쇄의 일부여야 하지만 실제로는 그렇지 않은 변수를 참조할 경우 실패할 수 있습니다.
eval을 사용하지 않는 것은 나쁘기 때문에 옹호하는 사람도 있습니다만, 같은 사람이 Function과 set Timeout을 동적으로 사용하고 있기 때문에, 후드에서 eval을 사용하고 있습니다.d
참고로 샌드박스가 충분히 확실하지 않은 경우(예를 들어 코드 주입을 허용하는 사이트에서 작업 중인 경우) 평가는 마지막 문제입니다.보안의 기본 규칙은 모든 입력이 악하다는 것이지만, JavaScript의 경우 JavaScript 자체도 악할 수 있습니다. 왜냐하면 JavaScript에서는 어떤 함수든 덮어쓸 수 있고 실제 함수를 사용하고 있는지 확신할 수 없기 때문입니다.따라서 악성코드가 사용자보다 먼저 시작되면 JavaScript 내장 함수를 신뢰할 수 없습니다.d
이 투고에 대한 후기는 다음과 같습니다.
정말로 필요한 경우(시간 평가의 80%는 필요 없음) 및 수행 중인 작업에 대한 확신이 있는 경우 eval(또는 더 나은 기능)을 사용합니다.폐쇄 및 OOP는 다른 종류의 로직을 사용하여 평가를 대체할 수 있는 경우의 80~90%를 커버합니다.나머지 코드는 동적으로 생성됩니다(예를 들어 인터프리터 작성 시 등).JSON 평가(여기서 Crockford 안전 평가를 사용할 수 있습니다.)
eval()을 사용해야 하는 유일한 예는 동적 JS를 즉시 실행해야 하는 경우입니다.서버에서 비동기식으로 다운로드하는 JS를 말하는 거예요.
...10의 9배는 리팩터링을 통해 쉽게 피할 수 있습니다.
서버 측에서 eval은 sql, influseddb, 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에서 퀘스트 또는 이벤트를 검증하는 규칙을 만듭니다.
단점:
완전히 테스트되지 않은 경우 코드에 오류가 있을 수 있으며 서비스 내용을 분해할 수 있습니다.
만약 해커가 당신의 시스템에 스크립트를 쓸 수 있다면 당신은 거의 망한 것입니다.
스크립트를 검증하는 한 가지 방법은 스크립트의 해시를 안전한 장소에 보관하는 것입니다.그러면 실행하기 전에 체크할 수 있습니다.
평가는 악이 아니라 오용될 뿐입니다.
코드를 작성했거나 신뢰할 수 있다면 괜찮습니다.평가와 사용자 입력이 어떻게 상관이 없는지에 대해 사람들이 계속 이야기합니다.뭐랄까~
서버에 사용자 입력이 있을 경우 클라이언트로 돌아가 해당 코드가 삭제되지 않고 평가에서 사용됩니다.축하합니다. 판도라의 상자를 열어 사용자 데이터가 누구에게나 전송되도록 했습니다.
평가의 위치에 따라 많은 웹 사이트가 SPA를 사용하고 있으며, 평가를 통해 사용자가 애플리케이션 내부에 쉽게 액세스할 수 있게 됩니다.이제 가짜 브라우저 확장을 만들어 해당 평가에 테이프를 붙여 데이터를 다시 훔칠 수 있습니다.
네가 평가서를 사용하는 이유가 뭔지 알아내야 해코드 생성은 단순히 그런 일을 하는 방법이나 오브젝트 등을 사용할 수 있는 경우에는 그다지 이상적이지 않습니다.
평가하다서버가 사용자가 작성한 스웨거 파일을 읽고 있습니다.의 대부분은 됩니다.{myParam}따라서 엔드포인트가 많기 때문에 복잡한 치환을 수행할 필요 없이 URL을 읽은 후 템플릿 문자열로 변환해야 합니다.그그이이이이이도도도요요요요요요요 。이것은 매우 간단한 예입니다.
const params = { id: 5 };
const route = '/api/user/{id}';
route.replace(/{/g, '${params.');
// use eval(route); to do something
eval옳은 선택인 경우는 거의 없습니다.해야 할 것을 할 수 있는 , 으로 훨씬 표기법을 할 수 있습니다.있습니다.즉, 어소시에이션 어레이 표기법( ).obj["prop"] is is is is is와 obj.prop폐쇄, 객체 지향 기술, 기능 기술 - 대신 사용합니다.
클라이언트 스크립트에 관한 한 보안 문제는 논쟁거리라고 생각합니다.브라우저에 로드된 모든 내용은 조작될 수 있으므로 동일하게 취급해야 합니다.JavaScript 코드를 실행하거나 브라우저의 URL 바 등 DOM 내의 오브젝트를 조작하는 훨씬 쉬운 방법이 있는 경우 eval() 문을 사용해도 위험은 없습니다.
javascript:alert("hello");
누군가 자신의 DOM을 조작하고 싶다면, 나는 도망치라고 말한다.모든 유형의 공격을 방지하기 위한 보안은 항상 서버 애플리케이션 및 기간에서 책임져야 합니다.
실용적인 관점에서 볼 때, 다른 방법으로 작업을 수행할 수 있는 상황에서 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>
도 언급하지 않았으니 .evalWebassembly-Javascript interop.페이지에 WASM 코드가 직접 호출할 수 있는 미리 작성된 스크립트를 포함하는 것이 이상적이지만, 실제로 필요한 작업을 수행하려면 C#과 같은 웹 어셈블리 언어에서 동적 Javascript를 전달해야 할 수도 있습니다.
또한 이 시나리오에서는 전달되는 내용을 완전히 제어할 수 있기 때문에 안전합니다.이 방법은 C#을 사용하여 SQL 문을 작성하는 것과 마찬가지로 안전합니다.즉, 사용자가 제공한 데이터를 사용하여 스크립트를 생성할 때마다 신중하게(문자열을 이스케이프하는 등) 수행해야 합니다.그러나 이러한 경고와 함께 상호 운용 상황에서 분명한 위치를 차지하고 있으며 "악"과는 거리가 멀다.
할 수 eval★★★★★★ 。
코드 생성저는 최근에 하이퍼바라는 도서관을 썼는데, 가상돔과 핸들바를 연결하는 역할을 합니다.핸들바 템플릿을 해석하여 하이퍼스크립트로 변환합니다.하이퍼스크립트가 문자열로 먼저 생성되고 반환되기 전에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()을 사용하지 않을 이유가 없습니다.eval() 함수로 전송되는 내용을 조작할 수 있지만 웹 사이트의 소스 코드를 조작할 수 있어 JavaScript 코드 자체를 변경할 수 있기 때문에 보안상의 문제는 아닙니다.
그럼 언제 eval()을 사용하지 않는 건가요?Eval()은 서드파티에 의해 변경될 수 있는 경우에만 사용할 수 없습니다.클라이언트와 서버간의 접속을 대행 수신하는 등(단, 문제가 있는 경우는 HTTPS 를 사용합니다).포럼과 같이 다른 사람이 작성한 코드를 해석하기 위해 eval()을 사용하면 안 됩니다.
만약 그것이 정말 필요하다면 평가는 나쁜 것이 아니다.그러나 우연히 알게 된 평가 사용의 99.9%는 필요하지 않습니다(set Timeout은 제외).
저에게 악이란 성능이나 보안 문제가 아닙니다(간접적으로 둘 다).이렇게 불필요한 평가 사용으로 인해 유지보수가 더 어려워집니다.리팩터링 툴이 떨어집니다.코드를 검색하는 것은 어렵다.그 구제금융의 예상치 못한 효과는 엄청나다.
의 예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(이 버전은 콘크리트 멤버 Import를 지원하지 않습니다)처럼 보일 수 있습니다.
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;
}
나는 평가가 정당화되는 경우는 드물다고 생각한다.실제로 정당화될 때 사용하는 것보다 정당하다고 생각하는 경우가 더 많습니다.
보안 문제가 가장 잘 알려져 있습니다.그러나 JavaScript는 J를 사용합니다.IT 컴파일은 평가에서 매우 저조합니다.Eval은 컴파일러의 블랙박스와 비슷하며, JavaScript는 성능 최적화 및 범위 지정을 안전하고 정확하게 적용하기 위해 사전에(어느 정도) 코드를 예측할 수 있어야 합니다.경우에 따라서는 퍼포먼스에 대한 영향이 평가 밖의 다른 코드에도 영향을 줄 수 있습니다.
자세한 것은, https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closures/ch2.md#eval 를 참조해 주세요.
가능하면 테스트 중에만.또한 eval()은 다른 특수 JSON 등보다 훨씬 느립니다.평가자
저는 eval이 클라이언트 측 웹 어플리케이션과 안전성을 위해 매우 강력한 기능이라고 생각합니다.JavaScript만큼 안전하지만 그렇지 않습니다.:-) Firebug와 같은 툴을 사용하면 자바스크립트 애플리케이션을 공격할 수 있기 때문에 보안 문제는 기본적으로 서버 측의 문제입니다.
JavaScript의 eval()이 나쁜 것은 언제입니까?
저는 항상 평가 사용을 자제하려고 노력합니다.거의 항상 보다 깨끗하고 유지보수가 용이한 솔루션을 사용할 수 있습니다.JSON 구문 분석에도 평가가 필요하지 않습니다.평가는 유지보수의 지옥을 가중시킵니다.더글라스 크록포드 같은 거장들이 눈살을 찌푸리게 하는 것도 이유가 있다.
그러나 나는 그것을 사용해야 하는 한 가지 예를 발견했다.
표현을 넘겨야 할 때.
예를 들어, 나는 나를 위해 일반적인 오브젝트를 구성하는 함수를 가지고 있지만, 나는 레시피를 알려줘야 한다. 어떻게 타일 URL을 구성해야 하는가?zoom ★★★★★★★★★★★★★★★★★」coord★★★★★★★★★★★★★★★★★★:
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은 매크로가 없을 때 코드 생성에 유용합니다.
예를 들어, Brainfuck 컴파일러를 쓰고 있다면 명령어 시퀀스를 문자열로 실행하는 함수를 만들고 함수를 반환하도록 평가해야 할 것입니다.
스크립트를 연결하여 즉시 실행함으로써 달성해야 할 작업을 수행할 수 있는 경우가 많지만, 일반적으로 훨씬 강력하고 유지보수가 가능한 기술을 사용할 수 있습니다.eval이 올바른 선택인 경우는 거의 없습니다.: 연관 배열 표기법 (obj["prop"는 obj.prop과 동일), 클로저, 객체 지향 기술, 기능 기술 - 대신 사용합니다.
해석 함수를 사용하여 JSON 구조를 해석하는 경우(예를 들어 jQuery.parseJ)SON)은 JSON 파일의 완벽한 구조를 요구합니다(각 속성 이름은 큰따옴표로 묶음).그러나 JavaScript는 더 유연합니다.따라서 eval()을 사용하여 회피할 수 있습니다.
언급URL : https://stackoverflow.com/questions/197769/when-is-javascripts-eval-not-evil
'source' 카테고리의 다른 글
| MIN() 함수를 사용한 MySQL의 잘못된 결과 (0) | 2022.09.11 |
|---|---|
| Grunt, NPM 및 Bower의 차이(패키지).json vs bower.json) (0) | 2022.09.11 |
| 아름다운 수프와 아이디로 디바와 내용물을 추출 (0) | 2022.09.11 |
| 속성이 XPath로 시작하는 요소 선택 (0) | 2022.09.11 |
| 범위 내에서 'n'개의 고유한 난수 생성 (0) | 2022.09.11 |