код переноса строки unicode
Кодировки и окончания строк
В Visual Studio следующие символы интерпретируются как разрывы строк:
CR LF: возврат каретки + перевод строки, символы Юникода 000D + 000A
LF: перевод строки, символ Юникода 000A
NEL: следующая строка, символ Юникода 0085
LS: разделитель строки, символ Юникода 2028
PS: разделитель абзаца, символ Юникода 2029
Для текста, который копируется из других приложений, сохраняется исходная кодировка и символы разрыва строки. Например, при копировании текста из Блокнота и вставке его в текстовый файл в Visual Studio текст имеет те же параметры, которые применялись в Блокноте.
При открытии файла, который содержит разные символы разрыва строки, может появиться диалоговое окно с запросом о том, следует ли нормализовать несогласованные символы разрыва строки и какой тип разрыва строки выбрать.
Дополнительные параметры сохранения
Чтобы определить тип символов разрыва строки, можно использовать параметры в диалоговом окне Файл > Дополнительные параметры сохранения. Кроме того, с помощью этих параметров можно изменить кодировку файла.
Если в меню Файл пункт Дополнительные параметры сохранения отсутствует, его можно добавить.
Кроме того, чтобы открыть диалоговое окно Дополнительные параметры сохранения, можно выбрать пункт меню Файл > Сохранить как. В диалоговом окне Сохранить файл как щелкните треугольник раскрывающегося списка рядом с кнопкой Сохранить и выберите пункт Сохранить с кодировкой.
Перевод строки
Перевод строки, или разрыв строки — продолжение печати текста с новой строки, то есть с левого края на строку ниже, или уже на следующей странице.
Разделителем строк, обозначающим место перевода строки, в текстовых данных служит один или пара управляющих символов, а в размеченном тексте также — определённый тег (в HTML — тег
, от англ. break — «разрыв»). Разделитель строк также называют просто переводом строки, когда нет надобности их различать.
Вместе с другими действиями перевод строки выполняется также перед следующим абзацем или страницей.
Содержание
Терминология
Таким образом, вывод последовательности CR+LF в семантике терминала гарантирует действие «создание новой строки».
Терминалы (и их эмуляторы) могут также проводить различные преобразования символов (например, LF → CR+LF, CR → CR+LF) при вводе и выводе текста.
Жёсткий возврат, иногда аппаратный возврат — разделитель строк, поставленный пользователем.
Мягкий возврат — перевод строки, выполненный текстовым процессором в том месте текста, которое им выбрано. Мягкий возврат является разделителем строк для текстового процессора и не является таковым для пользователя.
В ASCII
Системы, основанные на ASCII или совместимом наборе символов, используют или LF (перевод строки, 0x0A), или CR (возврат каретки, 0x0D) по отдельности, или последовательность CR+LF; см. ниже историческую причину для соглашения CR+LF. Эти названия основаны на командах принтера: перевод строки означает, что одна строка на бумаге должна быть перенесена при печати, а возврат каретки означает, что каретка печатающего устройства должна вернуться к началу текущей строки.
В Юникоде
По стандарту, любое совместимое с Юникодом приложение должно воспринимать как перевод строки каждый из нижеследующих символов:
Трудности
Нет общепринятых сокращений русских терминов. ВК (Возврат Каретки) совпадает по написанию с сокращением от англ. BreaK («разрыв [строки]», — то же, что перевод строки), а ПС не различает Подачу Строки и Перевод Строки.
Разница представлений
Перевод строки при вводе с клавиатуры представлен единообразно во всех системах — символом CR, и в системах с другим представлением перевода строки текстовые данные приходится перекодировать.
Последняя строка
История
На перфокартных системах хранения данных одна строка записывалась на одну перфокарту, поэтому строка была заданной длины, по количеству колонок (обычно 80). Строки короче добивались пробелами, а строки длиннее обрезались. Разделителя строк не было, а неявный перевод строки предполагался через каждые 80 символов. Некоторые ранние мейнфреймовые операционные системы переняли это для хранения текста в файлах, где уже не было естественного ограничения на длину строки.
На механических пишущих машинках был рычаг, который возвращал каретку к левому краю страницы и прокручивал вал, подвигая бумагу вверх на строку. На телетайпах и более поздних алфавитно-цифровых печатающих устройствах (АЦПУ) вместо каретки была головка, в лазерных принтерах она перестала быть материальной, но в термине возврат каретки всё это продолжали называть кареткой, чтобы его не менять. На телетайпах возврат каретки и подачу строки разделили, откуда традиция представления перевода строки как CR+LF перешла и к текстовым файлам.
Конец строки
Телетайпы сначала печатали на рулонной бумаге, и сообщения начинали и заканчивали переводом строки, чтобы каждое начиналось с новой строки наверняка. Отсюда пошёл обычай включать разделитель сообщений в состав самого сообщения.
На компьютерах появился диалоговый режим работы, когда поочерёдно печатались вводимые управляющие сообщения пользователя и ответные программные сообщения. Пользователь после сообщения всегда переводил строку, так как одновременно это означало команду к исполнению, а вот программы после своего сообщения строку иногда не переводили, несмотря на предписание. Устройство вывода изначально не было приспособлено к тому, чтобы терминал мог следить за переводами строк, и реализовать это было трудно, поэтому чтобы ввод пользователя начинался с новой строки наверняка, управляющий диалогом терминал после программного сообщения переводил строку тоже. Помещать перевод строки предписывалось и в конце текстового файла.
Забота о разделении сообщений легла на терминал, и думать об этом перестали, а перевод строки в конце текста переосмыслился как конец последней строки, вместе с чем как концы строк переосмыслились и вообще все переводы строк, чему способствовало удобство работы с регулярно завершёнными строками с точки зрения программирования, сродни нуль-терминированным строкам. Так обычай включать разделитель сообщений в состав сообщения перешёл в обычай включать разделитель строк в состав строки.
Лишняя строка в конце файла обычно не представляет хлопот, поэтому перевод строки до сих пор называют концом строки, а разделитель строк — символом конца строки (EOL, англ. end of line ).
Перетекание разделителя в завершитель и обратно бывает не только у перевода строки. Так, точка с запятой в языке Си команды завершает, а в Паскале их разделяет. В письменной речи после нескольких предложений точку почти всегда ставят, а после одиночного — чаще нет. Это колебание хорошо видно в списках, где одиночные предложения иногда начинают с большой буквы, а иногда — с маленькой.
Абзац
На телетайпах, а потом и в первых редакторах разделение текста на абзацы не имело своего особого представления, для этого использовали пустые строки или отступ из нескольких пробелов, а переводы строки внутри абзаца проставляли вручную.
Позже в редакторах появился автоматический перенос, выполняемый на лету при отрисовке текста каждый раз заново. Для отличения от ручного его назвали мягким возвратом, а ручной — жёстким (перенос называли и просто возвратом, см. раздел Разница представлений). Разделитель строк при этом переносил как раньше, но приобрёл смысл ещё и разделителя абзацев — для тех строк, в которых срабатывал автоперенос и которые становились при этом абзацами. Включатель такого режима назвали переносом по словам (англ. word wrap ). При автопереносе ручной перенос разрывал абзац, межабзацный интервал делался как раньше (в новых терминах — перемежением пустым абзацем), но основное качество абзаца — независимость от разбиения на строки — было достигнуто.
Режим автопереноса включался и выключался пользователем вручную, определить это программно было трудно, то есть, избавившись от ручного переноса, получили другую ручную операцию. Стало понятно, что не обойтись без более автоматизирующего разнесения разделителя строк и разделителя абзацев, то есть для них понадобились два разных символа.
Чтобы не заботиться о совместимости с уже существующим в ASCII разделителем строк/абзацев, разработчики не стали использовать символы ASCII для разделителя строк и разделителя абзацев. В HTML использовали теги
и
, в Юникоде — символы U+2028 и U+2029, соответственно. В Википедии абзацы можно разделять пустыми строками, отображаемыми при этом полноценным интервалом.
Очень странные вещи c Java Characters
Тайна ошибки комментария и другие истории.
Вступление
Знаете ли вы, что следующее является допустимым выражением Java?
Вы можете попробовать скопировать и вставить его в основной метод любого класса и скомпилировать. Если вы затем добавите следующий оператор
и после компиляции запустите этот класс, код напечатает число 8!
А знаете ли вы, что этот комментарий вместо этого вызывает синтаксическую ошибку во время компиляции?
Тем не менее, комментарии не должны приводить к синтаксическим ошибкам. Фактически, программисты часто комментируют фрагменты кода, чтобы компилятор их игнорировал. так что же происходит?
Примитивный тип данных char
Как всем известно, char это один из восьми примитивных типов Java. Это позволяет нам хранить по одному символу. Ниже приведен простой пример, в котором значение символа присваивается типу char :
На самом деле этот тип данных используется нечасто, потому что в большинстве случаев программистам нужны последовательности символов и поэтому они предпочитают строки. Каждое буквальное значение символа должно быть заключено между двумя одинарными кавычками, чтобы не путать с двойными кавычками, используемыми для строковых литералов. Объявление строки:
используя один печатный символ на клавиатуре (например ‘&’ ).
используя специальный escape-символ (например, ‘\n’ который указывает символ перевода строки).
Давайте добавим некоторые детали в следующих трех разделах.
Печатаемые символы клавиатуры
Мы можем назначить любой символ, найденный на нашей клавиатуре, char переменной, при условии, что наши системные настройки поддерживают требуемый символ и что этот символ доступен для печати (например, клавиши «Canc» и «Enter» не печатаются).
Тип данных char хранится в 2 байтах (16 бит), а диапазон состоит только из положительных чисел от 0 до 65 535. Фактически, существует «отображение», которое связывает определенный символ с каждым числом. Это отображение (или кодирование) определяется стандартом Unicode (более подробно описанным в следующем разделе).
Формат Unicode (шестнадцатеричное представление)
Мы можем напрямую присвоить Unicode char значение в шестнадцатеричном формате, используя 4 цифры, которые однозначно идентифицируют данный символ, добавляя к нему префикс \u (всегда в нижнем регистре). Например:
В данном случае мы говорим о литерале в формате Unicode (или литерале в шестнадцатеричном формате). Фактически, при использовании 4 цифр в шестнадцатеричном формате охватывается ровно 65 536 символов.
Специальные escape-символы
В char типе также можно хранить специальные escape-символы, то есть последовательности символов, которые вызывают определенное поведение при печати:
\b эквивалентно backspace, отмене слева (эквивалентно клавише Delete).
\n эквивалентно переводу строки (эквивалентно клавише Ente).
\\ равняется только одному \ (только потому, что символ \ используется для escape-символов).
\t эквивалентно горизонтальной табуляции (эквивалентно клавише TAB).
\’ эквивалентно одинарной кавычке (одинарная кавычка ограничивает литерал символа).
\» эквивалентно двойной кавычке (двойная кавычка ограничивает литерал строки).
\r представляет собой возврат каретки (специальный символ, который перемещает курсор в начало строки).
\f представляет собой подачу страницы (неиспользуемый специальный символ, представляющий курсор, перемещающийся на следующую страницу документа).
Обратите внимание, что присвоение литерала ‘»‘ символу совершенно законно, поэтому следующий оператор:
что эквивалентно следующему коду:
правильно и напечатает символ двойной кавычки:
Если бы мы попытались не использовать escape-символ для одиночных кавычек, например, со следующим утверждением:
мы получим следующие ошибки времени компиляции, поскольку компилятор не сможет различить разделители символов:
Поскольку разделители строковых литералов представлены в двойных кавычках, ситуация обратная. Фактически, внутри строки можно заключить одинарные кавычки:
С другой стороны, мы должны использовать \» escape-символ, чтобы использовать двойные кавычки в строке. Итак, следующее утверждение:
вызовет следующие ошибки компиляции:
Вместо этого верна следующая инструкция:
Написание Java кода в формате Unicode
Литеральный формат Unicode также можно использовать для замены любой строки нашего кода. Фактически, компилятор сначала преобразует формат Unicode в символ, а затем оценивает синтаксис. Например, мы могли бы переписать следующий оператор:
Фактически, если мы добавим к предыдущей строке следующий оператор:
Несомненно, это бесполезный способ написания нашего кода. Но может быть полезно знать эту функцию, поскольку она позволяет нам понять некоторые ошибки, которые (редко) случаются.
Формат Unicode для escape-символов
мы получим следующую ошибку времени компиляции:
В реальности, компилятор преобразует предыдущий код в следующий перед его оценкой:
Формат Unicode был преобразован в символ новой строки, и предыдущий синтаксис не является допустимым синтаксисом для компилятора Java.
Также в этом случае компилятор преобразует предыдущий код следующим образом:
что приведет к следующим ошибкам времени компиляции:
Первая ошибка связана с тем, что первая пара кавычек не содержит символа, а вторая ошибка указывает на то, что указание третьей одинарной кавычки является незакрытым символьным литералом.
мы получим следующую ошибку времени компиляции:
Фактически, компилятор преобразовал число в формате Unicode в возврат каретки, вернув курсор в начало строки, и то, что должно было быть второй одинарной кавычкой, стало первой.
мы получим следующую ошибку времени компиляции:
Это потому, что предыдущий код будет преобразован в следующий:
и поэтому пара символов ‘ рассматривается как escape-символ, соответствующий одинарной кавычке, и поэтому в буквальном закрытии отсутствует другая одинарная кавычка.
проблем не будет. Но если мы используем этот символ внутри строки:
мы получим следующую ошибку времени компиляции:
поскольку предыдущий код будет преобразован в следующий:
Тайна ошибки комментария
Еще более странная ситуация возникает при использовании однострочных комментариев для форматов Unicode, таких как возврат каретки или перевод строки. Например, несмотря на то, что оба следующих оператора закомментированы, могут возникнуть ошибки во время компиляции!
Это связано с тем, что компилятор всегда преобразует шестнадцатеричные форматы с помощью символов перевода строки и возврата каретки, которые несовместимы с однострочными комментариями; они печатают символы вне комментария!
Чтобы разрешить ситуацию, используйте обозначение многострочного комментария, например:
Выводы
В этой статье мы увидели, что использование типа char в Java скрывает некоторые действительно удивительные особые случаи. В частности, мы увидели, что можно писать код Java, используя формат Unicode. Это связано с тем, что компилятор сначала преобразует формат Unicode в символ, а затем оценивает синтаксис. Это означает, что программисты могут находить синтаксические ошибки там, где они никогда не ожидали, особенно в комментариях.
Примечание автора: эта статья представляет собой короткий отрывок из раздела 3.3.5 «Примитивные символьные типы данных» тома 1 моей книги «Java для пришельцев». Для получения дополнительной информации посетите сайт книги (вы можете загрузить раздел 3.3.5 из области «Примеры»).
Вставка символов и знаков на основе латинского алфавита в кодировке ASCII или Юникод
С помощью кодировок символов ASCII и Юникода можно хранить данные на компьютере и обмениваться ими с другими компьютерами и программами. Ниже перечислены часто используемые латинские символы ASCII и Юникода. Наборы символов Юникода, отличные от латинских, можно посмотреть в соответствующих таблицах, упорядоченных по наборам.
В этой статье
Вставка символа ASCII или Юникода в документ
Если вам нужно ввести только несколько специальных знаков или символов, можно использовать таблицу символов или сочетания клавиш. Список символов ASCII см. в следующих таблицах или статье Вставка букв национальных алфавитов с помощью сочетаний клавиш.
Многие языки содержат символы, которые не удалось сжатить, в 256-символьный набор extended ACSII. Таким образом, существуют варианты ASCII и Юникода, которые должны включать региональные символы и символы, и см. таблицы кодов символов Юникода по сценариям.
Если у вас возникают проблемы с вводом кода необходимого символа, попробуйте использовать таблицу символов.
Вставка символов ASCII
Чтобы вставить символ ASCII, нажмите и удерживайте клавишу ALT, вводя код символа. Например, чтобы вставить символ градуса (º), нажмите и удерживайте клавишу ALT, затем введите 0176 на цифровой клавиатуре.
Для ввода чисел используйте цифровую клавиатуру, а не цифры на основной клавиатуре. Если на цифровой клавиатуре необходимо ввести цифры, убедитесь, что включен индикатор NUM LOCK.
Вставка символов Юникода
Чтобы вставить символ Юникода, введите код символа, затем последовательно нажмите клавиши ALT и X. Например, чтобы вставить символ доллара ($), введите 0024 и последовательно нажмите клавиши ALT и X. Все коды символов Юникода см. в таблицах символов Юникода, упорядоченных по наборам.
Важно: Некоторые программы Microsoft Office, например PowerPoint и InfoPath, не поддерживают преобразование кодов Юникода в символы. Если вам необходимо вставить символ Юникода в одной из таких программ, используйте таблицу символов.
Если после нажатия клавиш ALT+X отображается неправильный символ Юникода, выберите правильный код, а затем снова нажмите ALT+X.
Кроме того, перед кодом следует ввести «U+». Например, если ввести «1U+B5» и нажать клавиши ALT+X, отобразится текст «1µ», а если ввести «1B5» и нажать клавиши ALT+X, отобразится символ «Ƶ».
Использование таблицы символов
Таблица символов — это программа, встроенная в Microsoft Windows, которая позволяет просматривать символы, доступные для выбранного шрифта.
С помощью таблицы символов можно копировать отдельные символы или группу символов в буфер обмена и вставлять их в любую программу, поддерживающую отображение этих символов. Открытие таблицы символов
В Windows 10 Введите слово «символ» в поле поиска на панели задач и выберите таблицу символов в результатах поиска.
В Windows 8 Введите слово «символ» на начальном экране и выберите таблицу символов в результатах поиска.
В Windows 7: Нажмите кнопку Пуск, а затем последовательно выберите команды Программы, Стандартные, Служебные и Таблица знаков.
Знаки группются по шрифтам. Щелкните список шрифтов, чтобы выбрать набор символов. Чтобы выбрать символ, щелкните его, нажмите кнопку «Выбрать», щелкните в документе правую кнопку мыши в том месте, где он должен быть, а затем выберите «Вировать».
Этот день мы приближали, как могли — блокнот в Windows 10 стал понимать юниксовый перевод строки
Notepad в windows 10 начал понимать юниксовый перевод строки, а не только формат Windows.
С проблемой «каши» вместо удобочитаемого текста десятилетиями сталкивались те, кто пытался открыть в среде Windows текстовые документы, подготовленные на других операционных системах. Теперь же всё в одночасье изменяется. И это изменение столь же мало, сколь и эпично по своим практическим результатам и идеологическим последствиям. Microsoft вновь пытается играть в кросс-интеграцию и поддержку открытых стандартов.
Долгие годы Windows Блокнот мог нормально отображать только те текстовые документы, которые содержали символы начала новой строки в формате Windows End of Line (EOL) — «возврат каретки» (CR) и «подача на строку» (LF). На деле это приводило к тому, что Notepad не смог правильно отобразить содержимое текстовых файлов, созданных в Unix, Linux и macOS, где в качестве признака конца строки использовался только символ LF.
Обратите внимание, что строка состояния указывает обнаруженный формат EOL текущего открытого файла.
Так же для гибкого управления новой возможностью в разделе реестра [HKEY_CURRENT_USER\Software\Microsoft\Notepad] вводятся два дополнительных ключа:
По накалу страстей спор о способе начала новой строки в электронных документах сравним со спором о пробелах и табуляциях в исходных текстах программ. У этого противостояния «за строку» было много причин, как лежащих в области древних стандартов и традиций, так и берущих свои корни в особенностях конструкции печатных машин и телетайпов. Не меньшую роль сыграло и стремление одних программистов буквально выполнять (интерпретировать) команды и управляющие символы, а других — следовать здравому смыслу.
Что мы можем узнать о проблеме из Википедии
Исторически на механических пишущих машинках был рычаг, который возвращал каретку к левому краю страницы и прокручивал вал, подвигая бумагу вверх на строку. На телетайпах и более поздних алфавитно-цифровых печатающих устройствах (АЦПУ) вместо каретки была головка, в лазерных принтерах она перестала быть материальной, но в термине возврат каретки всё это продолжали называть кареткой, чтобы его не менять. На телетайпах возврат каретки и подачу строки разделили, откуда традиция представления перевода строки как CR+LF перешла и к текстовым файлам.
Системы, основанные на ASCII или совместимом наборе символов, используют или LF (перевод строки, 0x0A), или CR (возврат каретки, 0x0D) по отдельности, или последовательность CR+LF. Эти названия основаны на командах принтера: перевод строки означает, что одна строка на бумаге должна быть перенесена при печати, а возврат каретки означает, что каретка печатающего устройства должна вернуться к началу текущей строки.
Но как известно, стандарты стандартами, а реализации у всех часто выходят разными. И масла в огонь подливает необходимость корректно отображать унаследованные документы, созданные до эпохи юникода. Отсутствие единого общепринятого представления перевода строки в разных операционных системах надолго осложнило обмен текстовыми данными между ними.
Юникод старается примирить эту разницу, уравнивая CR, LF и CR+LF, однако вступает в противоречие с наследуемым им ASCII при трактовке последовательности LF+CR, не предварённой CR: согласно ASCII это один перевод строки, а согласно Юникоду — два.