基于 Sublime Text 3 的 Python 2.7 版本不打印 '\uFFFD' 字符

问题。

我正在使用基于 Sublime Text 3 构建的 Python 2.7，并且在打印时遇到问题。
在某些情况下，我得到的输出非常混乱'\uFFFD' - the 'REPLACEMENT CHARACTER'.

例如：

print u'\ufffd' # should be '�' - the 'REPLACEMENT CHARACTER'
print u'\u0061' # should be 'a'
-----------------------------------------------------
[Finished in 0.1s]

顺序颠倒后：

print u'\u0061' 
print u'\ufffd'
-----------------------------------------------------
a
�
[Finished in 0.1s]

因此，Sublime 可以打印出“�”字符，但由于某种原因在第一种情况下不会这样做。
输出对语句顺序的依赖似乎很奇怪。

一般来说，替换字符的问题会导致非常不可预测的打印输出行为。
例如，我想打印带有错误替换的解码字节：

cp1251_bytes = '\xe4\xe0' # 'да' in cp1251 
print cp1251_bytes.decode('utf-8', errors='replace')
-----------------------------------------------------
��
[Finished in 0.1s]

让我们替换字节：

cp1251_bytes = '\xed\xe5\xf2' # 'нет' in cp1251
print cp1251_bytes.decode('utf-8', errors='replace')
-----------------------------------------------------
[Finished in 0.1s]

并添加一条打印语句：

cp1251_bytes = '\xed\xe5\xf2' # 'нет' in cp1251 
print cp1251_bytes.decode('cp1251') 
print cp1251_bytes.decode('utf-8', errors='replace')
-----------------------------------------------------
нет
���
[Finished in 0.1s]

下面是一些其他测试用例的实现说明：

总结，所描述的打印输出行为有以下模式：

我的问题：

我的 Python 2.7 sublime-build 文件：

{   
    "cmd": ["C:\\_Anaconda3\\envs\\python27\\python", "-u", "$file"],
    "file_regex": "^[ ]*File \"(...*?)\", line ([0-9]*)",
    "selector": "source.python",
    "env": {"PYTHONIOENCODING": "utf-8"}
}

与 Anaconda 分开安装的 Python 2.7 的行为是完全相同的。

我已经重现了您的问题，并且找到了一个可以在我的平台上运行的解决方案：去除-u来自你的旗帜cmd构建配置选项.

我不是 100% 确定为什么会这样，但这似乎是由于控制台解释包含多字节字符的无缓冲数据流而导致的不良交互。这是我发现的：

• The -u option将 Python 的输出切换为无缓冲的
• 这个问题根本不是替换字符所特有的。我对“あ”（U+3042）等其他字符也有类似的行为。
• 其他编码也会出现类似的不良结果。环境"env": {"PYTHONIOENCODING": "utf-16be"}结果是print u'\u3042'输出0B.

最后一个编码设置为 UTF-16BE 的示例说明了我的想法。由于输出未缓冲，因此控制台一次接收一个字节。所以它收到0x30字节优先。然后控制台确定这不是有效的 UTF-16BE，并决定回退到 ASCII，从而输出0。当然，它会立即接收下一个字节并遵循相同的逻辑来输出B.

使用 UTF-8 编码，控制台接收到的字节不可能被解释为 ASCII，所以我相信控制台在正确解释无缓冲流方面做得稍微好一些，但它仍然遇到了你的问题的困难指出。