|
0 / 0 / 0
Регистрация: 27.06.2020
Сообщений: 10
|
|
Выведите строки, содержащие обратный слеш "\"27.06.2020, 21:01. Показов 9124. Ответов 12
Метки нет (Все метки)
0
|
|
| 27.06.2020, 21:01 | |
|
Ответы с готовыми решениями:
12
Обратный слеш
Обратный слеш: в чем специфика? |
|
0 / 0 / 1
Регистрация: 18.05.2020
Сообщений: 10
|
||||||
| 28.06.2020, 00:55 | ||||||
Сообщение было отмечено mik-a-el как решение
Решение
0
|
||||||
| 28.06.2020, 02:22 | |||||||||||
Redavoi, Из условия не понятно, в каком виде хранятся строки. Если это строки в файле, то они все содержат как минимум один символ \ в конце строки \n . Если эти символы не учитывать, то их нужно убирать, прежде чем искать нужные строки. Добавлено через 5 минут Убрать символы конца строки можно с помощью str.rstrip()
0
|
|||||||||||
|
19530 / 11067 / 2931
Регистрация: 21.10.2017
Сообщений: 23,294
|
|
| 28.06.2020, 08:54 | |
|
3
|
|
|
Просто Лис
|
|||||||
| 28.06.2020, 10:13 | |||||||
3
|
|||||||
|
19530 / 11067 / 2931
Регистрация: 21.10.2017
Сообщений: 23,294
|
|
| 28.06.2020, 11:07 | |
|
1
|
|
| 28.06.2020, 16:50 | ||||||||||||||||||||||
|
Лутц М. Программирование на Python. Том 1 (4-е издание, 2011) стр. 224-228 Лутц М. Изучаем Python (4-е издание, 2011) стр. 1023 Приведу только частичные выдержки из его книг. Кликните здесь для просмотра всего текста
"о историческим причинам конец строки текста в файле представляется на разных платформах различными символами. В Unix и Linux – это одиночный символ \n, а в Windows – это последовательность из двух символов \r\n. В результате файлы, перемещаемые между Linux и Windows, могут после передачи странно выглядеть в текстовом редакторе – они могут сохранить окончание строки, принятое на исходной платформе. Например, большинство текстовых редакторов для Windows обрабатывает текст в формате Unix, но Блокнот (Notepad) составляет заметное исключение – текстовые файлы, скопированные из Unix или Linux, обычно выглядят в Блокноте, как одна большая строка со странными символами внутри (\n). Точно так же при копировании файлов из Windows в Unix в двоичном режиме в них сохраняется символ \r (который в текстовых редакторах часто отображается как ^M).
Сценариям на языке Python это обычно безразлично, потому что объекты файлов автоматически отображают последовательность DOS \r\n в одиночный символ \n. При выполнении сценариев в Windows это действует так: • Для файлов, открытых в текстовом режиме, при чтении \r\n преобразуется в \n. • Для файлов, открытых в текстовом режиме, при записи \n преобразуется в \r\n. • Для файлов, открытых в двоичном режиме, никакие преобразования не производятся. Следует запомнить два важных следствия из этих правил. Во-первых, почти всегда во всех сценариях на языке Python символ конца строки представляется одиночным \n, независимо от способа его сохранения во внешних файлах на соответствующей платформе. Путем соответствующего преобразования \n при чтении и записи Python скрывает присущие платформам различия. Второе следствие из этого преобразования более тонкое: при обработке двоичных файлов использование двоичного режима (например, rb, wb) отключает механизм преобразования символов конца строки. Если выбрать неправильный режим, указанные преобразования вполне могут повредить данные, как при чтении, так и при записи, – случайно оказавшиеся среди двоичных данных байты \r могут быть ошибочно отброшены при чтении или ошибочно добавлены к байтам \n при записи. В итоге двоичные данные окажутся искаженными, что, вероятно, совсем не то, что вам хотелось бы получить при работе с изображениями или аудиоклипами! В Python 3.X эта проблема ушла на задний план, потому что мы в принципе не можем использовать двоичные данные с файлами, открытыми в текстовом режиме, из-за того, что текстовый режим предполагает автоматическое применение кодировок Юникода к содержимому файлов. Операции чтения и записи просто будут терпеть неудачу, если данные не смогут быть декодированы при чтении или закодированы при записи. Использование двоичного режима позволяет избежать ошибок, связанных с преобразованием Юникода, и автоматически запрещает преобразование символов конца строки как таковое (ошибки, связанные с преобразованием Юникода, можно было бы перехватывать в инструкции try). Итак, стоит запомнить как отдельный факт, что двоичный режим предохраняет двоичные данные от искажения в результате преобразования символов конца строки, особенно если вы работаете только с текстовыми данными ASCII, когда можно смело забыть обо всех проблемах, связанных с Юникодом. При записи в двоичном режиме, напротив, предотвращаются любые преобразования, как и предполагалось, даже когда данные содержат байты, которые в текстовом режиме интерпретировались бы как часть символов конца строки (при выводе строк байтов отдельные байты выводятся как символы ASCII, если они соответствуют печатаемым символам, и как экранированные шестнадцатеричные последовательности в противном случае):
При записи в двоичном режиме, напротив, предотвращаются любые преобразования, как и предполагалось, даже когда данные содержат байты, которые в текстовом режиме интерпретировались бы как часть символов конца строки (при выводе строк байтов отдельные байты выводятся как символы ASCII, если они соответствуют печатаемым символам, и как экранированные шестнадцатеричные последовательности в противном случае):
"Проще говоря, запомните, что во всех текстовых файлах при определении конца строки следует ориентироваться на символ \n, а двоичные файлы всегда должны открываться в двоичном режиме, чтобы предотвратить преобразование символов конца строки и кодирование/ декодирование символов Юникода. Вообще тип содержимого файла определяется режимом его открытия, а режимы открытия определяют способы обработки содержимого, что в точности соответствует нашим желаниям." Как видите все не так просто. Поэтому я и обратил внимание на то, что важно в каком виде мы рассматриваем в условии строки.
0
|
||||||||||||||||||||||
|
19530 / 11067 / 2931
Регистрация: 21.10.2017
Сообщений: 23,294
|
|
| 28.06.2020, 17:15 | |
|
1
|
|
| 28.06.2020, 18:34 | ||
|
Ладно, делайте как хотите. Я задачи с нечеткими условиями не решаю.
0
|
||
| 28.06.2020, 20:58 | |||||||||||||||||
Пример2:
Экранированные последовательности, это как раз тот случай, когда слэш не воспринимается как самостоятельный символ. Пример:
0
|
|||||||||||||||||
|
Просто Лис
|
||||||
| 29.06.2020, 05:04 | ||||||
|
Viktorrus, я не знаю, что вы пытаетесь доказать себе (или нам).
0
|
||||||
| 29.06.2020, 10:35 | ||
Вы сами до фантазировали условие задачи , какие обратные слэши нужно искать. Удачи!
0
|
||
| 29.06.2020, 10:35 | |
|
Помогаю со студенческими работами здесь
13
Как напечать обратный слеш? Заменить обратный слеш на обычный
Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Модель заражения группы наркоманов
alhaos 17.04.2026
Условия задачи сформулированы тут
Суть:
- Группа наркоманов из 10 человек.
- Только один инфицирован ВИЧ.
- Колются одной иглой.
- Колются раз в день.
- Колются последовательно через. . .
|
Мысли в слух. Про "навсегда".
kumehtar 16.04.2026
Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .
|
My Business CRM
MaGz GoLd 16.04.2026
Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .
|
Знаешь почему 90% людей редко бывают счастливыми?
kumehtar 14.04.2026
Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . .
а удачный момент так и не приходит.
|
|
Фиксация колонок в отчете СКД
Maks 14.04.2026
Фиксация колонок в СКД отчета типа Таблица.
Задача: зафиксировать три левых колонки в отчете.
Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)
/ / . . .
|
Настройки VS Code
Loafer 13.04.2026
{
"cmake. configureOnOpen": false,
"diffEditor. ignoreTrimWhitespace": true,
"editor. guides. bracketPairs": "active",
"extensions. ignoreRecommendations": true,
. . .
|
Оптимизация кода на разграничение прав доступа к элементам формы
Maks 13.04.2026
Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2.
Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива.
Было так:. . .
|
Контроль заполнения и очистка дат в зависимости от значения перечислений
Maks 12.04.2026
Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2.
Задача: реализовать контроль корректности заполнения дат назначения. . .
|