Перевод в разные кодировки: Онлайн декодер

Содержание

Что нужно знать каждому разработчику о кодировках и наборах символов для работы с текстом / Хабр

Это первая часть перевода статьи What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text

Если вы работаете с текстом в компьютере, вам обязательно нужно знать про кодировки. Даже если вы посылаете электронные письма. Даже если вы их только получаете. Необязательно понимать каждую деталь, но надо хотя бы знать, что из себя представляют кодировки. И вот первая хорошая новость: статья может быть немного запутанной, но основная идея очень и очень простая.

Эта статья о кодировках и наборах символов.

Статья Джоеэля Спольски под названием «Абсолютный минимум о Unicode и наборе символов для каждого разработчика(без исключений!)» будет хорошей вводной и мне доставляет большое удовольствие перечитывать ее время от времени. Я стесняюсь отсылать к ней тех людей, которые испытывают трудности с пониманием проблем с кодировкам, хотя она довольно легкая в плане технических деталей. Я надеюсь, эта статья прольет немного света на то, чем именно являются кодировки, и почему все ваши тексты оказываются испорченными в самый ненужный момент. Статья предназначена для разработчиков(главным образом, на PHP), но пользу от нее может получить любой пользователь компьютера.

Основы

Все более или менее слышали об этом, но каким-то образом знание испаряется, когда дело доходит до обсуждения, так что вот вам: компьютер не может хранить буквы, числа, картинки или что-либо еще. Он может запомнить только биты. Бит имеет только два значения: ДА или НЕТ, ПРАВДА или ЛОЖЬ, 1 или 0 или любую другую пару, которую вы можете вообразить. Раз уж компьютер работает с электричеством, бит представлен электрическим зарядом: он либо есть, либо его нет. Людям проще представлять это в виде 1 и 0, так что я буду придерживаться этих обозначений.

Чтобы с помощью битов представлять нечно полезное, нам нужны правила. Надо сконвертировать последовательность бит в что-то похожее на буквы, числа и изображения, используя схему кодирования, или, коротко, кодировку. Вот так, например:

01100010 01101001 01110100 01110011
b i t s

В этой кодировке, 01100010 представляет из себя ‘b’, 01101001 — ‘i’, 01110100 — ‘t’, 01110011 — ‘s’. Конкретная последовательность бит соответствует букве, а буква – конкретной последовательности битов. Если вы можете запомнить последовательности для 26 букв или умеете действительно быстро находить нужное соответствие, то вы сможете читать биты, как книги.

Упомянутая схема носит название ASCII. Строка с нолями и единицами разбивается на части по 8 бит(по байтам). Кодировка ASCII определяет таблицу перевода байтов в человеческие буквы. Вот небольшой кусочек этой таблицы:

bits character
01000001 A
01000010 B
01000011 C
01000100 D
01000101 E
01000110 F

В ней 95 символов, включая буквы от A до Z, в нижнем и верхнем регистре, цифры от 0 до 9, с десяток знаков препинания, амперсанд, знак доллара и прочие. В нее также включены 33 значения, такие как пробел, табуляция, перевод строки, возврат символа и прочие. Это непечатаемые символы, хотя они видимы человеку и используются им. Некоторые значения полезны только компьютеру, такие как коды начала и конца текста. Всего в кодировку ASCII включены 128 символов — прекрасное ровное число для тех, кто смыслит в компьютерах, так как оно использует все комбинации 7ми битов (от 0000000 до 1111111).

Вот вам способ представить человеческую строку, используя только единицы и нули:

01001000 01100101 01101100 01101100 01101111 00100000
01010111 01101111 01110010 01101100 01100100
«Hello World»

Важные термины

Для кодирования чего-либо в ASCII двигайтесь справа налево, подменяя буквы на биты. Для декодирования битов в символы, следуйте по таблице слева направо, подменяя биты на буквы.

encode |enˈkōd|
verb [ with obj. ]
convert into a coded form
code |kōd|
noun
a system of words, letters, figures, or other symbols substituted for other words, letters, etc.

Кодирование – это представление чего-либо чем-нибудь другим. Кодировка – это набор правил, описывающий способ перевода одного представления в другое.

Прочие термины, заслуживающие прояснения:

Набор символов, чарсет, charset – Набор символов, который может быть закодирован. «Кодировка ASCII включает набор из 128 символов». Синоним к кодировке.

Кодовая страница – страница кодов, закрепляюшая за символом набор битов. Таблица. Синоним к кодировке.

Строка – пачка чего-нибудь, объединенных вместе. Битовая строка – это пачка бит, такая как 00011011. Символьная строка – это пачка символов, например «Вот эта». Синоним к последовательности.

Двоичный, восьмеричный, десятичный, шестнадцатеричный

Существует множество способов записывать числа. 10011111 – это бинарная запись для 237 в восьмеричной, 159 в десятичной и 9F в шестнадцатиричной системах. Значения у всех этих чисел одинаково, но шестнадцатиричная система короче и проще для понимания, чем двоичная. Я буду придерживаться двоичной системы в этой статье, чтобы улучшить понимание и убрать лишний уровень абстракции. Не пугайтесь, встречая коды символов в других нотациях, все значения эквиваленты.

Excusez-Moi?

Раз уж мы теперь знаем, о чем говорим, заметим: 95 символов – это совсем немного, когда речь идет о языках. Этот набор покрывает базовый английский, но как насчет французских символов? А вот это Straßen¬übergangs¬änderungs¬gesetz из немецкого языка? А приглашение на smörgåsbord в шведском? В-общем, не получится. Не в ASCII. Спецификация на представление é, ß, ü, ä, ö просто отсутствует.

“Постойте-ка”, скажут европейцы, “в обычных компьютерах с 8 битами в байте, ASCII никак не использует бит, который всегда равен 0! Мы можем использовать его, чтобы расширить таблицу еще на 128 значений”. И было так. Но способов обозначить звучание гласных еще слишком много. Не все сочетания букв и значений, используемые в европейских языках, влезают в таблицу из 256 записей. Так мир пришел к изобилию кодировок, стандартов, стандартов де-факто и недостандартов, которые покрывают все субнаборы символов. Кому-то понадобилось написать документ на шведском или чешском, и, не найдя нужной кодировки, просто изобрел еще одну. Или я думаю, что все так и произошло.

Не забывайте о русском, хинди, арабском, корейском и множестве других живых языков планеты. Про мертвые уж молчим. Как только вы найдете способ писать документ, использующий несколько языков, попробуйте добавить китайский. Или японский. Оба содержат тысячи символов. И у вас всего 256 значений. Вперед!

Многобайтные кодировки

Для создания таблиц, которые содержат более 256 символов, одного байта просто недостаточно. Двух байтов (16 бит) хватит для кодировки 65536 различных значений. Big-5 например, кодировка двухбайтная. Вместо разбиения последовательности битов в блоки по 8, она использует блоки по 16 битов и содержит большую(я имею ввиду БОЛЬШУЮ) таблицу с соответствием. Big-5 в своем основном виде покрывает большинство символов традиционного китайского. GB18030 – это похожая кодировка, но она включает как традиционный, так и упрощенный китайский.

И, прежде чем вы спросите, да, есть кодировки только для упрощенного китайского. А разве одной недостаточно?

Вот кусок таблицы GB18030:

bits character
10000001 01000000 丂
10000001 01000001 丄
10000001 01000010 丅
10000001 01000011 丆
10000001 01000100 丏

GB18030 покрывает довольно большой диапазон символов, включая большую часть латинских символов, но в конце концов, это всего лишь еще одна кодировка среди многих других.

Путаница с Unicode

В итоге тем, кому больше всех надоела эта каша, пришла в голову идея разработать единый стандарт, объединяющий все кодировки. Этим стандартом стал Unicode. Он определяет невероятную таблицу из 1 114 112 пунктов, используемую для всех вариантов букв и символов. Этого хватит для кодирования всех европейских, средне-азиатских, дальневосточных, южных, северных, западных, доисторических и будущих символов, о которых человечеству известно. Unicode позволяет создать документ на любом языке любыми символами, которые можно ввести в компьютер. Это было невозможно, или очень затруднительно до эры Unicode. В стандарте есть даже неофициальная секция под клингонский. Вы поняли, Unicode настолько большой, чтобы допускает неофициальные секции.

Итак, и сколько же байт использует Unicode для кодирования?

Нисколько. Потому что Unicode – это не кодировка.
Смущены? Не вы одни. Unicode в первую и главную очередь определяет таблицу пунктов для символов. Это такой способ сказать «65 – A, 66 – B, 9731 – »(я не шучу, так и есть). Как эти пункты кодируются в байты является предметом другого разговора. Для представления 1 114 112 значений двух байт недостаточно. Трех достаточно, но 3 – странное число, так что 4 является комфортным минимумом. Но, пока вы не используете китайский, или другой язык со множеством символов, которые требуют большого количества битов для кодирования, вам никогда не придет в голову использовать толстую колбасу из 4х байт. Если “A” всегда кодируется в 00000000 00000000 00000000 01000001, а “B” – в 00000000 00000000 00000000 01000010, то документ, использующий такую кодировку, распухнет в 4 раза.

Существует несколько способов решения этой проблемы. UTF-32 – это кодировка, которая переводит все символы в наборы из 32 бит. Это простой алгоритм, но изводящий много места впустую. UTF-16 и UTF-8 являются кодировками с переменной длиной кодирования. Если символ может быть закодирован одним байтом(потому что номер пункта символа очень маленький), UTF-8 закодирует его одним байтом. Если нужно 2 байта, то используется 2 байта. Кодировка сообщает старшими битами, сколькими битами кодируется текущий символ. Такой способ экономит место, но так же и тратит его в случае, если эти сигнальные биты часто используются. UTF-16 является компромиссом: все символы как минимум двухбайтные, но их размер может увеличиваться до 4 байт, если нужно.

character encoding bits
A UTF-8 01000001
A UTF-16 00000000 01000001
A UTF-32 00000000 00000000 00000000 01000001
あ UTF-8 11100011 10000001 10000010
あ UTF-16 00110000 01000010
あ UTF-32 00000000 00000000 00110000 01000010

И все. Unicode – это огромная таблица соответствия символов и чисел, а различные UTF кодировки определяют, как эти числа переводятся в биты. В-общем, Unicode – это просто еще одна схема. Ничего особенного, она просто пытается покрыть все, что можно, оставаясь эффективной. И это хорошо.

Пункты

Символы определяются по их Unicode-пунктам. Эти пункты записаны в шестнадцатеричной системе и предварены “ U+” (просто для удобство, не значит ничего, кроме “Это пункт Unicode”). Символ Ḁ имеет пункт U+1E00. Иными(десятичными) словами, это 7680й символ таблицы Unicode. Он официально называется “ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА А С КОЛЬЦОМ СНИЗУ”.

Ниасилил

Суть вышесказанного: любой символ может быть закодирован множеством разных последовательностей бит, и любая последовательность бит может представлять разные символы, в зависимости от используемой кодировки. Причина в том, что разные кодировки используют разное число бит на символ и разные значения для кодирования разных символов.

bits encoding characters
11000100 01000010 Windows Latin 1 ÄB
11000100 01000010 Mac Roman ƒB
11000100 01000010 GB18030 腂
characters encoding bits
Føö Windows Latin 1 01000110 11111000 11110110
Føö Mac Roman 01000110 10111111 10011010
Føö UTF-8 01000110 11000011 10111000 11000011 10110110

Заблуждения, смущения и проблемы

Имея все вышесказанное, мы приходим к насущным проблемам, которые испытывают множество пользователей и разработчиков каждый день, как они соотносятся с указанным выше, и каковы пути решения. Сама большая проблема – это

Какого черта мой текст нечитаем?

ÉGÉìÉRÅ[ÉfÉBÉìÉOÇÕìÔÇµÇ≠Ç»Ç¢

Если вы откроете документ, и он выглядит так, как текст выше, то причина у этого одна: ваша программа ошиблась с кодировкой. И все. Документ не испорчен(по крайней мере, пока), и не нужно никакое волшебство. Вместо него надо просто выбрать правильную кодировку для отображения текста. Предполагаемый документ выше содержит биты:

10000011 01000111 10000011 10010011 10000011 01010010 10000001 01011011
10000011 01100110 10000011 01000010 10000011 10010011 10000011 01001111
10000010 11001101 10010011 11101111 10000010 10110101 10000010 10101101
10000010 11001000 10000010 10100010

Так, быстренько угадали кодировку? Если вы пожали плечами, то вы правы. Да кто знает?
Попробуем с ASCII. Большая часть этих байтов начинается с 1. Если вы правильно помните, ASCII вообще-то не использует этот бит. Так что ASCII не вариант.

Как насчет UTF-8? Большая часть байт не является валидными значениями в этой кодировке. Как насчет Mac Roman(еще одна европейская кодировка)? Хм, для нее эти байты являются правильными значениями. 10000011 декодируетися в ”É”, в “G” и так далее. Так что в Mac Roman текст будет выглядеть так: ÉGÉìÉRÅ[ÉfÉBÉìÉOÇÕìÔÇµÇ≠Ç»Ç¢. Правильно? Нет? Может быть? А компьютер-то откуда знает? Может кто-то хотел написать именно это. Насколько я знаю, это может быть последовательностью ДНК! Так и порешим: это Mac Roman, и это ДНК.

Конечно, это полный бред. Правильный ответ таков: текст закодирован в Japanes Shift-JIS и должен выглядеть как エンコーディングは難しくない. Кто бы мог подумать?
Первая причина нечитаемости текста в том, что кто-то пытается прочитать последовательность байт в неверной кодировке. Компьютеру всегда нужно подсказывать. Сам он не догадается. Некоторые типы документов определяют кодировку своего содержимого, но последовательность байт всегда остается черным ящиком.

Большинство браузеров предоставляют возможность указать кодировку страницы с помощью специального пункта меню.

Иные программы тоже имеют аналогичные пункты.

У автора нет разбиения на части, но статья и так длинна. Продолжение будет через пару дней.

перевод на английский, синонимы, антонимы, примеры предложений, значение, словосочетания

Текст в кодировке , отличной от Юникод (например, на китайском или японском языке), искажается в Skype для бизнеса [ИСПРАВЛЕНО]	Non — unicode text (such as Chinese or Japanese languages) in Skype for Business shows up as garbled text [FIXED]
Общая для всех схем кодирования двоичных файлов в текст, Base64 предназначена для передачи данных, хранящихся в двоичных форматах по каналам, которые надежно поддерживают только текстовое содержимое.	Common to all binary — to — text encoding schemes, Base64 is designed to carry data stored in binary formats across channels that only reliably support text content.
В этом примере текст является типом, html-подтипом, а charset=UTF-8-необязательным параметром, указывающим кодировку символов.	In this example, text is the type, html is the subtype, and charset=UTF — 8 is an optional parameter indicating the character encoding .
При кодировании в base64 текст, четырех символов, как правило, преобразуется обратно в три байта.	When decoding Base64 text, four characters are typically converted back to three bytes.
Конвергентное шифрование, также известное как хэш-кодирование содержимого, представляет собой криптосистему, которая производит идентичный зашифрованный текст из идентичных текстовых файлов.	Convergent encryption, also known as content hash keying, is a cryptosystem that produces identical ciphertext from identical plaintext files.
Двоичный в текст кодировки , таких как uuencode и binhex, как правило, используется.	Binary — to — text encodings , such as uuencode and BinHex were typically used.
Они могут быть использованы для угадывания схемы кодирования текста, так как любой текст, содержащий их, по определению не является правильно закодированным текстом Юникода.	They can be used to guess a text’s encoding scheme, since any text containing these is by definition not a correctly encoded Unicode text.
Таким образом, размещение закодированной спецификации в начале текстового потока может указывать на то, что текст является Юникодом, и идентифицировать используемую схему кодирования .	Therefore, placing an encoded BOM at the start of a text stream can indicate that the text is Unicode and identify the encoding scheme used.
Двоичные данные и текст в любой другой кодировке , скорее всего, содержат последовательности байтов, которые недопустимы как UTF-8.	Binary data and text in any other encoding are likely to contain byte sequences that are invalid as UTF — 8.
Microsoft Word 2000 и более поздние версии — это приложения с поддержкой юникода, которые обрабатывают текст с помощью 16-разрядной схемы кодирования символов Юникода.	Microsoft Word 2000 and later versions are Unicode — enabled applications that handle text using the 16 — bit Unicode character encoding scheme.
Двоичное кодирование в текст — это кодирование данных в обычном тексте.	A binary — to — text encoding is encoding of data in plain text.
Методы кодирования двоичного кода в текст также используются в качестве механизма кодирования обычного текста.	Binary — to — text encoding methods are also used as a mechanism for encoding plain text.
В приведенной ниже таблице сравниваются наиболее часто используемые формы кодировки двоичного кода в текст.	The table below compares the most used forms of binary — to — text encodings .
Различные кодировки различаются в сопоставлении между последовательностями битов и символов и в том, как форматируется результирующий текст.	The different encodings differ in the mapping between sequences of bits and characters and in how the resulting text is formatted.
Обычный текст не содержит никакой другой информации о самом тексте, даже о используемой конвенции кодирования символов.	Plain text contains no other information about the text itself, not even the character encoding convention employed.
алгоритм кодирования , используемый для преобразования текста, отличного от US-ASCII, или двоичных данных в теле сообщения;	The encoding algorithm used to transform any non — US — ASCII text or binary data that exists in the message body.
Вы можете указывать параметры кодирования MIME или кодирования в виде обычного текста для определенных контактов в вашей папке Контакты.	You can control the MIME or plain text encoding options for specific contacts in your Contacts folder.
Инициатива кодирования текста использует элемент для кодирования любого нестандартного символа или глифа, включая gaiji.	The Text Encoding Initiative uses a element to encode any non — standard character or glyph, including gaiji.
Шестнадцатеричное используется в кодировке передачи Base16, в которой каждый байт открытого текста разбивается на два 4-битных значения и представляется двумя шестнадцатеричными цифрами.	Hexadecimal is used in the transfer encoding Base16, in which each byte of the plaintext is broken into two 4 — bit values and represented by two hexadecimal digits.
Стандарт Unicode для кодирования текста на компьютерах определяет 8 символов для карточных мастей в блоке разные символы, в U+2660-2667.	The Unicode standard for text encoding on computers defines 8 characters for card suits in the Miscellaneous Symbols block, at U+2660–2667.
Сервер WHOIS и/или клиент не могут определить действующую кодировку текста для запроса или содержимого базы данных.	A WHOIS server and/or client cannot determine the text encoding in effect for the query or the database content.
Подобные отступы использовались в течение многих десятилетий, как и в кодировании для компьютерного программирования, для визуального разделения разделов текста.	Similar indentation has been used for many decades, as in coding for computer programming, to visually separate sections of text.
Отступы в кодировке сноски могут помочь прояснить разделы текста, содержащие несколько сносок, как это обычно бывает в больших статьях.	Indenting the footnote coding can help clarify sections of text that contain several footnotes, as is typical in large articles.
Приведенное выше разбиение всего текста сноски на 4 строки позволяет кодировать ее как первую сноску страницы.	The above line — splitting of the entire footnote text, into 4 lines, allows it to be coded as the first footnote of a page.
Формат STEP-файла определяется в стандарте ISO 10303-21 кодировка открытого текста структуры Exchange.	The format of a STEP — File is defined in ISO 10303 — 21 Clear Text Encoding of the Exchange Structure.
Формы представления представлены только для обеспечения совместимости со старыми стандартами и в настоящее время не требуются для кодирования текста.	The presentation forms are present only for compatibility with older standards, and are not currently needed for coding text.
Наивное программное обеспечение для обработки текста может неверно предположить, что используется определенная кодировка , что приводит к mojibake.	Naive text processing software may improperly assume that a particular encoding is being used, resulting in mojibake.
Этот процесс называется двоичным кодированием текста.	This process is referred to as binary to text encoding .
NET использует кодировку base64 для безопасной передачи текста через HTTP POST, чтобы избежать столкновения разделителей.	NET uses base64 encoding to safely transmit text via HTTP POST, in order to avoid delimiter collision.
Ряд маленьких английских слов легче читать, запоминать и вводить, чем десятичные или другие двоичные системы кодирования текста.	A series of small English words is easier for humans to read, remember, and type in than decimal or other binary — to — text encoding systems.
Различия в наборах символов, используемых для кодирования , могут привести к тому, что текстовое сообщение, отправленное из одной страны в другую, станет нечитаемым.	Differences in the character sets used for coding can cause a text message sent from one country to another to become unreadable.
Если у файла другая кодировка , попробуйте открыть его в любом текстовом редакторе и снова сохранить файл с новым названием.	If it’s not encoded in UTF — 8, try opening the file in any text editor and saving it again under a new file name.
Если составное сообщение содержит части, включающие двоичные данные или текстовые знаки, отличные от знаков в кодировке US-ASCII, эти части должны быть закодированы с помощью алгоритма Quoted Printable или Base64.	If the multipart message contains other parts that have binary data, that part of the message must be encoded using the Quoted — printable or Base64 encoding algorithms.
Для любых текстовых вложений используется кодирование Quoted Printable или Base64.	Any message attachments are encoded by using Quoted — printable or Base64 encoding .
Если задано значение $true, то параметры кодирования текстовых сообщений для почтового контакта или почтового пользователя переопределяют соответствующие параметры в Outlook.	If the value $true, the plain text message encoding settings for the mail contact or mail user override the corresponding settings in Outlook.
В то время большинство профессиональных веб-авторов предпочитали кодировать HTML вручную с помощью текстовых редакторов, потому что они хотели получить полный контроль над исходным кодом.	At the time, most professional web authors preferred to code HTML by hand using text editors because they wanted full control over the source.
Многие веб-браузеры используют более ограниченную форму поиска контента, чтобы попытаться определить кодировку символов текстовых файлов, для которых тип MIME уже известен.	Numerous web browsers use a more limited form of content sniffing to attempt to determine the character encoding of text files for which the MIME type is already known.
Позже файлы конфигурации на основе XML стали популярным выбором для кодирования конфигурации в текстовых файлах.	Later XML — based configuration files became a popular choice for encoding configuration in text files.
UTF-8-это разреженная кодировка в том смысле, что большая часть возможных комбинаций байтов не приводит к правильному тексту UTF-8.	UTF — 8 is a sparse encoding in the sense that a large fraction of possible byte combinations do not result in valid UTF — 8 text.
Используя 3-канальное растровое изображение, текстурированное по всей модели,можно кодировать более подробную информацию о нормальном векторе.	By using a 3 — channel bitmapped image textured across the model, more detailed normal vector information can be encoded .
Мясо кур, баранина, говядина: в тексты стандартов были включены окончательные поправки с целью согласования нумерации и кодирования .	Chicken Meat, Ovine meat, bovine meat: Final corrections were made to the texts of the standards to harmonize numbering and coding.

Кодирование строк и R · R и C++

Опубликовано 21 февраля 2018 г.

Этот пост в блоге представляет собой попытку исследовать и ответить на удивительно сложный вопрос:

Как записать содержимое в кодировке UTF-8 в файл?

Предположим, что вы автор пакета, которому нужно обработать какой-то текст, предоставленный пользователем. Чтобы не усложнять себе жизнь, убедитесь, что все, что вы читаете и пишете, закодировано в кодировке UTF-8, поскольку эта кодировка может широко представлять символы почти всех языков. Ваша интуиция может заключаться в том, чтобы открыть соединение и написать в него, например следующее:

 write_utf8 <- function(text, f = tempfile()) {
  
  # убедитесь, что текст имеет формат UTF-8
  utf8 <- enc2utf8 (текст)
  
  # создаем соединение с кодировкой UTF-8
  con <- файл(f, открыть = "w+", кодировка = "UTF-8")
  writeLines (utf8, кон = кон)
  закрыть (против)
  
  # прочитать обратно из файла только для подтверждения
  # все выглядит так, как ожидалось
  readLines(f, кодировка = "UTF-8")
  
}

И может показаться, что это правильно на вашем компьютере.

 write_utf8("брюле")

 [1] "брюле"

К сожалению, пользователь Windows сообщает о проблеме при попытке написать японский символ «鬼»:

 > write_utf8 («鬼»)
[1] ""

Но вы просите своего японского друга проверить вашу функцию, и в его системе все выглядит нормально:

 > write_utf8("鬼")
[1] "鬼"

Но, что еще более странно, в системе вашего японского друга он получает странный вывод при попытке написать «брюле»:

 > write_utf8("брюле")
[1] "br璉馥"

Здесь явно что-то не так, но что ?

Кодирование строк

Прежде чем мы углубимся во внутренности R, нам следует обсудить кодировки. Я постараюсь представить ровно столько материала, чтобы мы могли понять, что такое кодирование и как компьютер понимает письменный язык, но я немного умолчу об истории. Если вы хотите узнать больше, см. «Что обязательно нужно знать каждому программисту о кодировках и наборах символов для работы с текстом».

Как компьютер хранит текст? Язык сложен. Компьютеры, наоборот, просты. У них есть байты. Последовательности нулей и единиц. Наш единственный выбор — выяснить, как перевести сложные элементы письменного языка в байты. Как мы это делаем?

Ответ на этот вопрос - кодирование. Кодирование используется для сопоставления частей языка с последовательностью байтов . Например, вы можете быть знакомы с кодировкой ASCII (американский стандартный код для обмена информацией). Это система кодирования английских символов, а также подмножество часто используемых символов. В этой системе буква «а» представлена последовательностью 9 байтов.0048 01100001 . Вы можете убедиться в этом с помощью pryr::bits() :

 pryr::bits('a')

 [1] "01100001"

Вместо последовательности байтов мы могли бы также сказать, что буква «а» отображается на то же целое число, представленное этой последовательностью байтов. Это число равно 97:

 pryr::bits(97L)

 [1] "00000000 00000000 00000000 01100001"

0003

 pryr::bits(0x61L)

 [1] "00000000 00000000 00000000 01100001"

Тем не менее, суть та же. Если нужно обрабатывать байты с использованием кодировки ASCII, это означает, что последовательность байтов 01100001 должна быть интерпретирована как английская буква «a», а буква «a» должна быть закодирована в системе как байт последовательность 01100001 . Для краткости мы можем обозначить эту последовательность байтов тем же целым числом, которое она представляет; 97 . Однако чаще эти числа представляются с использованием шестнадцатеричной записи, поэтому эта последовательность байтов будет представлена как 0x61 .

ASCII, однако, весьма ограничен как кодировка. Он не был предназначен для представления всей широты письменного языка; скорее, он был просто разработан для представления 128 часто используемых символов и символов английского языка. Что, если мы хотим представить неанглийские символы?

Вы можете себе представить, что одним из решений может быть определение разных кодировок для разных языков. Именно это и делается в Windows: японские пользователи могут установить японскую версию Windows, чтобы получить японскую локаль с символами, закодированными в японской кодировке; Китайские пользователи могут установить китайскую версию Windows, чтобы получить китайскую кодировку и так далее.

Однако эти системы столкнулись с препятствием — что, если вы хотите представить нескольких языков в одном и том же потоке байтов? Все рассмотренные до сих пор кодировки представляют собой системы для представления одного письменного языка; что, если мы хотим представить их всех?

Введите Юникод. Стандарт Unicode фактически представляет собой стандартизированную систему для кодирования всех письменных языков. Стандарт юникода был специально разработан для совместимости с ASCII — другими словами, в стандарте юникода буква «а» по-прежнему сопоставляется с кодовой точкой 9.7; или, что чаще представлено в стандарте Unicode, . Обратите внимание, что это просто шестнадцатеричное представление того же числа. В стандарте Unicode символ «û» сопоставляется с кодовой точкой ; символ «é» соответствует ; символ «鬼» соответствует и так далее. Чтобы представить символ «鬼» в системе, нам нужно написать последовательность байтов, которая представляет кодовую точку 9.0049 .

Однако юникод - это , а не кодировка. Это система однозначного сопоставления языковых конструкций с числами. Нам по-прежнему нужен способ представления стандарта юникода в реальной кодировке, то есть сопоставление символов, определенных в стандарте юникода, с последовательностью байтов. Несколько сбивает с толку тот факт, что существует нескольких способов кодирования символов Юникода. UTF-8 является одной из таких кодировок, но также существуют варианты, такие как UTF-16 и UTF-32. Обсуждение различий немного выходит за рамки этого поста в блоге, но, по сути, это просто разные способы сопоставления кодовых точек, указанных в Unicode, с последовательностями байтов. Просто бывают разные компромиссы между разными способами представления разных последовательностей. В настоящее время доминирует UTF-8, потому что его плюсы, как правило, перевешивают его минусы, но он не вездесущ.

Суть того, что я хочу проиллюстрировать, заключается в следующем:

Текст представлен на компьютерах последовательностями байтов;
Кодировка используется для сопоставления последовательности байтов с письменным языком, который она представляет;
Стандарт Unicode — это попытка преобразовать письменный язык в единую стандартизированную кодировку;
UTF-8 — наиболее распространенный способ кодирования символов Юникода, но не единственный.

Теперь у нас достаточно знаний, чтобы говорить о кодировках в R.

`Кодировка строки в R`

В R векторы символов имеют две части информации: последовательность байтов и кодировку, в которой эти байты должны интерпретироваться. Кодировку конкретной строки можно запросить с помощью функции Encoding() :

 Encoding('a')

 [1] "unknown"

В этом случае обычно сообщается о четырех кодировках:

latin1 : Также известный как ISO/IEC 8859-1, это особый вид «расширенного ASCII» кодирования;
UTF-8 : Система кодирования, используемая для представления текста, закодированного с использованием стандарта Unicode;
байт : связанный текст не имеет «настоящей» кодировки; то есть текст не может быть интерпретирован как письменный язык;
unknown : связанная кодировка «неизвестна», но предполагается, что она совпадает с кодировкой, связанной с активной локалью, то есть локалью, о которой сообщает Sys. getlocale() .

R использует библиотеку iconv для перевода текста между различными кодировками. Например:

 utf8 <- "\u00fb" # 'û'
latin1 <- iconv(utf8, to = "latin1")
paste(latin1, "(latin1):", pryr::bits(latin1))

 [1] "û (latin1): 11111011"

 paste(utf8, "(UTF-8):", pryr:: bits(utf8))

 [1] "û (UTF-8) : 11000011 10111011"

Надеюсь, это доказывает, что мы можем представить один и тот же символ с другой последовательностью байтов в разных кодировках.

Итак, что пошло не так в нашем вышеупомянутом примере? Мы пытались записать контент в соединение, открытое в кодировке UTF-8, но это, похоже, не сработало.

Подождите, что это на самом деле означает :

запись содержимого в соединение, открытое с кодировкой UTF-8

Наш контент уже закодирован в UTF-8, не так ли? так что мы действительно хотим просто записать наш текст байт за байтом в связанное соединение. Так почему же мы пытаемся указать кодировку для соединения?

Документация из ?writeLines поясняет это:

Обычно строки символов с отмеченными кодировками преобразуются в текущую кодировку перед передачей в соединение (которое может выполнить дальнейшее перекодирование)

Давайте немного распакуем это. В этой строке указано, что преобразование между кодировками потенциально происходит в двух местах:

. Во-первых, текст, который вы предоставили writeLines() , переведен на текущий или родной кодировка;
Далее этот текст отправляется соединению, которое пытается перевести его обратно в запрошенную кодировку (в нашем случае UTF-8 ).

Другими словами, пытаясь записать содержимое UTF-8 в файл, мы неосознанно прошли через системную кодировку! И, как вы можете себе представить, это не удастся, если вы попытаетесь написать символы, которые не могут быть представлены в системной кодировке пользователя — например, японские символы в английской локали.

Другими словами, мы на самом деле хотим сделать следующее:

Гарантировать, что контент закодирован в UTF-8;
Открыть соединение, которое также пропускает любую возможную трансляцию;
Попросите writeLines() пропустить любой возможный перевод.

Открытие соединения с кодировкой = "native.enc" делает возможным шаг 2, а вызов writeLines(..., useBytes = TRUE) делает возможным шаг 3. Давайте перепишем наш write_utf8() подпрограмма еще раз с учетом этого:

 write_utf8 <- function(text, f = tempfile()) {
  
  # шаг 1: убедитесь, что наш текст закодирован в utf8
  utf8 <- enc2utf8 (текст)
  
  # шаг 2: создайте соединение с "родной" кодировкой
  # это сигнализирует R о переводе перед записью
  # к соединению следует пропустить
  con <- файл (f, open = "w+", encoding = "native.enc")
  
  # шаг 3: пишем в соединение с 'useBytes = TRUE',
  # сообщаем R пропустить перевод в нативную кодировку
  writeLines(utf8, con = con, useBytes = TRUE)
  
  # закрываем наше соединение
  закрыть (против)
  
  # прочитать обратно из файла только для подтверждения
  # все выглядит так, как ожидалось
  readLines(f, кодировка = "UTF-8")
  
}

Как именно это работает? Аргумент useBytes функции writeLines() фактически означает «представить, что этот текст находится в родной кодировке, и не выполнять перевод». Затем, открывая соединение с использованием encoding = "native.enc" , соединение получает данные, которые предполагает, что находится в собственной кодировке, и мы запросили перевод в родную кодировку. Поскольку мы отправляем нативную кодировку и запрашиваем нативную кодировку, перевод не выполняется. R намекает на такое поведение в Кодирование раздела ?файла :

Кроме того, «» и «native.enc» означают «родную» кодировку, то есть внутреннюю кодировку текущей локали, поэтому перевод не выполняется.

Но, опять же для акцента, надо понимать, что перевод может происходить в двух местах:

Во-первых, большинство подпрограмм R для записи (например, writeLines() ) будут переводить текст в родную кодировку, если вы не попросите иначе;
Далее, большинство подключений R будут предполагать , что они получают текст в собственной кодировке, и поэтому будут преобразовываться в кодировку, связанную с подключением, когда это возможно.

То, что мы делаем, эффективно «обманывает» R, заставляя поверить, что он пишет текст в родной кодировке, и с помощью этого трюка R пропускает любой перевод текста, который мы отправляем в соединение.

Вы тестируете это на своем компьютере с Windows и, к вашему облегчению:

 > write_utf8 ("брюле")
[1] «брюле»
> write_utf8("鬼")
[1] "鬼"

К сожалению, ваш японский друг все еще сообщает о проблеме:

 > write_utf8("брюле")
[1] "br璉馥"

Вы решаете нырнуть и посмотреть. Вооружившись знаниями о кодировках, вы решаете посмотреть, что R считает кодировкой для «брюле». Вот что вы видите в RStudio:

 > Sys.setlocale(locale = "English")
[1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> Кодировка("брюле")
[1] "латиница1"
> charToRaw("брюле")
[1] 62 72 сб 6в е965
> Sys.setlocale(locale = "японский")
[1] "LC_COLLATE=Japanese_Japan. 932;LC_CTYPE=Japanese_Japan.932;LC_MONETARY=Japanese_Japan.932;LC_NUMERIC=C;LC_TIME=Japanese_Japan.932"
> Кодировка("брюле")
[1] «неизвестно»
> charToRaw("брюле")
[1] 62 72 сб 6в е9 65

Интересно — по какой-то причине R выбирает неправильную кодировку для строкового литерала «brûlée» в японской локали. К сожалению, я не до конца понимаю механизм, с помощью которого R угадывает кодировку строки. Но, по крайней мере, теперь мы знаем, что «здесь будут драконы», когда дело доходит до кодирования строковых литералов R.

К счастью, этого можно вообще избежать, явно используя кодовые точки Юникода в строковом литерале:

 > text <- "br\u00Fbl\u00e9e"
> текст
[1] «брюле»
> Кодировка (текст)
[1] «УТФ-8»

Есть еще одна вещь, на которую нам нужно обратить внимание. Обычно запись в файлы выполняется по имени, а не путем явного открытия и закрытия соединения. Например:

 writeLines(text, file = "results/output.txt")

Незаметно R создаст для вас подключение к файлу, используя файл() функция. Посмотрим на его сигнатуру:

 файл

 функция (описание = "", open = "", blocking = TRUE, encoding = getOption("encoding"),
    необработанный = FALSE, метод = getOption ("url.method", "по умолчанию"))
{
    .Internal(файл(описание, открытие, блокировка, кодировка, метод,
        сырой))
}
<байт-код: 0x7ffbd4067c98>

Это соединение с файлом открывается с кодировкой . Эта кодировка предоставляется encoding option:

 getOption("encoding")

 [1] "native.enc"

Теперь значением по умолчанию для этой кодировки является native.enc , но вполне возможно, что пользователи изменили это вариант. Однако при написании контента вы хотите убедиться, что вы пишете в соединение, открытое с кодировкой = "native.enc" . С этой целью вам следует избегать записи в файлы по имени, а вместо этого явно открывать и закрывать соединение самостоятельно .

`Сводка`

Кодировки — это спецификация для перевода письменного языка в последовательности байтов, которые могут быть обработаны и поняты компьютером.
По умолчанию при попытке записи в соединение R будет переводить ваши строки через системную кодировку. Этот перевод может завершиться ошибкой, если вы попытаетесь записать содержимое UTF-8, которое не может быть представлено в системной кодировке.
Это преобразование можно подавить с помощью аргумента useBytes = TRUE для writeLines() и обеспечения открытия соединений с использованием encoding = "native.enc" .
Поскольку кодировку, используемую соединениями, можно настроить с помощью параметра R encoding , важно явно открывать и закрывать соединения с кодировкой native.enc .
Сценарии Portable R должны использовать кодовые точки Unicode, чтобы избежать случайного неправильного кодирования строковых литералов.

`Дополнительная информация`

«Что абсолютно необходимо знать каждому программисту о кодировках и наборах символов для работы с текстом» “. http://kunststube.net/encoding/
«Абсолютный минимум, который каждый разработчик программного обеспечения обязательно должен знать о Unicode и наборах символов (без оправданий!)». https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

Включите JavaScript для просмотра комментариев с помощью Disqus. Многоязычная поддержка Unicode

`Многоязычная поддержка Unicode`

Photon предназначен для обработки международных символов. Следуя стандарту Unicode (ISO/IEC 10646), Photon позволяет создавать приложения, которые могут легко поддерживать основные языки и письменности мира.

Unicode основан на наборе символов ASCII, но использует 16-битная кодировка для поддержки полного многоязычного текста. есть нет необходимости в управляющих последовательностях или управляющих кодах, когда указание любого символа на любом языке. Обратите внимание, что Юникод кодировка удобно обрабатывает все символы - будь то алфавит, идеограммы или символы - в точности так же.

Photon поддерживает другие кодировки набора символов и предоставляет библиотеку функции для перевода в Unicode и обратно. язык ФАБ поддержка базы данных позволяет легко изменить язык в вашем приложении. Также доступны дополнительные продукты для поддержки шрифтов и ввода для языков. например японский.

В эту главу входят:

Кодировка UTF-8
Файлы перевода набора символов
Клавиатурные столики
Многоязычные приложения PhAB

Ранее известная как UTF-2, UTF-8 (для «8-разрядных form") формат преобразования предназначен для решения использование символьных данных Unicode в 8-битных средах UNIX.

Вот некоторые из основных особенностей UTF-8:

Библиотека перевода набора символов Photon предназначена для подпрограммы поддержки для преобразования в и из собственного Unicode/ Набор символов UTF-8.

Файл конфигурации /usr/photon/translations/charsets детализирует наборы символов, для которых установлена поддержка преобразования. Каждая запись в этом файле описывает целевой набор символов, указывая:

стандартное имя для этого перевода
список допустимых псевдонимов для этого перевода
текстовое описание
метод перевода
уникальный код идентификатора (код перечисления MIB)
файл данных, содержащий данные таблицы перевода.

Вот пример записи для ISO 8859-1:

[ИСО_8859-1:1987]
МИБенум = 4
Псевдоним = iso-ir-100,ISO_8859-1,ISO-8859-1,latin1,csISOLatin1
Метод = 8 бит
Таблица = 8859-1.таб
Описание = Western (Latin-1)

Новые записи могут быть добавлены в файл по мере необходимости при условии, что поддержка кода для соответствующего метода. Новые записи для существующего метода потребуется новый файл данных перевода. Допустимые методы перевода:

7 бит: Простой поиск таблицы с доменом 0x00 — 0x7F; файл данных представляет собой (двоичную) таблицу из 128 широкосимвольных кодов.
8 бит: Простой поиск таблицы с доменом 0x00 — 0xFF; файл данных представляет собой (двоичную) таблицу из 256 широкосимвольных кодов.
: Shift-JIS (8-битная); файл данных представляет собой широкосимвольную сетку 94x94.
ес: Кодировка с расширенным кодом unix (8-битная); файл данных 94x94 сетка с широкими символами.
внутренний: UTF-8; внешние ресурсы не требуются.

Photon поставляется с набором стандартных переводов для общих наборы символов, включая алфавиты ISO 8859, многие DOS/IBM/Windows кодовые страницы и ряд японских кодировок (SJIS и EUC).

Photon поставляется с многочисленными таблицами клавиатуры (см. /usr/фотон/клавиатура). По умолчанию Photon предполагает, что вы используя 101-клавишную клавиатуру США. Если вы хотите использовать другой клавиатуры укажите имя соответствующей таблицы клавиатуры с помощью KBD переменная среды.

Например, добавив следующую строку в ваш сисинит. узел файл выбирает немецкий клавиатура:

экспорт KBD=de_DE_102.kbd

Вы можете создавать пользовательские таблицы клавиатуры для языковых файлов, которые не поставляются.

Двоичные файлы клавиатуры (*.kbd) хранятся в Каталог /etc/config/kbd. Эти файлы содержат определения возможностей, связанные с одним типом клавиатуры. соответствующие исходные определения для всех клавиатур, поддерживаемых Photon типы называются файлами определения клавиатуры (*.kdef). Они есть содержится в /usr/photon/keyboard.

Чтобы просмотреть или изменить информацию на существующей клавиатуре (*.kbd), необходимо сначала преобразовать его в текст (*.kdef) с помощью утилиты kbcvt. Чтобы использовать измененный файл определения клавиатуры, вы должны скомпилировать его с помощью mkkbd и поместите результат в /etc/config/kbd.

Чтобы создать совершенно новую таблицу клавиатуры, начните с клавиатуры файл определения (*. kdef), обладающий большинством возможностей, которые вы требовать. Сделайте его копию, отредактируйте копию с помощью любого текстового редактора, скомпилируйте его с помощью mkkbd и поместите результат в /etc/config/kbd.

Файл sample.kdef в Каталог /usr/photon/keyboard содержит комментарии описание синтаксиса определения клавиатуры.

Утилита mkkbd оптимизирует размер вашей клавиатуры определения путем удаления неиспользуемых типов клавиш, символов и компоновки последовательности. Неиспользуемый тип ключа — это тот, у которого нет ключей. присвоено ему. Неиспользованная последовательность компоновки — это та, которая не может быть набирается на клавиатуре. Неиспользованный символ — это запись в символе таблица ключевого типа, на который никогда не ссылаются. Вот пример:

Тип ключа "MyKeyType" {
    Немодифицированный Sym # 1
     Сим №3
    }

Каждый ключ, принадлежащий типу MyKeyType, должен указывать три символы, но символ 2 никогда не будет использоваться. В таком случае, mkkbd удаляет неиспользуемые символы из определений клавиш и соответствующим образом настраивает тип ключа.

`Создание таблицы клавиатуры из текстового файла`

Утилита mkkbd компилирует текстовый файл, содержащий клавиатуру определения (*.kdef) и может создавать файл двоичной таблицы клавиатуры (*.kbd) из каждого определение.

Входной файл берется из стандартного ввода ( stdin ) или файл, указанный вами с помощью параметра -i . Если вход определяет несколько клавиатур, вы можете выбрать те, которые будут преобразуются в двоичные путем сопоставления имен клавиатур с одним или несколькими узоры персонажей.

Всегда используйте одинарные или двойные кавычки при указании шаблона имени (например, "fr_*"), чтобы избежать расширения оболочки.

Если указать каталог для выходных файлов (с0448 -д или опция -k ), бинарные файлы будут названы в соответствии с имена, указанные в текстовом файле. Безымянные клавиатуры не преобразован. Если вы не укажете каталог, первая клавиатура, которая соответствует заданному шаблону, преобразуется, и выходной двоичный файл записывается в стандартный вывод ( stdout ). В этом случае мы рекомендуется перенаправить вывод в файл.

Безымянная клавиатура считается соответствующей шаблону, только если вы не указать любые шаблоны - таким образом, можно преобразовать безымянную клавиатуру в двоичную, только если это первая клавиатура, определенная в вашем файл.

Утилита mkkbd сообщит вам о синтаксических ошибках и некоторые конфликты в вашем определении клавиатуры.

`Преобразование таблицы клавиатуры в текстовый файл`

Утилита kbcvt преобразует одну или несколько двоичных клавиатур таблицы (*.kbd) в текст. Если бинарный файл вы хотите convert находится в каталоге /etc/config/kbd и имеет .kbd, вам не нужно указывать имя файла расширение в командной строке. Выходной текст записывается по стандарту вывод ( стандартный вывод ).

Клавиатурные таблицы названы в соответствии со следующими соглашение:

la _ CO _ номер .kbd

где:

ла: Двухбуквенный код языка, например de для Deutsch, en для английского языка, fr для французского языка, и так далее.
СО: Международный двухбуквенный код для страны, например CA для Канады, ГБ для Великобритании, и US для США.
номер: Количество клавиш на клавиатуре - обычно 101 или 102.

Доступные таблицы:

Язык	Стол
Бельгийский французский	fr_BE_102.kbd
Канадский английский	en_CA_101.kbd
Канадский французский	fr_CA_102.kbd
Датский	da_DK_102. kbd
Голландский	nl_NL_102.kbd
Французский	fr_FR_102.kbd
немецкий	de_DE_102.kbd
Итальянский	it_IT_102.kbd
Японский	ja_JP_106.kbd
Норвежский	no_NO_102.kbd
польский	pl_PL_102.kbd
Португальский	pt_PT_102.kbd
Швейцарский французский	fr_CH_102.kbd
Швейцарский немецкий	de_CH_102.kbd
Испанский	es_ES_102.kbd
Шведский	se_SE_102. kbd
Английский (Великобритания)	en_GB_102.kbd
Английский (США)	en_US_101.kbd

Предположим, вам нужно включить символ, которого нет в стандартная таблица ASCII, например è. Вы можете сделать это, используя 9«А» Клавиши Sym [Acircumflex] [combining_circumflex] «A»

Название символа состоит из буквы и ударения или диакритический знак. Например, Agrave — это заглавная буква A. с серьезным ударением, а agrave - это маленькое a с серьезный акцент.

В нашем примере мы хотим вставить символ è. Итак, нам нужно найти последовательность компоновки, называемую egrave, в файл compose.inc:

Sym [egrave] Ключи [combining_grave] 'e'
Sym [egrave] Ключи '`' 'e'

Есть два способа получить этого персонажа. Первая запись может быть интерпретируется как:

Если на вашей клавиатуре есть клавиша Combine_grave (на стандартных клавиатурах нет) и ключ e , вы можете составить è, нажав Alt (или любую другую клавишу). определяется как клавиша «Создать»), за которой следует ключ Combine_grave, за которым следует e .
Если на вашей клавиатуре мертвая клавиша Combine_grave (клавиша, которая не производит символ при нажатии сама по себе) и клавиша e , вы можете составить символ è, нажав мертвую ключ Combine_grave, за которым следует и .

Вторая запись может быть интерпретирована как:

Если на вашей клавиатуре есть клавиша ` и e , вы можете составить символ è, нажав Alt (или любая другая клавиша, определенная как клавиша «Создать»), за которой следует клавиша ` , затем e .
Если на вашей клавиатуре неработающая клавиша ` и e ключ, вы можете составить символ è нажав мертвую `Ключ , за которым следует e .

Приложения PhAB можно настроить для работы на языке, отличном от Английский. Используя соответствующий файл перевода (если таковой имеется для вашей системы; см.

Штирлиц — Сеть печатных салонов в Перми