首页 文章 精选 留言 我的

精选列表

搜索[智能解析]，共10007篇文章
优秀的个人博客,低调大师

Jsp 无法解析${}

错误原因1：未导包 解决： maven依赖 <!-- JSTL for JSP --> <!-- https://mvnrepository.com/artifact/javax.servlet/jstl --> <dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> </dependency> <!-- https://mvnrepository.com/artifact/taglibs/standard --> <dependency> <groupId>taglibs</groupId> <artifactId>standard</artifactId> <version>1.1.2</version> </dependency> 手动导入 图1.png 错误原因2：配置 解决： 在首行设置isELIgnored为false，即不忽略EL表达式 <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" isELIgnored="false"%>
2018-05-12
优秀的个人博客,低调大师

__cdecl __stdcall 解析

1.如果函数func是__cdecl(默认调用方式)，调用时情况如下 int main() { //参数从右到左压栈 push4 push3 push2 push1 call func add esp0x10//调用者恢复堆栈指针esp，4个参数的大小是0x10(4x4) } 2.如果函数func是__stdcall，调用时情况如下 int main() { //参数从右到左压栈 push4 push3 push2 push1 call func //恢复堆栈指针由被调用者func负责，方法是"ret 0x10" } 3.如果函数func是__pascal，调用情况如下 int main() { //参数从左到右压栈 push1 push2 push3 push4 call func //恢复堆栈指针由被调用者func负责，方法是"ret 0x10" } 3.如果函数func是__fastcall，调用情况如下 int main() { //参数先用ecx, edx, eax传递，然后再压栈 //不进栈 //(不知为什么，帮助中写的是从左到右传递的， //是不是错了，还是bcb6和bcb5的不一样) push4 mov ecx3 mov edx2 mov eax1 call func //恢复堆栈指针由被调用者func负责，方法是"ret 0x04", //因为只进栈一个参数，其余用寄存器传递，所以用ret 0x04恢复 } 发表者：huang_jh #define callback __stdcall #define winapi __stdcall 定义成不同的名字只是为了"望文知意"就像hwnd和hcursor是一样的类型. 他们都是窗口函数(过程)...... 发表者：sinman 我收集的，全仍上来了 左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，但不同的是函数名的修饰部分。 _stdcall是pascal程序的缺省调用方式，通常用于win32 api中，函数采用从右到左的压栈方式，自己在退出时清空堆栈。vc将函数编译后会在函数名前面加上下划线前缀，在函数名后加上"@"和参数的字节数。 2、c调用约定按从右至左的顺序压参数入栈，由调用者把参数弹出栈。对于传送参数的内存栈是由调用者来维护的。另外，在函数名修饰约定方面也有所不同。 _cdecl是c和c＋＋程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文件大小会比调用_stdcall函数的大。函 数采用从右到左的压栈方式。vc将函数编译后会在函数名前面加上下划线前缀。是mfc缺省调用约定。 3、__fastcall调用约定是“人”如其名，它的主要特点就是快，因为它是通过寄存器来传送参数的或更小的参数，剩下的参数仍旧自右向左压栈传送， 被调用的函数在返回前清理传送参数的内存栈），在函数名修饰约定方面，它和前两者均不同。 _fastcall方式的函数采用寄存器传递参数，vc将函数编译后会在函数名前面加上"@"前缀，在函数名后加上"@"和参数的字节数。 4、thiscall仅仅应用于“c++”成员函数。this指针存放于cx寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定。 5、naked call采用1-4的调用约定时，如果必要的话，进入函数时编译器会产生代码来保存esi，edi，ebx，ebp寄存器，退出函数时则产生代码恢复这些 寄存器的内容。naked call不产生这样的代码。naked call不是类型修饰符，故必须和_declspec共同使用。 关键字 __stdcall、__cdecl和__fastcall可以直接加在要输出的函数前，也可以在编译环境的setting...\c/c++ \code generation项选择。当加在输出函数前的关键字与编译环境中的选择不同时，直接加在输出函数前的关键字有效。它们对应的命令行参数分别为/gz、 /gd和/gr。缺省状态为/gd，即__cdecl。 要完全模仿pascal调用约定首先必须使用__stdcall调用约定，至于函数名修饰约定，可以通过其它方法模仿。还有一个值得一提的是winapi 宏，windows.h支持该宏，它可以将出函数翻译成适当的调用约定，在win32中，它被定义为__stdcall。使用winapi宏可以创建自己 的apis。 2)名字修饰约定 1、修饰名(decoration name) “c”或者“c++”函数在内部通过修饰名识别。修饰名是编译器在编译函数定义或者原型时生成的字符串。有些情况下使用函数的修饰名是必要的，如在模块定 义文件里头指定输出“c++”重载函数、构造函数、析构函数，又如在汇编代码里调用“c””或“c++”函数等。 修饰名由函数名、类名、调用约定、返回类型、参数等共同决定。 2、名字修饰约定随调用约定和编译种类(c或c++)的不同而变化。函数名修饰约定随编译种类和调用约定的不同而不同，下面分别说明。 a、c编译时函数名修饰约定规则： __stdcall调用约定在输出函数名前加上一个下划线前缀，后面加上一个“@”符号和其参数的字节数，格式为_functionname@number。 __cdecl调用约定仅在输出函数名前加上一个下划线前缀，格式为_functionname。 __fastcall调用约定在输出函数名前加上一个“@”符号，后面也是一个“@”符号和其参数的字节数，格式为@functionname@number。 它们均不改变输出函数名中的字符大小写，这和pascal调用约定不同，pascal约定输出的函数名无任何修饰且全部大写。 b、c++编译时函数名修饰约定规则： __stdcall调用约定： 1、以“?”标识函数名的开始，后跟函数名； 2、函数名后面以“@@yg”标识参数表的开始，后跟参数表； 3、参数表以代号表示： x--void ， d--char， e--unsigned char， f--short， h--int， i--unsigned int， j--long， k--unsigned long， m--float， n--double， _n--bool， .... pa--表示指针，后面的代号表明指针类型，如果相同类型的指针连续出现，以“0”代替，一个“0”代表一次重复； 4、参数表的第一项为该函数的返回值类型，其后依次为参数的数据类型,指针标识在其所指数据类型前； 5、参数表后以“@z”标识整个名字的结束，如果该函数无参数，则以“z”标识结束。 其格式为“?functionname@@yg*****@z”或“?functionname@@yg*xz”，例如 int test1-----“?test1@@yghpadk@z” void test2 -----“?test2@@ygxxz” __cdecl调用约定： 规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的“@@yg”变为“@@ya”。 __fastcall调用约定： 规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的“@@yg”变为“@@yi”。 vc++对函数的省缺声明是"__cedcl",将只能被c/c++调用. cb在输出函数声明时使用4种修饰符号 //__cdecl cb的默认值，它会在输出函数名前加_，并保留此函数名不变，参数按照从右到左的顺序依次传递给栈，也可以写成_cdecl和cdecl形式。 //__fastcall 她修饰的函数的参数将尽肯呢感地使用寄存器来处理，其函数名前加@，参数按照从左到右的顺序压栈； //__pascal 它说明的函数名使用pascal格式的命名约定。这时函数名全部大写。参数按照从左到右的顺序压栈； //__stdcall 使用标准约定的函数名。函数名不会改变。使用__stdcall修饰时。参数按照由右到左的顺序压栈，也可以是_stdcall； 发表者：echoher far是古代的东西 在16位模式下，指针是16位的 指针的寻址空间只有64k 如果指定far，说明这个指针指向的地址要加上基地址 就是说用far可以指定64k以外的区域 现在已经没用了 一点用也没有了 原文http://hi.baidu.com/_%E2d_%B7%B3_%DE%B2%C2%D2/blog/item/4e48666da7c769ff4316948c.html ============================================================================== 本文转自被遗忘的博客园博客，原文链接：http://www.cnblogs.com/rollenholt/articles/2423120.html，如需转载请自行联系原作者
2018-01-05
优秀的个人博客,低调大师

android fastjson 解析

JSONObject jsonObject = JSON.parseObject(wsResponse);String recommends = jsonObject.getString("recommends");Log.i("ss","__________________________recommends:"+recommends); List<Recommend> contents = JSON.parseArray(recommends, Recommend.class); Log.i("ss","____________________________contents.size:"+contents.size());注意： 1:是Integer不是int2:是implements Serializable，不是implements Serializable, Parcelable public class Recommend implements Serializable { private Integer mediaId; private String title; private Integer timeSpan; private Integer roomId; private String roomName; private Integer gameId; private Float overallScore; private Integer scoreType; private Integer totalViews; private Integer definition; private String createTime; } 本文转自wanqi博客园博客，原文链接http://www.cnblogs.com/wanqieddy/p/4655032.html，如需转载请自行联系原作者
2017-12-21
优秀的个人博客,低调大师

SecureRandom漏洞解析

SecureRandom漏洞描述 2013年比特币开发商在一篇博客中透露，由于Android系统存在一处关键漏洞，该平台上的比特币电子钱包很容易失窃。比特币开发商称，该漏洞影响到Android平台上的每一个比特币电子钱包应用程序，包括流行的比特币钱包（BitcoinWallet）、blockchain.info钱包（blockchain.infowallet）、BitcoinSpinner钱包（BitcoinSpinnerWallet）和Mycelium钱包（MyceliumWallet）等。 该漏洞存在于Android系统随机生成数字串安全密钥的环节中。该漏洞的生成原因是对SecureRandom类的不正确使用方式导致的。 翻看Android的官方文档会发现。对于SecureRandom类的构造函数SecureRandom(byte[] seed)和SecureRandom#setSeed方法有一段安全性提醒： “Seeds this SecureRandom instance withthe specified Seeding SecureRandom may be insecure” 遗憾的是Android官网并未对此做过多的解释。setSeed方法为什么会引起安全风险？应该怎样使用SecureRandom类？ SecureRandom漏洞详情 1. SecureRandom漏洞位置 SecureRandom＃SecureRandom(byte[] seed) SecureRandom＃setSeed(long seed) SecureRandom＃setSeed(byte[] seed) 2.SecureRandom漏洞触发条件 在调用SecureRandom类的构造函数SecureRandom(byte[] seed)。或者在生成随机数之前调用setSeed(long seed)或者setSeed(byte[] seed)方法设置随机种子 3. SecureRandom漏洞原理 SecureRandom随机性是通过它的seed来保证的。如果输入相同的seed会导致生成重复的随机数。SecureRandom内部维护一个internal random state，它生成随机数的方式具有确定性。（如果输入相同的seed那么生成的随机数也相同）具体过程如下图： 在生成一个随机数时internal random state会从seed源中取出一个seed。通过内部运算生成随机数。internal random state具有确定性，不能保证SecureRandom的随机性，所以SecureRandom依靠输入的seed的随机性保证自己能够生成出不相同的随机数。 SecureRandom漏洞POC 在SecureRandom生成随机数时，如果我们不调用setSeed方法，SecureRandom会从系统的中找到一个默认随机源。每次生成随机数时都会从这个随机源中取seed。在linux和Android中这个随机源位于/dev/urandom文件。如果我们在终端可以运行cat /dev/urandom命令，会观察到随机值会不断的打印到屏幕上。 在Android 4.2以下，SecureRandom是基于老版的Bouncy Castle实现的。如果生成SecureRandom对象后马上调用setSeed方法。SecureRandom会用用户设置的seed代替默认的随机源。使得每次生成随机数时都是会使用相同的seed作为输入。从而导致生成的随机数是相同的。下面是一段存在安全风险的使用方法： SecureRandomsecureRandom=newSecureRandom(); byte[]b=newbyte[]{(byte)1}; secureRandom.setSeed(b); //PriortoAndroid4.2,thenextlinewouldalwaysreturnthesamenumber! System.out.println(secureRandom.nextInt()); 在Android4.2 之前使用以上代码， Android会用种子byte b[]代替了系统默认的随机数生成源。导致nextInt()方法总是范围同一个随机数。 4.2以上的SecureRadom类为什么没有这个问题呢？因为经过比特币钱包漏洞之后Google修改了SecureRandom的内部实现，用基于OpenSSL的算法替代了老版的Bouncy Castle。用户调用setSeed时会将用户设置的seed添加到随机源（/dev/urandom）中而不是简单的替换。 SecureRandom漏洞修复建议： 1.不要使用自定义随机源代替系统默认随机源（推荐）除非有特殊需求，在使用SecureRandom类时，不要调用以下函数： SecureRandom＃SecureRandom(byte[]seed) SecureRandom＃setSeed(longseed) SecureRandom＃setSeed(byte[]seed) 2.在调用setSeed方法前先调用任意nextXXX方法。原理如下： 我们可以通过SecureRandom＃nextBytes(byte[] bytes)避免这个问题。具体做法是调用setSeed方法前先调用一次SecureRandom＃nextBytes(byte[] bytes)方法。为什么这样就可以避免默认随机源被替代呢？我们可以从源码中找到答案。（本文所引用代码全部基于Android API 16） 在SecureRandom初始化时，会生成一个SecureRandomSpi对象。SecureRandom的核心方法都由SecureRandomSpi对象代理。下面是SecureRandomSpi类的子类SHA1PRNG_SecureRandomImpl的初始化源码： 在初始化时会将内部状态机设置为state = UNDEFINED。如果使用者接着调用SecureRandom＃nextBytes方法， SecureRandom会调用SecureRandomSpi#engineNextBytes方法 如果state的状态为UNDEFINED，那么nextBytes会使用默认的随机源。并将state设置为NEXT_BYTES之后如果调用setSeed方法，最终会调用到SecureRandomSpi#engineSetSeed方法.源码如下： 当state＝＝NEXT_BYTES时会恢复原有的hash再更新seed，因为nextBytes时已经设置了系统的seed所以setSeed中传入的seed将添加到系统seed的尾部。这样生成随机数时也会在系统的随机源中找seed，从而保证其随机性。 SecureRandom的一种误用模式 最近网上流传一种利用SecureRandom输出固定随机值并用这个随机值当作加密秘钥的用法。这种模式利用前一节中提到的用特定seed代替系统随机源的方法，故意让SecureRandom每次都输出固定的随机值。通过这个固定值作为秘钥加密本地文本。其使用方式和流程如下： 使用例子： 这种方式确实可以对原始秘钥做一定的隐藏。起到混淆的作用。但google官方博客否定了该方式的使用。原因如下： 1.对资深的攻击者而言这种方式的加密太过简单。他们可以轻易的看懂这里在干什么，并构造有效的攻击代码。 2.整个加密的过程依赖SecureRandom的实现细节，这种依赖使得程序健壮性和可扩展性都非常脆弱。例如在Android API 17以后SecureRandom的默认实现方式从Cipher.RSA换到了OpenSSL。SecureRandom新的实现方式不能将自己的seed替换掉系统的seed。造成这段代码在API 17以上不能工作。APP必须强制升级才能继续运作。对某个类内部细节的依赖是软件设计中的大忌。 3.从seed到生成key的过程非常的廉价，时间成本和资源要求的很低。如果攻击者采用暴力破解这种加密方式将显的很脆弱。 如何正确的从password生成一个秘钥？ 标准的秘钥生成方式应该使用PKCS#5算法。该算法主要有两个优点。 1.利用随机盐加强秘钥的强度。随机盐可以有效的防止暴力破解。同一个password可以生成多个秘钥。攻击者不得不针对每个salt构造不同的秘钥字典。 2.通过迭代方式增加秘钥生成的时间成本。使得攻击者破解秘钥的时间大大增加。 Android的JCE provider现在能支持PBKDF2WithHmacSHA1。下面的代码将展示如何通过PBK算法将password生成为一个秘钥。 原文链接：阿里聚安全：http://jaq.alibaba.com/blog.htm?id=47
2017-11-26
优秀的个人博客,低调大师

VasSonic源码解析

H5很重要，H5很重要，H5很重要，重要的事情要说三遍。VasSonic是腾讯开源的解决H5首屏渲染痛点的开源项目，本文通过解读代码来学习WebView的优化思路。 H5的优劣 H5的优势很明显，跨平台、迭代快、开发体验好。H5的劣势同样明显，加载慢，用户体验差。业内大牛想尽各种方法来弥补H5的劣势，初级使用缓存、预加载等常用方案，高级如Hybrid、ReactNative、Weex等H5的进阶解决方案。VasSonic专注于H5的秒开，使用的也是我们常见的性能优化方案。本文尝试了解VasSonic是如何用常见的手段将性能优化做到极致的。 VasSonic解决什么问题 关于WebView为什么打开慢、加载慢，业界已经有很多分析了，结论也是比较一致的，推荐美团点评技术团队的WebView性能、体验分析与优化，腾讯关于VasSonic的官方文
2017-09-18
优秀的个人博客,低调大师

HBase架构解析

Hbase组件  客户端Client 整个HBase集群的入口 使用HBase RPC机制与HMaster和HRegionserver通信 与HMaster通信进行管理类的操作 与HRegionserver通信进行读写类操作 包含访问HBase的接口，并维护cache来加快对HBase的访问，与HRegionserver交互 程序协调服务Zookeeper 保证任何时候，集群中只有一个Master 存贮所有Region的寻址入口 实时监控Region server的上线和下线信息。并实时通知给Master 存储HBase的schema和table元数据 HBase主节点Master 管理用户对Table的增删改查操作 管理HRegionServer的负载均衡，调整Region分布 在Region Split后，负责新Region的分配 在HRegionServer停机后，负责失效HRegionServer上的Region迁移 HMaster失效仅会导致所有元数据无法被修改，表的数据读写还是可以正常运行 HBase与Zookeeper HBase元数据存储在Zookeeper中 默认情况下，HBase管理Zookeeper示例，比如，启动或停止Zookeeper Zookeeper解决HBase单节点故障问题 HMaster与HRegionserver启动时回向Zookeeper注册 寻找RegionServer过程详解  - Zookeeper(读取Zookeeper找到-ROOT-表的位置) - -ROOT-(-ROOT-表包含.META.表所在的region列表，该表只会有一个Region;Zookeeper中记录了-ROOT-表的location) - .META(这个表包含所有的用户空间region列表，已经RegionServer的服务器地址) - 用户表 - Client第一次操作后，会将-ROOT-和.META.缓存到本地，不需要再访问zookeeper (PS:0.96之后的版本，ZK不再存储ROOT表信息，直接存储META表信息) HBase容错性 Master容错:Zookeeper重新选择一个新的Master 无Master过程中，数据读取仍然照常进行； 无Master中，region切分，负载均衡无法进行； RegionServer容错:定时向Zookeeper汇报心跳，如果一段时间内未出现心跳，master将该RegioinServer上的Region重新分配到其他RegionServer上；失效服务器上“预写”日志由服务器进行分割并派送给新的ReginServer zookeeper容错:Zookeeper高可靠的服务，不存在单点故障
2017-07-31

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册