作者归档：feng

中文化和国际化问题权威解析之一：字符编码发展历程

发表于由
回复

原作者序
在我开发Java程序的几年中，遇到得最多，也是别人向我提问最多的问题，就是各种各样看似稀奇古怪的中文乱码问题了。网上也有许多解释和解决Java中文问题的文章，但水平参差不齐，有一些文章甚至是错误的。

此外，我们公司自己的Java程序从一开始就采用了错误的方式处理中文问题，虽能解一时之急，却引出了越来越多的深远的问题。每当我听到有的同事还在讨论如何特殊处理双字节的中文GB码，就感慨他们思路的狭隘。试问，今天我们可以用特殊的方式处理我们所熟悉的中文编码，可是今后我们怎样才能应付日文版、韩文版、或世界其它国家语言的产品开发呢？

在我看来，与其说这些问题是“中文化问题”，不如说是“国际化问题”。所谓的“汉化”这种说法已经随时代远去了。想想看，这个词带有明显的小农经济的色彩：自家汉化自家用，哪管世界变化多。经过汉化的软件，常常意味着：版本落后、不兼容、不稳定。为什么会这样呢？根本原因是，从软件的设计阶段，就没有考虑国际用户的需要，没有采用国际通用的标准。事后要弥补自然难上加难。

所以让我们把眼光放开，想一想“国际化”。当然国际化的目的还是生产出“汉化”的软件，但我们可以用同样的方法“韩化”、“日化”、“阿拉伯化”，统称为“本地化” —— 这就是“国际化”的目的。国际化和本地化有两个很体面的英文缩写：I18n（Internationalization）和L10n（Localization）。

想要开发出国际化的软件产品，首先要了解国际标准，而不是使用东拼西凑的权宜之计。本文首先从相关国际标准的讨论切入，相信正确地理解和应用这些标准，所有的“中文化问题”或“国际化问题”都会迎刃而解。

字符编码简介
ASCII码
从学计算机的那天开始，老师就告诉我们在计算机里面，所有的英文字母都对应到一个数字编码，这就是ASCII码（American Standard Code for Information Interchange）。ASCII码是很久很久以前（1968年）制定的。它只使用了一个8位字节中的低7位，总共是127个编码位。这样的方案很快就不够使用了。

单字节编码的发展
在80年代早期，一些现在流行的标准（如ISO 8859和Unicode）还未出现。那时为了支持多种地区的语言，各大组织机构或IT厂商开始发明它们自己的编码方案，以便弥补ASCII编码的不足。一时间，各种互不相容的字符编码方案成百花齐放之势。

为了避免混乱，ISO组织在1998年之后，陆续发表了一系列代号为8859的标准，作为ASCII编码的标准扩展，终于统一了单字节的西方字符的编码。ISO是设在瑞士的国际标准化组织的简称（International Organization for Standardization）。

ISO-8859-1（Latin1 - 西欧字符）

ISO-8859-1覆盖了大多数西欧语言，包括：法国、西班牙、葡萄牙、意大利、荷兰、德国、丹麦、瑞典、挪威、芬兰、冰岛、爱尔兰、苏格兰、英格兰等，因而也涉及到了整个美洲大陆、澳大利亚和非洲很多国家的语言。

此外，ISO-8859-1后来被采纳为ISO-10646标准（后面会讲到）的首页，换句话说，Unicode的最开头256个字符编码和ISO-8859-1是一一对应的。正是由于这个特殊性，使很多人产生了对ISO-8859-1编码的误用。

ISO-8859标准还包括：

ISO-8859-2（Latin2 - 中、东欧字符）
ISO-8859-3（Latin3 - 南欧字符）
ISO-8859-4（Latin4 - 北欧字符）
ISO-8859-5（Cyrillic - 斯拉夫语）
ISO-8859-6（Arabic - 阿拉伯语）
ISO-8859-7（Greek - 希腊语）
ISO-8859-8（Hebrew - 希伯来语）
ISO-8859-9（Latin5）
ISO-8859-10（Latin6）
ISO-8859-11（Thai - 泰国语）
ISO-8859-12（保留）
ISO-8859-13（Latin7）
ISO-8859-14（Latin8）
ISO-8859-15（Latin9）
但是ISO 8859系列标准的字符编码，还是互不相容，不可能同时使用的。毕竟它们只是单字节的编码方案。而且，它们和多字节的编码方案如中文编码GB2312和BIG5也是不相容的。那些欧洲字符（最高位为1的字符），在GB2312和BIG5中被认为是双字节汉字编码的首字节。

多字节编码的发展
单字节编码只有256个码位（28=256），而中文字符何止千千万，单字节编码不可能满足中文编码的需要。于是为了适应东方文字信息处理的需要，ISO又制定了ISO 2022标准（Character code structure and extension techniques），提供了七位与八位编码字符集的扩充方法的标准。我国根据ISO 2022制定了国家标准GB2311 ——《信息交换用七位编码字符集的扩充方法》，并根据该标准制定了国家标准GB2312-80编码。其他东方国家和地区也制定了各自的字符编码标准，如日本的JIS0208，韩国的KSC5601，台湾地区的CNS11643等。

