用vs2008编译的一个项目,之前运行得很好,今天编译了一下,结果又出现了 R6034.记得之前曾发生过无数回这样诡异的事情.后来都轻松解决,这回却忘记怎么弄了.

一番折腾之后,得出如下解决之法,特记录如下

1)可以先将"清单工具"中的嵌入清单设成否,编译,然后再改成"是",重新编译,运行试试,

2)或者干脆彻底地,把生成的清单文件删除,再重新编译,100%ok.

 R6034 错误的解决之道--仅限于原来可以正常运行的情况下。

ByteArray 有二种操作
一种是Read系列，主要是将从position开始的，返回某种类型长度或指定长度的缓冲,返回结果会做根据字节顺序一些处理，同时postion会自动移到读取缓冲的终点。

二是Write系列，也是从position开始，写入某种类型长度或指定长度的数据（必要时会根据字节顺序作处理），同时position会自增。

要注意的有几点
1)字节顺序
 var b:ByteArray= new ByteArray;
 b.endian=flash.utils.Endian.BIG_ENDIAN;
 b.writeShort(0x1234);
 b.position=0;
 trace(b.readByte());//=0x12，如果b.endian=flash.utils.LITTLE_ENDIAN,则是0x34
2）readBytes
ByteArray.readBytes(bytes:ByteArray, offset:uint = 0, length:uint = 0):void
Reads the number of data bytes, specified by the length parameter, from the byte stream.

如
var b:ByteArray= new ByteArray;
var a:ByteArray= new ByteArray;
..
b.ReadBytes(a,o,l);

这时从b的角度来考虑，b是从b.position开始读取b的内容的。
从a的角度来看，a被写的数据是存放在[o,o+l)这段空间的，这时不关心a的position在何处。
如果a的长度原来不够，则会自动增长到o+l长度。

3）writeBytes
public function writeBytes(bytes:ByteArray, offset:uint = 0, length:uint = 0):void
var b:ByteArray= new ByteArray;
var a:ByteArray= new ByteArray;
...
b.writeBytes(a,o,l);
表示从b.postion 开始写入从a的o处开始l 长度的缓冲到b

4) 关于字符集的问题
ByteArray在处理utf-8及普通字符集都没有太大问题（通过read/writeUTF/MultiByte）
但在处理utf-16时有点小麻烦。
也就说，如果ByteArray存放的是utf-16则有些问题。

flex 自己的文档 “Supported Character Sets”  有这么一行：Unicode (Big-Endian) unicodeFFFE ，也就是说 0xFFFE flex当成大端的BOM，然而恰恰相反，这似乎应该是小端BOM吧。
所以当byteArray存放的是ucs-2时，即无论是大端还是小端，或者你怎么设置都不能正确得到字符串。晕啊。
这太郁闷了，当有BOM存在时，经过代码验证，flex是忽略ByteArray的endian设置的---只要有BOM存在(这是有道理的，因为bom决定了字节顺序）。

我写了一个小小的flex页面（页面及代码见文章最后），专门来测试，试了大把的charset 。最后的结果是让我对使用readMultiByte读取ucs-2(utf16-be or utf16-le)的缓冲不抱任何希望。

因此凡是utf-16编码的ByteArray得通过另外的方法来取得--而且有比较简单的方法（运气啊！是运气，还是因为上帝在这里关上门，就会在另一面打开一扇窗？）

ByteArray中缓冲区的数据要符合二个条件就可以读出

1. 必须得有BOM
2. BOM之后的数据流字节顺序与BOM是一致的

这样就可以通过ByteArray.toString()得到 String了！

小小代码例子：

var s:String = "123中国";
var b:ByteArray= new ByteArray;
b.writeByte(0xFF);
b.writeByte(0xFE);
b.endian=Endian.LITTLE_ENDIAN; //与上面的BOM对应起来
for ( var i:int = 0 ; i <s.length ; ++i )
{
 buff.writeShort( s.charCodeAt( i ));
}

var news:String = b.toString();
trace(news);

// or

var s:String = "123中国";
var b:ByteArray= new ByteArray;
b.writeByte(0xFE);
b.writeByte(0xFF);
b.endian=Endian.BIG_ENDIAN; //与上面的BOM对应起来
for ( var i:int = 0 ; i <s.length ; ++i )
{
 buff.writeShort( s.charCodeAt( i ));
}

var news:String = b.toString();
trace(news);

 

我测试的flash程序所在

http://chensheng.net/p/test-bytearray/

源代码点右键可以看到,utf-16字符串与byteArray之间的相互转换

 btw:这好象是一个bug

请参见：http://bugs.adobe.com/jira/browse/FP-716

呵呵，这么说来，许多中文论坛上关于 Flex 中文乱码 的麻烦是有原因的，我这才是解决之首。

他会同时把注册表中 某些重要的地方有这个木马文件名的注册表项也给删除掉。
因此，你即使将被修改过的dll恢复，也会导致一些其他的错误。

这是第二回了，上回弄了我好几天才找到原因，修复后没有作记录。
今天这事又发生了，只是有点印象，结果还是想了一个小时才找到解决办法。
故特此记录。

因此，一旦当某木马或病毒被发现并清除之后，系统如果出一些错误，如服务无法启动，则可以从这个方面着手思考。

抱怨一下：kaspersky怎么也应该把除删除文件外的一些重点操作，如删除注册表项等记录起来，或者写到一个日志文件里（或许有？我不知道？）。

要使用subversion最少需要二个软件

• TortoiseSVN  我最新下载的是TortoiseSVN-1.5.8.15348-win32-svn-1.5.5.msi，不过又好象出1.6了 这是客户端软件，同时还可以管理
• 服务器端我用的是CollabNetSubversion-server-1.5.6-2.win32.exe

安装其实很简单：
首先安装CollabNetSubversion-server-1.5.6-2.win32.exe
1）要注意几点，你需要设置好你的svn仓库目录，如d:\data\svn_repository，端口默认3690
2)一般而言，你可以不安装apache，这东东对于我来说，还用不上，也不愿意用(http访问速度慢），干脆就不用装了

安装完成后，你到windows服务管理中可以找到subversion服务，启动他，你可以看到他的命令行可能如下：
"d:\soft\CollabNetSubversionServer\svnserve.exe" --service -r "d:\data\svn_repository" --listen-port "3690"

3)安装好TortoiseSVN。

