WoW64 (Windows 32-bit On Windows 64-bit) is a subsystem of the Windows operating system that is capable of running 32-bit applications and is included on all 64-bit versions of Windows — including Windows 2000 Limited Edition, Windows XP Professional x64 Edition, IA-64 and x64 versions of Windows Server 2003, as well as 64-bit versions of Windows Vista, Windows Server 2008, and Windows 7. In Windows Server 2008 R2 Server Core, it is an optional component. WoW64 is designed to take care of many of the differences between 32-bit Windows and 64-bit Windows, particularly involving structural changes to Windows itself.

Translation libraries

The Wow64 subsystem is a lightweight compatibility layer that has similar interfaces on all 64-bit versions of Windows. Its primary purpose is to create a 32-bit environment that provides the interfaces required to allow 32-bit Windows applications to run unmodified in the 64-bit system. Technically, WoW64 is implemented using three dynamic-link libraries (DLLs): Wow64.dll, which is the core interface to the Windows NT kernel that translates between 32-bit and 64-bit calls, including pointer and call stack manipulations; Wow64win.dll, which provides the appropriate entry points for 32-bit applications; and Wow64cpu.dll, which takes care of switching the processor from 32-bit to 64-bit mode.

Architectures

Despite its outwardly similar appearance on all versions of 64-bit Windows, WoW64's implementation varies depending on the target processor architecture. For example, the version of 64-bit Windows developed for the Intel Itanium 2 processor (known at Microsoft as IA-64 architecture) uses Wow64win.dll to set up the emulation of x86 instructions within the Itanium 2's unique instruction set. This emulation is a much more computationally-expensive task than the Wow64win.dll's functions on the x86-64 architecture (alias "Intel 64" in the Intel terminology, or "AMD64" in the original AMD implementation of this 64-bit mode, also used in the architecture type name of Windows installers), which switches the processor hardware from its 64-bit mode to compatibility mode when it becomes necessary to execute a 32-bit thread, and then handles the switch back to 64-bit mode.

Registry and file system

The WoW64 subsystem also handles other key aspects of running 32-bit applications. It's involved in managing the interaction of 32-bit applications with the Windows components such as the Registry, which has distinct keys for 64-bit and 32-bit applications. For example HKEY_LOCAL_MACHINE\Software\Wow6432Node is the 32-bit equivalent of HKEY_LOCAL_MACHINE\Software (although 32-bit applications are not aware of this redirection). Some Registry keys are mapped from 64-bit to their 32-bit equivalents, while others have their contents mirrored, depending on the edition of Windows.

The operating system uses the %SystemRoot%\system32 directory for its 64-bit library and executable files. This is done for backward compatibility reasons, as many legacy applications are hardcoded to use that path. When executing 32-bit applications, WoW64 transparently redirects 32-bit DLLs to %SystemRoot%\SysWOW64, which contains 32-bit libraries and executables. 32-bit applications are generally not aware that they are running on a 64-bit operating system. 32-bit applications can access %SystemRoot%\System32 through the pseudo directory %SystemRoot%\sysnative.

There are two "Program Files" directories, both visible to both 32-bit and 64-bit applications. The directory that stores the 32 bit files is called Program Files (x86) to differentiate between the two, while the 64 bit maintains the traditional "Program Files" name without any additional qualifier.

 Incompatible applications

32-bit applications that include only 32-bit kernel-mode device drivers, or that plug into the process space of components that are implemented purely as 64-bit processes (e.g. Windows Explorer) cannot be executed on a 64-bit platform. Service applications are supported. The SysWOW64 folder located in the Windows folder on the OS drive contains several applications to support 32-bit applications (e.g. cmd.exe, useful to register 32bit windows services, odbcad32.exe, to register ODBC connections for 32-bit applications).

Internet Explorer is implemented as both a 32-bit and a 64-bit application because of the large number of 32-bit ActiveX components on the internet that would not be able to plug into the 64-bit version. The 32-bit version is used by default and the 64-bit version cannot be set to be the default browser.

A bug in the translation layer of the x64 version of WoW64^[1][2] also renders all 32-bit applications that rely on the Windows API function GetThreadContext incompatible. Such applications include application debuggers, call stack tracers (e.g. IDEs displaying call stack) and applications that use garbage collection (GC) engines. One of the more widely used but affected^[3] GC engines is the Boehm GC. It is also used as the default Garbage Collector of the equally popular Mono. While Mono has introduced a new (but optional) GC as of October 2010 called SGen-GC, it performs stack scanning in the same manner as Boehm GC, thus also making it incompatible under Wow64. No fix is planned and no workarounds have been provided by Microsoft as of 15th November 2010.

人们通常认为，Exchange Server 上必须安装 MAPI 客户端（例如 Microsoft Outlook 或 Exchange 客户端）才能创建 MAPI 配置文件；这种想法是错误的。因为此原因而安装 MAPI 客户端是不必要的，而且就 Outlook 而言，不建议您在生产服务器上安装它。只要安装有 MAPI 子系统（Exchange 中已经包含此子系统），就可以通过其他各种方法来创建 MAPI 配置文件。

1. 使用 NewProf.exe

2. 使用 ProfMan2 示例

3. 使用 MAPILogonEx

// CreateProfileWithMAPILogonEx function: This takes advantage of the 
// profile prompt dialog's "New" button.
bool CreateProfileWithMAPILogonEx()
{
    HRESULT         hRes = S_OK;        // Return code from MAPI calls.
    LPMAPISESSION   lpSession = NULL;   // MAPI Session pointer.

    // Initialize MAPI.
    if (FAILED(hRes = MAPIInitialize(NULL)))
    {
        cout<<"Error initializing MAPI. hRes = 0x"<<hex<<hRes<<dec<<endl;
        return FALSE;
    }

    // Instruct user to click the "New" button.
    cout<<"When the \"Choose Profile\" dialog appears, click the \"New\" button"
        <<"to configure a new profile."<<endl;

    // Call MAPILogonEx to display the profile chooser dialog.
    if (FAILED(hRes = MAPILogonEx(NULL,
                                  NULL,
                                  NULL,
                                  MAPI_LOGON_UI,
                                  &lpSession)))
    {
        cout<<"Error logging on. hRes = 0x"<<hex<<hRes<<dec<<endl;
        return FALSE;
    }

    // Log off the session.
    if (FAILED(hRes = lpSession->Logoff(0,0,0)))
    {
        cout<<"Error logging off. hRes = 0x"<<hex<<hRes<<dec<<endl;
    }

    // Release the session.
    lpSession->Release();

    // Uninitialize MAPI.
    MAPIUninitialize();

    // Return true to indicate success.
    return TRUE;
}
				

