procedure TForm1.Button1Click(Sender: TObject); var S: string; T: string; I: Integer; begin S := 'a,b,c,.,.,中,国,人,'; T := ''; for I := 1 to Length(WideString(S)) do if Length(string(WideString(S)[I])) = 2 then T := T + WideString(S)[I]; Caption := T; end;
procedure TForm1.Button1Click(Sender: TObject); var S, T: WideString; vData: string; I: Integer; begin with TFileStream.Create(ParamStr(0), fmShareDenyNone) do try Caption := IntToStr(Size); SetLength(vData, Size); if Size <> 0 then Read(vData[1], Size); finally Free; end; S := vData; T := ''; for I := 1 to Length(S) do case Ord(S[I]) of $4E00..$9FA5: T := T + S[I]; //汉字总数: U+4E00(19968)到U+9FA5(40869)共20902个汉字 $FF00..$FFFF: T := T + S[I]; //符号 end; Memo1.Text := T; end;
from <<Programming Windows>>Unicode解决方案 我们面临的基本问题是世界上的书写语言不能简单地用256个8位元代码表示。以前的解决方案包括内码表和DBCS已被证明是不能满足需要的,而且也是笨拙的。那什么才是真正的解决方案呢?身为程式写作者,我们经历过这类问题。如果事情太多,用8位元数值已经不能表示,那么我们就试更宽的值,例如16位元值。而且这很有趣的,正是Unicode被制定的原因。与混乱的256个字元代码映射,以及含有一些1位元组代码和一些2位元组代码的双位元组字元集不同,Unicode是统一的16位元系统,这样就允许表示65,536个字元。这对表示所有字元及世界上使用象形文字的语言,包括一系列的数学、符号和货币单位符号的集合来说是充裕的。明白Unicode和DBCS之间的区别很重要。Unicode使用(特别在C程式设计语言环境里)「宽字元集」。「Unicode中的每个字元都是16位元宽而不是8位元宽。」在Unicode中,没有单单使用8位元数值的意义存在。相比之下,在双位元组字元集中我们仍然处理8位元数值。有些位元组自身定义字元,而某些位元组则显示需要和另一个位元组共同定义一个字元。处理DBCS字串非常杂乱,但是处理Unicode文字则像处理有秩序的文字。您也许会高兴地知道前128个Unicode字元(16位元代码从0x0000到0x007F)就是ASCII字元,而接下来的128个Unicode字元(代码从0x0080到0x00FF)是ISO 8859-1对ASCII的扩展。Unicode中不同部分的字元都同样基於现有的标准。这是为了便於转换。希腊字母表使用从0x0370到0x03FF的代码,斯拉夫语使用从0x0400到0x04FF的代码,美国使用从0x0530到0x058F的代码,希伯来语使用从0x0590到0x05FF的代码。中国、日本和韩国的象形文字(总称为CJK)占用了从0x3000到0x9FFF的代码
请问楼主你的: with TFileStream.Create(ParamStr(0), fmShareDenyNone) do try Caption := IntToStr(Size); SetLength(vData, Size); if Size <> 0 then Read(vData[1], Size); finally Free; end;这段代码是做什么用的呀,Caption还不要定义的吗,能加点解释不??TKS~~
to keconghua: 楼主?发贴的人才叫楼主 你自己才是楼主明白不?Caption是TForm的属性,是输出用的 那段代码是测试用的可以省略 目的就是得到vData-用来测试的字符串你自己不提供调试的代码和模拟数据,唉~~~
var
S: string;
T: string;
I: Integer;
begin
S := 'a,b,c,.,.,中,国,人,';
T := '';
for I := 1 to Length(WideString(S)) do
if Length(string(WideString(S)[I])) = 2 then
T := T + WideString(S)[I];
Caption := T;
end;
我目前的一个字串有5000多个文件内容合起来的,所以得到的数据有很多是乱码
高手继续指点,谢谢~~
var
S, T: WideString;
vData: string;
I: Integer;
begin
with TFileStream.Create(ParamStr(0), fmShareDenyNone) do try
Caption := IntToStr(Size);
SetLength(vData, Size);
if Size <> 0 then Read(vData[1], Size);
finally
Free;
end;
S := vData;
T := '';
for I := 1 to Length(S) do
case Ord(S[I]) of
$4E00..$9FA5: T := T + S[I]; //汉字总数: U+4E00(19968)到U+9FA5(40869)共20902个汉字
$FF00..$FFFF: T := T + S[I]; //符号
end;
Memo1.Text := T;
end;
我们面临的基本问题是世界上的书写语言不能简单地用256个8位元代码表示。以前的解决方案包括内码表和DBCS已被证明是不能满足需要的,而且也是笨拙的。那什么才是真正的解决方案呢?身为程式写作者,我们经历过这类问题。如果事情太多,用8位元数值已经不能表示,那么我们就试更宽的值,例如16位元值。而且这很有趣的,正是Unicode被制定的原因。与混乱的256个字元代码映射,以及含有一些1位元组代码和一些2位元组代码的双位元组字元集不同,Unicode是统一的16位元系统,这样就允许表示65,536个字元。这对表示所有字元及世界上使用象形文字的语言,包括一系列的数学、符号和货币单位符号的集合来说是充裕的。明白Unicode和DBCS之间的区别很重要。Unicode使用(特别在C程式设计语言环境里)「宽字元集」。「Unicode中的每个字元都是16位元宽而不是8位元宽。」在Unicode中,没有单单使用8位元数值的意义存在。相比之下,在双位元组字元集中我们仍然处理8位元数值。有些位元组自身定义字元,而某些位元组则显示需要和另一个位元组共同定义一个字元。处理DBCS字串非常杂乱,但是处理Unicode文字则像处理有秩序的文字。您也许会高兴地知道前128个Unicode字元(16位元代码从0x0000到0x007F)就是ASCII字元,而接下来的128个Unicode字元(代码从0x0080到0x00FF)是ISO 8859-1对ASCII的扩展。Unicode中不同部分的字元都同样基於现有的标准。这是为了便於转换。希腊字母表使用从0x0370到0x03FF的代码,斯拉夫语使用从0x0400到0x04FF的代码,美国使用从0x0530到0x058F的代码,希伯来语使用从0x0590到0x05FF的代码。中国、日本和韩国的象形文字(总称为CJK)占用了从0x3000到0x9FFF的代码
with TFileStream.Create(ParamStr(0), fmShareDenyNone) do try
Caption := IntToStr(Size);
SetLength(vData, Size);
if Size <> 0 then Read(vData[1], Size);
finally
Free;
end;这段代码是做什么用的呀,Caption还不要定义的吗,能加点解释不??TKS~~
楼主?发贴的人才叫楼主
你自己才是楼主明白不?Caption是TForm的属性,是输出用的
那段代码是测试用的可以省略
目的就是得到vData-用来测试的字符串你自己不提供调试的代码和模拟数据,唉~~~