Комментарии 37
Русские символы? Кажется, вы хотели сказать "кириллица".
Не обижайтесь, но… Идет 2017 год, все человечество уже лет 15-17 точно перешло на Unicode. И только в Windows нужны какие-то эзотерические заклинания, вспоминать, что такое магические 866 и 1251. Понимаю, что все это видимо ради совместимости с приложениями 30-летней давности, но все же, можно было бы придумать и более изящное решение, особенно учитывая, что PowerShell — относительно недавнее изобретение и ему по большому счету совместимость с 30-летними приложениями не нужна.
Если немного глубже погрузиться в изучение стандарта unicode то можно узнать, что он состоит из двух основных разделов: универсальный набор символов (universal character set) и семейство кодировок (unicode transformation format). Так как в статье озвучена проблема кодировок, то посмотрим, какой зоопарк нам предоставляет unicode, а это UTF-8, UTF-16, UTF-32 + модификации LE / BE, ну и экзотика типа UTF-7, UTF-9, UTF-18. Так что проблемы кодировок символов с приходом unicode никуда не делись.
Unicode конечно несовершенен, как и все в этом мире. Но UTF-8 покрывает значительно большее количество случаев и намного более удобен, чем подобные костыли с code pages.
Я не знаток всех мировых языков. На повседневном уровне использую три: русский, английский, испанский. У меня в альтернативной операционной системе, что в консоли, что в любом другом приложении можно свободно использовать и комбинировать эти языки как угодно. При необходимости можно использовать еще сколько угодно языков. Да, наверное, какие-то проблемы с редкими символами из японского/китайского или малаяламского могут возникнуть, специально этим не интересовался.
В общем, Unicode — может быть и не всеобъемлющее решение, но однозначно намного более универсальное, чем полуработающие костыли (автор, насколько я понимаю, так и не добился работы без предупреждений во всех ситуациях). Допустим, если у нас существует необходимость работать с 2-3 языками одновременно, то я не вижу возможного решения вообще.
И это в 2017 году, когда по улицам скоро начнут ездить робомобили с искусственным интеллектом, память компьютеров измеряется десятками, если не сотнями гигабайт, а скорость процессоров дошла до физического предела… Но до сих пор в консоли Windows существуют ограничения 30-летней давности, когда компьютеры были слабее, чем самый слабый процессор в наручных часах...
Но UTF-8 покрывает значительно большее количество случаев и намного более удобен, чем подобные костыли с code pages.
А почему именно UTF-8?
Был опыт в попытке подружить вывод консоли TalendStudio с со сборочным агентом bamboo работающем под linux, вот только первый отправлял в stdout данные в кодировке UTF-16 а агент считывал их используя кодировку UTF-8. Так что использование unicode и не windows стека технологий в общем случае не спасет от возникновения проблем.
Ну и не надо забывать, что первоначально была задача решить проблему производства. :)
PowerShell — относительно недавнее изобретение и ему по большому счету совместимость с 30-летними приложениями не нужна.
Да, конечно, вы правы. И поэтому так такой совместимости по умолчанию и не предусмотрено: приложения, которые пользуются современными юникодовыми API (WriteConsoleW), будут печатать вывод нормально, а для устаревших приложений нужны бубны (некоторые сорта которых описаны в посте). К сожалению, приложений, которые не пользуются современными юникодовыми API, ещё очень много. Многие рантаймы языков программирования также этот режим вывода не поддерживают, что ещё печальнее.
А в линуксе как вы будете запускать программу, которая выводит UTF-16 в stdout, и чтоб этот текст отобразился на терминале?
(Я не утверждаю, что вы не сможете это сделать, просто мне действительно интересно посмотреть на решение.)
Во-первых, приложение, которое выводит на stdout интерактивный контент не в том, что указано в переменных локализации LC_*, надо исправлять, а не жить с этим. Это — ошибка, а не нормальное поведение.
Во-вторых, если очень нужно — большинство эмуляторов терминала умеют установить произвольную кодировку в качестве отображаемой, в том числе варианты UTF16.
приложение, которое выводит на stdout интерактивный контент не в том, что указано в переменных локализации LC_*, надо исправлять, а не жить с этим. Это — ошибка, а не нормальное поведение.
В этом я с вами тоже полностью согласен! Приложения, которые пытаются использовать функции семейства WriteConsoleA (которые по определению работают в текущей OEM-кодировке), чтобы выводить текст в другой кодировке, тоже надо исправлять. В Windows, если вам угодно, переменные локализации LC_* всегда константы и указывают UTF-16 кодировку, для которой есть соответствующее семейство функций вывода на экран. К сожалению, многие программы это игнорируют и пытаются совать в OEM-функции тексты в своих кодировках, что иногда и вызывает проблемы.
если очень нужно — большинство эмуляторов терминала умеют установить произвольную кодировку в качестве отображаемой, в том числе варианты UTF16.
А это не испортит вывод предыдущих команд в том же терминале? Пожалуй, для каких-то единичных программ всё-таки лучше пайпать их вывод в iconv.
Приложения, которые пытаются использовать функции семейства WriteConsoleA [...] тоже надо исправлять
Только вот Microsoft с вами, боюсь, не согласен. Иначе бы делали какие-то телодвижения по объявлению *A функций deprecated и пытались бы как-то форсировать переход человечества в светлое будущее. Вот здесь говорят, что их пытаются deprecate'ить, но только по каким-то одиночным библиотекам типа winsock2.
А это не испортит вывод предыдущих команд в том же терминале?
Не должно. Хотя бы потому, что терминал, вообще говоря, не имеет возможности переинтерпретировать какую-то часть старого потока символов при таком переключении кодировки (хотя бы потому, что эту часть еще как-то выделить и запомнить надо, а это потребует весьма нетривиальных телодвижений). Это же не браузер, в котором кодировку всего документа переключают — документа-то нет.
Депрекейтить необязательно, достаточно только лишь подробно рассмотреть вопрос. У функции WriteConsoleA есть вполне определённое поведение: вывести строку в текущей OEM-кодировке (ну, вообще говоря, просто в текущей кодировке консоли в соответствии с SetConsoleOutputCP, которая по умолчанию инициализируется из OEM).
Если конкретному приложению нужно именно это (мне сложно представить себе современное приложение с такими нуждами, но мало ли) — оно вполне легитимно вправе использовать это семейство функций.
Если же конкретное приложение хочет выводить какой-то национальный текст вне зависимости от кодировки терминала — оно должно использовать соответствующие юникодовые функции (a la WriteConsoleW). Вот и всё.
Про обратную совместимость: благодаря этим бесконечным костылям в windows 10.0 запускается и работает то, что писалось во времена windows 3.5. А уж без специфических программ если — то windows 5 софт работает без проблем в windows 10.
Вы на каком красноглазии сидите, что позволяете себе свысока подобные сентенции публично? Там можно десятилетний бинарник запустить без проблем, да?
Простите, что так задел вас.
Не знаю, как с бинарной совместимостью с Linux. Она там есть, но насколько хорошая — не знаю, т.к. весь необходимый мне софт — opensource — поэтому никогда не нужна была бинарная совместимость. Раньше у меня было время читать lkml и множество других источников информации о развитии Linux, и помню, что этот вопрос обсуждался и совместимость старались сохранить.
Предполагаю, что десятилетний бинарник скорее всего можно будет запустить.
Что касается поддержки Unicode в ntfs — не знаю, что тут сказать. Может быть это требовалось по каким-то причинам для ntfs, про файловые системы Linux/Unix можно сказать, что они поддерживали Unicode с самого начала существования, еще до возникновения Unicode, так как для большинства файловых систем Linux/Unix — имя файла — это просто набор байтов, который они никак не пытаются интерпретировать. То же самое относится, естественно, к содержимому файла. Поэтому можно использовать хоть Unicode, хоть что угодно вместо него.
Но тут речь не о сравнении операционных систем — я не пытался и не хотел начинать такой разговор. Просто описанное в статье мне показалось костылями, да еще и неработающими. Выразил свое удивление, вот и все. Может быть все эти неудобства стоят того, чтобы кто-то мог запустить на Windows 10 программу для Windows 3.11. Меня это удивляет, конечно, потому что таких людей наверняка меньше 1%, и почему бы им не использовать копию Win 3.11 или виртуальную машину, вместо того, чтобы миллионы людей по всему миру испытывали неудобства.
Мне кажется, эта полемика возникла из взаимонепонимания двух ортогональных точек зрения: Ваша, "как надо писать программы"(точка зрения разработчика) и автора, "как заставить работать то, что написали другие"(т.зр. сисадмина). Вы поавы, ситуацию надо менять в корне. Но пока она не исправлена, проблема есть и её надо решать в рамках задач по эксплуатации независимо от того, что "есть правильный путь". Так что да, автор тоже прав, что ищет пути.
Я не обладаю всей информацией, чтобы предложить решение. Всю жизнь использую Linux — так сложилось, что Linux увидел раньше Windows, еще где-то в 95 или 96 году. С Windows знаком постольку-поскольку, сталкиваюсь лишь на компьютерах знакомых.
Поэтому мне сложно предложить техническое решение, решающее данную проблему. Просто удивило — все это выглядит как нагромождение костылей. Представляю какое астрономическое количество человеко-лет тратит Microsoft на поддержку этой совместимости, в том числе откровенно дебильных codepages, которые, мне казалось, давно остались лишь в музеях. А затем пользователи Windows по всему миру тратят свои человеко-часы, чтобы построить новые костыли поверх старых, чтобы обойти эти грабли древних кодировок.
В итоге, полмира тратит время впустую, лишь бы кто-то мог запустить supercalc.exe 1986 года на операционной системе 2015-го года. Мне почему-то это не кажется поводом для гордости. Есть какой-то баланс между ломанием совместимости в каждой новой версии и фанатичной поддержкой совместимости. Кому нужно работать с приложениями 20-30 летней давности, скорее всего будет делать это на старом железе со старой системой. В крайнем случае, почему бы не установить виртуальную машину.
Зачем подвергать людей таким пыткам, что они даже банальный скрипт невозможно написать без танцев с бубном? Неужели не существует разумного способа решить данную проблему раз и навсегда? Например, сказать: «пусть cmd и все прочее, что потенциально может использоваться для старых приложений, будет использовать codepages, а для PowerScript мы делаем стандартом Unicode?»
Ну, Linux тоже стоит в куче мегакорпораций, и ничего, как-то умудряется поддерживать всюду сквозной unicode без костылей. В любом приложении, консольном или GUI, написанном на любом языке программирования, с использованием любого фреймворка, могу вводить текст на нескольких языках, и он будет отображаться всюду без проблем, сохраняться, загружаться. По-моему, это просто необходимое условие для минимально комфортного уровня работы, потому что за пределами Северной Америки, почти всем людям приходится ежедневно использовать два и более языка.
Про supercalc — не верю, что кто-то покупает новую машину с i7, устанавливает Windows 10, и все это, для того, чтобы запустить supercalc. Если такие пользователи и есть, то у них стоит какое-нибудь древнее железо, на котором крутится DOS, Windows 3.11 или что-то подобное.
Понятно, что полная статистика есть только у Microsoft, да и есть ли?.. Но все же сомнительно, чтобы такие пользователи составляли хоть сколько-нибудь значительный процент среди покупателей тех же Windows 7, Windows 10.
Ну и как я писал выше — путаете набор символов (char set) и кодировку (encoding).
Я нигде не писал, что «Microsoft разводит пользователей на бабки». И отлично знаю разницу между char set и encoding, хотя частенько использую термин unicode как синоним utf-8, прошу за это прощения.
На самом деле удивило, что до сих пор людям приходится бороться с code pages причем в современных языках и приложениях. Когда уже много лет не испытывал абсолютно никаких проблем в этой области, подобные проблемы на самом деле удивляют. 866? 1251? Какие-то хаки, чтобы прочитать кириллицу в выводе скрипта? Это действительно удивительно при взгляде с другой стороны баррикад.
Причем я ни в одном комментарии не критиковал Microsoft, только лишь выражал искреннее недоумение.
Какой унылый демагог. Ваше мнение, безусловно, очень важно, держите в курсе.
благодаря этим бесконечным костылям в windows 10.0 запускается и работает кое-что, что писалось во времена windows 3.5
жизнефикс
PowerShell — относительно недавнее изобретение и ему по большому счету совместимость с 30-летними приложениями не нужна.
Это вам не нужно и мне не нужно, а у майкрософта это основная бизнес-фича и священная корова.
Идет 2017 год, все человечество уже лет 15-17 точно перешло на Unicode. И только в Windows нужны какие-то эзотерические заклинания
Тут не очень понятно, к чему вы это. Я вот при установке Windows на ноутбук, погорячившись, назвал профиль «Андрей». Ну и в результате, то там то сям вылазит:
Qt проект, положенный в такую папку, вообще отказывается собираться, и так далее.
Нет пока что в мире совершенства, хоть и 2017 год на дворе.
Особенно доставляет то, что у меня все языковые настройки немецкие — с этой стороны тоже вылазят свои трогательные косяки.
С другой стороны, есть пользователи (коих, вероятно, большинство), которые с такой проблемой не сталкивались, просто потому, что не используют «проблемное» сочетание продуктов за ненадобностью.
Автор в одном конкретном случае получил вывод в неверной кодировке, разобрался что к чему, исправил это дело и поделился.
Мне вот по долгу службы приходится разрабатывать десктопное приложение, локализованное для многих языков, при этом используя IDE с весьма кривой поддержкой юникода, так у меня целая коллекция таких вот случаев (хотя они слишком частные, и не будут интересны широкому кругу).
Шаг за шагом эти проблемы решаются, но пройдёт ещё довольно много времени, прежде чем все эти болячки окончательно исчезнут.
using System;
using System.Text;
class Program
{
static void Main(string[] args)
{
Console.OutputEncoding = Encoding.UTF8;
Console.WriteLine("c'est-à-dire хелло Βικιπαίδεια");
}
}
вот скрипт (1.ps1 в UTF8-BOM):
Write-Output "c'est-à-dire хелло Βικιπαίδεια"
&"C:\Users\Alex\Documents\visual studio 2017\Projects\SamplePowershellApp\SamplePowershellApp\bin\Debug\SamplePowershellApp.exe"
Результат:
Для себя эту проблему (в терминале, а не в ISE) решил установкой кастомного терминала и макросами на смену шрифта вывода — на удалённом хосте включаем шрифт Terminal, и кракозябры превращаются в читаемый вывод.
Powershell и кирилица в консольных приложениях (updated)