UWP编程对文本编码的处理

TonyDeng UID.2870126
2018-08-26 发表

本帖最后由 TonyDeng 于 2018-8-26 05:46 编辑

UWP是国际化的编程框架,其默认文本编码是UTF-8,但是我们的系统一般是大陆区,文本编码默认是GB2312,这是两种不同的编码,如果直接使用UWP的FileIO读写由系统生成的文本文件(.txt),会出现错误,或者是报告无法读取,或者是读出乱码。一般手工的操作,是生成文本文件之后,把它“另存为”UTF-8编码的文件,然后让UWP应用去读。但是,如果我们有大量的现成文本文件需要读取(比如从网上下载的txt小说,或者是从Word、Excel等导出的数据),这样处理是不可忍受的,最直接的办法是让UWP应用读GB2312的文件自己在內部转码。这个操作的编程步骤如下: 首先注册自己当前的应用使用系统默认编码 Encoding.RegisterProvider(CodePagesEncodingProvider.Instance); 这行代码放在应用的入口即可。 应用中,用Picker选中需要的StorageFile类型文件file,这是Windows运行时的文件类型,然而转码时必须使用.NET的类型,为此使用如下代码把两者连接起来 Stream stream = await file.OpenStreamForReadAsync(); 这样,stream流就是.NET的Stream类型,可以使用.NET的文本转码功能进行转码了。 把文件内容全部读入内存中,此时不要使用文本模式,必须使用原始的字节读取 int length = (int)file.Length; // 获取文件的字节数,默认是long,但是要强制为int,因为後面的函数只用int byte[] buffer = new byte(length); // 创建内存数组,用于储存读入的数据 await stream.ReadAsync(buffer, 0, length); // 把文件内容读入到数组中 把数据读入到数组中之后,使用.NET的转码功能进行转码 string text = Encoding.GetEncoding(0).GetString(buffer); 这里Encoding.GetEncoding(0)就是系统默认的ANSI编码,随系统的设置而变。大陆简体系统一般是GB2312,系统显示是ANSI,它既不是内定的Unicode-16,也不是UTF-8,总之在Windows运行时中是没有这种编码的,这就是吊诡之处。系统中的ANSI=GB2312,这里所谓GB2312其实是GB集,包括GBK和GB18030,并非最早的一、二级简体中文字符集,而是包括繁体汉字在内的两万多个汉字字符的字符集,它对应的CodePage=936。 这样处理之后,text字符串就可以在UWP程序中显示和编辑了。

敬告:
为防止不可控的内容风险,本站已关闭新用户注册,新贴的发表及评论;
你现在看到的内容只是互联网用户曾经发表的言论快照,仅用于老用户留存纪念,且仅与科技行业相关,全部内容不代表本站观点及立场;
本站重新开放前已针对包括用户隐私、版权保护、信息安全、国家政策在内的各种互联网法律法规要求,执行了隐患内容的自查、屏蔽和删除;
本站目前所属个人主体,未有任何盈利安排与计划,且与原WFUN.COM所属公司不存在任何关联关系;
如果本帖内容或者相关资源侵犯到您的合法权益,或者您认为存在问题,那么请您务必点此举报或投诉!
全部回复:
太学主 UID.2954924
2018-08-26 使用 Lumia 920 回复

路过。。

TonyDeng UID.2870126
2018-08-26 回复

GBK可以显示繁体汉字,但它与港台的繁体系统是不同的,後者是Big5编码。看起来是一样的繁体字,两种编码方案下的编码是不一样的,不要看到繁体字就说是港台的。简体对应CP936,繁体对应CP950。

辛勤的蜜蜂 UID.813897
2018-08-26 使用 Lumia 950 XL 回复

你是个专业人士。

artfly08 UID.2900999
2018-08-26 使用 Lumia 950 XL 回复

开发者,支持

TonyDeng UID.2870126
2018-08-26 回复

本帖最后由 TonyDeng 于 2018-8-27 00:00 编辑

关于字符编码的一些直观感觉,看图: ***图片停止解析*** 先不管英文,看汉字。图中我输入了“啊”字,它的Unicode编码是4A55或554A(以下全部是十六进制),占2字节空间,然而UTF-8编码是E5958A,占3字节空间,前者是固定宽度的2字节,後者却是可变宽度的,一般来说,一个汉字基本占3字节空间,当在网络上传播的文本数据以汉字居多时,其实用UTF-8编码更耗资源,所以一般要压缩。 关键之处,是留意GB码与Unicode码的区别:虽然都是2字节的数据,但内容完全不同,GB是B0A1,与Unicode的4A55或554A根本不搭界。所以,如果一份文本文檔被错误理解其编码的时候,得到的就完全不是它原本希望表达的字,那就是乱码的来源。当把UTF-8当做GB或反过来的时候,更糟糕,因为连字长都分割错了。

no****df UID.2968908
2018-08-27 回复

***图片停止解析***不明觉厉

artfly08 UID.2900999
2018-08-31 使用 Lumia 950 XL 回复

支持

本站使用Golang构建,点击此处申请开源鄂ICP备18029942号-4联系站长投诉/举报