С работа с кодировками: Использование классов кодировки символов в .NET
Учим русский | Глава 2. Основные принципы работы с Dreamweaver | Статьи | Программирование Realcoding.Net
Выберем в списке вкладок пункт New Document. Итак, что же здесь изображено? Но прежде чем начать
разговор о русификации Dreamweaver, немного поговорим об особенностях
национального Web-творчества. А именно о кодировках русского языка и борьбе с
ними.
Вероятно, вы знаете, что каждый символ, который может быть введен с клавиатуры и
отображен на экране, имеет уникальный номер, называемый кодом символа.
Совокупность таких кодов вместе с описанием, какой код какому символу
соответствует, образует кодировку. Каждая кодировка имеет свое наименование,
например 1251 или КОИ-8.
Поскольку любой язык использует свой набор символов, для каждого языка
кодировки, как правило, различны. (Исключение — некоторые западноевропейские
языки.) Но на этом путаница с кодировками не кончается. Дело в том, что разные
операционные системы используют различные кодировки. Например,
западноевропейская версия Windows использует кодировку 1250, русская — 1251,
американская версия MS-DOS— 437, а русская -866 (она же ISO-8859-5). Ну,
американская с западноевропейской — бог с ними, обойдемся без иноземцев! Однако
русских кодировок, как видите, уже две. А если добавить сюда еще кодировку,
используемую русской версией операционной системы UNIX — КОИ-8, и русской
версией компьютеров Macintosh — MacCyrillic, кодировок станет уже четыре. И это
только главные, на памяти автора существовали еще штуки четыре менее
распространенных кириллических кодировок («основная» кодировка ГОСТ,
«болгарская», «американская», «югославская» и еще какие-то). Кроме того, в
последнее время появилась кодировка Unicode, поддерживающая ВСЕ имеющиеся на
Земле языки. Настоящая тирания кодировок!..
Чем
все это грозит? А вот чем. Вы, наверно, пытались открыть текстовый документ,
созданный в Блокноте, в Norton Commander. Видели, что при этом получается —
текст абсолютно нечитаем. А все потому, что русские кодировки 866 (MS-DOS) и
1251 (Windows) не совпадают! В них одному и тому же символу присвоены разные
коды!!!
Каков же выход?
Выхода нет. Можно надеяться только на то, что какая-то из кодировок станет
стандартом и постепенно вытеснит конкурентов. Пока что на роль такого
(негласного) стандарта претендует 1251, хотя интернетчики старого поколения,
пользующиеся UNIX-совместимыми системами, «пропихивают» КОИ-8. Во всяком случае,
сейчас большинство Web-страниц, имеющихся в русском сегменте Сети, написано в
кодировке 1251.
Здесь стоит упомянуть еще два момента. Современные программы Web-обозревателей
поддерживают все доступные сейчас кодировки и корректно их распознают. Это
первое. Второе: Web-сервер (точнее, его администратор) может потребовать, чтобы
публикуемые вами странички были закодированы в какой-либо конкретной кодировке,
например в КОИ-8. Это стоит иметь в виду, когда вы будете выбирать кодировку для
своего Web-творения.
Когда вы создаете в Dreamweaver Web-страницу, используемая в ней кодировка
прописывается в ее заголовке с помощью особого тега <МЕТА>. Например, так:
<МЕТА HTTP-EQUIV=»Content-Type» CONTENT=»text/html; charset=windows-1251″></HEAD>
Как
вы поняли, эта страница создана с использованием кодировки Windows, т. е. 1251.
Подробнее о теге <МЕТА> мы поговорим далее в этой книге.
Итак, какие же кодировки поддерживает Dreamweaver? (Имеются в виду, конечно же,
русские кодировки.) Все они перечислены в табл. 2.4 и задаются с помощью
раскрывающегося списка Default Encoding.
Таблица 2.4. Кодировки русского текста, поддерживаемые Dreamweaver
| | ||
ISO-8859-5 КОИ8 (KOI-8R) MacCyrillic Windows-1251 | Русская версия MS-DOS | ||
Western (Latin1) | Это | ||
Какую же кодировку выбрать? Ответ прост. Если вы не связаны какими-либо
специфическими требованиями администратора Web-сервера, на котором будет
опубликован ваш сайт, смело выбирайте пункт Windows-1251. В противном
случае выберите ту кодировку, которую требует сервер. Если вы создаете странички
на английском языке, ваш выбор — Western (Latinl).
Теперь переключитесь на вкладку Fonts. На этой вкладке вы сможете
настроить шрифты, которыми будет отображаться текст вашей страницы. В списке
Font Settings выберите шрифтовой набор, который будет использован для
отображения ваших Web-страниц. Здесь альтернатива еще проще: если текст русский
— выбирайте Cyrillic, если английский — Western (Latinl).
Что
касается начертаний и размеров шрифтов, используемых для отображения текста,
автор может только посоветовать, но никак не порекомендовать. Автор предпочитает
в качестве пропорционального шрифта (раскрывающийся список Proportional Font)
Arial, в качестве моноширинного (Fixed Font) — Lucida Console, а для
отображения исходного HTML-кода в редакторе кода (Code Inspector) — тоже
Lucida Console. Размеры шрифтов (раскрывающийся список Size) автор обычно ставит
равным 10 пунктам (малый размер, Small). Но, еще раз повторим, что это
дело вкуса.
А
теперь еще одна важная деталь. К сожалению, все программы имеют ошибки, даже
самые лучшие из них. Dreamweaver в этом случае не исключение. Из-за ошибки он
некорректно открывает Web-страницы, в которых не прописана с помощью тега <МЕТА>
используемая в них кодировка. Для того чтобы вразумить его, нам придется сделать
следующее.
Прежде всего, закройте Dreamweaver. Далее откройте в Проводнике или в другом
диспетчере файлов папку, в которой у вас установлен Dreamweaver. Обычно это
папка Program Files/Macromedia/Dreamweaver MX. В ней вы увидите папку
Configuration. Откройте в ней подпапку Encodings. В этой подпапке находится файл
EncodingMenu.xml. В этом файле перечислены все поддерживаемые Dreamweaver
кодировки.
Ниже
приведен фрагмент этого файла, в котором перечисляются русские кодировки,
интересующие нас:
<mm:encoding
name=»Cyrillic (ISO-8859-5)» charset=»iso-8859-5″
fontgroup=»Cyrillic» winfontcharset=204 macfontscript=7
filename=»iso88595.xml»/>
<mm:encoding
name=»Cyrillic (KOI8-R)» charset=»KOI8-R»
fontgroup=»Cyrillic» winfontcharset=204 macfontscript=7
filename=»KOI8R.xml»/>
<mm:encoding name=»Cyrillic (MacCyrillic)» charset=»x-mac-cyrillic»
fontgroup=»Cyrillic» winfontcharset=204 macfontscript=7
filename=»MacCyrillic.xml»/>
<mm:encoding
name=»Cyrillic (Windows-1251)» charset=»windows-1251″
fontgroup=»Cyrillic» winfontcharset=204 macfontscript=7
filename=»Win1251.xml»/>
Кстати, данные в этом файле записаны в формате XML. Dreamweaver понимает этот
формат и очень часто использует его для сохранения конфигурационных данных.
Дело
в том, что из-за ошибки Dreamweaver использует для представления текста страниц
с непрописанной кодировкой ту, которая встретится ему первой. В данном случае
это кодировка MS-DOS — ISO-8859-5. Нам нужно поместить на первое место кодировку
1251. Для этого исправьте файл EncodingMenu.xml так:
<mm:encoding name=»Cyrillic (Windows-1251)» charset=»windows-1251″
fontgroup=»Cyrillic» winfontcharset=204 macfontscript=7
filename=»Winl251.xml»/>
<mm:encoding name=»Cyrillic (ISO-8859-5)» charset=»iso-8859-5″
fontgroup=»Cyrillic» winfontcharset=204 macfontscript=7
filename=»iso88595.xml»/>
<mm:encoding
name=»Cyrillic (KOI8-R)» charset=»KOI8-R»
fontgroup=»Cyrillic» winfontcharset=204 macfontscript=7
filename=»KOI8R.xml»/>
<mm:encoding
name=»Cyrillic (MacCyrillic)» charset=»x-mac-cyrillic»
fontgroup=»Cyrillic» winfontcharset=204 macfontscript=7
filename=»MacCyrillic.xml»/>
После этого сохраните этот файл и закройте его. Теперь можете запускать
Dreamweaver — он станет корректно открывать все Web-страницы.
ABAP Blog | Работа с кодировками
SAP предоставляет разработчикам возможность преобразовывать наборы символов из одной кодовой страницы в другую, из внутреннего представления SAP системы в необходимую кодировку. Кодовая страница представлена четырехзначным номером. Для того чтобы получить описание по номеру кодовой страницы можно воспользоваться ФМ: SCP_CODEPAGE_BY_EXTERNAL_NAME или посмотреть содержимое таблицы TCP00A. Для того чтобы получить кодовую страницу используемую на сервере приложений в настоящий момент, можно воспользоваться статическим методом GET_APPSERVER_CODEPAGE из класса CL_ABAP_CONV_UC_NUMBER.
Примеры кодовых страниц:
Кодовая страница | Текстовое описание |
124 | IBM EBCDIC 00697/00297 |
1100 | iso-8859-1 |
1105 | US-ASCII (7 bits) |
1160 | windows-1252 |
4102 | utf-16be |
4103 | utf-16le |
4110 | utf-8 |
8000 | Shift-JIS |
8300 | BIG5 |
Проблемы, связанные с перекодированием:
- Конвертация не всегда возможна, т.к. символы из исходной кодировки могут не существовать в той, в которую преобразуем.
- Последовательность байтов в исходной кодировке не опознана. Проблема может быть связана с некорректным определением номера исходной кодировки.
Для преобразования в ABAP создан набор классов CL_ABAP_CONV* :
- CL_ABAP_CONV_OBJ – универсальный класс для перекодирования
- CL_ABAP_CONV_IN_CE – преобразование набора символов во внутреннее представление системы
- CL_ABAP_CONV_OUT_CE – преобразование из внутреннего представления системы в указанную кодировку
- CL_ABAP_CONV_X2X_CE – преобразование набора символов из одной кодировки в другую
- CL_ABAP_CONV_UC_NUMBER – преобразование набора символов в формат UNICODE в байтовом представлении.
REPORT zccc_api.
DATA: go_conv_in TYPE REF TO cl_abap_conv_in_ce,
go_conv_out TYPE REF TO cl_abap_conv_out_ce,
go_conv_obj TYPE REF TO cl_abap_conv_obj,
gv_buffer(4) TYPE X,
gv_text(100) TYPE C.
gv_buffer = ‘41424332’. » Набор байтов в UTF-8 означает ABC2
go_conv_in = cl_abap_conv_in_ce=>create(
ENCODING = ‘UTF-8’ » Кодировка из которой будем преобразовывать
).
go_conv_in->convert( EXPORTING INPUT = gv_buffer IMPORTING DATA = gv_text ).
WRITE: / gv_text. CLEAR gv_buffer.
go_conv_out = cl_abap_conv_out_ce=>create(
ENCODING = ‘UTF-8’ » Кодировка в которую будем преобразовывать
).
go_conv_out->convert( EXPORTING DATA = gv_text IMPORTING buffer = gv_buffer ).
WRITE: / gv_buffer. CLEAR gv_text.
CREATE OBJECT go_conv_obj
EXPORTING
incode = 4110 » UTF-8
outcode = 1500. » System
CHECK go_conv_out IS BOUND.
go_conv_obj->convert(
EXPORTING
inbuff = gv_buffer outbufflg = 0
IMPORTING outbuff = gv_text ).
WRITE: / gv_text.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
| REPORT zccc_api.
DATA: go_conv_in TYPE REF TO cl_abap_conv_in_ce, go_conv_out TYPE REF TO cl_abap_conv_out_ce, go_conv_obj TYPE REF TO cl_abap_conv_obj, gv_buffer(4) TYPE X, gv_text(100) TYPE C.
gv_buffer = ‘41424332’. » Набор байтов в UTF-8 означает ABC2
go_conv_in = cl_abap_conv_in_ce=>create( ENCODING = ‘UTF-8’ » Кодировка из которой будем преобразовывать ). go_conv_in->convert( EXPORTING INPUT = gv_buffer IMPORTING DATA = gv_text ).
WRITE: / gv_text. CLEAR gv_buffer.
go_conv_out = cl_abap_conv_out_ce=>create( ENCODING = ‘UTF-8’ » Кодировка в которую будем преобразовывать ).
go_conv_out->convert( EXPORTING DATA = gv_text IMPORTING buffer = gv_buffer ).
WRITE: / gv_buffer. CLEAR gv_text.
CREATE OBJECT go_conv_obj EXPORTING incode = 4110 » UTF-8 outcode = 1500. » System
CHECK go_conv_out IS BOUND.
go_conv_obj->convert( EXPORTING inbuff = gv_buffer outbufflg = 0 IMPORTING outbuff = gv_text ).
WRITE: / gv_text. |
Ссылка на SAP Wiki по теме.
Как настроить кодировку сайта самостоятельно
Как кодировка влияет на отображение сайта, чем отличается UTF-8 от Windows 1251 и где указать кодировку.
Разбираем, на что влияет кодировка, нужно ли указывать ее самостоятельно, и почему могут появиться так называемые «кракозябры» на сайте.
Зачем нужна кодировка
Кодировка (Charset) — способ отображения кода на экране, соответствие набора символов набору числовых значений. О ней сообщает строка Content-Type и сервер в header запросе.
Несовпадение кодировок сервера и страницы будет причиной появления ошибок. Если они не совпадают, информация декодируется некорректно, так что контент на сайте будет отображаться в виде набора бессвязных букв, иероглифов и символов, в народе называемых «кракозябрами». Такой текст прочитать невозможно, так что пользователь просто уйдет с сайта и найдет другой ресурс. Или останется, если ему не очень важно содержание:
Студентка списывала реферат с формулами, а на сайте слетела кодировка. Реальная история
Google рекомендует всегда указывать сведения о кодировке, чтобы текст точно корректно отображался в браузере пользователя.
Кодировка влияет на SEO?
Разберемся, как кодировка на сайте влияет на индексацию в Яндекс и Google.
Яндекс четко заявляет:
«Тип используемой на сайте кодировки не влияет на индексирование сайта. Если ваш сервер не передает в заголовке кодировку, робот Яндекса также определит ее самостоятельно».
Позиция Google такая же. Поисковики не рассматривают Charset как фактор ранжирования или сигнал для индексирования, тем не менее, она косвенно влияет на трафик и позиции.
Если кодировка сервера не совпадает с той, что указана на сайте, пользователи увидят нечитабельные символы вместо контента. На таком сайте сложно что-либо понять, так что скорее всего пользователи сбегут, а на сайте будут расти отказы.
Пример страницы со слетевшей кодировкой
Поэтому она важна для SEO, хоть и влияет на него косвенно через поведенческие. Пользователи должны видеть читабельный текст на человеческом языке, чтобы работать с сайтом.
Виды кодировок
Существует довольно много видов, но сейчас распространены два:
UTF-8
Unicode Transformation Format — универсальный стандарт кодирования, который работает с символами почти всех языков мира. Символы могут занимать от 1 до 4 байт, такое кодирование позволяет создавать мультиязычные сайты.
Есть несколько вариантов — UTF-8, 16, 32, но чаще используют восьмибитное.
Windows-1251
Этот вид занимает второе место по популярности после UTF-8. Windows-1251 — кодирование для кириллицы, созданное на базе кодировок, использовавшихся в русификаторах операционной системы Windows. В ней есть все символы, которые используются в русской типографике, кроме значка ударения. Символы занимают 1 байт.
Выбор кодировки остается на усмотрение веб-мастера, но UTF-8 используют намного чаще — ее поддерживают все популярные браузеры и распознают поисковики, а еще ее удобнее использовать для сайтов на разных языках.
Определить кодировку страницы своего или чужого сайта можно через исходный код страницы. Откройте страницу сайта, выберите «Просмотр кода страницы» (сочетание горячих клавиш Ctrl+U» в Google Chrome) и найдите упоминание «charset» внутри тега head.
На странице сайта используется кодировка UTF-8:
Указание кодировки в коде страницы
Узнать вид кодирования можно с помощью «Анализа сайта». Сервис проверяет в том числе и техническую сторону ресурса: анализирует серверную информацию, определяет кодировку, проверяет редиректы и другие пункты.
Фрагмент анализа серверной информации сайта
С помощью этого же сервиса можно проверить корректность указанного кодирования. Аудит внутренних страниц «Анализа сайта» проверяет кодировку сервера и сравнивает ее с той, которая указана на внутренней странице. Найденные ошибки Анализ покажет в результатах проверки, и вы сразу узнаете, где нужно исправить.
Отчет о технических данных
Кодировка сервера и страницы
Проверить кодировку еще можно через сервис Validator.w3, о котором писали в статье о проверке валидации кода. Нужная надпись находится внизу страницы.
Кодировка сайта в валидаторе
Если валидатор не обнаружит Charset, он покажет ошибку:
Ошибка указания кодировки
Но валидатор работает не точно: он проверяет только синтаксис разметки, поэтому может не показать ошибку, даже если кодирование указано неправильно.
Если кодировка не отображается
Если вы зашли на чужой сайт с абракадаброй, а вам все равно очень интересно почитать контент, то в Справке Google объясняют, как исправить кодирование текста через браузер.
О проблеме возникновения абракадабры на вашем сайте будут сигнализировать метрики поведения: вырастут отказы, уменьшится глубина просмотров. Но скорее всего вы и раньше заметите, что что-то пошло не так.
Главное правило — для всех файлов, скриптов, баз данных сайта и сервера должна быть указана одна кодировка. Ошибка может возникнуть, если вы случайно указали на сайте разные виды кодировки.
Яндекс советует использовать одинаковую кодировку для страниц и кириллических адресов структуры. К примеру, если робот встретит ссылку href=»/корзина» на странице с кодировкой UTF-8, он сохранит ее в этом же UTF-8, так что страница должна быть доступна по адресу «/%D0%BA%D0%BE%D1%80%D0%B7%D0%B8%D0%BD%D0%B0».
Где указать кодировку сайта
Если проблема возникла на вашем сайте, способ исправления зависит от вида сайта. Для одностраничника достаточно указать кодировку в мета-теге страницы, а для большого сайта есть разные варианты:
- кодировка в мета-теге;
- кодировка в .htaccess;
- кодировка документа;
- кодировка в базе данных MySQL.
Кодировка в мета-теге
Добавьте указание кодировки в head файла шаблона сайта.
При создании документа HTML укажите тег meta в начале в блоке head. Некоторые браузеры могут не распознать указание кодировки, если оно будет ниже.
Мета-тег может выглядеть так:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
или так:
<meta charset="utf-8">
В HTML5 они эквивалентны.
Тег кодировки в HTML
В темах WordPress обычно тег «charset» с кодировкой указан по умолчанию, но лучше проверить.
Кодировка в файле httpd.conf
Инструкции для сервера находятся в файле httpd.conf, обычно его можно найти на пути «/usr/local/apache/conf/».
Если вам нужно сменить кодировку Windows-1251 на UTF-8, замените строчку «AddDefaultCharset windows-1251» на «AddDefaultCharset utf-8».
Осторожнее: если вы измените в файле кодировку по умолчанию, то она изменится для всех проектов на этом сервере.
Убедитесь, что сервер не передает HTTP-заголовки с конфликтующими кодировками.
Кодировка в .htaccess
Добавьте кодировку в файл .htaccess:
- Откройте панель управления хостингом.
- Перейдите в корневую папку сайта.
- В файле .htaccess добавьте в самое начало код:
- для указания кодировки UTF-8 — AddDefaultCharset UTF-8;
- для указания кодировки Windows-1251 — AddDefaultCharset WINDOWS-1251.
- Перейдите на сайт и очистите кэш браузера.
Кодировка документа
Готовые файлы HTML важно сохранять в нужной кодировке сайта. Узнать текущую кодировку файла можно через Notepad++: откройте файл и зайдите в «Encoding». Меняется она там же: чтобы сменить кодировку на UTF-8, выберите «Convert to UTF-8 without BOOM». Нужно выбрать «без BOOM», чтобы не было пустых символов.
Кодировка Базы данных
Выбирайте нужную кодировку сразу при создании базы данных. Распространенный вариант — «UTF-8 general ci».
Где менять кодировку у БД:
- Кликните по названию нужной базы в утилите управления БД phpMyAdmin и откройте ее.
- Кликните на раздел «Операции»:
- Введите нужную кодировку для базы данных MySQL:
- Перейдите на сайт и очистите кэш.
С новой БД проще, но если вы меняете кодировку у существующей базы, то у созданных таблиц и колонок заданы свои кодировки, которые тоже нужно поменять.
Для всех таблиц, колонок, файлов, сервера и вообще всего, что связано с сайтом, должна быть одна кодировка.
Проблема может не решиться, если все дело в кодировке подключения к базе данных. Что делать:
- Подключитесь к серверу с правами mysql root пользователя:
mysql -u root -p - Выберите нужную базу:
USE имя_базы; - Выполните запрос:
SET NAMES ‘utf8’;
Если вы хотите указать Windows-1251, то пишите не «utf-8», а «cp1251» — обозначение для кодировки Windows-1251 у MySQL.
Чтобы установить UTF-8 по умолчанию, откройте на сервере my.cnf и добавьте следующее:
В области [client]:
default-character-set=utf8
В области [mysql]:
default-character-set=utf8
В области [mysqld]:
collation-server = utf8_unicode_ci
init-connect='SET NAMES utf8'
character-set-server = utf8
Вы когда-нибудь сталкивались с проблемами кодировки на сайте?
Глава 11. Работа с простыми текстовыми файлами
1. Кодировка по умолчанию
Простые текстовые файлы, в большинстве случаев имеющие расширение «txt», содержат только текст, и нет чёткого способа сообщить
компьютеру, на каком языке этот текст написан. Самое большее, что ОмегаТ может сделать в этом случае, это считать, что текст
написан на том же языке, что и язык, используемый операционной системой. Для файлов в 16-битной Юникод-кодировке такой проблемы
не существует. Однако, если файл имеет 8-битную кодировку, может возникнуть следующая неприятная ситуация: вместо отображения
текста на японском языке…
…программа покажет следующее:
Компьютер, на котором установлена ОмегаТ, работает на русском языке, и, соответственно, вместо иероглифов кандзи, программа
пытается использовать кириллицу.
2. Подход ОмегаТ
В целом, в ОмегаТ есть три метода борьбы с этой проблемой. Все они основываются на использовании файловых фильтров в меню Параметры.
- Change the encoding of your files to Unicode
откройте исходный файл в текстовом редакторе, который корректно распознаёт кодировку и сохраните файл в кодировке «UTF-8». Измените расширения файла с
.txt
на.utf8.
ОмегаТ автоматически распознает его как UTF-8 файл. Этот подход наиболее разумен, так как позволяет избавиться от многих проблем
в дальнейшем.
- Specify the encoding for your plain text files
то есть файлов с расширением
.txt
: в секции Текстовые файлы диалогового окна «Файловые фильтры» измените кодировку исходных файлов с «<auto>» на кодировку, соответствующую вашим исходным.txt
-файлам, например, на «.jp» для примера выше.
- Change the extensions of your plain text source files
например, для японских текстовых файлов с
.txt
на.jp
: в секции Текстовые файлы диалогового окна «Файловые фильтры» добавьте новый Шаблон имени исходного файла (например, на*.jp
для вышеприведённого примера) и выберите необходимые кодировки оригинала и перевода.
По умолчанию в ОмегаТ включены следующие настройки, чтобы вам было легче работать с некоторыми текстовыми файлами:
файлы
.txt2
считаются сохранёнными в кодировке ISO-8859-2, которая покрывает большинство языков Центральной и Восточной Европы.
Вы можете проверить эти настройки, выбрав пункт Файловые фильтры в меню Параметры. Например, если у вас есть текстовый файл на чешском (скорее всего, сохранённый в кодировке ISO-8859-2), вам нужно просто сменить расширение с .txt
на .txt2
и ОмегаТ корректно распознает его содержимое. И, конечно, если вы хотите навсегда избавиться от этих проблем, подумайте о возможности
сохранения таких файлов в Юникоде, то есть в формате .utf8
.
полезная информация и краткая ретроспектива
- Главная
- ->
- Материалы
- ->
- Кодировки: полезная информация и краткая ретроспектива
Reg.ru: домены и хостинг
Крупнейший регистратор и хостинг-провайдер в России.
Более 2 миллионов доменных имен на обслуживании.
Продвижение, почта для домена, решения для бизнеса.
Более 700 тыс. клиентов по всему миру уже сделали свой выбор.
Перейти на сайт->
Бесплатный Курс «Практика HTML5 и CSS3»
Освойте бесплатно пошаговый видеокурс
по основам адаптивной верстки
на HTML5 и CSS3 с полного нуля.
Начать->
Фреймворк Bootstrap: быстрая адаптивная вёрстка
Пошаговый видеокурс по основам адаптивной верстки в фреймворке Bootstrap.
Научитесь верстать просто, быстро и качественно, используя мощный и практичный инструмент.
Верстайте на заказ и получайте деньги.
Получить в подарок->
Бесплатный курс «Сайт на WordPress»
Хотите освоить CMS WordPress?
Получите уроки по дизайну и верстке сайта на WordPress.
Научитесь работать с темами и нарезать макет.
Бесплатный видеокурс по рисованию дизайна сайта, его верстке и установке на CMS WordPress!
Получить в подарок->
*Наведите курсор мыши для приостановки прокрутки.
Назад
Вперед
Кодировки: полезная информация и краткая ретроспектива
Данную статью я решил написать как небольшой обзор, касающийся вопроса кодировок.
Мы разберемся, что такое вообще кодировка и немного коснемся истории того, как они появились в принципе.
Мы поговорим о некоторых их особенностях а также рассмотрим моменты, позволяющие нам работать с кодировками более осознанно и избегать появления на сайте так называемых кракозябров, т.е. нечитаемых символов.
Итак, поехали…
Что такое кодировка?
Упрощенно говоря, кодировка — это таблица сопоставлений символов, которые мы можем видеть на экране, определенным числовым кодам.
Т.е. каждый символ, который мы вводим с клавиатуры, либо видим на экране монитора, закодирован определенной последовательностью битов (нулей и единиц). 8 бит, как вы, наверное, знаете, равны 1 байту информации, но об этом чуть позже.
Внешний вид самих символов определяется файлами шрифтов, которые установлены на вашем компьютере. Поэтому процесс вывода на экран текста можно описать как постоянное сопоставление последовательностей нулей и единиц каким-то конкретным символам, входящим в состав шрифта.
Прародителем всех современных кодировок можно считать ASCII.
Эта аббревиатура расшифровывается как American Standard Code for Information Interchange (американская стандартная кодировочная таблица для печатных символов и некоторых специальных кодов).
Это однобайтовая кодировка, в которую изначально заложено всего 128 символов: буквы латинского алфавита, арабские цифры и т.д.
Позже она была расширена (изначально она не использовала все 8 бит), поэтому появилась возможность использовать уже не 128, а 256 (2 в 8 степени) различных символов, которые можно закодировать в одном байте информации.
Такое усовершенствование позволило добавлять в ASCII символы национальных языков, помимо уже существующей латиницы.
Вариантов расширенной кодировки ASCII существует очень много по причине того, что языков в мире тоже немало. Думаю, что многие из вас слышали о такой кодировке, как KOI8-R — это тоже расширенная кодировка ASCII, предназначенная для работы с символами русского языка.
Следующим шагом в развитии кодировок можно считать появление так называемых ANSI-кодировок.
По сути это были те же расширенные версии ASCII, однако из них были удалены различные псевдографические элементы и добавлены символы типографики, для которых ранее не хватало «свободных мест».
Примером такой ANSI-кодировки является всем известная Windows-1251. Помимо типографических символов, в эту кодировку также были включены буквы алфавитов языков, близких к русскому (украинский, белорусский, сербский, македонский и болгарский).
ANSI-кодировка — это собирательное название. В действительности, реальная кодировка при использовании ANSI будет определяться тем, что указано в реестре вашей операционной системы Windows. В случае с русским языком это будет Windows-1251, однако, для других языков это будет другая разновидность ANSI.
Как вы понимаете, куча кодировок и отсутствие единого стандарта до добра не довели, что и стало причиной частых встреч с так называемыми кракозябрами — нечитаемым бессмысленным набором символов.
Причина их появления проста — это попытка отобразить символы, закодированные с помощью одной кодировочной таблицы, используя другую кодировочную таблицу.
В контексте веб-разработки, мы можем столкнуться с кракозябрами, когда, к примеру, русский текст по ошибке сохраняется не в той кодировке, которая используется на сервере.
Разумеется, это не единственный случай, когда мы можем получить нечитаемый текст — вариантов тут масса, особенно, если учесть, что есть еще база данных, в которой информация также хранится в определенной кодировке, есть сопоставление соединения с базой данных и т.д.
Возникновение всех этих проблем послужило стимулом для создания чего-то нового. Это должна была быть кодировка, которая могла бы кодировать любой язык в мире (ведь с помощью однобайтовых кодировок при всем желании нельзя описать все символы, скажем, китайского языка, где их явно больше, чем 256), любые дополнительные спецсимволы и типографику.
Одним словом, нужно было создать универсальную кодировку, которая решила бы проблему кракозябров раз и навсегда.
Юникод — универсальная кодировка текста (UTF-32, UTF-16 и UTF-8)
Сам стандарт был предложен в 1991 году некоммерческой организацией «Консорциум Юникода» (Unicode Consortium, Unicode Inc.), и первым результатом его работы стало создание кодировки UTF-32.
Кстати, сама аббревиатура UTF расшифровывается как Unicode Transformation Format (Формат Преобразования Юникод).
В этой кодировке для кодирования одного символа предполагалось использовать аж 32 бита, т.е. 4 байта информации. Если сравнивать это число с однобайтовыми кодировками, то мы придем к простому выводу: для кодирования 1 символа в этой универсальной кодировке нужно в 4 раза больше битов, что «утяжеляет» файл в 4 раза.
Очевидно также, что количество символов, которое потенциально могло быть описано с помощью данной кодировки, превышает все разумные пределы и технически ограничено числом, равным 2 в 32 степени. Понятно, что это был явный перебор и расточительство с точки зрения веса файлов, поэтому данная кодировка не получила распространения.
На смену ей пришла новая разработка — UTF-16.
Как очевидно из названия, в этой кодировке один символ кодируют уже не 32 бита, а только 16 (т.е. 2 байта). Очевидно, это делает любой символ вдвое «легче», чем в UTF-32, однако и вдвое «тяжелее» любого символа, закодированного с помощью однобайтовой кодировки.
Количество символов, доступное для кодирования в UTF-16 равно, как минимум, 2 в 16 степени, т.е. 65536 символов. Вроде бы все неплохо, к тому же окончательная величина кодового пространства в UTF-16 была расширена до более, чем 1 миллиона символов.
Однако и данная кодировка до конца не удовлетворяла потребности разработчиков. Скажем, если вы пишете, используя исключительно латинские символы, то после перехода с расширенной версии кодировки ASCII к UTF-16 вес каждого файла увеличивался вдвое.
В результате, была предпринята еще одна попытка создания чего-то универсального, и этим чем-то стала всем нам известная кодировка UTF-8.
UTF-8 — это многобайтовая кодировка с переменной длинной символа. Глядя на название, можно по аналогии с UTF-32 и UTF-16 подумать, что здесь для кодирования одного символа используется 8 бит, однако это не так. Точнее, не совсем так.
Дело в том, что UTF-8 обеспечивает наилучшую совместимость со старыми системами, использовавшими 8-битные символы. Для кодирования одного символа в UTF-8 реально используется от 1 до 4 байт (гипотетически можно и до 6 байт).
В UTF-8 все латинские символы кодируются 8 битами, как и в кодировке ASCII. Иными словами, базовая часть кодировки ASCII (128 символов) перешла в UTF-8, что позволяет «тратить» на их представление всего 1 байт, сохраняя при этом универсальность кодировки, ради которой все и затевалось.
Итак, если первые 128 символов кодируются 1 байтом, то все остальные символы кодируются уже 2 байтами и более. В частности, каждый символ кириллицы кодируется именно 2 байтами.
Таким образом, мы получили универсальную кодировку, позволяющую охватить все возможные символы, которые требуется отобразить, не «утяжеляя» без необходимости файлы.
C BOM или без BOM?
Если вы работали с текстовыми редакторами (редакторами кода), например Notepad++, phpDesigner, rapid PHP и т.д., то, вероятно, обращали внимание на то, что при задании кодировки, в которой будет создана страница, можно выбрать, как правило, 3 варианта:
— ANSI
— UTF-8
— UTF-8 без BOM
Сразу скажу, что выбирать всегда стоит именно последний вариант — UTF-8 без BOM.
Итак, что же такое BOM и почему нам это не нужно?
BOM расшифровывается как Byte Order Mark. Это специальный Unicode-символ, используемый для индикации порядка байтов текстового файла. По спецификации его использование не является обязательным, однако если BOM используется, то он должен быть установлен в начале текстового файла.
Не будем вдаваться в детали работы BOM. Для нас главный вывод следующий: использование этого служебного символа вместе с UTF-8 мешает программам считывать кодировку нормальным образом, в результате чего возникают ошибки в работе скриптов.
Поэтому, при работе с UTF-8 используйте именно вариант «UTF-8 без BOM». Также лучше не используйте редакторы, в которых в принципе нельзя указать кодировку (скажем, Блокнот из стандартных программ в Windows).
Кодировка текущего файла, открытого в редакторе кода, как правило, указывается в нижней части окна.
Обратите внимание, что запись «ANSI as UTF-8» в редакторе Notepad++ означает то же самое, что и «UTF-8 без BOM». Это одно и то же.
В программе phpDesigner нельзя сразу точно сказать, используется BOM, или нет. Для этого нужно кликнуть правой кнопкой мыши по надписи «UTF-8», после чего во всплывающем окне можно увидеть, используется ли BOM (опция Save with BOM).
В редакторе rapid PHP кодировка UTF-8 без BOM обозначается как «UTF-8*».
Как вы понимаете, в разных редакторах все выглядит немного по-разному, однако главную идею вы поняли.
После того, как документ сохранен в UTF-8 без BOM, нужно также убедиться, что верная кодировка указана в специальном метатэге в секции head вашего html-документа:
<meta charset = "utf-8" />
Соблюдение этих простых правил уже позволит вам избежать многих пробелем с кодировками.
На этом все, надеюсь, что данный небольшой экскурс и пояснения помогли вам лучше понять, что такое кодировки, какие они бывают и как работают.
Если вам интересна эта тема с более прикладной точки зрения, то рекомендую вам изучить мой видеоурок Полный UTF-8: чеклист для начинающих.
Дмитрий Науменко.
P.S. Присмотритесь к премиум-урокам по различным аспектам сайтостроения, а также к бесплатному курсу по созданию своей CMS-системы на PHP с нуля. Все это поможет вам быстрее и проще освоить различные технологии веб-разработки.
Понравился материал и хотите отблагодарить?
Просто поделитесь с друзьями и коллегами!
Смотрите также:
Наверх
Изменение кодировки текста и файлов
Функции ChangeFileCharset и ChangeTextCharset предназначены для изменения кодировки символов в текстовых файлах и строках.
Исходную и конечную (желаемую) кодировку можно задать в параметрах вызова функций.
ВНИМАНИЕ: Новая (универсальная) версия функции сохранения текста в файл в заданной кодировке:
http://excelvba.ru/code/SaveTextToFile
Список доступных на вашем компьютере кодировок можно найти в реестре Windows в ветке
HKEY_CLASSES_ROOT\MIME\Database\Charset
Среди доступных кодировок есть koi8-r, ascii, utf-7, utf-8, Windows-1250, Windows-1251, Windows-1252, и т.д. и т.п.
Определить исходную и конечную кодировку можно, воспользовавшись онлайн-декодером:
http://www.artlebedev.ru/tools/decoder/advanced/
(после преобразования снизу будет написано, из какой кодировки в какую переведён текст)
Sub ПримерИспользования_ChangeTextCharset() ИсходнаяСтрока = "бНОПНЯ" ' вызываем функцию ChangeTextCharset с указанием кодировок ' (меняем кодировку с KOI8-R на Windows-1251) ПерекодированнаяСтрока = ChangeTextCharset(ИсходнаяСтрока, "Windows-1251", "KOI8-R") MsgBox "Результат перекодировки: """ & ПерекодированнаяСтрока & """", _ vbInformation, "Исходная строка: """ & ИсходнаяСтрока & """" End Sub
Function ChangeFileCharset(ByVal filename$, ByVal DestCharset$, _ Optional ByVal SourceCharset$) As Boolean ' функция перекодировки (смены кодировки) текстового файла ' В качестве параметров функция получает путь filename$ к текстовому файлу, ' и название кодировки DestCharset$ (в которую будет переведён файл) ' Функция возвращает TRUE, если перекодировка прошла успешно On Error Resume Next: Err.Clear With CreateObject("ADODB.Stream") .Type = 2 If Len(SourceCharset$) Then .Charset = SourceCharset$ ' указываем исходную кодировку .Open .LoadFromFile filename$ ' загружаем данные из файла FileContent$ = .ReadText ' считываем текст файла в переменную FileContent$ .Close .Charset = DestCharset$ ' назначаем новую кодировку .Open .WriteText FileContent$ .SaveToFile filename$, 2 ' сохраняем файл уже в новой кодировке .Close End With ChangeFileCharset = Err = 0 End Function
Function ChangeTextCharset(ByVal txt$, ByVal DestCharset$, _ Optional ByVal SourceCharset$) As String ' функция перекодировки (смены кодировки) текстовоq строки ' В качестве параметров функция получает текстовую строку txt$, ' и название кодировки DestCharset$ (в которую будет переведён текст) ' Функция возвращает текст в новой кодировке On Error Resume Next: Err.Clear With CreateObject("ADODB.Stream") .Type = 2: .Mode = 3 If Len(SourceCharset$) Then .Charset = SourceCharset$ ' указываем исходную кодировку .Open .WriteText txt$ .Position = 0 .Charset = DestCharset$ ' назначаем новую кодировку ChangeTextCharset = .ReadText .Close End With End Function
‘ Функция для перекодировки файла в UTF-8 без BOM (то же самое, что и UTF-8, только без первых 3 байтов)
Function ChangeFileCharset_UTF8noBOM(ByVal filename$, Optional ByVal SourceCharset$) As Boolean ' функция перекодировки (смены кодировки) текстового файла ' В качестве параметров функция получает путь filename$ к текстовому файлу, ' Функция возвращает TRUE, если перекодировка прошла успешно On Error Resume Next: Err.Clear DestCharset$ = "utf-8" With CreateObject("ADODB.Stream") .Type = 2 If Len(SourceCharset$) Then .Charset = SourceCharset$ ' указываем исходную кодировку .Open .LoadFromFile filename$ ' загружаем данные из файла FileContent$ = .ReadText ' считываем текст файла в переменную FileContent$ .Close .Charset = DestCharset$ ' назначаем новую кодировку "utf-8" .Open .WriteText FileContent$ 'Write your data into the stream. Dim binaryStream As Object Set binaryStream = CreateObject("ADODB.Stream") binaryStream.Type = 1 binaryStream.Mode = 3 binaryStream.Open 'Skip BOM bytes .Position = 3 .CopyTo binaryStream .Flush .Close binaryStream.SaveToFile filename$, 2 binaryStream.Close End With ChangeFileCharset_UTF8noBOM = Err = 0 End Function
Функция перекодировки текста в UTF-8 без BOM
Function EncodeUTF8noBOM(ByVal txt As String) As String For i = 1 To Len(txt) l = Mid(txt, i, 1) Select Case AscW(l) Case Is > 4095: t = Chr(AscW(l) \ 64 \ 64 + 224) & Chr(AscW(l) \ 64) & Chr(8 * 16 + AscW(l) Mod 64) Case Is > 127: t = Chr(AscW(l) \ 64 + 192) & Chr(8 * 16 + AscW(l) Mod 64) Case Else: t = l End Select EncodeUTF8noBOM = EncodeUTF8noBOM & t Next End Function
что это такое и как установить ее
Кодировка сайта
Этот атрибут веб-ресурса объединяет в себе его коды и основанное на них экранное отображение печатных символов.
Назначение и принцип работы кодировки
Независимо от вида и места размещения (в текстовом контенте, файлах, письмах на email и на сайтах), целью кодирования всегда является сохранение данных в двоичном формате, то есть на языке компьютеров.
Как это работает?
Для наглядности рассмотрим такой пример. Допустим, ваш друг воспринимает только два символа: единицу и ноль. С другими цифрами и буквами он не знаком и может прочитать только те тексты, которые состоят из известных ему элементов. Поэтому возникает масса вопросов: как с таким другом общаться, доносить до него смысл слов и понимать, что он отвечает. Выход из ситуации – разработать систему, по которой каждой цифре, букве и другому символу будет соответствовать определенная комбинация единиц и нулей. Это позволит рассказать что-то другу, заменив слова двоичным кодом, и узнать, что он отвечает.
Что может пойти не так?
Если непонятливый друг один, всё более-менее понятно. Но как быть, когда таких людей десятки или даже сотни? У каждого из них собственные друзья и таблицы с кодами, поэтому при встрече никто никого не сможет понять. Один решил заменить «А» на 111000, а на другом табличном языке – это цифра 5. В результате все путаются, и разговор никак не складывается. Но пора вернуться к реальности. Компьютеры – это те друзья, о которых мы говорили, а кодировки – таблицы с заменой символов.
Виды кодировок
Из всех существующих языков кодирования мы выбрали несколько самых востребованных и удобных, о которых расскажем подробнее.
UTF-8
Этот вид кодирования, полное название которого – «Unicode Transformation Format», представляет собой восьмибитный «Юникод». Он появился в 1992 году и с тех пор по всему миру остаётся эталоном программного обеспечения. В UTF-8 есть два раздела, выделенных под кириллицу: Cyrillic Supplement и Cyrillic.
Таблица кодировки UTF-8 для букв русского алфавита
Коды UTF-8 для кириллических букв
Windows-1251
Это вторая по популярности восьмибитная кодировка, разработанная для русификаторов Windows еще в 1990 году. Она рассчитана на кириллический шрифт.
Таблица кодировки Windows-1251
Коды Windows-1251
KOI8-R
Такой стандартный язык предназначен специально для кодирования кириллицы. Убирая восьмой бит у каждого из его символов, получаем латинскую транскрипцию кириллических букв. С его помощью можно, например, закодировать письмо для отправки на email, но сегодня этот вид кодировки можно встретить редко.
Таблица кодировки KOI8-R
Коды KOI8-R
Способы определения кодировки
Когда на сайте возникают ошибки, чтобы исправить их, иногда необходимо установить, как закодирована страница. Как именно это можно сделать, расскажем дальше.
1-й способ – по метатегу
Будем действовать по такому алгоритму.
- Открываем исходный код. Для этого в открытом окне кликаем правой клавишей мышки по свободному месту. Появится меню, в котором нужно выбрать «Исходный код страницы».
- Находим тег в директории .
- Дальше ищем в нём строчку с реквизитом charset. Именно его значение отражает кодировку страницы.
2-й способ – при помощи инструментов браузера
В этом случае, чтобы проверить, какой вид кодирования выбран для сайта, нужно придерживаться такой схемы действий.
- Ищем в настройках браузера раздел с информацией о странице или пункт «Подробнее» в зависимости от выбранного программного обеспечения.
- Откроется окно, в котором нам нужно выбрать вкладку с ключевыми сведениями о странице.
- Здесь одним из пунктов будет кодировка
Установка кодировки для разных браузеров
Если при открытии сайта невозможно ничего прочитать, потому что видны не буквы кириллицы, а какие-то крючки, цифры или символы на латинице, для приведения страницы в стандартный вид необходимо выставить кодировку вручную. Рассмотрим по шагам, как это сделать в самых популярных браузерах.
Firefox от Mozilla
- Открываем меню. Это можно сделать, кликнув по значку в виде трех горизонтальных полосок.
- Переходим в раздел «Ещё».
- Откроется окно, где нужно выбрать пункт «Кодировка текста».
- Из появившегося списка выбираем подходящий вариант.
Opera
- Запускаем настройку браузера.
- Находим в меню раздел «Веб-сайты»..
- Здесь нужно выбрать «Отображение».
- Из доступных команд нам пригодится «Настроить шрифты».
- Теперь остаётся только выбрать кодировку.
Chrome от Google
- Заходим в меню. В этом браузере это можно сделать, кликнув по троеточию в правом верхнем углу.
- Выбираем раздел «Дополнительные инструменты»
- Здесь нам нужен пункт «Кодировка».
- В открывшемся окне появится список языков кодирования, из которых выбираем нужный.
Настройка кодировки
Если с вашим сайтом постоянно возникают проблемы, поступают жалобы от посетителей по поводу неправильно закодированных страниц, есть смысл настроить всё заново. Чтобы наладить работу ресурса, нужно закодировать сервер, базы данных, скрипты и файлы одинаково. Для этого мы пройдёмся по таким пунктам.
- Все размещённые на сайте файлы приводим к единой кодировке. Если есть необходимость её поменять, используем специальные приложения. Как вариант, можно выбрать Notepad++.
- Устанавливаем теги кодировок в html.
- Настраиваем заголовки серверов таким образом, чтобы они кодировались по умолчанию. Иначе браузер не будет воспринимать даже метатеги.
- В файле httpd.conf находим команду AddDefaultCharset и устанавливаем нужное значение.
- Если доступ к корневым настройкам сервера отсутствует, есть другой способ изменения кодировки. Вводим необходимые параметры в файл .htaccess, размещённый в папке нашего ресурса.
- Заголовки можно отправить при помощи скриптов. Это важная операция, и прежде чем выводить контент, прежде всего нужно выполнить её.
Нам придётся выставить для подключаемых модулей правильную кодировку вручную. Если закодировать сайт неправильно, можно причинить вред аудитории. В результате посещаемость и доходность значительно снизятся. Попав на ваш ресурс, посетители увидят не тексты, а непонятные символы. Вряд ли кто-то из них займётся ручной настройкой кодировки, и практически все просто покинут страницу. Нужно решать эту задачу максимально ответственно, так как от правильного кодирования во многом зависит судьба вашего проекта.
Теги
Вам также будет интересно
Введение Rubyist в кодировку символов, Unicode и UTF-8
Очень вероятно, что вы видели исключение Ruby, такое как UndefinedConversionError
или IncompatibleCharacterEncodings
. Маловероятно, что вы поняли, что означает исключение. Эта статья поможет. Вы узнаете, как работают кодировки символов и как они реализованы в Ruby. К концу вы сможете гораздо легче понять и исправить эти ошибки.
Так что же такое «кодировка символов»?
На каждом языке программирования вы работаете со строками.Иногда вы обрабатываете их как входные, иногда вы отображаете их как выходные. Но ваш компьютер не понимает «строк». Он понимает только биты: единицы и нули. Процесс преобразования строк в биты называется кодировкой символов.
Но кодировка символов принадлежит не только эпохе компьютеров. До появления компьютеров мы можем учиться на более простом процессе: азбуке Морзе.
Код Морзе
Азбука Морзе очень проста по определению. У вас есть два символа или два способа подачи сигнала (короткий и длинный).Эти два символа представляют собой простой английский алфавит. Например:
- A — .- (одна короткая метка и одна длинная метка)
- E есть. (одна короткая отметка)
- O — — (три длинных знака)
Эта система была изобретена примерно в 1837 году и позволяла кодировать весь алфавит всего двумя символами или сигналами.
Здесь можно поиграть с одним переводчиком онлайн.
На изображении вы можете увидеть «кодировщика», человека, ответственного за кодирование и декодирование сообщений.Это скоро изменится с появлением компьютеров.
От ручного к автоматическому кодированию
Чтобы закодировать сообщение, вам нужен человек, который вручную переводит символы в символы, следуя алгоритму кода Морзе.
Подобно азбуке Морзе, компьютеры используют только два «символа»: 1 и 0. Вы можете сохранить в компьютере только их последовательность, и когда они будут прочитаны, их нужно интерпретировать таким образом, чтобы это было понятно пользователю. .
В обоих случаях процесс работает следующим образом:
Сообщение -> Кодирование -> Сохранить / Отправить -> Декодирование -> Сообщение
SOS азбукой Морзе это будет:
SOS -> Кодировать ('SOS') ->... --- ... -> Декодировать ('... --- ...') -> SOS
----------------------- --------------------------
Отправитель Получатель
Большое изменение в компьютерах и других технологиях заключалось в том, что процесс кодирования и декодирования был автоматизирован, поэтому нам больше не требовались люди для перевода информации.
Когда были изобретены компьютеры, одним из первых стандартов, созданных для автоматического преобразования символов в единицы и нули (хотя и не первым), был ASCII.
ASCII — это американский стандартный код для обмена информацией. «Американская» роль в течение некоторого времени играла важную роль в том, как компьютеры работали с информацией; мы увидим почему в следующем разделе.
ASCII (1963)
Основываясь на знании телеграфных кодов, таких как азбука Морзе, и очень ранних компьютеров, стандарт для кодирования и декодирования символов на компьютере был создан примерно в 1963 году. Эта система была относительно простой, поскольку сначала охватывала только 127 символов, английский алфавит плюс дополнительные символы. .
ASCII работал путем связывания каждого символа с десятичным числом, которое можно было преобразовать в двоичный код. Давайте посмотрим на пример:
«A» — это 65 в ASCII, поэтому нам нужно перевести 65 в двоичный код.
Если вы не знаете, как это работает, вот быстрый способ : Мы начинаем делить 65 на 2 и продолжаем, пока не получим 0. Если деление неточно, мы добавляем 1 в качестве остатка:
65/2 = 32 + 1
32/2 = 16 + 0
16/2 = 8 + 0
8/2 = 4 + 0
4/2 = 2 + 0
2/2 = 1 + 0
1/2 = 0 + 1
Теперь берем остатки и складываем их в обратном порядке:
Таким образом, мы сохраним «A» как «1000001» с исходной кодировкой ASCII, теперь известной как US-ASCII.7 символов = 127.
Вот полная таблица:
(С http://www.plcdev.com/ascii_chart)
Проблема с ASCII
Что произойдет, если мы захотим добавить еще один символ, например французский ç или японский иероглиф 大?
Да, у нас будет проблема.
После ASCII люди пытались решить эту проблему, создав свои собственные системы кодирования. Они использовали больше бит, но это в конечном итоге вызвало другую проблему.
Основная проблема заключалась в том, что при чтении файла вы не знали, есть ли у вас определенная система кодирования.Попытка интерпретировать его с помощью неправильной кодировки привела к тарабарщине вроде «���» или «Ã, ÂÃ⠀ šÃ‚».
Развитие этих систем кодирования было большим и широким. В зависимости от языка у вас были разные системы. Языкам с большим количеством символов, таким как китайский, пришлось разработать более сложные системы для кодирования своих алфавитов.
После многих лет борьбы с этим был создан новый стандарт: Unicode. Этот стандарт определил способ кодирования и декодирования информации современными компьютерами.
Юникод (1988)
Цель
Unicode очень проста. Согласно его официальному сайту:
«Чтобы предоставить уникальный номер для каждого символа, независимо от платформы, программы или языка».
Таким образом, каждому символу в языке назначен уникальный код, также известный как кодовая точка. В настоящее время насчитывается более 137 000 символов.
В рамках стандарта Unicode у нас есть разные способы кодирования этих значений или кодовых точек, но UTF-8 является наиболее обширным.
Те же люди, которые создали язык программирования Go, Роб Пайк и Кен Томпсон, также создали UTF-8. Он добился успеха, потому что он эффективно и умно кодирует эти числа. Посмотрим, почему именно.
UTF-8: формат преобразования Unicode (1993)
UTF-8 теперь де-факто кодировка для веб-сайтов (более 94% веб-сайтов используют эту кодировку). Это также кодировка по умолчанию для многих языков программирования и файлов. Так почему это было так успешно и как это работает?
UTF-8, как и другие системы кодирования, преобразует числа, определенные в Unicode, в двоичные для сохранения их в компьютере.
Есть два очень важных аспекта UTF-8:
— Эффективен при хранении битов, так как символ может занимать от 1 до 4 байтов.
— Благодаря использованию Unicode и динамического количества байтов он совместим с кодировкой ASCII, поскольку первые 127 символов занимают 1 байт. Это означает, что вы можете открыть файл ASCII как UTF-8.
Давайте разберемся, как работает UTF-8.
UTF-8 с 1 байтом
В зависимости от значения в таблице Unicode, UTF-8 использует разное количество символов.
С первыми 127 используется следующий шаблон:
Ржавчина1
0_______
Таким образом, всегда будет 0, за которым следует двоичное число, представляющее значение в Юникоде (которое также будет ASCII). Например: A = 65 = 1000001.
Давайте проверим это с помощью Ruby, используя метод unpack в String:
'A'. Распаковать ('B *'). Первый
# 01000001
Буква B означает, что нам нужен двоичный формат со старшим битом первым.В данном контексте это означает бит с наивысшим значением.
Звездочка говорит Ruby продолжать, пока не кончатся биты. Если бы мы использовали вместо этого число, мы получили бы только биты до этого числа:
'A'. Распаковка ('B4'). Первая
# 01000
UTF-8 с 2 байтами
Если у нас есть символ, значение или кодовая точка которого в Unicode превышает 127, до 2047, мы используем два байта со следующим шаблоном:
Итак, у нас есть 11 пустых битов для значения в Юникоде.Давайте посмотрим на пример:
À — это 192 в Юникоде, поэтому в двоичном формате это 11000000, что занимает 8 бит. Он не помещается в первый шаблон, поэтому мы используем второй:
Начинаем заполнять поля справа налево:
Что там происходит с пустыми битами? Мы просто ставим нули, поэтому окончательный результат будет: 11000011 10000000.
Здесь мы можем увидеть закономерность. Если мы начнем чтение слева направо, первая группа из 8 бит будет иметь две единицы в начале. Это означает, что символ займет 2 байта:
Опять же, мы можем проверить это с помощью Ruby:
«А».распаковать ('B *'). сначала
# 1100001110000000
Небольшой совет: мы можем лучше отформатировать вывод с помощью:
'А'.unpack (' B8 B8 '). Join (' ')
# 11000011 10000000
Мы получаем массив из 'À'.unpack (' B8 B8 ')
и затем соединяем элементы пробелом, чтобы получить строку. Восьмерки в параметре unpack говорят Ruby получить 8 бит в 2 группы.
UTF-8 с 3 байтами
Если значение в Unicode для символа не соответствует 11 битам, доступным в предыдущем шаблоне, нам понадобится дополнительный байт:
1110____ 10______ 10______
Опять же, три единицы в начале шаблона говорят нам, что мы собираемся прочитать 3-байтовый символ.
Тот же процесс будет применен к этому шаблону; преобразовать значение Unicode в двоичное и начать заполнять слоты справа налево. Если после этого у нас остались пустые места, заполните их нулями.
UTF-8 с 4 байтами
Некоторые значения занимают даже больше, чем 11 пустых битов, которые были в предыдущем шаблоне. Давайте посмотрим на пример с эмодзи 🙂, который для Юникода также можно рассматривать как такой символ, как «a» или «大».
Значение или кодовая точка «» в Юникоде — 128578.Это число в двоичном формате: 11111011001000010, 17 бит. Это означает, что он не помещается в 3-байтовый шаблон, поскольку у нас было только 16 пустых слотов, поэтому нам нужно использовать новый шаблон, который занимает 4 байта в памяти:
11110___ 10______ 10______ 10______
Начнем снова, заполнив его числом в двоичном формате:
Ржавчина1
11110___ 10_11111 10011001 10000010
А теперь заполняем остальные нулями:
Ржавчина1
1111000 10011111 10011001 10000010
Давайте посмотрим, как это выглядит в Ruby.
Поскольку мы уже знаем, что это займет 4 байта, мы можем оптимизировать для лучшей читаемости вывода:
'🙂'.unpack (' B8 B8 B8 B8 '). Join (' ')
# 11110000 10011111 10011001 10000010
Но если бы мы этого не сделали, мы могли бы просто использовать:
Мы также могли бы использовать строковый метод «bytes» для извлечения байтов в массив:
🙂. Байтов
# [240, 159, 153, 130]
И затем мы могли бы отобразить элементы в двоичном формате с помощью:
"🙂".bytes.map {| e | e.to_s 2}
# ["11110000", "10011111", "10011001", "10000010"]
И если бы нам нужна была строка, мы могли бы использовать join:
"🙂" .bytes.map {| e | e.to_s 2} .join ('')
# 11110000 10011111 10011001 10000010
UTF-8 имеет больше места, чем необходимо для Unicode
Еще одним важным аспектом UTF-8 является то, что он может включать все значения Unicode (или кодовые точки) — и не только те, которые существуют сегодня, но также и те, которые будут существовать в будущем.21 (= 2 097 152) значения, намного больше, чем наибольшее количество значений Unicode, которое мы когда-либо будем иметь со стандартом, около 1,1 миллиона.
Это означает, что мы можем использовать UTF-8 с уверенностью, что в будущем нам не потребуется переходить на другую систему кодирования для выделения новых символов или языков.
Работа с разными кодировками в Ruby
В Ruby мы можем сразу увидеть кодировку заданной строки, сделав это:
'Привет'. Encoding.name
# "UTF-8"
Можно также закодировать строку с другой системой кодирования.Например:
encoded_string = 'привет, как дела?'. Encode ("ISO-8859-1", "UTF-8")
encoded_string.encoding.name
# ISO-8859-1
Если преобразование несовместимо, по умолчанию мы получаем ошибку. Допустим, мы хотим преобразовать «hello 🙂» из UTF-8 в ASCII. Поскольку смайлик «🙂» не подходит для ASCII, мы не можем. В этом случае Ruby выдает ошибку:
"привет 🙂" .encode ("ASCII", "UTF-8")
# Encoding :: UndefinedConversionError (U + 1F642 из UTF-8 в US-ASCII)
Но Ruby позволяет нам иметь исключения, когда, если символ не может быть закодирован, мы можем заменить его на «?».
"привет 🙂" .encode ("ASCII", "UTF-8", undef:: replace)
# Привет ?
У нас также есть возможность заменить определенные символы допустимым символом в новой кодировке:
"hello 🙂" .encode ("ASCII", "UTF-8", резерв: {"🙂" => ":)"})
# Привет :)
Проверка кодировки сценария для сценария в Ruby
Чтобы увидеть кодировку файла сценария, над которым вы работаете, файла «.rb», вы можете сделать следующее:
__ENCODING__
# В моем случае будет отображаться "# ".
Начиная с Ruby 2.0, кодировка по умолчанию для скриптов Ruby — UTF-8, но вы можете изменить это с помощью комментария в первой строке:
# кодировка: ASCII
__ENCODING__
# # <Кодировка: US-ASCII>
Но лучше придерживаться стандарта UTF-8, если у вас нет веских причин для его изменения.
Несколько советов по работе с кодировками в Ruby
Вы можете увидеть весь список поддерживаемых кодировок в Ruby с кодировкой .имя_список
. Это вернет большой массив:
[«ASCII-8BIT», «UTF-8», «US-ASCII», «UTF-16BE», «UTF-16LE», «UTF-32BE», «UTF-32LE», «UTF-16» , «UTF-32», «UTF8-MAC» ...
Другой важный аспект при работе с символами вне английского языка заключается в том, что до Ruby 2.4 некоторые методы, такие как upcase
или reverse
, не работали должным образом. Например, в Ruby 2.3 upcase работает не так, как вы думаете:
# Рубин 2.3
'öıüëâñà'.upcase
# 'öıüëâñà'
Обходной путь использовал ActiveSupport из Rails или другой внешний гем, но начиная с Ruby 2.4 у нас есть полное сопоставление регистров Unicode:
# Начиная с Ruby 2.4 и выше
'öıüëâñà'.upcase
# 'ÖIÜËÂÑÀ'
Немного развлечься с смайликами
Давайте посмотрим, как смайлики работают в Unicode и Ruby:
Это «Поднятая рука с частью между средним и безымянным пальцами», также известная как смайлик «Вулканский салют». Если у нас есть тот же смайлик, но с другим оттенком кожи, который не используется по умолчанию, происходит кое-что интересное:
'🖖🏾'.символы
# ["🖖", "🏾"]
Итак, вместо одного персонажа у нас есть два для одного смайлика.
Что там произошло?
Ну, некоторые символы в Юникоде определяются как комбинация нескольких символов. В этом случае, если компьютер видит эти два символа вместе, он показывает только один с примененным оттенком кожи.
Есть еще один забавный пример с флагами.
'🇦🇺'.chars
# ["🇦", "🇺"]
В Юникоде эмодзи флага внутренне представлены некоторыми абстрактными символами Юникода, называемыми «региональными символами индикатора», такими как 🇦 или 🇿.Обычно они не используются вне флагов, и когда компьютер видит два символа вместе, он показывает флаг, если он есть для этой комбинации.
Чтобы убедиться в этом, попробуйте скопировать это и удалить запятую в любом текстовом редакторе или поле:
Заключение
Я надеюсь, что этот обзор того, как работают Unicode и UTF-8 и как они соотносятся с Ruby и потенциальными ошибками, был вам полезен.
Самый важный урок, который нужно усвоить, — это помнить, что при работе с любым типом текста у вас есть связанная система кодирования, и важно сохранить ее при сохранении или изменении.По возможности используйте современную систему кодирования, такую как UTF-8, чтобы не менять ее в будущем.
Замечание о выпусках Ruby
Я использовал Ruby 2.6.5 для всех примеров в этой статье. Вы можете попробовать их в онлайн-REPL или локально, перейдя в терминал и выполнив irb
, если у вас установлен Ruby.
Поскольку поддержка Unicode была улучшена в последних выпусках, я решил использовать последнюю версию, поэтому эта статья останется актуальной. Во всяком случае, с Ruby 2.4 и выше, все примеры должны работать, как показано здесь.
Работа с кодировками в Ruby 1.9
(Последнее обновление 11.2.2013)
Я не буду вдаваться в подробности здесь, а остановлюсь на том, что я считаю важными. Если вам нужна дополнительная информация по этой теме, я настоятельно рекомендую The Pragmatic Programmers ’Programming Ruby 1.9, который посвящает этой теме целую главу.
Одно из больших изменений в Ruby 1.9 — это многоязычие (a.к.а. m17n) поддержка.
Раньше поддержка чего-либо, кроме строк в кодировке ASCII, была, по меньшей мере, несколько тусклой. Ruby 1.8 всегда предполагает, что символы в строках представляют собой ровно один байт, что неизменно приводит к проблемам, среди прочего, при работе с многобайтовыми кодировками. Установив $ KCODE
, вы могли добавить некоторую поддержку различных японских кодировок или UTF-8, но даже тогда были некоторые проблемы, которые затрудняли работу с такими строками.
Многие другие языки решают эту проблему, используя внутреннюю кодировку для всех своих строк. Python, например, использует Unicode для всех строк, что означает, что он должен перекодировать строки в других кодировках (например, Shift JIS, кодировка, используемая для японских символов), прежде чем иметь возможность работать с ними. Однако Ruby 1.9 поддерживает строковые кодировки символов, а также поддерживает преобразование между этими кодировками. Практически это означает, что вы можете назначить каждой строке собственную кодировку, и Ruby автоматически будет делать такие вещи, как правильное вычисление длины строки.
Кодировки
представлены экземпляром кодировки
. Каждый экземпляр представляет определенную кодировку, например UTF-8. Вы можете получить список всех встроенных кодировок, позвонив по номеру Encoding.list
. Начиная с Ruby 1.9.1-RC1, этот список содержит 83 различных кодировки, которые, вероятно, покрывают 99% потребностей в кодировании, которые у вас когда-либо будут.
Однако Ruby не только поддерживает кодирование строк (и, конечно, регулярных выражений), но также поддерживает различные кодировки для файлов исходного кода, а также того, что вы читаете и записываете в потоки ввода-вывода.Это означает, что теперь вы можете использовать умляуты в именах переменных, если вы правильно указали кодировку вашего исходного кода:
#! Ruby19
# кодировка: utf-8
псевдоним: λ: лямбда
π = Math :: PI
hello_world = λ {| тема | "Здравствуйте, # {subject}! Π равно # {π}"}
помещает hello_world ["world"] # => Привет, мир! π равно 3,14159265358979
помещает "λπ" .length # => 2
В этом примере я установил кодировку внутри самого файла исходного кода, используя волшебный комментарий. Есть несколько разных способов их использования, но в основном Ruby сканирует в поисках комментария в первой или второй строке (для размещения shebangs), который содержит строку « encoding:
», за которой следует имя кодировки, поэтому даже магические комментарии вроде Emacs ‘ # - * - кодировка: utf-8 - * -
будет работать.Кроме того, Ruby также ищет метку порядка байтов UTF-8 в начале файла и автоматически устанавливает соответствующую кодировку. Если ничего из этого не указано, Ruby по умолчанию будет использовать ASCII.
Установив кодировку, Ruby также допускает идентификаторы, отличные от ascii, поэтому я могу присвоить лямбда
псевдониму фактического греческого лямбда-символа. Также обратите внимание, что он правильно дает длину строки как 2, тогда как Ruby 1.8 напечатал бы 4, поскольку Ruby 1.9 автоматически использует текущую кодировку исходного файла для любых строковых литералов в этом файле.
Обратите внимание, что приведенный выше пример демонстрирует то, что я считаю плохим поведением программистов. Идентификаторы, отличные от ASCII, такие как Lambda или Pi, могут быть понятны большинству программистов, но использование вашего родного языка и символов для имен переменных и методов делает практически невозможным понимание вашего кода для тех, кто не говорит на вашем языке. Поэтому, если у вас нет веской причины, используйте английские имена, как вы это делали в Ruby 1.8.
Кодировка исходного файла устанавливается для каждого файла индивидуально, поэтому использование библиотеки, использующей Shift JIS, в то время как ваши исходные файлы используют UTF-8, вообще не проблема (опять же, если все правильно декларируют свою кодировку).
Как я уже упоминал, каждая строка (и регулярное выражение, которое для целей этого поста — одно и то же) имеет свою собственную кодировку, к которой вы можете получить доступ с помощью метода String # encoding
( __ENCODING__
возвращает текущий источник кодировка файла):
>> __ENCODING__.name
=> «UTF-8»
>> str = "Rüby"
=> «Руби»
>> str.encoding.name
=> «UTF-8»
Если вы хотите перекодировать строку в другую кодировку, используйте String # encode
:
>> str_in_western_iso = str.кодировать ("iso-8859-1")
=> «R ######
Поскольку моя оболочка настроена для UTF-8, строки в кодировке ISO-8859-1 не только не будут отображаться правильно, но и испортят мой вывод (ублюдки!). Но посмотрев на байты для обеих строк, мы увидим, что str
было правильно перекодировано:
>> str.bytes.to_a
=> [82, 195, 188, 98, 121]
>> str_in_western_iso.bytes.to_a
=> [82, 252, 98, 121]
Транскодирование в кодировку, которая не поддерживает все символы в вашей строке, конечно же, не удастся:
>> str_in_ascii = str.кодировать ("us-ascii")
Encoding :: UndefinedConversionError: "\ xC3 \ xBC" из UTF-8 в US-ASCII
from (irb): 29: в `кодировке '
от (irb): 29
из / usr / local / bin / irb19: 12: в `<основной> '
Однако для таких случаев можно указать символы-заполнители. Вы также можете принудительно ввести кодировку в строку, используя String # force_encoding
, который изменяет свою кодировку без изменения базовых байтов. Также обратите внимание, что String # encode
имеет гораздо больше возможностей для перекодирования.См. Документацию Ruby или Programming Ruby 1.9 для получения дополнительной информации.
Внешние данные также имеют множество различных кодировок, и вы будете рады услышать, что Ruby поддерживает и их.
Как и строки, объекты ввода-вывода также имеют связанные с ними кодировки, но в отличие от строк, объекты ввода-вывода имеют концепцию внешней кодировки. Внешнее кодирование описывает, как данные фактически кодируются.
Во-первых, быстрый пример:
>> f = файл.open ("example.txt")
=> # <Файл: example.txt>
>> f.external_encoding.name
=> «UTF-8»
>> content = f.read
=> «Этот файл содержит только символы ASCII.»
>> content.encoding.name
=> «UTF-8»
По умолчанию для внешней кодировки установлено значение переменной среды $ LANG
— в моем случае de_AT.UTF-8
. Однако на него также может влиять переменная $ LC_ALL
( спасибо Дэну Хенсгену ).
Однако не каждый файл, который вы собираетесь читать, будет использовать внешнюю кодировку по умолчанию, поэтому вы можете переопределить ее при вызове File.открыть
. Поскольку example.txt
содержит только символы ASCII, мы захотим использовать кодировку ASCII при его чтении:
>> f = File.open ("example.txt", "r: ascii")
=> # <Файл: example.txt>
>> f.external_encoding.name
=> «US-ASCII»
>> content = f.read
=> «Этот файл содержит только символы ASCII.»
>> content.encoding.name
=> «US-ASCII»
Здесь я сказал Ruby использовать ASCII в качестве внешней кодировки для примера .txt
, и любые считываемые из него данные автоматически получают ту же кодировку.
Часто внешняя кодировка не соответствует кодировке, которую мы хотим использовать внутри, например UTF-8. Поэтому, когда мы читаем файл, содержащий символы ISO-8859-1, строки могут иметь связанную с ними правильную кодировку, но мы не можем распечатать их должным образом, поскольку оболочка ожидает символы UTF-8:
>> f = File.open ("iso-8859-1.txt", "r: iso-8859-1")
=> # <Файл: iso-8859-1.txt>
>> ф.external_encoding.name
=> «ISO-8859-1»
>> content = f.read
=> "Этот файл содержит умляуты: ###"
>> content.encoding.name
=> «ISO-8859-1»
Мы можем решить эту проблему, указав нашу внутреннюю кодировку при открытии файла:
>> f = File.open ("iso-8859-1.txt", "r: iso-8859-1: utf-8")
=> # <Файл: iso-8859-1.txt>
>> f.external_encoding.name
=> «ISO-8859-1»
>> content = f.read
=> «Этот файл содержит умляуты: äöü»
>> содержание.encoding.name
=> «UTF-8»
Это заставляет Ruby автоматически перекодировать данные при чтении, таким образом обеспечивая правильный вывод.
Единственный способ установить внутреннюю (и внешнюю) кодировку по умолчанию — использовать переключатель -E
, например рубин -E iso-8859-1: utf-8
. Это установит внешнюю кодировку по умолчанию на ISO-8859-1 и внутреннюю кодировку по умолчанию на UTF-8. Необязательно указывать и то, и другое: -E iso-9959-1
будет указывать только внешнюю кодировку по умолчанию, а -E: utf-8
— только внутреннюю кодировку по умолчанию.
Все это кодирование имеет еще один эффект: теперь вы больше не можете просто читать двоичные файлы, как вы это делали в Ruby 1.8. Чтобы заставить Ruby читать файл как двоичные данные, либо укажите флаг b
, либо используйте двоичную кодировку
при открытии файлов (пользователи Windows уже будут знакомы с флагом b
). Это устанавливает внешнюю кодировку ASCII-8BIT, обеспечивая правильное чтение двоичных данных:
>> f = File.open ("example.txt", "rb")
=> # <Файл: пример.txt>
>> f.external_encoding.name
=> «ASCII-8BIT»
>> f.read.encoding.name
=> «ASCII-8BIT»
>> f.close
=> ноль
>> f = File.open ("example.txt", "r: двоичный")
=> # <Файл: example.txt>
>> f.external_encoding.name
=> «ASCII-8BIT»
>> f.read.encoding.name
=> «ASCII-8BIT»
Еще одна потенциальная ловушка — это когда вы работаете со строками с несовместимыми кодировками. Если вы попытаетесь запустить регулярное выражение в кодировке UTF-8 для строки в кодировке ISO-8859-1, вы получите исключение.Есть несколько способов справиться с этим, но лучший способ — принудительно использовать одну кодировку, которую вы используете внутри (я рекомендую UTF-8), и перекодировать любую другую строку. Этого можно добиться разными способами, но, вероятно, самый простой способ — установить правильную внутреннюю кодировку по умолчанию.
Кодировка
— CLion
Чтобы правильно отображать и редактировать файлы, CLion необходимо знать, какую кодировку использовать. Как правило, файлы исходного кода в основном находятся в UTF-8. Это рекомендуемая кодировка, если у вас нет других требований.
Чтобы определить кодировку файла, CLion использует следующие шаги:
Если присутствует метка порядка байтов (BOM), CLion будет использовать соответствующую кодировку Unicode независимо от всех других настроек. Для получения дополнительной информации см. Метка порядка байтов.
Если в файле явно указана кодировка, CLion будет использовать указанную кодировку. Например, это может относиться к файлам XML или HTML. Явное объявление также отменяет все остальные настройки, но вы можете изменить его в редакторе.
Если в файле нет спецификации и явного объявления кодировки, CLion будет использовать кодировку, настроенную для файла или каталога в настройках кодировки файла. Если кодировка не настроена для файла или каталога, CLion будет использовать кодировку родительского каталога. Если кодировка родительского каталога также не настроена, CLion вернется к кодировке проекта, а при отсутствии проекта — к глобальной кодировке.
Изменить кодировку, используемую для просмотра файла
Если CLion неправильно отображает символы в файле, вероятно, он не может определить кодировку файла.В этом случае вам необходимо указать правильную кодировку для использования при просмотре и редактировании этого файла.
Открыв файл в редакторе, выберите в главном меню или щелкните виджет «Кодировка файла» в строке состояния и выберите правильную кодировку файла.
Список кодировок достаточно большой. Вы можете использовать быстрый поиск, чтобы быстро найти правильную кодировку: начните вводить текст, когда всплывающее окно открыто.
Кодировки, отмеченные значком или могут изменить содержимое файла.В этом случае CLion открывает диалоговое окно, в котором вы можете выбрать, что делать с файлом:
Перезагрузить: загрузить файл в редактор с диска и применить изменения кодировки только к редактору. Вы увидите изменения содержимого, связанные с выбранной кодировкой, но сам файл не изменится.
Конвертировать: перезаписать файл с выбранной кодировкой.
Это добавит ассоциацию для файла в настройки кодировки файла. CLion будет использовать указанную кодировку для просмотра и редактирования этого файла.
Настройка параметров кодировки файлов
В диалоговом окне «Настройки / Предпочтения» Ctrl + Alt + S выберите.
CLion использует эти настройки для просмотра и редактирования файлов, для которых не удалось определить кодировку, а также использует указанные кодировки для новых файлов.
Выбрать кодировку вывода консоли
По умолчанию CLion использует системную кодировку для просмотра вывода консоли.
В диалоговом окне «Настройки / Предпочтения» Ctrl + Alt + S выберите.
Выберите кодировку по умолчанию из списка Кодировка по умолчанию.
Нажмите ОК, чтобы применить изменения.
Последнее изменение: 26 февраля 2021 г.
Кодировок символов
Кодировка символов — это отображение набора символов на
их представление на диске. jEdit может использовать любую кодировку, поддерживаемую
платформа Java.
Буферы в памяти всегда хранятся в UTF-16
кодировка, что означает, что каждый символ сопоставляется с целым числом от 0
и 65535. UTF-16
— это собственная кодировка, поддерживаемая
Java и имеет достаточно большой набор символов для поддержки большинства современных
языков.
Когда буфер загружается, он конвертируется со своего диска
представление в UTF-16
с использованием указанного
кодирование.
Кодировка по умолчанию, используемая для загрузки файлов, для которых нет других
кодировка указана, может быть установлена в
Кодировки панель
>
диалоговое окно; см. раздел «Панель кодировок».Если вы не измените этот параметр, это будет
собственная кодировка, например MacRoman
на MacOS,
windows-1252
в Windows и
ISO-8859-1
в Unix.
Кодировка может быть явно установлена при открытии файла в файле
системный браузер
>
меню.
Обратите внимание, что общего способа автоматического определения используемой кодировки не существует.
файлом, однако jEdit поддерживает «детекторы кодирования», из которых
Некоторые из них предоставляются в ядре, а другие могут быть предоставлены плагинами
через сервисы api.На панели параметров кодировок
раздел под названием «Панель кодировок», вы можете настроить, какие
используются и порядок, в котором они пробуются. Вот некоторые из
детекторы кодирования, распознаваемые jEdit:
BOM :
UTF-16
иUTF-8Y
файлы определяются автоматически, потому что они начинаются с определенного фиксированного
последовательность символов. Обратите внимание, что простой UTF-8 не требует
конкретный заголовок и, следовательно, не может быть обнаружен автоматически, если только
рассматриваемый файл является файлом XML.XML-PI :
Кодировки, используемые в файлах XML с XML PI, например
следующие автоматически обнаруживаются:xml version = "1.0" encoding = "UTF-8">
html :
Кодировки, указанные в файлах HTML с атрибутомcontent =
в элементеmeta
, могут быть обнаружены автоматически:python :
У Python есть собственный способ указания кодировки в верхней части
файл.# - * - кодировка: utf-8 - * -
свойство-буфера :
Включить синтаксис локальных свойств буфера
(см. раздел «Локальные свойства буфера»)
вверху файла, чтобы указать кодировку.#: кодировка = ISO-8859-1:
Показана кодировка, которая будет использоваться для сохранения текущего буфера.
в строке состояния, и его можно изменить в
> диалоговое окно.Обратите внимание, что изменение этого параметра не имеет
влияние на содержимое буфера; если вы открыли файл с неправильным
encoding и получил мусор, нужно его перезагрузить.
> это простой способ.
Если файл открыт без явной кодировки, и он
отображается в списке последних файлов, jEdit будет использовать последнюю использованную кодировку
при работе с этим файлом; в противном случае кодировка по умолчанию будет
использовал.
Пока мир постепенно сходится на UTF-8 и UTF-16
кодировки для хранения текста, широкий спектр старых кодировок
все еще широко используются, и Java поддерживает большинство из них.
Самой простой кодировкой символов, которая все еще используется, является ASCII, или
«Американский стандартный код для обмена информацией».
ASCII кодирует латинские буквы, используемые в английском языке, в дополнение к цифрам
и ряд знаков препинания. Каждый символ ASCII состоит из
из 7 бит существует ограничение в 128 различных символов, что делает
он не подходит ни для чего, кроме английского текста. jEdit загрузится
и сохраните файлы как ASCII, если кодировка US-ASCII
используется.
Поскольку ASCII не подходит для международного использования, большинство
операционные системы используют 8-битное расширение ASCII, с первым
128 значений сопоставлены с символами ASCII, а остальные используются для
кодировать акценты, умляуты и другие эзотерические
типографские знаки. Все три основные операционные системы расширяют
ASCII по-другому. Файлы, написанные программами Macintosh, могут быть
читать в кодировке MacRoman
; Текст Windows
файлы обычно хранятся как windows-1252
.в
В мире Unix кодировка символов 8859_1
имеет
нашел широкое распространение.
В Windows различные другие кодировки, называемые
кодовых страниц , идентифицируемых по номеру, используются
для хранения неанглийского текста. Соответствующее имя кодировки Java:
windows-
, за которым следует номер кодовой страницы, для
пример windows-850
.
Многие распространенные межплатформенные международные наборы символов
также поддерживается; КОИ8_Р
для русского текста,
Big5
и GBK
для китайцев и
SJIS
для японского языка.
Локализации и кодировки символов — Руководства разработчика
Браузеры внутренне обрабатывают текст как Unicode. Однако способ представления символов в байтах (кодировка символов) используется для передачи текста по сети в браузер. Спецификация HTML рекомендует использовать кодировку UTF-8 (которая может представлять весь Юникод) и независимо от используемой кодировки требует, чтобы веб-контент объявлял, какая кодировка была использована.
Атрибут charset элемента
используется для указания кодировки символов страницы. должен использоваться в блоке
.
Чтобы указать, что страница использует, например, кодировку символов UTF-8 (согласно рекомендации), поместите следующую строку в блок
:
Когда кодировка объявлена веб-контентом, как того требует спецификация HTML, Firefox будет использовать эту кодировку для преобразования байтов во внутреннее представление. К сожалению, использование UTF-8 и объявление об использовании UTF-8 не всегда было распространенным способом предложения веб-контента.В 1990-х годах было обычным делом оставлять кодировку необъявленной и использовать кодировку, специфичную для региона, которая не могла представить весь Юникод.
Firefox нуждается в резервной кодировке, которую он использует для несовместимого устаревшего контента, который не объявляет свою кодировку. Для большинства локалей резервной кодировкой является windows-1252 (часто называемая ISO-8859-1), которая была кодировкой, испускаемой большинством приложений Windows в 1990-х годах, и надмножеством кодировки, испускаемой большинством приложений UNIX в 1990-х годах в качестве развернутой в Америке есть и в Западной Европе.Однако есть регионы, где веб-публикация была распространена уже в 1990-х годах, но кодировка windows-1252 не подходила для местного языка. В этих языковых стандартах унаследованный контент, не объявляющий свою кодировку, обычно кодируется с использованием унаследованной кодировки, отличной от windows-1252. Для работы с устаревшим контентом в некоторых локализациях Firefox требуется резервная кодировка, отличная от Windows-1252.
К сожалению, это означает, что функциональные возможности Firefox, доступные в Интернете, различаются в зависимости от локали, и трудно читать устаревший контент в разных регионах с разными резервными кодировками.Чтобы избежать появления этой проблемы в регионах, где веб-публикация стала популярной после принятия UTF-8, в регионах, в которых нет устаревшей кодировки, отличной от Windows-1252, возникшей в результате практики 1990-х годов, следует оставить резервную кодировку в Windows- 1252, чтобы облегчить чтение содержимого между языками из старых языковых стандартов, резервная кодировка которых — windows-1252. Ожидается, что контент UTF-8, созданный для новой локали, объявляет свою кодировку, и в этом случае резервная кодировка не участвует в обработке контента.
Кроме того, существует небольшое количество локалей, в которых в 1990-х годах не было очевидной единой кодировки, специфичной для региона, и в веб-браузерах было введено эвристическое обнаружение среди множества устаревших кодировок. Это привело к тому, что веб-авторы зависели от присутствия эвристического обнаружения, поэтому Firefox по-прежнему имеет эвристическое обнаружение в этих регионах.
Текст ниже относится к каноническим названиям кодировок. Канонические имена — это значения справа от знака равенства в unixcharset.характеристики.
Начиная с Firefox 28, этот раздел устарел, поскольку предпочтение intl.charset.default
больше не существует. Преобразование локалей в резервные кодировки теперь встроено в сам Gecko.
Резервная кодировка определяется параметром intl.charset.default
в intl.properties
. Он должен быть установлен на каноническое имя устаревшей кодировки, с которой пользователи локализаций, скорее всего, столкнутся при просмотре несоответствующего устаревшего веб-контента, который не объявляет свою кодировку.Обратите внимание, что резервная кодировка, определенная в предыдущем предложении, не обязательно должна иметь возможность представлять символы, необходимые для языка локализации!
Резервную кодировку следует оставить для windows-1252 для регионов Западной Европы, Северной, Центральной и Южной Америки, Африки, Центральной Азии и Океании. Как правило, для регионов Центральной и Восточной Европы, Ближнего Востока и стран Восточной Азии необходимо установить что-то другое, кроме windows-1252.
Во избежание проблемы веб-авторов, создающих новый контент UTF-8, не объявляя, что контент использует UTF-8, и для того, чтобы максимизировать способность пользователей читать контент в разных языках, не устанавливает для резервной кодировки UTF-8 для любой новой локализации. Обратите внимание, что Firefox больше не отправляет HTTP-заголовок Accept-Charset
, поэтому нет необходимости учитывать, что объявляется в Accept-Charset
при установке резервной кодировки.
Для языков, в которых в настоящее время используется резервная кодировка ISO-8859-1, ее следует изменить на windows-1252. ISO-8859-1 декодируется точно так же, как windows-1252, но Firefox переходит к обработке windows-1252 как предпочтительной метки для этой кодировки в соответствии со стандартом кодирования.
Для регионов, где Internet Explorer имеет большую долю рынка, чем Firefox, резервная кодировка обычно должна быть установлена на то же значение, что и в Internet Explorer. Вы можете увидеть резервную кодировку конкретного браузера, загрузив тестовую страницу.(Обязательно используйте установку браузера, в которой настройки оставлены по умолчанию, когда исследуете!)
Для регионов, где Firefox имеет большую долю рынка, чем Internet Explorer, вероятно, лучше не изменять резервную кодировку, даже если она не соответствует приведенным выше инструкциям. (Например, резервная кодировка для польского, венгерского и чешского языков, вероятно, должна оставаться ISO-8859-2, даже если IE имеет другую резервную кодировку.)
В случае сомнений используйте windows-1252 в качестве резервной кодировки.
Режим эвристического обнаружения определяется параметром intl.charset.detector
в intl.properties
. Параметр необходимо оставить пустым для всех языков, кроме русского, украинского и японского. Ни в коем случае не указывайте «универсальный» детектор. Это не совсем универсальный , несмотря на название!
Если локализация предназначена для языка меньшинства, и пользователи, как правило, владеют языком большинства в регионе и очень часто читают веб-контент, написанный на языке большинства, целесообразно указать резервную кодировку и режим эвристического обнаружения. То же, что и для локализации для большинства языков региона.Например, для локализации на язык меньшинств в России уместно скопировать настройки из русской локализации.
Параметр intl.charsetmenu.browser.static
в intl.properties
упрощает доступ к некоторым кодировкам символов в меню «Кодировка символов» в браузере. Значение должно быть списком канонических кодировок, разделенных запятыми. Список должен включать как минимум резервную кодировку, windows-1252 и UTF-8. Для локалей, где существует несколько распространенных устаревших кодировок, все эти кодировки должны быть включены.Например, резервная кодировка для японского языка — Shift_JIS, но есть и другие устаревшие кодировки: ISO-2022-JP и EUC-JP. Следовательно, имеет смысл использовать в списке Shift_JIS, EUC-JP, ISO-2022-JP, windows-1252, UTF-8.
Поддерживается
кодировок — Urwid 2.1.2
Urwid имеет единую глобальную настройку кодировки текста, которая устанавливается при запуске.
на основе настроенного языкового стандарта. Вы можете изменить эту настройку с помощью
set_encoding ()
метод. например.
urwid.set_encoding ("UTF-8")
Существует два различных режима обработки кодировок с помощью Urwid: Unicode или
Пройти через. Режим соответствует использованию строк Unicode или обычных строк.
в ваших виджетах.
txt_a = urwid.Text (u "Эль-Ниньо") txt_b = urwid.Text ("Эль-Ниньо")
txt_a
будет автоматически закодирован при отображении (режим Unicode).
txt_b
— предполагается, что находится в кодировке, которую ожидает пользователь, и передал
через как есть (сквозной режим).Если кодировки разные, то
пользователь увидит на экране «моджибаке» (мусор).
Единственный раз, когда имеет смысл использовать сквозной режим, — это если вы обрабатываете
кодировка, которая не выполняет обратный переход к Unicode должным образом, или если вы абсолютно
уверен, что знаешь, что делаешь.
Поддержка Unicode
Урвид имеет базовое представление о ширине символов, поэтому макет текста
код может правильно обернуть и отобразить большую часть текста. В настоящее время нет поддержки для
текст с письмом справа налево.
Вы должны иметь возможность использовать любые допустимые символы Юникода, которые присутствуют в
глобальная настройка кодировки в ваших виджетах с добавлением некоторых общих DEC
графические символы:
\ u00A3 (£), \ u00B0 (°), \ u00B1 (±), \ u00B7 (·), \ u03C0 (π), \ u2260 (≠), \ u2264 (≤), \ u2265 (≥), \ u23ba (⎺), \ u23bb (⎻), \ u23bc (⎼), \ u23bd (⎽), \ u2500 (─), \ u2502 (│), \ u250c (┌), \ u2510 (┐), \ u2514 (└), \ u2518 (┘), \ u251c (├), \ u2524 (┤), \ u252c (┬), \ u2534 (┴), \ u253c (┼), \ u2592 (▒), \ u25c6 (◆)
Если вы используете эти символы в кодировке, отличной от UTF-8, они будут отправлены с использованием
альтернативные последовательности наборов символов, поддерживаемые некоторыми терминалами.
Сквозная поддержка
Поддерживаемые кодировки для сквозного режима:
В сквозном режиме Urwid по-прежнему должен вычислять ширину символов. Для UTF-8
mode ширина указана в стандарте Unicode. Для ISO-8859- * все
байты считаются символами шириной в 1 столбец. Для остальных поддерживаемых
кодирование любого байта с установленным старшим битом считается половиной 2-столбца
широкий характер.
Дополнительные равнины в EUC в настоящее время не поддерживаются.
Работа в будущем
Кодировка текста должна быть настройкой для каждого экрана (модуля дисплея), а не глобальной
параметр. Должна быть возможность одновременно поддерживать разные кодировки на
разные экраны с Урвидом. Чтобы выполнить эту работу, возможно, потребуется изменить
сигнатура функции многих методов виджета, потому что кодировка должна быть
указывается вместе с размером и фокусом.
Кодирование, зависящее от устройства, также должно быть возможно для режима Unicode. ЖК-дисплей
модуль дисплея в разработке управляет устройством с нестандартным отображением
Код Unicode указывает на 8-битные значения, но по-прежнему можно использовать
Текст Unicode для отображения поддерживаемых им символов.
Понимание кодировки символов — GeeksforGeeks
Вы когда-нибудь представляли, как компьютер может понимать и отображать то, что вы написали? Вы когда-нибудь задумывались, что означают UTF-8 или UTF-16, когда вы проходите через некоторые конфигурации? Только подумайте, как компьютер должен интерпретировать «HeLLo WorlD».
Все мы знаем, что компьютер хранит данные в битах и байтах. Итак, для отображения символа на экране или отображения символа в виде байта в памяти компьютера необходим стандарт.Прочтите следующее:
\ x48 \ x65 \ x4C \ x4C \ x6F \ x20 \ x57 \ x6F \ x72 \ x6C \ x44
Это то, что вам покажет воспоминание. Как узнать, какой символ определяет каждый байт памяти?
Вот кодировка символов на картинке:
Если вы еще не догадались — это «HeLLo WorlD» в UTF-8 для вас. И да, мы продолжим читать о UTF-8. Но начнем с ASCII. Большинство из вас, кто занимался программированием или работал со строками, должно быть, знали, что такое ASCII.Если нет, давайте определим, что такое ASCII.
ASCII: ASCII означает Американский стандартный код для обмена информацией. Компьютеры могут понимать только числа, поэтому код ASCII — это числовое представление символа, такого как «a» или «@», или какого-либо действия. ASCII был разработан давно, и теперь непечатаемые символы редко используются по своему первоначальному назначению.
Просто посмотрите на следующее —
Шестнадцатеричный | Десятичное число | Персонаж |
---|---|---|
\ x48 | 110 | H |
\ x65 | 145 | e |
\ x4c | 114 | L |
И так далее.Вы можете посмотреть таблицу и отображение ASCII на http://www.asciitable.com/. Если вы еще не смотрели таблицу, я порекомендую вам сделать это сейчас! Вы заметите, что это простой набор английских слов и знаков препинания.
Теперь предположим, что я хочу написать следующие символы:
A
B? @
Это будет интерпретироваться моим декодером как 0x410x0a0x200x420x3f0x40 в шестнадцатеричном виде и 065010032066063064 в десятичном, где даже пробел (0x20) и следующая строка (0x0a) имеют байтовое значение или пространство памяти.
Разные страны, языки, но потребность, которая их объединила
Сегодня Интернет сблизил мир. И люди во всем мире не говорят только по-английски, верно? Возникла потребность в расширении этого пространства. Если вы создали приложение и видите, что люди во Франции хотят его использовать, поскольку вы видите в нем большой потенциал. Разве не было бы неплохо просто сменить язык, но с той же функциональностью?
Почему бы не создать универсальный код, короче Unicode для всех ??
Итак, появился Unicode с действительно хорошей идеей.Каждому символу, в том числе на разных языках, был присвоен уникальный номер, называемый Code Point. Одним из преимуществ Unicode перед другими возможными наборами является то, что его первые 256 кодовых точек идентичны ASCII. Таким образом, для программного обеспечения / браузера проще кодировать и декодировать символы большинства живых языков, используемых на компьютерах. Он стремится быть и в значительной степени уже является надмножеством всех других кодированных наборов символов.
Юникод также является набором символов (не кодировкой).Он использует те же символы, что и стандарт ASCII, но расширяет список дополнительными символами, что дает каждому символу точку кода. Он стремится содержать всех персонажей (и популярных иконок), используемых во всем мире.
Прежде чем их узнать, давайте сразу разберемся с терминологией :
- Символ — это минимальная единица текста, имеющая семантическое значение.
- Набор символов — это набор символов, которые могут использоваться в нескольких языках.Пример: набор латинских символов используется в английском и большинстве европейских языков, хотя набор символов греческого языка используется только в греческом языке.
- Кодированный набор символов — это набор символов, в котором каждый символ соответствует уникальному номеру.
- Кодовая точка набора кодированных символов — это любое допустимое значение в наборе символов.
- Кодовая единица — это битовая последовательность, используемая для кодирования каждого символа репертуара в заданной форме кодирования.
Вы когда-нибудь задумывались, что такое UTF-8 или UTF-16 ??
UTF-8: UTF-8 действительно была доминирующей кодировкой символов во всемирной паутине с 2009 года, и по состоянию на июнь 2017 года насчитывает 89 символов.4% всех веб-страниц. UTF-8 кодирует каждую из 1112 064 действительных кодовых точек в Unicode, используя от одного до четырех 8-битных байтов. Точки кода с более низкими числовыми значениями, которые, как правило, встречаются чаще, кодируются с использованием меньшего количества байтов. Первые 128 символов Unicode, которые взаимно однозначно соответствуют ASCII, кодируются с использованием одного октета с тем же двоичным значением, что и ASCII, так что действительный текст ASCII также является действительным Unicode в кодировке UTF-8.
Так сколько байтов к каким символам дают доступ в этих кодировках?
UTF-8:
1 байт: стандартный ASCII
2 байта: арабский, иврит, большинство европейских сценариев (в первую очередь, за исключением грузинского)
3 байта: BMP
4 байта: все символы Unicode
UTF-16:
2 байта: BMP
4 байта: все символы Unicode
Итак, я упомянул BMP.Что это такое?
Basic Multilingual Plane (BMP) содержит символы почти всех современных языков и большое количество символов. Основная цель BMP — поддержка унификации предшествующих наборов символов, а также символов для письма.
UTF-8, UTF-16 и UTF-32 — это кодировки, которые применяют таблицу символов Юникода. Но у каждого из них есть немного другой способ их кодирования. UTF-8 будет использовать только 1 байт при кодировании символа ASCII, давая тот же результат, что и любая другая кодировка ASCII.Но для других символов он будет использовать первый бит, чтобы указать, что за ним последует второй байт. UTF-16 по умолчанию использует 16-битный формат, но это дает вам только 65 тысяч возможных символов, что далеко не достаточно для полного набора Unicode. Поэтому некоторые символы используют пары 16-битных значений. UTF-32 наоборот, он использует большую часть памяти (каждый символ имеет фиксированную ширину 4 байта), что делает его довольно раздутым, но теперь в этом сценарии каждый символ имеет эту точную длину, поэтому манипуляции со строками становятся намного проще. Вы можете вычислить количество символов в строке, просто исходя из длины строки в байтах.Вы не можете этого сделать с UTF-8. Вот как он упрощает размещение всего набора символов для разных языков и помогает людям распространять свои приложения или информацию в мире, просто кодируя / записывая на своем языке, остальное все заботится о Декодер.
Поскольку это только начало в мире кодирования символов. Надеюсь, это поможет вам понять кодировку символов на более высоком уровне.
Автор статьи Deepa Banerjee . Если вам нравится GeeksforGeeks, и вы хотите внести свой вклад, вы также можете написать статью, используя свой вклад.geeksforgeeks.org или отправьте свою статью по адресу [email protected]. Посмотрите, как ваша статья появляется на главной странице GeeksforGeeks, и помогите другим гикам.
Пожалуйста, напишите комментарий, если вы обнаружите что-то неправильное, или если вы хотите поделиться дополнительной информацией по теме, обсужденной выше.
.