4）下面是我的使用惯例

a）打开d:\data\svn_repository
b)建立一个目录，如“某某项目“，这里我们用代号"project_a"，当然目录可以是中文名也可以是英文名。
建立一个目录，如”某工程“，这里我们用代号“prj_b"

到目录 d:\data\svn_repository\project_a ，点右键，使用 TortoiseSVN 的“create repository here"
到目录 d:\data\svn_repository\某工程  点右键，使用 TortoiseSVN 的“create repository here"

这样我们就已经创建了二个项目

用
svn://localhost/project_a （或svn://ip地址/project_a）及 svn://localhost/某工程 你就会发现已经有二个svn可以管理的仓库了。
当然你可以试一个 svn://localhost/ 你就会发现提示“No repository found in ..."

c)在目录d:\data\svn_repository 创建一个passwd
内容为
[users]
usera=passwd-a
userb=passwd-b
d)在目录d:\data\svn_repository创建文件：svnserve.conf
内容为

[general]
anon-access =none
auth-access = write
password-db = ../../passwd
authz-db = authz

并将其分别复制到
d:\data\svn_repository\某工程\conf 及d:\data\svn_repository\project_a\conf 目录（覆盖文件）

e)修改d:\data\svn_repository\project_a\conf\authz 文件
内容
[/]
usera=rw
*=
f)修改d:\data\svn_repository\某工程\conf\authz 文件
内容
[/]
userb=rw
*=

这样你就会发现
usera只能读写 project_a
而userb只能读写"某工程“

总结：
这样做的目的
1）必须要有密码与用户名才可以读写
2）所有项目的用户与密码都由同一个文件管理
3）不同的项目及目录都可以设置不同的用户及相应的权限