BIG5

BIG5是从CNS11643的早期版本发展而来的，虽然没有包括CNS11643的全部内容，但却是目前台湾、香港地区普遍使用的一种繁体汉字的市场标准，包括440个符号，一级汉字5401个、二级汉字7652个，共计13060个汉字。

GB2312-80

全称是《信息交换用汉字编码字符集 基本集》，1980年发布，是中文信息处理的国家标准，在大陆及海外使用简体中文的地区（如新加坡等）是强制使用的唯一中文编码。

·         双字节编码

·         A1-A9：符号区，包含682个符号

·         B0-F7：汉字区，包含6763个汉字

GB2312码共收录6763个简体汉字、682个符号，其中汉字部分：一级字3755，以拼音排序，二级字3008，以偏旁排序。该标准的制定和应用为规范、推动中文信息化进程起了很大作用。

GBK

汉字内码扩展规范（GBK）是国家技术监督局1995年为中文Windows 95所制定的新的汉字内码规范。

·         双字节编码，GB2312-80的扩充，在码位上和GB2312-80兼容。

·         范围：8140 ～ FEFE（剔除xx7F）共23940个码位。

·         包含21003个汉字，包含了ISO 10646中的全部中日韩汉字，简、繁体字融于一库。

严格说，GBK不能算是国家标准，最多算是一个商业标准。而GB18030才是真正的国家标准。

GB18030-2000

全称是《信息交换用汉字编码字符集》，是我国的强制标准，所有不支持GB18030标准的软件将不能作为产品出售。

·         单字节、双字节、四字节编码。

·         向下与GB2312编码兼容。

·         支持GB 13000.1-1993中的全部中、日、韩（CJK）统一汉字字符和全部CJK统一汉字扩展A的字符。

虽然GB18030标准非常强大，但它是一个中国大陆的标准。在编码上，除了和GB2312以外，还是不能和世界上其它任何一种字符编码统一。

终极标准 —— Unicode和ISO 10646
前面所讲的一切字符编码方案，都是针对局部地区或少数语言文字的，没有办法同时表达所有的语言文字，或在多种语言平台上交换。这对今天极其频繁的国际信息交流是不相称的。

为了提高计算机的信息处理和交换功能，使得世界各国的文字都能在计算机中处理，从1984年起，ISO组织就开始研究制定一个全新的标准：通用多八位编码字符集（Universal Multiple-Octet Coded Character Set），简称UCS。标准的编号为：ISO 10646。这一标准为世界各种主要语言的字符(包括简体及繁体的中文字)及附加符号，编制统一的内码。

统一码（Unicode）是Universal Code的缩写，是由另一个叫“Unicode学术学会”（The Unicode Consortium）的机构制定的字符编码系统。Unicode与ISO 10646国际编码标准从内容上来说是同步一致的。

Unicode是Java语言和XML的基础，所以我们要稍微详细地介绍一下Unicode以及ISO 10646标准。

注意：不够耐心的读者可以跳过本章的余下部分。但显然了解本章所描述的Unicode及相关编码的技术细节，有利于你更好地理解和应用Unicode。

Unicode和ISO 10646的关系
在1991年，Unicode学术学会与ISO国际标准化组织决定共同制订一套适用于多种语言文本的通用编码标准。Unicode与ISO 10646国际编码标准于1992年1月正式合作发展一套通用编码标准。自此，两个组织便一直紧密合作，同步发展Unicode及ISO 10646国际编码标准。

ISO 10646（UCS）
Unicode

1993年，ISO组织发表ISO 10646国际编码标准的第一个版本，全名是ISO/IEC 10646-1:1993。它收录了20902个表意字符（ideograph，中日韩文均属表意字符）。
同年，Unicode学术学会根据ISO/IEC 10646-1:1993修订了Unicode 1.0，发布Unicode 1.1。

不断改善和修订ISO 10646标准。
1996年发表Unicode 2.0，1998年发表Unicode 2.1，根据ISO 10646做了一些改善和修订，新增了欧元符号。

2000年10月发表了ISO 10646第二版的第一部分：ISO/IEC 10646-1:2000，新增收了6,582个表意字符于扩展区A中（CJK Unified Ideographs Extension A）。
2000年2月，发表Unicode 3.0，也包含了同样的CJK Ext A。

2001年，发表了ISO/IEC 10646的第二部分，增收了42711个表意字符于扩展区B里。
2001年，Unicode发表3.1版，将CJK Ext B纳入新版Unicode中。

虽然两个组织保持如此密切的合作关系，但Unicode和ISO 10646还是有区别的。ISO 10646着重定义字符编码，而Unicode则在此基础上，为这些字符及编码数据提出应用的方法以及对语义数据作补充。

