• basename.properties
• basename_en.properties
• basename_zh_TW.properties

• messages_zh_TW.txt

onlyfun.caterpillar.welcome=哈囉
onlyfun.caterpillar.name=世界 

• messages_zh_TW.properties

onlyfun.caterpillar.welcome=\u54c8\u56c9
onlyfun.caterpillar.name=\u4e16\u754c 

• messages.properties

onlyfun.caterpillar.welcome=Hello
onlyfun.caterpillar.name=World 

• ResourceBundleDemo.java

package onlyfun.caterpillar;
 
import java.util.ResourceBundle;

public class ResourceBundleDemo {
    public static void main(String[] args) {
        ResourceBundle resource = 
                  ResourceBundle.getBundle("messages");
        
        System.out.print(resource.getString(
                      "onlyfun.caterpillar.welcome") + "!");
        System.out.println(resource.getString(
                      "onlyfun.caterpillar.name") + "!");
    }
} 

plist文件是标准的xml文件，在cocoa中可以很简单地使用。这里介绍一下使用方法：

以下代码在Mac和iPhone中均适用。

写入plist文件：

读取plist文件：

本文系翻译文章，但并未严格按照原文翻译。

1. 第一个OSGi模块
本文期望展示OSGi开发环境的简洁性，因此这里没有使用eclipse开发环境。本文只使用文本编辑器和基本的命令行工具进行OSGi程序开发。
本文的第一个例子相对其他示例有些长，这是因为我们需要建立一个基本的工作环境。在开始之前，我们需要一个可以运行的OSGi框架。现在我们可以在三种开源框架中进行选择：Apache Felix，Knopflerfish和Equinox。本文所有编写的代码对以上三个框架来说都是可用的，只是在使得这些代码运行的指令上有所区别。本文选择eclipse使用的Equinox。首先需要找到eclipse安装目录下的org.eclipse.osgi_3.2.1.R32x_v20060919.jar并复制此文件到一个空目录（文件中的版本号会根据安装eclipse的不同而不同）。为了使命令行参数短一些，把刚才复制过来的jar文件更名为equinox.jar。现在就可以在命令行中定位到刚才那个空目录并执行这个命令：
> java -jar equinox.jar -console
几秒钟后，命令窗口中会出现osgi>提示。如果是这样，就说明OSGi已经运行起来了（意外总会发生，比如你没有安装java！）。
osgi>命令行提示允许我们运行Equinox中的命令来进行整个框架的控制。可以在提示符后输入help获得所有命令的列表。经常使用的一个命令是ss。ss表示简要状态（short status）的意思。ss会列出当前已经安装到框架中所有模块（bundle）和它们状态的列表。在OSGi中bundle表示一个模块，这与eclipse中的插件（plug-ins）具有等同的概念。
输入ss后，Equinox输出为：
Framework is launched.
id State Bundle
0 ACTIVE system.bundle_3.2.1.R32x_v20060919
以上输出告诉我们当前只安装了一个已经启动的模块：系统模块（System bundle）。此模块是OSGi的一个总是安装并处于活动状态的特殊模块，它代表了框架本身。
现在我们开始编写一个模块。在相同的目录下，创建一个名称为HelloActivator.java的文件并复制以下代码到文件中：
import org.osgi.framework.*;
public class HelloActivator implements BundleActivator {
public void start(BundleContext context) { System.out.println("Hello Eclipse!"); }
public void stop(BundleContext context) { System.out.println("Goodbye Eclipse!"); }
}
一个模块还需要一个元文件（manifest file）对它的各种元信息进行声明：如模块的名称，版本等信息。所以现在还需要创建一个名称为HelloWorld.mf的文件并复制下文的文本到此文件中。特别需要注意的是要在此文本文件的最后保留一个空白行，否则打包命令jar在打包时会截短文件（最后一行丢失）。这样就会使得生产的jar包中的元文件缺失一行，导致jar文件读取和运行失败。
Manifest-Version: 1.0
Bundle-Name: HelloWorld
Bundle-Activator: HelloActivator
Bundle-SymbolicName: HelloWorld
Bundle-Version: 1.0.0
Import-Package: org.osgi.framework
现在另外打开一个命令行窗口使用如下命令构建一个jar文件：
> javac -classpath equinox.jar HelloActivator.java
> jar -cfm HelloWorld.jar HelloWorld.mf HelloActivator.class
回到原先的OSGi控制台，输入install file:HelloWorld.jar。控制台会输出"Bundle id is 1" ，接着输入ss命令就可以得到如下输出信息：
Framework is launched.
id State Bundle
0 ACTIVE system.bundle_3.2.1.R32x_v20060919
1 INSTALLED HelloWorld_1.0.0
刚才开发的HelloWorld模块安装到了OSGi框架中，但此模块还没有运行起来。现在输入命令start 1。命令中的1是安装HelloWorld模块完成后，OSGi赋值给此模块的ID号。当运行启动命令后，控制台显示消息"Hello Eclipse!"。接着输入stop 1就会得到消息"Goodbye Eclipse!"。
这些命令都做了些什么事情？上面的代码实现了一个BundleActivator接口，这个接口用于允许框架通知我们一些重要的生命期事件。当模块启动时，框架调用start方法，而如果模块停止时，框架则调用stop方法。还有一个要说明的是元文件中有一行声明"Bundle-Activator: HelloActivator"就是用于通知框架在一个模块中那个类是启动类（activator）。通常我们使用一个完整的类名称，但在此示例中为了简单而只使用的缺省包名。
术语表：
Bundle： 模块
Activator：启动器
Component：组件
Service：服务
Sevice Register：服务注册表
Declarative Service: 服务声明，简称DS
OSGi Framework： OSGi框架或者框架
manifest file： 元文件

=========================================================================================
OSGi开发起步(Getting Started with OSGi)-2与OSGi框架进行交互
原文出自： http://neilbartlett.name/blog/osgi-articles/ - Getting Started with OSGi

本文系翻译文章，但并未严格按照原文翻译。

2. 与OSGi框架进行交互

上一节举了一个简单的示例模块HelloWorld：启动和停止时输出消息的模块。该模块通过实现BundleActivator接口定义的start和stop函数方法完成了这些消息的输出。如果回过头来仔细的研究start和stop方法的定义，我们可以发现函数定义了一个BundleContext类型的参数。在本节描述参数BundleContext以及它的用法。
BundleContext是OSGi框架提供给一个模块的'通行票据'。当模块需要与框架进行交互和通信时，就可以使用BundleContext。实际上，这也是一个模块可以唯一与OSGi框架进行交互的渠道。OSGi框架在每个模块启动时会通过此模块的BundleActivator派送一个票据：BundleContext。
如果上一节的OSGi控制台还在运行状态，下面的工作就不需要重启控制台。如果控制台关闭了就需要使用下面的命令启动它。
> java -jar equinox.jar -console
输入ss后就会发现上次安装过的HelloWorld模块。即便是OSGi框架关闭重启了之后，HelloWorld模块也会保持上节的状态。这主要是因为OSGi框架进行了模块的持久化存储处理。
在这一节我们完成一个查找并卸载HelloWorld模块的模块。在OSGi控制台可以使用uninstall命令简单的完成这项任务。但是这一节希望通过OSGiAPI编码的方式实现此任务。
创建一个名称为HelloWorldKiller.java的文件，输入下面的代码：
import org.osgi.framework.*;
public class HelloWorldKiller implements BundleActivator {
public void start(BundleContext context) {
System.out.println("HelloWorldKiller searching...");
Bundle[] bundles = context.getBundles();
for(int i=0; i<bundles.length; i++) {
if("HelloWorld".equals(bundles[i]
.getSymbolicName())) {
try { System.out.println("Hello World found, " + "destroying!"); bundles[i].uninstall(); return; } catch (BundleException e) { System.err.println("Failed: " + e.getMessage()); }
}
}
System.out.println("Hello World bundle not found");
}
public void stop(BundleContext context) { System.out.println("HelloWorldKiller shutting down"); }
}
接着创建此模块的元文件，注意文件最后要留一个空白行。在元文件中输入以下内容：
Manifest-Version: 1.0
Bundle-Name: HelloWorldKiller
Bundle-Activator: HelloWorldKiller
Bundle-SymbolicName: HelloWorldKiller
Bundle-Version: 1.0.0
Import-Package: org.osgi.framework
编译和构建模块对应的jar文件：
> javac -classpath equinox.jar HelloWorldKiller.java
>jar -cfm HelloWorldKiller.jar HelloWorldKiller.mf HelloWorldKiller.class
在控制台安装构建完成的新模块：install file:HelloWorldKiller.jar。然后输入ss。模块的状态类似以下列表：
id State Bundle
0 ACTIVE system.bundle_3.2.1.R32x_v20060919
1 ACTIVE HelloWorld_1.0.0
2 INSTALLED HelloWorldKiller_1.0.0
接着启动我们的新模块HelloWorldKiller：start 2。其输出信息为：
HelloWorldKiller searching...
Hello World found, destroying!
Goodbye Eclipse!
注意最后一行是先前那个HelloWorld模块的输出信息。当这个模块处于运行状态并且启动HelloWorldKiller时，HelloWorld模块被停止并进行了卸载。这种操作触发了HelloWorld模块启动器的stop方法。
输入命令ss就会发现HelloWorld模块消失了。
id State Bundle
0 ACTIVE system.bundle_3.2.1.R32x_v20060919
2 ACTIVE HelloWorldKiller_1.0.0
这里的问题是：安全性如何保证？好像任何模块都可以卸载其他模块。实际上OSGi定义了一个复杂的安全层次机制。这个安全机制提供了对模块与框架交互的精确控制。这样就可以把卸载模块的权限限制在某些特定的管理模块。重要的是OSGi进行安全控制基本上是一个配置过程，所以在这个讲解系列里我们关注点主要放在编码上。
在开始下节讲解之前，我们可以了解一下BundleContext接口，看看此接口提供了哪些方法可供使用。比如，我们可以使用installBundle方法安装一个模块到OSGi中。或者也可以获取当前所有安装的模块列表并打印这些模块最近一次修改的日期和时间。具体的方法可以参考OSGi R4的API javadoc .
术语表：
Bundle： 模块
Activator：启动器
Component：组件
Service：服务
Sevice Register：服务注册表
Declarative Service: 服务声明，简称DS
OSGi Framework： OSGi框架或者框架
manifest file： 元文件