1 将CentOS-4.6-x86_64-binDVD.iso 下载到一个目录
(因为有多台机器需要升级，可以采用nfs)
2 mkdir /mnt/iso
3 mount -t iso9660 -o loop CentOS-4.6-x86_64-binDVD.iso /mnt/iso
4 修改/etc/yum.repos.d/CentOS-Base.repo
将所有mirrorlist改成baseurl=file:///mnt/iso/
5 将gpgcheck=1 改成gpgcheck=0
6 yum remove srptools
(上面那步解决：Error: Missing Dependency: kernel-ib is needed by package srptools）
7 yum upgrade

8 一路选择yes
9 最后# cat /etc/redhat-release
>CentOS release 4.6 (Final)
 

初步升级完成

详情参见：SQLite的原子提交原理

DBCS 是双字符集

 它兼容ascii。也就是说，在DBCS中，ANSI所表示的字符是一样的。这就是说DBCS并不总是用双字符，只是在需要的时候，最多用双字符来表示。DBCS是一种统称，一种泛指。具体来说，Shift-JIS,gb2312,big5,gbk,gb18030等等都是dbcs的一种具体实现方案。

GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE

　GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符

2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030，对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。

从ASCII、GB2312、GBK到GB18030，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。

这里还有一些细节：

• GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。
• 在DBCS中，GB内码的存储格式始终是大端字节顺序（即网络节顺序），即高位在前。
• GB2312的两个字节的最高位都是1。但符合这个条件的码位只有128*128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析：在读取DBCS字符流时，只要遇到高位为1的字节，就可以将下两个字节作为一个双字节编码，而不用管低字节的高位是什么。

那么又什么是区位码？

区位码，即是区码与位码。

我国国家标准局于1981年5月颁布了《信息交换用汉字编码字符集——基本集》，代号为GB2312-80，共对6763个汉字和682个图形字符进行了编码，其编码原则为：汉字用两个字节表示，每个字节用七位码（高位为0），;国家标准将汉字和图形符号排列在一个94行94列的二维代码表中，;每两个字节分别用两位十进制编码，前字节的编码称为区码，后字节的编码称为位码，此即区位码，;如“保”字在二维代码表中处于17区第3位，区位码即为“1703 ”。

国标码

国标码是汉字信息交换的标准编码.是指我国1981年公布的“中华人民共和国国家标准信息交换汉字编码”，代号为“GB2312-80”。由连续的两个字节组成。

国标码：并不等于区位码，它是由区位码稍作转换得到,其转换方法为：先将十进制区码和位码转换为十六进制的区码和位码，;这样就得了一个与国标码有一个相对位置差的代码，;再将这个代码的第一个字节和第二个字节分别加上20H，就得到国标码。如：“保”字的国标码为3123H，它是经过下面的转换得到的：1703D－>1103H->+20H－>3123H。

国标码很少直接使用。

那上面的所谓内码又是什么呢？其实就是gb2312编码时存储表示汉字的代码。从区位码到内码，需要在高字节和低字节上分别加上A0。

国标码是汉字信息交换的标准编码，但因其前后字节的最高位为0，与ASCII码发生冲突，如“保”字，国标码为31H和23H（区位码为0x1103)，而西文字符“1”和“#”的SCII也为31H和23H，现假如内存中有两个字节为31H和23H，;这到底是一个汉字，还是两个西文字符“1”;和“#”?于是就出现了二义性，显然，国标码是不可能在计算机内部直接采用的，于是，;汉字的机内码采用变形国标码，其变换方法为：将国标码的每个字节都加上128(0xA0)，即将两个字节的最高位由0改1，其余7位不变，如：由上面我们知道，“保”字的国标码为3123H，前字节为00110001B，后字节为00100011B，高位改1为10110001B和10100011B 即为B1A3H，因此，字的机内码就是B1A3H。

MBCS 又是什么呢？

MBCS=多字节字符集。所以DBCS(双字节字符集)又说回来是MBCS的一种实现策略。DBCS似乎是MBCS的主要实现（因为中文，日文等是主要需求这MBCS），所以可以简单的认为MBCS一般就是DBCS好了。

为了完整起见，再说一下SBCS（即单字符集）。ASCII码就是单字符集，没办法来表示更多字符。

• mbcs=1个文字由多个字节表现的文字的集合。同时，指在其文字中分配的字符编码的体系。
• 像日语和中文等文字组/编码一样地，把以2个字节表现1个字的文字组和编码体系特别地称为DBCS(Double Byte Character Set)。
• 把拉丁字母和数字·记号的ASCII等，以一个字节表现1个字的文字组和编码体系的叫做SBCS(Single Byte Character Set)。

MBCS(DBCS)主要是一种unicode的一种替换

那什么又是unicode?

unicode是一件大工程。

Unicode也是一种字符编码方法，不过它是由国际组织设计，可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set"，简称为UCS。UCS可以看作是"Unicode Character Set"的缩写。

前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容（更准确地说，是与ISO-8859-1兼容），与GB码不兼容。例如“汉”字的Unicode编码是6C49，而GB码是BABA。

Unicode 具体不多说了，一般有有ucs与utf之说。

