Comments: |
Примерно то же самое я почувствовал когда увидел в cmd Windows 10 нормальный selection flow. Раньше был исключительно прямоугольник.
Там ещё и ANSI коды для 256 цветов теперь поддерживаются. Нет, это не сон. :)
From: (Anonymous) 2018-05-10 04:14 pm
| (Link)
|
Таладна. Когда я обнаружил, что ресайз работает по-человечески, вот это был shock and awe. Осталось только дождаться поддержки UTF-8 из коробки.
Ну вы палку-то не перегибайте. UTF-8 это уже уровень армагедона
From: (Anonymous) 2018-05-11 05:39 pm
| (Link)
|
Он поддерживается, но не по умолчанию. Интуитивная юзер-френдли команда chcp 65001 включает поддержку. Ну и шрифт нужно не абы какой выбрать, а чтобы нужные буковки в нем были.
From: (Anonymous) 2018-05-12 09:43 am
| (Link)
|
К сожалению, никакой «поддержки» Юникода не появляется, это всего лишь хак, задающий интерпретацию символов во вводе и выводе интерпретатора, и справляющийся разве что с листингом непредставимых в одной кодировке имён файлов.
Как известно, в Windows никакого UTF-8 нет, а есть юникодное API, работающее с двухбайтными (ну, для начала) символами в UTF-16LE, и ANSI API, работающее с однобайтными символами в текущей системной кодировке. После "chcp 65001" функции _A не перекомпилируются магически в функции _W, и мы имеем все те радости, глюки и падения, которые получает человек, решивший по-быстрому пихнуть в char[] строку UTF-8 без глобального пересмотра всех используемых библиотек.
ANSI-кодировки символов с переменной шириной (MBCS) в Windows тоже существуют, в версиях для азиатских и других языков, но в них как раз-таки система и приложения пересобраны с библиотеками, переписанными для работы с такими кодировками. UTF-8 не является одной из поддерживаемых локалей.
В Powershell есть юникод (поскольку это никакая не консоль, а REPL для C#, работающий с его объектами), в UNIX-подсистеме, по идее, тоже должны были что-то нормальное для работы программ придумать (не совместимое со старой консолью, очевидно).
From: (Anonymous) 2018-05-13 05:43 pm
| (Link)
|
Вы меня, похоже, неправильно поняли. chcp отвечает за преобразование байтов, отправляемых в консоль, в видимые пользователю на экране буковки (и обратно, из нажимаемых кнопочек в байты). Все. chcp 65001 делает так, что это преобразование преобразует из/в UTF-8. Я имел в виду только это и больше ничего. Ни о каких локалях и W и A APIs и библиотеках речи нет, это из другой оперы совсем.
From: (Anonymous) 2018-05-14 04:27 pm
| (Link)
|
…А в результате данных операций в указанные функции попадает поток в UTF-8, с переменной шириной символа и сложными правилами кодирования и декодирования, хотя там его никто не ждёт.
В результате, например, привычный .bat-файл в однобайтной кодировке может не запуститься в кодовой странице 65001, поскольку содержит последовательности символов, не разрешённые в UTF-8. Или программа упадёт из-за того, что в файле (не консоли), который она честно читает в соответствии с заданными настройками окружения, будут символы, которых нет в шрифте (В ШРИФТЕ!) консоли. Последнее, впрочем, и без Юникода можно было организовать.
From: (Anonymous) 2018-05-14 06:04 pm
| (Link)
|
> сложными правилами кодирования и декодирования
А зачем его кодировать и декодировать? В задачу большинства программ это не входит. Байты нужно хранить и пересылать как есть, а декодированием занимаются специально обученные сущности (консоль, например).
Консольные программы под вендой, которым таки да нужно понимать символы, либо читают wchar_t (и тогда им все равно, что там за code page в любом случае), либо рассчитаны на какую-то одну legacy code page (и тогда они подлежат утилизации в биореакторе).
> хотя там его никто не ждёт
Кто включил 65001, тот именно UTF-8 и ждет. Вот я, например. Включил 65001, жду UTF-8, его получаю, и ничего такого катастрофического не происходит.
> может не запуститься в кодовой странице 65001
Он может не запуститься и в любой другой странице, отличной от той, в которой головотяп его писал. В большинстве страниц есть коды, не соответствующие никаким символам. Вывод такого кода в консоль приводит к всяческим неприятностям.
> в файле (не консоли), который она честно читает в соответствии с заданными настройками окружения, будут символы, которых нет в шрифте
Это какая-то фантазия. Если легального символа нет в шрифте консоли, консоль его заменяет на квадратик, вопросительный знак или какую другую кракозябру, это раз. Чтение из файла совершенно никак с этим не связано, это два. Я проверял.
From: (Anonymous) 2018-05-14 06:47 pm
| (Link)
|
> Байты нужно хранить и пересылать как есть
Переслал тебе length(s) байтов, у одного результата строка обрывается посреди символа, у другой функции стек мусором затёрт, куда сам сядешь, куда мать посадишь?
> Это какая-то фантазия.
Невероятно, но факт: замена шрифта на растровый 256-символьный делает больно даже программам уровня «прочесть строку из файла 1 — записать строку в файл 2».
> Если легального символа нет в шрифте консоли, консоль его заменяет на квадратик, вопросительный знак или какую другую кракозябру, это раз.
Это три разных подмены, и как минимум две из них происходят совсем не в коде вывода на экран данных консоли; отнюдь не «раз».
From: (Anonymous) 2018-05-11 02:52 pm
| (Link)
|
Юникод? В консольной подсистеме Windows? Чтобы программы перестали падать, даже не взаимодействуя с консолью? Никогда!
> Наверное, конец света действительно близок.
А он будет кончаться на 0xA или 0xD, 0xA? ))
Или "А он будет кончаться на ^Z или ^D?"
Вау! Да так он уже скоро с Notepad++ конкурировать будет ;)
Ну Яблы же перешли на Юникс, чому бы Окнам не?
Вот когда он синтаксис красить начнет - тогда и я поверю ;)
Это пока только в insider build?
Кажется, да, я запутался уже с их терминологией.
Ну после того как винда щетай из коробки заражена убунтой... уже сложно удивить
From: (Anonymous) 2018-05-11 11:34 pm
| (Link)
|
Это вы про что? Я пропустил совсем...
From: bakabaka 2018-05-12 07:30 am
Microsift Linux давно уже не шутка | (Link)
|
Собственно, поэтому и блокнот стали чинить
Пора заводить таг "муравей"?
После такой новости я не удивлюсь даже, если Notepad станет строчки нумеровать.
"Extended" - это в смысле, notepad теперь распознает ситуацию, когда «новая строка» есть, а «возврата каретки» нет.
Мрачно лезу в Википедию:
The Unicode standard defines a number of characters that conforming applications should recognize as line terminators:[5] LF: Line Feed, U+000A VT: Vertical Tab, U+000B FF: Form Feed, U+000C CR: Carriage Return, U+000D CR+LF: CR (U+000D) followed by LF (U+000A) NEL: Next Line, U+0085 LS: Line Separator, U+2028 PS: Paragraph Separator, U+2029
Есть над чем работать...
From: (Anonymous) 2018-05-10 06:23 pm
| (Link)
|
Program Files/Sublime Text/uninstall.exe
Так всё логично: сначала нативные драйвера для SQL Server-а из линукса, потом отсутствие претензий к Mono, потом Linux Subsystem в Windows 10, потом и Visual Studio Core в линукс...
From: (Anonymous) 2018-05-11 05:16 pm
| (Link)
|
Here is an even more ominous sign: https://opensource.microsoft.com/?keyword=linux | |