=========================================================================
OSGi开发起步(Getting Started with OSGi)-3 模块间依赖
3. 模块间依赖
上两节展示了模块的启动和停止以及模块与系统框架的交互方式。但是问题是模块真正的用途是什么呢？
模块是功能集合。模块使我们能够把庞大纷杂的项目划分成可管理的单元。这些单元可以方便的载入到OSGi运行环境。问题是，不管我们喜欢还是不喜欢，模块几乎总是依赖于其他模块。对jar文件来说，从来没有一个可靠的方式来指定不同jar之间的依赖关系（注意，jar元文件中的类路径也不是一个可靠的方法）。因此你永远不能真正的确定： Jar中的代码会正常工作？还是会在运行时失控抛出一个ClassNotFoundException异常？
OSGi以简洁的方式解决了这个问题。仅仅这样说还不如通过功能展示来的更有说服力些。所以让我们马上开始编码来做到这点。
不幸的是直至现在，我们一直使用默认包的方式进行类的开发。这种方式不适应更复杂问题的编码，所以现在需要使用java包的形式进行编码开发和功能划分。首先以一个非常简单的JavaBean类开始，复制以下代码到文件osgitut /movies/ Movie.java ：
package osgitut.movies;
public class Movie {
private final String title;
private final String director;
public Movie(String title, String director) { this.title = title; this.director = director; }
public String getTitle() { return title; }
public String getDirector() { return director; }
}
现在接着在此包内创建一个接口。复制以下代码到文件osgitut /movies/ MovieFinder.java ：
package osgitut.movies;
public interface MovieFinder { Movie[] findAll(); }
然后把这两个类封装为一个模块。当然，这个模块十分简单而且用途也不大。但是对于本节探讨的内容已经足够了。同前面一样，模块还必要有一个对应的元文件MoviesInterface.mf：
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Movies Interface
Bundle-SymbolicName: MoviesInterface
Bundle-Version: 1.0.0
Export-Package: osgitut.movies;version="1.0.0"
文件中多了一行：Export-Package。这个属性表明包osgitut.movies从这个模块中导出。而问题是java的jar文件中所有的东西都是导出的。但是我们难道不想只导出包中的部分代码而保持其他部分只在包内部可见吗?我们当然可以使用private或者protected限制类的访问范围，而这样一来同一个jar中其他包也不能访问这些类了。所以OSGi有效地引进了一种新的代码保护级别：如果模块中的包名没有在Export-Package头中列出，那么此包就只能在这个模块中才能访问到。
此外，我们还在导出包名称后挂接了软件版本号。在下一个阶段的讲解中我们会发现这十分重要。当然，这也不是绝对有必要提供一个版本。但如果你不指定版本号时，OSGi将自动为导出的包指定版本" 0.0.0 "。始终为导出的包指定明确的版本是一个优秀的实践经验。
现在构建此模块：
> javac osgitut/movies/Movie.java osgitut/movies/MovieFinder.java
> jar -cfm MoviesInterface.jar MoviesInterface.mf osgitut/movies/*.class
完成此项工作后我们不要急于安装此模块。在这之前我们还需要构建此模块的一个依赖模块。即一个实现了MovieFinder接口的具体实现类：osgitut/movies/impl/BasicMovieFinderImpl.java :
package osgitut.movies.impl;
import osgitut.movies.*;
public class BasicMovieFinderImpl implements MovieFinder {
private static final Movie[] MOVIES = new Movie[] { new Movie("The Godfather", "Francis Ford Coppola"), new Movie("Spirited Away", "Hayao Miyazaki") };
public Movie[] findAll() { return MOVIES; }
}
还需要一个元文件：BasicMovieFinder.mf。
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Basic Movie Finder
Bundle-SymbolicName: BasicMovieFinder
Bundle-Version: 1.0.0
Import-Package: osgitut.movies;version="[1.0.0,2.0.0)"
注意，在这里我们导入了一个由其他模块导出的包osgitut.movies。而且还同时为此导入包设置了版本范围。框架在运行时刻使用此版本范围匹配一个适合的导出包。OSGi表达版本范围使用的是通用的数学式语法：方括号表示包含，圆括号表示排除。在上面这个示例元文件中我们使用这个语法有效的指定了一个1.x的版本。
对本节示例来说，在导入部分加入版本限制并不是必需的。但这是一个通用的实践准则。
现在按照以下命令构建第二个模块：
> javac -classpath MoviesInterface.jar osgitut/movies/impl/BasicMovieFinderImpl.java
> jar -cfm BasicMovieFinder.jar BasicMovieFinder.mf osgitut/movies/impl/*.class
最后我们可以准备在OSGi环境中试验这两个模块。第一步就是安装BasicMovieFinder模块并运行ss命令。这时此模块的状态显示为INSTALLED。
id State Bundle
0 ACTIVE org.eclipse.osgi_3.3.0.v20070208
4 INSTALLED BasicMovieFinder_1.0.0
（说明，你的模块列表可能与上面这个示例列表存在一定的差异。实际上，模块id号会根据你上次安装和卸载HelloWorld模块的次数而确定。因此下面示例中的id号要根据你运行环境中相应的id进行替换。）
INSTALLED表示框架载入了这个模块，但还没有完成此模块依赖关系的解析。一个让框架执行模块依赖解析的命令是refresh。这里输入refresh 4然后是ss命令就可以看到：
id State Bundle
0 ACTIVE org.eclipse.osgi_3.3.0.v20070208
4 INSTALLED BasicMovieFinder_1.0.0
这个模块没有解析成功并仍然处于INSTALLED状态。这个问题出在我们并没有安装其依赖的那个包含Movie类和MovieFinder接口的模块。如果想确认是不是这个问题，在框架控制台输入diag 4以获取此模块的调试信息：
file:BasicMovieFinder.jar [4]
Missing imported package osgitut.movies_[1.0.0,2.0.0).
看来确实是因为框架运行环境没有任何可供导出的osgitut.movies包。那么现在就安装MoviesInterface.jar模块并运行ss。大致的输出结果为：
id State Bundle
0 ACTIVE org.eclipse.osgi_3.3.0.v20070208
4 INSTALLED BasicMovieFinder_1.0.0
5 INSTALLED MoviesInterface_1.0.0
最后一步就是通知框架重新执行BasicMovieFinder模块的依赖解析。依旧使用refresh 4命令。输出的结果为：
id State Bundle
0 ACTIVE org.eclipse.osgi_3.3.0.v20070208
4 RESOLVED BasicMovieFinder_1.0.0
5 RESOLVED MoviesInterface_1.0.0
BasicMovieFinder模块现在处于已解析状态。这是一个基本步骤。因为只有处于已解析的模块才能启动。
需要注意的是通常情况下并不需要使用本节展示的手工方式进行模块依赖解析。一般来说模块会在它们需要的时候自动进行解析。例如，我们可以注意到MoviesInterface模块也处理已解析状态，而我们并没有针对此模块显示的执行refresh命令。
下一节我们进行OSGi服务开发。

=======================================================================================
OSGi开发起步(Getting Started with OSGi)-4注册一个服务
4 注册一个服务
我们终于可以开始OSGi服务的讲解了。在我看来，服务层是OSGi中最具特点的部分。在接下来的几节你就会充分体会到这一点。
上节讲解的是MovieFinder接口的例子。这个接口被MovieLister用来查找电影。这个例子是一个Ioc（控制反转）的例子。
MovieLister并不太关心原始电影数据的来源，所以我们使用了MovieFinder接口隐藏了这些细节。关键在于我们可以使用另外一种实现替代现有的MovieFinder：比如从数据库或者亚马逊web服务进行电影查询。而MovieLister只依赖与接口而不是具体的实现。
虽然不错，但是有些时候我们实际上还是要把一个MovieFinder的具体实现明确指定给MovieLister。我们是用一个外部容器把这个具体实现"推"给了MovieLister，而不是让MovieLister自己调用一个查找方法发现这个具体实现对象。
这就是IoC术语的由来。现在存在大量的这类外部容器，如PicoContainer,HiveMind,Spring以及EJB3.0。但是直至现在这些容器都有一个基本限制：它们都是静态的。一旦一个MovieFinder指定给了MovieLister，两者在整个JVM虚拟机生命周期内都一直关联。
OSGi支持具有动态特性的IoC模式。OSGi支持动态的提供给MovieLister一个MovieFinder的实现然后移除它们。这样我们就能在一个支持文本电影数据查询的应用程序和一个依赖亚马逊web服务电影数据查询的应用程序之间进行热切换。
OSGi服务层用于支持以上特性。我们要做的只是在服务注册表中注册MovieFinder为其中的一个服务就能支持热切换特性。这可是相当简单啊。同样的MovieLister的功能也可以由一个MovieLister服务提供。一个服务与一个普通的java对象（POJO）没有什么不同，它只是使用java接口名进行了服务注册而已。
在本节我们就看看如何在注册表中注册服务。接下来就试试怎样编码从注册表获取服务并提供给一个MovieLister。
在上节代码基础上增加一个BasicMovieFinder。不需要更改任何现有的类，只是在增加一个启动器类。下面就是这个启动类osgitut/movies/impl/BasicMovieFinderActivator.java:
package osgitut.movies.impl;
import org.osgi.framework.*;
import osgitut.movies.*;
import java.util.Properties;
import java.util.Dictionary;
public class BasicMovieFinderActivator implements BundleActivator {
private ServiceRegistration registration;
public void start(BundleContext context) { MovieFinder finder = new BasicMovieFinderImpl(); Dictionary props = new Properties(); props.put("category", "misc"); registration = context.registerService( MovieFinder.class.getName(), finder, props); }
public void stop(BundleContext context) { registration.unregister(); }
}
接下来就是修改BasicMovieFinder.mf文件：
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Basic Movie Finder
Bundle-SymbolicName: BasicMovieFinder
Bundle-Version: 1.0.0
Bundle-Activator: osgitut.movies.impl.BasicMovieFinderActivator
Import-Package: org.osgi.framework,
osgitut.movies;version="[1.0.0,2.0.0)"
在这个元文件中相对上节变化了两行。第一个增加了Bundle-Activator行。此行描述当前模块使用的启动模块（以前我们并没有使用）。此外还在导入包行中增加了org.osgi.framework。本节以前版本的模块并没有与框架进行交互，因此也就不需要导入OSGiAPI相关的包。
现在重新构建BasicMovieFinder.jar。
> javac -classpath equinox.jar:MoviesInterface.jar osgitut/movies/impl/*.java
> jar cfm BasicMovieFinder.jar BasicMovieFinder.mf osgitut/movies/impl/*.class
回到OSGi控制台，上节安装的BasicMovieFinder.jar还在框架中运行。因此要更新这个模块，运行update N命令，N是这个模块的ID（使用ss可以得到此ID）。接着使用start N命令启动此模块。接着我们看到什么-基本上也没看到些什么。
实际上，模块已经在OSGi服务注册表中注册了，但是并没有其他人在另外一端要使用此服务。因此这个服务的注册过程并没有产生任何可视效果。如果我们想向自己保证我们的代码确实运行了，也大可不必掘地三尺。执行下面这个命令就可以了：
services (objectClass=*MovieFinder)
我们会看到下面的输出：
{osgitut.movies.MovieFinder}={category=misc, service.id=22}
Registered by bundle: file:BasicMovieFinder.jar [4]
No bundles using service.
看到了，服务的确注册了。在下节我们就讲解如何查找这个服务并在另外模块中使用此服务。

=============================================================================
OSGi开发起步(Getting Started with OSGi)-5使用一个服务
5. 使用一个服务：Consuming a Service
上节讲解了如何注册一个服务。现在就是在一个模块中查找和使用这些服务的时候了。
与上节一样，我们还是使用电影搜索的例子。我们已经构建了一个MovieFinder服务并在服务注册表中进行了服务注册。现状我们需要构建一个MovieLister来使用这个MovieFinder服务搜索某个导演执导的影片。这里假设MovieLister也是一个服务，也可以被其他诸如GUI程序使用。问题是，OSGi服务是动态的：它们可能有效也可能处理不可使用状态。这也就是说有时存在需要使用MovieFinder服务而它却正好不能使用的情况。
那么当MovieFinder不可用的时候MovieLister怎么办？显然，调用MovieFinder是MovieLister能有效运作的核心部分。实际上我们也只有以下几种选择：

• 产生错误。如返回null或者抛出一个异常。
• 等待。
• 不让这种情况出现。
  在本文我们选择比较简单的前两种选择。The third option may not even make any sense to you yet, but hopefully it will after we look at some of the implications of the first two.
  首先我们需要定义MovieLister服务的接口。复制以下内容到文件osgitut/movies/MovieLister.java：
  package osgitut.movies;
  import java.util.List;
  public interface MovieLister { List listByDirector(String name); }
  然后是文件osgitut/movies/impl/MovieListerImpl.java :
  package osgitut.movies.impl;
  import java.util.*;
  import osgitut.movies.*;
  import org.osgi.framework.*;
  import org.osgi.util.tracker.ServiceTracker;
  public class MovieListerImpl implements MovieLister {
  private final ServiceTracker finderTrack;
  public MovieListerImpl(ServiceTracker finderTrack) { this.finderTrack = finderTrack; }
  public List listByDirector(String name)
  Unknown macro: { MovieFinder finder = (MovieFinder) finderTrack.getService(); if(finder == null) { return null; } else { return doSearch(name, finder); } }
  
  private List doSearch(String name, MovieFinder finder) {
  Movie[] movies = finder.findAll();
  List result = new LinkedList();
  for (int i = 0; i < movies.length; i++)
  Unknown macro: { if(movies[i].getDirector().indexOf(name) > -1) { result.add(movies[i]); } }
  
  return result;
  }
  }
  上面的代码可能是至今我们最长的一段示例代码了。这里面有些什么呢？第一，实际的影片搜索逻辑分离到了doSearch(string, MovieFinder)方法中。此方法帮助我们隔离了搜索代码与OSGi代码。虽然，这里制定的搜索办法并不是很高效，但对于一个以示例为目的的程序已经足够了：实际上只是实现了一个只有两部影片的数据库。
  第二部分是listByDirector(String name)方法。这个方法使用了一个ServiceTracker对象从服务注册表获取一个MovieFinder。ServiceTracker是一个十分有用的类。它封装和抽象了一些难于使用的OSGi底层API。无论如何我们还是要检查需要的服务是否实际可用。此服务假定在MovieLister构造函数中把ServiceTracker传递过啦。
  注意，你可能在其他部分看到一些没有使用ServiceTracker从服务注册表查询服务的代码。例如，使用BundleContext的getServiceReference和GetSevice方法。但这样一来就需要编写一些更复杂的代码并需要仔细进行一些清理工作。在我看来，使用底层API并不能得到太多的好处，反倒是会引起许多问题。最好的选择还是使用ServiceTracker。
  在一个模块的启动器中是创建ServiceTracker的最佳地点。复制以下代码到文件osgitut/movies/impl/MovieListerActivator.java：
  package osgitut.movies.impl;
  import java.util.*;
  import org.osgi.framework.*;
  import org.osgi.util.tracker.ServiceTracker;
  import osgitut.movies.*;
  public class MovieListerActivator implements BundleActivator {
  private ServiceTracker finderTracker;
  private ServiceRegistration listerReg;
  public void start(BundleContext context) throws Exception { // Create and open the MovieFinder ServiceTracker finderTracker = new ServiceTracker(context, MovieFinder.class.getName(), null); finderTracker.open(); // Create the MovieLister and register as a service MovieLister lister = new MovieListerImpl(finderTracker); listerReg = context.registerService(MovieLister.class.getName(), lister, null); // Execute the sample search doSampleSearch(lister); }
  public void stop(BundleContext context) throws Exception { // Unregister the MovieLister service listerReg.unregister(); // Close the MovieFinder ServiceTracker finderTracker.close(); }
  private void doSampleSearch(MovieLister lister) {
  List movies = lister.listByDirector("Miyazaki");
  if(movies == null) { System.err.println("Could not retrieve movie list"); } else
  Unknown macro: { for (Iterator it = movies.iterator(); it.hasNext();) { Movie movie = (Movie) it.next(); System.out.println("Title: " + movie.getTitle()); } }
  
  }
  }
  现在这个启动器可以启动服务查找感兴趣的影片了。首先，在start方法中创建了一个ServiceTracker对象。这个对象由之前写的MovieLister使用。接着就打开ServiceTracker并设置此对象跟踪注册表中的MovieFinder服务实例。然后创建MovieListerImpl对象并使用MovieLister为名称在注册表中注册一个服务。最后，为了证明服务确实运行，在启动模块时启动器使用MovieLister执行了一个简单的搜索并输出了搜索结果。
  到此，我们可以使用前几节的方法构建和安装我们设计的这些模块。要记得创建元文件，并在元文件中正确的设置Bundle-Activator为osgitut.movies.impl.MovieListerActivator。还有就是在导入包中包含以下三个包：org.osgi.framework , org.osgi.util.tracker and osgitut.movies。
  一旦把MovieLister.jar安装到了OSGi框架运行环境，就可以启动这个模块。根据BasicMovieFinder模块是否处于运行状态，此时OSGi控制台会输出不同的消息。
  如果没有运行，会输出：
  osgi> start 2
  Could not retrieve movie list
  如果处于运行状态则会输出：
  osgi> start 2
  Title: Spirited Away
  在停止和启动模块的时候，以上消息都会在控制台出现。还记得我们可以在服务处于不可用状态是选择等待吗？使用上面的代码，只需要做简单的修改：在MovieListerImpl的第16行中使用ServiceTracker的waitForService(5000)代替getService()，同时增加一个处理InterruptedException的try/catch块。
  这会导致listByDirector()方法阻塞5000毫秒等待MovieFinder服务可用。如果这时刚好MovieFinder服务安装并且可以使用，这个方法就可以立即获取到这个服务。
  通常并不建议以这样的方式挂起一个线程。在实践中，这样做是相对危险的。因为listByDirector方法实际是由模块启动器中的start方法调用的。而模块启动器start方法又是由一个框架线程调用。启动器必须快速返回，因为当前一个模块启动是还需要执行许多其他的工作。实际上在最糟糕的情况下这种等待的做法可能导致一个死锁。因为我们进入了一个框架对象的同步区，而这个同步区可能已经被其他现场锁定。通常的建议是不要在模块启动器的start方法或者其他任何框架直接调用的代码中执行任何长时间或者阻断性的操作。

=================================================================
OSGi开发起步(Getting Started with OSGi)-6(1)动态服务跟踪
6 动态服务跟踪：Dynamic Service Tracking
上节讲解了如何使用一个服务：MovieLister使用MovieFinder查找由某个导演指导的影片。同时还涉及了处理OSGi服务动态特性的各种策略，特别介绍了MovieLister找不到一个有效的MovieFinder服务时的处理办法。
还有一种上节没有涉及的情况是：如何处理同时有多个MovieFinder服务可用的情况？因为任何模块都可以使用MovieFinder接口注册一个服务，并且对于服务注册机制来说任何模块都是同等对待的。
我们可以简单的忽略这个问题，这也是上节代码的实际处理逻辑。通过调用ServiceTracker上的getService()方法，我们选择由服务注册表任意提供一个MovieFinder服务。有一些参数可以调整注册表的选择策略（比如在服务注册时设置的SERVICE_RANKKING属性），但是作为一个服务的使用者我们并没有参与这个服务选择过程。并且实际上尽量少的控制并不是一件坏事，因为我们应该可以使用任何一个MovieFinder服务。这也是使用接口的原因。
从另外一方面来说，在一些情况下注册和使用多个服务也大有用途，例如，如果有多个有效的MovieFinder服务，这就意味这存在多个影片数据来源可供MovieLister使用。如果可以通过使用所有的这些服务进行影片查找，我们就可以获得更大的搜索网络空间并提供给用户更好的搜索结果。
另一个问题是上节遗留下来的：在没有任何一个MovieFinder服务可用时，MovieLister应该如何正确处理？上节的处理逻辑是在服务无效时简单的在listByDirector调用时返回null。But what if we made it impossible for methods on MovieLister to be called when the MovieFinder isn't present?
MovieLister与MovieFinder一样是一个服务。如果MovieFinder服务消失了，MovieLister服务是不是也应该消失？也就是说，我们希望MovieLister与MovieFinder之间有一个一对多的依赖关系。本文的最后一节，我们介绍零对一依赖关系。
首先使用下面的代码修改MovieListerImpl类：
package osgitut.movies.impl;
import java.util.*;
import osgitut.movies.*;
public class MovieListerImpl implements MovieLister {

private Collection finders =
Collections.synchronizedCollection(new ArrayList());

protected void bindFinder(MovieFinder finder) { finders.add(finder); System.out.println("MovieLister: added a finder"); }

protected void unbindFinder(MovieFinder finder) { finders.remove(finder); System.out.println("MovieLister: removed a finder"); }

public List listByDirector(String director) {
MovieFinder[] finderArray = (MovieFinder[])
finders.toArray(new MovieFinder[finders.size()]);
List result = new LinkedList();
for(int j=0; j<finderArray.length; j++) {
Movie[] all = finderArray[j].findAll(); 
for(int i=0; i<all.length; i++) {
if(director.equals(all[i].getDirector())) { result.add(all[i]); }
}
}
return result;
}

}
上面的代码移除了MovieListerImpl上所有的OSGi依赖。MovieListerImpl现在是一个纯POJO了。当然，它还需要其他对象协助跟踪MovieFinder服务并通过bindFinder方法提供此服务。因此我们还需要创建一个新的java文件：osgitut/movies/impl/MovieFinderTracker.java。
package osgitut.movies.impl;
import org.osgi.framework.*;
import org.osgi.util.tracker.*;
import osgitut.movies.*;
public class MovieFinderTracker extends ServiceTracker {

private final MovieListerImpl lister = new MovieListerImpl();
private int finderCount = 0;
private ServiceRegistration registration = null;

public MovieFinderTracker(BundleContext context) { super(context, MovieFinder.class.getName(), null); }

private boolean registering = false;
public Object addingService(ServiceReference reference) {
MovieFinder finder = (MovieFinder) context.getService(reference);
lister.bindFinder(finder);
synchronized(this) { finderCount ++; if (registering) return finder; registering = (finderCount == 1); if (!registering) return finder; }
ServiceRegistration reg = context.registerService(
MovieLister.class.getName(), lister, null);
synchronized(this) { registering = false; registration = reg; }
return finder;
}
public void removedService(ServiceReference reference, Object service) {
MovieFinder finder = (MovieFinder) service;
lister.unbindFinder(finder);
context.ungetService(reference);
ServiceRegistration needsUnregistration = null;
synchronized(this) {
finderCount --;
if (finderCount == 0) { needsUnregistration = registration; registration = null; }
}
if(needsUnregistration != null) { needsUnregistration.unregister(); }
}
}

==========================================================================================
OSGi开发起步(Getting Started with OSGi)-6(2)动态服务跟踪
上面这个类覆盖了上节讨论的ServiceTracker类，并且定制了服务有效和失效时ServiceTracker的行为。具体来说就是，当一个增加MovieFinder服务时调用addingSevice方法，当删除一个MovieFinder服务时调用removedService方法。此外还有一个modifiedService方法，只不过在本节处理逻辑中不需要而没有覆盖。
有必要仔细看看这两个方法中的处理逻辑。首先，在addingSevice方法中传入的参数是ServiceReference而不是一个实际服务实现对象。ServiceReference是一个轻量级的句柄对象。它可以作为一个参数任意的进行传输，并可以用来获取实际服务的属性。比如，服务在进行服务注册时传入的属性集。实际上，使用一个ServiceReference对象并不会导致OSGi框架增加实际服务的引用计数。你可以认为ServiceReference承担了类似java反射API中WeakReference类的角色。
在addingSevice方法中首先是通过ServiceReference获取一个实际的MovieFinder服务对象。这又要使用BundleContext：任何与OSGi框架的交互都是通过BundleContext接口进行的。幸运的是，ServiceTracker定义了一个我们可以直接使用的类型为BundleContext的保护成员context。
接下来我们使用bindFinder方法把获取到的MovieFinder服务绑定到MovieListerImpl。然后就把MovieListerImpl也注册为一个使用MovieLister接口的服务。注意，我们只在MovieListerImpl没有注册为服务的情况下才进行服务注册。这是因为，我们现在希望一个MovieLister使用多个MovieFinder服务。
最后，addingSevice方法返回一个Object。问题是，我们到底要返回一个什么对象呢？实际上，ServiceTracker并不关心addingSevice返回什么对象。addingSevice可以返回任何我们需要的对象。重点是，addingSevice返回的对象会在调用modifiedService或者removedService的时候重新传回。这也就是在removedService方法第一行见到的直接对object进行的MovieFinder类型转换。接着就使用此对象进行它与MovieLister的解绑，同时我们根据可以使用的MovieFinder服务是否为零进行MovieLister服务的反注册。
一般说来，任何在addingSevice中的行为都应该在removedService中进行状态清理。因此，我们应该在addingSevice中返回任何有助于我们需要在removedService中进行清理工作的对象。返回的可以是一个HashMap中的键值，也可以是一个ServiceRegistration对象，或者是一个实际的服务对象。
在removedService的最后一步，我们解绑了在addingSevice中绑定的服务。这一点十分重要，这个操作使得服务注册表减少服务使用计数值，从而可以使计数值为零进行服务释放。
现状我们还需要一个模块启动器osgitut/movies/impl/TrackingMovieListerActivator.java：
package osgitut.movies.impl;
import org.osgi.framework.*;
public class TrackingMovieListerActivator implements BundleActivator {
private MovieFinderTracker tracker;
public void start(BundleContext context) { tracker = new MovieFinderTracker(context); tracker.open(); }
public void stop(BundleContext context) { tracker.close(); }
}
不要忘记TrackingMovieLister.mf：
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Tracking Movie Lister
Bundle-SymbolicName: TrackingMovieLister
Bundle-Version: 1.0.0
Bundle-Activator: osgitut.movies.impl.TrackingMovieListerActivator
Import-Package: org.osgi.framework,
org.osgi.util.tracker,
osgitut.movies;version="[1.0.0,2.0.0)"
按照前几节的步骤进行模块的构建和部署。完成后，执行以下的步骤验证运行逻辑是否正确：

• 启动 BasicMovieFinder和TrackingMovieLister。检查是否出现"MovieLister：added a finder"消息。
• 停止 BasicMovieFinder。检查是否出现"MovieLister: removed a finder"消息。
• 执行service命令，检查是否MovieLister服务已经反注册。
  本节内容展示的是一个十分强大的技术。我们把一个服务的生命周期与另一个服务（实际上是多个）的生命周期绑定。进一步，我们可以绑定MovieLister和第三个服务并可以依此类推。这样我们就构建了一个服务依赖图，这种依赖图与其他一些静态IOC容器构建的beans图不同。OSGi的服务依赖图更健壮，self-healing并具有自动调整能力。
  另一方面，这一节的代码还存在一些问题。MovieFinderTracker和TrackingMovieListerActivator类会形成整个系统负载的瓶颈。当我们打算进行这个系统的扩展时，我们还不得不重复进行这些基本雷同的编码工作。因此在下一节我们讲解如何使用几行XML语句完成这些重复和繁琐的工作。
  在下一节不再在一个目录下使用命令行构建我们的系统。本文的目标是展示OSGi是一个简单而强大的框架，但并不妨碍我们使用更高效的方式比如eclipse的IDE完成这些工作。

==================================================================================================
OSGi开发起步(Getting Started with OSGi)-7服务声明介绍
7 服务声明介绍：Introducing Declarative Services
服务声明（简称DS）规范是OSGi最新的内容之一。增加此服务规范是为了在多个模块之间有效协调服务。这种服务协调工作本身并不复杂（如上节我们展示的那样），但是这项工作总是面临那些恼人的代码。而且具体实现时还必须注意处理各种线程问题。总的来说，模块服务协作这件工作是一件极易出错的工作。
最早试图解决服务协作问题的是一个称为Service Binder的工具。这个工具由Humberto Cervantes 和 Richard Hall开发。Service Binder设计了自动服务依赖管理特性。这个特性允许开发者专注于服务。服务之间的协作和依赖通过声明实现，而所有的声明都使用XML完成。
服务声明规范是由Service Binder发展而来，并成为了OSGi4.0标准的一部分。
前面几节的示例都是使用的命令行完成所有的编码、配置、构建和运行工作。从这节开始则使用EclipseSDK。需要明确的是，本文中介绍的任何技术和方法并不依赖于Eclipse。尽管Eclipse可以很好的帮助我们完成很多工作，但同样的我们也可以使用NetBeans，Intellij或者vi来完成这些工作。
首先我们需要下载Equinox的服务声明实现包。可以在Equinox的下载页面下载最新的org.eclipse.equniox.ds_x.x.x_xxxx.jar。下载完成后，把下载的jar复制到Eclipse的plugins目录，并重新启动Eclipse。
现在重新创建一个模块。在Eclipse中使用插件工程向导：
l 在主菜单中选择File->New->Project。
l 选择Plug-in Project并点击Next。
l 输入工程的名称：SampleExporter。
l 在最下面的"This plug-in is targeted to run with"文字下选择"OSGi framework"以及下拉框中的"standard"。这个是个基本步骤：这一步可以防止我们使用OSGi框架实现之外的特性。
l 选择"Next"。在向导显示的下一个对话框中选择"Generate an activator..."。如果选择，点击"Finish"完成创建工作。
我们现在生成了一个空的模块工程。接下来的工作就是在这个工程中增加代码。为了使得示例尽量简单，我们使用在每个java运行环境中都存在的java.lang.Runnable接口提供服务。现在我们可以使用Eclipse的复制代码特性创建包和源文件。复制下面的代码，在Eclipse中选择SampleExporter工程的src目录，并执行Edit->Paste。
package org.example.ds;
public class SampleRunnable implements Runnable {
public void run() { System.out.println("Hello from SampleRunnable"); }
}
接下来我们需要创建一个XML文件。使用这个文件声明SampleRunnable是一个服务。在工程的顶级目录下创建一个名称为OSGI-INF的目录，新建一个名称为samplerrunnable.xml的文件然后复制下面的文本到文件中。
<?xml version="1.0"?>
<component name="samplerunnable">
<implementation class="org.example.ds.SampleRunnable"/>
<service>
<provide interface="java.lang.Runnable"/>
</service>
</component>
这是一个最简单的DS声明。这个声明表示有一个名称为"samplerunnable"的组件，这个组件使用接口java.lang.Runnable向服务注册器提供一个服务。同时还说明了这个模块是由org.example.da.SampleRunnable类实现的。
最后就是要告知服务声明runtime这个XML文件的位置。通知是通过在组件的MANIFEST.MF文件中增加一项说明实现的。在Eclipse中打开元文件页面，定位到"MANIFEST.MF"文件窗格。在这个文件内容的最后增加一行：
Sevice-Component: OSGI-INF/samplerunnable.xml
然后保存文件。在进行下一步之前，我们可以运行Equinox检查一下我们的模块是否可以正常运行。在Run菜单中选择"Run..."，当运行对话框打开后选择左边树中的"Equniox OSGi Framework"并点击New按钮。如果你是一个熟练的Eclipse用户但又没有做过OSGi开发，这个对话框相对来说有些复杂（或者奇怪）。第一个标识为Bundles的窗格允许我们选择哪些Bundles是运行环境需要包含的，是否需要启动等。为了使用一个简化的运行环境，取消当前所有选中的Bundles，并重新选择以下的Bundles：
SampleExporter (underneath Workspace)
org.eclipse.equinox.ds (underneath Target Platform)
除此之外我们还有一些依赖的Bundles，这可以使用Add Required Bundles功能把这些依赖的Bundles添加进来。最好把"Validate bundles automatically prior to launching"也选中。最后，点击Run运行这个工程。一段时间后osgi>提示符就出现在Eclipse控制台。OSGi框架运行起来了，我们可以使用前几节的命令与框架进行交互。
我们开发的服务注册了没有？使用services命令检查一下。在命令的输出结果中，我们会发现类似的信息：
{java.lang.Runnable}={component.name=samplerunnable, component.id=1, service.id=22}
Registered by bundle: initial@reference:file:..../SampleExporter/ [5]
No bundles using service.
看来服务的确注册了。需要指出的是：服务是由我们的模块注册的，而不是由声明服务模块注册的，实际上，In fact DS has registered it on behalf of our bundle。还需要注意的是，服务的使用者并不需要为了使用这个服务而做什么特别的处理，它甚至不必知道我们使用了服务声明。这些服务使用者也可以使用DS或者直接使用OSGi代码来访问服务。
还有一点就是在上面的模块代码中并没有出现与OSGi标准相关的java代码。也就是说，本节我们编写的是一个POJO类。这也是DS的一个主要特点。

=================================================================================================================
OSGi开发起步(Getting Started with OSGi)-8(1)服务声明和依赖

8服务声明和依赖：Declarative Services and Dependencies
上节对DS做了初步的介绍。本节介绍如何使用DS声明的服务。上节我们使用java.lang.Runnable接口使用DS注册了一个服务，本节介绍如何创建一个依赖于这个服务的组件。
正如介绍的那样，DS规范使得开发者只需关注应用自身的逻辑，避免如前几节需要编写的那些OSGi服务"粘合"代码。使用DS，我们只要简单的编写代码就可以了。但在之间编码之前，我们还得创建一个Eclipse工程。使用上节的工程创建步骤创建一个名称为SampleImporter的工程。
复制下面的代码并粘贴到新建工程的src目录：
package org.example.ds;
import org.eclipse.osgi.framework.console.CommandInterpreter;
import org.eclipse.osgi.framework.console.CommandProvider;
public class SampleCommandProvider1 implements CommandProvider {

private Runnable runnable;

public synchronized void setRunnable(Runnable r) { runnable = r; }
public synchronized void unsetRunnable(Runnable r) { runnable = null; }
public synchronized void _run(CommandInterpreter ci) {
if(runnable != null) { runnable.run(); } else { ci.println("Error, no Runnable available"); }
}
public String getHelp() { return "\trun - execute a Runnable service"; }
}
这个类实现了CommandProvider接口。启动Equinox后在osgi>提示符可以执行一系列的命令。CommandProvider接口用于扩充这些命令。编写CommandProvider的原因是为了提供一种方便的交互式测试代码方式。在IBM developerWorks上Chirs Aniszczyk的一篇文章详细讨论了CommandProvider。
在上面的代码中我们注意到没有任何OSGi方法调用，实际上我们并不需要从org.osgi.*导入任何类。我们依赖的那个服务（在本示例中是一个java.lang.Runnable实例）是通过setRunnable方法提供的，并且通过unsetRunnable移除。我们可以认为这是某种形式的依赖注射。
另外两个方法getHelp和_run是CommandProvider接口定义的实现方法。_run方法名的下划线有些滑稽，但这也只是Equinox控制台API的一项odd特性，与OSGi的DS无关。在Equinox控制台中规定具有下划线的方法名称是一个控制台命令。因此定义一个_run方法就相当于在Equinox控制台中增加了一个run命令。另外一个需要注意的情况是，在上面这个类的实现代码中仔细的处理了runnable属性的线程安全特性。由于OSGi本质上是多线程的，因此在OSGi中线程安全是十分重要的。Frankly我们应该总是编写线程安全的代码。
和以前一样，我们还是需要一个包含DS声明的XML文件。复制下面的文本到这个插件工程的OSGI-INF/commandprovider1.xml文件中：
<?xml version="1.0"?>
<component name="commandprovider1">
<implementation class="org.example.ds.SampleCommandProvider1"/>
<service>
<provide interface="org.eclipse.osgi.framework.console.CommandProvider"/>
</service>
<reference name="RUNNABLE"
interface="java.lang.Runnable"
bind="setRunnable"
unbind="unsetRunnable"
cardinality="0..1"
policy="dynamic"/>
</component>
编写完成了XML文件后还要把下面这行加入到bundle元文件的最后：
Service-Component: OSGI-INF/commandprovider1.xml

===========================================================================================================
OSGi开发起步(Getting Started with OSGi)-8(2)服务声明和依赖

在XML文件中有两个我们已经介绍过的元素项：implementation和service。Implementation提供了组件的实现类，而service则告知DS把这个组件注册为一个服务。这个示例中的服务使用CommandProvider接口注册。这个接口使得Equinox控制台知晓这个CommandProvider的存在。
文件中还有一个以前没有介绍的reference元素项。reference用于向DS声明组件与一个服务之间的依赖关系。其中的name属性为任意字符串。名称属性用于对依赖进行命名（我们并不需要关心它的用途-实际上只是一个可读性的标识）。本示例中使用了组件依赖的接口名称来命名。bind属性指定一个实现类的方法名。当一个服务可用时，也就是一个Runnable的服务在服务注册表中注册时，DS就会调用此方法。DS使用这个方法传入这个新服务对象的引用提供给我们的组件使用。同样的，unbind属性是当一个服务不可用时，DS回调的方法。
Cardinality是一个能显示DS真正能力的属性。这个属性控制服务的依赖是可选的还是强制的、单依赖还是多依赖。这个属性可能的值为：
0..1: optional and singular, "zero or one"
1..1: mandatory and singular, "exactly one"
0..n: optional and multiple, "zero to many"
1..n: mandatory and multiple, "one to many" or "at least one"
在这个示例中我们使用的是0.1。也就是能cope那些不可用的服务。回头看以下_run方法中的代码，我们就会发现为了处理这种情况而进行的null检查代码。
现在还是来看看这个模块运行的情况。如果上节安装的SampleExporter还有效，在osgi控制台输入run命令会得到如下输出：
Hello from SampleRunnable
这证实了我们已经成功将上节编写的Runnable服务成功导入。接着运行stop命令停止SampleExporter模块。再运行run命令得到的输出是：
Error,no Runnable available
这个输出表明DS发现了Runnable服务已经停止并调用了unsetRunnable方法。
再看一下cardinality属性，如果把它的值改为1.1（改可选为强制）会怎样？更改这个属性后重新运行Equinox。在SampleExporter启动后运行run命令会得到与前面相同的结果。但是当停止SampleExporter后运行run，OSGi输出的是一个与前面不同的错误消息。实际上，Equinox控制台输出的是一个帮助消息。这个消息是对一个不可识别命令的标准错误输出消息。这也就是说我们这个命令执行服务已经被DS反注册了。当一个组件的强制依赖不能满足是，DS强制停止这个组件并反注册组件提供的任何服务。这就是Equinox不能识别run命令的原因。
如此方便的服务装配是选择DS的最佳原因。还记得使用ServiceTracker时，我们处理这种情况时不得不编写的那些代码吗？
还有一个值得关注的属性是ploicy。这个属性的值定义为static和dynamic之一。这两个状态值用于表明组件是否支持服务的动态切换。如果不支持，DS就没有必要每次在目标服务变化后停止原组件并创建一个新组件实例。停止后新建这个过程可是一个重负载性的过程，所以我们的建议最好还是尽可能的编码一个支持动态切换的组件。不过DS的这个属性缺省是静态的，因此在组件开发时还得手动的调整此属性为动态。
上面我们试了0.1和1.1，但是没有讲解多对多（0.n）的依赖。在服务注册表中不会仅仅只有一个Runnable服务注册。如果我们只是需要绑定其中的一个服务，那么我们所绑定的将是其中的任意一个服务。看来我们还需要一个runall命令用来运行服务注册表中已经注册的所有Runnable服务。
但就对上面那个组件来说，我们把cardinality属性更改为"0.n"时会出现什么情况？其实，更改后这个服务还是可以运行：只不过setRunnable不会只调用一次，DS会在每个Runnable服务注册是调用此方法一次。问题是多次调用会导致上面组件处理逻辑的混乱。因此为应对更通常的0.n的情况，就不能只是使用单个的Runnable成员，而是需要一个Runnable集合成员。下面是根据以上分析修改的类，把这个类的代码复制到工程的src目录下：
package org.example.ds;
import java.util.*;
import org.eclipse.osgi.framework.console.CommandInterpreter;
import org.eclipse.osgi.framework.console.CommandProvider;
public class SampleCommandProvider2 implements CommandProvider {
private List<Runnable> runnables =
Collections.synchronizedList(new ArrayList<Runnable>());

public void addRunnable(Runnable r) { runnables.add(r); }
public void removeRunnable(Runnable r) { runnables.remove(r); }
public void _runall(CommandInterpreter ci) {
synchronized(runnables) {
for(Runnable r : runnables) { r.run(); }
}
}
public String getHelp() { return "\trunall - Run all registered Runnables"; }
}
再创建OSGI-INF/commandprovider2.xml：
<?xml version="1.0"?>
<component name="commandprovider2">
<implementation class="org.example.ds.SampleCommandProvider2"/>
<service>
<provide interface="org.eclipse.osgi.framework.console.CommandProvider"/>
</service>
<reference name="RUNNABLE"
interface="java.lang.Runnable"
bind="addRunnable"
unbind="removeRunnable"
cardinality="0..n"
policy="dynamic"/>
</component>
最后是把这个文件按照如下方式加到元文件中：
Service-Component: OSGI-INF/commandprovider1.xml,
OSGI-INF/commandprovider2.xml
上面的XML文件中的DS声明与以前的基本一样，只是修改了bind和unbind方法的名称，以及cardinality的值（0.n）。现在就可以试着运行这个新的runall命令看看结果如何啦。欣赏完输出结果后，还可以试着更改cardinality为1.n看看有什么不一样的事情发生！
本节是这个讲解的最后一节。通过这几节的讲解我们发现OSGi并不神秘并且相当易用。接下来的事情就是不断的开发和使用它。不过，我还是强烈的建议在开始和进行过程中一定认真的学习一下OSGi R4 core和service规范。

=======================================================================================

什么叫IOC（编程术语

所谓dylib，就是bsd风格的动态库。基本可以认为等价于windows的dll和linux的so。mac基于bsd，所以也使用的是dylib。

如果你需要引用一个第三方的dylib，在xcode下编译出cocoa程序，在本机上运行是不会出问题的。但是发布出来，给其他用户用，就可能出问题。因为用户不一定有这个库。

这个问题给我造成了相当的困扰，我到现在也没找到正规的方法。但是我确实解决了这个问题，虽然方法不一定正宗。不管怎么说，写下来，如果暂时没有更好的办法，那么先这样做。如果谁有更好的办法，也请一定不吝留言或邮件给我。

我的办法是这样的:

1 otool -L yourapp.app/Contents/MacOS/yourapp

这一步的意思是对你编译出的app使用otool命令，以便获得依赖哪些dylib的信息。注意这个路径。cocoa的app在命令行下表现为目录。所有相关的东西都在里面。
结果如下所示：
yourapp.app/Contents/MacOS/yourapp:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
/usr/local/lib/lib01.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/local/lib/lib02.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/local/lib/lib03.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.12.0)

注意我标红的地方。假如lib01,lib02,lib03是本程序引用的第三方库，那么在这个程序里面，他们的引用地址是位于/usr/local/lib上的。这是开发机上的安装情况。而使用这个程序的客户机未必安装这些东西，所以程序就要出错。

显然，我们需要做2件事。a 把这些库附带在app上 b 把他们的引用地址修改到正确的位置。

2 mkdir yourapp.app/Contents/dylib

在编译出来的app中，创建dylib目录

然后把所有需要的库复制过去

cp /usr/local/lib/lib01.dylib yourapp.app/Contents/dylib/
cp /usr/local/lib/lib02.dylib yourapp.app/Contents/dylib/
cp /usr/local/lib/lib03.dylib yourapp.app/Contents/dylib/

3 install_name_tool -change /usr/local/lib/lib01.dylib @loader_path/../dylib/lib01.dylib "yourapp.app/Contents/MacOS/yourapp"

install_name_tool 是苹果提供的用来修改dylib安装名称的命令。这个命令执行之后，再用otool -L 就可以看到变化了

yourapp.app/Contents/MacOS/yourapp:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
@loader_path/../dylib/lib01.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/local/lib/lib02.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/local/lib/lib03.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.12.0)

注意标红的位置。已经变化了。@loader_path 指的是应用程序运行的位置，也就是yourapp.app/Contents/MacOS/yourapp，所以要用一个..，以便定位到第2步创建的dylib目录。
重复这个命令，修改lib02,lib03

4 otool -L yourapp.app/Contents/dylib/*.dylib

继续用otool 来检查dylib下面使用的第三方库是否还有其他依赖，install_name是否正确，重复1，2，3的步骤，把所需要的dylib复制过来，修改install_name。

如果都改对了，那么这个app就附带上了dylib，可以在其他机器上正确运行了，不用非要寻找/usr/local/lib下面的库了。

刚才我们修改的结果是一个build的结果。当然，每次build都这么折腾一下很麻烦。所以继续这样做：

1 前面的步骤得到了一个完整的dylib目录。把这个dylib复制一份备用。比如放在你的xcode项目下面。

2 编写一个脚本：

mkdir "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/dylib"
cp -f /your/path/to/xcode_project_name/dylib/*.dylib "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/dylib/"

install_name_tool -change /usr/local/lib/lib01.dylib @loader_path/../dylib/lib01.dylib "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/MacOS/$PRODUCT_NAME"
(用这个格式重复前面对app使用过的dylib)

3 在xcode中，展开targets节点，右键点工程名称，在菜单中选Add->New Build Phasa->New Run Script Build Phasa，在打开的对话框里面，把刚才的脚本贴进去。如图所示。

这个脚本会在build之后自动运行。不过我这里有个奇怪的问题，如果Shell里面写了/bin/sh，会报告找不到这个文件(实际上存在)，而让shell为空，反而可以正确的运行shell命令。

经过这些处理，每次编译出来的app就可以拿到其他机器上运行了。可真够麻烦的...

不幸的是偶然将这个文件保存成了test.c，然后编译的时候出现了

error， error C2143: syntax error : missing ';' before 'type'

感觉很奇怪,细细看来所有的语法都似乎都是对的，更奇怪的是把文件改成cpp或者cc能正常编译，把int a;和if调换下也能正常编译。这样的错误可能发生在当变量的声明放在可执行代码之后。而这个是在K&R C中规定的，但在ANSI C中废除。

MSDN (http://support.microsoft.com/kb/58559)给出的解释如下：

In Microsoft C, compiler errors C2143 and C2144 are defined as follows:

You may receive this error message if your program places executable code before a data declaration, an acceptable practice in Kernighan-and-Ritchie C. This practice has been outlawed in later versions of the ANSI drafts. 

This error message will normally occur if a required closing curly brace (}), right parenthesis [)], or semicolon (;) is missing.

注: The C Programming Language的作者简称K&R，也是C语言之父, 经常用K&R C来和ANSI C做对比。这本书的第二版已经用ANSI.

我用的编译器是VS2008, 看来微软向来无视标准。

总结：

在 ANSI C或者C++中，在可执行代码中随时定义变量是允许的，但是在K&R C中是不允许的，VS2008实现的C竟然是K&R C。注意这样的错误也体现在VS中要是用for (int i = 0; i++; i<10)同时你的文件名是.c的也会出现这样的错误。

Code complete中讨论过变量名的最迟绑定有利于增加代码的可读性等。所以在VS中写c要注意了。

请说出const与#define 相比，有何优点？
答案：1） const 常量有数据类型，而宏常量没有数据类型。编译器可以对前者进行类型安全检查。而对后者只进行字符替换，没有类型安全检查，并且在字符替换可能会产生意料不到的错误。
      2） 有些集成化的调试工具可以对const 常量进行调试，但是不能对宏常量进行调试。

在8086 汇编下，逻辑地址和物理地址是怎样转换的？（Intel）
答案：通用寄存器给出的地址，是段内偏移地址，相应段寄存器地址*10H+通用寄存器内地址，就得到了真正要访问的地址。

当一个类A 中没有生命任何成员变量与成员函数,这时sizeof(A)的值是多少，如果不是零，请解释一下编译器为什么没有让它为零。（Autodesk）
答案：肯定不是零。举个反例，如果是零的话，声明一个class A[10]对象数组，而每一个对象占用的空间是零，这时就没办法区分A[0],A[1]…了。

 描述内存分配方式以及它们的区别?
1） 从静态存储区域分配。内存在程序编译的时候就已经分配好，这块内存在程序的整个运行期间都存在。例如全局变量，static 变量。
2） 在栈上创建。在执行函数时，函数内局部变量的存储单元都可以在栈上创建，函数执行结束时这些存储单元自动被释放。栈内存分配运算内置于处理器的指令集。
3） 从堆上分配，亦称动态内存分配。程序在运行的时候用malloc 或new 申请任意多少的内存，程序员自己负责在何时用free 或delete 释放内存。动态内存的生存期由程序员决定，使用非常灵活，但问题也最多。

 main 函数执行以前，还会执行什么代码？
答案：全局对象的构造函数会在main 函数之前执行。

 C++是不是类型安全的？
答案：不是。两个不同类型的指针之间可以强制转换（用reinterpret cast)。C#是类型安全的。

有哪几种情况只能用intialization list 而不能用assignment?

答案：当类中含有const、reference 成员变量；基类的构造函数都需要初始化表。

define DOUBLE(x) x+x ，i = 5*DOUBLE(5)； i 是多少？
答案：i 为30

New delete 与malloc free 的联系与区别?
答案：都是在堆(heap)上进行动态的内存操作。用malloc函数需要指定内存分配的字节数并且不能初始化对象，new 会自动调用对象的构造函数。delete 会调用对象的destructor，而free 不会调用对象的destructor.

1、写一个“标准”宏，这个宏输入两个参数并返回较小的一个。
.#define Min(X, Y) ((X)>(Y)?(Y):(X))//结尾没有;
2、嵌入式系统中经常要用到无限循环，你怎么用C编写死循环。
while(1){}或者for(;;)
3、关键字static的作用是什么？
定义静态变量
4、关键字const有什么含意？
表示常量不可以修改的变量。
5、关键字volatile有什么含意？并举出三个不同的例子？
提示编译器对象的值可能在编译器未监测到的情况下改变。

int (*s[10])(int) 表示的是什么啊
int (*s[10])(int) 函数指针数组，每个指针指向一个int func(int param)的函数。

1.有以下表达式：
int a=248; b=4;int const c=21;const int *d=&a;
int *const e=&b;int const *f const =&a;
请问下列表达式哪些会被编译器禁止？为什么？
*c=32;d=&b;*d=43;e=34;e=&a;f=0x321f;
*c 这是个什么东东，禁止
*d 说了是const， 禁止
e = &a 说了是const 禁止
const *f const =&a; 禁止
2.交换两个变量的值，不使用第三个变量。即a=3,b=5,交换之后a=5,b=3;
有两种解法, 一种用算术算法, 一种用^(异或)
a = a + b;
b = a - b;
a = a - b; 
or
a = a^b;// 只能对int,char..
b = a^b;
a = a^b;
or
a ^= b ^= a;
3.c和c++中的struct有什么不同？
c和c++中struct的主要区别是c中的struct不可以含有成员函数，而c++中的struct可以。c++中struct和class的主要区别在于默认的存取权限不同，struct默认为public，而class默认为private
4.＃i nclude <stdio.h>
＃i nclude <stdlib.h>
void getmemory(char *p)
{
    p=(char *) malloc(100);
    strcpy(p,"hello world");
}
int main( )
{
    char *str=NULL;
    getmemory(str);
    printf("%s/n",str);
    free(str);
    return 0;
   }
程序崩溃，getmemory中的malloc 不能返回动态内存， free（）对str操作很危险
5.char szstr[10];
strcpy(szstr,"0123456789");
产生什么结果？为什么？
长度不一样，会造成非法的OS
6.列举几种进程的同步机制，并比较其优缺点。
   原子操作 
信号量机制
   自旋锁
   管程，会合，分布式系统

7.进程之间通信的途径
共享存储系统
消息传递系统
管道：以文件系统为基础
11.进程死锁的原因
资源竞争及进程推进顺序非法
12.死锁的4个必要条件
互斥、请求保持、不可剥夺、环路
13.死锁的处理
鸵鸟策略、预防策略、避免策略、检测与解除死锁
15.   操作系统中进程调度策略有哪几种？
FCFS(先来先服务)，优先级，时间片轮转，多级反馈
8.类的静态成员和非静态成员有何区别？
类的静态成员每个类只有一个，非静态成员每个对象一个
9.纯虚函数如何定义？使用时应注意什么？
virtual void f()=0;
是接口，子类必须要实现
10.数组和链表的区别
数组：数据顺序存储，固定大小
连表：数据可以随机存储，大小可动态改变

12.ISO的七层模型是什么？tcp/udp是属于哪一层？tcp/udp有何优缺点？
应用层
表示层
会话层
运输层
网络层
物理链路层
物理层
tcp /udp属于运输层
TCP 服务提供了数据流传输、可靠性、有效流控制、全双工操作和多路复用技术等。
与 TCP 不同， UDP 并不提供对 IP 协议的可靠机制、流控制以及错误恢复功能等。由于 UDP 比较简单， UDP 头包含很少的字节，比 TCP 负载消耗少。
tcp: 提供稳定的传输服务，有流量控制，缺点是包头大，冗余性不好
udp: 不提供稳定的服务，包头小，开销小  

1：(void *)ptr 和 (*(void**))ptr的结果是否相同？其中ptr为同一个指针
.(void *)ptr 和 (*(void**))ptr值是相同的
2：int main()
   {
    int x=3;
    printf("%d",x);
    return 1;
   
   }
问函数既然不会被其它函数调用，为什么要返回1？
mian中，c标准认为0表示成功，非0表示错误。具体的值是某中具体出错信息

1，要对绝对地址0x100000赋值，我们可以用
(unsigned int*)0x100000 = 1234;
那么要是想让程序跳转到绝对地址是0x100000去执行，应该怎么做？
*((void (*)( ))0x100000 ) ( );
首先要将0x100000强制转换成函数指针,即:
(void (*)())0x100000
然后再调用它:
*((void (*)())0x100000)();
用typedef可以看得更直观些:
typedef void(*)() voidFuncPtr;
*((voidFuncPtr)0x100000)();
2，已知一个数组table，用一个宏定义，求出数据的元素个数
#define NTBL
#define NTBL (sizeof(table)/sizeof(table[0]))

面试题: 线程与进程的区别和联系? 线程是否具有相同的堆栈? dll是否有独立的堆栈?
进程是死的，只是一些资源的集合，真正的程序执行都是线程来完成的，程序启动的时候操作系统就帮你创建了一个主线程。

每个线程有自己的堆栈。
DLL中有没有独立的堆栈，这个问题不好回答，或者说这个问题本身是否有问题。因为DLL中的代码是被某些线程所执行，只有线程拥有堆栈，如果DLL中的代码是EXE中的线程所调用，那么这个时候是不是说这个DLL没有自己独立的堆栈？如果DLL中的代码是由DLL自己创建的线程所执行，那么是不是说DLL有独立的堆栈？

以上讲的是堆栈，如果对于堆来说，每个DLL有自己的堆，所以如果是从DLL中动态分配的内存，最好是从DLL中删除，如果你从DLL中分配内存，然后在EXE中，或者另外一个DLL中删除，很有可能导致程序崩溃

unsigned short A = 10;
printf("~A = %u\n", ~A);

char c=128; 
printf("c=%d\n",c);

输出多少？并分析过程
第一题，～A ＝0xfffffff5,int值 为－11，但输出的是uint。所以输出4294967285
第二题，c＝0x10,输出的是int，最高位为1，是负数，所以它的值就是0x00的补码就是128，所以输出－128。
这两道题都是在考察二进制向int或uint转换时的最高位处理。

分析下面的程序：
void GetMemory(char **p,int num)
{
    *p=(char *)malloc(num);
    
}        
int main()
{
    char *str=NULL;
    
    GetMemory(&str,100);
    
    strcpy(str,"hello");
    
    free(str);
    
    if(str!=NULL)
    {
        strcpy(str,"world");
    }    
        
    printf("\n str is %s",str);
    getchar();
}    
问输出结果是什么？希望大家能说说原因，先谢谢了
输出str is world。
free 只是释放的str指向的内存空间,它本身的值还是存在的.
所以free之后，有一个好的习惯就是将str=NULL.
此时str指向空间的内存已被回收,如果输出语句之前还存在分配空间的操作的话,这段存储空间是可能被重新分配给其他变量的,
尽管这段程序确实是存在大大的问题（上面各位已经说得很清楚了），但是通常会打印出world来。
这是因为，进程中的内存管理一般不是由操作系统完成的，而是由库函数自己完成的。
当你malloc一块内存的时候，管理库向操作系统申请一块空间（可能会比你申请的大一些），然后在这块空间中记录一些管理信息（一般是在你申请的内存前面一点），并将可用内存的地址返回。但是释放内存的时候，管理库通常都不会将内存还给操作系统，因此你是可以继续访问这块地址的，只不过。。。。。。。。楼上都说过了，最好别这么干。

char a[10],strlen(a)为什么等于15？运行的结果

＃i nclude "stdio.h"
＃i nclude "string.h"

void main()
{

char aa[10];
printf("%d",strlen(aa));
}

sizeof()和初不初始化，没有关系；
strlen()和初始化有关。

char (*str)[20];/*str是一个数组指针，即指向数组的指针．*/
char *str[20];/*str是一个指针数组，其元素为指针型数据．*/