UCS的结构
UCS的结构是一个四维的编码空间，每一维由一个字节（八位二进制位）组成，范围是00到FF。总体上分为128个群组(Group 00-7F)，每一群组由256个平面(Plane 00-FF)组成，每一平面有256行(Row 00-FF)，每一行256个编码位(Cell 00-FF)。所以，每一平面包括65,536个字符位(Character Position 0000-FFFF)。

整个编码字符集的每个字符都由4个字节，按“组-面-行-列”的顺序表示。所以UCS的可编码空间为：128 × 256 × 256 × 256 = 231。

UCS将其第一个平面(00群组中的00平面)称作基本多语种平面（Basic Multilingual Plane，BMP）。

 

在UCS中，目前只有00组是重要的，Unicode学术学会断言，在可以预见的将来，甚至不可能用完00组中的前17个平面（00平面到10平面）。因此，Unicode只定义了ISO 10646的第00组的前17个平面。事实上，目前绝大多数字符，都分配在第00平面BMP中。

 

下表中列出了BMP中的字符分配情况：

区间
描述

（0000-1FFF）基本拼音字符区
包括所有拼读文字的字母拼音和音标。它的字符集一般较小，如：拉丁文、西里尔文、希腊文、希伯来文、阿拉伯文、泰文、天成文书（梵文）等。

（2000-28FF）符号区
包括许多种用于标点、数学、化学、科技及其它特殊用途上的“符号”和“丁贝符”（示意图形符号）。

（2E80-33FF）中日韩语音及符号区
包括用于中国、日本、韩国语言中的标点、符号、字根（笔画）及发音等字符。

（3400-9FA5）中日韩汉字字符区
由27,484个中日韩（越）的统一汉字组成。

（A000-A4C6）彝族字符区
由1,165个中国南方彝族音节和50个其字根组成。

（AC00-D7A3）韩字符拼音区
由11,172个预先组合的韩字符拼音音节组成。

（D800-DFFF）代理区
这个区被平分为1024个“高半代理区”（D800-DBFF）码位和1024个“低半代理区”（DC00-DFFF）码位，用来形成代理对，可以得到超过一百万个扩充编码位。

（E000-F8FF）私人专用区
包含6,400个编码位，用于用户或开发商自行定义的字符编码。

（F900-FA2D）兼容字符区
包括一些被许多行业协会和国家标准广泛使用的字符，但在Unicode编码中有不同的表现形式。包含一些专用字符。

UCS的表现形式
UCS有两种方式来表示一个字符编码：四字节正规形式（UCS-4，Four-octet canonical form）和双字节基本平面形式（UCS-2，Two-octet BMP form）。

UCS-4 —— 四字节正规形式

UCS-4用4个字节来表示一个字符。第一个字节表示组（Group），第二表示平面（Plane），第三表示行（Row），第四表示单元号或列（Cell）。

UCS-2 —— 双字节基本平面形式

当系统只使用BMP的字符码时，可以省略群组和平面中的八位，将字符码由32个位缩短为16个位（2个字节）。标记为UCS-2。

Unicode和UCS-2同样采用16位编码。所以一般可以把Unicode和UCS-2看作是同一样东西。

代理对（Surrogate Pair）

UCS-4定义了4个字节表示一个字符，用来应付将来的扩展是绰绰有余。可是Unicode和UCS-2只定义了2个字节，却很容易用尽。代理对（Surrogate Pair）的设计在这种背景下应运而生。

UCS-2在BMP中开辟了一个特殊的区间（D800 - DFFF） -- 代理区，并平分成两个区，分别称为高半代理区（High-half Zone，D800 - DBFF），和低半代理区（Low-half Zone，DC00 - DFFF），各有1024个码位。使用时，从高低两个代理区中各取一个编码组成一个四字节的代理，来表示一个在BMP以外平面上的编码字符位。这样一来，总共可以多表示1024×1024个字符，映射到00群组中的01到10平面（共16个平面）。

代理对提供了用BMP的2字节编码来表示在基本多文种平面（BMP）之外的16个平面编码的机制。一些不常用的字符可以用代理对表示。目前，只有ISO/IEC 10646-2:2001和Unicode 3.1才使用到代理对。

高半代理区和低半代理区的划分，使编码位相互区分开。非代理区字符一定不会在这个区里。因为高半代理区和低半代理区不相交，所以很容易决定字符值的边界。一个完好的文本中，高半代理码和低半代理码总是按先后成对出现。

如果在实现上没有删除代理码或在代理码对中插入字符，数据的完整性就可得到保证。即使数据有残损，也只是局部的。一个残缺的码只影响一个字符。因为高半代理区和低半代理区不相交，且成对出现，错码不会传到文本的其它部分。

具体来说，一个代理对（H，L）由码值为D800-DBFF 的高半代理码H和码值为 DC00-DFFF低半代理码L组成。将一个字符映射到UCS-4码位中。假设N是UCS-4码值，则有：（以下所有数字均为16进制）

N = (H - D800) × 400 + (L - DC00) + 10000

于是得到N的码值为10000到10FFFF。

注意