UCS规定了怎么用多个字节表示各种文字。怎样传输这些编码，是由UTF(UCS Transformation Format)规范规定的，常见的UTF规范包括UTF-8、UTF-7、UTF-16。

而ucs分成ucs-2与ucs-4。基本上在现实应用中，可以忽略ucs-4（基本上没有软件使用它）

UCS有两种格式：UCS-2和UCS-4。顾名思义，UCS-2就是用两个字节编码，UCS-4就是用4个字节（实际上只用了31位，最高位必须为0）编码。

UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-8的编码方式如下：

例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间，所以肯定要用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 110001 001001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。

读者可以用记事本测试一下我们的编码是否正确。

UTF-16以16位为单元对UCS进行编码。对于小于0x10000的UCS码，UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于0x10000的UCS码，定义了一个算法。不过由于实际使用的UCS2，或者UCS4的BMP必然小于0x10000，所以就目前而言，可以认为UTF-16和UCS-2基本相同。但UCS-2只是一个编码方案，UTF-16却要用于实际的传输，所以就不得不考虑字节序的问题。

UTF的字节序和BOM

UTF-8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”，那么这是“奎”还是“乙”？

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：

在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。

这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF（读者可以用我们前面介绍的编码方法验证一下）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

 实际在我们用vc编写程序的时候，unicode就基本是用ucs。

上上周一直在折腾一个旧磁盘阵列.

在RedHat AS4.0 上面倒是轻松就可以找到这个阵列.只是开始的时候出了点麻烦.

我为这个阵列的每个通道都映射了二个分区.折腾许久之后,发现安装的Linux只认识一个分区.

打电话问磁盘阵列厂家的技术人员,没有什么结果,显然,他没遇上这样的事情.

最后自己找到了解决办法:

然后reboot就ok了.

最后用: fdisk -l

Disk /dev/sda: 1689.5 GB, 1689549537280 bytes
Disk /dev/sdb: 1830.3 GB, 1830348128256 bytes
Disk /dev/sdc: 1689.5 GB, 1689549537280 bytes
Disk /dev/sdd: 1830.3 GB, 1830348128256 bytes

显然 sda与sdc是重复的,sdb与sdd 是重复的.这我不知道如何处理了,在windows 2003中也显示有四个磁盘.不管他了.

最后在我把这个东东折腾好之后,竟然在redhat的网站上找到了相关资料,晕.谁让我对linux投入太少.顺便把url记一

 如何使红帽企业Linux4支持多LUN?

http://www.redhat.com.cn/kbase/5583.php

最后要讲一下的是我折腾XManager的事情.其实把Xmanager用起来不麻烦.麻烦的是我在.bash_profile

设置了 DISPLAY=a.b.c.d:0

这一个设置害得我花了太多时间,对于XManager来说,完全是画蛇添足.

1.[root@hot158 ~]# uname -a

Linux hot158 2.6.9-42.ELsmp #1 SMP Tue Aug 15 10:35:26 BST 2006 x86_64 x86_64 x86_64 GNU/Linux

2.[root@hot158 ~]# cp /boot/initrd-2.6.9-42.ELsmp.img /boot/initrd-2.6.9-42.ELsmp.old

3.添加以下内容到/etc/modprobe.conf

options scsi_mod max_luns=xxx

(xxx是scsi_mod需要支持LUN的数目，如255)

4. 为了使修改有效，创建启动内存磁盘

mkinitrd -f /boot/initrd-2.6.9-42.ELsmp.img  2.6.9-42.ELsmp

 -=========================

Xmanager:
1. /etc/X11/xdm/Xaccess 文件，去掉这行的注释。
# * #any host can get a login windows"
2.

#vi /etc/X11/xdm/xdm-config

在最后一行： DisplayManager.requestPort: 0 前面加！号注释掉此行。

#vi /etc/X11/xdm/Xservers

在最后一行：:0 local /usr/X11R6/bin/X 前面加#号注释掉这一行。
3. /etc/X11/gdm/gdm.conf文件，
[xdmcp]部分，把enable 改为 true
4. /etc/kde/kdm/kdmrc文件，
[Xdmcp]部分，把enable 改为 true
5. /etc/inittab 修改运行级别为5 (X11) ，如果为3的话，你看到的将不是桌面，而是命令行窗口。
6. 防火墙 增加177端口
7. reboot

如果想要每次启动自动启动xdm，那么请在/etc/rc.d/rc.local文件尾部加入/etc/X11R6/bin/xdm