long a=0x801010;
a+5=?
0x801010用二进制表示为：“1000 0000 0001 0000 0001 0000”，十进制的值为8392720，再加上5就是8392725罗

1)给定结构struct A 
{
       char t:4;
       char k:4;
       unsigned short i:8;
       unsigned long m;
};问sizeof(A) = ?
给定结构struct A 
{
       char t:4; 4位
       char k:4; 4位
       unsigned short i:8; 8位      
       unsigned long m; // 偏移2字节保证4字节对齐
}; // 共8字节
2)下面的函数实现在一个数上加一个数，有什么错误？请改正。
int add_n ( int n )
{
    static int i = 100;
    i += n;
    return i;
}
当你第二次调用时得不到正确的结果，难道你写个函数就是为了调用一次？问题就出在 static上？

// 帮忙分析一下
＃i nclude<iostream.h>
＃i nclude <string.h>
＃i nclude <malloc.h>
＃i nclude <stdio.h>
＃i nclude <stdlib.h>
＃i nclude <memory.h>
typedef struct AA
{
        int b1:5;
        int b2:2;
}AA;
void main()
{
        AA aa;
        char cc[100];
         strcpy(cc,"0123456789abcdefghijklmnopqrstuvwxyz");
       memcpy(&aa,cc,sizeof(AA));
        cout << aa.b1 <<endl;
        cout << aa.b2 <<endl;
}
答案是 -16和１
首先sizeof(AA)的大小为4,b1和b2分别占5bit和2bit.
经过strcpy和memcpy后,aa的4个字节所存放的值是:
0,1,2,3的ASC码，即00110000,00110001,00110010,00110011
所以，最后一步：显示的是这４个字节的前５位，和之后的２位
分别为：10000,和01
因为int是有正负之分　　所以：答案是-16和１

