如果 TECGetTextEncodingFromInternetName() 需要 Pascal 风格的字符串,为什么 CopyCStringToPascal() 在 OSX 10.5 中不再使用?
我的责任是为 OSX 10.5 构建旧版本的开源库。 (该库是 Xerces 2.8。)
由于(除其他外)使用已停止使用的 OSX 函数 CopyCStringToPascal()
,该库无法在 OSX 10.5 上进行开箱即用的构建。相关的代码片段是:
Str255 pasEncodingName;
...
CopyCStringToPascal(cEncodingName, pasEncodingName);
TECGetTextEncodingFromInternetName (&textEncoding, pasEncodingName);
调查显示,CopyCStringToPascal() 确实将 C 字符串转换为 Pascal 风格的字符串(第一个字节提供字符串中字符数的字符串) )。因此,从上下文来看,很明显,TECGetTextEncodingFromInternetName()
的第二个参数必须是 Pascal 风格的字符串(尽管我在互联网上搜寻的任何文档中都找不到证实这一点的信息)。
因为最新版本的开源库 (Xerces 3.1) 成功构建在 OSX 10.5 上,并且其实现都显式定义了函数 CopyCStringToPascal()
(因为它在 OSX 10.5 中已停止使用)来创建Pascal 风格的字符串,并继续使用 TECGetTextEncodingFromInternetName()
(在 OSX 中尚未停止使用) 10.5),我相信这证实了即使对于 OSX 10.5,TECGetTextEncodingFromInternetName()
确实仍然需要 Pascal 风格的字符串。
因为当前的 OSX 10.5 系统例程仍然需要 Pascal 风格的字符串,所以我很困惑为什么转换为如此必要的 Pascal 字符串的函数 CopyCStringToPascal()
在 OSX 10.5 中已不再使用。我写这个问题是为了进一步确认我没有犯错误,只是简单地为 Xerces 2.8 显式定义这个函数(并且在与此讨论相关的代码区域中不进行任何更改)以使 Xerces 2.8 能够使用 OSX 10.5 构建。谢谢。
It is my responsibility to build an old version of an open-source library for OSX 10.5. (The library is Xerces 2.8.)
The library fails to build out-of-the-box on OSX 10.5 due to (among other things) use of the discontinued OSX function CopyCStringToPascal()
. The relevant code snippet is:
Str255 pasEncodingName;
...
CopyCStringToPascal(cEncodingName, pasEncodingName);
TECGetTextEncodingFromInternetName (&textEncoding, pasEncodingName);
Investigation has shown that CopyCStringToPascal()
does, indeed, convert a C string into a Pascal-style string (a string for which the first byte provides the number of characters in the string). Therefore, from context, it is clear that the second parameter to TECGetTextEncodingFromInternetName()
must be a Pascal-style string (although I cannot find this confirmed in any documentation from scavenging the internet).
Because the newest version of the open-source library (Xerces 3.1) successfully builds on OSX 10.5, and its implementation both explicitly defines the function CopyCStringToPascal()
(since it has been discontinued in OSX 10.5) to create a Pascal-style string, and continues to use TECGetTextEncodingFromInternetName()
(which has not been discontinued in OSX 10.5), I trust this to be confirmation that indeed TECGetTextEncodingFromInternetName()
continues to require a Pascal-style string even for OSX 10.5.
Because Pascal-style strings are STILL required by current OSX 10.5 system routines, I am mystified as to why the function CopyCStringToPascal()
, which converts to such a necessary Pascal string, has been discontinued in OSX 10.5. I'm writing this question in order to further confirm that I am not making a mistake by simply defining this function explicitly for Xerces 2.8 (and otherwise changing nothing in the area of the code relevant to this discussion) in order to get Xerces 2.8 to build with OSX 10.5. Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
升级路径共有三种,均通过CFString。
第一种方法(Grady Player 已经建议)是使用 CFString 将编码名称转换为 Pascal 字符串。您可以从 CFString 中的编码名称开始(使用
CFSTR
宏);如果没有,您可以从 C 字符串创建一个 CFString,并从 CFString 创建一个 Pascal 字符串。第二种是使用CFString,而不是文本编码转换管理器,将编码名称转换为编码标识符。 CFString 和 TEC 都使用相同的标识符(比较 CFStringEncodingExt.h 和 TextCommon.h 之间的常量),因此您可以使用
CFStringConvertIANACharSetNameToEncoding
(将编码名称作为 CFString)来获取编码标识符。如果您将编码标识符从 CF 传递到 TEC,这有点作弊,但只要 Apple 认为不适合无缘无故地更改所有常量,它就会起作用。第三种是使用 CFString 进行转换本身。使用
CFStringCreateWithBytes
从输入创建 CFString,并使用CFStringGetBytes
确定输出长度,然后再次执行转换。该解决方案完全放弃了 TEC。虽然 TEC 本身尚未被弃用(尚未),但如果它需要使用或重新发明已被弃用/删除的其他 API 才能使其正常工作,那么对于基于 TEC 的代码的寿命而言,这也是一个坏兆头。我建议提交错误,要求在 TEC 中对
TECGetTextEncodingFromInternetName
进行现代替代;您可以根据您的请求得到的响应来决定要做什么。There are three upgrade paths, all through CFString.
The first, already suggested by Grady Player, is to use CFString to convert the encoding name to a Pascal string. You may be able to start with the encoding name in a CFString (using the
CFSTR
macro); if not, you can create a CFString from the C string, and a Pascal string from the CFString.The second is to use CFString, instead of Text Encoding Conversion Manager, to convert the encoding name to an encoding identifier. CFString and TEC both use the same identifiers (compare the constants between CFStringEncodingExt.h and TextCommon.h), so you can use
CFStringConvertIANACharSetNameToEncoding
—which takes the encoding name as a CFString—to get the encoding identifier. If you pass the encoding identifier from CF to TEC, this is sort of cheating, but as long as Apple doesn't see fit to change all the constants for no apparent reason, it'll work.The third is to use CFString for the conversion itself. Create a CFString from the input using
CFStringCreateWithBytes
, and useCFStringGetBytes
to determine the output length and then again to perform the conversion. This solution drops TEC entirely.While TEC itself isn't deprecated (yet), if it requires the use or reinvention of other APIs that have been deprecated/removed to make it work, that's also a bad sign for the longevity of your TEC-based code. I suggest filing a bug to ask for a modern replacement in TEC for
TECGetTextEncodingFromInternetName
; you can decide what to do based on the response you get to your request.如果您只是搜索 CFString 参考从我收集到的信息中,您会看到一些与 Pascal 匹配的内容...
尝试
如果失败,请使用:
另外,我没有看到它在哪里说您应该使用 pascal 字符串。
if you just search CFString reference you see a few things that match Pascal, from what I can glean...
try
if that fails, use:
Also I don't see where it says you are supposed to use a pascal string.