当你想下载Linux、JDK、Tomcat、eclipse时,你是下载32位版本还是64位版本?64位版本有两种,应该选哪一个?
当你看到这些内容:x86、x64、x86-32、x86-64、ia64、i80386、i80486、i80586、i80686,知道是干什么的吗?
这事儿要先从CPU说起:
-------------------------------
IA-32架构与IA-64架构
IA是Intel
Architecture(英特尔体系结构)的英语缩写。
IA-32架构下有32位CPU,也64位CPU。(我们经常使用的CPU)
IA-64架构下有Intel64的位CPU (只有服务器使用的CPU)
-------------------------------
IA-32架构:
本架构的CPU都采用X86指令
Intel、AM
在更改数据量大的表格数据结构时,不要点“保存”按钮,而是在表结构编辑框左侧点右键===》选择“生成更改脚本”,这时出来了文本对话框,把里面的内容全选并复制,并关闭这个表,选择不保存,右击该表所属的数据库,选“新建查询”,之后Ctrl+V把刚复制的脚本粘进来,并运行。这样就再也不会弹出超时的提示了,如果数据量相当大,我们只需要耐心等待即可了!
(2012-01-21 14:46)
短信网关在处理SP接入的同时,他还有个很重要的作用就是流控,以防止第三方突然提交大量的短信而导致整个短信平台出现异常增加的流量,导致系统不稳定。为了实现对于客户端过来的请求进行流控,由于无法判断SP提交的短信实时速度,短信网关需要将实时提交的短信进行分时(类似高数里面的微积分的概念),并根据细小的分时来统计当前的流量,对于超过流控的流量进行过滤。这句话不大好理解,我们可以简单举个例子:假设网关开给你的流量是10条/秒,那个网关就给你准备10个杯子,你在1秒内往10个杯子倒水,网关并不是实时进行清空,1秒后网关就会一次清空这10个杯子。这里会出现两种情况,一种是你没有倒满10个杯子,那么你的流量就没到10条/秒,这样就没有问题,如果1秒内你倒了12个杯子,其中有2杯子的水没有地方盛放,那么那两个杯子的水就倒到外面了,也就是被流控了。当然网关分时可能比这1秒的时间更短。这个例子说明两个问题:一、在细小的时间间隔内,网关进行的流控,所以提交的短信并不是按照几分钟内的提交速度,虽然你可能1分钟提交的短信总量按照每秒换算并未超过流控,但是你在中间某几秒提交的速度过快,也会导致被流控。二、虽然你可能按照严格的流量进行满打满
(2012-01-14 04:55)
反编译Apk得到Java源代码
一、反编译Apk得到Java源代码
首先要下载两个工具:dex2jar和JD-GUI
前者是将apk中的classes.dex转化成Jar文件,而JD-GUI是一个反编译工具,可以直接查看Jar包的源代码。以下是下载地址:
dex2jar:http://laichao.googlecode.com/files/dex2jar-0.0.7-SNAPSHOT.zip
JD-GUI:http://laic
把/dev/null看作'黑洞'.
它非常等价于一个只写文件. 所有写入它的内容都会永远丢失. 而尝试从它那儿读取内容则什么也读不到. 然而,
/dev/null对命令行和脚本都非常的有用.
禁止标准输出.
cat $filename >/dev/null
# 文件内容丢失,而不会输出到标准输出.
|
禁止标准错误
rm $badname 2>/dev/null
# 这样错误信息[标准错误]就被丢到太平洋去了.
|
禁止标准输出和标准错误的输出.
cat $filename 2>/dev/null >/dev/null
# 如果'$filename'不存在,将不会有任何错误信息提示.
|
用curl获取一个经过gzip压缩后的网页时返回乱码
原因大体就是服务器返回的Content-Encoding的值和网页的编码不同,造成curl解码出问题,直接将gzip或deflate编码的文件下载了,所以看起来是乱码了。
Content-Encoding: gzip
读取前几个字节为:1F 8B 08 ,其中1F 8B表明为gzip压缩,而08表示为deflate压缩。
这样实际编码和通过Content-Encoding获取的编码不一样,所以curl解码出错,导致下载的是未解码的页面,也就是一堆乱码。
知道了原因,就有了解决方案了
可以通过读取下载的二进制文件的前3个字节,来判断是否是压缩文件