求函数返回值，输入x=9999; 
int func （ x ）
{ 
    int countx = 0; 
    while ( x ) 
    { 
        countx ++; 
        x = x&(x-1); 
    } 
    return countx; 
} 
结果呢？
知道了这是统计9999的二进制数值中有多少个1的函数，且有
9999＝9×1024＋512＋256＋15

9×1024中含有1的个数为2；
512中含有1的个数为1；
256中含有1的个数为1；
15中含有1的个数为4；
故共有1的个数为8，结果为8。
1000 - 1 = 0111，正好是原数取反。这就是原理。
用这种方法来求1的个数是很效率很高的。
不必去一个一个地移位。循环次数最少。

int a,b,c 请写函数实现C=a+b ,不可以改变数据类型,如将c改为long int,关键是如何处理溢出问题
bool add (int a, int b,int *c)
{
*c=a+b;
return (a>0 && b>0 &&(*c<a || *c<b) || (a<0 && b<0 &&(*c>a || *c>b)));
}

分析：
struct bit 
{   int a:3; 
    int b:2; 
    int c:3; 
}; 
int main() 
{ 
bit s; 
char *c=(char*)&s; 
   cout<<sizeof(bit)<<endl;
*c=0x99;
   cout << s.a <<endl <<s.b<<endl<<s.c<<endl; 
     int a=-1;
   printf("%x",a);
return 0; 
} 
输出为什么是
4
1
-1
-4
ffffffff
因为0x99在内存中表示为 100 11 001 , a = 001, b = 11, c = 100
当c为有符合数时, c = 100, 最高1为表示c为负数，负数在计算机用补码表示，所以c = -4;同理 
b = -1;
当c为有符合数时, c = 100,即 c = 4,同理 b = 3

