Question

让我通过这样说来预示：我绝不是Windows程序员。请纠正我可能存在的任何误解，帮助我。

我的理解是Windows具有（传统的）单字节字符串接口和现代化的Unicode接口。

我的目标是仔细检查在Windows内核中实现的cp1252。我将从Windows XP开始，但我打算尽可能多地检查版本。

我打算将这样一个程序的输出格式化为：https://encoding.spec.whatwg.org/index-windows-1252.txt

我的问题主要是：我将使用哪些Windows API函数来完成上述任务？我认为这是mbstowcs_s。

其次：我必须写C才能检查相关接口吗？如果是这样，我会使用什么编译器？我认为Visual Studio Express 2010是一个很好的匹配，但我找不到任何（合法的）下载它的地方。

对于那些必须知道X到Y的人，有两个竞争标准和cp1252的实现。它们之间略有不同，但确实有所不同，这对我来说很重要。

WHATWG指定，所有浏览器都实现此标准： https://encoding.spec.whatwg.org/index-windows-1252.txt

Microsoft指定，python实现此标准： http://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT

不同之处在于五个不可打印的字符。在Windows规范中，它们完全未定义，因此这些字节不能通过cp1252进行往返。在WHATWG规范（以及所有浏览器）中，这些字节映射到相同值的非打印字符，如latin1，这意味着这些字节可以通过cp1252成功往返。

我强烈怀疑微软的实施实际上与WHATWG规范和浏览器的实现相匹配，而不是他们发布的规范。这就是我试图在上面证明/反驳的。

Answer 1

使用@ abernert的帮助，我想出了这个。总而言之，微软的规范与他们的实现不符，我怀疑：

from ctypes import cdll, windll, c_char_p
c = cdll.msvcrt
k = windll.kernel32
LC_ALL = 0  # from locale.h
# reference: https://msdn.microsoft.com/en-US/library/x99tb11d.aspx
c.setlocale.restype = c_char_p
result = c.setlocale(LC_ALL, '.1252')
assert result == 'English_United States.1252', result

from ctypes import create_string_buffer
# cp1252 is classified as "multi-byte" by the msapi along with utf8
mb = create_string_buffer(1)
wc1 = create_string_buffer(2)
wc2 = create_string_buffer(2)

print 'IN | MSVC  KERN'
print '---+-----------'
for b in range(0x80, 0xA0):
    mb.value = chr(b)

    # reference: https://msdn.microsoft.com/en-us/library/yk02bkxb.aspx
    result = c.mbtowc(wc1, mb, 1)
    assert result == 1, result

    # reference:
    #     https://msdn.microsoft.com/en-us/library/windows/desktop/dd319072.aspx
    result = k.MultiByteToWideChar(1252, 0, mb, 1, wc2, 1)
    assert result == 1, result

    print '%02X | %02X%02X  %02X%02X' % (
        ord(mb.value),
        # little-endian:
        ord(wc1.raw[1]), ord(wc1.raw[0]),
        ord(wc2.raw[1]), ord(wc2.raw[0]),
    )

