Основная проблема заключается в том, что невозможно использовать Unicode в Windows, используя только стандартную библиотеку C и не зависящие от платформы или сторонние расширения. Упомянутые вами языки происходят из платформ Unix, чей метод реализации Unicode хорошо сочетается с C (они используют обычные строки char*
, функции языка C и UTF-8). Если вы хотите использовать Unicode в C, вам более или менее необходимо написать все дважды: один раз с использованием нестандартных расширений Microsoft и один раз с использованием стандартных функций C API для всех других операционных систем. Хотя это может быть сделано, обычно оно не имеет высокого приоритета, потому что это громоздко, и большинство разработчиков языка сценариев либо ненавидят, либо игнорируют Windows.
На более техническом уровне, я думаю, основное предположение, которое делают большинство разработчиков стандартных библиотек, заключается в том, что все потоки ввода-вывода по своей сути основаны на байтах на уровне ОС, что справедливо для файлов во всех операционных системах и для всех потоки в Unix-подобных системах, за исключением консоли Windows. Таким образом, архитектура многих библиотек классов и стандарт языка программирования должны быть значительно изменены, если кто-то хочет включить консольный ввод-вывод Windows.
Еще один более субъективный момент заключается в том, что Microsoft просто не хватило для продвижения использования Unicode. Первой ОС Windows с приличной (для своего времени) поддержкой Unicode была Windows NT 3.1, выпущенная в 1993 году, задолго до того, как в Linux и OS X появилась поддержка Unicode. Тем не менее, переход на Unicode в этих ОС был гораздо более плавным и беспроблемным. Microsoft снова выслушала продавцов, а не инженеров, и оставила технически устаревшую Windows 9x примерно до 2001 года; вместо того, чтобы заставлять разработчиков использовать чистый интерфейс Unicode, они все еще поставляют сломанный и теперь ненужный 8-битный интерфейс API и приглашают программистов использовать его (посмотрите на несколько недавних вопросов Windows API по переполнению стека, большинство новичков все еще используйте ужасное устаревшее API!).
Когда вышел Unicode, многие поняли, что это полезно. Unicode начинался как чисто 16-битное кодирование, поэтому было естественно использовать 16-битные кодовые единицы. Затем Microsoft, по-видимому, сказала: «Хорошо, у нас есть эта 16-битная кодировка, поэтому мы должны создать 16-битный API», не понимая, что никто не будет ее использовать. Однако светила Unix подумали: «Как мы можем интегрировать это в существующую систему эффективным и обратно-совместимым способом, чтобы люди могли его использовать?» и впоследствии изобрел UTF-8, который является блестящим инженерным произведением. Так же, как при создании Unix, люди Unix думали немного больше, нужно немного дольше, имели меньший финансовый успех, но в конце концов сделали это правильно.
Я не могу комментировать Perl (но я думаю, что в сообществе Perl больше ненавистников Windows, чем в сообществе Python), но в отношении Python я знаю, что BDFL (который также не любит Windows) заявил, что Адекватная поддержка Юникода на всех платформах - главная цель.