位域 ：   
有些信息在存储时，并不需要占用一个完整的字节， 而只需占几个或一个二进制位。例如在存放一个开关量时，只有0和1 两种状态， 用一位二进位即可。为了节省存储空间，并使处理简便，Ｃ语言又提供了一种数据结构，称为“位域”或“位段”。所谓“位域”是把一个字节中的二进位划分为几个不同的区域， 并说明每个区域的位数。每个域有一个域名，允许在程序中按域名进行操作。 这样就可以把几个不同的对象用一个字节的二进制位域来表示。一、位域的定义和位域变量的说明位域定义与结构定义相仿，其形式为：     
struct 位域结构名     
{ 位域列表 };    
其中位域列表的形式为： 类型说明符 位域名：位域长度     
例如：     
struct bs    
{    
int a:8;    
int b:2;    
int c:6;    
};    
位域变量的说明与结构变量说明的方式相同。 可采用先定义后说明，同时定义说明或者直接说明这三种方式。例如：     
struct bs    
{    
int a:8;    
int b:2;    
int c:6;    
}data;    
说明data为bs变量，共占两个字节。其中位域a占8位，位域b占2位，位域c占6位。对于位域的定义尚有以下几点说明：   

1. 一个位域必须存储在同一个字节中，不能跨两个字节。如一个字节所剩空间不够存放另一位域时，应从下一单元起存放该位域。也可以有意使某位域从下一单元开始。例如：     
struct bs    
{    
unsigned a:4    
unsigned :0 /*空域*/    
unsigned b:4 /*从下一单元开始存放*/    
unsigned c:4    
}    
在这个位域定义中，a占第一字节的4位，后4位填0表示不使用，b从第二字节开始，占用4位，c占用4位。   

2. 由于位域不允许跨两个字节，因此位域的长度不能大于一个字节的长度，也就是说不能超过8位二进位。   

3. 位域可以无位域名，这时它只用来作填充或调整位置。无名的位域是不能使用的。例如：     
struct k    
{    
int a:1    
int :2 /*该2位不能使用*/    
int b:3    
int c:2    
};    
从以上分析可以看出，位域在本质上就是一种结构类型， 不过其成员是按二进位分配的。   