4. 使用 LAUNCHWIZARDENTRY 函数

// CreateProfileWithLAUNCHWIZARD function: This uses the LAUNCHWIZARDENTRY API
// to display the profile configuration UI.
bool CreateProfileWithLAUNCHWIZARD()
{
    HRESULT     hRes = S_OK;                    // Return code from MAPI calls.
    TCHAR       szProfName[80] = {0};           // String to hold profile name.
    LPTSTR      szServices[] = {"MSEMS", NULL}; // String to hold message service names.

    // Call LaunchWizard to add the MSEMS service.
    if (FAILED(hRes = LaunchWizard(NULL,
                                   NULL,
                                   (LPCTSTR *)szServices,
                                   80,
                                   szProfName)))
    {
        cout<<"Error launching wizard. hRes = 0x"<<hex<<hRes<<dec<<endl;
        return FALSE;
    }

    // Return true indicating success.
    return TRUE;
}
				

5. 使用 MAPI IProfAdmin 接口

// CreateProfileWithIProfAdmin function: This uses the MAPI IProfAdmin to 
// programmatically create a profile. No UI is displayed.
bool CreateProfileWithIProfAdmin()
{
    HRESULT         hRes = S_OK;            // Result from MAPI calls.
    LPPROFADMIN     lpProfAdmin = NULL;     // Profile Admin object.
    LPSERVICEADMIN  lpSvcAdmin = NULL;      // Service Admin object.
    LPMAPITABLE     lpMsgSvcTable = NULL;   // Table to hold services.
    LPSRowSet       lpSvcRows = NULL;       // Rowset to hold results of table query.
    SPropValue      rgval[2];               // Property structure to hold values we want to set.
    SRestriction    sres;                   // Restriction structure.
    SPropValue      SvcProps;               // Property structure for restriction.
    char            szProfile[80] = {0};    // String for profile name.
    char            szMailbox[80] = {0};    // String for mailbox name.
    char            szServer[80] = {0};     // String for server name.

    // This indicates columns we want returned from HrQueryAllRows.
    enum {iSvcName, iSvcUID, cptaSvc};
    SizedSPropTagArray(cptaSvc,sptCols) = { cptaSvc, PR_SERVICE_NAME, PR_SERVICE_UID };

    // Get configuration info from user.
    cout<<"Enter name for profile: ";
    cin>>szProfile;
    cout<<"Enter Exchange mailbox name: ";
    cin>>szMailbox;
    cout<<"Enter Exchange server name: ";
    cin>>szServer;

    // Initialize MAPI.

    if (FAILED(hRes = MAPIInitialize(NULL)))
    {
        cout<<"Error initializing MAPI.";
        goto error;
    }

    // Get an IProfAdmin interface.

    if (FAILED(hRes = MAPIAdminProfiles(0,              // Flags.
                                        &lpProfAdmin))) // Pointer to new IProfAdmin.
    {
        cout<<"Error getting IProfAdmin interface.";
        goto error;
    }

    // Create a new profile.

    if (FAILED(hRes = lpProfAdmin->CreateProfile(szProfile,     // Name of new profile.
                                                 NULL,          // Password for profile.
                                                 NULL,          // Handle to parent window.
                                                 NULL)))        // Flags.
    {
        cout<<"Error creating profile.";
        goto error;
    }

    // Get an IMsgServiceAdmin interface off of the IProfAdmin interface.

    if (FAILED(hRes = lpProfAdmin->AdminServices(szProfile,     // Profile that we want to modify.
                                                 NULL,          // Password for that profile.
                                                 NULL,          // Handle to parent window.
                                                 0,             // Flags.
                                                 &lpSvcAdmin))) // Pointer to new IMsgServiceAdmin.
    {
        cout<<"Error getting IMsgServiceAdmin interface.";
        goto error;
    }

    // Create the new message service for Exchange.

    if (FAILED(hRes = lpSvcAdmin->CreateMsgService("MSEMS",     // Name of service from MAPISVC.INF.
                                                   NULL,        // Display name of service.
                                                   NULL,        // Handle to parent window.
                                                   NULL)))      // Flags.
    {
        cout<<"Error creating Exchange message service.";
        goto error;
    }
        
    // We now need to get the entry id for the new service.
    // This can be done by getting the message service table
    // and getting the entry that corresponds to the new service.

    if (FAILED(hRes = lpSvcAdmin->GetMsgServiceTable(0,                 // Flags.
                                                     &lpMsgSvcTable)))  // Pointer to table.
    {
        cout<<"Error getting Message Service Table.";
        goto error;
    }

    // Set up restriction to query table.

    sres.rt = RES_CONTENT;
    sres.res.resContent.ulFuzzyLevel = FL_FULLSTRING;
    sres.res.resContent.ulPropTag = PR_SERVICE_NAME;
    sres.res.resContent.lpProp = &SvcProps;

    SvcProps.ulPropTag = PR_SERVICE_NAME;
    SvcProps.Value.lpszA = "MSEMS";

    // Query the table to get the entry for the newly created message service.

    if (FAILED(hRes = HrQueryAllRows(lpMsgSvcTable,
                                     (LPSPropTagArray)&sptCols,
                                     &sres,
                                     NULL,
                                     0,
                                     &lpSvcRows)))
    {
        cout<<"Error querying table for new message service.";
        goto error;
    }

    // Setup a SPropValue array for the properties you need to configure.

    // First, the server name.
    ZeroMemory(&rgval[1], sizeof(SPropValue) );
    rgval[1].ulPropTag = PR_PROFILE_UNRESOLVED_SERVER;
    rgval[1].Value.lpszA = szServer;

    // Next, the mailbox name.
    ZeroMemory(&rgval[0], sizeof(SPropValue) );
    rgval[0].ulPropTag = PR_PROFILE_UNRESOLVED_NAME; 
    rgval[0].Value.lpszA = szMailbox;

    // Configure the message service with the above properties.

        if (FAILED(hRes = lpSvcAdmin->ConfigureMsgService(
        (LPMAPIUID)lpSvcRows->aRow->lpProps[iSvcUID].Value.bin.lpb, // Entry ID of service to configure.
        NULL,                                                       // Handle to parent window.
        0,                                                          // Flags.
        2,                                                          // Number of properties we are setting.
        rgval)))                                                    // Pointer to SPropValue array.
    {
        cout<<"Error configuring message service.";
        goto error;
    }

    goto cleanup;

error:
    cout<<" hRes = 0x"<<hex<<hRes<<dec<<endl;
    return FALSE;

cleanup:
    // Clean up.
    if (lpSvcRows) FreeProws(lpSvcRows);
    if (lpMsgSvcTable) lpMsgSvcTable->Release();
    if (lpSvcAdmin) lpSvcAdmin->Release();
    if (lpProfAdmin) lpProfAdmin->Release();

    MAPIUninitialize();
    return TRUE;

}
				

Hi,

I have my projects in VS 2008 SP1 and is using .NET 3.5 SP1. Till now we are developing application in Any CPU platform setting for all the projects and supported only 32-bit platforms. Now we are going to support 64-bit OS platforms as well.

Q-1. What difference it makes by building solution for Any CPU, x86 and x64 platform?

Q-2. Will it make any difference if I build my application using Any CPU platform setting and run on x64 platform?

Q-3. What are the advantages of creating different builds for x86 and x64? Any performance gain? anything considerable change?

Q-4. I have my VC++ dll library which is imported in one of my C# project as well. What changes are required in that VC++ dll to make it running on both x86 and x64?

Appreciate your inputs.

For Q1-Q3:

AnyCPU will compile your assembly to run on any platform. DLLs and EXEs compiled with AnyCPU option will behave with sutle difference. On a 64-bit Windows operating system, EXEs compiled with this option will execute on the 64 bit CLR, while DLLs compiled with this option will execute on the same CLR as the process into which it is being loaded. So, if a 32bit EXE load a DLL that is compiled with this option, the process is 32bit so the DLL will run on the 32bit CLR.

x86 option compiles your assembly to be run by the 32-bit, x86-compatible common language runtime. On 32bit platform, the EXEs will run as 32bit process. On 64bit platform, the EXEs will run under WOW64 mode.

x64 option compiles your assembly to be run by the 64-bit common language runtime on a computer that supports the AMD64 or EM64T instruction set.

Also please take a look at: How to: Optimize an Application for a Specific CPU Type

For Q4:

Please take a look at : How do exes/dlls generated with the /platform:x switch interact?

I received a question about this recently, so i figured i'd elaborate here with a little example...

Let's assume we have the following three dlls:

   anycpu.dll      -- compiled "any cpu"

   x86.dll           -- compiled "x86"

   x64.dll           -- compiled "x64"

And the following three exes:

   anycpu.exe     -- compiled "any cpu"

   x86.exe          -- compiled "x86"

   x64.exe          -- compiled "x64"

What happens if you try to use these exes and dlls together? We have to consider two possible scenarios, running on a 32-bit machine and running on a 64-bit machine...

On a 32-bit x86 machine:

anycpu.exe -- runs as a 32-bit process, can load anycpu.dll and x86.dll, will get BadImageFormatException if it tries to load x64.dll

x86.exe -- runs as a 32-bit process, can load anycpu.dll and x86.dll, will get BadImageFormatException if it tries to load x64.dll

x64.exe -- will get BadImageFormatException when it tries to run

On a 64-bit x64 machine:

anycpu.exe -- runs as a 64-bit process, can load anycpu.dll and x64.dll, will get BadImageFormatException if it tries to load x86.dll

x86.exe -- runs as a 32-bit process, can load anycpu.dll and x86.dll, will get BadImageFormatException if it tries to load x64.dll

x64.exe -- runs as a 64-bit process, can load anycpu.dll and x64.dll, will get BadImageFormatException if it tries to load x86.dll

