勇者无疆

今天，居然发现了一个IE支持，而Firefox确不支持的CSS属性。

.peopleBox a { text-indent:-999px; }

测试的时候，发现IE下表现良好，但是Firefox确无动于衷。

一直以来，从小到大，思想里从来不会出现这样的情形，所以当时确实是大吃一惊。

Google后才发现:

This property specifies the indentation of the first line of text in a block. More precisely, it specifies the indentation of the first box that flows into the block’s first line box. The box is indented with respect to the left (or right, for right-to-left layout) edge of the line box. User agents should render this indentation as blank space.

原来只对块级元素起作用，而且只是第一行。看来这些东西记得还是不是很牢固

参考资料：
1、W3C

目前网络上有众多的在线电子地图服务，诸如Mapabc、Google Maps、Yahoo Maps、Mapbar、Microsoft Virtual Earth Maps、51地图等等。使用这些开放的API，地图应用的开发者和爱好者们可以非常方便的调用在线地图服务提供的各种资源、实现各种各样的地图第三方应用。

最近工作上需要选择一种地图API来嵌入到现有的产品中，开始在众多的API服务中进行选择，最后选定了Mapabc，下面就说一下选择的理由。

1、支持的接口非常丰富。Flash地图、静态地图、Flex地图三种选择。Flash地图对于跨平台的支持非常好，而且在一些比较轻量的调用上，我可以配合静态地图，这样就能够比较合理的规划自己的应用。

2、本土公司，文档资料全部为中文。Mapabc提供了丰富详细的产品文档和调用示例，这个对于API的上手是非常有益的，而且本土公司，全中文的支持对于我们理解和解决问题带来很多好处。

3、支持公交查询。Mapabc提供了全面、详细的公交查询及结果。北京巴士公司使用的地图查询就是由Mapabc来提供，有了这样的合作关系，公交线路数据的更新也会非常及时，而这个是目前其他地图API服务所无法企及的。

4、收费策略。Mapabc的收费比较低，收费方式多样，可以根据地图数据的区域收费。而且达成合作后，还可以将服务部署到局域网内部，非常适合自己有服务器实力的大集团用户。

5、支持明码坐标。Mapabc API在2.0版本，支持了明码偏转坐标，同时仍能够兼容1.0版本的字符坐标。明码坐标的支持，对于自己开发一些基于坐标运算的地图应用非常有用，而同时支持字符坐标，对于坐标数据也能起到一定的保密作用。

6、实景地图的整合。Mapabc与国内的实景服务提供商City8有合作，在API中嵌入了相关的调用接口，可以实现地图和实景的无缝连接。

7、稳定的服务。鉴于国内互联网整治的风潮以及Google在走与留之间博弈的影响，所以考虑使用国内的地图服务提供商，这样能够保证服务稳定性和可访问性。而且Mapabc的兄弟公司图盟，是国内少数的拥有地图测绘资质的公司，所以其也能够稳定持续的提供高质量的地图数据。

当然，Mapabc与Google Maps的API比起来，也有一些缺点，希望在今后API的升级中，能够逐步的赶上国际级的地图服务提供商。

1、地址解析。能够直接将用户的地址解析到具体的经纬度，并且在地图上展示出来。

2、卫星图支持。目前Mapabc还无法提供卫星图的支持。事实上，按照国家相关法律的规定，国内的地图服务商很难提供卫星图的支持。Sohu的实景据说是有政府背景才能够提供的。

3、对于手机的支持。目前Mapabc API对于手机客户端的支持还比较薄弱。

4、响应速度上的考虑。Mapabc作为网络方面的后起之秀，实力同Google和百度等互联网巨头还是无法相比，在硬件设施和网络带宽上的投入势必会影响其服务的响应速度和质量，这一点在选择时，也会成为一个顾虑。

————–

有兴趣的朋友可以加入QQ群：93429544

或者到论坛中来交流一下

参考资料：
1、主流电子地图API比较
2、记录几个关于Google Map API的站点
3、国内地图比较

由于之前黑莓一直存在内存不足的情况，而且严重的时候会丢失短信，为了解决这个问题，我决定利用这一天的时间对黑莓进行刷机和瘦身。

刷机之前先用 wipe 格式化手机，然后在利用DM 安装下载的ROM。

这个过程不是很难，按照 1 的方法很容易可以做到，当然，前提是你的系统中这两个程序都没有安装过，而且你是第一次刷机的时候。

我第一次也是很顺利的将系统进行了瘦身，并且刷成了4.5.0.174 的系统。

系统安装完成后，希望能够美化自己的 BB，结果就是在这个地方，差点他成为板砖。

问题出在两个方面：

1、没有及时的将Vendor.xml 还原。刷机的时候，需要将这个文件删除或者重命名，完成后需要还原，否则安装文件会出现问题。我没有还原，但是安装了几个软件，刚开始没什么问题，后来几个就出现了“更新设备时发生严重错误”的提示。