二、位域的使用位域的使用和结构成员的使用相同，其一般形式为： 位域变量名•位域名 位域允许用各种格式输出。    
main(){    
struct bs    
{    
unsigned a:1;    
unsigned b:3;    
unsigned c:4;    
} bit,*pbit;    
bit.a=1;    
bit.b=7;    
bit.c=15;    
pri

改错：
＃i nclude <stdio.h>

int main(void) {

    int **p;
    int arr[100];

    p = &arr;

    return 0;
}
解答：
搞错了,是指针类型不同,
int **p; //二级指针
&arr; //得到的是指向第一维为100的数组的指针
＃i nclude <stdio.h>
int main(void) {
int **p, *q;
int arr[100];
q = arr;
p = &q;
return 0;
}

下面这个程序执行后会有什么错误或者效果:
#define MAX 255
int main()
{
   unsigned char A[MAX],i;//i被定义为unsigned char
   for (i=0;i<=MAX;i++)
      A[i]=i;
}
解答：死循环加数组越界访问（C/C++不进行数组越界检查）
MAX=255 
数组A的下标范围为:0..MAX-1,这是其一..
其二.当i循环到255时,循环内执行:
A[255]=255;
这句本身没有问题..但是返回for (i=0;i<=MAX;i++)语句时,
由于unsigned char的取值范围在(0..255),i++以后i又为0了..无限循环下去.

struct name1{
   char str;
   short x;
   int   num;
}

struct name2{
   char str;
   int num;
   short x;
}

sizeof(struct name1)=8,sizeof(struct name2)=12
在第二个结构中，为保证num按四个字节对齐，char后必须留出3字节的空间；同时为保证整个结构的自然对齐（这里是4字节对齐），在x后还要补齐2个字节，这样就是12字节。

intel：
A.c 和B.c两个c文件中使用了两个相同名字的static变量,编译的时候会不会有问题?这两个static变量会保存到哪里（栈还是堆或者其他的）?
static的全局变量，表明这个变量仅在本模块中有意义，不会影响其他模块。
他们都放在数据区，但是编译器对他们的命名是不同的。
如果要使变量在其他模块也有意义的话，需要使用extern关键字。

struct s1
{
int i: 8;
int j: 4;
int a: 3;
double b;
};

struct s2
{
int i: 8;
int j: 4;
double b;
int a:3;
};

printf("sizeof(s1)= %d\n", sizeof(s1));
printf("sizeof(s2)= %d\n", sizeof(s2));
result: 16, 24
第一个struct s1
{
int i: 8;
int j: 4;
int a: 3;
double b;
};
理论上是这样的，首先是i在相对0的位置，占8位一个字节，然后，j就在相对一个字节的位置，由于一个位置的字节数是4位的倍数，因此不用对齐，就放在那里了，然后是a，要在3位的倍数关系的位置上，因此要移一位，在15位的位置上放下，目前总共是18位，折算过来是2字节2位的样子，由于double是8字节的，因此要在相对0要是8个字节的位置上放下，因此从18位开始到8个字节之间的位置被忽略，直接放在8字节的位置了，因此，总共是16字节。

第二个最后会对照是不是结构体内最大数据的倍数，不是的话，会补成是最大数据的倍数

上面是基本问题，接下来是编程问题：

本人很弱，这几个题也搞不定，特来求救：
1）读文件file1.txt的内容（例如）：
12
34
56
输出到file2.txt：
56
34
12
（逆序）
2）输出和为一个给定整数的所有组合
例如n=5
5=1+4；5=2+3（相加的数不能重复）
则输出
1，4；2，3。
望高手赐教！！

第一题,注意可增长数组的应用.
＃i nclude <stdio.h>
＃i nclude <stdlib.h>

int main(void)
{
         int MAX = 10;
int *a = (int *)malloc(MAX * sizeof(int));
int *b;
    
FILE *fp1;
FILE *fp2;

fp1 = fopen("a.txt","r");
if(fp1 == NULL)
{printf("error1");
    exit(-1);
}

    fp2 = fopen("b.txt","w");
if(fp2 == NULL)
{printf("error2");
    exit(-1);
}

int i = 0;
    int j = 0;

while(fscanf(fp1,"%d",&a[i]) != EOF)
{
i++;
j++;
if(i >= MAX)
{
MAX = 2 * MAX;
b = (int*)realloc(a,MAX * sizeof(int));
if(b == NULL)
{
printf("error3");
exit(-1);
}
a = b;
}
}

for(;--j >= 0;)
   fprintf(fp2,"%d\n",a[j]);

fclose(fp1);
fclose(fp2);

return 0;
}

第二题.
＃i nclude <stdio.h>

int main(void)
{
unsigned long int i,j,k;

printf("please input the number\n");
scanf("%d",&i);
    if( i % 2 == 0)
        j = i / 2;
else
j = i / 2 + 1;

printf("The result is \n");
    for(k = 0; k < j; k++)
     printf("%d = %d + %d\n",i,k,i - k);
return 0;
}

＃i nclude <stdio.h>
void main()
{
unsigned long int a,i=1;
scanf("%d",&a);
if(a%2==0)
{
     for(i=1;i<a/2;i++)
     printf("%d",a,a-i);
}
else
for(i=1;i<=a/2;i++)
        printf(" %d, %d",i,a-i);
}

兄弟,这样的题目若是做不出来实在是有些不应该, 给你一个递规反向输出字符串的例子,可谓是反序的经典例程.

void inverse(char *p)
{
    if( *p = = '\0' ) 
return;
    inverse( p+1 );
    printf( "%c", *p );
}

int main(int argc, char *argv[])
{
    inverse("abc\0");

    return 0;
}

借签了楼上的“递规反向输出”
＃i nclude <stdio.h>
void test(FILE *fread, FILE *fwrite)
{
        char buf[1024] = {0};
        if (!fgets(buf, sizeof(buf), fread))
}

Google Breakpad 完全解析（二） —— Windows前台实现篇

原创文章，转载请标明出处：Soul Apogee (http://bigasp.com)，谢谢。

好，看完了如何使用breakpad，我们现在看看breakpad在Windows下到底是如何实现的呢？

代码结构

在我们来看breakpad是如何实现其强大的功能之前，我们先来看一下他的代码结构吧。

Google breakpad的源代码都在src的目录下，他分为如下几个文件夹：
client：这下面包含了前台应用程序中捕捉dump的部分代码，里面按照平台分成各个子文件夹
common：前台后台都会用到的部分基础代码，字符串转换，内存读写，md5神马的
google_breakpad：breakpad中公共的头文件
processor：用于在后台处理崩溃的核心代码
testing：测试工程
third_party：第三方库
tools：一些小工具，用于处理dump文件和符号表

我们先来看Windows下前台实现的部分，也就是client文件夹下的代码。

breakpad的崩溃捕获机制

在Windows下捕获崩溃，大家很容易会想到那个捕获结构化异常的Api：SetUnhandledExceptionFilter。

breakpad中也使用了这个Api来实现的崩溃捕获，另外，breakpad还捕获了另外两种C++运行库提供的崩溃，一种是使用_set_purecall_handler捕获纯虚函数调用产生的崩溃，还有一种是使用_set_invalid_parameter_handler捕获错误的参数调用产生的崩溃。

另外由于C++运行库提供的崩溃回调中，并不会提供当前的线程现场和崩溃信息，所以breakpad会自己生成好这些信息，然后请求生成dump。
这里值得一说的是，在非异常崩溃处理中，breakpad获取线程现场使用的函数是RtlCaptureContext而不是GetThreadContext。
RtlCaptureContext只能捕获当前线程的现场，而GetThreadContext可以捕获任意线程的现场，只要有这个线程的句柄即可。
但是GetThreadContext有两个不好的地方：不能获取当前线程的现场；获取现场前必须先用SuspendThread暂停目标线程。
而RtlCaptureContext虽然只能获取当前线程的现场，但是调用他时可以不用暂停线程的运行。
对于breakpad来说，崩溃发生后越早获取现场就越好，所以breakpad使用RtlCaptureContext函数作为他的线程获取函数。

breakpad中的C/S结构

由于breakpad是在进程外抓取dump，所以breakpad需要实现一个C/S结构来处理崩溃进程抓取dump的请求。

1. breakpad跨进程通信的实现
breakpad中使用了命名管道来实现IPC。

在客户端，初始化ExceptionHandler的时候，如果指定了PipeName，也就表示此时需要使用进程外的dump抓 取，ExceptionHandler，会建立一个 CrashGenerationClient的对象，由这个对象连接服务端，将自己注册到服务端上 去。
大家可以参看exception_handler.cc中的ExceptionHandler::Initialize函数。

在服务端，初始化CrashGenerationServer的时候，就会建立一个命名管道，并等待客户端来连接。一旦有客户端连接上来，服务端会 为每一个客户端生成一个ClientInfo的对象，之后用这个对象来管理所有的客户端，一旦有崩溃发生，服务端都会从这个对象中取出dump所需要的信 息。
大家可以参看crash_generation_server.cc中的CrashGenerationServer::HandleReadDoneState函数。

2. breakpad捕获崩溃生成dump的流程
breakpad进程外生成dump的流程大概如下：
google-breakpad-out-of-process-dump:

这段流程的代码就是crash_generation_client.cc和crash_generation_server.cc。

有两个简单的问题，这里说明一下，高手们就请直接忽略吧，咩哈哈：
在服务端如何为客户端生成事件句柄？
使用DuplicateHandle，即可把任意一个内核对象的句柄复制到其他进程，并且可以指定产生的句柄的权限。

如何异步的等待一个事件？
使用RegisterWaitForSingleObject，即可异步的等待一个事件，当事件发生的时候，就可以回调到一个指定的回 调函数中，但是要注意的是，RegisterWaitForSingleObject会在一个新的线程中来等待这个事件，此处很容易产生多线程的调用，需 要注意线程问题。

3. 服务端关键数据结构：ClientInfo
ClientInfo是服务端中最重要的数据结构，服务端通过它来管理所有的客户端。客户端注册时，会保存或生成里面所有的信息，在客户端请求生成dump的时候，服务端就会通过ClientInfo获取所有客户端的信息。ClientInfo中保存了如下信息：

• 客户端进程pid和句柄
• 生成Minidump的类型
• 自定义的客户端信息
• 客户端崩溃的线程ID
• 客户端崩溃的信息
• 客户端请求崩溃所使用的事件句柄

这里有一个问题：在客户端发生崩溃时，服务器如何通过ClientInfo获取到客户端的崩溃信息呢？

客户端中有几个用于保存崩溃信息的变量，在注册时，客户端会将这几个变量的地址发送至服务端，服务端将其保存在ClientInfo中，然后当崩溃 发生的时候，服务端就可以通过ReadProcessMemory读取客户端中的信息，从而生成dump。这样做就避免了每次发生崩溃，都要通过Pipe 将崩溃信息传递到服务端中去了。

这些变量分别是：崩溃的线程ID，EXCEPTION_POINTERS和MDRawAssertionInfo。
EXCEPTION_POINTERS和MDRawAssertionInfo的区别在于，异常崩溃的信息会被写入EXCEPTION_POINTERS，非异常崩溃（非法参数和纯虚函数调用）的信息会被写入MDRawAssertionInfo中。

dump文件的上传

在breakpad的工程中，有一个工程叫做：crash_report_sender，里面是一个上传崩溃文件的类，他的实现很简单，他使用Windows Internet Api来完成dump文件的上传。
在使用crash_report_sender时，可以为其指定一个checkpoint_file。

这个文件只有一个作用，就是用来保存上次上传崩溃的时间和今天上传过的崩溃的次数。通过这个文件，我们就可以来设置每日上传的崩溃的最大数量。

调整每日上传崩溃的最大数量的函数是set_max_reports_per_day。

需要注意的是：在上传dump文件的时候，crash_report_sender并不会对dump文件进行分析，而是直接上传整个dump文件， 如果你需要上传的dump文件非常大的话，可以考虑把崩溃分析处理的逻辑放入前台，通过去重或者直接上传分析结果，减少上传的文件大小。

breakpad存在的问题

进程外生成dump有很多好处，其中最大的好处就是不会被崩溃进程影响，这样dump的过程就不容易出错，但是这样也有一定的弊端。

1. 部分崩溃无法抓取
在一些极端的崩溃，如堆栈溢出之类的崩溃，进程外抓取dump有时候会失败。

2. 无法抓取死锁或者其他原因导致的进程僵死
breakpad现在没有检测进程死锁的代码，也没有在服务端控制客户端请求dump的代码，所以现在breakpad无法抓取死锁等进程僵死的问题。不过因为breakpad的定位是处理崩溃，如果有这种需要的童鞋，可以自行修改breakpad的代码，添加这些功能。

3. 对服务端有依赖
如果指定了在使用进程外抓取dump，breakpad对服务端就有依赖。主要体现在抓取dump时，如果服务端不存在，客户端将无法正常抓取dump，甚至有时会出现阻塞。

当然对于这些问题，随着breakpad的发展肯定会越来越完善。如果，你遇到了了这些问题，而又绕过不了，那就改代码，并且提交给breakpad吧，开源项目就是这么发展的。

好，到此breakpad的Windows实现就已经说完了，如果有神马问题，还请多多指教。谢谢大家。

北京德胜门中医院http://www.0531jsk.com/德胜门中医院

Google Breakpad 完全解析（一） —— Windows入门篇

原创文章，转载请标明出处：Soul Apogee (http://bigasp.com)，谢谢。

Google breakpad是 一个非常实用的跨平台的崩溃转储和分析模块，他支持Windows，Linux和Mac和Solaris。由于他本身跨平台，所以很大的减少我们在平台移 植时的工作，毕竟崩溃转储，每个平台下都不同，使用起来很难统一，而Google breakpad就帮我们做到了这一点，不管是哪个平台下的崩溃，都能够进行统一的分析。现在很多工程都在使用他：最著名的几个如 Chrome，Firefox，Picasa和Google Earth。另外他的License是BSD的，也就是说，我们即便是在商业软件中使用，也是合法的，哈哈，这么好的东西，我们能放过么？现在就让我们来 看看这个神奇的软件吧。

原理简介

breakpad抓取dump的方式和一般我们抓取dump的方式不一样。在breakpad的wiki上有一幅图可以很好的概括他的原理。

breakpad把应用程序分成三个部分，代码，breakpad客户端和调试信息。

1. 在build system中，通过symbol dumper用平台相关的调试信息生成平台无关的symbol文件。这样做的好处很明显，一旦平台无关了，所有平台的崩溃就可以做统一的分析了。
2. breakpad采取进程外转储和分析崩溃的方式，他使用C/S结构，客户端用来捕获当前进程中发生的崩溃，并通知服务端崩溃发生。服务端用来响应客户端，抓取dump文件。这样做的目的是为了减少崩溃进程对dump的影响。
3. Dump生成后转发到崩溃分析器中，这个部分可以在本地也可以在服务器上，他对Dump文件进行解析，生成可读的堆栈信息。

这就是breakpad处理dump大概的流程。

对于原理的介绍google写的已经相当好了。更多的详细信息，可以直接移步到breakpad的wiki。

安装和编译

breakpad的编译比较曲折，所以在此记录一下。

编译breakpad，请确认你的机器上装有以下的软件：
1. python 2.4.3
请不要使用python3，会报错。另外python2中推荐这个版本，使用新的版本在编译其他google的工程时有时会报错

2. Windows SDK 7
如果没有这个，编译会报错。另外这个是在线安装，时间很久，最好并行做其他的事情。

3. VS2005的补丁
KB918559
KB926601
KB935225
KB943969
KB947315

已经安装了以上软件的童鞋，就可以开始进行下面的工作鸟

1. 使用svn把代码checkout下来

2. 设置Windows SDK 7
装过其他版本Windows SDK的童鞋，记得一定要进行这一步，SDK的安装程序，并不会帮你设置VS。
运行开始菜单->程序->Microsoft Windows SDK v7.0->Visual Studio Registration->Windows SDK Configuration Tool，选择v7.0，点击Make Current。

3. 为python设置环境变量
由于breakpad使用python来生成Windows下的工程文件，所以需要将python所在目录，设置到环境变量PATH中去。

4. 生成Windows工程文件

此时，在src/client/windows下就可以看到生成好的breakpad_client.sln了。运行吧！

5. Hello World!
编译build all，现在一般是不会报错了，如果报错，请检查是不是漏了什么步骤，特别是补丁。
编译完成之后，运行crash_generation_app吧，这是他的测试程序，dump的默认位置保存在C:Dumps下，请注意先建立好目录，不然会无法使用。
启动测试程序之后，此时还不能抓取dump，因为这个是breakpad中的服务器端，需要再启动一个测试程序，在第二个测试程序中，我们就可以试验Client菜单中的各种崩溃了。这些崩溃都会被抓住转存到C:Dumps目录下。

如何使用breakpad

在Windows下使用breakpad的方法很简单，只需要创建一个ExceptionHandler的类即可，大家可以在crash_generation_app这个工程中找到示例代码，也可以直接移步Wiki，上面说的也很详细。

1.进程内抓取Dump文件

进程内抓取Dump文件是最简单的breakpad的用法。使用方法很简单：

2.进程外抓取Dump文件

使用进程外抓取Dump时，需要指定服务端和客户端，在服务端中需要创建CrashGenerationServer的实例，而在客户端中则只需要创建ExceptionHandler即可。此外，如果服务端自己需要抓进程内的Dump，请将pipe的参数置为NULL。

使用breakpad的时候，有两个地方需要注意：
1. 记得把breakpad的solution下的几个工程，包含到你开发的工程中，或者直接包含他们的lib。
common：基础功能，包含一个对GUID的封装和http上传的类。
exception_handler：用来捕获崩溃的类。
crash_generation_server：breakpad的服务端，用来在产生崩溃时抓取dump。
crash_generation_client：breakpad的客户端，用来捕获当前进程的崩溃。

2. 在初始化breakpad之前，记得先创建好dump文件的目录，不然breakpad服务端将不能正常的写dump，这会导致breakpad客户端在崩溃时无限等待服务端dump写完的消息，最后失去响应。

调试Release发布版程序的Crash错误 （转）

操作系统装载应用程序后，做完初始化工作就转到程序的入口点执行。程序的默认入 口点由连接程序设置， 不同的连接器选择的入口函数也不尽相同。在VC++下，连接器对控制台程序设置的入口函数是 mainCRTStartup，mainCRTStartup 再调用main 函数；对图形用户界面（GUI）程序设置的入口函数是 WinMainCRTStartup，WinMainCRTStartup 调用你自己写的 WinMain 函数。具体设置哪个入口点是由连接器的“/subsystem:”选项确定的，它告诉操作系统如何运行编译生成的.EXE文件。可以指定四种方 式：CONSOLE|WINDOWS|NATIVE|POSIX。如果这个选项参数的值为 WINDOWS，则表示该应用程序运行时不需要控制台，有关连接器参数选项的详细说明请参考 MSDN 库。

以下四种组合，可以实现console和windows模式的混合，可以达到不弹出DOS窗口的效果，也可以达到在Windows程序中向控制台输出printf信息的目的。
#pragma comment( linker, "/subsystem:windows /entry:WinMainCRTStartup" )
#pragma comment( linker, "/subsystem:windows /entry:mainCRTStartup" )
#pragma comment( linker, "/subsystem:console /entry:mainCRTStartup" )
#pragma comment( linker, "/subsystem:console /entry:WinMainCRTStartup" )

int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR      lpCmdLine,
int        nCmdShow)
{
      // ...
}

int main(void)
{
      // ...
}

1、Run-Time Library

C Run-Time Libraries有静态库版本，也有动态链接库版本；有单线程版本，也有多线程版本；还有调试和非调试版本。
可以在"project"-"settings"-"C/C++"-"Code Generation"中选择Run-Time Library的版本。

动态链接库版本：
/MD Multithreaded DLL 使用导入库MSVCRT.LIB
/MDd Debug Multithreaded DLL 使用导入库MSVCRTD.LIB

静态库版本：
/ML Single-Threaded 使用静态库LIBC.LIB 
/MLd Debug Single-Threaded 使用静态库LIBCD.LIB
/MT Multithreaded 使用静态库LIBCMT.LIB
/MTd Debug Multithreaded 使用静态库LIBCMTD.LIB

C Run-Time Library的标准io部分与操作系统的关系很密切，在Windows上，CRT的io部分代码只是一个包装，底层要用到操作系统内核kernel32.dll中的函数，在编译时使用导入库kernel32.lib。这也就是为什么在嵌入式环境中，我们一般不能直接使用C标准库。
在Linux环境当然也有C标准库，例如：
ld -o output /lib/crt0.o hello.o -lc
参数"-lc"就是在引用C标准库libc.a。猜一猜"-lm"引用哪个库文件？

2、常见的编译参数

与MFC DLL有关的编译常数包括：
_WINDLL 表示要做一个用到MFC的DLL
_USRDLL 表示做一个用户DLL（相对MFC扩展DLL而言） 
_AFXDLL 表示使用MFC动态链接库
_AFXEXT 表示要做一个MFC扩展DLL
所以：
Regular, statically linked to MFC _WINDLL,_USRDLL 
Regular, using the shared MFC DLL _WINDLL,_USRDLL,_AFXDLL
Extension DLL _WINDLL,_AFXDLL,_AFXEXT

CL.EXE编译所有源文件，LINK.EXE链接EXE和DLL，LIB.EXE产生静态库。

3、subsystem和可执行文件的启动

将 subsystem 选成"console"后，Windows在进入可执行文件的代码前（如mainCRTStartup），就会产生一个控制台窗口。
如果选择"windows"，操作系统就不产生console窗口,该类型应用程序的窗口由用户自己创建。

可执行文件都有一个Entry Point，LINK时可以用/entry指定。缺省情况下，如果subsystem是“console”，Entry Point是 mainCRTStartup(ANSI)或wmainCRTStartuup(UNICODE)，即：
/subsystem:"console" /entry:"mainCRTStartup" (ANSI)
/subsystem:"console" /entry:"wmainCRTStartuup" (UNICODE)
mainCRTStartup 或 wmainCRTStartuup 会调用main或wmain。
值得一提的是，在进入应用程序的Entry Point前，Windows的装载器已经做过C变量的初始化，有初值的全局变量拥有了它们的初值，没有初值的变量被设为0。

如果subsystem是“windows”，Entry Point是WinMain(ANSI)或wWinMain(UINCODE)，即：
/subsystem:"windows" /entry:"WinMainCRTStartup" (ANSI)
/sbusystem:"windows" /entry:"wWinMainCRTStartup" (UINCODE)
WinMainCRTStartup 或 wWinMainCRTStartup 会调用 WinMain 或 wWinMain。

这些入口点函数，在CRT目录都可以看到源代码，例如（为了简洁，我删除了原代码的一些条件编译）：

void mainCRTStartup(void)
{
        int mainret;

        /* Get the full Win32 version */
        _osver = GetVersion();
        _winminor = (_osver >> 8) & 0x00FF ;
        _winmajor = _osver & 0x00FF ;
        _winver = (_winmajor << 8) + _winminor;
        _osver = (_osver >> 16) & 0x00FFFF ;

#ifdef _MT
        if ( !_heap_init(1) )               /* initialize heap */
#else  /* _MT */
        if ( !_heap_init(0) )               /* initialize heap */
#endif  /* _MT */
            fast_error_exit(_RT_HEAPINIT);  /* write message and die */

#ifdef _MT
        if( !_mtinit() )                    /* initialize multi-thread */
            fast_error_exit(_RT_THREAD);    /* write message and die */
#endif  /* _MT */

        __try {
            _ioinit();                      /* initialize lowio */
            _acmdln = (char *)GetCommandLineA();        /* get cmd line info */
            _aenvptr = (char *)__crtGetEnvironmentStringsA();        /* get environ info */
            _setargv();
            _setenvp();
            __initenv = _environ;
            mainret = main(__argc, __argv, _environ);
            exit(mainret);
        }
        __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) )
        {
            _exit( GetExceptionCode() );        /* Should never reach here */
        } /* end of try - except */
}  

如果使用MFC框架，WinMain也会被埋藏在MFC库中（APPMODUL.CPP）：
extern "C" int WINAPI
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPTSTR lpCmdLine, int nCmdShow)
{
// call shared/exported WinMain
return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}
对于ANSI版本，"_tWinMain"就是"WinMain"；对于UINCODE版本，"_tWinMain"就是"wWinMain"。可参见afx.h：

#ifdef _UNICODE
#define _tmain wmain
#define _tWinMain wWinMain
#else
#define _tmain main
#define _tWinMain WinMain
#endif

全局C++对象的构造函数是在什么地方调用的？答案是在进入应用程序的Entry Point后，在调用main函数前的初始化操作中。所以MFC的theApp的构造函数是在_tWinMain之前调用的。

4、不显示Console窗口的Console程序

#include "windows.h"
#pragma comment( linker, "/subsystem:\"windows\" /entry:\"mainCRTStartup\"" ) // 设置入口地址 
void main(void)
{
MessageBox(NULL, "hello", "Notice", MB_OK);
}

这个Console程序就不会显示Console窗口。如果选/MLd的话，这个程序只需要链接LIBCD.LIB user32.lib kernel32.lib。

其实如果不想看到Console窗口，还有一个更直接的方法：那就是直接在EXE文件中将PE文件头的Subsystem从3改成2。在EXE文件中，PE文件头的偏移地址是0x3c，Subsystem是一个WORD，它在PE文件头中的偏移是0x5c。

5、MFC的库文件

静态MFC库主要有：
ANSI Debug NAFXCWD.LIB
ANSI Release NAFXCW.LIB
Unicode Debug UAFXCWD.LIB
Unicode Release UAFXCW.LIB 

动态链接库主要有;
ANSI Debug MFCxxD.LIB (core，MFCxxD.DLL), 
MFCOxxD.LIB (OLE，MFCOxxD.DLL), 
MFCDxxD.LIB (database，MFCDxxD.DLL), 
MFCNxxD.LIB (network，MFCNxxD.DLL), 
MFCSxxD.LIB (static)

ANSI Release MFCxx.LIB (combined，MFCxx.DLL)
MFCSxx.LIB (static)

Unicode Debug MFCxxUD.LIB (core，MFCxxUD.DLL), 
MFCOxxUD.LIB (OLE，MFCOxxUD.DLL), 
MFCDxxUD.LIB (database，MFCDxxUD.DLL), 
MFCNxxUD.LIB (network，MFCNxxUD.DLL), 
MFCSxxUD.LIB (static)

Unicode Release MFCxxU.DLL (combined，MFCxxU.DLL), 
MFCSxxU.LIB (static)

上面的LIB文件除了MFCSxx(D、U、UD).LIB以外都是导入库。
MFC动态链接库版本也需要静态链接一些文件，这些文件就放在MFCSxx(D、U、UD).LIB中。例如包含_tWinMain的appmodul.cpp。

6、结束语

研究这些问题的动机是想弄清楚我们的程序是如何装载、运行的。但是，由于Windows不是开源平台，我也只能研究到PE文件（Windows上可执行文件的格式）。entry point、subsystem都是PE文件头的一部分。

Windows在进入PE文件的entry point之前做了些什么，就看不到了，只能大概推测：应该是创建一个进程，装载PE文件和所有需要的DLL，初始化C变量，然后从某个起点函数开始运行。不同的subsystem，应该有不同的起点。调用这个起点函数时应该传入PE文件的entry point地址。

1 什么是堆栈

编译器一般使用堆栈实现函数调用。堆栈是存储器的一个区域，嵌入式环境有时需要程序员自己定义一个数组作为堆栈。Windows为每个线程自动维护一个堆栈，堆栈的大小可以设置。编译器使用堆栈来堆放每个函数的参数、局部变量等信息。

函数调用经常是嵌套的，在同一时刻，堆栈中会有多个函数的信息，每个函数占用一个连续的区域。一个函数占用的区域被称作帧（frame）。

编译器从高地址开始使用堆栈。 假设我们定义一个数组a[1024]作为堆栈空间，一开始栈顶指针指向a[1023]。如果栈里有两个函数a和b，且a调用了b，栈顶指针会指向函数b的帧。如果函数b返回。栈顶指针就指向函数a的帧。如果在栈里放了太多东西造成溢出，破坏的是a[0]上面的东西。

在多线程（任务）环境，CPU的堆栈指针指向的存储器区域就是当前使用的堆栈。切换线程的一个重要工作，就是将堆栈指针设为当前线程的堆栈栈顶地址。

不同CPU，不同编译器的堆栈布局、函数调用方法都可能不同，但堆栈的基本概念是一样的。

2 函数调用约定

函数调用约定包括传递参数的顺序，谁负责清理参数占用的堆栈等，例如 ：

调用函数的代码和被调函数必须采用相同的函数的调用约定，程序才能正常运行。在Windows上，__cdecl是C/C++程序的缺省函数调用约定。

在有的cpu上，编译器会用寄存器传递参数，函数使用的堆栈由被调函数分配和释放。这种调用约定在行为上和__cdecl有一个共同点：实参和形参数目不符不会导致堆栈错误。

不过，即使用寄存器传递参数，编译器在进入函数时，还是会将寄存器里的参数存入堆栈指定位置。参数和局部变量一样应该在堆栈中有一席之地。参数可以被理解为由调用函数指定初值的局部变量。

3 例子：__cdecl和__stdcall

不同的CPU，不同的编译器，堆栈的布局可能是不同的。本文以x86，VC++的编译器为例。

VC++编译器的已经不再支持__pascal, __fortran, __syscall等函数调用约定。目前只支持__cdecl和__stdcall。

采用__cdecl或__stdcall调用方式的程序，在刚进入子函数时，堆栈内容是一样的。esp指向的栈顶是返回地址。这是被call指令压入堆栈的。下面是参数，左边参数在上，右边参数在下（先入栈）。

如前表所示，__cdecl和__stdcall的区别是：__cdecl是调用者清理参数占用的堆栈，__stdcall是被调函数清理参数占用的堆栈。

由于__stdcall的被调函数在编译时就必须知道传入参数的准确数目（被调函数要清理堆栈），所以不能支持变参数函数，例如printf。而且如果调用者使用了不正确的参数数目，会导致堆栈错误。

通过查看汇编代码，__cdecl函数调用在call语句后会有一个堆栈调整语句，例如：

a = 0x1234;
b = 0x5678;
c = add(a, b);

对应x86汇编：

mov dword ptr [ebp-4],1234h
mov dword ptr [ebp-8],5678h
mov eax,dword ptr [ebp-8]
push eax
mov ecx,dword ptr [ebp-4]
push ecx
call 0040100a
add esp,8
mov dword ptr [ebp-0Ch],eax

__stdcall的函数调用则不需要调整堆栈：

call 00401005
mov dword ptr [ebp-0Ch],eax

函数

int __cdecl add(int a, int b)
{
return a+b;
}

产生以下汇编代码（Debug版本）：

push ebp
mov ebp,esp
sub esp,40h
push ebx
push esi
push edi
lea edi,[ebp-40h]
mov ecx,10h
mov eax,0CCCCCCCCh
rep stos dword ptr [edi]
mov eax,dword ptr [ebp+8]
add eax,dword ptr [ebp+0Ch]
pop edi
pop esi
pop ebx
mov esp,ebp
pop ebp
ret // 跳转到esp所指地址,并将esp+4,使esp指向进入函数时的第一个参数

再查看__stdcall函数的实现，会发现与__cdecl函数只有最后一行不同：

ret 8 // 执行ret并清理参数占用的堆栈

对于调试版本，VC++编译器在“直接调用地址”时会增加检查esp的代码，例如：

ta = (TAdd)add; // TAdd定义：typedef int (__cdecl *TAdd)(int a, int b);
c = ta(a, b);

产生以下汇编代码：

mov [ebp-10h],0040100a
mov esi,esp
mov ecx,dword ptr [ebp-8]
push ecx
mov edx,dword ptr [ebp-4]
push edx
call dword ptr [ebp-10h]
add esp,8
cmp esi,esp
call __chkesp (004011e0)
mov dword ptr [ebp-0Ch],eax

__chkesp 代码如下。如果esp不等于函数调用前保存的值，就会转到错误处理代码。

004011E0 jne __chkesp+3 (004011e3)
004011E2 ret
004011E3 ;错误处理代码

__chkesp的错误处理会弹出对话框，报告函数调用造成esp值不正确。 Release版本的汇编代码要简洁得多。也不会增加 __chkesp。如果发生esp错误，程序会继续运行，直到“遇到问题需要关闭”。

3 补充说明

函数调用约定只是“调用函数的代码”和被调用函数之间的关系。

假设函数A是__stdcall，函数B调用函数A。你必须通过函数声明告诉编译器，函数A是__stdcall。编译器自然会产生正确的调用代码。

如果函数A是__stdcall。但在引用函数A的地方，你却告诉编译器，函数A是__cdecl方式，编译器产生__cdecl方式的代码，与函数A的调用约定不一致，就会发生错误。

以delphi调用VC函数为例，delphi的函数缺省采用__pascal约定，VC的函数缺省采用__cdecl约定。我们一般将VC的函数设为__stdcall，例如：

int __stdcall add(int a, int b);

在delphi中将这个函数也声明为__stdcall，就可以调用了：

function add(a: Integer; b: Integer): Integer;
stdcall; external 'a.dll';

因为考虑到可能被其它语言的程序调用，不少API采用__stdcall的调用约定。

3 字符编码模型

程序员经常会面对复杂的问题，而降低复杂性的最简单的方法就是分而治之。Peter Constable在他的文章"Character set encoding basics Understanding character set encodings and legacy encodings"中描述了字符编码的四层模型。我觉得这种说法确实可以更清晰地展现字符编码中发生的事情，所以在这里也介绍一下。

3.1 字符的范围（Abstract character repertoire）

设计字符编码的第一层就是确定字符的范围，即要支持哪些字符。有些编码方案的字符范围是固定的，例如ASCII、ISO 8859 系列。有些编码方案的字符范围是开放的，例如Unicode的字符范围就是世界上所有的字符。

3.2 用数字表示字符（Coded character set）

设计字符编码的第二层是将字符和数字对应起来。可以将这个层次理解成数学家（即从数学角度）看到的字符编码。数学家看到的字符编码是一个正整数。例如在Unicode中：汉字“字”对应的数字是23383。汉字“”对应的数字是134192。

在写html文件时，可以通过输入"字"来插入字符“字”。不过在设计字符编码时，我们还是习惯用16进制表示数字。即将23383写成0x5BD7，将134192写成0x20C30。

3.3 用基本数据类型表示字符（Character encoding form）

设计字符编码的第三层是用编程语言中的基本数据类型来表示字符。可以将这个层次理解成程序员看到的字符编码。在Unicode中，我们有很多方式将数字23383表示成程序中的数据，包括：UTF-8、UTF-16、UTF-32。UTF是“UCS Transformation Format”的缩写，可以翻译成Unicode字符集转换格式，即怎样将Unicode定义的数字转换成程序数据。例如，“汉字”对应的数字是0x6c49和0x5b57，而编码的程序数据是：

	BYTE data_utf8[] = {0xE6, 0xB1, 0x89, 0xE5, 0xAD, 0x97};	// UTF-8编码
	WORD data_utf16[] = {0x6c49, 0x5b57};				// UTF-16编码
	DWORD data_utf32[] = {0x6c49, 0x5b57};				// UTF-32编码

这里用BYTE、WORD、DWORD分别表示无符号8位整数，无符号16位整数和无符号32位整数。UTF-8、UTF-16、UTF-32分别以BYTE、WORD、DWORD作为编码单位。

“汉字”的UTF-8编码需要6个字节。“汉字”的UTF-16编码需要两个WORD，大小是4个字节。“汉字”的UTF-32编码需要两个DWORD，大小是8个字节。4.2节会介绍将数字映射到UTF编码的规则。

3.4 作为字节流的字符（Character encoding scheme）

字符编码的第四层是计算机看到的字符，即在文件或内存中的字节流。例如，“字”的UTF-32编码是0x5b57，如果用little endian表示，字节流是“57 5b 00 00”。如果用big endian表示，字节流是“00 00 5b 57”。

字符编码的第三层规定了一个字符由哪些编码单位按什么顺序表示。字符编码的第四层在第三层的基础上又考虑了编码单位内部的字节序。UTF-8的编码单位是字节，不受字节序的影响。UTF-16、UTF-32根据字节序的不同，又衍生出UTF-16LE、UTF-16BE、UTF-32LE、UTF-32BE四种编码方案。LE和BE分别是Little Endian和Big Endian的缩写。

3.5 小结

通过四层模型，我们又把字符编码中发生的这些事情梳理了一遍。其实大多数代码页都不需要完整的四层模型，例如GB18030以字节为编码单位，直接规定了字节序列和字符的映射关系，跳过了第二层，也不需要第四层。

4 再谈Unicode

Unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。Unicode用数字0-0x10FFFF来映射这些字符，最多可以容纳1114112个字符，或者说有1114112个码位。码位就是可以分配给字符的数字。UTF-8、UTF-16、UTF-32都是将数字转换到程序数据的编码方案。

Unicode字符集可以简写为UCS（Unicode Character Set）。早期的Unicode标准有UCS-2、UCS-4的说法。UCS-2用两个字节编码，UCS-4用4个字节编码。UCS-4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个平面（plane）。每个平面根据第3个字节分为256行 （row），每行有256个码位（cell）。group 0的平面0被称作BMP（Basic Multilingual Plane）。将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。

Unicode标准计划使用group 0 的17个平面: 从BMP（平面0）到平面16，即数字0-0x10FFFF。《谈谈Unicode编码》主要介绍了BMP的编码，本文将介绍完整的Unicode编码，并从多个角度浏览Unicode。本文的介绍基于Unicode 5.0.0版本。

4.1 浏览Unicode

先看一些数字：每个平面有2^16=65536个码位。Unicode计划使用了17个平面，一共有17*65536=1114112个码位。其实，现在已定义的码位只有238605个，分布在平面0、平面1、平面2、平面14、平面15、平面16。其中平面15和平面16上只是定义了两个各占65534个码位的专用区（Private Use Area），分别是0xF0000-0xFFFFD和0x100000-0x10FFFD。所谓专用区，就是保留给大家放自定义字符的区域，可以简写为PUA。

平面0也有一个专用区：0xE000-0xF8FF，有6400个码位。平面0的0xD800-0xDFFF，共2048个码位，是一个被称作代理区（Surrogate）的特殊区域。它的用途将在4.2节介绍。

238605-65534*2-6400-2408=99089。余下的99089个已定义码位分布在平面0、平面1、平面2和平面14上，它们对应着Unicode目前定义的99089个字符，其中包括71226个汉字。平面0、平面1、平面2和平面14上分别定义了52080、3419、43253和337个字符。平面2的43253个字符都是汉字。平面0上定义了27973个汉字。

在更深入地了解Unicode字符前，我们先了解一下UCD。

4.1.1 什么是UCD

UCD是Unicode字符数据库（Unicode Character Database）的缩写。UCD由一些描述Unicode字符属性和内部关系的纯文本或html文件组成。大家可以在Unicode组织的网站看到UCD的最新版本。

UCD中的文本文件大都是适合于程序分析的Unicode相关数据。其中的html文件解释了数据库的组织，数据的格式和含义。UCD中最庞大的文件无疑就是描述汉字属性的文件Unihan.txt。在UCD 5.0,0中，Unihan.txt文件大小有28,221K字节。Unihan.txt中包含了很多有参考价值的索引，例如汉字部首、笔划、拼音、使用频度、四角号码排序等。这些索引都是基于一些比较权威的辞典，但大多数索引只能检索部分汉字。

我介绍UCD的目的主要是为了使用其中的两个概念：Block和Script。

4.1.2 Block

UCD中的Blocks.txt将Unicode的码位分割成一些连续的Block，并描述了每个Block的用途：

Block是Unicode字符的一个属性。属于同一个Block的字符有着相近的用途。Block表中的开始码位、结束码位只是用来划分出一块区域，在开始码位和结束码位之间可能还有很多未定义的码位。使用UniToy，大家可以按照Block浏览Unicode字符，既可以按列表显示：

4.1.3 Script

Unicode中每个字符都有一个Script属性，这个属性表明字符所属的文字系统。Unicode目前支持以下Script：

其中，有两个Script值有着特殊的含义：

• Common：Script属性为Common的字符可能在多个文字系统中使用，不是某个文字系统特有的。例如：空格、数字等。
• Inherited：Script属性为Inherited的字符会继承前一个字符的Script属性。主要是一些组合用符号，例如：在“组合附加符号”区（0x300-0x36f），字符的Script属性都是Inherited。

UCD中的Script.txt列出了每个字符的Script属性。使用UniToy可以按照Script属性查看字符。例如：

左侧Script窗口中，第一层节点是按英文字母顺序排列的Script属性。第二层节点是包含该Script文字的行（row），点击后显示该行内属于这个Script的字符。这样，就可以集中查看属于同一文字系统的字符。

4.1.4 Unicode中的汉字

前面提过，在Unicode已定义的99089个字符中，有71226个字符是汉字。它们的分布如下：

UCD的Unihan.txt中的部首偏旁索引（kRSUnicode）可以检索全部71226个汉字。kRSUnicode的部首是按照康熙字典定义的，共214个部首。简体字按照简体部首对应的繁体部首检索。UniToy整理了康熙字典部首对应的简体部首，提供了按照部首检索汉字的功能：

4.2 UTF编码

在字符编码的四个层次中，第一层的范围和第二层的编码在4.1节已经详细讨论过了。本节讨论第三层的UTF编码和第四层的字节序，主要谈谈第三层的UTF编码，即怎样将Unicode定义的编码转换成程序数据。

4.2.1 UTF-8

UTF-8以字节为单位对Unicode进行编码。从Unicode到UTF-8的编码方式如下：

UTF-8的特点是对不同范围的字符使用不同长度的编码。对于0x00-0x7F之间的字符，UTF-8编码与ASCII编码完全相同。UTF-8编码的最大长度是4个字节。从上表可以看出，4字节模板有21个x，即可以容纳21位二进制数字。Unicode的最大码位0x10FFFF也只有21位。

例1：“汉”字的Unicode编码是0x6C49。0x6C49在0x0800-0xFFFF之间，使用用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将0x6C49写成二进制是：0110 1100 0100 1001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。

例2：“”字的Unicode编码是0x20C30。0x20C30在0x010000-0x10FFFF之间，使用用4字节模板了：11110xxx 10xxxxxx 10xxxxxx 10xxxxxx。将0x20C30写成21位二进制数字（不足21位就在前面补0）：0 0010 0000 1100 0011 0000，用这个比特流依次代替模板中的x，得到：11110000 10100000 10110000 10110000，即F0 A0 B0 B0。

4.2.2 UTF-16

UniToy有个“输出编码”功能，可以输出当前选择的文本编码。因为UniToy内部采用UTF-16编码，所以输出的编码就是文本的UTF-16编码。例如：如果我们输出“汉”字的UTF-16编码，可以看到0x6C49，这与“汉”字的Unicode编码是一致的。如果我们输出“”字的UTF-16编码，可以看到0xD843, 0xDC30。“”字的Unicode编码是0x20C30，它的UTF-16编码是怎样得到的呢？

4.2.2.1 编码规则

UTF-16编码以16位无符号整数为单位。我们把Unicode编码记作U。编码规则如下：

• 如果U<0x10000，U的UTF-16编码就是U对应的16位无符号整数（为书写简便，下文将16位无符号整数记作WORD）。
• 如果U≥0x10000，我们先计算U'=U-0x10000，然后将U'写成二进制形式：yyyy yyyy yyxx xxxx xxxx，U的UTF-16编码（二进制）就是：110110yyyyyyyyyy110111xxxxxxxxxx。

为什么U'可以被写成20个二进制位？Unicode的最大码位是0x10ffff，减去0x10000后，U'的最大值是0xfffff，所以肯定可以用20个二进制位表示。例如：“”字的Unicode编码是0x20C30，减去0x10000后，得到0x10C30，写成二进制是：0001 0000 1100 0011 0000。用前10位依次替代模板中的y，用后10位依次替代模板中的x，就得到：1101100001000011 1101110000110000，即0xD843 0xDC30。

4.2.2.2 代理区（Surrogate）

按照上述规则，Unicode编码0x10000-0x10FFFF的UTF-16编码有两个WORD，第一个WORD的高6位是110110，第二个WORD的高6位是110111。可见，第一个WORD的取值范围（二进制）是11011000 00000000到11011011 11111111，即0xD800-0xDBFF。第二个WORD的取值范围（二进制）是11011100 00000000到11011111 11111111，即0xDC00-0xDFFF。