/platform (Specify Output Platform) (C# Compiler Options) 

Copy

/platform:string

Parameters

string

x86, Itanium, x64, or anycpu (default).

Remarks

---

• x86 compiles your assembly to be run by the 32-bit, x86-compatible common language runtime.

• Itanium compiles your assembly to be run by the 64-bit common language runtime on a computer with an Itanium processor.

• x64 compiles your assembly to be run by the 64-bit common language runtime on a computer that supports the AMD64 or EM64T instruction set.

• anycpu (default) compiles your assembly to run on any platform.

On a 64-bit Windows operating system:

• Assemblies compiled with /platform:x86 will execute on the 32 bit CLR running under WOW64.

• Executables compiled with the /platform:anycpu will execute on the 64 bit CLR.

• DLLs compiled with the /platform:anycpu will execute on the same CLR as the process into which it is being loaded.

For more information about developing an application to run on a Windows 64-bit operating system, see 64-bit Applications.

To set this compiler option in the Visual Studio development environment

1. Open the Properties page for the project. For details, see How to: Set Project Properties (C#, J#).

2. Click the Build property page.

3. Modify the Platform target property.

Note   /platform is not available in the development environment in Visual C# Express.

For information on how to set this compiler option programmatically, see PlatformTarget.

Example

---

The following example shows how to use the /platform option to specify that the application should only be run by the 64-bit CLR on a 64-bit Windows operating system for Itanium.

Copy

csc /platform:Itanium myItanium.cs

1        预备知识—程序的内存分配
一个由c/C++编译的程序占用的内存分为以下几个部分

u       1、栈区（stack）—   由编译器自动分配释放 (由编译器在需要的时候分配，在不需要的时候自动清除) 。存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。

u       2、堆区（heap） —   一般由程序员分配释放（由new分配的内存块，他们的释放编译器不去管，由我们的应用程序去控制，一般一个new就要对应一个delete）(c中用malloc，c++中用new)， 若程序员不释放，程序结束时可能由OS回收 。注意它与数据结构中的堆是两回事，分配方式倒是类似于链表，呵呵。

u       自由存储区，就是那些由malloc等分配的内存块，他和堆是十分相似的，不过它是用free来结束自己的生命的。

u       3、全局区（静态区）（static）—，全局变量和静态变量的存储是放在一块的，初始化的全局变量和静态变量在一块区域， 未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。在C++里面没有这个区分了，他们共同占用同一块内存区。 - 程序结束后有系统释放

u       4、文字常量区  —常量字符串就是放在这里的，不允许修改。 程序结束后由系统释放

u       5、程序代码区—存放函数体的二进制代码。 

l        更改堆栈大小的设置：

在VC6下面，默认的栈空间大小是1M（好像是，记不清楚了）。当然，我们可以修改：

    打开工程，依次操作菜单如下：Project->Setting->Link，在Category 中选中Output，然后在Reserve中设定堆栈的最大值和commit。

注意：reserve最小值为4Byte；commit是保留在虚拟内存的页文件里面，它设置的较大会使栈开辟较大的值，可能增加内存的开销和启动时间。

1.1          例子程序
这是一个前辈写的，非常详细

//main.cpp

int a = 0; 全局初始化区

char *p1; 全局未初始化区

main()

{

int b; 栈

char s[] = "abc"; 栈

char *p2; 栈

char *p3 = "123456"; 123456\0在常量区，p3在栈上。

static int c =0； 全局（静态）初始化区

p1 = (char *)malloc(10);

p2 = (char *)malloc(20);

分配得来得10和20字节的区域就在堆区。

strcpy(p1, "123456"); 123456\0放在常量区，编译器可能会将它与p3所指向的"123456"优化成一个地方。

}

2        堆和栈的理论知识
2.1      申请方式
stack:

由系统自动分配。 例如，声明在函数中一个局部变量 int b; 系统自动在栈中为b开辟空间

heap:

需要程序员自己申请，并指明大小，在c中malloc函数

如p1 = (char *)malloc(10);

在C++中用new运算符

如p2 = (char *)malloc(10);

但是注意p1、p2本身是在栈中的。

2.2      申请后系统的响应
栈

只要栈的剩余空间大于所申请空间，系统将为程序提供内存，否则将报异常提示栈溢出。

堆

首先应该知道操作系统有一个记录空闲内存地址的链表，当系统收到程序的申请时，

会遍历该链表，寻找第一个空间大于所申请空间的堆结点，然后将该结点从空闲结点链表中删除，并将该结点的空间分配给程序，另外，对于大多数系统，会在这块内存空间中的首地址处记录本次分配的大小，这样，代码中的delete语句才能正确的释放本内存空间。另外，由于找到的堆结点的大小不一定正好等于申请的大小，系统会自动的将多余的那部分重新放入空闲链表中。

2.3      申请大小的限制
栈

在Windows下,栈是向低地址扩展的数据结构，是一块连续的内存的区域。这句话的意思是栈顶的地址和栈的最大容量是系统预先规定好的，在WINDOWS下，栈的大小是2M（也有的说是1M，总之是一个编译时就确定的常数），如果申请的空间超过栈的剩余空间时，将提示overflow。因此，能从栈获得的空间较小。

堆

堆是向高地址扩展的数据结构，是不连续的内存区域。这是由于系统是用链表来存储的空闲内存地址的，自然是不连续的，而链表的遍历方向是由低地址向高地址。堆的大小受限于计算机系统中有效的虚拟内存。由此可见，堆获得的空间比较灵活，也比较大。

2.4      申请效率的比较：
栈由系统自动分配，速度较快。但程序员是无法控制的。

堆是由new分配的内存，一般速度比较慢，而且容易产生内存碎片,不过用起来最方便.

另外，在WINDOWS下，最好的方式是用VirtualAlloc分配内存，他不是在堆，也不是在栈是直接在进程的地址空间中保留一快内存，虽然用起来最不方便。但是速度快，也最灵活。

2.5      堆和栈中的存储内容
栈： 在函数调用时，第一个进栈的是主函数中后的下一条指令（函数调用语句的下一条可执行语句）的地址，然后是函数的各个参数，在大多数的C编译器中，参数是由右往左入栈的，然后是函数中的局部变量。注意静态变量是不入栈的。

当本次函数调用结束后，局部变量先出栈，然后是参数，最后栈顶指针指向最开始存的地址，也就是主函数中的下一条指令，程序由该点继续运行。

堆：一般是在堆的头部用一个字节存放堆的大小。堆中的具体内容有程序员安排。

2.6      存取效率的比较
char s1[] = "aaaaaaaaaaaaaaa";

char *s2 = "bbbbbbbbbbbbbbbbb";

aaaaaaaaaaa是在运行时刻赋值的；

而bbbbbbbbbbb是在编译时就确定的；

但是，在以后的存取中，在栈上的数组比指针所指向的字符串(例如堆)快。

比如：

#include

void main()

{

char a = 1;

char c[] = "1234567890";

char *p ="1234567890";

a = c[1];

a = p[1];

return;

}

对应的汇编代码

10: a = c[1];

00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh]

0040106A 88 4D FC mov byte ptr [ebp-4],cl

11: a = p[1];

0040106D 8B 55 EC mov edx,dword ptr [ebp-14h]

00401070 8A 42 01 mov al,byte ptr [edx+1]

00401073 88 45 FC mov byte ptr [ebp-4],al

第一种在读取时直接就把字符串中的元素读到寄存器cl中，而第二种则要先把指针值读到edx中，在根据edx读取字符，显然慢了。

2.7      小结：
堆和栈的区别可以用如下的比喻来看出：

使用栈就象我们去饭馆里吃饭，只管点菜（发出申请）、付钱、和吃（使用），吃饱了就走，不必理会切菜、洗菜等准备工作和洗碗、刷锅等扫尾工作，他的好处是快捷，但是自由度小。

使用堆就象是自己动手做喜欢吃的菜肴，比较麻烦，但是比较符合自己的口味，而且自由度大

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/douzixinxin/archive/2006/02/23/606942.aspx

• 摘要：本文将谈到Visual C# 2010中的新特性—协变和逆变。随着Visual Studio 2010 Beta1的发布，更多的新功能期待大家的试用。

1. 协变和逆变
开发时经常与到以下的问题,首先看代码:
定义一个水果类和继承了该类的苹果类：

public class Fruit
{
public string Name { get; set; }
}
public class Apple : Fruit
{
}

有一个方法接收一个元素类型为Fruit的泛型集合，如下所示：

static void Output(List fruits)
{
foreach (Fruit f in fruits)
Console.WriteLine(f.Name);
}

由于Apple类继承自Fruit，所以很自然的认为以下代码“应该”能够正常运行：

static void Main(string[] args)
{
List apples = new List();
Output(apples);
Console.ReadLine();
}

但实际上在.NET Framework 4.0以前的版本中这段代码不能通过编译。还有另外一种相似的情况，在Windows窗体应用程序中鼠标点击事件和键盘按键事件拥有不同类型的事件参数MouseEventArgs和KeyPressEventArgs，这两个类均继承自EventArgs，如果希望在这两件事件触发时执行相同的操作，期望编写以下“通用”的事件处理程序附加到两个事件上是行不通的：

private void Form1_UserAction(object sender, EventArgs e)
{
}

只能须创建两个单独的事件处理程序来执行操作。
Visual C# 2010 中引入的协变和逆变解决了类似于这样的问题。
在泛型接口和委托中协变（covariance）可以使用泛型参数所定义类型的继承类型，逆变（contravariance）用于使用更一般的类型。一个泛型接口或委托的泛型参数被声明为协变或逆变时该接口或委托称为变体。在.NET Framework 4和Visual Studio 2010中，C#和Visual Basic均支持变体泛型接口和委托，并且允许泛型参数的隐式转换，而且这两种语言都允许创建自定义变体接口和委托。变体只支持引用类型，值类型不支持变体。
使用协变，第一个问题可以解决，这些代码在Visual Studio 2010中能够正确编译并运行。使用逆变可以解决第二个问题，这时事件处理程序使用了“更一般”的类型（该事件的委托允许使用更一般的类型）。
2. 接口中的变体
在.NET Framework 4中对一些已存在的泛型接口引入了变体支持，这支持实现了这些接口的类的隐式转换。这些接口是：

IEnumberable
IEnumerator
IQueryable
IGrouping
IComparer
IEqualityComparer
IComparable

开发人员还可以在泛型类型参数上使用in和out关键字以声明变体泛型接口。
2.1 使用out关键字声明协变泛型参数，例如以下代码：

interface IFileCollection
{
}

但是该变体类型T必须遵守以下规则：
1. 该类型不能作为方法参数而只能作为返回类型。

interface IFileCollection
{
T IndexOf(int i);
}

2. 第一个规则有一个特殊情况是当方法参数是逆变泛型委托时可以将该类型作为该委托的泛型类型参数。

interface IFileCollection
{
void Delete(Action file);
}

3. 该类型不能作为接口方法中泛型类型的约束，例如以下代码是错误的

interface IFileCollection
{
void Display where R : T;
}

2.2. 使用in关键字声明逆变泛型参数。逆变类型仅能用于方法的参数和泛型类型约束而不能作为返回类型。

interface IOperator
{
void Increace(T value);
void Double() where R : T;
}

2.3. 可以在一个接口中同时使用out和in定义协变和逆变，但仍需遵守相应规则。
2.4. 实现变体接口时语法与普通接口语法一致，但实现了变体接口的类不在是变体的。如果某个接口继承自变体接口，根据需要使用in或out来指定子接口是否仍然为变体类型。如果某个接口同时继承了变体接口和非变体接口，那么该接口为非变体类型，并且不能从逆变接口继承为协变接口。
3. 委托中的变体
.NET Framework 4 中为某些已存在的泛型委托引入变体支持，这些支持在使用委托类型匹配方法签名时提供了很大的灵活性，这些委托是：
System命名空间下的Action委托，例如Action和Action
System命名空间下的Func委托，例如Func和Func
Predicate委托
Comparison委托
EventHandler委托（正是由于该委托的存在解决了我们的第2个问题）
Converter委托。
同样可以使用out和in关键字定义协变和逆变泛型参数，仍然需要遵守在接口中定义时相应的规则。定义完成之后使用原来的委托访问语法实例化和调用委托即可
4. 总结
Visual C# 2010中新提供了协变和逆变的新特性，一个泛型接口或委托的泛型参数被声明为协变或逆变时该接口或委托称为变体，这为我们解决类似于开篇中的两类问题带来了便利。.NET Framework 4中已为现有的一些接口和委托增加了变体支持，并且开发人员可以使用in和out关键字定义自己的变体接口和委托，但在定义时需要遵守相应的规则。

51CTO.com曾经报道过讲解C# 4.0中的动态类型和动态编程的文章，也曾对C# 4.0动态编程技巧做过一些演示。但依然有读者不太了解dynamic到底有那些作用。本文摘选博主“胡里胡涂”的一篇文章，针对作者提出的两个问题对dynamic进行理解。
◆写程序时少了智能感知
◆运行程序时速度变慢(反射)
看完New features in CSharp 4.docx才恍然明白，趁着没事，把东西整理一下，希望能对暂时还不明白dynamic有什么用的朋友提供一些参考。当然，由于本人才疏学浅，不保证所有的观点都是正确的，希望大家用辩证的眼光来看这篇文章，如有错误之处，请大伙批评指正。
言归正传，dynamic关键字用于声明一个动态对象，然后通过该动态对象去调用方法或读写属性。
在使用C# 2.0或3.0的时候，如果一个对象需要在运行时才能确定，并且没有接口和基类方面的信息，那我们一般使用反射技术来调用这个未知对像的方法或属性，而C# 4.0提供的dynamic可以帮我们简化这些工作。假设我们的程序会在运行时取得一个不确定类型的对象，但这个对象一定会有个Print()方法，我们需要调用这个方法打印出一些信息，那么在C# 4.0下面，我们可以用下面的两句代码来实现这个需求。
dynamic unknowObj = GetDymanicObject();unknowObj.Print();  //调用动态对象的某个方法
这种解决方式比起用反射调用Print方法，应该简洁很多吧？程序员要做的就是别把方法名Print()打错，VS2010是不会为dynamic对象提供智能提示的，因为VS不知道运行时这个unknowObj会是什么东东……
到这里，应该有不少的朋友可以从这个例子上看出，当程序编译到unknowObj.Print()的时候，VS会帮我们生成反射的代码，用反射的方式去调用Print这个方法，实质上就是帮我们自动反射了。
如果能理解这一点，那也就不难理解C#为啥要搞dynamic这个既没智能感知，运行又慢的怪物出来了。
按New features in CSharp 4的说法，dymanic主要应用于下面的场景：
1、自动反射
2、COM组件互操作
3、混合编程，例如IronRuby和IronPython
4、处理Html DOM对象
如果有处理过上面这些工作的朋友们，应该不难理解了吧。
具体的内容，还请大伙自己看看New features in CSharp 4，里面说得比较详细。

【编辑推荐】

1. 浅谈C# 4.0中的动态类型和动态编程
2. C# 4.0中的动态类型与编程技巧

Forrester的高级分析师Dave West认为，测试驱动开发（TDD）就像是“圣杯”，但是“如果能达到这个目标，付出再多的辛苦也是值得的。”
    在企业向敏捷转型的各种实践中，TDD通常是最艰难的一个。
    这对美国犹他州Midvale的IBM软件组来说是确确实实的体验。他们从2007年就开始向敏捷转型。IBM开发转型部门副总裁Sue Mckinney认为，测试驱动开发前景非常诱人，但是“在这个过程中我们的付出可能也是最多的。”
    Mckinney说：“虽然我们做了大量的自动单元测试和功能测试，集成测试也做得越来越好，但是这毕竟是一种意识问题。开发人员喜欢编写代码，他们一点儿也不喜欢做测试。”
    她又补充道，但这是他们必须经历的一段旅程，“我们通过兼并获得一些优秀的设计师，他们在TDD方面有很不错的经验，值得我们效仿。我们请他们将经验和大家分享。这将是我们2009年的重点工作——让我们的团队学习TDD。”
    TDD根源于极限编程（XP），通常指开发人员在编写代码之前创建用于对代码进行自动单元测试的实践。Kirk Knoernschild是Burton集团的一位分析师。他列举了这个过程中所面临的挑战：“如果单元太大就很难写出高质量的测试。并且，虽然许多组织都说他们的开发人员在写单元测试，但是实际上他们也不知道自己的代码覆盖率有多高。还有许多组织仍然会把测试阶段推迟到软件周期的后期，这无疑会使问题变得更严重。”
    旧代码也会产生问题。据AMS Services的首席架构师Chris Kinsman说，虽然AMS已经提高了对代码的单元测试和集成测试的力度，但是他们并没有做太多TDD方面的工作。“我们现在有大量的非TDD代码。旧代码几乎没有测试驱动的。”Chris表示，“部分团队做过TDD方面的短期努力，但那不等于在全部团队都采用了这个实践。”
    他认为，AMS不一定会把TDD作为目标，“我担心我们的代码基础可能不支持这么做。在走这一步之前，我们还要先解决一些架构上的问题。我并不是从理论上反对这么做，我只是不想把我们当前的工作弄得更辛苦而已。”
    Knoernschild认为，测试驱动开发所面临的另一难题是它给人一种会减缓开发团队速度的感觉。复式记账法就是一个很好的类比。如果会计不使用复式记账法，那么他的工作会快很多。但是这样的结果就是一旦出错他无法（轻松地）使用制约系统进行检查。测试也是如此。一旦出现了问题，你会发现你缺少相应的制约系统来检查并确定问题的根源所在。
    虽然TDD确实会减缓工作速度，但是长远看来，“随着代码的增长，它实际上是会提高速度的。”
    Forrester的分析师West认为，这是一种文化上的转变，“以前的软件工程师在拿不定主意的时候会写许多文件，但是这些文件都没有说到痛处。因为这时候没有让你战胜这个问题的环境，缺少的是一种氛围。”
    West还说道，开发人员在写测试之前可能需要先研究一些东西，“并不是说你不喜欢这种方式，而是在你写出一部分编码、了解到一个大概之前，你无法真正地明白问题，也就无法写出测试来。而在敏捷所提倡的探索性过程中，你可以更好地了解问题所在，相应地也就会更习惯于这种做法。”
    West认为，测试资源按部门划分的方法也是一个障碍，“某些供应商要为此负责，因为他们鼓励卓越中心的做法——即专门负责QA的部门。这使得很难从早期就开始QA方面的工作，所以你只能在没有QA的情况做敏捷工作。你确实会做单元测试，但是你把它和其它工作分开了，因为它们属于不同的部门。”
    网络内容管理公司Vignette已经开始接受TDD，但也只是刚开始。其工程部主任Subu Subramanian说，“如果团队考虑了需求描述和验收标准，他们会把这些详细地写到测试里，这样他们在进行设计和开发的时候就会同时考虑测试。”他表示，Vignette的最终目标是把测试带入到开发周期的早期阶段。
    虽然这不是敏捷的一部分，却可以为测试驱动开发带来意想不到的效果。他说，“虽然TDD通常会和敏捷开发联系在一起，也是敏捷实践的一种，但是即使你没有把全部精力都投入到敏捷当中，TDD的价值也是显而易见的。从你写下第一行代码的时候，你就可以把测试带入开发周期。你可以在编写代码的同时生成相应的测试集。”
    他还补充说，“如何执行TDD取决于你的企业结构。你必须根据实际情况做决定。比如可以是一种两人工作的模式，一人写测试，一人写代码。”
    不管TDD将来如何发展，各企业都需要“尽可能地在早期阶段把尽量多的精力放到质量与测试当中”。

UNICODE：它是用两个字节表示一个字符的方法。比如字符'A'在ASCII下面是一个字符，可'A'在UNICODE下面是两个字符,高字符用0填充，而且汉字'程'在ASCII下面是两个字节，而在UNICODE下仍旧是两个字节。UNICODE的用处就是定长表示世界文字，据统计，用两个字节可以编码现存的所有文字而没有二义。   MBCS，它是多字节字符集，它是不定长表示世界文字的编码。MBCS表示英文字母时就和ASCII一样（这也是我们容易把MBCS和ASCII搞混的原因），但表示其他文字时就需要用多字节。   WINDOWS下面的程序设计可以支持MBCS和UNICODE两种编码的字符串，具体用那种就看你定义了MBCS宏还是UNICODE宏。MBCS宏对应的字符串指针是char*也就是LPSTR，UNICODE对应的指针是unsigned   short*也就是LPWSTR，为了写程序方便微软定义了类型LPTSTR，在MBCS下他就是char*,   在UNICODE下它是unsigned   char*,这样你就可以重定义一个宏进行不同字符集的转换了。 LPTSTR、LPCSTR、LPCTSTR、LPSTR的意义：

LPSTR：32bit指针 指向一个字符串，每个字符占1字节

LPCSTR:32-bit指针 指向一个常字符串，每个字符占1字节
LPCTSTR:32-bit指针 指向一个常字符串,每字符可能占1字节或2字节，取决于Unicode是否定义
LPTSTR:32-bit指针 每字符可能占1字节或2字节，取决于Unicode是否定义

Windows使用两种字符集ANSI和UNICODE，前者就是通常使用的单字节方式，但这种方式处理象中文这样的双字节字符不方便，容易出现半个汉字的情况。而后者是双字节方式，方便处理双字节字符。WindowsNT的所有与字符有关的函数都提供两种方式的版本，而Windows9x只支持ANSI方式。_T一般同字常数相关，如_T("Hello"。如果你编译一个程序为ANSI方式，_T实际不起任何作用。而如果编译一个程序为UNICODE方式，则编译器会把"Hello"字符串以UNICODE方式保存。_T和_L的区别在于，_L不管你是以什么方式编译，一律以UNICODE方式保存.

 Windows核心编程的第一章。

L是表示字符串资源为Unicode的。

比如
wchar_t Str[] = L"Hello World!";
这个就是双子节存储字符了。

_T是一个适配的宏～

当
#ifdef _UNICODE的时候
_T就是L
没有#ifdef _UNICODE的时候
_T就是ANSI的。

比如

LPTSTR lpStr = new TCHAR[32];
TCHAR* szBuf = _T("Hello");
以上两句使得无论是在UNICODE编译条件下都是正确编译的。

而且MS推荐你使用相匹配的字符串函数。
比如处理LPTSTR或者LPCTSTR 的时候，不要用strlen ,而是要用_tcslen

否则在UNICODE的编译条件下，strlen不能处理 wchar_t*的字符串。

T是非常有意思的一个符号（TCHAR、LPCTSTR、LPTSTR、_T()、_TEXT()...），它表示使用一种中间类型，既不明确表示使用 MBCS，也不明确表示使用 UNICODE。那到底使用哪种字符集?编译的时候才决定

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/douzixinxin/archive/2006/07/03/869937.aspx

 [原创文章，转载请保留或注明出处：http://www.regexlab.com/zh/encoding.htm]

级别：中级

摘要：本文介绍了字符与编码的发展过程，相关概念的正确理解。举例说明了一些实际应用中，编码的实现方法。然后，本文讲述了通常对字符与编码的几种误解，由于这些误解而导致乱码产生的原因，以及消除乱码的办法。本文的内容涵盖了“中文问题”，“乱码问题”。

掌握编码问题的关键是正确地理解相关概念，编码所涉及的技术其实是很简单的。因此，阅读本文时需要慢读多想，多思考。

引言

“字符与编码”是一个被经常讨论的话题。即使这样，时常出现的乱码仍然困扰着大家。虽然我们有很多的办法可以用来消除乱码，但我们并不一定理解这些办法的内在原理。而有的乱码产生的原因，实际上由于底层代码本身有问题所导致的。因此，不仅是初学者会对字符编码感到模糊，有的底层开发人员同样对字符编码缺乏准确的理解。

回页首

1. 编码问题的由来，相关概念的理解

1.1 字符与编码的发展

从计算机对多国语言的支持角度看，大致可以分为三个阶段：

字符串在内存中的存放方法：

在 ASCII 阶段，单字节字符串使用一个字节存放一个字符（SBCS）。比如，"Bob123" 在内存中为：

42	6F	62	31	32	33	00
B	o	b	1	2	3	\0

在使用 ANSI 编码支持多种语言阶段，每个字符使用一个字节或多个字节来表示（MBCS），因此，这种方式存放的字符也被称作多字节字符。比如，"中文123" 在中文 Windows 95 内存中为7个字节，每个汉字占2个字节，每个英文和数字字符占1个字节：

D6	D0	CE	C4	31	32	33	00
中		文		1	2	3	\0

在 UNICODE 被采用之后，计算机存放字符串时，改为存放每个字符在 UNICODE 字符集中的序号。目前计算机一般使用 2 个字节（16 位）来存放一个序号（DBCS），因此，这种方式存放的字符也被称作宽字节字符。比如，字符串 "中文123" 在 Windows 2000 下，内存中实际存放的是 5 个序号：

2D	4E	87	65	31	00	32	00	33	00	00	00	← 在 x86 CPU 中，低字节在前
中		文		1		2		3		\0

一共占 10 个字节。

回页首

1.2 字符，字节，字符串

理解编码的关键，是要把字符的概念和字节的概念理解准确。这两个概念容易混淆，我们在此做一下区分：

由于不同 ANSI 编码所规定的标准是不相同的，因此，对于一个给定的多字节字符串，我们必须知道它采用的是哪一种编码规则，才能够知道它包含了哪些“字符”。而对于 UNICODE 字符串来说，不管在什么环境下，它所代表的“字符”内容总是不变的。

回页首

1.3 字符集与编码

各个国家和地区所制定的不同 ANSI 编码标准中，都只规定了各自语言所需的“字符”。比如：汉字标准（GB2312）中没有规定韩国语字符怎样存储。这些 ANSI 编码标准所规定的内容包含两层含义：

1. 使用哪些字符。也就是说哪些汉字，字母和符号会被收入标准中。所包含“字符”的集合就叫做“字符集”。
2. 规定每个“字符”分别用一个字节还是多个字节存储，用哪些字节来存储，这个规定就叫做“编码”。

各个国家和地区在制定编码标准的时候，“字符的集合”和“编码”一般都是同时制定的。因此，平常我们所说的“字符集”，比如：GB2312, GBK, JIS 等，除了有“字符的集合”这层含义外，同时也包含了“编码”的含义。

“UNICODE 字符集”包含了各种语言中使用到的所有“字符”。用来给 UNICODE 字符集编码的标准有很多种，比如：UTF-8, UTF-7, UTF-16, UnicodeLittle, UnicodeBig 等。

回页首

1.4 常用的编码简介

简单介绍一下常用的编码规则，为后边的章节做一个准备。在这里，我们根据编码规则的特点，把所有的编码分成三类：

我们实际上没有必要去深究每一种编码具体把某一个字符编码成了哪几个字节，我们只需要知道“编码”的概念就是把“字符”转化成“字节”就可以了。对于“UNICODE 编码”，由于它们是可以通过计算得到的，因此，在特殊的场合，我们可以去了解某一种“UNICODE 编码”是怎样的规则。

回页首

2. 字符与编码在程序中的实现

2.1 程序中的字符与字节

在 C++ 和 Java 中，用来代表“字符”和“字节”的数据类型，以及进行编码的方法：

以上需要注意几点：

1. Java 中的 char 代表一个“UNICODE 字符（宽字节字符）”，而 C++ 中的 char 代表一个字节。
2. MultiByteToWideChar() 和 WideCharToMultiByte() 是 Windows API 函数。

回页首

2.2 C++ 中相关实现方法

声明一段字符串常量：

UNICODE 字符串的 I/O 操作，字符与字节的转换操作：

在 Visual C++ 中，UNICODE 字符串常量有更简单的表示方法。如果源程序的编码与当前默认 ANSI 编码不符，则需要使用 #pragma setlocale，告诉编译器源程序使用的编码：

以上需要注意 #pragma setlocale 与 setlocale(LC_ALL, "") 的作用是不同的，#pragma setlocale 在编译时起作用，setlocale() 在运行时起作用。

回页首

2.3 Java 中相关实现方法

字符串类 String 中的内容是 UNICODE 字符串：

字符串 I/O 操作，字符与字节转换操作。在 Java 包 java.io.* 中，以“Stream”结尾的类一般是用来操作“字节串”的类，以“Reader”，“Writer”结尾的类一般是用来操作“字符串”的类。

如果 java 的源程序编码与当前默认 ANSI 编码不符，则在编译的时候，需要指明一下源程序的编码。比如：

以上需要注意区分源程序的编码与 I/O 操作的编码，前者是在编译时起作用，后者是在运行时起作用。

回页首

3. 几种误解，以及乱码产生的原因和解决办法

3.1 容易产生的误解

第一种误解，往往是导致乱码产生的原因。第二种误解，往往导致本来容易纠正的乱码问题变得更复杂。

在这里，我们可以看到，其中所讲的“误解一”，即采用每“一个字节”就是“一个字符”的转化方法，实际上也就等同于采用 iso-8859-1 进行转化。因此，我们常常使用 bytes = string.getBytes("iso-8859-1") 来进行逆向操作，得到原始的“字节串”。然后再使用正确的 ANSI 编码，比如 string = new String(bytes, "GB2312")，来得到正确的“UNICODE 字符串”。

回页首

3.2 非 UNICODE 程序在不同语言环境间移植时的乱码

非 UNICODE 程序中的字符串，都是以某种 ANSI 编码形式存在的。如果程序运行时的语言环境与开发时的语言环境不同，将会导致 ANSI 字符串的显示失败。

比如，在日文环境下开发的非 UNICODE 的日文程序界面，拿到中文环境下运行时，界面上将显示乱码。如果这个日文程序界面改为采用 UNICODE 来记录字符串，那么当在中文环境下运行时，界面上将可以显示正常的日文。

由于客观原因，有时候我们必须在中文操作系统下运行非 UNICODE 的日文软件，这时我们可以采用一些工具，比如，南极星，AppLocale 等，暂时的模拟不同的语言环境。

回页首

3.3 网页提交字符串

当页面中的表单提交字符串时，首先把字符串按照当前页面的编码，转化成字节串。然后再将每个字节转化成 "%XX" 的格式提交到 Web 服务器。比如，一个编码为 GB2312 的页面，提交 "中" 这个字符串时，提交给服务器的内容为 "%D6%D0"。

在服务器端，Web 服务器把收到的 "%D6%D0" 转化成 [0xD6, 0xD0] 两个字节，然后再根据 GB2312 编码规则得到 "中" 字。

在 Tomcat 服务器中，request.getParameter() 得到乱码时，常常是因为前面提到的“误解一”造成的。默认情况下，当提交 "%D6%D0" 给 Tomcat 服务器时，request.getParameter() 将返回 [0x00D6, 0x00D0] 两个 UNICODE 字符，而不是返回一个 "中" 字符。因此，我们需要使用 bytes = string.getBytes("iso-8859-1") 得到原始的字节串，再用 string = new String(bytes, "GB2312") 重新得到正确的字符串 "中"。

回页首

3.4 从数据库读取字符串

通过数据库客户端（比如 ODBC 或 JDBC）从数据库服务器中读取字符串时，客户端需要从服务器获知所使用的 ANSI 编码。当数据库服务器发送字节流给客户端时，客户端负责将字节流按照正确的编码转化成 UNICODE 字符串。

如果从数据库读取字符串时得到乱码，而数据库中存放的数据又是正确的，那么往往还是因为前面提到的“误解一”造成的。解决的办法还是通过 string = new String( string.getBytes("iso-8859-1"), "GB2312") 的方法，重新得到原始的字节串，再重新使用正确的编码转化成字符串。

回页首

3.5 电子邮件中的字符串

当一段 Text 或者 HTML 通过电子邮件传送时，发送的内容首先通过一种指定的字符编码转化成“字节串”，然后再把“字节串”通过一种指定的传输编码（Content-Transfer-Encoding）进行转化得到另一串“字节串”。比如，打开一封电子邮件源代码，可以看到类似的内容：

最常用的 Content-Transfer-Encoding 有 Base64 和 Quoted-Printable 两种。在对二进制文件或者中文文本进行转化时，Base64 得到的“字节串”比 Quoted-Printable 更短。在对英文文本进行转化时，Quoted-Printable 得到的“字节串”比 Base64 更短。

邮件的标题，用了一种更简短的格式来标注“字符编码”和“传输编码”。比如，标题内容为 "中"，则在邮件源代码中表示为：

其中，

• 第一个“=?”与“?”中间的部分指定了字符编码，在这个例子中指定的是 GB2312。
• “?”与“?”中间的“B”代表 Base64。如果是“Q”则代表 Quoted-Printable。
• 最后“?”与“?=”之间的部分，就是经过 GB2312 转化成字节串，再经过 Base64 转化后的标题内容。

如果“传输编码”改为 Quoted-Printable，同样，如果标题内容为 "中"：

如果阅读邮件时出现乱码，一般是因为“字符编码”或“传输编码”指定有误，或者是没有指定。比如，有的发邮件组件在发送邮件时，标题 "中"：

这样的表示，实际上是明确指明了标题为 [0x00D6, 0x00D0]，即 "ÖÐ"，而不是 "中"。

回页首

4. 几种错误理解的纠正

误解：“ISO-8859-1 是国际编码？”

非也。iso-8859-1 只是单字节字符集中最简单的一种，也就是“字节编号”与“UNICODE 字符编号”一致的那种编码规则。当我们要把一个“字节串”转化成“字符串”，而又不知道它是哪一种 ANSI 编码时，先暂时地把“每一个字节”作为“一个字符”进行转化，不会造成信息丢失。然后再使用 bytes = string.getBytes("iso-8859-1") 的方法可恢复到原始的字节串。

误解：“Java 中，怎样知道某个字符串的内码？”

Java 中，字符串类 java.lang.String 处理的是 UNICODE 字符串，不是 ANSI 字符串。我们只需要把字符串作为“抽象的符号的串”来看待。因此不存在字符串的内码的问题。