分类目录归档：网络技术

网络相关技术

MySQL engine/type类型InnoDB/MYISAM/MERGE/BDB/HEAP的区别

关于MySQL的一些优化中，对MYSQL的engine选择也是一种非常重要的事，今天听同事介绍了下，innodb 和 MyISAM方式，前者主要是用于较强的事务处理，后者用于一般的数据管理。后都的速度快于前者（对大部分应用而言），而前者主要用于事务性强的，如银行、证券等要求数据非常严格的应用系统，关于其一般性介绍，我在网上找了一篇，转载于下，供大家也供自己参考。

 

看MySQL参考手册 发现CREATE TABLE 时有多种数据库存储引擎：
TYPE = {BDB | HEAP | ISAM | InnoDB | MERGE | MRG_MYISAM | MYISAM } 

网上查了下据说MyISAM、InnoDB两种引擎常用
大至区别如下[不知是否准确]：
高级处理: MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。
执行速度: MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快。
移值性: MyISAM类型的二进制数据文件可以在不同操作系统中迁移。也就是可以直接从Windows系统拷贝到linux系统中使用。

 

继续阅读 →

如何去掉链接的虚线框

今天为了把一个HTML的A标记做一个链接，但是点击后有虚框，看起来很是不爽。于是去BAIDU.结果BAIDU千篇一律的相同的。。不过都是不可用的。郁闷。。。还是去GOOGLE吧。运气好。第二条记录便是我想要的。感谢CSSBABY的方案，非常好用。。不过这个方法不怎么统一哈。。没办法，浏览器厂商是这样的。我们只有这样解决啦。。。

   

当一个链接得到焦点时，默认会有个虚线框。如图：

链接虚线框

继续阅读 →

IE各种版本的CSS识别方式

从网上收集来的关于IE各种版本的CSS识别方式，如果，以后免得到处找。

  • <!–[if !IE]><!–> 除IE外都可识别 <!–<![endif]–>
  • <!–[if IE]> 所有的IE可识别 <![endif]–>
  • <!–[if IE 5.0]> 只有IE5.0可以识别 <![endif]–>
  • <!–[if IE 5]> 仅IE5.0与IE5.5可以识别 <![endif]–>
  • <!–[if gt IE 5.0]> IE5.0以及IE5.0以上版本都可以识别 <![endif]–>
  • <!–[if IE 6]> 仅IE6可识别 <![endif]–>
  • <!–[if lt IE 6]> IE6以及IE6以下版本可识别 <![endif]–>
  • <!–[if gte IE 6]> IE6以及IE6以上版本可识别 <![endif]–>
  • <!–[if IE 7]> 仅IE7可识别 <![endif]–>
  • <!–[if lt IE 7]> IE7以及IE7以下版本可识别 <![endif]–>
  • <!–[if gte IE 7]> IE7以及IE7以上版本可识别 <![endif]–>

Aapache与IIS所选择PHP版本也会不同

最近为了一个项目，而且需要搭建php开发环境，但遇到不少问题，现在把我的搭建过过程与大家分享。主是要有些东西按网上的说话，找到不全，不知为什么。最后到官方网站找到原因

在选择php下载时应注意以下问题，先看官方的提醒，如下：

继续阅读 →

BASE64编码的图片在网页中的显示问题的解决

1.为什么要用到BASE64编码的图片信息

Base64是网络上最常见的用于传输8Bit字节代码的编码方式之一。Base64主要不是加密，它主要的用途是把一些二进制数转成普通字符用于网络传输。由于一些二进制字符在传输协议中属于控制字符，不能直接传送需要转换一下。最常见的用途是作为电子邮件或WebService附件的传输编码.

2.base64编码定义

目前的internet e-mail标准–简单邮件传递协议(smtp)在rfc821中规定了两条重要但不难实现的限制：

1)  邮件的内容必须全部为7-比特的美国ascii码。

2)  每一行的长度不能超过1000的字符。

因此为了通过smtp用e-mail进行传送,内存的序列化对象必须转化为和以上相容的格式。

rfc1521提供了一个可行的方案。它定义了邮件的内容部分,使之能包涵多种形式的数据。这种标准就是目前众所周知的mime。

按照rfc1521编码过程为:输入是24个比特,输出是4个字节。24个比特输入组从左至右 由3个8比特的输入组形成。这24个比特被看成4个连续的6比特组,而每个6比特输入组被翻译为base64码表中的一个数字。依次反复不断进行，直到全 部输入数据转换完成。

如果最后剩下两个输入数据，在编码结果后加1个“=”；如果最后剩下一个输入数据，编码结果后加2个“=”；如果没有剩下任何数据，就什么都不要加，这样 才可以保证资料还原的正确性。

完整的base64定义可见 RFC1421和 RFC2045。编码后的数据比原始数据略长，为原来的4/3。在电子邮件中，根据RFC822规定，每76个字符，还需要加上一个回车换行。可以估算编 码后数据长度大约为原长的135.1%。

继续阅读 →