Comments 23
Статья — лучшее подтверждение тому, что всё — от средств компиляции до комментариев в программе должно быть на английском языке.
Я, наверное, буду очень наивен.
Но на рынке железа есть единичные НЖМД с ёмкостью 4*1012 байт. Неужели в этих условиях нет возможности использовать многобайтовые кодировки unicode? 16-битные, 32-битные, uft-8, uft-16? Неужели экономия на спичках того стоит?
Но на рынке железа есть единичные НЖМД с ёмкостью 4*1012 байт. Неужели в этих условиях нет возможности использовать многобайтовые кодировки unicode? 16-битные, 32-битные, uft-8, uft-16? Неужели экономия на спичках того стоит?
1. Возможно, компилятор чудесного ассемблера написан в 90-е или вообще под ДОС.
2. Возможно, компилятор написан на Cи, у которого с юникодом нехорошо под Windows.
Поясню: строки во многих функциях, например fopen, однобайтовые (utf-16 версия _wfopen — нестандартное расширение MS). Чтобы подружить Си с юникодом, остаётся использовать utf-8 (что в linux и практикуется), однако текстовая консоль Windows почему-то принципиально не хочет поддерживать utf-8, оставляя выбор между utf-16 и любой не-юникодной кодировкой.
2. Возможно, компилятор написан на Cи, у которого с юникодом нехорошо под Windows.
Поясню: строки во многих функциях, например fopen, однобайтовые (utf-16 версия _wfopen — нестандартное расширение MS). Чтобы подружить Си с юникодом, остаётся использовать utf-8 (что в linux и практикуется), однако текстовая консоль Windows почему-то принципиально не хочет поддерживать utf-8, оставляя выбор между utf-16 и любой не-юникодной кодировкой.
cygwin? Любая другая консольная среда, которая не страдает синдромом windows? Я имею в виду, синдром windows-1252, 1251, etc.
Такой софт будет сложнее продать пользователям Windows. Придётся оказывать поддержку с настройкой терминала. Видимо, дешевле в OEM-кодировке оставаться. Ну, или сразу писать софт в unicode с использованием Microsoft-specific функций.
кому какое дело из пользователей, что используется при разработке ПО? На выходе-то там обыкновенный исполняемый файл. А консоль в виндах сто лет юникодная, если ConsoleWriteW использовать, а не *A.
Короче, героическое преодоление грабель, которому научили авторов в юности, которое они сейчас мужественно стараются воспроизвести.
Короче, героическое преодоление грабель, которому научили авторов в юности, которое они сейчас мужественно стараются воспроизвести.
Иногда огромное дело пользователям, что используется. В моем случае пользователь==заказчик, и кое-что пишет в ТЗ, это раз. А два — чтобы сделать «обыкновенный исполняемый файл» для именно этого процессора существует единственный компилятор от производителя процессора. И менять процессор только из-за локали — смешно, ему нет аналогов.
Не думайте, пожалуйста, что это грабли ради преодоления.
Справедливости ради скажу, что у этого ассемблера существует версия с английскими сообщениями. Но в данный момент у меня на рабочем месте ее нет, и не от меня одного зависит, чтоб появилась.
Не думайте, пожалуйста, что это грабли ради преодоления.
Справедливости ради скажу, что у этого ассемблера существует версия с английскими сообщениями. Но в данный момент у меня на рабочем месте ее нет, и не от меня одного зависит, чтоб появилась.
Консоль — это только половина беды. Туда же и CreateFileW, и т.п… А-общем, отказ от stdlib в пользу Win32 API
А можно уточнить, какая связь между НЖМД на много байт, многобайтовыми кодировками и чужим компилятором? Я, честно, не понял.
Менять настройку encoding где бы то ни было после того, как куда‐либо в память Vim попала хотя бы одна не‐ASCII строка — нельзя. Это написано прямо в справке: второй абзац
Удивительно, что при наличии настроек для кодировки файла, терминала, вывода на печать и внутреннего представления, нет отдельной настройки для кодировки окружения.
И, кстати, не используйте
:h 'encoding'.Удивительно, что при наличии настроек для кодировки файла, терминала, вывода на печать и внутреннего представления, нет отдельной настройки для кодировки окружения.
И, кстати, не используйте
set для установки сложных значений. Есть let:let &l:makeprg='c:\bin\make.exe $* | c:\bin\iconv\iconv.exe -c -f CP866 -t CP1251'
Лично я бы исправил make-файл, а не настройки vim. Почему? Потому что это в дальнейшем позволит разрулить ситуацию, когда из одного и того же make-файла вызываются два компилятора, один из которых пишет в консоль в cp-866, а второй — в windows-1251.
Тогда, если я запускаю make в консоли, а не в VIM (например, на чужом компьютере), надо сначала научить консоль (на чужом компьютере) выводить в cp1251. Или использовать разные Makefile.
Или использовать разные переменные окружения.
PS научить консоль выводить в cp1251 просто — chcp 1251. Другое дело, что очень мало программ с таким режимом совместимы (впрочем, для других он, наоборот, единственный).
PS научить консоль выводить в cp1251 просто — chcp 1251. Другое дело, что очень мало программ с таким режимом совместимы (впрочем, для других он, наоборот, единственный).
Сейчас попробовал: chcp на перенаправление в файл не действует.
А это значит, IDE, вызывая «make.exe > build.log», будет всё время получать лог в кодировке 866, независимо от chcp.
Также пожелание amarao — писать всё в юникоде — не поможет.
Командный интерпретатор весь юникодный вывод сконвертирует в 866 при записи в лог-файл.
А это значит, IDE, вызывая «make.exe > build.log», будет всё время получать лог в кодировке 866, независимо от chcp.
Также пожелание amarao — писать всё в юникоде — не поможет.
Командный интерпретатор весь юникодный вывод сконвертирует в 866 при записи в лог-файл.
Ну, не буду я на чужом компе с консолью куражиться, и тем более, менять переменные окружения. Пока что приходится вообще батник вместо make использовать. И вообще, речь не об этом.
Я всего лишь пытался показать, что иногда приходится использовать некий фильтр между командой типа :make и выдачей результатов пользователю. Некий фильтр, например, перекодировку. И что можно найти (или написать) утилиту и вставить ее в соответствующее место. Когда я рылся в интернетах, не нашел такого решения нигде ни разу, по крайней мере, под Windows (в Linux цепочки утилит — норма). Решил сам, внимательно перечитав справку. Мне случайно подумалось, что подобная задача может интересовать не только меня, и предложил решение. Как бы, количество байтов в кодировке вообще ни при чем.
Я всего лишь пытался показать, что иногда приходится использовать некий фильтр между командой типа :make и выдачей результатов пользователю. Некий фильтр, например, перекодировку. И что можно найти (или написать) утилиту и вставить ее в соответствующее место. Когда я рылся в интернетах, не нашел такого решения нигде ни разу, по крайней мере, под Windows (в Linux цепочки утилит — норма). Решил сам, внимательно перечитав справку. Мне случайно подумалось, что подобная задача может интересовать не только меня, и предложил решение. Как бы, количество байтов в кодировке вообще ни при чем.
Sign up to leave a comment.
VIM, Windows, quickfix — борьба с кодировкой компилятора