Комментарии 92
Вспоминается вот этот вот ресурс: https://2cyr.com/decode/
А нет чего-то open-source-ного для этого?
Есть утилита iconv. Да и в том же vim/neovim можно поменять кодировку. Писал как-то пост про это в свой тг канал, если интересно - скину вам сообщением ссылку на пост. В принципе, всё это можно и самому нагуглить, просто у меня более "разжёвано".
З.Ы. Статью смотрел по диагонали. У iconv нет автоопределения кодировки, но можно перебрать 2-3 самые распространённые кодировки в рунете - с большой вероятностью будет одна из них. А можно обернуть iconv в простенький python-скрипт, который будет фрагмент текста переводить используя разные кодировки, останется лишь выбрать кодировку, после которой текст больше всего похож на правду.
пост про это в свой тг канал
++enc=cp1251 уже требует пост в тг канал?
В принципе, всё сводится к :e ++enc=cp1251 и :w ++enc=utf-8 Я всего лишь подобнее описал работу с iconv из консоли и преобразование в UTF-8 всех файлов в заданной директории и во всех вложенных директориях рекурсивно. Встала такая задача полгода назад, и родился пост, поделиться опытом, так сказать. Понятно, что опытным юзерам тут всё понятно как 2 пальца, я больше для новичков писал :)
Родился пост, в неиндексируемом месте, там где никто никогда не увидит... Чтобы что? :)
Хороший вопрос :) Ну, канал с заметками, человек 100 увидели. На статьи для Хабра такие заметки не тянут. Возможно, стоит попробовать новую фичу Хабра – посты. А вот интересно, они индексируются Яндексом/Гуглом?
Да
На Хабре как раз таки есть раздел Посты. Пишите туда пожалуйста. Я вот пишу
Ну вот ХЗ, всю жизнь (когда мне было лень указать явно кодировку, т.е. достаточно часто) - я использую enconv и не жужжу (какие-то самописные скрипты не нужны).
Кроме iconv, есть ещё enca. Iconv есть в любом линуксе, а enca надо ещё поискать и скорее всего собрать, зато в нём есть АВТООПРЕДЕЛЕНИЕ! Я как-то в рамках рефакторинга очень-очень старого легаси-проекта (часть авторов писали в 1251, часть в КОИ8) натравил на дерево исходников связку find и enca, и она успешно всё перевела в UTF8.
Вот, кажется оно (хотя я пользовался бинарной сборкой одного из отечественных дистрибутивов):
Уже никому не нужны странные кодировки, все сожрал UTF-8 (иногда UTF-16). Лет 10 назад были chardet/chardetect/enca
Я давеча из-под Win 11 запустил bat файл, в ключ программы передал текст на русском. И очень удивился. Вот как вы думаете, в какой кодировке должен быть bat, чтобы ключ был передан корректно в .net приложение?
866? консоль винды насколько я помню довольно забавная штука
cmde.exe в Винде отсталое говно мамонта и про современные кодировки не в курсе.
Как сидели с однобайтовыми так и сидят и ради "совместимости" тянут ещё ту DOS'овскую кодировку.
А почему совместимость в кавычках? Альтернатива-то какая?
В кавычках, потому что непонятно с чем совместимость.
В массе своей команднострочные программы умерли вместе с DOS.
Да остался ещё FAR, но кто в корпоративном мире про него знает?
Может ещё что-то по мелочи.
99,999(9)% всего взаимодействи в Винде происходит через гуй.
Да, они родили свой pwsh который оказался очень так себе.
Впрочем под Виндой альтернативы нет, так что остаётся страдать тем немногим которым почему-то понадобилась командная строка..
В массе своей команднострочные программы умерли вместе с DOS.
Так умерли, что треть функционала системы можно посмотреть и конфигурировать только в консоли через системные утилиты, а из оставшегося большую часть вообще только через win32. Причем, большая часть встречающихся сторонних утилит для конфигурации всего и вся опять таки консольные, т.к. все это впихнуть в UI практически нереально.
А гуй так вообще покрывает только самый базовый функционал, зачастую еще и очень сильно ограниченно. Хочешь больше - вот тебе старые добрые системные утилиты, вот тебе cmd c powershell. Причем, последний хоть и так себе по синтаксису, но прямой доступ к базовому .NET вполне себе решает кучу проблем.
Впрочем под Виндой альтернативы нет, так что остаётся страдать тем немногим которым почему-то понадобилась командная строка..
Почему нет? Есть форк бизибокса под винду, есть баш от гита, есть баш в комплекте с WSL, и прочее, прочее, прочее, что можно затащить в оболочку штатного виндового терминала, которому уже 5 лет как стукнуло.
PS. А FAR в корпоративном мире живее всех живых, постоянно с его адептами сталкиваюсь.
Треть это "Win+R, type whatever.msc, press enter"?
Единственно что полноценный гуёвый функционал утилиты net отсутствует, а так всё настраивается через гуй или реестр.
Через whatever.msc хорошо если 10% на домашней и побольше на про/серверной. Да и правку реестра настройкой через UI сложно назвать, тем более, что нагугленное проще применять шеллом или .reg файлами.
А так, все что связано с сетями, больше чем IP задать - добро пожаловать в консоль. Большая часть работы с сервисами - добро пожаловать в консоль. Падает установщик - добро пожаловать в консоль. Да даже процессы убивать и то проще через консоль, особенно после того, что они с новым диспетчером сделали.
Честно говоря, с каждым годом я все больше и больше в консоли времени провожу, когда нужно сделать больше, чем поменять цвета/картинки и посмотреть какие там сетевые адаптеры живые в данный момент. И это при том, что я кодер.
Мне интересно, ну вон в *-ксах ушли от однобайтовых кодировок и никто не умер, а Микрософт так и не смогла родить нормальный shell.
А всё что ты написал - оправдания.
Самое главное, почему MS использует две кодировки для русского языка одновременно?
Для совместимости с DOS, который умер настолько давно, что не многие помнят что это такое?
(иногда UTF-16)
Если принять во внимание, что на 9 из 10 пользовательских компьютеров стоит MS Windows, то ваше “иногда” выглядит довольно забавно :)
А я вспомнил shtirlitz . Хорошая программа была
Есть uchardet, которая для длинных текстов довольно неплохо определяет кодировку.
а мне вспомнился декодер у Лебедева https://www.artlebedev.ru/decoder/
Такое впечатление, что автор этого поста, да и переводчик, зашли в какую-то пещеру лет 20 назад и только недавно проснулись. По крайней мере 20 лет назад я в последний раз писал автоопределение кодировок. Да и бнопню видел в последний раз примерно тогда же
Да и бнопню видел в последний раз примерно тогда же
А это не обязательно видеть, достаточно столкнутся с тем что какойто софт не работает с файлами которые лежат в C:\Пользователи\Документы Васяна\Какойто-Хлам\Самыйнужный файлик 123.docx ( для любителей похейтить винду - /home/vasyan/Документы Васяна/Какойто-Хлам/Самыйнужный файлик 123.docx )
и такого софта внезапно больше чем хотелось бы
Обозначенная проблема, скорее всего, связана с пробелом, а не с кодировками.
а чем вам пробел не символ?
вообще проблема не только с пробелом, софт зачастую не признает ничего кроме ascii символов
например такойже путь с пробелами но на английском будет работать нормально почти везде где разработчики не совсем идиоты (с остальным уже поправку на то можно делать что в мире нет языка кроме английского если вы в штатах живете)
Многие программы вызывают скрипты и передают имена файлов в качестве параметров. Если не думать об экранировании, то со всякими пробелами, кавычками и бекслешами возникают вопросы.
В macOS, кстати, можно символ "/" использовать в видимых именах файлов в файндере, а в файловой системе это ":". Тоже раздолье, спасает только то, что мало кто так файлы называет.
Пару месяцев назад помогал другу решать проблему с русским путем, для какойто Java IDE не помню уже какой. Не хотела работать если в имени пользователя были русские буквы(темп она там хранила). Оказалось была в системе выбрана англиская кодировка для приложений не Unicode.
Какая-нибудь Visual Studio до сих пор наровит сохранить файл в CP1251, если там кириллические символы затесались.
Она делает интереснее: сохраняет в utf-8 если кириллические символы были сразу, и в системной кодировке если их не было. Когда они появляются - кодировка файла не меняется (сама кодировка определяется по наличию BOM).
Ну да, поэтому я если надо, сохраняю фал с кириллицей через Notepad++, а уже потом открываю его в Visual Studio.
Но меня удручает, почему студия всё ещё лезет за какой-то там системной кодировкой. И вообще не ясно, зачем эта системная кодировка нужна, почему там всё по умолчанию не в UTF-8.
От этого спасает файл .editorconfig в корне проекта, в нём можно задать кодировку и окончания строк для файлов по умолчанию, студия его понимает. Ну и компилятору добавить опцию /utf-8, чтобы исходники трактовались как UTF-8 без необходимости добавлять BOM.
А ещё Visual Studio до сих пор не умеет показывать кириллические символы в подсказках при наведении курсора на #define. Если определить #define тэст тэст2, при наведении на "тэст" высветится #define тэст \u0442\u044d\u0441\u04422.
Надо же, а мне всего 2 года назад (не 20) прислали для отладки моего редактора контактов файл .VCF, сгенерированный аутлуком. И там, внезапно, оказалась cp1251. Хотя во всех RFC на vCard прописан UTF8.
Разработчики Qt вот тоже, видимо, 20 лет бнопни не видели. И в Qt 6.0 выкинули все неюникодные кодировки, а заодно и класс QTextCodec перевели в устаревшие. Уже в 6.4 их убедили вернуть поддержку всего, что поддерживает ICU... но уже в новые классы, которые изначально были заточены только на юникод. Козу купили, козу продали, но несовместимостей успели наломать.
Автор поста ещё почему-то отсчитывает номера знакомест в двоичных числах слева направо.
Вот буквально сегодня firefox показал мне кракозябры вместо русского текста в текстовых файлах, причём раньше в меню Вид можно было выбрать кодировку руками, но они это убрали почему-то)
Настолько удивительная статья, что пришлось посмотреть биографию автора. Она всё и объясняет. Англичанин, год назад переехавший в Финляндию. Человек открыл для себя мир за пределами 26 букв.
Однако, поддерживаю предыдущего оратора: зачем это было переводить на русский?
Сложности возникают с однобайтовыми кодировками, не относящимися к Unicode. Например, сложно отличить Win-1252 от KOI8, ведь для кодирования разных вещей и та, и другая используют обычно пустой первый бит ASCII.
пустой, да еще и первый бит...
По умолчанию, в большинстве конфигураций Excel сохраняет CSV в кодировке Win-1252.
аааа
Win-1252 — это однобайтная кодировка, не относящаяся к Unicode. Это расширение ASCII, засовывающее в неиспользованный восьмой бит достаточно большое количество символов для почти каждого европейского языка.
теперь этот пустой первый бит стал восьмым и неиспользуемым...
Примерно 25 лет назад я попробовал натренировать самодельную нейросеть на распознавание кодировок. Обучалась на пентиуме примерно пару часов. Определяла на удивление точно по 20 символам текста.
Проблемы разных стандартов только в том, что всегда найдётся группа альтернативно одарённых, которые вместо доработки пишут что-то своё с нуля...
Любой стандарт обладает фатальным недостатком
Unicode возник не так? Т.е. одарённые не взяли ASCII и не расширили её?
Вот кстати, а какой толк сейчас использовать UTF-16 (обе версии)?
Насколько я понимаю, 16-битные кодировки родились тогда, когда наивно полагали, что 16 бит хватит всем. Тогда же появился wchar_t, до сих пор использующийся в WinAPI. Тогда же в Java и JavaScript строки сделали 16-битными.
Но потом оказалось, что таки нужно сильно больше символов, чем полагалось ранее и UTF-16 стало не хватать, из-за чего появились суррогатные пары. В этом свете не понятно, какие ещё преимущества осталось у этого способа представления - он требует больше памяти в сравнении с UTF-8 для в основном латинских текстов, да к тому же существует проблема порядка байт.
Вот кстати, а какой толк сейчас использовать UTF-16 (обе версии)?
Вот вы сами и ответили на свой вопрос: wchar_t до сих пор используется в WinAPI
какие ещё преимущества осталось у этого способа представления
Всегда быстрый произвольный доступ к символам по их индексам\смещению, в отличии от UTF-8.
Поломать всё win- , jvm- и веб-апи? Чтобы что?
Тут пахнет экстремизмом:)
Равны единице, или «включены» только второй и последний биты
блин, ну даже если это перевод, то можно же было исправить ошибку с нумерацией битов, они считаются справа налево.
Я извиняюсь, с какой стороны у байта лево?
Сверху
Операция SHL производит сдвиг битов в сторону старших, значит, там и лево.
Быстрый ответ:
Биты в байте нумеруются справа налево от 0 до 7.
Нет.
Ну вы можете "неткать" сколько угодно, как указали выше в ассемблере есть команды по сдвигу битов (SHL, SHR) и по ним легко понять что это так.
Так же вы можете записать в экранный байт числа 1 и 127 и в случае выбора планарного графического режима где 1 бит отражает состояние пиксела, вы увидите, что точка 127 находится слева, а точка 1 - справа, что соответствует расположению битов справа налево.
Статья по вашей ссылке про порядок БАЙТОВ (big endian, little endian). А здесь обсуждался порядок БИТОВ в байте.
@slonopotamus, как бы это есть. Называется bit endianness. Например в Eithernet, там MAC адрес вначале. Передача идет справа налево, так как справа в первом байте 2 бита от которых зависит мультикаст и уникальность MAC.
Здесь всё довольно просто; по крайней мере, в вопросе числа, обозначающего «A», в целом есть консенсус.
Да? Точно есть? :)
А ничего что https://util.unicode.org/UnicodeJsps/character.jsp?a=0410 это «А»? И визуально отличить А от A - не очень просто.
ФНС до сих пор все свои форматы клепает в расово-верном православном win-1251. Про UTF-8 они видимо не слышали. И всё бы хорошо, но только до первого клиента с национальными буквами в названии, не попадающими в 1251.
Вообще-то вместе с WIN1252 стоило бы упомянуть что у Windows в GUI одна кодировка, в cmd другая. Для примера в русской обычно стоит 1251, а в консоли 866. Что кое когда приводит к очень забавным случаям
Не "кое-когда"=иногда, а всегда.
Сейчас самым простым (менее геморройным) нахожу использование PowerShell. Там в выводе можно явно указывать кодировку. И для консоли её тоже можно явно задавать. А дедушку cmd уже пора потихоньку на пенсию отправлять. Во всяком случае принять за правило "ничего нового в cmd не создавать".
Ну почему же всегда. Если работать страна штаты и язык только EN , то никаких коллизий не возникает
а у дедушки cmd есть команда chcp
Тут цимес в том, что помимо кодировки вывода также нужно следить за кодировкой файла скрипта. И что скрипты часто становятся зависимы от языковой версии ОС Windows. Несколько раз натыкался на то, что покрыл скрипт chcp, удостоверился что скрипт в нужной кодировке... А потом запустил скрипт не на Windows RU, а на "En + RU language pack" и оно опять кракозябрами заговорило. Даже при моей набирающей в силу возраста обороты консервативности, даже при таком небольшом опыте скриптописания под Windows я не могу советовать использовать cmd в 2024 году. Это вызывает больше проблем, чем решает.
Я не говорю о том, что PS идеален. Просто из двух кучек советую выбирать наименее вонючую )
Тем временем самый популярный браузер не даёт просто скопировать ссылку на какую-нибудь страницу самой популярной интэрнэт-энциклопедии и вставить её в нормальном виде.
Это такой позор, что слов нет.
Читал, что Опера определяла такой момент и не уродовала ссылку.
UTF-16, в основном применяемая в мире Windows, Java и JavaScript
Не, не втягивайте Java в это.
KOI8 — не относящаяся к Unicode кодировка, используется там, где применяется кириллица
Где сейчас используется кодировка koi8-r?
Некоторые в ней письма шлют. Наследие старых почтовых систем...
Идея кодировки понятна, если даже старший бит отрежется, прочитать можно будет (буковки А, О и т.п. будут выглядеть одинаково, хоть и станут латинскими).
Но что за почтовые клиенты так шлют? На ум приходит разве что какой-то линуксовый скрипт из прошлого века. Виндовое тех времен вряд ли без изменений продолжает работать.
Но что за почтовые клиенты так шлют? На ум приходит разве что какой-то линуксовый скрипт из прошлого века. Виндовое тех времен вряд ли без изменений продолжает работать.
Например, один из местных форумов оповещения шлет в KOI-8. Там давно ничего не меняли («работает — не трогай!»), и все из тех времен, когда web по умолчанию был в windows-1251, а почта — в KOI-8.
Кстати, Thunderbird к KOI-8 неравнодушен. Тоже любит предлагать его по умолчанию. Тут, правда, не уверен, возможно, из-за того, что когда-то на компьютере была установлена старая версия и потом апгрейдилась, и в каких-то глобальных настройках это все осталось.
Нельзя предполагать, что все используют UTF-8