ByePast

正则应该是不可以计算的吧

> 可以考虑增加对最近两个月份之间的对比，这个也是有两个出生年份的 月份天可以简单地进行计算，月在01-12之间，日在01-31之间，其实也有不如1800年 真正严格的标准，还是推荐代码，如 [https://github.com/dromara/hutool/blob/v5-master/hutool-core/src/main/java/cn/hu/core/util/ IdcardUtil.java](https://github.com/dromara/hutool/blob/v5-master/hutool-core/src/main/java/cn/hutool/core/util/IdcardUtil.java) 代码这个已经写出来了的，这个是严格校验的代码 ```javaScript function verifyIDCard (val) { const reg = /^(^\d{18}$|^\d{17}(\d|X|x))$/ if (!reg.test(val)) { return false } let count = 0 // 从第一位到第十七位的系数 let coefficientList...

It didn't work for me before. It's a bit related to the Chrome version. I installed it in Firefox and it worked normally. Later, I upgraded the Chrome version, and...

有没有什么好办法解决呢

我测试了一下，修复了的，mui.picker.min.js换成下面地址这个就可以了 https://github.com/Dhgan/mui/blob/aebb557f79f004cdd9c179d5754378e634180931/examples/hello-mui/js/mui.picker.min.js

> 1、首先什么是HTTP协议? http协议是超文本传输协议，位于tcp/ip四层模型中的应用层；通过请求/响应的方式在客户端和服务器之间进行通信；但是缺少安全性，http协议信息传输是通过明文的方式传输，不做任何加密，相当于在网络上裸奔；容易被中间人恶意篡改，这种行为叫做中间人攻击； 2、加密通信： 为了安全性，双方可以使用对称加密的方式key进行信息交流，但是这种方式对称加密秘钥也会被拦截，也不够安全，进而还是存在被中间人攻击风险； 于是人们又想出来另外一种方式，使用非对称加密的方式；使用公钥/私钥加解密；通信方A发起通信并携带自己的公钥，接收方B通过公钥来加密对称秘钥；然后发送给发起方A；A通过私钥解密；双发接下来通过对称秘钥来进行加密通信；但是这种方式还是会存在一种安全性；中间人虽然不知道发起方A的私钥，但是可以做到偷天换日，将拦截发起方的公钥key;并将自己生成的一对公/私钥的公钥发送给B；接收方B并不知道公钥已经被偷偷换过；按照之前的流程，B通过公钥加密自己生成的对称加密秘钥key2;发送给A； 这次通信再次被中间人拦截，尽管后面的通信，两者还是用key2通信，但是中间人已经掌握了Key2;可以进行轻松的加解密；还是存在被中间人攻击风险； > > 3、解决困境：权威的证书颁发机构CA来解决； 3.1制作证书：作为服务端的A，首先把自己的公钥key1发给证书颁发机构，向证书颁发机构进行申请证书；证书颁发机构有一套自己的公私钥，CA通过自己的私钥来加密key1,并且通过服务端网址等信息生成一个证书签名，证书签名同样使用机构的私钥进行加密；制作完成后，机构将证书发给A； 3.2校验证书真伪：当B向服务端A发起请求通信的时候，A不再直接返回自己的公钥，而是返回一个证书； 说明：各大浏览器和操作系统已经维护了所有的权威证书机构的名称和公钥。B只需要知道是哪个权威机构发的证书，使用对应的机构公钥，就可以解密出证书签名；接下来，B使用同样的规则，生成自己的证书签名，如果两个签名是一致的，说明证书是有效的； 签名验证成功后，B就可以再次利用机构的公钥，解密出A的公钥key1;接下来的操作，就是和之前一样的流程了； 3.3：中间人是否会拦截发送假证书到B呢？ 因为证书的签名是由服务器端网址等信息生成的，并且通过第三方机构的私钥加密中间人无法篡改； 所以最关键的问题是证书签名的真伪； > > 4、https主要的思想是在http基础上增加了ssl安全层，即以上认证过程；: "于是人们又想出来另外一种方式，使用非对称加密的方式；使用公钥/私钥加解密；通信方A发起通信并携带自己的公钥，接收方B通过公钥来加密对称秘钥；然后发送给发起方A；A通过私钥解密；双发接下来通过对称秘钥来进行加密通信；但是这种方式还是会存在一种安全性；中间人虽然不知道发起方A的私钥，但是可以做到偷天换日，将拦截发起方的公钥key;并将自己生成的一对公/私钥的公钥发送给B；接收方B并不知道公钥已经被偷偷换过；按照之前的流程，B通过公钥加密自己生成的对称加密秘钥key2;发送给A； 这次通信再次被中间人拦截，尽管后面的通信，两者还是用key2通信，但是中间人已经掌握了Key2;可以进行轻松的加解密；还是存在被中间人攻击风险；" 这段话不对吧，服务端只是不会发送私钥给客户端，而客户端只是需要公钥进行加密，服务端使用私钥进行解密(客户端是不知道私钥的，客户端只能公钥进行加密，无法解密)。就算是要进行签名，也不会使用服务端中那个私钥进行签名(服务端的私钥是不会暴露出来的)，而是另外一对公/私钥。怎么进行偷天换日？