2、使用alxMake生成的alx文件。下载了很多主题都没有 alx 文件，用alxMake生成的alx文件中，顺序总是不对，不知道是不是这个问题的原因。

好在，blackberry的机器还比较抗造，经过一天的折腾，没有变成板砖。

顺便说一下，我的黑莓是 8320，刷的系统是 4.5.0.174 使用的dm 版本是 4.7.0 B59

参考资料：

1、黑莓瘦身教程

2、黑莓入门设置

YUI3的Overlay为我们提供了一个创建叠加层的方便的方（从名字就可以看出来），他扩展自Widget类。目前的版本，仅支持简单的页面XY定位、相对于一个Node或者viewport对其或居中。下面来体验一下Overlay。

最简单的引用YUI3的方法自然是引用Yahoo服务器上的种子文件，地址如下：

<script src="http://yui.yahooapis.com/3.0.0/build/yui/yui-min.js"></script>

引用了种子文件之后，我们就可以在我们的应用中使用Overlay了，建立一个新的YUI的命名空间，如下：

YUI().use(‘overlay’,function(Y){

    var overlay = Y.Overlay({

         contentBox:“#MyContent”,

         visible:true,

         width:“20em”,

         height:“20em”,

         xy:[200,200]    
    });

    overlay.render();

});

先来熟悉一下overlay所支持的属性：

内容：

overlay的内容既可以是我们事先写在页面中的，也可以通过script在后期创建。因为使用了标准的模块，所以内容基本上有三个部分：headerContent、bodyContent、footerContent。通过脚本设置内容的时候，既可以直接填入innerHTML，也可以通过传入一个node对象来实现，使用的方式非常的灵活。

定位：

Overlay的定位有三种方式，xy、对齐、居中。

xy定位的方式是通过指定x,y或者xy来为叠加层定位，这个定位是基于页面的xy坐标，比如[200,200]是相对于页面左上角分别200px的位置。

对齐(align)，可以将overlay与页面中的某个node进行对齐，通过传入一个两个属性的对象来实现，如下例：

YUI().use(‘overlay’,function(Y){

  var overlay = Y.overlay({

       contentBox:“MyContent”

       align:{

             node:“MyAchor”

             points:[Y.WidgetPositionExt.TL,Y.WidgetPositionExt.TR]

});

其中points表示叠加层和要对其的node的位置关系，第一个参数为叠加层，第二个为对齐node，上例的参数表示叠加层的左上角和node的右上角对齐。

层叠顺序：

IE6下有一个著名的bug，就是select控件默认总是zindex高于其他所有的层，overlay的shim属性正是考虑了这个问题存在的。这个选项默认在IE6下是打开的，会通过创建iframe的方式来规避这个bug。

使用overlay也好，其他的yui特性也好，感觉非常的方便和灵活，可以说是一个真真正正为开发者考虑的js框架，而我们也应该学习YUI3的这种设计思想和风格，让自己的应用也变得更加灵活和方便。

总体来看，目前YUI3的Overlay基本能够满足我们日常创建一些叠加层的需要，但是还有一些更高级的属性或者控制功能期待在后续的版本中加入进来。

参考资料：

1、YAHOO YUI3 Overlay

默认安装的LAMP环境中，时区默认设置在GMT时间，所以一般得到的时间都会比我们电脑中显示的时间早八个小时（假设你的时间设置正确，并且时区是在东八区）。PHP提供了两个函数用来处理时区的操作:

date_default_timezone_set() 和 date_default_timezone_get()

如果我们希望更改服务器默认的时区，修改 php.ini 文件中的 ;date.timezone = ，添加自己需要的时区，例如 date.timezone = Asia/Chongqing，然后重启服务器就可以了。PHP支持的 timezone 的字符串在参考资料[1]中可以看到。

用下面这一段代码，可以比较清楚的看到时区变化的影响：

$now = time();
echo "The GMT now is : " . date(’Y-m-d H:i:s’, now()) . ‘<br />’ ;
echo "The local time is : " . date(’Y-m-d H:i:s’, gmt_to_local($now) ) . ‘<br />’;
date_default_timezone_set(’Asia/Chongqing’);
echo ‘Set the timezone to :’ . date_default_timezone_get() . "<br />";
echo "The GMT now is : " . date(’Y-m-d H:i:s’, now()) . ‘<br />’ ;
echo "The local time is : " . date(’Y-m-d H:i:s’, gmt_to_local($now) ) . ‘<br />’;

如果我们的站点是面向单一时区的用户，我想采用这个时区的时间来记载没什么问题，或者网站应用的类型并不 Care 时间的差别，那么我们用什么时间做存储都没关系。一旦我们的用户对于时区的影响有较大关系的时候，我想应该统一使用GMT的标准时间来进行存储，在显示的时候再根据用户所在的时区进行显示，这样虽然前端显示每次都需要去计算用户当前的时间，但是对于后台逻辑的统一性应该是大有裨益的。

目前，我们国家已经废除了夏令时的使用，但是世界上仍有其他一些国家在使用夏令时，我们在程序处理的时候应该注意这个问题，具体的资料可以参考 Daylight Saving。

参考资料：
1、List of Supported Timezones
2、Daylight Saving

采用典型的LAMP架构开发的时候，环境中多处涉及到编码的指定，有一个地方忽略，都有可能造成页面汉字乱码的产生，本文将总结这些乱码产生的可能的原因，方便我们排查。

1、页面中的问题。

每个网页文件都有其编码，同时网页文件的源码中，也有一个位置会告诉浏览器，这个页面应该用什么样的编码去解释。

<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8” />

这里指定的编码应该和页面本身的编码一致，否则就会产生乱码。

还有一个需要注意的问题：当在ie浏览器下面浏览网页面的时候使用 utf-8 编码，<title>标签被放在<meta>标签前面。当title为中文的时(比如Blog名为中文或者文章标题为中文)，在 IE下会出现显示空白页的问题。而使用gbk或者gb2312等编码就不会有什么问题了。

这个问题是由于 utf-8 使用3个字节表示一个汉字，而GB2312或BIG5使用两个字节。页面输出时，由于上述原因，使浏览器解析、输出<title> </title>的内容时，如果在</title>前有奇数个全角字符时，IE把 UTF-8 当作两个字节解析时出现半个汉字的情况，这时该半个汉字会和</title>的<结合成一个乱码字，导致IE无法读完< title>部分，致使整个页面为空百输出。此时查看源文件，会发现实际上整个页面全部已经下载了。

浏览器获得编码的方式：

HTTP Header中的"Content-Type”项；
返回的html代码开头是否有BOM（Byte of Marker）；
html代码中的 meta 标签；

浏览器解码解析网页的过程：

浏览器(无论是IE还是Firefox)在解析页面时，首先取HTTP Header中的Content-Type项，如果有写明charset的话就认定页面的编码方式为charset指定的值。如果没有指明，则认定为默认值。根据上表，IE中文版的默认值是GB2312，Firefox中文版的默认值是GBK，不过IE的GB2312好像和GBK没啥区别。然后，浏览器会看一下有没有BOM。一旦发现有UTF-8的3字节BOM，则重新认定页面的编码方式为UTF-8。

解码阶段，解码完成后是解析html的阶段。解析html的过程中，当解析到head部分的meta标签时，浏览器会根据<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />这个语句中的说明，重新认定编码方式为charset后面的方式，中断html解析过程，返回到解码步骤重新解码。

meta标签的作用：

“meta是用来在HTML文档中模拟HTTP协议的响应头报文。”在meta标签中写和在HTTP头里写是一样的，这也是为了解决用普通 HTML写网页的人无法自行定义HTTP头的问题。但是，meta是一个html标签，所以必须进入到html解析的步骤才能生效，而生效后，浏览器会退回几步，重新设置好HTTP头从头再开始解码、解析html。所以meta中写的内容会覆盖HTTP头里的内容，无论哪个浏览器都是这样的。

2、Apache的DefaultCharset配置。

Apache2的配置中有这么一项 AddDefaultCharset ，默认这项设置在配置文件中并没有指定的。

AddDefaultCharset 指令
说明     当应答内容是text/plain或text/html时，在HTTP应答头中加入的默认字符集
语法     AddDefaultCharset On|Off|charset
默认值     AddDefaultCharset Off
作用域     server config, virtual host, directory, .htaccess
覆盖项     FileInfo
状态     核心(C)
模块     core

当且仅当应答内容是text/plain或text/html时，此指令将会在HTTP应答头中加入的默认字符集。理论上这将覆盖在文档体中通过<meta>标 签指定的字符集，但是实际的行为通常取决于用户浏览器的设置。AddDefaultCharset Off 将会禁用此功能。 AddDefaultCharset On 将启用Apache内部的默认字符集iso-8859-1 。您也可以指定使用在IANA注册过的字符集名字 中的另外一个charset 。比如说： AddDefaultCharset utf-8

也就是说，当Apache不指定defaultcharset的时候，页面编码由页面自己的meta标签指定。 当Apache指定的时候，将忽略页面中的meta标签指定的编码. 但是容许脚本直接header编码方式给客户端。

这样，我们就清楚了，服务器配置一般不选择这一项，就给我们页面编写带来了很多灵活性。同一个服务器中，可以存在不同编码的网页。当然，这并不是一个很好的习惯。

参考资料：

1、IE中打开UTF-8编码的页面中title显示空白的问题
2、解决一个乱码问题