输出:(在Windows XP，Vista，7,8.1上测试）

IN | MSVC  KERN
---+-----------
80 | 20AC  20AC
81 | 0081  0081
82 | 201A  201A
83 | 0192  0192
84 | 201E  201E
85 | 2026  2026
86 | 2020  2020
87 | 2021  2021
88 | 02C6  02C6
89 | 2030  2030
8A | 0160  0160
8B | 2039  2039
8C | 0152  0152
8D | 008D  008D
8E | 017D  017D
8F | 008F  008F
90 | 0090  0090
91 | 2018  2018
92 | 2019  2019
93 | 201C  201C
94 | 201D  201D
95 | 2022  2022
96 | 2013  2013
97 | 2014  2014
98 | 02DC  02DC
99 | 2122  2122
9A | 0161  0161
9B | 203A  203A
9C | 0153  0153
9D | 009D  009D
9E | 017E  017E
9F | 0178  0178

将此与Microsoft在unicode.org注册的the spec进行比较：

0x80    0x20AC  #EURO SIGN
0x81            #UNDEFINED
0x82    0x201A  #SINGLE LOW-9 QUOTATION MARK
0x83    0x0192  #LATIN SMALL LETTER F WITH HOOK
0x84    0x201E  #DOUBLE LOW-9 QUOTATION MARK
0x85    0x2026  #HORIZONTAL ELLIPSIS
0x86    0x2020  #DAGGER
0x87    0x2021  #DOUBLE DAGGER
0x88    0x02C6  #MODIFIER LETTER CIRCUMFLEX ACCENT
0x89    0x2030  #PER MILLE SIGN
0x8A    0x0160  #LATIN CAPITAL LETTER S WITH CARON
0x8B    0x2039  #SINGLE LEFT-POINTING ANGLE QUOTATION MARK
0x8C    0x0152  #LATIN CAPITAL LIGATURE OE
0x8D            #UNDEFINED
0x8E    0x017D  #LATIN CAPITAL LETTER Z WITH CARON
0x8F            #UNDEFINED
0x90            #UNDEFINED
0x91    0x2018  #LEFT SINGLE QUOTATION MARK
0x92    0x2019  #RIGHT SINGLE QUOTATION MARK
0x93    0x201C  #LEFT DOUBLE QUOTATION MARK
0x94    0x201D  #RIGHT DOUBLE QUOTATION MARK
0x95    0x2022  #BULLET
0x96    0x2013  #EN DASH
0x97    0x2014  #EM DASH
0x98    0x02DC  #SMALL TILDE
0x99    0x2122  #TRADE MARK SIGN
0x9A    0x0161  #LATIN SMALL LETTER S WITH CARON
0x9B    0x203A  #SINGLE RIGHT-POINTING ANGLE QUOTATION MARK
0x9C    0x0153  #LATIN SMALL LIGATURE OE
0x9D            #UNDEFINED
0x9E    0x017E  #LATIN SMALL LETTER Z WITH CARON
0x9F    0x0178  #LATIN CAPITAL LETTER Y WITH DIAERESIS

我很清楚标记为UNDEFINED（字节81 8D 8F 90和9D）的插槽不是未定义的，不是错误，而是解码为等序数的不可打印字符，就像在the WHATWG spec中那样，下面：

  0 0x20AC  € (EURO SIGN)
  1 0x0081   (<control>)
  2 0x201A  ‚ (SINGLE LOW-9 QUOTATION MARK)
  3 0x0192  ƒ (LATIN SMALL LETTER F WITH HOOK)
  4 0x201E  „ (DOUBLE LOW-9 QUOTATION MARK)
  5 0x2026  … (HORIZONTAL ELLIPSIS)
  6 0x2020  † (DAGGER)
  7 0x2021  ‡ (DOUBLE DAGGER)
  8 0x02C6  ˆ (MODIFIER LETTER CIRCUMFLEX ACCENT)
  9 0x2030  ‰ (PER MILLE SIGN)
 10 0x0160  Š (LATIN CAPITAL LETTER S WITH CARON)
 11 0x2039  ‹ (SINGLE LEFT-POINTING ANGLE QUOTATION MARK)
 12 0x0152  Œ (LATIN CAPITAL LIGATURE OE)
 13 0x008D   (<control>)
 14 0x017D  Ž (LATIN CAPITAL LETTER Z WITH CARON)
 15 0x008F   (<control>)
 16 0x0090   (<control>)
 17 0x2018  ‘ (LEFT SINGLE QUOTATION MARK)
 18 0x2019  ’ (RIGHT SINGLE QUOTATION MARK)
 19 0x201C  “ (LEFT DOUBLE QUOTATION MARK)
 20 0x201D  ” (RIGHT DOUBLE QUOTATION MARK)
 21 0x2022  • (BULLET)
 22 0x2013  – (EN DASH)
 23 0x2014  — (EM DASH)
 24 0x02DC  ˜ (SMALL TILDE)
 25 0x2122  ™ (TRADE MARK SIGN)
 26 0x0161  š (LATIN SMALL LETTER S WITH CARON)
 27 0x203A  › (SINGLE RIGHT-POINTING ANGLE QUOTATION MARK)
 28 0x0153  œ (LATIN SMALL LIGATURE OE)
 29 0x009D   (<control>)
 30 0x017E  ž (LATIN SMALL LETTER Z WITH CARON)
 31 0x0178  Ÿ (LATIN CAPITAL LETTER Y WITH DIAERESIS)

Answer 2

你的问题没有任何意义。你想检查＆＃34;编码＆＃34;每个版本的Windows从95到10使用。

但是，这些版本的Windows都没有＆＃34;编码＆＃34;。它们中的每一个都可以以相同的方式配置：它具有由Microsoft预先配置的默认系统编码，以及由Microsoft或系统OEM设置但用户可以更改的当前用户编码。因此，您的测试不依赖于Windows 95与Windows 7，它依赖于Microsoft的美国Windows 95默认设置与Microsoft的Windows Windows 95默认设置与HP的Windows 95相比使用默认设置与Microsoft的US Windows 95以及控制面板中的238种可能选项

此外，要生成您尝试生成的文件类型，您不需要触摸任何Win32 API。您需要做的就是调用任何使用已配置的系统区域设置字符集的函数来将单字节/多字节文本解码为UTF-16 / Unicode文本。例如，从C，您可以从MSVCRT调用mbcstowcs系列中的一个;从Python中，您可以使用decode在str（Python 2）/ bytes（Python 3）对象上调用sys.getdefaultencoding()方法;等

如果你真的想使用系统接口来测试相同的信息，你可以......但是你会遇到大多数接口的限制。例如，您可以CreateFileA创建一个具有8位名称的新文件，然后尝试CreateFileW打开具有相应16位名称的同一文件，并验证它是否有效......但是你不能测试任何非法的文件名字符。

最后，Microsoft 已经为大多数（如果不是全部）平台提供了免费的C编译器，但是其中一些很长时间没有服务，所以我不知道你是否可以（在最不合法地得到他们。但您始终可以使用MinGW来设置基于gcc的工具链。我不知道当前版本是否仍适用于Win95，但如果没有，旧版本仍然可用。

Answer 3

要回答您的X问题，而不是Y问题：

您无法真正询问“Windows”如何处理它所谓的“ANSI字符串”，因为有多个不同的级别可以独立处理它们。这是一个相当不错的选择，他们都是以兼容的方式这样做的......但你的全部观点是避免这种不错的赌注并直接检验真相。

我认为你可以放心地假设MultiByteToWideChar会给你与在Win32 API中调用SpamA与SpamW函数相同的结果。（如果你甚至不能假设，我认为你真的需要测试API中的每一个函数对，以确保它们都具有相同的结果......）你可以直接传递CP_1252，但我认为在配置为1252的系统上传递CP_OEMCP可以更好地测试您的要求。或者只做两件事。

MSVCRT（处理提供基于8位字符串的标准C接口和大块POSIX到便携式程序，包括CPython）有其自己的转换，这似乎是合理的。要验证这一点，请致电mbstowcs或其中一位亲属。

我非常确定Win32系统层以与用户层相同的方式处理ANSI字符串，但您可能希望搜索未记录的ZwMultiByteToWideChar或类似字符串。我认为内核在任何地方都不处理ANSI字符串 - 例如，IIRC，当你编写文件系统驱动程序时，唯一的路径名接口很宽......但是你可能想要下载DDK并确保我是对的。

我认为Explorer GUI shell依赖于Win32层来处理所有内容，并且不会在任何地方触及ANSI字符串。 cmd.exe命令行shell仅处理Unicode（在Win9x上运行DOS程序时除外） - 但它也是一个终端，作为终端，它实际上处理ANSI和Unicode字符串并映射它们。特别是，您可以发送ANSI或Unicode控制台输出并读取ANSI或Unicode控制台输入。这可能是通过MultiByteToWideChar和朋友完成的，但我不能保证。我认为MSVCRT的stdin / out和wstdin / out以及它的DOS-conio风格的getch/etc. and getwch/etc.函数只是访问这些相应的控制台API而不是在MSVCRT中进行翻译，但是如果你不相信它，你可以绕过它要么获得本机控制台流，要么直接调用Console I / O函数。

那么，如何为这些东西编写测试程序，而不是为每个操作系统找到多个不受支持的Microsoft C ++编译器版本和SDK？（而且，即使你这样做了，你怎么能确定更高版本的WinXP SDK没有隐藏你自己存在于XP本身的问题？）

答案是在运行时只有LoadLibrary和GetProcAddress各自的DLL中的函数。您可以从为一个版本的Windows编译的程序中执行此操作。

或者，更简单地说，只需使用Python，并使用其ctypes模块来访问DLL中的函数。只需确保明确创建并传递LPSTR和LPWSTR缓冲区，而不是将str / bytes / unicode个对象传递到任何位置。

所以最终，我认为您需要的是一个20行的Python脚本，它使用ctypes从MultiByteToWideChar或KERNEL32.DLL中调出mbstowcs MSVCRT32.DLL或两者。

Windows：直接检查cp1252

3 个答案: