Windows 1251 или utf 8, что лучше
Обновлено: 21.11.2024
смотрит тебе в лицо. Или, может быть, «они» начинают отображаться как «они».
Итак, если у вас плохая кодировка, как понять, что сломалось? И как это исправить?
Что такое кодировка?
Если вы можете себе представить, что кодирование делает со строкой, эти ошибки легче исправить.
Строку можно представить как массив байтов или небольших чисел:
В этой кодировке 104 означает h , 33 означает ! и т. д.
Это становится сложнее, когда вы используете символы, которые менее распространены в английском языке:
Теперь сложнее сказать, какое число представляет какой символ. Вместо одного байта ṏ представлен группой байтов [225, 185, 143]. Но связь между байтами и символами все еще существует. И кодировка строки определяет эту связь.
Посмотрите, как выглядит один набор байтов при использовании разных кодировок:
Байты не изменились. Но это выглядит совсем не так. Изменение кодировки изменило способ печати строки без изменения байтов.
И не все строки могут быть представлены во всех кодировках:
Большинство кодировок небольшие и не могут обрабатывать все возможные символы. Вы увидите эту ошибку, когда символ одной кодировки не существует в другой или когда Ruby не может понять, как преобразовать символ между двумя кодировками.
Вы можете обойти эту ошибку, если передадите в encode дополнительные параметры:
Параметры invalid и undef заменяют символы, которые нельзя перевести, другими символами. По умолчанию этим символом замены является ? . (При преобразовании в Unicode это �).
К сожалению, при замене символов кодировкой вы можете потерять информацию. Вы понятия не имеете, какие байты были заменены на ? . Но если вам нужно, чтобы ваши данные были в этой новой кодировке, потеря данных может быть лучше, чем поломка.
На данный момент вы познакомились с тремя ключевыми строковыми методами, помогающими разобраться в кодировках:
encode , который переводит строку в другую кодировку (преобразовывая символы в их эквиваленты в новой кодировке)
bytes , который покажет вам байты, составляющие строку
force_encoding , который покажет вам, как эти байты будут выглядеть в другой кодировке
Основное различие между encode и force_encoding заключается в том, что encode может изменять байты, а force_encoding — нет.
Трехэтапный процесс исправления ошибок кодирования
Вы можете исправить большинство проблем с кодировкой, выполнив три действия:
1. Узнайте, в какой кодировке фактически находится ваша строка.
Звучит просто. Но только потому, что строка указывает на некоторую кодировку, не означает, что это действительно так:
Это неправильно — если бы это было на самом деле UTF-8, в нем не было бы этого странного числа с обратной косой чертой. Так как же определить правильную кодировку для вашей строки?
Многие старые версии программного обеспечения придерживаются одной кодировки по умолчанию, поэтому вы можете выяснить, откуда были получены данные. Кто-нибудь вставлял из Word? Это может быть Windows-1252. Это пришло из файла или вы взяли его со старого веб-сайта? Это может быть ISO-8859-1.
Я также обнаружил, что полезно искать таблицы кодирования, подобные тем, которые находятся на связанных страницах Википедии. В этих таблицах вы можете найти символы, на которые ссылаются неизвестные номера, и посмотреть, имеют ли они смысл в контексте.
В этом примере диаграмма Windows-1252 показывает, что байт 99 представляет символ «™». Байт 99 не существует в ISO-8859-1. Если ™ здесь имеет смысл, вы можете предположить, что ввод был в Windows-1252, и двигаться дальше. В противном случае вы можете продолжать исследования, пока не найдете персонажа, который покажется вам более разумным.
2. Решите, какую кодировку вы хотите использовать для строки.
Это просто. Если у вас нет действительно веской причины, вы хотите, чтобы ваши строки были в кодировке UTF-8.
3. Перекодируйте вашу строку из кодировки на шаге 1 в кодировку на шаге 2.
Это можно сделать с помощью метода encode. В этом примере наша строка была в кодировке Windows-1252, и мы хотим сделать ее кодировкой UTF-8. Довольно просто:
Намного лучше. (Хотя порядок кодировок в этом вызове всегда казался мне обратным).
Представить разные интерпретации одного и того же массива байтов может быть сложно. Особенно когда одна из этих интерпретаций не работает. Но есть отличный способ привыкнуть к кодировкам: поэкспериментировать с ними.
Откройте консоль irb и повозитесь с encode , bytes и force_encoding . Посмотрите, как encode изменяет байты, составляющие строку. Создайте интуицию о том, как выглядят разные кодировки. Когда вы освоитесь с кодировками и выполните эти шаги, вы за считанные минуты исправите то, на что раньше у вас уходили часы.
Наконец, если вы хотите узнать, как сделать привычкой изучение подобных вещей на практике, возьмите бесплатный пример главы из моей книги. Разбирать вещи в консоли — это действительно увлекательный способ изучения подобных идей.
Проталкиваете учебники, но так ничего и не узнали?
Вы трижды просматривали одно и то же руководство, но до сих пор не знаете, как создать настоящее приложение?
В этом бесплатном 7-дневном курсе по Rails вы узнаете, как запускать собственные приложения на Rails, не сдаваясь и не перегружаясь.
Вы также узнаете о самом быстром способе изучения новых функций Rails с помощью 32-страничного примера Practicing Rails: Learn Rails без перегрузок.
Зарегистрируйтесь ниже, чтобы начать:
Спасибо! Через несколько минут вы должны получить от меня электронное письмо с бесплатным образцом главы. Пока вы ждете, я хотел бы встретиться с вами в Твиттере. Вы можете узнавать немного больше о Ruby каждый день — я делюсь лучшими статьями о Ruby и Rails, которые я читал. Кроме того, он отлично подходит для коротких бесед и ответов на вопросы о разработке программного обеспечения.
Понравилась ли вам эта статья? Вы должны прочитать это:
Комментарии
Я Джастин Вайс, инженер-программист компании Aha! и автор нескольких жемчужин Ruby, таких как robut и resque_unit. Я хотел бы услышать от вас, поэтому вы должны отправить мне электронное письмо или подписаться на меня в Твиттере.
Преодолейте шум и сложность и наконец-то станьте разработчиком Rails, каким вы должны быть.
Описывает, как PowerShell использует кодировку символов для ввода и вывода строковых данных.
Подробное описание
Юникод – это всемирный стандарт кодировки символов. Система использует Unicode исключительно для обработки символов и строк. Подробное описание всех аспектов Unicode см. в Стандарте Unicode.
PowerShell по умолчанию использует набор символов Unicode. Однако некоторые командлеты имеют параметр Encoding, который может указывать кодировку для другого набора символов. Этот параметр позволяет выбрать конкретную кодировку символов, необходимую для взаимодействия с другими системами и приложениями.
Следующие командлеты имеют параметр Encoding:
- Microsoft.PowerShell.Management
- Добавить контент
- Получить содержание
- Установить содержимое
- Экспорт-Clixml
- Экспорт-CSV
- Экспорт-PSSession
- Формат-шестнадцатеричный
- Импорт-CSV
- Из файла
- Select-String
- Отправить сообщение
Знак порядка байтов
Знак порядка следования байтов (BOM) — это подпись Unicode в первых нескольких байтах файла или текстового потока, указывающая, какая кодировка Unicode используется для данных. Дополнительные сведения см. в документации по меткам порядка следования байтов.
В Windows PowerShell любая кодировка Unicode, кроме UTF7, всегда создает спецификацию. PowerShell (v6 и выше) по умолчанию использует utf8NoBOM для всего вывода текста.
Для лучшей общей совместимости избегайте использования спецификаций в файлах UTF-8. Платформы Unix и утилиты наследия Unix, также используемые на платформах Windows, не поддерживают спецификации.
Точно так же следует избегать кодировки UTF7. UTF-7 не является стандартной кодировкой Unicode и записывается без спецификации во всех версиях PowerShell.
Создание сценариев PowerShell на Unix-подобной платформе или использование кроссплатформенного редактора в Windows, например Visual Studio Code, приводит к созданию файла, закодированного с использованием UTF8NoBOM . Эти файлы нормально работают в PowerShell, но могут не работать в Windows PowerShell, если файл содержит символы, отличные от Ascii.
Если вам нужно использовать в скриптах символы, отличные от Ascii, сохраните их как UTF-8 с BOM. Без спецификации Windows PowerShell ошибочно интерпретирует ваш сценарий как закодированный в устаревшей кодовой странице "ANSI". И наоборот, файлы со спецификацией UTF-8 могут быть проблематичными на Unix-подобных платформах. Многие инструменты Unix, такие как cat , sed , awk и некоторые редакторы, такие как gedit, не знают, как обрабатывать спецификацию.
Кодировка символов в Windows PowerShell
В PowerShell 5.1 параметр Encoding поддерживает следующие значения:
- Ascii Использует набор символов Ascii (7-битный).
- BigEndianUnicode Использует кодировку UTF-16 с порядком байтов от старшего к старшему.
- BigEndianUTF32 Использует кодировку UTF-32 с прямым порядком байтов.
- Байт Кодирует набор символов в последовательность байтов.
- По умолчанию. Используется кодировка, соответствующая активной кодовой странице системы (обычно ANSI).
- Oem Использует кодировку, соответствующую текущей кодовой странице OEM в системе.
- Строка аналогична Unicode .
- Юникод использует кодировку UTF-16 с прямым порядком байтов.
- Неизвестно То же, что и Unicode .
- UTF32 Использует UTF-32 с прямым порядком байтов.
- UTF7 использует UTF-7.
- UTF8 использует кодировку UTF-8 (со спецификацией).
Как правило, Windows PowerShell по умолчанию использует кодировку Unicode UTF-16LE. Однако кодировка по умолчанию, используемая командлетами в Windows PowerShell, несовместима.
При использовании любой кодировки Unicode, кроме UTF7, всегда создается спецификация.
Для командлетов, записывающих выходные данные в файлы:
Out-File и операторы перенаправления > и >> создают UTF-16LE, который заметно отличается от Set-Content и Add-Content .
Командлет New-ModuleManifest и Export-CliXml также создают файлы UTF-16LE.
Если целевой файл пуст или не существует, команды Set-Content и Add-Content используют кодировку по умолчанию. По умолчанию используется кодировка, указанная в устаревшей кодовой странице ANSI активной локали системы.
Export-Csv создает файлы Ascii, но использует другую кодировку при использовании параметра Append (см. ниже).
Export-PSSession по умолчанию создает файлы UTF-8 со спецификацией.
New-Item -Type File -Value создает файл UTF-8 без спецификации.
Send-MailMessage по умолчанию использует кодировку по умолчанию.
Start-Transcript создает файлы Utf8 со спецификацией. При использовании параметра Append кодировка может быть другой (см. ниже).
Для команд, которые присоединяются к существующему файлу:
Out-File -Append и оператор перенаправления >> не пытаются сопоставить кодировку содержимого существующего целевого файла. Вместо этого они используют кодировку по умолчанию, если не используется параметр Encoding. При добавлении содержимого необходимо использовать исходную кодировку файлов.
При отсутствии явного параметра Encoding командлет Add-Content определяет существующую кодировку и автоматически применяет ее к новому содержимому. Если существующее содержимое не имеет спецификации, используется кодировка ANSI по умолчанию. Поведение Add-Content такое же, как и в PowerShell (v6 и выше), за исключением кодировки по умолчанию Utf8 .
Export-Csv -Append соответствует существующей кодировке, если целевой файл содержит спецификацию. При отсутствии спецификации используется кодировка Utf8.
Start-Transcript -Append соответствует существующей кодировке файлов, содержащих спецификацию. При отсутствии спецификации по умолчанию используется кодировка Ascii. Это кодирование может привести к потере данных или повреждению символов, если данные в расшифровке содержат многобайтовые символы.
Для командлетов, считывающих строковые данные при отсутствии спецификации:
Get-Content и Import-PowerShellDataFile используют кодировку ANSI по умолчанию. ANSI также используется ядром PowerShell при чтении исходного кода из файлов.
Import-Csv , Import-CliXml и Select-String предполагают Utf8 при отсутствии спецификации.
Кодировка символов в PowerShell
В PowerShell (v6 и выше) параметр Encoding поддерживает следующие значения:
- ascii : использует кодировку для набора символов ASCII (7-бит).
- bigendianunicode : кодирует в формате UTF-16, используя порядок байтов с обратным порядком байтов.
- oem : использует кодировку по умолчанию для MS-DOS и консольных программ.
- Unicode : кодирует в формате UTF-16, используя порядок байтов с прямым порядком байтов.
- utf7 : кодирует в формате UTF-7.
- utf8 : кодирует в формате UTF-8 (без спецификации).
- utf8BOM: кодирует в формате UTF-8 с меткой порядка байтов (BOM).
- utf8NoBOM: кодирует в формате UTF-8 без метки порядка байтов (BOM).
- utf32 : кодирует в формате UTF-32.
PowerShell по умолчанию использует utf8NoBOM для всех выходных данных.
Изменение кодировки по умолчанию
PowerShell имеет две переменные по умолчанию, которые можно использовать для изменения режима кодирования по умолчанию.
- $PSDefaultParameterValues
- $OutputEncoding
Начиная с PowerShell 5.1 операторы перенаправления ( > и >> ) вызывают командлет Out-File. Таким образом, вы можете установить для них кодировку по умолчанию, используя привилегированную переменную $PSDefaultParameterValues, как показано в этом примере:
Используйте следующую инструкцию, чтобы изменить кодировку по умолчанию для всех командлетов, имеющих параметр Encoding.
Помещение этой команды в ваш профиль PowerShell делает предпочтение глобальным параметром сеанса, который влияет на все команды и сценарии, которые явно не указывают кодировку.
Точно так же вы должны включать в свои скрипты или модули такие команды, которые должны вести себя так же. Использование этих команд гарантирует одинаковое поведение командлетов даже при запуске другим пользователем, на другом компьютере или в другой версии PowerShell.
Автоматическая переменная $OutputEncoding влияет на кодировку, используемую PowerShell для связи с внешними программами. Это не влияет на кодировку, которую операторы перенаправления вывода и командлеты PowerShell используют для сохранения в файлы.
При использовании VS Code для создания и редактирования сценариев PowerShell важно, чтобы ваши файлы сохранялись с использованием правильного формата кодировки символов.
Что такое кодировка файлов и почему это важно?
VS Code управляет интерфейсом между вводом человеком строк символов в буфер и чтением/записью блоков байтов в файловую систему. Когда VS Code сохраняет файл, он использует текстовую кодировку, чтобы решить, какими байтами становится каждый символ. Дополнительные сведения см. в разделе about_Character_Encoding.
Аналогично, когда PowerShell запускает сценарий, он должен преобразовать байты в файле в символы, чтобы преобразовать файл в программу PowerShell. Поскольку VS Code записывает файл, а PowerShell читает файл, они должны использовать одну и ту же систему кодирования. Этот процесс разбора скрипта PowerShell проходит следующим образом: байты -> символы -> токены -> абстрактное синтаксическое дерево — > выполнение.
И VS Code, и PowerShell устанавливаются с разумной конфигурацией кодировки по умолчанию. Однако кодировка по умолчанию, используемая PowerShell, изменилась с выпуском PowerShell 6. Чтобы у вас не было проблем с использованием PowerShell или расширения PowerShell в VS Code, необходимо правильно настроить параметры VS Code и PowerShell.
Распространенные причины проблем с кодировкой
Проблемы с кодировкой возникают, когда кодировка VS Code или файла сценария не соответствует ожидаемой кодировке PowerShell. PowerShell не может автоматически определить кодировку файла.
У вас больше шансов столкнуться с проблемами кодирования, если вы используете символы, не входящие в 7-битный набор символов ASCII. Например:
- Расширенные небуквенные символы, такие как длинное тире ( — ), неразрывный пробел ( ) или двойная левая кавычка ( " )
- Латинские символы с ударением ( É , ü )
- Нелатинские символы, такие как кириллица ( Д , Ц )
- Символы CJK (本, 화, が)
- Кодировки VS Code и PowerShell не изменились по сравнению с их значениями по умолчанию. Для PowerShell 5.1 и более ранних версий кодировка по умолчанию отличается от кодировки VS Code.
- Другой редактор открыл и перезаписал файл в новой кодировке. Это часто случается с ISE.
- Файл возвращается в систему управления версиями в кодировке, отличной от ожидаемой VS Code или PowerShell. Это может произойти, если соавторы используют редакторы с разными конфигурациями кодирования.
Как понять, что у вас проблемы с кодировкой
Часто ошибки кодирования проявляются в виде ошибок синтаксического анализа в сценариях. Если вы обнаружите странные последовательности символов в своем скрипте, это может быть проблемой. В приведенном ниже примере вместо символов â€" отображается короткое тире (–):
Эта проблема возникает из-за того, что VS Code кодирует символ в UTF-8 как байты 0xE2 0x80 0x93 . Когда эти байты декодируются как Windows-1252, они интерпретируются как символы â€".
Некоторые странные последовательности символов, которые вы можете увидеть, включают:
- €" вместо –
- €" вместо -
- №2 вместо Ä
- Â вместо (неразрывный пробел)
- é вместо é
В этом удобном справочнике перечислены распространенные шаблоны, указывающие на проблему с кодировкой UTF-8/Windows-1252.
Как расширение PowerShell в VS Code взаимодействует с кодировками
Расширение PowerShell взаимодействует со сценариями несколькими способами:
- Когда сценарии редактируются в VS Code, содержимое отправляется VS Code на расширение. Протокол языкового сервера требует, чтобы это содержимое передавалось в кодировке UTF-8. Поэтому расширение не может получить неправильную кодировку.
- Когда сценарии выполняются непосредственно в интегрированной консоли, PowerShell напрямую считывает их из файла. Если кодировка PowerShell отличается от кодировки VS Code, здесь что-то может пойти не так.
- Когда сценарий, открытый в VS Code, ссылается на другой сценарий, не открытый в VS Code, расширение возвращается к загрузке содержимого этого сценария из файловой системы. Расширение PowerShell по умолчанию использует кодировку UTF-8, но использует метку порядка байтов или определение спецификации для выбора правильной кодировки.
Выбор правильной кодировки
Разные системы и приложения могут использовать разные кодировки:
- В .NET Standard, в Интернете и в мире Linux в настоящее время преобладает кодировка UTF-8.
- Многие приложения .NET Framework используют кодировку UTF-16. По историческим причинам его иногда называют «Юникод». Этот термин теперь относится к широкому стандарту, включающему как UTF-8, так и UTF-16.
- В Windows многие нативные приложения, созданные до Unicode, по-прежнему используют Windows-1252 по умолчанию.
В кодировках Unicode также используется понятие метки порядка байтов (BOM). Спецификации появляются в начале текста, чтобы сообщить декодеру, какую кодировку использует текст. Для многобайтовых кодировок спецификация также указывает порядок байтов кодировки. Спецификации предназначены для байтов, которые редко встречаются в тексте, отличном от Unicode, что позволяет разумно предположить, что текст является Unicode, когда присутствует спецификация.
Спецификации являются необязательными, и их внедрение не так популярно в мире Linux, поскольку везде используется надежное соглашение UTF-8. Большинство приложений Linux предполагают, что текстовый ввод закодирован в UTF-8. Хотя многие приложения Linux распознают и правильно обрабатывают спецификацию, некоторые из них этого не делают, что приводит к артефактам в тексте, обрабатываемом этими приложениями.
- Если вы работаете в основном с приложениями Windows и Windows PowerShell, вам следует предпочесть такую кодировку, как UTF-8 с BOM или UTF-16.
- Если вы работаете на разных платформах, вам следует предпочесть UTF-8 с BOM.
- Если вы работаете в основном в контексте, связанном с Linux, вам следует предпочесть кодировку UTF-8 без спецификации.
- Windows-1252 и latin-1 по сути являются устаревшими кодировками, которых следует избегать, если это возможно. Однако от них могут зависеть некоторые старые приложения Windows.
- Также стоит отметить, что подписание скрипта зависит от кодировки, а это означает, что изменение кодировки в подписанном скрипте потребует отмены подписи.
Настройка кода VS
Кодировка VS Code по умолчанию — UTF-8 без спецификации.
Чтобы установить кодировку VS Code, перейдите к настройкам VS Code ( Ctrl + , ) и установите параметр "files.encoding":
- utf8 : [UTF-8] без спецификации
- utf8bom : [UTF-8] со спецификацией
- utf16le : обратный порядок байтов [UTF-16]
- utf16be: обратный порядок байтов [UTF-16].
- Windows1252 : [Windows-1252]
Вы должны получить раскрывающийся список для этого в представлении GUI или завершения для него в представлении JSON.
Вы также можете добавить следующее к автоопределению кодировки, когда это возможно:
Если вы не хотите, чтобы эти настройки влияли на все типы файлов, VS Code также допускает настройку для каждого языка. Создайте настройку для конкретного языка, поместив настройки в поле [ ]. Например:
Вы также можете рассмотреть возможность установки трекера Gremlins для Visual Studio Code. Это расширение показывает некоторые символы Unicode, которые легко искажаются, потому что они невидимы или выглядят как обычные символы.
Настройка PowerShell
Кодировка PowerShell по умолчанию зависит от версии:
- В PowerShell 6+ по умолчанию используется кодировка UTF-8 без спецификации на всех платформах.
- В Windows PowerShell кодировкой по умолчанию обычно является Windows-1252, расширение latin-1, также известное как ISO 8859-1.
В PowerShell 5+ вы можете найти кодировку по умолчанию следующим образом:
Следующий сценарий можно использовать, чтобы определить, какую кодировку ваш сеанс PowerShell выводит для сценария без спецификации.
Возможно настроить PowerShell для использования данной кодировки в более широком смысле, используя настройки профиля. См. следующие статьи:
Невозможно заставить PowerShell использовать определенную кодировку ввода. PowerShell 5.1 и более ранних версий, работающих в Windows с языковым стандартом en-US, по умолчанию использует кодировку Windows-1252, если нет спецификации. Другие настройки локали могут использовать другую кодировку. Чтобы обеспечить совместимость, лучше всего сохранять скрипты в формате Unicode со спецификацией.
Любые другие имеющиеся у вас инструменты, которые касаются сценариев PowerShell, могут зависеть от вашего выбора кодировки или перекодирования ваших сценариев в другую кодировку.
Существующие скрипты
Сценарии, уже находящиеся в файловой системе, возможно, потребуется перекодировать в выбранную вами новую кодировку. В нижней панели VS Code вы увидите метку UTF-8. Щелкните его, чтобы открыть панель действий, и выберите Сохранить с кодировкой. Теперь вы можете выбрать новую кодировку для этого файла. Подробные инструкции см. в кодировке VS Code.
Если вам нужно перекодировать несколько файлов, вы можете использовать следующий скрипт:
Интегрированная среда сценариев PowerShell (ISE)
Если вы также редактируете скрипты с помощью интегрированной среды сценариев PowerShell, вам необходимо синхронизировать там свои настройки кодирования.
ISE должен учитывать спецификацию, но также можно использовать отражение для установки кодировки. Обратите внимание, что это не будет сохраняться между запусками.
Программное обеспечение для контроля версий
Некоторые инструменты управления исходным кодом, такие как git, игнорируют кодировки; git просто отслеживает байты. Другие, такие как Azure DevOps или Mercurial, не могут. Даже некоторые инструменты на основе git полагаются на декодирование текста.
В этом случае убедитесь, что вы:
- Настройте кодировку текста в системе управления версиями в соответствии с конфигурацией VS Code.
- Убедитесь, что все ваши файлы проверены системой контроля версий в соответствующей кодировке.
- Остерегайтесь изменений кодировки, полученных через систему управления версиями. Ключевым признаком этого является diff, указывающий на изменения, но при этом кажется, что ничего не изменилось (потому что байты изменились, а символы — нет).
Среда для соавторов
Помимо настройки системы управления версиями, убедитесь, что у ваших соавторов файлов, которыми вы делитесь, нет настроек, переопределяющих вашу кодировку путем перекодирования файлов PowerShell.
Другие программы
Любая другая программа, которая читает или записывает сценарий PowerShell, может перекодировать его.
- Использование буфера обмена для копирования и вставки сценария. Это часто встречается в таких сценариях, как:
- Копирование скрипта на виртуальную машину
- Копирование сценария из сообщения электронной почты или веб-страницы
- Копирование сценария в документ Microsoft Word или PowerPoint или из него
- Блокнот
- вим
- Любой другой редактор сценариев PowerShell
- Get-Content/Set-Content/Out-File
- Операторы перенаправления PowerShell, такие как > и >>
- sed/awk
- Веб-браузер при загрузке скриптов
- Файловый ресурс
Некоторые из этих инструментов работают с байтами, а не с текстом, но другие предлагают конфигурации кодирования. В тех случаях, когда вам нужно настроить кодировку, вам нужно сделать ее такой же, как кодировка вашего редактора, чтобы избежать проблем.
Другие ресурсы по кодированию в PowerShell
Есть еще несколько полезных статей о кодировании и настройке кодирования в PowerShell, которые стоит прочитать:
289, 2
Привет всем
у меня есть файл utf-8, который я пытаюсь преобразовать в WINDOWS-1251 на linux
безуспешно
имя файла utf-8 когда я пытаюсь сделать:15 129, 5 008
Еще 10 обсуждений, которые могут вас заинтересовать
1. UNIX для начинающих: вопросы и ответы
Преобразование файлов в формат UTF-8 в AIX 7.1
Дорогие, у меня есть сценарий оболочки, отлично работающий в Oracle Linux, который определяет кодировку (точнее, кодировку) файлов в указанном каталоге с помощью команды "file" (команда file выводит кодировку в Linux , но не делает этого в AIX), то, если файл не является текстом UTF-8. (4 ответа)
Обсуждение начато: JeanM-1
2. Программирование оболочки и создание сценариев
Преобразовать файл UTF-8 в ASCII/ISO8859-1 ИЛИ заменить символы
Я пытаюсь разработать скрипт, который будет работать с исходным файлом UTF-8 и выполнять одно или несколько из следующих действий. Он примет целевую кодировку в качестве аргумента, например. US-ASCII или ISO-8859-1 и т. д. 1. Он должен заменить все вхождения символов за пределами целевого набора символов на " " (пробел) или. (3 ответа)
Обсуждение начато: hemkiran.s
3. Linux
Помощь в преобразовании файла из UNIX UTF-8 в Windows UTF-16
Привет, я попытался преобразовать файл UTF-8 в файл формата Windows UTF-16, как показано ниже, с unix-машины unix2dos out.txt, и я получаю некоторые китайские символы, как показано ниже, которые я открыл преобразованный файл на машине Windows. ЯЗЫК=en_US.UTF-8. (3 ответа)
Обсуждение начато: phanidhar6039
4. Программирование оболочки и создание сценариев
Преобразуйте этот сценарий Windows, чтобы я мог использовать его на Macbook
Привет, ребята, я уже несколько дней ломаю голову над чем-то, что кажется слишком простым, чтобы быть таким сложным для меня. У меня есть этот скрипт bash, который я отлично использовал на своем ПК с Windows. Я перенес этот файл на свой Macbook и попытался запустить его, но завтра он терпит неудачу. Это содержимое файла. (3 ответа)
Обсуждение начато: richsark
5. Красная шляпа
Не удается преобразовать 7-битный ASCII в UTF-8
Здравствуйте, я пытаюсь преобразовать 7-битный файл ASCII в UTF-8. Раньше я использовал iconv, хотя по какой-то причине он не может его распознать и говорит, что кодировка файла неизвестна. Когда я использовал пакет ascii2uni с другим пакетом, ./ascii2uni -a K -a I -a J -a X test_file > new_test_file Это все еще. (2 ответа)
Обсуждение начато: rockf1bull
6. Программирование оболочки и создание сценариев
Преобразование метасимволов Windows в обычный текст
Привет всем. Мне нужно взять плоский файл, переданный по FTP из Windows в Unix, и преобразовать его для загрузки в базу данных MySQL без ручного вмешательства. Однако некоторые символы являются «причудливыми» (например, причудливые двойные кавычки «Начало» и «Конец» из Windows), которые отображаются как коды с использованием vi. Мне нужно. (4 ответа)
Обсуждение начато: superdelic
7. Солярис
Ошибка аутентификации MySQL 1251 в Solaris.
Я пытаюсь подключиться к MySQL, установленному в Windows, с компьютера Solaris. При этом возникает ошибка: «Клиент не поддерживает протокол аутентификации, запрошенный сервером; рассмотрите возможность обновления клиента MySQL; errno = 1251». Я установил mysql-5.1.34-solaris10-sparc.tar.gz. (1 ответ)
Обсуждение начато: amit_27
8. UNIX для продвинутых и опытных пользователей
Преобразовать шестнадцатеричное значение UTF-8 в символ
Здравствуйте, у меня есть не-ascii-символ (Ŵ), который может быть представлен в кодировке UTF-8 как эквивалентное шестнадцатеричное значение (\xC5B4). Есть ли в unix функция для преобразования этого шестнадцатеричного значения обратно для отображения символа? (10 ответов)
Обсуждение начато: sumirmehta
9. Солярис
удаленно преобразовать ОС Windows в Solaris
У меня есть терминал Windows 2000, который я хочу преобразовать в Solaris 10. Я удаленно подключен к терминалу Windows через iLO, а затем вставил DVD-диск Solaris в свой локальный дисковод. Теперь, когда я подключаюсь к машине с Windows через «RDP» — я вижу там локальный DVD — и ЕСЛИ я затем перезагружаю удаленную машину. (1 ответ)
Обсуждение начато: panchpan
10. Программирование
Как преобразовать Ascii -> UTF-8 и обратно в C++
При работе с русским текстом под FreeBSD&MySQL мне нужно преобразовать строку из MySQL в формат Unicode. Я только начал свой путь в C++ под FreeBSD, поэтому, пожалуйста, объясните мне, как я могу получить ascii-код переменной Char, а также как я могу получить символ в переменной с указанным ascii. (3 ответа)
Читайте также: