题目:
十道选择,几道填空,三道大题
- proxy代理;
- generator中的yield*;
- Number.isNaN()判断;
- 正则表达式获取三四级域名(这个我没做出来);
- 服务器通过设置什么响应头来设置Cookie,又通过设置什么使cookie不能被js脚本获取;
- await,setTimeout的代码选择答案;
- js数组API乱炖的代码选择答案;
- 临时重定向的响应码(302);什么响应码可以使客户端使用本地缓存(304);
- 简答题:URL->浏览器的简单描述;
- 代码题:
- 输入两个数组,去重后获取最接近平均值的最小值。举例:[1,2,3,4,6],[2,3,4,5],平均值是3.5,result是3;
- 不超过5位的数转中文。举例:12345转为一万两千三百四十五。
解:
1. proxy代理
ES6中的代理模式-----Proxy
Proxy 对象用于定义基本操作的自定义行为(如属性查找,赋值,枚举,函数调用等)。
简单来说:Proxy对象就是可以让你去对JavaScript中的一切合法对象的基本操作进行自定义.然后用你自定义的操作去覆盖其对象的基本操作.也就是当一个对象去执行一个基本操作时,其执行的过程和结果是你自定义的,而不是对象的.
对于代理模式Proxy
的作用主要体现在三个方面:
1、 拦截和监视外部对对象的访问
2、 降低函数或类的复杂度
2、 在复杂操作前对操作进行校验或对所需资源进行管理
2. generator
Generator 是 ES6 中新增的语法,和 Promise ⼀样,都可以⽤来异步编程
// 使⽤ * 表示这是⼀个 Generator 函数
// 内部可以通过 yield 暂停代码
// 通过调⽤ next 恢复执⾏
function* test() {
let a = 1 + 2;
yield 2;
yield 3;
}
let b = test();
console.log(b.next()); // > { value: 2, done: false }
console.log(b.next()); // > { value: 3, done: false }
console.log(b.next()); // > { value: undefined, done: true }
从以上代码可以发现,加上 * 的函数执⾏后拥有了 next 函数,也就是说函数执⾏后返回了⼀个对象。每次调⽤ next 函数可以继续执⾏被暂停的代码。
3. Number.isNaN()
Number.isNaN()
方法确定传递的值是否为 NaN
,并且检查其类型是否为 Number
。 在 JavaScript 中,NaN
最特殊的地方就是,我们不能使用相等运算符(==
) 和 ===
)来判断一个值是否是 NaN
,因为 NaN == NaN
和 NaN === NaN
都会返回 false
。因此,必须要有一个判断值是否是 NaN
的方法。
和全局函数 isNaN()
相比,Number.isNaN()
不会自行将参数转换成数字,只有在参数是值为 NaN
的数字时,才会返回 true
。
Number.isNaN(NaN); // true
Number.isNaN(Number.NaN); // true
Number.isNaN(0 / 0) // true
// 下面这几个如果使用全局的 isNaN() 时,会返回 true。
Number.isNaN("NaN"); // false,字符串 "NaN" 不会被隐式转换成数字 NaN。
Number.isNaN(undefined); // false
Number.isNaN({}); // false
Number.isNaN("blabla"); // false
// 下面的都返回 false
Number.isNaN(true);
Number.isNaN(null);
Number.isNaN(37);
Number.isNaN("37");
Number.isNaN("37.37");
Number.isNaN("");
Number.isNaN(" ");
Number.isNaN = Number.isNaN || function(value) {
return typeof value === "number" && isNaN(value);
}
4. 正则表达式
5. 响应头设置cookie
ajax请求时是不会自动带上cookie的,要是想让它带上的会,必须要设置withCredentials为true。
有两种方法可以确保 Cookie
被安全发送,并且不会被意外的参与者或脚本访问:Secure
属性和HttpOnly
属性。
- 标记为
Secure
的 Cookie 只应通过被 HTTPS 协议加密过的请求发送给服务端,因此可以预防 {{Glossary(“ MitM”,“ man-in-the -middle“)}} 攻击者的攻击。但即便设置了Secure
标记,敏感信息也不应该通过 Cookie 传输,因为 Cookie 有其固有的不安全性,Secure
标记也无法提供确实的安全保障, 例如,可以访问客户端硬盘的人可以读取它。 从 Chrome 52 和 Firefox 52 开始,不安全的站点(http:
)无法使用Cookie的Secure
标记。 - JavaScript {{domxref(“ Document.cookie”)}} API 无法访问带有
HttpOnly
属性的cookie;此类 Cookie 仅作用于服务器。例如,例如,持久化服务器端会话的 Cookie 不需要对 JavaScript 可用,而应具有HttpOnly
属性。此预防措施有助于缓解跨站点脚本(XSS))攻击。