为了将一个WORD的UTF-16编码与两个WORD的UTF-16编码区分开来，Unicode编码的设计者将0xD800-0xDFFF保留下来，并称为代理区（Surrogate）：

高位替代就是指这个范围的码位是两个WORD的UTF-16编码的第一个WORD。低位替代就是指这个范围的码位是两个WORD的UTF-16编码的第二个WORD。那么，高位专用替代是什么意思？我们来解答这个问题，顺便看看怎么由UTF-16编码推导Unicode编码。

解：如果一个字符的UTF-16编码的第一个WORD在0xDB80到0xDBFF之间，那么它的Unicode编码在什么范围内？我们知道第二个WORD的取值范围是0xDC00-0xDFFF，所以这个字符的UTF-16编码范围应该是0xDB80 0xDC00到0xDBFF 0xDFFF。我们将这个范围写成二进制：

1101101110000000 11011100 00000000 - 1101101111111111 1101111111111111

按照编码的相反步骤，取出高低WORD的后10位，并拼在一起，得到

1110 0000 0000 0000 0000 - 1111 1111 1111 1111 1111

即0xe0000-0xfffff，按照编码的相反步骤再加上0x10000，得到0xf0000-0x10ffff。这就是UTF-16编码的第一个WORD在0xdb80到0xdbff之间的Unicode编码范围，即平面15和平面16。因为Unicode标准将平面15和平面16都作为专用区，所以0xDB80到0xDBFF之间的保留码位被称作高位专用替代。

4.2.3 UTF-32

UTF-32编码以32位无符号整数为单位。Unicode的UTF-32编码就是其对应的32位无符号整数。

4.2.4 字节序

根据字节序的不同，UTF-16可以被实现为UTF-16LE或UTF-16BE，UTF-32可以被实现为UTF-32LE或UTF-32BE。例如：

字符	Unicode编码	UTF-16LE	UTF-16BE	UTF32-LE	UTF32-BE
汉	0x6C49	49 6C	6C 49	49 6C 00 00	00 00 6C 49
	0x20C30	43 D8 30 DC	D8 43 DC 30	30 0C 02 00	00 02 0C 30

Unicode标准建议用BOM（Byte Order Mark）来区分字节序，即在传输字节流前，先传输被作为BOM的字符"零宽无中断空格"。这个字符的编码是FEFF，而反过来的FFFE（UTF-16）和FFFE0000（UTF-32）在Unicode中都是未定义的码位，不应该出现在实际传输中。下表是各种UTF编码的BOM：

5 结束语

程序员的工作就是将复杂的世界简单地表达出来，希望这篇文章也能做到这一点。本文的初稿完成于2007年2月14日。我会在我的个人主页http://www.fmddlmyy.cn维护这篇文章的最新版本。

我曾经写过一篇《谈谈Unicode编码，简要解释UCS、UTF、BMP、BOM等名词》（以下简称《谈谈Unicode编码》），在网上流传较广，我也收到不少朋友的反馈。本文探讨《谈谈Unicode编码》中未介绍或介绍较少的代码页、Surrogates等问题，补充一些Unicode资料，顺带介绍一下我最近编写的一个Unicode工具：UniToy。本文虽然是前文的补充，但在写作上尽量做到独立成篇。

标题中的“浅谈”是对自己的要求，我希望文字能尽量浅显易懂。但本文还是假设读者知道字节、16进制，了解《谈谈Unicode编码》中介绍过的字节序和Unicode的基本概念。

0 UniToy

1 文字的显示

1.1 发生了什么？

我们首先以Windows为例来看看文字显示过程中发生了什么。用记事本打开一个文本文件，可以看到文件包含的文字：

如果我们用UltraEdit或Hex Workshop查看这个文件的16进制数据，可以看到：

我们看到：文件“例子GBK.txt”有10个字节，依次是“D7 D6 B7 FB BA CD B1 E0 C2 EB”，这就是记事本从文件中读到的内容。记事本是用来打开文本文件的，所以它会调用Windows的文本显示函数将读到的数据作为文本显示。Windows首先将文本数据转换到它内部使用的编码格式：Unicode，然后按照文本的Unicode去字体文件中查找字体图像，最后将图像显示到窗口上。 总结一下前面的分析，文字的显示应该是这样的：

• 步骤1：文字首先以某种编码保存在文件中。
• 步骤2：Windows将文件中的文字编码映射到Unicode。
• 步骤3：Windows按照Unicode在字体文件中查找字体图像，画到窗口上。

如果上述3个步骤中任何一步发生了错误，文字就不能被正确显示，例如：

• 错误1：如果弄错了编码，例如将Big5编码的文字当作GBK编码，就会出现乱码。

  

• 错误2：如果从特定编码到Unicode的映射发生错误，例如文本数据中出现该编码方案未定义的字符，Windows就会使用缺省字符，通常是?。

  

• 如果当前字体不支持要显示的字符，Windows就会显示字体文件中的缺省图像：空白或方格。

在Unicode被广泛使用前，有多少种语言、文字，就可能有多少种文字编码方案。一种文字也可能有多种编码方案。那么我们怎么确定文本数据采用了什么编码？

1.2 采用了哪种编码？

按照惯例，文本文件中的数据都是文本编码，那么它怎么表明自己的编码格式？在记事本的“打开”对话框上：

我们可以看到记事本支持4种编码格式：ANSI、Unicode、Unicode big endian、UTF-8。如果读者看过《谈谈Unicode编码》，对Unicode、Unicode big endian、UTF-8应该不会陌生，其实它们更准确的名称应该是UTF-16LE（Little Endian）、UTF-16BE（Big Endian）和UTF-8，它们是基于Unicode的不同编码方案。

在《谈谈Unicode编码》中介绍过，Windows通过在文本文件开头增加一些特殊字节（BOM）来区分上述3种编码，并将没有BOM的文本数据按照ANSI代码页处理。那么什么是代码页，什么是ANSI代码页？

2 代码页和字符集

2.1 Windows的代码页

2.1.1 代码页

代码页（Code Page）是个古老的专业术语，据说是IBM公司首先使用的。代码页和字符集的含义基本相同，代码页规定了适用于特定地区的字符集合，和这些字符的编码。可以将代码页理解为字符和字节数据的映射表。

Windows为自己支持的代码页都编了一个号码。例如代码页936就是简体中文 GBK，代码页950就是繁体中文 Big5。代码页的概念比较简单，就是一个字符编码方案。但要说清楚Windows的ANSI代码页，就要从Windows的区域（Locale）说起了。

2.1.2 区域和ANSI代码页

微软为了适应世界上不同地区用户的文化背景和生活习惯，在Windows中设计了区域（Locale）设置的功能。Local是指特定于某个国家或地区的一组设定，包括代码页，数字、货币、时间和日期的格式等。在Windows内部，其实有两个Locale设置：系统Locale和用户Locale。系统Locale决定代码页，用户Locale决定数字、货币、时间和日期的格式。我们可以在控制面板的“区域和语言选项”中设置系统Locale和用户Locale：

每个Locale都有一个对应的代码页。Locale和代码页的对应关系，大家可以参阅我的另一篇文章《谈谈Windows程序中的字符编码》的附录1。系统Locale对应的代码页被作为Windows的默认代码页。在没有文本编码信息时，Windows按照默认代码页的编码方案解释文本数据。这个默认代码页通常被称作ANSI代码页（ACP）。

ANSI代码页还有一层意思，就是微软自己定义的代码页。在历史上，IBM的个人计算机和微软公司的操作系统曾经是PC的标准配置。微软公司将IBM公司定义的代码页称作OEM代码页，在IBM公司的代码页基础上作了些增补后，作为自己的代码页，并冠以ANSI的字样。我们在“区域和语言选项”高级页面的代码页转换表中看到的包含ANSI字样的代码页都是微软自己定义的代码页。例如：

• 874 （ANSI/OEM - 泰文）
• 932 （ANSI/OEM - 日文 Shift-JIS）
• 936 （ANSI/OEM - 简体中文 GBK）
• 949 （ANSI/OEM - 韩文）
• 950 （ANSI/OEM - 繁体中文 Big5）
• 1250 （ANSI - 中欧）
• 1251 （ANSI - 西里尔文）
• 1252 （ANSI - 拉丁文 I）
• 1253 （ANSI - 希腊文）
• 1254 （ANSI - 土耳其文）
• 1255 （ANSI - 希伯来文）
• 1256 （ANSI - 阿拉伯文）
• 1257 （ANSI - 波罗的海文）
• 1258 （ANSI/OEM - 越南）

在UniToy中，我们可以按照代码页编码顺序查看这些代码页的字符和编码：

我们不能直接设置ANSI代码页，只能通过选择系统Locale，间接改变当前的ANSI代码页。微软定义的Locale只使用自己定义的代码页。所以，我们虽然可以通过“区域和语言选项”中的代码页转换表安装很多代码页，但只能将微软的代码页作为系统默认代码页。

2.1.3 代码页转换表

在Windows 2000以后，Windows统一采用UTF-16作为内部字符编码。现在，安装一个代码页就是安装一张代码页转换表。通过代码页转换表，Windows既可以将代码页的编码转换到UTF-16，也可以将UTF-16转换到代码页的编码。代码页转换表的具体实现可以是一个以nls为后缀的数据文件，也可以是一个提供转换函数的动态链接库。有的代码页是不需要安装的。例如：Windows将UTF-7和UTF-8分别作为代码页65000和代码页65001。UTF-7、UTF-8和UTF-16都是基于Unicode的编码方案。它们之间可以通过简单的算法直接转换，不需要安装代码页转换表。

在安装过一个代码页后，Windows就知道怎样将该代码页的文本转换到Unicode文本，也知道怎样将Unicode文本转换成该代码页的文本。例如：UniToy有导入和导出功能。所谓导入功能就是将任一代码页的文本文件转换到Unicode文本；导出功能就是将Unicode文本转换到任一指定的代码页。这里所说的代码页就是指系统已安装的代码页：

其实，如果全世界人民在计算机刚发明时就统一采用Unicode作为字符编码，那么代码页就没有存在的必要了。可惜在Unicode被发明前，世界各国人民都发明并使用了各种字符编码方案。所以，Windows必须通过代码页支持已经被广泛使用的字符编码。从这种意义看，代码页主要是为了兼容现有的数据、程序和习惯而存在的。

2.1.4 SBCS、DBCS和MBCS

SBCS、DBCS和MBCS分别是单字节字符集、双字节字符集和多字节字符集的缩写。SBCS、DBCS和MBCS的最大编码长度分别是1字节、两字节和大于两字节（例如4或5字节）。例如：代码页1252 （ANSI-拉丁文 I）是单字节字符集；代码页936 （ANSI/OEM-简体中文 GBK）是双字节字符集；代码页54936 （GB18030 简体中文）是多字节字符集。

单字节字符集中的字符都用一个字节表示。显然，SBCS最多只能容纳256个字符。

双字节字符集的字符用一个或两个字节表示。那么我们从文本数据中读到一个字节时，怎么判断它是单字节字符，还是双字节字符的首字符？答案是通过字节所处范围来判断。例如：在GBK编码中，单字节字符的范围是0x00-0x80，双字节字符首字节的范围是0x81到0xFE。我们顺序读取字节数据，如果读到的字节在0x81到0xFE内，那么这个字节就是双字节字符的首字节。GBK定义双字节字符的尾字节范围是0x40到0x7E和0x80到0xFE。

GB18030是多字节字符集，它的字符可以用一个、两个或四个字节表示。这时我们又如何判断一个字节是属于单字节字符，双字节字符，还是四字节字符？GB18030与GBK是兼容的，它利用了GBK双字节字符尾字节的未使用码位。GB18030的四字节字符的第一字节的范围也是0x81到0xFE，第二字节的范围是0x30-0x39。通过第二字节所处范围就可以区分双字节字符和四字节字符。GB18030定义四字节字符的第三字节范围是0x81到0xFE，第四字节范围是0x30-0x39。

2.2 代码页实例

2.2.1 实例一：GB18030代码页

1.1节的“错误2”中演示了一个全被显示成'?'的文件。这个文件的数据是：

其实，这是一个包含了6个四字节字符的GB18030编码的文件。记事本按照GBK显示这些数据，而GB18030的四字节字符编码在GBK中是未定义的。Windows根据首字节范围判断出12个双字节字符，然后因为找不到匹配的转换而将其映射到默认字符'?'。使用UniToy按照GB18030代码页导入这个文件，就可以看到：

这个GB18030编码的文件是用UniToy创建的，编辑Unicode文本，然后导出到GB18030编码格式。

2.2.2 实例二：GBK和Big5的转换

综合使用UniToy的导入、导出功能就可以在任意两个代码页之间转换文本。其实，由于各代码页支持的字符范围不同，我们一般不会直接在代码页间转换文本。例如将以下GBK编码的文本：

直接转换到Big5编码，就会看到：

变成'?'的字符都是Big5编码不支持的简化字。在从Unicode转换到Big5编码时，由于Big5编码不支持这些字符，Windows就用默认字符'?'代替。在UniToy中，我们可以先将简体字转换到繁体字，然后再导出到Big5编码，就可以正常显示：

同理，将Big5编码的文本转换到GBK编码的步骤应该是：

• 将Big5编码的文本导入到Unicode文本；
• 将繁体的Unicode文本转换简体的Unicode文本；
• 将简体的Unicode文本导出到GBK文本。

2.3 互联网的字符集

2.3.1 字符集

互联网上的信息缤纷多彩，但文本依然是最重要的信息载体。html文件通过标记表明自己使用的字符集。例如：

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

或者：

<meta http-equiv="charset" content="iso-8859-1">

那么我们可以使用哪些字符集（charset）呢？在IETF（互联网工程任务组）的网页上维护着一份可以在互联网上使用的字符集的清单：CHARACTER SETS。如果有新的字符集被登记，IETF会更新这份文档。

简单浏览一下，2006年12月7日的版本列出了253个字符集。其中也包括微软的CP1250 ~ CP1258，在这里它们不会被称作什么ANSI代码页，而是被简单地称作windows-1250、windows-1251等。其实在Unicode被广泛使用前，除了中日韩等大字符集，世界上，特别是西方使用最广泛的字符集应该是ISO 8859系列字符集。

2.3.2 ISO 8859系列字符集

ISO 8859系列字符集是欧洲计算机制造商协会（ECMA）在上世纪80年代中期设计，并被国际标准化（ISO）组织采纳为国际标准。ISO 8859系列字符集目前有15个字符集，包括：

• ISO 8859-1 大部分的西欧语系，例如英文、法文、西班牙文和德文等（Latin-1）
• ISO 8859-2 大部分的中欧和东欧语系，例如捷克文、波兰文和匈牙利文等（Latin-2）
• ISO 8859-3 欧洲东南部和其它各种文字（Latin-3）
• ISO 8859-4 斯堪的那维亚和波罗的海语系（Latin-4）
• ISO 8859-5 拉丁文与斯拉夫文（俄文、保加利亚文等）
• ISO 8859-6 拉丁文与阿拉伯文
• ISO 8859-7 拉丁文与希腊文
• ISO 8859-8 拉丁文与希伯来文
• ISO 8859-9 为土耳其文修正的Latin-1（Latin-5）
• ISO 8859-10 拉普人、北欧与爱斯基摩人的文字（Latin-6）
• ISO 8859-11 拉丁文与泰文
• ISO 8859-13 波罗的海周边语系，例如拉脱维亚文等（Latin-7）
• ISO 8859-14 凯尔特文，例如盖尔文、威尔士文等（Latin-8）
• ISO 8859-15 改进的Latin-1，增加遗漏的法文、芬兰文字符和欧元符号（Latin-9）
• ISO 8859-16 罗马尼亚文（Latin-10）

其中缺少的编号12据说是为了预留给天城体梵文字母（Deva-nagari）的。印地文和尼泊尔文都使用了这种在七世纪形成的字母表。由于印度定义了自己的编码ISCII（Indian Script Code for Information Interchange），所以这个编号就未被使用。ISO 8859系列字符集都是单字节字符集，即只使用0x00-0xFF对字符编码。

大家都知道ASCII吧，那么大家知道ANSI X3.4和ISO 646吗？在1968年发布的ANSI X3.4和1972年发布的ISO 646就是ASCII编码，只不过是不同组织发布的。绝大多数字符集都与ASCII编码保持兼容，ISO 8859系列字符集也不例外，它们的0x00-0x7f都与ASCII码保持一致，各字符集的不同之处在于如何利用0x80-0xff的码位。使用UniToy可以查看ISO 8859系列所有字符集的编码，例如：

通过这些演示，大家是不是觉得代码页和字符集都是很简单、朴实的东西呢？好，在进入Unicode的话题前，让我们先看一个很深奥的概念。