| 网站首页 | 业界新闻 | 小组 | 威客 | 人才 | 下载频道 | 博客 | 代码贴 | 在线编程 | 编程论坛
欢迎加入我们,一同切磋技术
用户名:   
 
密 码:  
共有 1308 人关注过本帖
标题:Strconv(C, N)的第2个参数N是5或12时,我一看就有点儿头大!
只看楼主 加入收藏
csyx
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
来 自:火星
等 级:版主
威 望:37
帖 子:708
专家分:2848
注 册:2018-3-13
收藏
得分:0 
以下是引用吹水佬在2022-11-17 23:36:48的发言:

WideCharToMultiByte、MultiByteToWideChar 主要是用来互相转换,同时也能返回字数,注意,是字数,不是字节数。
通式的话,就算返回给你UTF8的字数,字节数也不好猜测,只求长度什么API都不用吧。

我说的也是字符数而非字节数,字节数谁都会数数
图片附件: 游客没有浏览图片的权限,请 登录注册

图片附件: 游客没有浏览图片的权限,请 登录注册

这家伙很懒,啥也没留下
2022-11-18 01:19
吹水佬
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:版主
威 望:451
帖 子:10608
专家分:43186
注 册:2014-5-20
收藏
得分:0 
回复 11楼 csyx
就是了
还是回到VFP的问题,VFP没有“字”的概念,顶多也是双字节、宽字符。W带头的通常也是指“宽字符”,所以VFP调用W***()通常要用到STRCONV(...,5)。
VFP提到的UNICODE也只有局限到一些,至于UNICODE的“字”,通常有8bit、16bit、24bit、32bit、40bit、48bit...甚至更多bit。
VFP如何精准获取UNICODE字符串,尤其是从文件中获取,甚至在超大文件中获取,通常是要通过缓冲来处理。

2022-11-18 07:52
cssnet
Rank: 5Rank: 5
等 级:职业侠客
威 望:5
帖 子:351
专家分:335
注 册:2013-10-4
收藏
得分:0 
严格说来,utf-16其实是不定长的。在Unicode基本平面定义的字符,没错儿是2字节;而在辅助平面定义的字符,则为两个2字节(即4字节)。
故而,若追求定长,那必须是UTF-32,每个字符都使用4字节。当然那样一来,存储英文的磁盘空间,就多了三倍。存储中文,也比ANSI多了将近1倍。
不能因为Windows API是utf-16,就说它好啊。
USC-2我也觉得爽哇!偷懒时当然我也曾这么干:

LenByte = len(c)
LenUnicode = int(LenByte/2)
假装Unicde == USC-2,假装用户不可能用到辅助平面定义的字符。

只是,在VFP这种ANSI内核的环境之下,若需处理Unicode,那么,转换成UTF-8,可能是最优、最安全的方案,没有之一。
2022-11-18 09:11
快速回复:Strconv(C, N)的第2个参数N是5或12时,我一看就有点儿头大!
数据加载中...
 
   



关于我们 | 广告合作 | 编程中国 | 清除Cookies | TOP | 手机版

编程中国 版权所有,并保留所有权利。
Powered by Discuz, Processed in 0.017494 second(s), 9 queries.
Copyright©2004-2024, BCCN.NET, All Rights Reserved