Unicode 3.0没有用到代理对，直到3.1才增加了CJK Ext B，用到了02平面，需要使用代理对才能访问。但99.99%的情况下，根本用不到那些字。此外，JDK1.4只支持到Unicode 3.0，所以目前Java还不能应用代理对。

UTF编码
UTF为UCS Transformation Format的缩写，意为“UCS转换格式”。UCS只是一个字形和内码上的标准，并没有定义实际在计算机上存取的方法，而UTF便定义了一整套的计算机存取UCS编码的转换格式，并考虑了与其它编码方式兼容。常用的格式有UTF-8和UTF-16。有时也用到UTF-7来进行7位数据传输。

UTF-16

UTF-16是用定长16位（2字节）来表示的UCS-2或Unicode转换格式。它将Unicode的编码值变成2字节的Big-endian（高位字节在前，低位字节在后）或Little-endian（低位字节在前，高位字节在后）编码。UTF-16利用代理对来访问BMP之外的字符编码。

Java使用Big-endian系统，而Intel系列处理器内部使用Little-endian系统（学汇编语言和C语言的人都知道）。

例如：“中国”两字，Unicode是4E2D 56FD，在Windows上用UTF-16编码，结果为四个字节：2D 4E FD 56；如果使用Java输出，结果为：4E 2D 56 FD。

使用UTF-16有什么缺点呢？很显然，

1.   所有原本1个字节就可以表示的西方字符，现在要用2个字节来表示，体积大了一倍。

2.   学过C的人都知道，0x00代表C字符串的结尾。但是用UTF-16来表示单字节字符（ISO-8859-1）时，高位字节为0x00。这样就会使C语言库函数发生误判。用UTF-16表示文件名、网址等，全引出无数的问题。

3.   字符的边界不好找。程序处理时必须从字符串的头部开始扫描，才可能正确地找出一个字符的边界，效率较低。此外，万一坏掉一个字节，这个字节之后的字符都会错位，坏掉一片。

所有的这些问题，在UTF-8中都不存在。

但是，UTF-16也有其天然的优点：它直接表现了字符编码的整数值。所以UTF-16是最直接的Unicode表示法。此外，它是定长的，这大大简化了字符串的操作。Java语言就是用UTF-16格式将字符存储在内存中的。正是这样，才使Java的Unicode字符串的操作格外简单高效。

UTF-8

UTF-8使用了变长技术，在每一个编码区域有不同的字码长度：

1.   对UCS-2，由1字节至3字节构成；

2.   如果UCS-2使用了代理对，则UTF-8最长可到4字节；

3.   对UCS-4，由1字节至6字节构成。

因为以字节（8位）为组成单元，故称为“UTF-8”。对于英文文本，UTF-8的文件大小比其它转换格式都小。

在UTF-8内，字符由1个至6个字节为组合。下表列举出了不同范围的UCS码转换成UTF-8的规则。英文字母“x”代表可以用来记录 Unicode 码值的区域。

UCS-4 区域（十六进制）
UTF-8字节组合（二进制）

0000 0000 —— 0000 007F
0xxxxxxx

0000 0080 —— 0000 07FF
110xxxxx 10xxxxxx

0000 0800 —— 0000 FFFF
1110xxxx 10xxxxxx 10xxxxxx

0001 0000 —— 001F FFFF
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

0020 0000 —— 03FF FFFF
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

0400 0000 —— 7FFF FFFF
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

在UTF-8内，

1.   如果一个字节，最高位（第8位）为0，表示这是一个ASCII字符（00 - 7F）。可见，所有ASCII编码已经是UTF-8了。

2.   如果一个字节，以11开头，连续的1的个数暗示这个字符的字节数，例如：110xxxxx代表它是双字节UTF-8字符的首字节。

3.   如果一个字节，以10开始，表示它不是首字节，需要向前查找才能得到当前字符的首字节。

可见UTF-8可以有效地保证数据的完整性，避免出现编码的错位。即使偶然出现“坏字”，也不会影响到后续的文本。

那么UTF-8有什么缺点呢？显然，对于在BMP中的中文字来说，需要用3个字节才能表示，比使用UTF-16或直接使用双字节的GB2312编码大了0.5倍。

上文说了一大通，总结一下，其实很简单：

字符编码是抽象字符在计算机中的数字表示。
字符编码集（character set，简称字符集）是一批字符编码的集合。世界上存在大量互不兼容的字符集，给国际交流带来了困难。
ASCII码是最古老的字符编码，它总共只定义了7位共128个字母、数字和符号。但它是其它所有字符编码的基础。
Unicode用16位整数编码，将世界上所有主要文字的字符统一起来了。如果利用代理对（surrogate pair）最多可以表示从0到1FFFF的字符。然而绝大多数情况下，只需要用到0到FFFF之间的字符就足够了。
Unicode常用UTF-8和UTF-16来表示。7位的ASCII码不用作任何变化，就已经是UTF-8了。但UTF-8需要用3个字节来表示一个汉字。
ISO 8859系列字符集，定义了单字节字符编码的标准。其中最特殊的是ISO-8859-1编码，它的编码和Unicode中最开始的256个字符编码完全相同。
GB18030编码是中国大陆的国家标准，在字汇上等同于Unicode，在编码上和GB2312编码以及GBK编码兼容。

