WritePrivateProfileString-不可预测 [英] WritePrivateProfileString - is unpredictable

查看:239
本文介绍了WritePrivateProfileString-不可预测的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在使用内部使用简单Win-Api调用WritePrivateProfileString的工具.

我知道定义标志UNICODE可以映射到WritePrivateProfileString**A**WritePrivateProfileString**W**

我正在向INI文件写入内容,该文件以前不存在.

在某些系统上,它的行为也有所不同.为什么?

例如:字符§"在ASCI中为A7(十六进制),有时被编写为Unicode格式C2 A7(十六进制). 但仅在某些系统上,我不知道为什么?!编写ANSI或UNICODE的系统条件是什么?

我试图先创建文件,然后再写入文件,甚至试图定义格式,方法是先添加一些字符,因为我认为WritePrivateProfileString在内部使用isTextUnicode, 但这里没有机会.

是否有人以正确的方式理解此API文档:
https://docs.microsoft.com/zh-cn/windows/win32/api/winbase/nf-winbase-writeprivateprofilestringa

如果文件是使用Unicode字符创建的,则该函数会将Unicode字符写入文件.否则,该函数将写入ANSI字符.

我在这里不能完全同意本文档.我知道我在某种程度上一定是错的;-)还是该怎么做对呢?

我们想要做的就是在任何情况下都将ANSI纯文本写入INI文件. (我无法将其更改为方法WritePrivateProfileString**A**,因为我们使用的是内部仅使用WritePrivateProfileString函数的工具.)不管怎样,它可以正确地用于90%的PC,但是在某些情况下,我们仍然可以使用INI文件中的unicode字母.

我也知道ASCI不是最新技术,但是我们正在对该INI值和"A7"值进行一些CRC计算.不是"C2 A7",这会导致错误计算,这就是为什么我们需要纯ASCII格式的背景.

谢谢您的帮助.

解决方案

我找到了根本原因:
https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows

2018年4月,针对Windows 10的内部版本17035(名义版本17134)发布了测试版:使用Unicode UTF-8进行全球语言支持".出现了用于将区域设置代码页设置为UTF-8的复选框.具有UTF-8字符串的函数,包括fopen和SetWindowTextA.在2019年5月,Microsoft增加了程序将代码页设置为UTF-8本身的功能,并开始建议所有软件都这样做,并专门使用UTF-8.

此设置在某些系统上已激活,它负责将我期望的ANSI代码更改为INI文件中的UNICODE.

是的,我知道将来我们必须朝UNICODE的方向前进.但是现在微软也将我们推向这个方向,这还不错,但是我以前并不知道这种设置或策略.

@IInspectable:是的,您是对的0xA7不是ASCII,而是ANSI(或ASCII-8,扩展ASCII),我把它弄混了,谢谢.

We are using a tool that uses internally the simple Win-Api call WritePrivateProfileString.

I'm aware of the define flag UNICODE to map either to WritePrivateProfileString**A** or WritePrivateProfileString**W**

I am writing something to the INI file, that file doesn't exist before.

And it behaves differently on some systems. Why?

For example: a character "§" which is A7 (hex) in ASCI, is sometimes written as Unicode format C2 A7 (hex). but only on some systems, and I don't know WHY?! What is the system-condition for writing ANSI or UNICODE?

I was trying to create the file first, before writing to it and even tried to define the format, by adding some characters already, cause I thought WritePrivateProfileString is using isTextUnicode internally, but no chance here.

Does anybody understand this API-Documentation in the right way:
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-writeprivateprofilestringa

If the file was created using Unicode characters, the function writes Unicode characters to the file. Otherwise, the function writes ANSI characters.

I can not really agree to this documentation here. I know I must be wrong here somehow ;-) Or how to do that right?

All that we want is to write in ANY case to ANY system just plain ANSI to the INI-file. (I can't change it to the method WritePrivateProfileString**A** cause we are using a tool that just uses the WritePrivateProfileString function internally.) Anyhow, it works for 90% of the PC's out there correct, but on some we have still unicode letters in the INI file.

I also know ASCI is not state-of-the-art, but we are performing some CRC-calculation of that INI values and "A7" is not "C2 A7", which leads to a miss-calculation, that's the background why we need plain ASCII format.

Thank you for any help.

解决方案

I found the root cause:
https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows

In April 2018 with insider build 17035 (nominal build 17134) for Windows 10, a "Beta: Use Unicode UTF-8 for worldwide language support" checkbox appeared for setting the locale code page to UTF-8.[a] This allows for calling "narrow" functions, including fopen and SetWindowTextA, with UTF-8 strings. In May 2019 Microsoft added the ability for a program to set the code page to UTF-8 itself, and started recommending that all software do this and use UTF-8 exclusively.

This setting was activated on some systems and it was responsible for changing my expected ANSI code to UNICODE in the INI-file.

Yes, I understand that we have to go in the UNICODE direction in the future. But now also Microsoft is pushing us to this direction, which is not bad, but I was not aware of this setting or strategy before.

@IInspectable: yes you are right 0xA7 is not ASCII but ANSI (or ASCII-8, Extended ASCII) I had mixed it up, thank you.

这篇关于WritePrivateProfileString-不可预测的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