Почему языки сценариев не выводят Unicode на консоль Windows?

Консоль Windows поддерживает Unicode как минимум десять лет и, возможно, еще с Windows NT. Однако по какой-то причине основные кроссплатформенные языки сценариев, включая Perl и Python, выводят только различные 8-битные кодировки, что требует больших усилий для обхода. Perl выдает предупреждение «широкий символ при печати», Python выдает ошибку charmap и завершает работу. Почему, черт возьми, после всех этих лет они просто не вызывают API Win32 -W, которые выводят UTF-16 Unicode, вместо того, чтобы проталкивать все через узкое место ANSI / кодовой страницы?

Неужели кроссплатформенная производительность имеет низкий приоритет? Это потому, что языки используют UTF-8 внутри и слишком беспокоят вывод UTF-16? Или API -W по своей природе сломаны до такой степени, что их нельзя использовать как есть?

ОБНОВЛЕНИЕ

Похоже, что вина, возможно, придется разделять всем сторонам. Я представил, что языки сценариев могут просто вызвать wprintf в Windows и позволить ОС / среде выполнения беспокоиться о таких вещах, как перенаправление. Но оказывается, что даже wprintf в Windows преобразует широкие символы в ANSI и обратно перед печатью на консоли !

Сообщите мне, было ли это исправлено, поскольку ссылка на отчет об ошибке кажется неработающей, но мой тестовый код Visual C по-прежнему не работает для wprintf и успешно выполняется для WriteConsoleW.

ОБНОВЛЕНИЕ 2

Фактически вы можете распечатать UTF-16 для консоль из C с использованием wprintf , но только если вы сначала выполните _setmode (_fileno (stdout), _O_U16TEXT) .

Из C вы можете напечатать UTF-8 на консоли, кодовая страница которой установлена ​​кодовая страница 65001, однако Perl, Python, PHP и Ruby содержат ошибки, которые предотвращают это. Perl и PHP повреждают вывод, добавляя дополнительные пустые строки после строк, содержащих хотя бы один широкий символ. У Ruby несколько иной поврежденный вывод. Сбой Python.

ОБНОВЛЕНИЕ 3

Node.js - это первый язык сценариев, который поставляется без этой проблемы прямо из коробки.

Команда разработчиков Python постепенно осознала, что это реальная проблема, так как впервые было сообщено в конце 2007 года и наблюдалась огромная активность, направленная на полное понимание и полное исправление ошибки в 2016.