本文来源：http://blog.csdn.net/sfdev/archive/2009/01/13/3770706.aspx

javascript中 escape、encodeURI、encodeURIComponent等方法的区别

发表于由
回复

escape 方法
返回一个可在所有计算机上读取的编码 String 对象。function escape(charString : String) : String
参数
charString
必选。要编码的任何 String 对象或文本。
备注
escape 方法返回一个包含 charstring 内容的字符串值（Unicode 格式）。所有空格、标点、重音符号以及任何其他非 ASCII 字符都用 %xx 编码替换，其中 xx 等于表示该字符的十六进制数。例如，空格返回为“%20”。

字符值大于 255 的字符以 %uxxxx 格式存储。

注意 escape 方法不能用来对“统一资源标识符”(URI) 进行编码。对其编码应使用 encodeURI 和 encodeURIComponent 方法。
要求
版本 1

请参见
encodeURI 方法 | encodeURIComponent 方法 | String 对象 | unescape 方法

适用于：Global 对象

encodeURI 方法
返回编码为有效的统一资源标识符 (URI) 的字符串。

function encodeURI(URIString : String) : String
参数
URIString
必选。表示编码 URI 的字符串。
备注
encodeURI 方法返回一个已编码的 URI。如果将编码结果传递给 decodeURI，则将返回初始的字符串。encodeURI 不对下列字符进行编码：“:”、“/”、“;”和“?”。请使用 encodeURIComponent 对这些字符进行编码。

要求
版本 5.5

请参见
decodeURI 方法 | decodeURIComponent 方法

适用于：Global 对象

encodeURIComponent 方法
返回编码为统一资源标识符 (URI) 的有效组件的字符串。

function encodeURIComponent(encodedURIString : String) : String
参数
encodedURIString
必选。表示编码 URI 组件的字符串。
备注
encodeURIComponent 方法返回一个已编码的 URI。如果将编码结果传递给 decodeURIComponent，则将返回初始的字符串。因为 encodeURIComponent 方法将对所有字符编码，请注意，如果该字符串代表一个路径，例如 /folder1/folder2/default.html，则其中的斜杠也将被编码，这样，当该字符串作为请求发送到 Web 服务器时它将是无效的。如果字符串中包含多个 URI 组件，请使用 encodeURI 方法进行编码。

要求
版本 5.5

请参见
decodeURI 方法 | decodeURIComponent 方法

适用于：Global 对象

unescape 方法
从用 escape 方法编码的 String 对象中返回已解码的字符串。

function unescape(charString : String) : String
参数
charString
必选。要解码的 String 对象或文本。
备注
unescape 方法返回一个包含 charstring 内容的字符串值。所有以 %xx 十六进制形式编码的字符都用 ASCII 字符集当中等效的字符代替。

以 %uxxxx 格式（Unicode 字符）编码的字符用十六进制编码 xxxx 的 Unicode 字符代替。

注意 unescape 方法不应用于解码“统一资源标识符”(URI)。请改用 decodeURI 和 decodeURIComponent 方法。
要求
版本 1

请参见
decodeURI 方法 | decodeURIComponent 方法 | escape 方法 | String 对象

适用于：Global 对象

decodeURI 方法
返回一个已编码的统一资源标识符 (URI) 的非编码形式。

function decodeURI(URIstring : String) : String
参数
URIstring
必选。表示编码 URI 的字符串。
备注
使用 decodeURI 方法代替已经过时的 unescape 方法。

decodeURI 方法返回一个字符串值。

如果 URIString 无效，将发生 URIError。

要求
版本 5.5

请参见
decodeURIComponent 方法 | encodeURI 方法

适用于：Global 对象

decodeURIComponent 方法
返回统一资源标识符 (URI) 的一个已编码组件的非编码形式。

function decodeURIComponent(encodedURIString : String) : String
必选的 encodedURIString 参数是一个表示已编码的 URI 组件的值。

备注
URIComponent 是一个完整的 URI 的一部分。

如果 encodedURIString 无效，则将产生 URIError。

要求
版本 5.5

请参见
decodeURI 方法 | encodeURI 方法

适用于：Global 对象

为firefox开启DNS解析缓存功能

发表于由
回复

某些linux发行版默认没有打开操作系统级的DNS解析的缓存功能，从而造成（使用firefox）第打开一个网页，等待时间很长，而这个等待时间大多是在等待DNS解析，非常影响上网效率。可以打开firefox内置的dns解析缓存功能改善这一状况，方法如下：
Firefox有dns缓存功能，但是默认缓存时间只有1分钟，可以通过修改该默认值加快DNS解析速度，方法如下：
打开一个新的窗口，地址栏输 入 about:config，回车，进入设置界面。然后搜索 network.dnsCacheExpiration ，把原来的60改成 6000（表示缓存6000秒），再搜索network.dnsCacheEntries 把默认的20改成1000（表示缓存1000条）。如果没 有上面两个项目，新建它们即可，新建条目类型为整数型。 当然也可以按照需要设置成其它的值。
但是dns缓存太久了也会出问题，比如有的网站ip换了，就无法访问了。
针对这样的问题，还可以安装一个 firefox 插件来开启或者 关闭dns cache功能，https://addons.mozilla.org/zh-CN/firefox/addon/5914 。

MSSQL数据库超时 80040e31

发表于由
回复

今天早上碰到了导致超时的一种不常见的特殊情况。特整理如下：
早上CSDN的论坛回复和发帖都一直报超时,错误信息是最常见的那种：

Microsoft OLE DB Provider for SQL Server 错误 '80040e31'
超时已过期
/Expert/reply.asp，行 110

服务器上看CPU、内存，都非常非常的低呀，这么低的占用率也能导致超时，我晕。后来到处查看，后来在事件日志中看到一个非警告的日志：

事件类型: 信息
事件来源: MSSQLSERVER
事件种类: (2)
事件 ID: 17055
日期:   2005-8-23
事件:   9:39:00
用户:   N/A
计算机:   ********
描述:
5144:
数据库 '*********' 中文件 '***********' 的自动增长在 453 毫秒后已取消或出现超时。使用 ALTER DATABASE 设置更小的 FILEGROWTH 或设置新的大小。

我倒竟然是数据库文件在增加的时候超时了。而不是平常常以为的具体的SQL语句超时。把 FILEGROWTH 设置为一个更低的值，ok 一切都恢复了。

FILEGROWTH 的设置就是在数据库的 Enterprise Manager 中，对数据库的属性的如下窗口进行设置：

一旦你的数据库文件大了后，上述超时就可能出现。这时候不要简单地以为服务器压力太大了。也许就是你的一个设置导致了超时。

反馈

# re: 数据库超时的其中一种情况

2005-8-23 10:35 by ghj1976

默认SQL Server 在数据库文件满了后，是自动增加原数据库文件的10%大小，用来继续使用。

如果你的数据库文件很大了，这时候麻烦就来了，CSDN 论坛的这次问题就是在增加这个数据库文件的时候超时了。

然后其它所有的新增操作都会报超时，而这时候其实CPU、内存占用率都非常非常的低。

# re: 数据库超时的其中一种情况

2005-8-23 10:36 by ghj1976

解决方法就是把上述的文件增长这里设置为一个更低的百分比或者直接指定增加多少兆字节。

# re: 数据库超时的其中一种情况

2005-8-23 10:38 by rIPPER

dba哪去了？ :)

# re: 数据库超时的其中一种情况

2005-8-23 12:30 by ocean

没错，微软有专门一篇文章说这个问题：

http://support.microsoft.com/?id=305635

# re: 数据库超时的其中一种情况

2005-8-23 13:36 by Jacob

这是一个很土的问题，然而在企业的生产环境中经常遇到。不仅是数据文件满会导致此问题，日志文件满也一样。
某一条数据更新语句在数据库或日志文件即将满的时候执行，数据库增长的IO操作会导致延时，此延时会阻塞其他数据库操作，连锁反应，形成blocking。
其实此时找出一条正在阻塞的更新语句，在查询分析器中执行，此时是没有超市时间的。忍过几分钟，当这条语句执行完后，数据文件就会增长完成，所有的blocking也就解开了。
正如楼上的朋友所问，"dba哪去了？"。文件的监测和日志的truncate，本来就应该是dba常抓不懈的工作。

# re: 数据库超时的其中一种情况

2005-8-23 23:39 by ocean

其实此时找出一条正在阻塞的更新语句，在查询分析器中执行，此时是没有超市时间的。忍过几分钟，当这条语句执行完后，数据文件就会增长完成，所有的blocking也就解开了。
----------------------------
这句话好像不对，按照KB上的，这个申请文件增长的请求是被操作系统拒绝的，所以不是等几分钟执行完语句就能增长的。解决的方法还是把文件的增长大小设置为一个固定数值而不是百分比。

# re: 数据库超时的其中一种情况

2005-8-23 23:54 by Benny Ng

我还是不明白..那我要做的措施是什么?(针对这个情况)

# re: 数据库超时的其中一种情况

2005-8-24 15:53 by 怡红公子

我在一年多以前就说过这个事情。
另外，用SQL2005就不容易遇到这个问题了哦。
数据库增加10G的大小也不过就是3秒钟。

# 哈哈！你被贴了。

2005-8-24 17:40 by 透明

http://gigix.blogdriver.com/gigix/936726.html

# re: 数据库超时的其中一种情况

2005-8-25 1:43 by 流言社

哎，到处都是“你小子被贴了”

# re: 数据库超时的其中一种情况

2006-3-8 10:45 by zjbmax

遇到数据库中很多进程被阻塞或死锁的情况怎么解决？（就是在sql2000的企业管理器的“管理”中的“当前活动”“锁/进程ID”中发现的）

很多不错的学习文章，虽然老了一点//本文内容已无效，当一篇测试文件用

发表于由
回复

这是一篇测试文章，一号标题

用来调试样式，h2, a brown fox jump over the lazy dog

twenty什么什么的主题，wordpress某个版本时自带的主题，这一段内容。twenty什么什么的主题，wordpress某个版本时自带的主题，这一段内容。twenty什么什么的主题，wordpress某个版本时自带的主题，这一段内容

效果还是不错的，三级标题

四级标题，四号的，排老四

五号标题，第五级，似乎没用过
还有六号，大概很少用吧大概都没人没有用过吧
就是对标题的样式搞得太坑，尤其是h3，竟然比字体还小，10px
所以做了个主题扩展，改掉这些，一段内容，随便一段内容
个人玩儿的

h1, a brown fox jump over the lazy dog

h2, a brown fox jump over the lazy dog

h3, a brown fox jump over the lazy dog

h4, a brown fox jump over the lazy dog

h5, a brown fox jump over the lazy dog
h6, a brown fox jump over the lazy dog

content, You should ensure that the SSH key you are using is attached to your GitHub user account. You can check this by typing the following into the command line:

http://fedora.linuxsir.org/main/
fa28d4b9-53ee-102d-956f-2075ea3753fb
http://fedora.linuxsir.org/main/fa28d4b9-53ee-102d-956f-2075ea3753fb
http://fedora.linuxsir.org/main/
abcdefg

美丽Ay:傲游浏览器“2008特别版”正名启事

发表于由
回复
傲游浏览器“2008特别版”正名启事
2008-08-14 14:15:13 pm · 记事 · 作者: spysorge

8月12日，傲游公司收到奥组委来函，要求最新发布的傲游浏览器版本名称避免使用“奥运”一词。公司同仁始而惊诧，继而反思，原来“奥运”这个词汇现在已经成为一个专有名词，不宜于敝公司使用。为了响应奥组委的工作，傲游将新版本的名称由“奥运版”更改为“2008特别版”。

自2001年申奥成功以来，2008这个数字就被赋予了深刻的含义，凝结了无数中华儿女的热忱期望。在2008年夏天终于到来的时候，中国体育健儿果然不负众望，在奥运赛场再建奇功。看着五星红旗一次又一次伴随着雄浑的国歌在赛场冉冉升起，中国体育健儿所体现出的奥林匹克精神不仅感动中国，也征服了全世界。2008，这个具备特殊意义的年份，必将和“更高、更快、更强”的奥林匹克精神一起，成为中华民族历史上永远的里程碑。

傲游公司为迎接北京奥运精心打造的“2008特别版”浏览器，正是向“更高、更快、更强”的奥林匹克精神的一次献礼。在未来，我们也希望能够以中国体育健儿为榜样来激励自己，超越自我，更好的服务广大用户，做成一个能够凝聚国人力量的品牌。

永久链接 · 此文章的 RSS 订阅地址

29 条评论 »

1.
[访客] tyreal · 2008-08-14 14:28:59 pm

抢到位置很激动，遨游加油！！！
2.
[访客] goodmorning · 2008-08-14 15:17:53 pm

呵呵，奥运真不能随便用啊。
3.
[访客] Anonymous · 2008-08-14 16:19:05 pm

同学们支持

以后北京，2008都禁用才好

最好是今年生的小孩不让上北京户口
4.
[访客] 盗盗 · 2008-08-14 18:45:39 pm

奥运=专有名词。。。
这个绝对汗。。。
5.
[访客] 枫叶刀 · 2008-08-14 18:55:48 pm

这个。。。。。。。。。有点那个啥
6.
[访客] Anonymous · 2008-08-14 19:38:50 pm

傲游浏览器 2008熬孕版
7.
[访客] 占7楼等小7查我IP · 2008-08-14 20:05:41 pm

沙发~
支持~
8.
[访客] Anonymous · 2008-08-14 20:21:45 pm

以后如果吃饭被专利了 不知道我们还能不能吃饭 唉
9.
[访客] 软件音速 · 2008-08-14 20:27:25 pm

很奥运!!!!!!!!!!!!!!!!!!!!!!!
傲游春节版发布后,
就会接到春节组发来的消息:必须改名
10.
[访客] Anonymous · 2008-08-14 21:02:36 pm

改名叫奥TMD运版吧
11.
[访客] 奥组委是SB · 2008-08-14 21:02:57 pm

国际上好好的东西到中国都变样了,开幕式公开作假,丢尽中国的脸,还有什么资格管东管西,奥组委就是SB一个
12.
[访客] Anonymous · 2008-08-14 22:10:20 pm

这就是中国特色社会主义中的现象。。。。。。
13.
Bingge · 2008-08-14 22:14:43 pm

原来“奥运”这个词汇现在已经成为一个专有名词，不宜于敝公司使用。为了响应奥组委的工作，….
14.
蓝雪王 · 2008-08-14 23:59:20 pm

这是好事啊，证明中国人的法律意识增强了。
15.
[访客] NewEye · 2008-08-15 8:01:42 am

CB观光团前来欣赏“aoyun”
16.
[访客] 库拉 · 2008-08-15 8:13:35 am

奥运真的很有名啊
17.
[访客] SX · 2008-08-15 9:43:41 am

CB路人甲对此深表同情
18.
asusmt · 2008-08-15 9:52:00 am

中国奥组委就是SB，干脆别让全世界人说“奥运”这个词了，保护知识产权。
19.
[访客] 枫丹白露 · 2008-08-15 13:15:45 pm

“为了响应奥组委的工作” 应该是“为了不影响吧”
20.
[访客] 枫丹白露 · 2008-08-15 13:16:49 pm

看错啦，请删除评论
21.
[访客] 占7楼等小7查我IP · 2008-08-15 19:32:39 pm

三七二十一~
22.
[访客] Anonymous · 2008-08-18 16:34:40 pm

hah ,这样也有。。
23.
[访客] 一小撮人 · 2008-08-19 12:35:05 pm

奥运啊~~~在中国，不是人人都能用！只有高级的人才能用。
傲游你这间小公司啊~~~当然不能用了….呵呵
24.
[访客] 海天 · 2008-08-21 9:07:39 am

可以叫 “傲运版”
25.
[访客] 哼哼 · 2008-08-21 19:37:11 pm

真够厚道的。。。
26.
[访客] 雨中漫步 · 2008-08-23 9:52:56 am

奥运版臃肿不好看，把奥运那一排去掉
27.
[访客] Anonymous · 2008-08-26 15:37:12 pm

哇哈哈~~~强汗！
顶！
28.
[访客] .o0CY○ · 2008-08-26 15:39:07 pm

支持奥运，支持傲游！
29.
[访客] 天堂的另一半 · 2008-08-28 23:53:05 pm

不错啊 顶下

微软 Windows 7启动时间不超过15秒 ???

发表于由
回复

有文：

9月4日消息，据国外媒体报道，微软近日在Windows 7官方博客中暗示，下一代操作系统Windows 7的启动时间只需15秒。

对于当前一代的Windows Vista系统，微软在开发之前就许下过多承诺，结果在产品正式发布后，很多诺言却未能实现。在Windows 7上，微软似乎吸取了教训，到目前为止，微软并未公布太多有关Windows 7的信息。

但微软近日却在Windows 7官方博客中暗示，Windows 7的启动时间预计只需15秒。微软称：“对于Windows 7，我们的最大目标是降低系统启动时间，一款优秀的系统启动时间不应超过15秒。”

当然，硬件配置不同，系统启动所需时间也不同。以Windows Vista SP1为例，启动时间在30秒以下的仅占35%，50秒以下的占75%。

启动快有什么用？电脑是用来“用”的，而不是用来“启动”的！

应该把问题核心放在系统整体性能，稳定性，兼容性，易用性，可定制性，低耗能，低系统占用，低硬件需求上。像“喂死它”那种垃圾，就算是企业版，卖100块都不买！！

对策：迅雷偷窥你的文件？

发表于由
回复
迅雷“偷窥”了你的电脑？

http://news.crsky.com/it/20080220/18262.html

这篇文章应该有很多人看过，对迅雷的此种“行径”，我们要采取一定的对策，以免自己的本来就不宽裕的网络带宽被盗用，   

   1)一定不要设置开机自动运行迅雷，下载时以不影响其他网络应用为前提，觉得妨碍电脑运行和其他网应用时不妨暂停下载，关闭迅雷
   2）.如有必要可选择在晚上不用电脑时进行下载，以免影响电脑和网络的正常使用Vc3霏凡软件站> 资讯中心
   3）.P2P精神在于无私分享，但不希望继续长期上传的文件可以转移下载到其他分区（推荐）或对文件改名。
（下一条是个人发现的最有效方法）
    4）最有效的方法之一：利用ntfs分区权限，严格设置迅雷下载目录的权限。
具体如下：
a.新建一个系统用户downloaduser，最好是属于guest组；以此用户的身份运行迅雷时，再下载文件
b.下载目录使新建的downloaduser这个用户有读写的权限。
c.最好再把其它的目录权限设为downloaduser不能访问
这样迅雷就没有偷偷做这些“违法”事件了

以其它用户身份运行程序方法（命令行法）：
开始 - 运行 cmd

进入迅雷安装目录，如D:\Program Files\Thunder Network\Thunder，执行命令如下
d:
cd D:\Program Files\Thunder Network\Thunder
runas /user:downloaduser Thunder.exe
此时系统会提示输入用户密码，输入即可
此法要保证系统服务 Secondary Logon 的正常运行

这样就可以防止迅雷的某些不受欢迎的动作了。可以测试，如果downloaduser没有下载目录的读写权限，添加下载任务会失败的

Pages: Prev 1 2 3 ... 39 40 41 42 43 44 45 46 47 48 49 Next