Недопустимые символы в теле сообщения: Ошибка «недопустимые символы» при синхронизации файлов из проводника Windows с OneDrive

Ошибка «недопустимые символы» при синхронизации файлов из проводника Windows с OneDrive

Проблема

При использовании Microsoft OneDrive для работы или учебного заведения (прежнее название — Microsoft SkyDrive Pro) для синхронизации файлов из проводника Windows с сайтом Microsoft SharePoint некоторые файлы могут синхронизироваться неправильно. Вместо этого отображается красный крестик на значке файла в проводнике Windows, и вы получаете одно из указанных ниже проблем.

1. В центре отправки Microsoft Office появляется следующее сообщение об ошибке: »

   не удалось выполнить
   отправку» Недопустимые символы

2. В OneDrive. Проблемы с синхронизацией отображаются в области уведомлений. При нажатии кнопки Показать проблемы с синхронизациейпоявится следующее сообщение:

   элемент X не может быть синхронизирован с OneDrive.

   Примечание. X — количество файлов, которые OneDrive пытается синхронизироваться.

   В столбце Error (ошибка) также присутствует следующее сообщение:

   это имя файла содержит недопустимые символы.

ПРИМЕЧАНИЕ. Эта проблема возникает, если вы синхронизируете файлы с Microsoft Microsoft 365 SharePoint Online или Microsoft SharePoint Server 2013.

Решение

Чтобы устранить эту проблему, удалите недопустимые символы из имени файла в проводнике Windows, который вы пытаетесь отправить на сайт SharePoint. 

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

После удаления неподдерживаемых символов из имени файла он синхронизируется с OneDrive.

Дополнительные сведения

Эта проблема возникает из-за того, что в OneDrive не поддерживаются символы, указанные в разделе «решение».

Дополнительные сведения о OneDrive ах можно найти в разделе что такое OneDrive? 

Все еще нужна помощь? Перейдите в сообщество Майкрософт.

Ошибки и предупреждения. API Яндекс.Директа. Версия 5

Код ошибки	Текст сообщения	Комментарий, возможные причины
52	Сервер авторизации временно недоступен	Сервер API Директа временно не может получить информацию от сервиса Яндекс.OAuth. Попробуйте вызвать метод через некоторое время.
1000	Сервер временно недоступен	Внутренняя ошибка сервера API Директа. Попробуйте вызвать метод через некоторое время. При повторении ошибки обратитесь в службу поддержки.
1001	Ошибка инициализации сервиса
1002	Ошибка операции
1003	Не удалось создать учетную запись пользователя на Яндексе	При создании учетной записи произошла ошибка. Попробуйте вызвать метод через некоторое время.
1004	Не удалось создать клиента	При создании клиента в Директе произошла ошибка. Попробуйте вызвать метод через некоторое время. При повторном вызове используйте другой логин.
1020	Внутренняя ошибка сервера	Список доступных валют не определен. Обратитесь в службу поддержки.
53	Ошибка авторизации	Указан недействительный OAuth-токен. Причины, по которым токен становится недействительным, перечислены в разделе Отзыв токенов документации Яндекс.OAuth.
58	Незавершенная регистрация	Необходимо создать заявку на доступ к API и дождаться ее подтверждения.
54	Нет прав	Рекламодатель, чей логин указан в запросе, не является клиентом агентства, от имени которого выполняется запрос. Пользователь, от имени которого выполняется запрос на запись/редактирование, имеет право только на чтение данных. Аккаунт рекламодателя необходимо перевести в валюту. В запросе к сервису AgencyClients указан токен, полученный для представителя рекламодателя.
513	Ваш логин не подключен к Яндекс.Директу	Пользователь, от имени которого выполняется запрос, не имеет аккаунта в Директе. Для регистрации аккаунта необходимо создать от имени пользователя рекламную кампанию в веб-интерфейсе. См. также раздел Доступ и авторизация.
3000	Нет доступа к API	У пользователя, от имени которого выполняется запрос, нет доступа к API. Доступ к API закрыт на время перевода кампаний в валюту. Пользователь не разрешил доступ к API с данного IP-адреса. См. раздел Ограничение доступа по IP-адресу.
3001	Нет доступа к методу	Доступ к методу AgencyClients.add предоставляется агентству по заявке.
152	Недостаточно баллов
506	Превышено ограничение на количество соединений	Превышено ограничение на количество одновременных соединений с сервером.
3500	Не поддерживается	Попытка добавить корректировку, несовместимую с типом кампании.
3600	Ограниченная функциональность	Попытка использовать стратегию или .
4000	Параметры запроса указаны неверно	Переданные параметры кампании (группы, объявления) не соответствуют типу кампании (группы, объявления). Параметры стратегии показа заданы неверно: отсутствует структура с параметрами выбранной стратегии или указана структура с параметрами другой стратегии. Неверный формат даты (например, в параметре Timestamp). Неверная временная зона. Для оптимизации конверсий по ключевым целям необходимо указать хотя бы одну ключевую цель, отличную от вовлеченных сессий. Для использования категорий товаров необходимо указать идентификатор фида.
4001	Неверно заданы параметры фильтрации SelectionCriteria	Превышено количество идентификаторов в массиве. В SelectionCriteria должен присутствовать хотя бы один параметр из совокупности (например, Ids, AdGroupIds и CampaignIds).
4002	Неверно указаны параметры страницы	Неверное значение параметра Limit или Offset.
4003	Не передано ни одного из необходимых параметров	В запросе должен присутствовать хотя бы один параметр из совокупности, однако не указано ни одного.
4004	Передан больше чем один параметр	Указаны взаимоисключающие параметры, только один из которых может присутствовать в запросе.
4005	В одном запросе необходимо использовать Id одного типа	При назначении ставок указаны идентификаторы разнородных объектов (например, в одной структуре Bids — CampaignId , а в другой — AdGroupId).
4006	В одном запросе заданы несовместимые операции	Редактировать уточнения к объявлению можно либо с помощью операций ADD и REMOVE, либо с помощью операции SET.
5000	Поле обязательно для заполнения	Значение обязательного поля пустое или состоит из пробелов.
5001	Превышена допустимая длина
5002	Используются недопустимые символы	Недопустимый символ в ключевой фразе, минус-фразе, тексте быстрой ссылки. Неверное использование операторов в ключевой фразе, например отдельно стоящий символ «!».
5003	Указано пустое значение	Пустая строка, например, в параметре Href в объявлении.
5004	Неверный формат	Некорректное значение поля объекта, например: В методе VCards.add: Некорректный идентификатор в системе мгновенного обмена сообщениями в параметре MessengerLogin. Некорректный адрес электронной почты в параметре ContactEmail. Некорректные часы работы в параметре WorkTime. Некорректный номер телефона в структуре Phone. В сервисе AdGroups: пустое имя группы. В сервисе AdImages: тип или размер файла изображения не соответствует требованиям.
5005	Поле задано неверно	Некорректное значение поля объекта, например: Идентификатор объекта не является целым положительным числом. В методе VCards.add: Неподдерживаемый тип системы мгновенного обмена сообщениями в параметре MessengerClient. Не указан код страны, код города или номер телефона в структуре Phone. Некорректная или несовместимая с городом станция метро в параметреMetroStationId. В сервисе Sitelinks протокол в ссылке отличен от http и https. В сервисе Ads: поле AdImageHash указана некорректная ссылка на изображение или ссылка на несуществующее изображение. В сервисе AdGroups: пустой массив RegionIds. В сервисе Bids: значение ставки или ContextCoverage выходит за рамки допустимого диапазона. В методе AgencyClients.add: указана недопустимая валюта клиента. Валюты, в которых агентство может регистрировать клиентов, указаны в результирующем параметре метода GetClientInfo (Live) API версии Live 4. В методе Keywords.update: попытка отключить все категории автотаргетинга.
5006	Неверное использование поля
5007	Повторяющийся элемент	Совпадают тексты быстрых ссылок или ссылки ведут на одну и ту же страницу сайта.
5008	Не передано ни одного из необходимых полей	Для объекта должно быть задано хотя бы одно поле из совокупности, однако не указано ни одного.
5009	Передано больше чем одно поле	Для объекта заданы взаимоисключающие поля.
5100	Неправильное использование шаблона	Некорректное использование шаблонов (##) в заголовке и тексте объявления.
5120	Геотаргетинг задан неправильно	Указан несуществующий идентификатор региона. Регион повторяется несколько раз. Указаны только минус-регионы. Указан минус-регион, совпадающий с регионом показа. Указан минус-регион, не содержащийся ни в одном из регионов показа.
5140	Ключевая фраза содержит много слов	Превышено количество ключевых слов во фразе.
5141	Некорректное использование стоп-слов	Ключевая фраза состоит только из стоп-слов.
5142	Превышена допустимая длина слова в ключевой фразе
5160	Минус-слово не может быть словосочетанием	Попытка использовать минус-слово с пробелом.
5161	Некорректное использование минус-слов	Ключевая фраза состоит только из минус-слов. Минус-слово содержит точку (при этом не является десятичным числом). Минус-слово начинается с апострофа или заканчивается апострофом. Неправильное сочетание специальных символов в ключевой фразе. Словосочетание в кавычках не может состоять из минус-слов. Нельзя указывать минус-слово, содержащееся в исходной ключевой фразе. Суммарная длина фраз превышает максимальное допустимое значение.
5162	Превышена допустимая длина минус-слова
5181	Запрещено изменять рекламируемое приложение
5200	Логин уже используется	Попытка создать клиента с логином, который уже используется на Яндексе другим пользователем.
6000	Неконсистентное состояние объекта	Тип группы объявлений не соответствует типу кампании или тип объявления не соответствует типу группы. Попытка удалить визитку, которая используется в объявлении. Попытка удалить набор быстрых ссылок, который используется в объявлении. В объявлении указан набор быстрых ссылок, но не указана основная ссылка. В объявлении не указана ни визитка, ни основная ссылка. Попытка изменить возрастную метку, если метка не присвоена, а также попытка указать возрастную метку, не соответствующую категории объявления. Попытка предоставить клиенту агентства полномочие на управление кампаниями с помощью файлов, если отсутствует полномочие на редактирование кампаний. Попытка создать группу медийных объявлений с условием нацеливания по профилю пользователей и с минус-фразами.
6001	Указан объект несоответствующего типа	Попытка добавить ключевую фразу в группу динамических объявлений. Попытка добавить категории автотаргетинга в неподдерживаемую группу объявлений.
6100	Регион показа не соответствует тексту объявления (заголовок, текст, быстрые ссылки)	При попытке изменить регионы показа в группе нарушено соответствие языку объявления (например, в объявлении символы казахского алфавита, а геотаргетинг меняется на Россию)
6101	Язык не соответствует геотаргетингу	При добавлении или изменении объявления нарушено соответствие регионам показа (например, при геотаргетинге на Россию добавляется объявление на украинском языке)
7000	Количество допустимых элементов превышено или равно нулю	Количество быстрых ссылок меньше 1 или больше 4 Попытка добавить более одного условия нацеливания на аудиторию в группу медийных объявлений.
7001	Достигнуто максимальное количество объектов	Достигнуто максимальное количество групп объявлений в кампании Достигнуто максимальное количество объявлений в группе Достигнуто максимальное количество ключевых фраз в группе объявлений
7002	Данный домен трекинговой системы не поддерживается
55	Операция не найдена	Указано неверное значение ключа method при запросе в формате JSON.
8000	Некорректный запрос	Не указан OAuth-токен. OAuth-токен имеет неверный формат (например, содержит недопустимые символы). Не указан логин рекламодателя при запросе от имени агентства. Отсутствует обязательный параметр. Присутствует неизвестный параметр. Некорректный тип параметра, например: строка вместо числа; единичное значение вместо массива; если параметр имеет фиксированный набор значений (пример: FieldNames) — к ошибке приводит значение не из набора. Невалидный JSON. Отсутствует ключ method при запросе в формате JSON. Отсутствует заголовок SOAPAction или тело SOAP-запроса.
8300	Неверный статус у объекта	Попытка выполнить операцию с объявлением, группой объявлений или визиткой в архивной или удаленной кампании. Попытка отправить на модерацию объявление, не являющееся черновиком, или объявление в группе, не содержащей условий показа, или архивное объявление. Попытка удалить объявление, которое запрещено удалять (например, объявление было в показе). Попытка остановить или запустить объявление-черновик или архивное объявление. Попытка заархивировать активное объявление или объявление-черновик.
8301	Невозможно удалить объект	Попытка удалить группу, содержащую объявления или условия показа (ключевые фразы, условия нацеливания на аудиторию, условия нацеливания для динамических объявлений). Попытка удалить единственную активную фразу в группе (при отсутствии условий нацеливания на аудиторию). Попытка удалить кампанию, удаление которой не допускается (например, на кампании есть средства или выставлен счет на оплату).
8302	Невозможно остановить показы	Попытка остановить единственную активную фразу в группе (при отсутствии условий нацеливания на аудиторию).
8303	Невозможно заархивировать объект	Попытка заархивировать кампанию, на которой есть средства. Попытка заархивировать кампанию, которая не остановлена. Попытка заархивировать кампанию при недостатке средств на общем счете.
8304	Невозможно разархивировать объект	Попытка разархивировать кампанию из специального архива (состояние CONVERTED) Попытка разархивировать кампанию с превышением ограничения на количество активных кампаний
8305	Невозможно выполнить действие	Попытка изменить сумму дневного бюджета более 3 раз в сутки.
8312	Отчет невозможно построить в режиме online	Отчет с указанными параметрами может быть сформирован только в режиме офлайн. Измените в запросе HTTP-заголовок processingMode. См. раздел Онлайн- и офлайн-отчет.
8600	Ошибка подключения общего счета
8800	Объект не найден	В HTTP-заголовке Client-Login указан несуществующий логин или логин рекламодателя, не принадлежащего агентству. Указан идентификатор несуществующего, удаленного или не принадлежащего пользователю объекта — кампании, группы, объявления, визитки, ключевой фразы.
9300	Превышено ограничение на количество объектов в одном запросе	Превышено максимальное количество объектов во входном массиве метода
9301	Слишком широкое условие отбора	Превышено максимальное количество выбираемых корректировок. Сумма значений параметров Limit и Offset не должно превышать 120 000.
9600	Поле не соответствует установленной стратегии	В запросе отсутствует поле, являющееся обязательным при некоторых условиях (например, Bid в методе Bids. Set для ручных стратегий показа).
9601	Не допускается изменение ставки	В кампании установлена автоматическая стратегия. Изменение ставок в сетях не разрешено, так как показы на сети отключены. Изменение ставок в сетях не разрешено, так как установлена стратегия, при которой ставка в сети зависит от ставки на поиске. Изменение ставок на поиске не разрешено, так как показы на поиске отключены.
9800	Объект не может присутствовать в запросе более одного раза	В одном вызове метода update, set или delete содержится несколько объектов с одинаковым идентификатором
9801	Объект с указанными характеристиками уже существует	Попытка добавить корректировку, которая уже существует (например, повторно добавить корректировку на мобильных или корректировку для целевой аудитории с тем же самым условием ретаргетинга и подбора аудитории).
9802	Элемент не может присутствовать в списке более одного раза	В сервисе Campaigns: повторяющееся значение в массиве BlockedIps, CounterIds, NegativeKeywords или повторяющиеся дни в массиве Schedule. В сервисе AdGroups:повторяющееся значение в массиве TargetDeviceType. В сервисе Ads: повторяющиеся значения в массиве уточнений.

Сообщения консоли, среды выполнения и сервера MobileFirst

FWLSE3000E	Возникла ошибка сервера.
FWLSE3001E	Обнаружен конфликт.
FWLSE3002E	Ресурс не найден.
FWLSE3003E	Невозможно добавить среду выполнения, так как полезная нагрузка не содержит имя.
FWLSE3010E	Обнаружена ошибка базы данных. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически необходимо задать неверную конфигурацию базы данных.
FWLSE3011E	Недопустимый номер порта “{0}” в свойстве JNDI mfp.admin.proxy.port. {0} — это номер порта, например 9080. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически нужно задать не имеющее смысл значение в свойстве JNDI mfp.admin.proxy.port. Затем открыть Operations Console. В результате сообщение появится в протоколах сервера.
FWLSE3012E	Ошибка соединения JMX. Причина: “{0}”. См. дополнительные сведения в протоколах сервера. {0} — это сообщение об ошибке, полученное из протокола JMX веб-сервера. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически необходимо внести такую ошибку в конфигурацию JMX, чтобы генерировалась исключительная ситуация.
FWLSE3013E	При попытке заблокировать транзакцию через {0} мс наступил тайм-аут. {0} — это число миллисекунд, например 32000. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически это происходит в том случае, если соединение с базой данных работает нестабильно или медленно.
FWLSE3017E	Обнаружена ошибка базы данных: {0}. Причина: {1} {0} — это сообщение об ошибке от cloudant. {1} — это сообщение о причине от cloudant. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически необходимо задать неверную конфигурацию Cloudant.
FWLSE3018E	Операция Cloudant не завершилась за {0} мс. {0} — это число миллисекунд, например 32000. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически необходимо использовать БД Cloudant и задать значение 1 в свойстве JNDI mfp.db.cloudant.documentOperation.timeout. Если соединение с cloudant работает медленно, откройте Operations Console. В результате сообщение появится в протоколах сервера.
FWLSE3019E	Не удалось получить блокировку транзакции. Причина: {0} {0} — это сообщение об исключительной ситуации, полученное из внешнего источника. Оно может представлять собой любую строку. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически для воспроизведения необходимо использовать ферму с Cloudant и завершить работу блокирующего главного узла, когда выполняется операция блокировки. Затем открыть Operations Console. В результате сообщение появится в протоколах сервера.
FWLSE3021E	При попытке заблокировать транзакцию через {0} мс наступил тайм-аут. Увеличьте значение свойства {1}. {0} — это число миллисекунд, например 32000. {1} — это имя свойства JNDI, задающего тайм-аут. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически это происходит в том случае, если соединение с базой данных работает нестабильно или медленно.
FWLSE3030E	Среда выполнения “{0}” отсутствует в базе данных администрирования MobileFirst. Возможно, база данных повреждена. Где: {0} — имя среды выполнения (любая строка). Эта ошибка происходит в том случае, если MobileFirst Server не удается загрузить среду выполнения, хранящуюся с базе данных. Для устранения ряда причин появления этого сообщения был выпущен APAR PI71317. Если уровень исправлений сервера ниже iFix 8.0.0.0-IF20170125-0919, выполните обновление до последнего iFix.
FWLSE3031E	Среду выполнения “{0}” невозможно добавить или удалить, поскольку она еще работает. {0} — это имя среды выполнения (любая строка).
FWLSE3032E	Среду выполнения “{0}” невозможно добавить, поскольку она уже существует. {0} — это имя среды выполнения (любая строка).
FWLSE3033E	Среда выполнения “{0}” непустая, однако запрошено ее удаление, только если она пустая. {0} — это имя среды выполнения (любая строка). Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически необходимо удалить остановленную среду выполнения, в которой еще есть приложения.
FWLSE3034E	Приложение “{1}” для среды выполнения “{0}” отсутствует в базе данных администрирования MobileFirst. Возможно, база данных повреждена. {0} — это имя среды выполнения (любая строка). {1} — это имя приложения (любая строка).
FWLSE30302E	Конфигурация лицензии приложения “{1}” для среды выполнения “{0}” отсутствует в базе данных администрирования MobileFirst. {0} — это имя среды выполнения (любая строка). {1} — это имя приложения (любая строка).
FWLSE30303E	Конфигурацию лицензии невозможно удалить, поскольку приложение “{1}” для среды выполнения “{0}” есть в базе данных администрирования MobileFirst или конфигурация лицензии не существует. {0} — это имя среды выполнения (любая строка). {1} — это имя приложения (любая строка).
FWLSE30035E	Приложение “{1}” невозможно добавить, поскольку оно уже есть в среде выполнения “{0}”. {0} — это имя среды выполнения (любая строка). {1} — это имя приложения (любая строка). Что нужно сделать для воспроизведения: происходит только во время модульного тестирования
FWLSE3035E	Приложение “{1}” со средой “{2}” среды выполнения “{0}” отсутствует в базе данных администрирования MobileFirst. Возможно, база данных повреждена. {0} — это имя среды выполнения (любая строка) {1} — это имя приложения (любая строка). {2} — это имя среды: android, ios, …
FWLSE30304E	Данные AppAuthenticity для приложения “{1}” со средой “{2}” и версией “{3}” среды выполнения “{0}” отсутствуют в базе данных администрирования MobileFirst. Возможно, база данных повреждена. {0} — это имя среды выполнения (любая строка) {1} — это имя приложения (любая строка). {2} — это имя среды: android, ios, …
FWLSE3036E	Приложение “{1}” со средой “{2}” и версией “{3}” среды выполнения “{0}” отсутствует в базе данных администрирования MobileFirst. Возможно, база данных повреждена. {0} — это имя среды выполнения (любая строка). {1} — это имя приложения (любая строка). {2} — это имя среды: android, ios, … {3} — это версия: 1. 0, 2.0 …
FWLSE3037E	Среду “{1}” с версией “{2}” невозможно добавить, поскольку она уже есть в приложении “{0}”. {0} — это имя приложения (любая строка). {1} — это имя среды: android, ios, … {2} — это версия: 1.0, 2.0 … Что нужно сделать для воспроизведения: происходит только во время модульного тестирования
FWLSE3038E	Адаптер “{1}” среды выполнения “{0}” отсутствует в базе данных администрирования MobileFirst. Возможно, база данных повреждена. {0} — это имя среды выполнения (любая строка). {1} — это имя адаптера (любая строка).
FWLSE3039E:	Адаптер “{0}” невозможно добавить, поскольку он уже есть в среде выполнения “{1}”. {0} — это имя среды выполнения (любая строка). {1} — это имя адаптера (любая строка). Что нужно сделать для воспроизведения: происходит только во время модульного тестирования.
FWLSE3040E	Профайл конфигурации “{0}” не найден ни для одной среды выполнения в базе данных администрирования MobileFirst. Возможно, база данных повреждена. {0} — это ИД профайла конфигурации (любая строка). Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически эта ошибка может появляться в протоколе трассировки при удалении несуществующего профайла конфигурации клиента.
FWLSE3045E	Не найден объект MBean для администрирования {0}. {0} — это MobileFirst. Что нужно сделать для воспроизведения: Это сделать очень сложно.
FWLSE3041E	Не найден объект MBean для проекта {0} ‘‘{1}’’. Возможно, веб-приложение среды выполнения {0} для проекта {0} ‘‘{1}’’ не работает. Если оно работает, проверьте объекты MBean с помощью JConsole. Если оно не работает, полная информация об ошибке записана в файлы протокола сервера. {0} — это MobileFirst. {1} — это имя проекта/среды выполнения (любая строка)
FWLSE3042E	Ошибка связи с объектом MBean ‘‘{0}’’. См. протоколы сервера приложений. {0} — это канонический ИД MBean в строковом формате. Что нужно сделать для воспроизведения: Это сделать очень сложно. Эта ошибка может возникать при установке worklight-jee-library версии 6.2 на сервере MobileFirst версии 7.1.
FWLSE3043E	Объект MBean с именем ‘‘{0}’’ больше не существует. См. протоколы сервера приложений. {0} — это канонический ИД MBean в строковом формате. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически эта ошибка возникает в ферме серверов при завершении работы сервера в процессе выполнения операции развертывания.
FWLSE3044E	Объект MBean с именем ‘‘{1}’’ не поддерживает ожидаемые операции. Убедитесь, что версия среды выполнения {0} совпадает с версией служб администрирования. {0} — это MobileFirst. {1} — это канонический ИД MBean в строковом формате. Что нужно сделать для воспроизведения: Это сделать очень сложно. Эта ошибка может возникать при установке worklight-jee-library версии 6.2 на сервере MobileFirst версии 7.1.
FWLSE3050E	Операция объекта MBean возвращает неизвестный тип. Убедитесь, что версия среды выполнения {0} совпадает с версией служб администрирования. {0} — это MobileFirst. Что нужно сделать для воспроизведения: Это сделать очень сложно. Эта ошибка может возникать при установке worklight-jee-library версии 6.2 на сервере MobileFirst версии 7.1.
FWLSE3051E	Недопустимая полезная нагрузка. См. дополнительные сообщения.
FWLSE3052E	Следующую полезную нагрузку не удалось распознать: “{0}”. {0} — это полезная нагрузка в формате JSON, например “{ a : 0 }”
FWLSE3053E	Недопустимые параметры. См. дополнительные сообщения.
FWLSE3061E	Среда “{0}”, указанная в файле “{1}” файла wlapp, неизвестна. Проверьте компоновку приложения. {0} — это среда: android, ios. {1} — это имя файла.
FWLSE3063E	Приложение невозможно развернуть, поскольку в файле wlapp отсутствует папка “{0}”. Проверьте компоновку приложения. {0} — это имя папки, например “meta”. Что нужно сделать для воспроизведения: Разверните wlapp, не содержащий папку meta
FWLSE3065E	Приложение невозможно развернуть, поскольку в файле wlapp отсутствует поле “{0}”. Проверьте компоновку приложения. {0} — это обязательное поле, например “app.id”
FWLSE3066E	Приложение невозможно развернуть, так как его версия, равная “{2}”, отличается от версии среды выполнения {0}, равной “{3}”. \nИспользуйте {1} “{4}” для компоновки и развертывания приложения. {0} — это MobileFirst, {1} — имя studio, например MobileFirst Studio, {2} — это версия приложения: 1.0, 2.0, … {3} — это версия среды выполнения, {4} — это необходимая версия studio
FWLSE3067E	Приложение невозможно развернуть, поскольку версия приложения старше версии среды выполнения {0}, которая равна “{2}”. \nИспользуйте {1} “{3}” для компоновки и развертывания приложения. {0} — это MobileFirst, {1} — это имя studio, например MobileFirst Studio, {2} — это версия среды выполнения, {3} — это необходимая версия studio
FWLSE3068E	Адаптер невозможно развернуть, так как версия адаптера, равная “{2}”, отличается от версии среды выполнения {0}, равной “{3}”. \nИспользуйте {1} “{4}” для компоновки и развертывания адаптера. {0} — это MobileFirst, {1} — имя studio, например MobileFirst Studio, {2} — это версия адаптера: 1.0, 2.0, … {3} — это версия среды выполнения, {4} — это необходимая версия studio
FWLSE3069E	Адаптер невозможно развернуть, поскольку версия адаптера старше версии среды выполнения {0}, которая равна “{2}”. \nИспользуйте {1} “{3}” для компоновки и развертывания адаптера. {0} — это MobileFirst, {1} — это имя studio, например MobileFirst Studio, {2} — это версия среды выполнения, {3} — это необходимая версия studio
FWLSE3070E	Не удалось обновить приложение “{1}” со средой “{2}” и версией “{3}”, поскольку оно заблокировано. Его можно разблокировать через {0} Operations Console. {0} — это MobileFirst, {1} — это имя приложения (любая строка), {2} — это среда приложения: android, ios, … {3} — это версия приложения: 1. 0, 2.0, …
FWLSE3071E	Не удалось развернуть гибридное приложение “{0}”, поскольку уже есть внутреннее приложение с таким именем. {0} — это имя приложения (любая строка) Что нужно сделать для воспроизведения: Создайте внутреннее и гибридное приложение с одинаковыми именами и разверните их в Operations Console.
FWLSE3072E	Не удалось развернуть внутреннее приложение “{0}”, поскольку уже есть гибридное приложение с таким именем. {0} — это имя приложения (любая строка) Что нужно сделать для воспроизведения: Создайте внутреннее и гибридное приложение с одинаковыми именами и разверните их в Operations Console.
FWLSE3073E	Не найден файл программы установки Adobe Air в приложении “{1}” версии “{2}”. \nИспользуйте {0} для перекомпоновки и развертывания файла wlapp для этого приложения. {0} — это имя studio, например MobileFirst Studio, {1} — это имя приложения (любая строка), {2} — это версия приложения: 1.0, 2.0, … Что нужно сделать для воспроизведения: Это происходит в случае повреждения приложения Adobe
FWLSE3074W	Блокировка должным образом обновлена для приложения “{0}” со средой “{1}” и версией “{2}”, однако это не влияет на среду “{1}”, поскольку она не поддерживает прямое обновление. {0} — это имя приложения (любая строка), {1} — это среда приложения: android, ios, … {2} — это версия приложения: 1.0, 2.0, … Что нужно сделать для воспроизведения: Это сделать очень сложно.
FWLSE3075W	Правило проверки подлинности приложения должным образом обновлено для приложения “{0}” со средой “{1}” и версией “{2}”, однако это не влияет на среду “{1}” приложения “{0}”, поскольку эта среда не поддерживает проверку подлинности приложений. Такую поддержку можно включить для данной среды приложений путем объявления в файле application-descriptor.xml конфигурации защиты, определенной в файле authenticationConfig.xml. {0} — это имя приложения (любая строка), {1} — это среда приложения: android, ios, … {2} — это версия приложения: 1.0, 2.0, … Что нужно сделать для воспроизведения: Это сделать очень сложно.
FWLSE3076W	Приложение “{0}” со средой “{1}” и версией “{2}” не развернуто, поскольку оно не изменилось с момента предыдущего развертывания. {0} — это имя приложения (любая строка), {1} — это среда приложения: android, ios, … {2} — это версия приложения: 1.0, 2.0, … Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически необходимо развернуть один и тот же wlapp в Operations Console.
FWLSE3077W	Адаптер “{0}” не развернут, поскольку он не изменился с момента предыдущего развертывания. {0} — это имя адаптера (любая строка) Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически необходимо развернуть один и тот же адаптер в Operations Console.
FWLSE3078W	Отсутствует файл уменьшенных изображений в файле wlapp для приложения “{0}” со средой “{1}” и версией “{2}”. {0} — это имя приложения (любая строка), {1} — это среда приложения: android, ios, … {2} — это версия приложения: 1.0, 2.0, …
FWLSE3079W	Невозможно проверить, скомпоновано ли приложение “{2}” со средой “{3}” и версией “{4}” с помощью той же версии {1}, что и среда выполнения {0}, так как и приложение, и среда выполнения скомпонованы с помощью Worklight Studio версии младше 6.0. Убедитесь, что оба элемента были скомпонованы с помощью одной версии {1}. {0} — это MobileFirst, {1} — это имя studio, например MobileFirst Studio, {2} — это имя приложения (любая строка), {3} — это среда приложения: android, ios, … {4} — это версия приложения: 1. 0, 2.0, … Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически нужно развернуть wlapp, скомпонованный с помощью Worklight Studio 5.0.6 или более старой версии, в MobileFirst Server 7.1.
FWLSE3080W	Невозможно проверить, скомпонован ли адаптер “{2}” с помощью той же версии {1}, что и среда выполнения {0}, так как и адаптер, и среда выполнения скомпонованы с помощью Worklight Studio версии младше 6.0. Убедитесь, что оба элемента были скомпонованы с помощью одной версии {1}. {0} — это MobileFirst, {1} — имя studio, например MobileFirst Studio, {2} — имя адаптера (любая строка) Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически нужно развернуть адаптер, скомпонованный с помощью Worklight Studio 5.0.6 или более старой версии, в MobileFirst Server 7.1.
FWLSE3081E	Проверка подлинности приложения не поддерживается для среды “{0}”. Поддерживаются только среды iOS и Android. {0} — это среда приложения: android, ios, … Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически необходимо отредактировать приложение с включенной проверкой подлинности, изменив среду, а затем развернуть его.
FWLSE3082E	Файл “{0}” пустой и не может быть развернут. {0} — это имя файла
FWLSE3084E	Файл адаптера невозможно развернуть, поскольку он не содержит обязательного файла XML адаптера. Проверьте компоновку. Что нужно сделать для воспроизведения: разверните адаптер, не содержащий файл XML
FWLSE3085E	Файл приложения невозможно развернуть, поскольку он не содержит обязательного файла “{0}”. Проверьте компоновку. Что нужно сделать для воспроизведения: разверните wlapp, не содержащий файл meta/deployment. data
FWLSE3090E	Транзакция выполняется бесконечно. См. протоколы сервера приложений. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически эта ошибка возникает, если транзакция зависает по неизвестной причине на 30 мин
FWLSE3091W	Сбой обработки транзакции {0}. См. протоколы сервера приложений. {0} — это ИД транзакции, обычно он представляет собой число Что нужно сделать для воспроизведения: Это сделать очень сложно. Возможно, удастся воспроизвести, если завершить работу среды выполнения во время обработки транзакции.
FWLSE3092W	Транзакция {0} была отменена до начала обработки. См. протоколы сервера приложений. {0} — это ИД транзакции, обычно он представляет собой число Что нужно сделать для воспроизведения: Это очень сложно сделать. Это происходит, когда есть несколько транзакций развертывания, и в момент завершения работы сервера по крайней мере одна из них еще не обработана. Необработанная транзакция будет отменена при перезапуске сервера.
FWLSE3100W	Нет доступа к двоичному ресурсу {3}. Не удалось выполнить запрос диапазона HTTP {0}-{1}. Максимальный размер данных составляет {2} байт. {0} — это начала диапазона байт, например 0, {1} — это конец диапазона байт, например 6666, {2} — это количество доступных байт, например 25, {3} — это имя ресурса (например, имя файла)
FWLSE3101W	Приложение {1}, среда {2}, версия {3}, скомпонованное с помощью {0} версии {4}, было переопределено средой, скомпонованной с помощью {0} версии {5} {0} — имя studio: MobileFirst Studio, {1} — имя приложения (любая строка), {2} — среда приложения: android, ios, … {3} — версия приложения: 1. 0, 2.0, … {4} — версия studio, например 3.0, {5} — другая версия studio, например 4.0 Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически необходимо скомпоновать приложение с помощью двух разных версий Studio, причем в обоих случаях должен использоваться один номер версии и одна среда. После развертывания обоих приложений на одном сервере может быть отправлено это сообщение. Однако оно может быть скрыто другими сообщениями. Мне ни разу не удавалось его увидеть.
FWLSE3102W	Для приложения {0} не включены push-уведомления. {0} — это имя приложения (любая строка)
FWLSE3103E	Тег Push-уведомления {0} не найден для приложения {2} среды выполнения {1}. {0} — это тег push-уведомления (любая строка), {1} — имя среды выполнения (любая строка), {2} — имя приложения (любая строка) Что нужно сделать для воспроизведения: происходит только во время модульного тестирования
FWLSE3104E	Тег Push-уведомления {0} уже существует для приложения {2} среды выполнения {1}. {0} — это тег push-уведомления (любая строка), {1} — имя среды выполнения (любая строка), {2} — имя приложения (любая строка) Что нужно сделать для воспроизведения: Это сделать очень сложно.
FWLSE3105W	Просрочен сертификат Push-уведомлений для {0}. {0} — имя посредника, передающего push-уведомления (любая строка) Что нужно сделать для воспроизведения: Это сделать очень сложно.
FWLSE3113E	При синхронизации среды выполнения {0} произошло несколько ошибок. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически эта ситуация возникает в процессе настройки фермы (в конфигурации с несколькими узлами) при запуске сервера, однако на всех узлах выдаются разные сообщения об ошибках.
FWLSE3199I	========= Запущен {0} версии {1}. Что нужно сделать для воспроизведения: Это сообщение добавляется в протокол сервера при каждом запуске сервера.
FWLSE3210W	Среда {1} приложения {0} версии {2} развернута с другой версией MobileFirst SDK для внутренних приложений. Прямые обновления станут недоступны для существующих клиентов с другими версиями MobileFirst SDK. Для того чтобы продолжить использование прямых обновлений, увеличьте версию приложения, опубликуйте его в общедоступном магазине приложений, разверните на сервере и (необязательно) заблокируйте старые версии приложения, чтобы заставить клиентов обновиться до новой версии из магазина приложений. Что нужно сделать для воспроизведения: Это сделать очень сложно. Теоретически эта ошибка может возникать, если приложение было создано в старой версии MobileFirst Studio с использованием другой, более старой версии MobileFirst SDK. Однако я не знаю о том, какие версии SDK применяются внутри MobileFirst.
FWLSE3119E	Сбой проверки сертификата APNS. См. дополнительные сообщения. Что нужно сделать для воспроизведения: Это сделать очень сложно. Это происходит в том случае, если сертификат push-уведомлений Apple недопустим.
FWLSE3120E	Эта функция API доступна только после миграции приложения на MobileFirst Platform 6.3. Текущая версия приложения: {0} Что нужно сделать для воспроизведения: Это сделать очень сложно. Это происходит при использовании новой версии push-уведомлений в старых приложениях.
FWLSE3121E	Эта функция API больше недоступна на сервере. См. дополнительные сообщения.
FWLSE3122E	Правило проверки подлинности приложения больше нельзя изменить внутри сервера. Для изменения правила проверки подлинности требуются повторная компоновка и развертывание приложения.
FWLSE3123W	Среда {1} приложения {0} версии {2} развернута с выключенной расширенной проверкой подлинности приложений. Рекомендуется применять расширенную проверку подлинности приложений для более надежной защиты от поддельных приложений. Для этого в инструменте mfpadm выполните команду включения расширенной проверки подлинности перед развертыванием приложения. Что нужно сделать для воспроизведения: Разверните приложение с использованием простой идентификации в Operations Console. В любых приложениях версии младше 7.0 нет расширенной проверки подлинности, поэтому должно быть показано это или следующее предупреждение. Предупреждение не отображается при использовании консоли Operations Console, встроенной в Worklight Studio.
FWLSE3124W	Среда {1} приложения {0} версии {2} развернута с выключенной проверкой подлинности приложений. Включите ее для дополнительной защиты от поддельных приложений.

Длина SMS и допустимые символы — mobizon.kz

Поддерживаемые наборы символов

Текст SMS может быть отправлен в одной из двух кодировок в зависимости от набора символов, использованных при составлении сообщения.

Кодировка GSM (латиница, 7 bit)

Если текст содержит только символы из приведенной таблицы, то SMS будет отправлено в кодировке GSM:

@	Δ	SP	0	¡	P	¿	p
£	_	!	1	A	Q	a	q
$	Φ	«	2	B	R	b	r
¥	Γ	#	3	C	S	c	s
è	Λ	¤	4	D	T	d	t
é	Ω	%	5	E	U	e	u
ù	Π	&	6	F	V	f	v
ì	Ψ	‘	7	G	W	g	w
ò	Σ	(	8	H	X	h	x
Ç	Θ	)	9	I	Y	i	y
LF	Ξ	*	:	J	Z	j	z
Ø		+	;	K	Ä	k	ä
ø	Æ	,	<	L	Ö	l	ö
CR	æ	—	=	M	Ñ	m	ñ
Å	ß	.	>	N	Ü	n	ü
å	É	/	?	O	§	o	à

CR — символ возврата каретки
LF — символ переноса строки
SP — символ пробела

Эта кодировка позволяет отправлять до 160 символов в одном SMS-сообщении. Также следует учитывать, что в GSM-7 кодировке существует несколько символов, которые при подсчете длины SMS считаются за два символа, ниже приведена таблица таких символов:

Кодировка Unicode (кириллица, расширенный набор символов)

В случае наличия хотя бы одного символа, не относящегося к GSM кодировке, SMS-сообщение будет отправлено в кодировке Unicode. Такое сообщение может содержать до 70 символов. Поддерживаются только символы из таблицы юникод (UTF-8) с кодами в диапазоне от U+0000 до U+9999, все остальные символы на данный момент не поддерживаются.

Длина SMS

Длина одиночного сообщения, состоящего только из символов GSM-алфавита — 160 символов.

Длина одиночного сообщения в кодировке Unicode — 70 символов.

В случае, если SMS-сообщение превышает указанную длину, оно разбивается на части — сегменты.

Каждый сегмент SMS отправляется и тарифицируется как отдельное сообщение.

Каждый сегмент SMS содержит специальный заголовок (несколько символов служебной информации) для последующей склейки на стороне получателя, поэтому максимальная длина одного сегмента в длинном сообщении составляет 153 символа в GSM кодировке и 67 символов в Unicode.

Максимальная длина SMS составляет 140 байт. Каждый символ GSM-алфавита кодируется 7 битами (за исключением нескольких, которые кодируются 14 битами). Это позволяет в 140 байтах, отведенных для текста SMS, передавать до 160 символов (140*8/7=160). При использовании в тексте SMS даже одного символа, не относящегося к GSM, весь текст передается в кодировке Unicode. При этом допустимое количество символов в одиночном сообщении сокращается до 70, так как в Unicode каждый символ кодируется при помощи 16 бит (140*8/16=70).

Для длинных SMS-сообщений используется заголовок (или UDH), который содержит 6 байт служебной информации, что занимает 7 символов при использовании только латиницы или 3 символа при использовании Юникода. Соответственно максимальная длина текста в одном сегменте составляет 153 символа для GSM и 67 символов для Unicode кодировки.

Количество сегментов в SMS	Количество символов в SMS
	Кодировка GSM	Кодировка Unicode
1	160	70
2	306	134
3	459	201
4	612	268
5	765	335
6	918	402
7	1071	469
8	1224	536
9	1377	603
10	1530	670

Хотя спецификация протокола SMPP позволяет создавать сообщения размером до 128 сегментов, на практике операторы мобильной связи не гарантируют качественную доставку сообщений, длина которых превышает 3 сегмента. Сообщения, включающие более 10 сегментов, некоторые операторы не доставляют совсем или могут доставить только часть сегментов, тем самым сделав бессмысленным весь текст сообщения. Поэтому мы рекомендуем отправлять сообщения, длиной не более 3 сегментов. Доставка более длинных SMS не гарантируется операторами связи.

Публичное API и веб-хуки | Центр справки CheckOffice

CheckOffice предоставляет публичное REST API для интеграций со сторонними сервисами.

Ограничения использования

Данный функционал доступен всем клиентам на тарифах Trial и Pro и в качестве подключаемой опции в индивидуальных тарифах.

---

Возможности API

• получение данных проверки по id

• создание проверки

• получение задачи по id

• создание задачи

• получение информации об объекте проверки по id

• получение информации о пользователе по id

Возможности веб-хуков

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

События веб-хуков:

• создание проверки

• изменение статуса проверки

• создание задачи

• изменение статуса задачи

---

Использование API

Для начала использования API перейдите в раздел Настройки — Публичное API. Для выполнения запросов вам понадобится ключ, для получения событий — настройка веб-хуков на необходимые события.

ВНИМАНИЕ! не передавайте ключ API посторонним лицам, так как они смогут получить доступ к вашим данным.

Ознакомьтесь с документацией swagger, она расположена по адресу

https://ваш-домен.checkoffice.ru/documentation/api/public 

Для выполнения запросов в swagger необходимо ввести ваш ключ API

Например, для выполнения запроса получения проверки потребуется указать ее id, его можно посмотреть в сервисе при открытии проверки

После выполнения запроса будет сгенерирован пример запроса для curl

Id для получения задачи так же можно узнать при открытии задачи в сервисе

Для того, чтобы выполнить запрос к сервису из внешних систем, укажите в его заголовках

API-Key: [Ваш-ключ-API]

---

Использование веб-хуков

Добавьте на странице Настройки-Публичное API веб-хук, укажите URL на который будут отправляться запросы, необходимые заголовки и выберите события, которые вас интересуют. Вы можете создать несколько различных вебхуков под ваши потребности.

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

При наступлении выбранного события сервис пришлет POST-запрос на указанный адрес. В теле запроса будут два поля:

• data — данные о задаче или проверке в зависимости от события

• event — тип сработавшего события — создание проверки inspection.create, изменение статуса проверки inspection.changeStatus, создание задачи task.create, изменение статуса задачи task.changeStatus

Схему данных, отсылаемых в поле data, можно посмотреть в документации swagger https://ваш-домен.checkoffice.ru/documentation/api/public, отсылаются объекты Task и Inspection

Обратите внимание, что сервис никак не обрабатывает ответы на запрос, и не повторяет попыток отсылки данных в случае возникновения ошибки.

---

Политика версионности и развития API

Публичное API имеет версию, актуальную версию можно узнать в разделе Настройки-Публичное API

Развивая сервис, мы будем добавлять новые данные в актуальную версию API.

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

Рекомендуется периодически обновлять ваши интеграции до актуальной версии API.

Победа над смыслами, или Артишоки либерального богословия / Православие.Ru

«В зрелом виде цветок артишока
имеет сходство с чертополохом».
Ботанический словарь

12 октября 2021 на портале Православие.Ru была опубликована статья протоиерея Александра Шаргунова, С. Марнова, О. Шикаловой, О. Штейнера «УМК “Приходская школа ‘под ключ’” или ключ от ящика Пандоры?»[1]. В статье был поставлен вопрос о десакрализации православного вероучения и искажении христианских нравственных ценностей в учебно-методическом пособии для воскресных школ за авторством диакона Ильи Кокина. Статья вызвала большой интерес, о живом отклике свидетельствуют многочисленные комментарии читателей.

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

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

«Если вы никогда не пробовали артишоки – настоятельно рекомендую! Конечно, их сезон – ранняя весна, март, и правильное место – Средиземноморье – именно там, именно тогда они самые нежные – только что срезанные, так и дышат весенней свежестью! Запеченные на гриле, с хорошим оливковым маслом, слегка подсоленные и сбрызнутые несколькими каплями лимона…»[2]

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

«Правдокопательство – очень похоже на попытку “раздеть” артишок. Наличие чего-то недосказанного, недопонятого, неопределённого побуждает правдоискателя снова и снова срывать кажущиеся ему лживыми покровы – пока он не докопается до самой сути. До той самой голой правды, которую можно безжалостно схватить за белую шею – сопротивляться-то ей уже нечем! Ага, попалась, негодница, ох сейчас мы тебя в ярком свете как рассмотрим! Нечем будет свою стыдобу прикрывать! И бессознательно вдохновляемый эротическим мотивом, от которого всё нутро ходуном ходит, правдоруб безжалостно срывает, сдирает, взламывает то, что для его “утончённого” вкуса – недостаточно истинно. Но, увы, итог всегда – такой же, как и с артишоком. Докопаться-то докопались – а на неё, эту самую голую, без слёз не взглянуть! И, спрашивается, ради чего было столько усилий?…»

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

Итак, вопрос об истине сведён к двум категориям – вкуса («взламывает то, что для утончённого вкуса недостаточно истинно») и мнения («кажущиеся лживыми покровы»). Понятие истины выносится за скобки, а вместо нее предлагается…

Предоставим слово самому о. Павлу, поскольку он является руководителем проекта «Академия веры». «Академия веры» – это просветительский проект от команды портала «Богослов.Ru». Авторы проекта – современные богословы, многие из которых преподают в Московской духовной академии. На сайте данного проекта заявлено, что это

«первый для Рунета ресурс, посвящённый многостороннему изучению христианского вероучения. Почему бы не посмотреть свежим взглядом на учение и традиции Православной Церкви?»[3]

Далее об этом свежем взгляде о. Павел говорит так:

«…Там, где привыкли видеть “дважды два четыре”, мы вдруг увидели некий диапазон. Там может быть не 4, а 4,358. Или — больше четырёх, но меньше пяти. Для некоторых это выглядит как разрушение основ, устоев того, на что многие привыкли опираться. На самом деле мы не разрушаем ничего, напротив, стараемся привить вкус к богомыслию»[4].

Кто-нибудь, может быть, скажет: «О вкусах не спорят», но ведь речь здесь идет об истинах нашей веры, а не о меню в ресторане. И подобно тому, как материалы УМК «Приходская школа “под ключ”» (для старших подростков) вызвали негативную реакцию священников, педагогов и родителей, так же и здесь, после знакомства с материалами «Академии веры», встаёт непростой вопрос: какие изменения происходят сейчас в духовном просвещении и духовном образовании (поскольку о. Павел, будучи преподавателем МДА, имеет к нему непосредственное отношение)?

Обратимся к примерам.

В мае 2021 года в Российском православном университете открылся учебный курс «Пастырское служение в высших учебных заведениях г. Москвы и Московской области». Вот какой «вкус к богомыслию» о. Павел прививал университетскому духовенству 19 мая:

«Я настоятельно вам рекомендую почитать книгу Б. Б. Виногродского, она называется “Искусство игры с миром. Смысл победы в победе над смыслами”. Он смог сделать то, что пока мы, православные, сделать не смогли – он смог даосскую систему мировоззрения упаковать в нашу актуальную российскую, русскую литературную систему. Он создал некое пространство смысловой игры в виде коротких афоризмов, шуток, небольших таких провокативных вбросов, которые вы читаете и воспринимаете, проглатываете, даже не задумываясь над тем, что на самом деле в вас ввели очень высокой концентрации инъекцию даосского мировоззрения. <…> То есть он смог эти смыслы переупаковать в такую форму, которая проникает к нам без всякого малейшего отторжения. Мы просто её кушаем, облизываемся и благодарим: “Слушайте, как же это было вкусно, как же это было прекрасно!”»

И далее:

«Меня эта книга задела. Очень бы хотелось, чтобы у нас появилось нечто подобное».

В предисловии к своей книге Б.Б. Виногродский пишет:

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

О. Павел восхищается тем, как путем провокативных вбросов в человека вводят определенные идеи, а человек об этом даже не подозревает… Это можно расценить как манипуляцию – воздействие на человека помимо его сознания. «Переупаковка» – это попытка в данном случае продать Православие в любой обертке, лишь бы «купили».

Обращаясь после этого к ряду фильмов проекта «Академия веры», начинаешь понимать, что они как раз представляют собой попытку «чередовать подходы». В этих фильмах прослеживается попытка победить смыслы, разбавить и упростить сложное смехом, нелепицей и многочисленными провокациями. Кандидат психологических наук, Мария Петровна Литвиненко, руководитель Центра психологической поддержки Управления по воспитательной работе молодежи, преподаватель психологии Донской духовной семинарии, говорит об одном из мультфильмов «Академии веры» «Почему Бог Троица»:

«Здесь очень много приемов манипуляции сознанием, четкой, грамотной… Идет антиреклама, ложные понятия исподволь внедряются в сознание. Понятия становятся размытыми, запутанными. После фильма, в целом, нет ничего точного, нет ничего истинного».

В январе 2019 года православная общественность попыталась предотвратить включение фильмов «Академии веры» в образовательное пространство. Священноначалию было направлено письмо, экспертную оценку дал кандидат богословия, зав. каф. теологии ПСТГУ П.Ю. Малков[5], в марте 2019 года прошел круглый стол «Святыни на экране. Христианские ценности и язык кинематографа». Но десять фильмов проекта всё же вошли в учебно-методический комплект для воскресных школ. Единственное, что было сделано, – из фильмов были вырезаны слова «харрасмент» и «расчленёнка». В течение двух лет сохранялась надежда, что создатели не остановятся на этой косметической правке и серьёзно, глубоко переработают все недопустимые для православной традиции и даже кощунственные образы, но этого не произошло.

По сути, ответ команды «Академии веры» её критикам аккумулируется в следующем размышлении:

«Когда у человека в теле есть мышечный блок, спазм, сначала человеку некомфортно, а потом происходит так называемая компенсация, и человек привыкает к тому, что он ходит, немножко подволакивая ногу, или шея у него перекручена. И даже если хороший мануальный терапевт начнет поправлять, то это долгий и болезненный процесс, потому что организм уже привык к такому ненормальному положению. Реакция на наш проект говорит о том, что мы начали разрабатывать, массировать очень болезненный духовный спазм, который препятствует тому, чтобы мы были продуктивны в деле просвещения и миссии»[6].

Переведём этот образ на обычный язык: человек, укорененный в традиции, оказывается, глубоко болен, он находится в «искаженном» состоянии, и это положение мешает христианской миссии нормально развиваться. А вот проект «Академия веры» – это своего рода терапия, помогающая освободиться от болезненных оков традиционализма… То есть протоиерей Павел Великанов и его команда (среди которых можно упомянуть иереев Стефана Домусчи, Анатолия Колота, Антония Борисова, диакона Илию Кокина и некоторых других соавторов «Академии веры»), великодушно берут на себя роль мануальных терапевтов по отношению к «больным», то есть к традиционно верующим православным христианам, диагностируя их мировоззренческие «болезни» и принимаясь за их «излечение».

19 февраля 2019 года в эфир вышла передача «Ответ священника»[7]. В самом начале выпуска ведущая знакомит зрителей с «уникальным спецпроектом» – «Академией веры». Прот. Павел говорит:

«Мы решили не бояться задавать вопросы и провоцировать людей». «Как мастерски Христос упаковывал глубочайшие смыслы в Своих притчах!»

На уже упоминаемых курсах для университетского духовенства протоиерей Павел рассказал о задачах и специфике проекта «Академия веры». Вновь обратимся к его собственным высказываниям (с учётом того, что перед нами – живая речь):

«Очень скандальный проект – “Академия веры”. Знаете, в фильмах про ковбоев бывает иногда такой эпизод, когда он крутит на пальце кольт – и вдруг ба-бах! – где-то сзади падает труп… Вот это – то самое ощущение, которое мы пережили с этим проектом. Мы не хотели никого трогать, задевать, создавать кому-то проблемы, мы с большим трудом получили президентский грант на этот проект, пришлось привлечь дополнительные средства. Просто хотелось сделать проект, который был бы адресован прежде всего старшим подросткам, молодым студентам».

В интервью журналу «Сноб» 3 апреля 2019 года о. Павел сообщил:

«Мы никогда не позиционировали свой ресурс как катехизаторский или педагогический»[8].

Но в течение двух последних лет 10 фильмов и инфографика данного проекта были в УМК «Приходская школа «под ключ»!

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

«Можем ли мы что-то такое сделать, чтобы этих подростков, у которых выработан устойчивый иммунитет ко всему церковному, снова перезагрузить? <…> Наша задача – заинтересовать. Отчасти мы посматривали на технологии удерживания внимания при компьютерных играх. В итоге нами были подготовлены вместе со студентами ВГИКа 40 мультипликационных фильмов, за которые мы очень сильно огребли от православного сообщества. Огребли отчасти справедливо – я даже признаю, какие-то моменты, по здравом рассуждении, мы посмотрели и поняли, что тут, конечно, мы где-то перегнули палку».

Вопрос из зала:

«А они еще есть пока, их можно посмотреть?»

О. Павел (приглушенным голосом):

«Да, да, да, есть, пока ещё есть, пока ещё не закрыто, отче. Их можно скачать, можно распространять… но лучше не надо».

О работе со студентами ВГИКа он говорит:

«У них был шок. Потому что в процессе этой работы тот самый кокон, обволакивающий нас как православных, как священников, как Церковь – он просто разлетелся вдрызг. Они вдруг увидели в Церкви людей думающих, живых и честных. Эти три вещи для них были открытием».

Получается, что до встречи со студией «Богослов» думающих, живых и честных христиан студенты никогда не видели.

«Когда они начинают работать, они заинтересованы в первую очередь материально – естественно, мы платим, – но при этом содержательно и в смысловом отношении мы предоставляем им полную свободу: мы сказали – рисуйте что хотите, мы с краешку только будем посматривать и… где-то какие-то вещи мы чуть-чуть недосмотрели».

Не очень верится в это «чуть-чуть». Во-первых, текст диктора сочиняли сценаристы – авторы «Академии веры». Что это за тексты, можно увидеть ниже. Во-вторых, есть разница между «предоставить свободу» и «с краешку посматривать». Можно было бы очертить горизонты, вдохновить на бережное прикосновение к православной традиции, но очевидна позиция самоустранения создателей портала.

Предлагаем теперь самим читателям оценить, что «думающие, живые и честные» богословы предлагают старшим подросткам и молодым студентам. Возьмём самые яркие примеры «нового» способа подачи православного вероучения в нескольких анимационных фильмах проекта «Академия веры».

В уже упомянутой рецензии П.Ю. Малкова достаточно глубоко проанализированы догматические вопросы, поэтому мы обратимся к ним с точки зрения психологии восприятия, к оценке образного ряда, который прямо или косвенно влияет на зрителя, взглянем на проект, который, по словам о. Антония Борисова, является «привлекательным, удобным путеводителем по сокровищнице православной веры»[9].

1. Анимационный фильм «Почему Бог Троица»
(автор сценария — диакон Илья Кокин)

Мультфильм о Троице начинается с вопроса: что вы представляете, когда слышите слово «Троица»? На экране мелькают три богатыря с картины Васнецова, три античных скульптуры, египетские божества. .. и кадр из фильма «Матрица», образ Тринити, фиксирующий на себе внимание зрителя. Разговор о самой главной Божественной тайне в Православии начинается с изображения затянутой в черную кожанку героини фильма (00:00:16-00:00:32). Как объяснить то, что формальное сходство в имени стало для авторов отправной точкой повествования о самом священном?

Дальше на экране возникает икона св. Андрея Рублева «Троица», сменяющаяся стилизованным, совсем не иконописным образом: сидящие вокруг престола Ангелы изображаются в мультяшном виде.

Начинается спор со святым иконописцем, который длится примерно половину фильма. Авторы пытаются опровергнуть утверждение, что икона св. Андрея Рублева указывает на тайну Троицы. Они толкуют явление Путников Аврааму как явление Сына Божия и двух ангелов.

Небольшой экскурс в историю. В святоотеческой традиции первых столетий ещё не было окончательной ясности в вопросе о том, Кто же явился Аврааму – Три Лица Пресвятой Троицы или же Сын Божий вместе с двумя ангелами. Среди святоотеческих суждений той эпохи, конечно же, присутствовали и те, которые представлены выше авторами фильма, – однако, по большей части, так думали в доникейский период, то есть в первые три века существования Церкви. В классическом богословии эпохи Вселенских Соборов именно та точка зрения, что Аврааму явилась Пресвятая Троица, стала для Церковного Предания основной. Причем не только для святых отцов, но и для православной иконописной традиции – как в Византии, так и на Руси. Ведь не случайно же величайшая и драгоценнейшая (как для русского церковного искусства, так и для всей отечественной культуры) икона, принадлежащая кисти прп. Андрея Рублева, ясно именуется образом Пресвятой Троицы! Протоиерей Павел Великанов, занимавший в то время, когда создавался этот фильм, должность заведующего кафедрой богословия МДА, не мог всего этого не знать. Что же заставило его выпустить фильм, где в качестве неоспоримой истины и единственно правильной точки зрения представлено мнение отдельных ранних отцов, а более зрелое и общепринятое свидетельство Церкви безапелляционно отвергнуто? Какой миссионерский смысл имеет это отрицание церковной традиции? Чем, собственно, позиция авторов «Академии веры» может быть более привлекательной для молодежи, чем богословие Святой Троицы, предложенное преподобным Андреем Рублевым?

Обращает на себя внимание и то, каким образом происходит визуализация авторской идеи на экране.

К Аврааму направляются три Ангела, один воздевает руки к небу, а сбоку стоит насмешливо хихикающая Сарра (00:01:27-00:01:29).

Во время слов диктора «а вот то, что произошло после, никак не укладывается в сюжет о явлении Святой Троицы» (00:01:27-00:01:34) на экране возникает тетрис, головоломка с геометрическими фигурами. Диктор сообщает: «Двое путников отправились в Содом…».

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

«…где подверглись, ну… харассменту. А чего еще было ждать от содомитов?»

Слово «харассмент» здесь означает сексуальное домогательство с попыткой изнасилования. Анимационная картинка на экране изображала толпу серых фигур (жителей города Содома), устремляющихся к дому, в который только что вошли два ангела. Затем (в изначальной версии фильма) ангелы выходили из дома с покрасневшими щеками и печальными лицами, держа в руках плакаты с надписью «#MeToo».

«Me too» – «хештег», постулирующий осуждение любых сексуальных домогательств и насилия. Из новой версии фильма исчезли хештег и слово «харассмент», но осталась фраза:

«Проблема здесь даже не в пикантности самой ситуации, а в том, что мы называем Святую Троицу Единосущной, Единой и Нераздельной» (00:01:42-00:01:51).

Тема сексуального насилия в фильме являлась тизером (англ. «дразнилка, завлекалка») – это рекламное сообщение, служащее для создания интриги. Вероятно, именно поэтому авторы все же решили оставить фразу, свидетельствующую о «пикантности ситуации». Эта фокусировка авторов на определенной тематике вызывает серьезные вопросы к создателям проекта. Для свидетельства о Троице эти акценты совершенно не нужны.

Совершившиеся в Содоме события, участниками которых оказались посетившие Авраама Путники, происходили совсем не так, как это представляют авторы фильма, и та аргументация, которую дальше приводят авторы, не выдерживает никакой критики, – об этом подробно пишет П. Ю. Малков в своей рецензии. А мы вернемся к изобразительному ряду фильма.

На экране снова возникает игровая приставка, где три сердечка освещают шествие зайчика к сундуку. Диктор сообщает:

«Чтобы хоть приблизительно понять христианское учение о Троице, попробуем ответить на два ключевых вопроса: как и зачем» (00:02:53-00:03:03).

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

На вопрос, «как» у Трех Лиц может быть одна общая природа, предлагаются следующие ответы-аналогии: падающий на голову человека кирпич (человек от удара пригибается к земле) и… чашка капучино, в которой соединяются кофе, молоко и сахар (00:03:33-00:03:57). Брови изображенного на экране игриво взлетают, и звучит абсолютно неуместная грустная шутка: «Чашка одна, а хочется три»… Одинокая слеза, стекающая при этом по щеке человека, отсылает зрителя к дешёвой мелодраме. И этот стёб посвящён тайне Божественного Триединства?

Диктор говорит: «Подобные формальные примеры мало что объясняют». Но эти слова являются прикрытием, потому что запомнится именно визуальный ряд.

Далее на экране открывается интернет-страничка, где апостол Иоанн Богослов печатает: «Бога никто никогда не видел» (00:01:56-00:02:04). Под рубрикой «Hot news» цитата из Библии: «Сотворим человека по образу Нашему и по подобию Нашему» (00:04:07-00:04:19). Откровения Священного Писания превращаются в газетную сенсацию.

Христианские толкователи на экране напоминают то ли «Ералаш», то ли «Крокодил», но все же больше они похожи на монахов-иезуитов в прошлом (00:04:20-00:04:32).

Это удивительно, но свидетельства Нового Завета о Пресвятой Троице в фильме вообще отсутствуют! Очевидно, спор со святым Андреем Рублевым для создателей фильма оказался гораздо важнее. Неужели эти богословы от мультипликации никогда не слышали о том, что прп. Андрей Рублев изобразил библейскую сцену именно в свете новозаветного учения о Святой Троице?

В статье о. Павла Великанова, опубликованной на сайте МДА[10], говорится:

у человека «уже есть представление о том, что могут сказать эти “церковники” о Троице: это будет скучно, нудно, елейно, предсказуемо и назидательно. И, когда он видит, что здесь что-то принципиально иное – и это совершенно не вписывается в тот шаблон, который есть у него в голове – он заинтригован! Вот такого рода демифологизация, конечно, вещь рискованная, опасная и мы понимаем, что где-то мы идем по лезвию бритвы, где-то мы можем быть на грани, всячески стараемся не переступить эту грань допустимости. Мы же понимаем, что все эти грани существуют исключительно в сознании людей, которые все это смотрят. То, что для одного человека является вполне нормальным и приемлемым, для другого является хулой на Духа Святого и тяжким кощунством».

Это программные тезисы. Для создателей проекта грань допустимости существует только в сознании людей, то есть она субъективна; якобы в реальности, т.е. объективно никаких граней нет. Есть лишь человеческие мнения, ни одно из которых не может претендовать на истину. И если невозможно установить грань между приемлемым и кощунственным, следовательно, допустимо всё, что «интригует», завлекает.

Нет, есть одна чёткая граница. Это граница, которой авторы «Академии веры» отделяют себя от церковного сообщества: вы скучные и занудные, а мы вот сейчас проведем демифологизацию… Священного Предания Церкви, не побоявшись оказаться на грани богохульства.

В передаче «Ответ священника»[11] о. Павел предлагает дополнительный, весьма специфический образ того, что такое хула на Духа Святого:

«Представьте себе большой симфонический оркестр, и вот в него вводится некий новый артист. Партитуры нет ни у кого, все знают наизусть свою партию, а у него тоже нет нот. Вот он начинает играть, и тут два варианта развития событий: либо он внимательно вслушивается в то, что происходит, начинает подстраиваться… <…> Либо смотрит на все это и говорит: “Слушайте, какую ерунду вы играете? Вот сейчас я вам покажу, как надо играть!” И начинает наяривать то, что ему в голову придет и что резко диссонирует со всем, что происходит. “Я-то знаю, как правильно, это вы все не знаете. ..”. Что будет делать нормальный дирижёр? Он сначала его постарается как можно дальше убрать, отдалить; если он будет усердствовать, он попросит охрану, чтобы его перевели в отдельное изолированное помещение, пусть там играет сколько хочет, но пусть не портит этот оркестр. Вот это и есть состояние хулы на Духа Святого. Это абсолютная уверенность в собственной правильности, несмотря на то, что всё, что происходит вокруг, тебя уверяет в том, что – “слушай, голубчик, а может, ты всё-таки не совсем прав?”» (00:38:16-00:39:25).

Раскрывать предложенный образ можно по-разному. Если под «симфоническим оркестром» мы будем понимать голос святых отцов, то хочется спросить отца Павла: «Слушай, голубчик… и т.д.». Если же под образом оркестра о. Павел предлагает понимать дух века сего, которому надо подпевать и подстраиваться, чтобы не «портить оркестр», тогда можно вспомнить свт. Афанасия Великого, прп. Максима Исповедника или свт. Марка Эфесского, которые оказывались в абсолютном меньшинстве, обличая фальшь окружавшей их «симфонии», мужественно противостоя проникновению еретического духа в церковное сознание.

2. Анимационный фильм «Что такое Священное Предание?»
(автор сценария — Алексей Пищулин)

Первые слова, которые слышит и видит зритель в фильме, это слова Чацкого из хрестоматийного произведения: «Свежо предание, да верится с трудом» (00:00:14-00:00:24). Неплохое начало для разговора о священном?

«Предание – это всегда и неизбежно пересказ», — сообщает диктор, и в подтверждение этого четыре бабули на экране воплощают собой «сарафанное радио» (00:00:24-00:00:34).

Потом на экране появляется апостол Павел с выпученными глазами, и в облачке представлены его слова: «Правду говорю!» Данный видеоряд сопровождается комментарием диктора: «Главным подтверждением правдивости был он сам – его глаза, сила его убеждения» (00:01:41-00:01:51). Что это, как не очередная насмешка – ведь именно неадекватное выражение глаз и выскакивающая сбоку фраза превращают изображение апостола в карикатуру.

В фильме зрителю постоянно внушают, что умный человек не станет верить небылицам. Сначала сообщается: «Сегодня Предание является таким же существенным источником наших знаний о Боге, как и Священное Писание» (00:03:01-00:03:08). На экране изображены весы, чашечки которых уравновешены. А дальше развивается мысль о том, что есть «принципиальное различие между ними». Авторы поясняют:

«Тексты, которые в итоге составили свод Нового Завета, прошли сквозь критический фильтр <…>. А вот предания стихийно возникали и распространялись на протяжении веков на огромных пространствах крещеного мира и при этом самым демократическим способом: послушал — передай дальше. Не расслышал? — не беда! На то тебе и даны творческие способности. Поэтому велика вероятность попадания в первоначальную версию <…> нелепостей. Да и богословский уровень рассказчиков, их элементарная грамотность тоже бывала разной» (00:03:14-00:04:23).

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

Авторы смешали всё это воедино и назвали общим именем: «Священное Предание». Они вообще уравнивают содержание Священного Предания со сказочным фольклором, былинами и поговорками:

«Так надо ли почитать Священное Предание? Безусловно, надо!… В нем коллективная память церковного народа. Точно так же ученые веками берегут и изучают сказочный фольклор, народный эпос, былины и поговорки» (00:04:24-00:04:46).

Священное Предание – это не коллективная память, а свидетельство святых о Боге, отраженное в коллективной памяти не «церковного народа», но Святой Церкви.

На последних секундах фильма на экране возникает еще один образ – изображение Земли.

«Писание и Предание вместе образуют единое целое, как планета и ее атмосфера с облаками – то в форме небесных гор, то в форме ангельских крыл. Предание – это накопившаяся за два тысячелетия атмосфера, которая окружает драгоценное ядро: изначальную кристальную простоту и ясность Божьего слова».

Петр Юрьевич Малков в своей рецензии раскрывает этот образ, объясняя, что собственно хотят донести до нас авторы фильма. Кристально простое и ясное Писание – твердая почва, на которой основывается наша вера, а Предание – это облачные воздушные замки, ненадежная реальность, наполненная фантазиями и элементами фольклора. Предание перемещается авторами фильма из области Богооткровенной в область поэтическо-эстетическую и оказывается просто неким культурным феноменом. Подобный подход к пониманию значения Священного Предания – абсолютно протестантский. В идеологии фильма, как и в протестантизме, спасительным значением для христианина обладает только одно Писание: Sola scriptura. Предание же — это лишь интерпретация содержания Божественного Откровения слабым человеческим умом, полная ошибок, противоречий, фантазий, фигур речи и элементарной средневековой дикости. Автор и податель Предания здесь уже не Бог, не Дух Святой; его авторы и «выдумщики» — лишь сами христиане.

Что после такой трактовки можно сказать о создателях фильма? Лучше всего скажут они сами – в фильме «Достаточно ли одной Библии?» на экране возникает кадр, где Священное Предание включает в себя «труды современных богословов» (00:02:40). Именно о таких трудах и можно сказать: «Свежо предание, да верится с трудом»…

3. Анимационный фильм «Есть ли христианство за границами православия?»
(автор сценария — Алексей Пищулин)

После слов диктора: «Есть ли христианство за границами православия?» на экране возникает неадекватное по выражению лицо человека, задающего этот вопрос.

Диктор продолжает:

«Хочется уточнить – а к кому этот вопрос? Если к Богу, то ответ может прозвучать неожиданно резко: «Не ваше дело» (00:00:19-00:00:30).

Приводимый далее в фильме пример с Иовом совсем не соответствует контексту вопроса. Авторы фильма отказывают всякому, кто хочет обратиться к Богу в поиске истины, в самой возможности обращаться к Нему с таким вопросом. Здесь вновь происходит смысловая подмена: понятие о непостижимости Бога и его Промысла выдают за невозможность присутствия Истины в какой бы то ни было конфессии. Сам факт существования конфессий преподносится не как следствие отпадения от истинного исповедания и верного пути духовной жизни, а как результат Промысла Божия, в который человеческое познание не должно вторгаться. Ответ Бога соотносится с изображением громкоговорителя, появляющегося на экране, и с кадром из советского фильма, где мужчины выясняют между собой отношения на фоне текста:

«Смысл этого ответа был именно таким: а ты вообще кто такой, чтобы спрашивать?» (00:00:46-00:00:51).

Невольно вспоминается ответ диакона Ильи на критику УМК «Приходская школа «под ключ» в его статье «Суд любви или суд Линча»:

«Вы, собственно, кто такие? Кем вы себя возомнили?!»

А ещё вспоминается приём, который применил о. Павел в уже упоминаемой статье[12]:

«Смотреть то, что мы сделали, для глубоко воцерковленного, благочестивого, консервативно настроенного человека — невыносимо. И это нормально, потому что не он адресат! А вот дальше происходит самое неприятное. Этот человек считает себя вправе оценивать и становиться судьей проекта, который не ему адресован. В этом и видится огромная опасность тоталитарной идеологии – когда Православие вместо открытого состояния веры и вдохновенного поиска, как рассказать другим об этом, превращается в жесткую идеологему. Вот как только Православие превращается в идеологию, оно тотчас начинает искать врагов. Или даже создавать их».

Воцерковлённый человек, который свидетельствует об истине, хранимой в Церкви, и указывает на искажение этой истины, обвиняется в тоталитаризме! А кем тогда были отцы Вселенских Соборов, которые боролись с ересями?! И кому, собственно, адресован этот проект, если на него можно попасть прямо с сайта Московской духовной академии? Неужели и ученикам духовных школ опасно быть воцерковленными и благочестивыми?

Авторы заменяют Бога на фреске Сикстинской капеллы летающим Макаронным монстром (речь о пародийной религии Бобби Хендерсона). Адам здесь протягивает руку не к Творцу, а к жуткому осьминогу. А вы, консерваторы, молчите! Это не вам адресовано, а тем, кто наконец освободился от жестких, православных идеологем!

Апология такого подхода заложена в текстовке фильма:

«…Каждого, кто оказывался вне консенсуса, так легко и удобно было сходу обзывать Иудой. И взаимные проклятия летали над головами спорящих, как бумажные самолетики» (00:01:57-00:02:09).

На экране – протопоп Аввакум, Генрих VIII (казнивший своих жен) и Лютер. В этом месте вспомнилась строчка из книги диакона Илии «Страх возводит стены, любовь строит мосты»:

«Ересифобия – страх перед идеями, отличными от общепринятых».

Хазарский каган спрашивает св. Кирилла, просветителя славян: «Почему наши мудрецы согласны между собой в видении веры, а ваши спорят? И каждый видит правду по-своему?» (00:02:15-00:02:27). Во время произнесения этих слов на экране в воздухе возникают две фигуры христианских священников, похожие на игрушечных: они бьют друг друга посохами по голове, лепеча по-детски и прыгая от удовольствия.

Ответ св. Кирилла таков: ваш бог похож на маленький, неглубокий и прозрачный бассейн, а наш – как безбрежное бурное море.

«Наивно, а то и бестактно спрашивать Бога о том, кто из спорящих о Нем более прав. Это все равно, как при оглашении наследства ерзать на стуле в ожидании, пока прозвучит твое имя и ревниво прикидывать, что же может достаться другим братьям и сестрам» (00:03:16-00:03:34).

Этот текст произносится диктором под звуки балалайки, которые весело звучат на фоне дележа репки дедом и бабкой.

Дальше озвучивается мысль о не-единстве Церкви:

«Да, к несчастью, Церковь, ступая по брусчатке веков, теряла единство. Его нарушали расколы, инакомыслие, географические факторы, исторические катаклизмы» (00:03:56-00:04:06).

Получается, что в некоторые времена Церковь не была единой. В статье «УМК “Приходская школа ‘под ключ’» или ключ от ящика Пандоры?” говорилось о том, как в фильме «Кто такой Бог?» происходит ниспровержение веры в Бога как Вседержителя (первый член Символа веры). Теперь ниспровергается девятый член этого Символа: «Верую во единую, Святую, Соборную и Апостольскую Церковь». Прослеживаете преемственность – от воскресной школы к высшему духовному образованию?

Несмотря на эту преамбулу в тексте, далее звучит:

«Единая Церковь была построена руками апостолов и первый из них, Петр, стал епископом Рима» (00:04:07-00:04:15).

Вообще-то создание Церкви – не человеческое дело, это дело Христа. Дальше идет речь о расхождении между Западом и Востоком, о Лютере (на фоне шприца и клизмы) и расколе в Русской Церкви в XVII веке. И перед нами вновь возникают игрушечные священнослужители, пытающиеся найти равновесие на качающейся доске.

«Но значит ли это, что сегодня каждый может потребовать огласить весь список и погрузиться в изучение меню, выбирая себе веру как десерт?» (00:04:43-00:04:53).

Ответ «нет» обусловлен в фильме совсем не тем, что Православие хранит истину.

«Выбор веры состоялся однажды, и ставить его под сомнение сегодня — значит отрекаться от своего народа, от предков, от общей судьбы с теми, кто в земле и на небе помнит и молится о тебе. У нас есть выстраданное осознание того, что наша вера правая…» (00:04:57-00:05:18).

Верность предкам – разве это аргумент, разве именно этот критерий является принципиально важным в вопросе поиска истины? Значит, и язычник пусть остается язычником, иудей – иудеем, еретик – еретиком, ведь нельзя же «отрекаться от своего народа»? Хочется спросить наших толерантных миссионеров, а зачем тогда вообще миссия, если нельзя ставить под сомнение веру предков?

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

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

«Если и есть какое-то соревнование между нами, то лишь состязание в великодушии. В итоге тот из нас будет правильно славить Бога, кто больше преуспеет в деле милосердия и любви» (00:05:23-00:05:38).

Главная мысль фильма – о верности памяти предков и делах милосердия. О догматах веры в фильме речь вообще не идет. Авторы намекают: не стоит задаваться вопросом об Истине – причиной разделений являются лишь мелочные споры людей.

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

4. Анимационный фильм «Есть ли в христианстве мистика?»
(автор – диакон Илья Кокин)

Фильм начинается фразой:

«Как было бы здорово связаться с Богом напрямую, заполучить Его телефон» (00:00:16-00:00:21).

«Библия говорит, что подобный телефон был у иудейских первосвященников, он назывался урим и туммим. Это было что-то вроде жребия, монетки, которая падает орлом или решкой, что означает “да” или “нет”. Урим и туммим навсегда утрачены, но у нас остался еще один способ обратиться к Богу напрямую. Об этом способе свидетельствуют многочисленные мистики и духовидцы. Речь об особых практиках, позволяющих вступить в общение с невидимым духовным миром» (00:00:43-00:01:23).

На карте последовательно возникают: даосизм, бхакти, суфизм, каббала, исихазм. Апофеозом становится идея о том, что

«каждая из перечисленных школ как бы угадала по одной цифре в телефоне Бога» (00:03:00-00:03:06).

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

Оказывается, вот что нужно, чтобы гарантированно выйти с Богом на связь, – объединить практики мистиков всех религий… и тогда мы получим точный «номер телефона» Бога! Где-то, кажется, у мадам Блаватской и Рерихов, мы такое уже слышали…

«В православном исихазме мы находим немало общего с этими мистическими школами – как формально (контроль над дыханием, особые положения тела, концентрация внимания в области сердца, использование схожей терминологии и т. п.), так и содержательно – отрешение от мирского, очищение ума от низменных помыслов, трезвение, созерцание Божественного света, поиск благодатного единения с Господом – обожение» (00:03:53-00:04:24).

Во время речи об особых положениях тела парень на экране совершает разнообразные физкультурные кульбиты. Концентрация внимания в области сердца иллюстрируется изображением процедуры УЗИ. «Схожая терминология» разных мистических школ представлена мемами из интернета, особенно поражает «LOL» (это калька с английского акронима laughing out loud, то есть «громко, вслух смеясь»).

Вы не видите здесь никакой связи с исихазмом? Проблема-то в вас! Ведь эту связь проследили «думающие, честные и живые богословы».

Кстати, кто и над кем здесь громко, вслух смеётся? Уж не авторы ли над зрителями?

Шутка шутке рознь. Несколько слов о специфическом юморе авторов проекта. В мае на уже упоминаемых курсах повышения квалификации о. Павел Великанов рассказал о самой популярной игре на сайте «Академия веры»: «Матушка, собери батюшку на служение Евхаристии» (точнее, игра называется «Собери клирика на служение Евхаристии» – Авт. ). Игра была представлена в следующей интерпретации:

«Вам надо собрать три коробочки – православного батюшку собирает матушка, католика собирает… не матушка, а вот протестанта… нет, надо по-другому… Служащую матушку собирает не батюшка, а муж». Смех в зале.

Занавес, господа консерваторы!

Дальше в фильме на чашу весов с надписью «исихазм» со свистом (!) падает понятие «умная молитва», что перевешивает все остальные мистические школы… Самое страшное, что модернистские провокативные идеи незаметно, исподволь вбрасываются в традиционные тексты. В фильме далее кратко сообщается о разнице между мантрой и молитвой, о настороженном отношении к созерцанию света. Об очищении сердца вообще говорится мельком, походя, чтобы формально соблюсти все приличия.

«Главное, что доказали подвижники-исихасты: для общения с Богом не нужен телефон, ведь само это слово означает возможность общения с кем-то далеким, “теле-” — “далекий”, “фон” — звук, а с Богом можно общаться в собственном сердце. Но для этого сердце нужно сначала очистить от зла» (00:05:28-00:05:56).

В заключительных кадрах на экране мы видим бессменный телефон с надписью: «Связь установлена, БЕЗЛИМИТ»…

Таким образом, приведённые примеры позволяют сделать вывод о том, что концепция представленных фильмов — это сочетание гностицизма, нигилизма и синкретизма, оформленная в стилистике постмодерна. Эта «гремучая смесь» подаётся как необходимость приспособления к взглядам на мир современной молодёжи, как попытка говорить на её языке. В рамках дискуссии на круглом столе еще два года назад о поиске понятного языка сказала Ирина Николаевна Гращенкова, киновед, кинокритик, историк кино:

«Мне думается, что надо все-таки говорить не на языке молодежи, а на языке для молодежи. Это не одно и то же».

Патриарх Московский и всея Руси Кирилл, отвечая на вопросы участников и гостей VIII Международного фестиваля «Вера и слово», недвусмысленно сказал, что миссионерский успех священника в работе с молодежью не определяется тем, насколько близок язык их проповеди к языку молодежи:

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

Итог:

Рассказ про артишоки у о. Павла заканчивается следующим рассуждением:

«В отличие от нас, человеков, Бог бесконечно деликатен. Он не только не срывает наших одежд и не бесчестит нас наготой, но и приглашает на Свой пир – где одевает, укутывает царскими облачениями Своей милости и красоты. Ведь только когда поверишь, что незаслуженно оказавшееся на твоих плечах роскошное одеяние больше не отберут, – только тогда тихо, незаметно, из-под полы выбросишь все пропахшие неправдой и грехом свои прежние одежды»[13].

Трудно сказать, каким переводом Евангелия руководствовался о. Павел при составлении этого текста. Судя по всему, своим собственным. В евангельской притче о брачном пире никто «из-под полы» прежние одежды не вытаскивал. Согласно восточной традиции, званые на пир перед праздником надевали брачные одежды, а если они не имели своих праздничных одежд, то получали их при входе. Быть на пиру в грязной одежде значило с презрением отнестись к хозяину дома: мол, я пришёл есть и пить, а до тебя мне нет дела. Царь из притчи Христа не накидывал роскошных одежд на человека, который посмел таким образом прийти на пир. Он спросил человека не в брачной одежде: «Друг! Как ты вошел сюда?» Но тот молчал, не имея никакого оправдания. За свою дерзость он был связан и выброшен вон с царского пира, без какой бы то ни было «деликатности». Притчу Господь закончил словами: «Много званых, а мало избранных».

Своеобразная авторская трактовка притчи свидетельствует о том самом «изменении угла зрения», которое присутствует в книге «Искусство игры с миром. Смысл победы в победе над смыслами».

Поражает отсутствие страха Божия у авторов проекта, которые считают, что можно соединять «пикантность» с темой о Пресвятой Троице, а изображение зомби – с темой Литургии[14]… Подменять Священное Предание – фольклором, а Творца – макаронным монстром, смешивать мистические практики разных религий и сравнивать Пресвятую Богородицу с героиней комиксов[15]… И при этом оставаться в полном убеждении, что Небесный Царь будет деликатно всё это терпеть!

Когда авторы «Академии веры» обращаются к тем, кто «прошел уровни» – грамматика, ритора, философа — и дошел до четвертого, «богословского» уровня («Вот это да! Вы уже на уровне Богослова! Это сильно! Ну а теперь держитесь! Вы уже достаточно выросли, чтобы поговорить на сложные темы…»[16]), вспоминается пример из книги «Несвятые святые».

«Как-то к отцу Иоанну (Крестьянкину) подошел важный молодой человек, выпускник духовной академии, и, представляясь, между прочим заявил:

– Я – богослов!

Отец Иоанн очень удивился и спросил:

– Как – четвертый?

– Что – “четвертый”? – не понял академист.

Отец Иоанн охотно пояснил:

– Мы в Церкви знаем трех богословов. Первый – святой Иоанн Богослов, апостол и любимый ученик Спасителя. Второй – Григорий Богослов. И третий – Симеон Новый Богослов. Только им святая Церковь за всю свою двухтысячелетнюю историю решилась усвоить имя “Богослов”. А вы, значит, четвертый?»

Есть принципиальная разница между провокацией и парадоксом, дерзостью и дерзновением. По словам авторов проекта, прозвучавшим на круглом столе, а также в видеопередачах и многочисленных публикациях, творение «Академии веры» – «дерзость» и «провокация». Если это останется сознательной позицией богословов «Академии веры», то вопросы будут только множиться. В том числе вопросы о том, кто, что и каким образом преподаёт студентам духовных школ, будущим пастырям, будущим православным миссионерам? И что, собственно, у нас происходит с христианским просвещением? Почему очередной «просветительский проект» становится очередным искажением вероучительных и нравственных основ нашей веры?

Если случится, что создатели проекта удалят из интернет-пространства все кощунства и провокации, переработают коренным образом сюжеты и откажутся от самой идеи «упаковывать» смыслы Православия в обертку постмодерна, тогда… Тогда ни у кого не будет вопросов к группе знатоков экзотических яств, расположившейся весенним утром где-то на далеком побережье.

Кодировка UTF-8 в электронных письмах, разбор тела

Кодировка =22 на самом деле не имеет ничего общего с кодировкой (будь то строчная UTF-8, прописная UTF-8 или любая другая кодировка).

Это кодировка Content-Transfer-Encoding: quoted-printable .

Кодировка для печати в кавычках — это просто способ октетов шестнадцатеричного кодирования, обычно ограниченный октетами, выходящими за пределы диапазона ascii для печати. Кажется странным, что символ DQUOTE будет закодирован таким образом, но это совершенно законно.

Если вы хотите искать строки в теле сообщения, вам необходимо сначала декодировать Тело сообщения. В противном случае вы не добьетесь успеха.

Я бы порекомендовал прочитать rfc2045 как минимум.

Возможно, вам также понадобится прочитать rfc2047 , если вы в конечном итоге захотите поискать заголовки в какой-то момент, но это становится … хитрым из-за различных ошибок, которые имеют отправляющие клиенты.

Теперь, когда меня «вызвали» в разглагольствования по поводу MIME, позвольте мне Объясните, почему декодирование заголовков так сложно сделать правильно. Я уверен, что почти каждый разработчик, который когда-либо работал над почтовым клиентом, мог бы сказать вам об этом, но я думаю, что я буду тем, кто сделает это.

Вот лишь краткий список проблем каждый разработчик сталкивается, когда он go должен реализовать декодер для заголовков, которые (теоретически) были закодированы в соответствии со спецификацией rfc2047:

1. Во-первых, технически существует два варианта кодирования заголовка форматы, определенные rfc2047 — один для фраз и один для неструктурированных текстовых полей. Они очень похожи, но вы не можете использовать одни и те же правила для их токенизации. Я упоминаю об этом, потому что кажется, что большинство парсеров MIME пропускают это очень тонкое различие и, как вы можете себе представить, делают большинство генераторов MIME. Черт, большинство генераторов MIME, вероятно, даже никогда не слышали о спецификациях, для начала это кажется.

   Это подводит нас к следующему:

2. Существует множество вариантов сбоя заголовков MIME. быть токенизируемым в соответствии с правилами rfc2822 и rfc2047. Вы встретите забавные вещи, такие как:

   a. токены кодированных слов, незаконно встраиваемые в токены других слов

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

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

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

   Вы можете увидеть некоторые примеры здесь .

3. Многие разработчики, по-видимому, упускают из виду тот факт, что каждому токену закодированного слова разрешено быть в различных кодировках символов (у вас может быть один токен в UTF-8, другой в ISO-8859-1 и еще один в koi8-r). Обычно это не представляет особой проблемы, поскольку вы просто декодируете каждую полезную нагрузку, а затем конвертируете из указанной кодировки в UTF-8 с помощью iconv () или чего-то еще. Однако из-за забавного нарушения, о котором я упоминал выше в (2 c) и (2d), это становится более сложным.

   Если этого недостаточно, чтобы вы захотели поднять руки вверх воздух и бормотание некоторых ненормативной лексики, есть еще …

4. Необъявленный 8-битный текст в заголовках. Ага. Некоторые почтовые программы просто не получили памятку о том, что они должны кодировать текст не ASCII. Так что теперь у вас есть забавный опыт смешивания и сопоставления необъявленного 8-битного текста «только Бог знает, что такое кодировка» вместе с содержанием (возможно, битых) закодированных слов.

Если вы хотите узнать, как справиться с этими проблемами, вы можете посмотреть, как я это сделал, используя C в моей библиотеке GMime , здесь: https://github.com/jstedfast/gmime/blob/master/gmime/gmime-utils. c#L1894 (в случае, если смещения линий изменятся в будущем, найдите _g_mime_utils_header_decode_text() и различные внутренние методы, которые он использует в этом исходном файле — я написал комментарии, объясняющие, как он справляется с вышеуказанными проблемами).

Или вы посмотреть, как я это сделал, используя C# в моей библиотеке MimeKit , можно здесь: https://github.com/jstedfast/MimeKit/blob/master/MimeKit/Utils/Rfc2047.cs

Для получения дополнительной информации о том, почему и как трудно работать с электронной почтой Посмотрите блог серии Джошуа Крамнера: http://quetzalcoatal.blogspot.com/search/label/email-hard

SyntaxError: недопустимый символ — JavaScript

Исключение JavaScript «недопустимый символ» возникает при наличии недопустимого или неожиданный токен, который не принадлежит этой позиции в коде.

  SyntaxError: недопустимый символ (край)
SyntaxError: недопустимый символ (Firefox)
SyntaxError: недопустимый или неожиданный токен (Chrome)
  

Имеется недопустимый или неожиданный токен, который не принадлежит этой позиции в код. Используйте редактор, поддерживающий подсветку синтаксиса, и внимательно проверяйте свой код. против несоответствий, таких как знак минус ( - ) против тире ( - ) или простые кавычки ( " ) против нестандартных кавычек ( " ).

Несовпадение символов

Некоторые символы выглядят одинаково, но это приведет к тому, что синтаксический анализатор не сможет интерпретировать ваш код. Известными примерами этого являются кавычки, минус или точка с запятой (греч. вопросительный знак (U+37e) выглядит так же).

  "Это похоже на строку";
                             

42 – 13;
                             

вар фу = 'бар';
                             
  

Это должно работать:

  "На самом деле это строка";
42 - 13;
вар фу = 'бар';
  

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

Забытые символы

Легко забыть какой-либо символ тут или там.

  var colors = ['#000', #333', '#666'];

  

Добавьте недостающую кавычку для '#333' .

  var colors = ['#000', '#333', '#666'];
  

Скрытые символы

При копировании и вставке кода из внешних источников могут быть недопустимые символы.Смотреть вне!

При просмотре этого кода в таком редакторе, как Vim, вы можете увидеть, что на самом деле пространство нулевой ширины (ZWSP) (U+200B) символ.

Установка Content-Type и специальных символов HTML

---

Процесс кодирования электронных писем со специальными символами и символами вызывает у вас затруднения?

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

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

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

Что такое кодировка символов?

Кодирование символов — это процесс написания или кодирования определенных символов в HTML, чтобы они отображались должным образом, независимо от устройства, веб-браузера или почтового клиента. Это делается путем назначения номера или кода. Когда у вас нет надлежащей кодировки электронной почты, вы видите неожиданные символы и пустые поля.

В наборе символов содержится определенная группа символов (charset=» »  в HTML-коде).Каждый из этих символов представлен фрагментом кода, который используется в качестве ключа для воспроизведения символа на экране.

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

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

Пуленепробиваемое кодирование электронной почты HTML

Если вы хотите быть на 100 % уверены, что весь текст правильно отображается в строке темы и тексте ваших электронных писем, самым безопасным решением будет преобразование специальных символов и символов в их объекты HTML .

Как вы, вероятно, уже знаете, почти у каждого символа и специального символа есть собственное имя и номер сущности. При помещении в код объект создает символ или символ.

Эти сущности всегда начинаются с амперсанда и заканчиваются точкой с запятой. Например,   Объект HTML используется для неразрывных пробелов. Использование сущностей HTML для символов «больше» и «меньше» (< и >) может быть полезным, поскольку их можно спутать с тегами в коде.

Вот некоторые распространенные специальные символы и их объекты HTML:

Символ	Название объекта	Номер объекта
&амперсанд	03 9	&
® зарегистрированный товарный знак	®	®
фунтов стерлингов	фунтов стерлингов;	£
¡ перевернутый восклицательный знак	¡	¡

Существуют также объекты HTML для кодирования электронной почты, которые влекут за собой символы нелатинских языков, таких как китайский или греческий. Символы этих языков также могут быть представлены в Unicode. Вот несколько примеров:

Символ	Номер объекта	Unicode
光 9013 Китайский символ света 901	U+5149
א Буква иврита алеф	א	U+05D0
Δ Греческая буква дельта	Δ	U+0394
ॐ Санскритский символ Ом	ॐ	U+0950

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

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

Электронная почта на Acid от Sinch создала конвертер символов HTML, чтобы немного облегчить вашу работу. Просто вставьте свои специальные символы и символы, нажмите кнопку и получите объекты HTML, необходимые для их преобразования в теле письма.

Попробуйте конвертер символов

Что такое тип контента?

Приступая к кодированию электронной почты, вы также можете указать браузерам и почтовым клиентам, как вы ожидаете, что они будут интерпретировать различные типы символов, задав тип контента.Даже если вы конвертируете отдельные специальные символы в объекты HTML, все же разумно определить тип содержимого вашего электронного письма.

Вы устанавливаете тип контента, выбирая соответствующий набор символов. Двумя наиболее распространенными наборами символов являются UTF-8 и ISO-8859-1. Тем не менее, почти во всех случаях , вы должны использовать UTF-8 в качестве типа содержимого электронной почты.

Почему UTF-8 лучше всего подходит для кодировки символов в электронной почте?

Хотя существует множество способов кодирования символов, UTF-8 стал международным стандартом благодаря своей полноте. UTF-8 может кодировать более 1 112 000 различных символов. Это включает в себя все письменные языки, математические символы, ноты и даже смайлики, используемые в электронном маркетинге.

Проблема с использованием набора символов ISO-8859-1 заключается в том, что он учитывает только латинские буквы и символы, что исключает многие восточные символы и глифы. На изображении ниже показано, как такие символы неправильно отображаются при использовании ISO-8859-1 по сравнению с UTF-8

.

Результат справа включает набор беспорядочного текста, который представляет собой интерпретацию символов ISO-8859-1.Обратите внимание, однако, что при использовании объекта HTML специальные символы правильно отображаются как для UTF-8, так и для ISO-8859-1. Вот что делает этот метод надежным.

Где указать тип контента в электронных письмах

Если вы разрабатываете веб-сайт, вы можете указать тип содержимого или указать набор символов в метатеге, используя такой код:

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

Заголовок электронной почты содержит множество технических сведений о сообщении, включая дату, имя отправителя (от:) и получателя (кому:), а также такие сведения, как данные аутентификации электронной почты. Когда почтовый клиент видит набор символов UTF-8, определенный в заголовке, он знает, как интерпретировать символы в сообщении.

Как установить тип контента в заголовках электронной почты

Ниже вы увидите фрагмент кода определенного заголовка электронной почты, который включает в себя тип содержимого, установленный в UTF-8 внизу:

 Дата: Ср, 15 декабря 2021 г. 12:45:55 -07:00
Кому: [email protected]
От: [email protected]
Тема: UTF-8
Идентификатор сообщения: 
Х-приоритет: 3
X-Mailer: EOAMailer 5. 0.0
MIME-версия: 1.0
Контент-передача-кодирование: 8 бит
Тип содержимого: текст/html; кодировка = "UTF-8"
 

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

Вот почему Email on Acid от Sinch включает возможность устанавливать или изменять тип контента в настройках специальных возможностей автоматизированного рабочего процесса Campaign Precheck. Одним нажатием кнопки платформа гарантирует, что правильный код будет добавлен в заголовок электронного письма.

Поскольку поставщики услуг электронной почты (ESP) устанавливают тип контента в заголовке, мы добавили еще один уровень сложности в нашу разработку электронной почты.При необходимости обратитесь к своему ESP и спросите, какой тип контента они указали в заголовке при отправке писем. Как только вы узнаете тип контента, используйте это значение в своем метатеге HTML при разработке электронного письма.

В противном случае вы всегда можете положиться на надежный метод преобразования специальных символов и символов в соответствующие объекты HTML.

Поддержка почтового клиента для типа содержимого

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

Мы провели тесты, чтобы увидеть, что делали клиенты, когда в заголовке был указан тип контента, и обнаружили, что Gmail был единственным исключением. Что бы ни было обозначено в заголовке письма, Gmail — единственный клиент, который автоматически конвертирует ваш текст в UTF-8. В том числе в iOS, когда люди используют Gmail на iPhone или iPad.

Мы заметили одно интересное действие: веб-клиенты преобразовывают ваш текст в набор символов типа содержимого перед его отображением в веб-браузере. Мы смогли проверить это, просмотрев, какой тип контента они задавали в своих метатегах. Как оказалось, большинство из них используют UTF-8.

Работает ли ваша кодировка электронной почты?

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

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

Хотя вы можете отправлять ручные тесты на различные типы почтовых ящиков, устройств и браузеров, электронная почта в Acid предоставляет упрощенный способ проверки кодировки электронной почты и множества других факторов.Это включает в себя доставку, отображение входящих сообщений, проблемы с рендерингом Outlook, электронные письма в темном режиме и многое другое.

Миссия Email on Acid — упростить электронный маркетинг. Вот почему мы создаем такие инструменты, как удобный конвертер символов HTML. И именно поэтому нам доверяют знатоки электронной почты по всему миру.

Попробуйте конвертер символов

Этот пост был обновлен в феврале 2022 г. Он также обновлялся в январе 2019 г. и феврале 2017 г. и впервые опубликован в 2011 г.

Автор: The Email on Acid Team

Команда по контенту Email on Acid состоит из специалистов по цифровому маркетингу, создателей контента и настоящих фанатов электронной почты.Присоединяйтесь к нам в LinkedIn, следите за нами в Facebook и пишите в Твиттере на @EmailonAcid в Твиттере, чтобы узнать больше приятных вещей и отличных рассуждений о маркетинге по электронной почте.

Автор: The Email on Acid Team

Команда по контенту Email on Acid состоит из специалистов по цифровому маркетингу, создателей контента и настоящих фанатов электронной почты. Присоединяйтесь к нам в LinkedIn, следите за нами в Facebook и пишите в Твиттере на @EmailonAcid в Твиттере, чтобы узнать больше приятных вещей и отличных рассуждений о маркетинге по электронной почте.

Бесплатный детектор символов Unicode для текстовых сообщений

Как использовать детектор символов Unicode

С помощью этого простого инструмента вы можете мгновенно идентифицировать символы GSM и символы Unicode в своих текстовых сообщениях.Символы в кодировке GSM будут выделены серым цветом, а специальные символы Unicode будут выделены красным.

• Шаг №1: Скопируйте и вставьте текстовое сообщение в пустое поле. Символы будут автоматически отображаться в поле результатов.
• Шаг №2: Определите различные символы в вашем SMS-сообщении. Символы GSM будут отображаться серым цветом, символы Unicode — красным, а escape-символы — оранжевым.
• Шаг №3: Инструмент также подсчитывает количество символов в тексте и количество частей разделенного сообщения, что позволяет контролировать объединение.

Почему следует использовать детектор символов Unicode

Как вы, наверное, уже знаете, текстовые сообщения ограничены 160 символами, если они все из набора символов GSM. Однако, если ваш текст содержит символы Unicode, он будет ограничен 70 символами вместо 160.

Конечно, сообщения длиннее 70 символов по-прежнему можно отправлять, но они станут составными. Это означает, что 160-символьное SMS-сообщение будет разделено на три текстовых сообщения, если они содержат символы Unicode.Это может быть очень неприятно. Что еще более неприятно, так это когда телефон вашего клиента выходит из строя из-за строк символов Unicode (это действительно случалось несколько раз).

Используя детектор символов Unicode, вы можете идентифицировать и заменять символы, которые не являются частью 7-битной кодировки GSM, чтобы избежать разделения текстовых сообщений на несколько сегментов.

Почему мы создали этот инструмент

Символы Unicode не только разбивают текст, но иногда они вообще не отображаются или отображаются как страшные □ □ □.Чтобы обеспечить правильную передачу информации на SMS-шлюз, текстовые сообщения должны быть правильно закодированы. Проблема в том, что многие символы крайне сложно кодировать, а поскольку кодировку GSM 3.38 практически невозможно поддерживать, многие провайдеры решили вообще отказаться от нее.

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

Преимущества использования детектора символов Unicode

Вот основные преимущества использования нашего инструмента обнаружения символов Unicode:

• Определите символы GSM и Unicode в ваших текстовых сообщениях.
• Определите количество символов и частей в тексте.
• Основываясь на количестве символов Unicode, узнайте, будет ли текст сегментирован.
• Удалите символы Unicode и замените их символами GSM.
• Предварительный просмотр текстовых сообщений перед их отправкой клиентам.
• Управление разделением текстового сообщения, если оно содержит кодировку Unicode.

Почему текстовые сообщения, содержащие Unicode, сегментированы?

Когда вы пытаетесь отправить текстовое сообщение с символами, которые не входят в набор символов GSM, вы должны использовать Unicode, который присваивает уникальный код каждому символу, не входящему в стандартный набор символов.Поскольку для описания символа Unicode используется несколько символов GSM, вы сможете отправлять текстовые сообщения только из 35–70 символов.

Можно ли избежать сегментации текстовых сообщений и по-прежнему использовать Unicode?

Чтобы избежать сегментации SMS и преобразовать символы Юникода только в латиницу, вы можете использовать наш Транслитератор текста.

GSM описывает протоколы для сотовых сетей и мобильных устройств второго поколения. В настоящее время это стандарт мобильной связи, занимающий более 90% рынка.Следовательно, все сообщения, отправляемые на такие устройства, должны соответствовать стандартной кодировке GSM.

Если текстовое сообщение содержит символы, отличные от GSM, оно будет ограничено 70 символами . Единственное решение, позволяющее избежать разделения ваших текстов, — это проверить наличие символов Unicode и заменить их их эквивалентом в кодировке GSM (если такой эквивалент существует).

Какие символы входят в кодировку GSM?

Стандартный набор символов GSM содержит буквы английского алфавита, цифры и некоторые специальные символы, в том числе несколько греческих.

Список символов GSM: здесь

Какие символы входят в набор символов Unicode?

Список символов Unicode содержит символы из кириллического, китайского, арабского, корейского и хангыльского алфавитов. Он также содержит несколько специальных символов (таких как смайлики, эмодзи и кандзи).

Список символов Unicode: здесь

McAfee Agent не может связаться с сервером ePO или удаленным обработчиком агентов.

masvc_имя_компьютера.log  записывается сообщение об ошибке 503:
.

masvc(8332.14056) ahclient.Info: инициировано подключение к сайту https://EPOSERVER:443/spipe/pkg?AgentGuid={08508f50-87f0-11e9-11b1-480fcf30bbf2}&Source=Agent_3.0.0.
masvc(8332.14056) ahclient.Info: Сетевая библиотека rc = <1008>, Обработчик агента сообщает код ответа <503>.
masvc(7844.4644) curl.Trace: rcv head 26 HTTP/1.1 503 Сервер занят  

Файл server_servername.log в папке DB\Logs показывает, что обработчику не удалось обработать входящие свойства:

I    #04412    NAIMSERV    Получено [FullProps] с КОМПЬЮТЕРА:{08508f50-87f0-11e9-11b1-480fcf30bb74} I# 90  90 04412    NAIMSERV    Реквизиты агента обработки для КОМПЬЮТЕРА(08508f50-87f0-11e9-11b1-480fcf30bbf2)
E    #04412    NAIMSERV   servdal. cpp(1959): Не удалось загрузить файл props.xml
E    #04412    NAIMSERV    servdal.cpp(2209): Не удалось изменить реквизиты агента!
I # 04412 Naimserv обработано [FULLPROPS] с компьютера: {08508F50-87F0-11E9-11b1-480fcf30bbf2} в 0 мс
E # 04412 Naimserv AgentserverCommhandler.cpp (656): Не удалось обработать запрос агента

server_ePOServerName.log  файл может регистрировать более легко идентифицируемое сообщение об ошибке в одном из следующих сценариев:

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

Ошибка: в текстовом содержимом обнаружен недопустимый символ.

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

MSINFO32 информация

Имя ОС Microsoft Windows Server 2016 Standard
Версия 10.0.14393 Сборка 14393
Другая ОС 3 Корпорация 64 4 Описание системы: Недоступно 9037 NGL-HV-032
Производитель системы HP
Модель системы ¬Qh
Тип системы 64-разрядный ПК
Артикул системы WV54MP0367
Процессор Intel(R) Xeon(R) CPU @ E2620 . 40 ГГц, 2400 МГц, 4 ядра, 8 логических процессоров
Процессор Intel(R) Xeon(R) CPU E5620 @ 2,40 ГГц, 2400 МГц, 4 ядра, 8 логических процессоров
BIOS Версия/Дата  HP O20, 01.07.2013
SMBIOS Версия   2.7

RFC 2047 — MIME (многоцелевые расширения почты Интернета), часть третья: расширения заголовков сообщений для текста, отличного от ASCII

 Сетевая рабочая группа К. Мур
Запрос комментариев: 2047 Университет Теннесси
Устаревшие: 1521, 1522, 1590, ноябрь 1996 г.
Категория: Трек стандартов


        MIME (многоцелевые расширения почты Интернета), часть третья:
              Расширения заголовка сообщения для текста, отличного от ASCII

Статус этого меморандума

   Этот документ определяет протокол отслеживания стандартов Интернета для
   Интернет-сообщество, а также запросы на обсуждение и предложения по
   улучшения.Пожалуйста, обратитесь к текущему выпуску «Интернет
   Стандарты официальных протоколов» (STD 1) для состояния стандартизации
   и статус этого протокола.  Распространение этой памятки не ограничено.

Абстрактный

   STD 11, RFC 822, определяет протокол представления сообщений, определяющий
   подробные сведения о заголовках сообщений US-ASCII и оставляет
   содержимое сообщения или тело сообщения в виде плоского текста US-ASCII. Этот набор
   документов, вместе называемых Многоцелевой интернет-почтой
   Расширения, или MIME, переопределяют формат сообщений, позволяя

   (1) тела текстовых сообщений в наборах символов, отличных от US-ASCII,

   (2) расширяемый набор различных форматов для нетекстовых сообщений
       тела,

   (3) тела сообщения, состоящие из нескольких частей, и

   (4) текстовая информация заголовка в наборах символов, отличных от US-ASCII.Эти документы основаны на более ранней работе, описанной в RFC 934, STD.
   11 и RFC 1049, но расширяет и пересматривает их. Поскольку в RFC 822 сказано
   так мало о телах сообщений, эти документы в основном
   ортогонален (а не пересмотрен) RFC 822.

   Этот конкретный документ является третьим документом в серии.  Это
   описывает расширения RFC 822, позволяющие передавать текстовые данные, отличные от US-ASCII, в
   Поля заголовка почты Интернета.









Трек стандартов Мура [Страница 1] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


   Среди других документов этой серии:

   + RFC 2045, определяющий различные заголовки, используемые для описания
     структура сообщений MIME.+ RFC 2046, определяющий общую структуру MIME-носителей
     система типизации и определяет начальный набор типов носителей,

   + RFC 2048, определяющий различные процедуры регистрации в IANA
     для средств, связанных с MIME, и

   + RFC 2049, описывающий критерии соответствия MIME и
     предоставляет несколько иллюстративных примеров форматов сообщений MIME,
     благодарности и библиография.

   Эти документы являются пересмотренными версиями RFC 1521, 1522 и 1590, которые
   сами по себе были ревизиями RFC 1341 и 1342.Приложение в RFC
   2049 описывает отличия и изменения от предыдущих версий. 

1. Введение

   RFC 2045 описывает механизм обозначения текстовых частей тела, которые
   кодируются различными наборами символов, а также методами кодирования
   такие части тела, как последовательности печатаемых символов US-ASCII. Этот
   memo описывает аналогичные методы, позволяющие кодировать не-ASCII
   текст в различных частях заголовка сообщения RFC 822 [2] таким образом,
   что вряд ли запутает существующее программное обеспечение для обработки сообщений.Подобно методам кодирования, описанным в RFC 2045, методы
   изложенные здесь, были разработаны, чтобы разрешить использование символов, отличных от ASCII.
   в заголовках сообщений способом, который вряд ли будет нарушен
   особенности существующих программ обработки почты в Интернете. Особенно,
   известно, что некоторые программы ретрансляции почты (а) удаляют некоторые сообщения
   поля заголовка, сохраняя при этом другие, (б) изменить порядок
   адреса в полях «Кому» или «Копия», (c) изменить (вертикальный) порядок
   поля заголовков и/или (d) "переносить" заголовки сообщений в разных местах
   чем в исходном сообщении. Кроме того, некоторое чтение почты
   программы, как известно, испытывают трудности с правильным разбором сообщения
   заголовки, которые, хотя и разрешены в соответствии с RFC 822, используют
   обратная косая черта, чтобы «скрыть» специальные символы, такие как «<», «,» или
   ":", или которые используют другие редко используемые функции этого
   Технические характеристики.

   Пока очень жаль, что эти программы не правильно
   интерпретировать заголовки RFC 822, "сломать" эти программы может привести к
   серьезные эксплуатационные проблемы для почтовой системы Интернета.То
   расширения, описанные в этом меморандуме, поэтому не полагаются на мало-
   используются функции RFC 822.



Трек стандартов Мура [Страница 2] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


   Вместо этого некоторые последовательности «обычных» печатных символов ASCII
   (известные как «закодированные слова») зарезервированы для использования в качестве закодированных данных. То
   синтаксис закодированных слов таков, что они вряд ли
   «случайно» отображаются как обычный текст в заголовках сообщений. Кроме того, символы, используемые в закодированных словах, ограничены
   те, которые не имеют особого значения в контексте, в котором
   появляется закодированное слово.

   Как правило, «закодированное слово» представляет собой последовательность печатных символов ASCII.
   символы, которые начинаются с "=?", заканчиваются на "?=" и имеют два символа "?" в
   между. Он определяет набор символов и метод кодирования, а также
   также включает исходный текст, закодированный как графические символы ASCII,
   в соответствии с правилами для этого метода кодирования.Композитор почты, реализующий эту спецификацию, предоставит
   средства ввода текста, отличного от ASCII, в поля заголовков, но будет
   перевести эти поля (или соответствующие части этих полей) в
   закодированные слова перед их вставкой в ​​заголовок сообщения.

   Программа чтения почты, реализующая эту спецификацию, распознает
   закодированные слова, когда они появляются в определенных частях сообщения
   заголовок. Вместо того, чтобы отображать закодированное слово «как есть», оно будет
   изменить кодировку и отобразить исходный текст в назначенном
   набор символов. ПРИМЕЧАНИЯ

   Этот меморандум в значительной степени основан на обозначениях и терминах, определенных в RFC 822 и
   RFC 2045. В частности, синтаксис ABNF, используемый в этом меморандуме.
   определен в RFC 822, а также во многих терминальных и нетерминальных
   символы из RFC 822 используются в грамматике для заголовка
   расширения, определенные здесь. Среди символов, определенных в RFC 822 и
   в этом меморандуме упоминаются: 'addr-spec', 'atom', 'CHAR', 'comment',
   «CTL», «ctext», «линейный пробел», «фраза», «пара в кавычках».
   «строка в кавычках», «ПРОБЕЛ» и «слово».Успешная реализация
   это расширение протокола требует внимательного отношения к RFC 822.
   определения этих терминов.

   Когда в этом меморандуме встречается термин «ASCII», он относится к «7-битному
   Американский стандартный код для обмена информацией», ANSI X3.4-1986.
   Имя набора символов MIME для этого набора символов — «US-ASCII». Когда нет
   конкретно ссылаясь на имя набора символов MIME, этот документ использует
   термин «ASCII» как для краткости, так и для соответствия RFC 822. 
   Однако разработчиков предупреждают, что имя набора символов должно быть
   пишется как «US-ASCII» в сообщениях MIME и заголовках частей тела.Трек стандартов Мура [Страница 3] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


   Этот меморандум определяет протокол для представления не-ASCII
   текст в заголовках сообщений. Он специально НЕ определяет какие-либо
   перевод между «8-битными заголовками» и чистыми заголовками ASCII, а также
   любой такой перевод считается возможным.

2. Синтаксис закодированных слов

   «Закодированное слово» определяется следующей грамматикой ABNF.То
   используется нотация RFC 822, за исключением того, что пробелы
   символы НЕ ДОЛЖНЫ появляться между компонентами «закодированного слова».

   закодированное слово = "=?" кодировка "?" кодировка "?" закодированный текст "?="

   кодировка = токен; см. раздел 3

   кодировка = токен ; см. раздел 4

   token = 1*<любой CHAR, кроме SPACE, CTL и специальных символов>

   especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
               <"> / "/" / "[" / "]" / "?" / ". " / "="

   encoded-text = 1*<Любой печатный символ ASCII, кроме "?"
                     или ПРОБЕЛ>
                  ; (но см. «Использование закодированных слов в сообщении
                  ; заголовки», раздел 5)

   Имена «кодировка» и «кодировка» не зависят от регистра.Таким образом
   имя набора символов "ISO-8859-1" эквивалентно "iso-8859-1", а
   кодировка с именем «Q» может быть записана как «Q», так и «q».

   «Закодированное слово» не может быть длиннее 75 символов, включая
   «кодировка», «кодировка», «кодированный текст» и разделители. Если это
   желательно закодировать больше текста, чем поместится в «закодированное слово»
   75 символов, несколько кодированных слов (разделенных пробелом CRLF) могут
   использоваться.

   Хотя нет ограничений на длину многострочного заголовка
   поле, каждая строка поля заголовка, содержащая один или несколько
   'encoded-word's ограничен 76 символами.Ограничения по длине включены как для облегчения взаимодействия,
   через межсетевые почтовые шлюзы, а также наложить ограничение на
   объем предпросмотра, который должен использовать синтаксический анализатор заголовков (при поиске
   final ?= разделитель), прежде чем он сможет решить, является ли токен
   "закодированное слово" или что-то еще. 





Трек стандартов Мура [Страница 4] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


   ВАЖНО: «закодированные слова» предназначены для распознавания как «атомы».
   парсером RFC 822.Как следствие, незакодированные пробелы
   символы (такие как ПРОБЕЛ и HTAB) ЗАПРЕЩЕНЫ в
   'закодированное слово'. Например, последовательность символов

      =?iso-8859-1?q?это какой-то текст?=

   будет проанализирован как четыре «атома», а не как один «атом» (по
   синтаксический анализатор RFC 822) или «закодированное слово» (с помощью синтаксического анализатора, который понимает
   «закодированные слова»). Правильный способ кодирования строки "это какой-то
   text" также предназначен для кодирования символов ПРОБЕЛ, например.

      =?iso-8859-1?q?this=20is=20some=20text?=

   Символы, которые могут появляться в «закодированном тексте», являются дополнительными.
   ограничено правилами раздела 5.3. Наборы символов

   Часть «charset» «закодированного слова» указывает символ
   набор, связанный с незакодированным текстом.  «Кодировка» может быть любой из
   имена наборов символов, разрешенные в параметре MIME "charset"
   часть тела "text/plain" или любое имя набора символов, зарегистрированное с
   IANA для использования с типом содержимого MIME text/plain.

   В некоторых наборах символов для переключения между
   «Режим ASCII» и другие режимы. Если незакодированный текст в «закодированном слове»
   содержит последовательность, которая заставляет интерпретатор набора символов переключаться
   вне режима ASCII, он ДОЛЖЕН содержать дополнительные управляющие коды, чтобы
   Режим ASCII снова выбирается в конце «закодированного слова».(Этот
   правило применяется отдельно к каждому «закодированному слову», включая соседние
   'закодированное слово в одном поле заголовка.)

   Когда есть возможность использовать более одного набора символов для
   представлять текст в виде «закодированного слова», а при отсутствии
   частные соглашения между отправителем и получателями сообщения, это
   рекомендуется использовать элементы серии ISO-8859-* в
   предпочтение другим наборам символов. 

4. Кодировки

   Первоначально допустимыми значениями для «кодирования» являются «Q» и «B».Эти
   кодировки описаны ниже. Кодировка "Q" рекомендуется для
   используйте, когда большинство символов, которые нужно закодировать, находятся в ASCII
   набор символов; в противном случае следует использовать кодировку «B».
   Тем не менее, программа для чтения почты, которая утверждает, что распознает «закодированные слова»,
   ДОЛЖЕН быть в состоянии принять любую кодировку для любого набора символов, который он
   поддерживает.



Трек стандартов Мура [Страница 5] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


   Только подмножество печатных символов ASCII может использоваться в
   'закодированный текст'.Пробелы и символы табуляции не допускаются, так что
   начало и конец «закодированного слова» очевидны. "?"
   символ используется в «закодированном слове» для разделения различных
   части «закодированного слова» друг от друга и, таким образом, не могут
   появляются в части «закодированного текста».  Другие персонажи также
   незаконны в определенных контекстах. Например, «закодированное слово» в
   «фраза», предшествующая адресу в поле заголовка From, не может содержать
   любой из «специальных», определенных в RFC 822.Наконец, некоторые другие
   символы запрещены в некоторых контекстах, чтобы обеспечить надежность
   сообщения, проходящие через межсетевые почтовые шлюзы.

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

4.1. Кодировка "В"

   Кодировка «B» идентична кодировке «BASE64», определенной RFC.
   2045.4.2. Кодировка "Q"

   Кодировка «Q» аналогична содержимому «Quoted-Printable».
   кодирование передачи, определенное в RFC 2045. Оно предназначено для
   содержащие в основном символы ASCII для расшифровки на ASCII
   терминал без расшифровки.

   (1) Любое 8-битное значение может быть представлено символом "=", за которым следуют два
       шестнадцатеричные цифры.  Например, если используемый набор символов
       были бы ISO-8859-1, символ "=", таким образом, кодировался бы как
       "=3D" и ПРОБЕЛ на "=20".(В верхнем регистре следует использовать
       шестнадцатеричные цифры от «A» до «F».)

   (2) 8-битное шестнадцатеричное значение 20 (например, ISO-8859-1 SPACE) может быть
       представлен как «_» (подчеркивание, ASCII 95.). (Этот персонаж может
       не проходить через какие-то межсетевые почтовые шлюзы, а использовать
       значительно улучшит читаемость данных в кодировке "Q" с почтой
       считыватели, которые не поддерживают эту кодировку.) Обратите внимание, что "_"
       всегда представляет шестнадцатеричное число 20, даже если символ ПРОБЕЛ
       занимает другую кодовую позицию в используемом наборе символов.(3) 8-битные значения, которые соответствуют печатным символам ASCII, другим
       чем "=", "?" и "_" (подчеркивание), МОГУТ быть представлены как
       персонажи. (Но см. раздел 5 об ограничениях.)
       в частности, ПРОБЕЛ и TAB НЕ ДОЛЖНЫ быть представлены сами по себе
       внутри закодированных слов. 



Трек стандартов Мура [Страница 6] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


5. Использование закодированных слов в заголовках сообщений

   «Закодированное слово» может появиться в заголовке сообщения или заголовке части тела.
   по следующим правилам:

(1) «Закодированное слово» может заменить токен «текст» (как определено в RFC 822).
    в любом поле заголовка «Тема» или «Комментарии», любое дополнительное сообщение
    поле заголовка или любое поле части тела MIME, для которого тело поля
    определяется как '*текст'.«Закодированное слово» может также появиться в любом
    определенное пользователем ("X-") сообщение или поле заголовка части тела.

    Обычный текст ASCII и закодированное слово могут появляться вместе в
    одно и то же поле заголовка. Однако «закодированное слово», которое появляется в
    Поле заголовка, определенное как '*text', ДОЛЖНО быть отделено от любого соседнего
    «закодированное слово» или «текст» с помощью «линейного пробела». 

(2) «Закодированное слово» может появляться в «комментарии», разделенном знаком «(» и
    ")", т. е. везде, где разрешен "ctext". Точнее, RFC.
    822 ABNF определение «комментарий» изменено следующим образом:

    comment = "(" *(ctext / пара в кавычках / комментарий / закодированное слово) ")"

    «Q»-кодированное «кодированное-слово», которое появляется в «комментарии», НЕ ДОЛЖНО
    содержать символы "(", ")" или "
    «закодированное слово», которое появляется в «комментарии», ДОЛЖНО быть отделено от
    любое смежное 'кодированное-слово' или 'ctext' с помощью 'linear-white-space'.Важно отметить, что комментарии распознаются только внутри
    «структурированные» полевые тела. В полях, тела которых определены как
    '*текст', "(" и ")" рассматриваются как обычные символы, а не
    разделители комментариев, и применяется правило (1) этого раздела. (См. RFC
    822, разделы 3.1.2 и 3.1.3)

(3) В качестве замены сущности «слово» внутри «фразы», ​​например,
    тот, который предшествует адресу в заголовке From, To или Cc.  АБНФ
    Таким образом, определение «фразы» из RFC 822 становится следующим:

    фраза = 1*(закодированное слово/слово)

    В этом случае набор символов, которые могут использоваться в Q-кодированном
    'кодированное-слово' ограничено: <верхний и нижний регистр ASCII
    буквы, десятичные цифры, "!", "*", "+", "-", "/", "=" и "_"
    (подчеркивание, ASCII 95.)>. «Закодированное слово», которое появляется внутри
    «фраза» ДОЛЖНА быть отделена от любого соседнего «слова», «текста» или
    «специальный» с помощью «линейного пробела».






Трек стандартов Мура [Страница 7] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


   Это ЕДИНСТВЕННЫЕ места, где может появиться «закодированное слово». В
   особый:

   + «Закодированное слово» НЕ ДОЛЖНО появляться ни в одной части «addr-spec».

   + «Закодированное слово» НЕ ДОЛЖНО появляться внутри «строки в кавычках».+ «Закодированное слово» НЕ ДОЛЖНО использоваться в поле заголовка Received.

   + «Закодированное слово» НЕ ДОЛЖНО использоваться в параметре MIME
     Content-Type или Content-Disposition, или в любом структурированном
     тело поля, за исключением «комментария» или «фразы». 

   «Закодированный текст» в «закодированном слове» должен быть автономным;
   'кодированный-текст' НЕ ДОЛЖЕН продолжаться с одного 'кодированного-слова' на
   еще один. Это означает, что часть «закодированного текста» буквы «B»
   'encoded-word' будет иметь длину, кратную 4 символам; для "Q"
   'кодированное-слово', любой символ "=", который появляется в 'кодированном-тексте'
   часть будет сопровождаться двумя шестнадцатеричными символами.Каждое «закодированное слово» ДОЛЖНО кодировать целое число октетов. То
   «закодированный текст» в каждом «закодированном слове» должен быть правильно сформирован в соответствии с
   к указанной кодировке; "закодированный текст" не может быть продолжен в
   следующее «закодированное слово». (Например, "=?charset?Q?=?=
   =?charset?Q?AB?=" было бы недопустимым, потому что две шестнадцатеричные цифры "AB"
   должен следовать за «=» в том же «закодированном слове».)

   Каждое «закодированное слово» ДОЛЖНО представлять целое число символов.
   Многооктетный символ не может быть разделен между соседними закодированными символами. 
   слова.Только печатные данные и данные пробельных символов должны быть закодированы с использованием
   эта схема. Однако, поскольку эти схемы кодирования позволяют
   кодирование произвольных значений октетов, программы чтения почты, реализующие это
   декодирование также должно обеспечивать отображение декодированных данных на
   терминал получателя не вызовет нежелательных побочных эффектов.

   Использование этих методов для кодирования нетекстовых данных (например, изображений или
   звуки) не определяется данным меморандумом. Использование «закодированных слов» для
   представлять строки, состоящие исключительно из символов ASCII, разрешено, но
   обескураженный.В редких случаях может потребоваться кодирование обычных
   текст, который выглядит как «закодированное слово».









Трек стандартов Мура [Страница 8] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


6. Поддержка кодированных слов почтовыми читателями

6.1. Распознавание «закодированных слов» в заголовках сообщений

   Программа чтения почты должна анализировать заголовки сообщений и частей тела в соответствии с
   к правилам в RFC 822, чтобы правильно распознавать «закодированные слова». 'закодированные слова должны быть распознаны следующим образом:

   (1) Любое поле заголовка сообщения или части тела, определенное как '*текст', или любое
       определяемое пользователем поле заголовка, следует анализировать следующим образом: Начало
       в начале тела поля и сразу после каждого
       появление 'linear-white-space', каждая последовательность до 75
       печатные символы (не содержащие «линейных пробелов»)
       должны быть проверены, чтобы увидеть, является ли это «закодированным словом» в соответствии с
       правила синтаксиса в разделе 2.Любая другая последовательность печатаемых
       символы следует рассматривать как обычный текст ASCII.

   (2) Любое поле заголовка, не определенное как «* текст», должно быть проанализировано.
       в соответствии с правилами синтаксиса для этого поля заголовка. Однако,
       любое «слово», которое появляется внутри «фразы», ​​должно рассматриваться как
       'encoded-word', если оно соответствует правилам синтаксиса в разделе 2.
       В противном случае его следует рассматривать как обычное «слово».

   (3) В «комментарии» любая последовательность до 75 печатных символов.
       (не содержит 'linear-white-space'), который соответствует синтаксису
       правил в разделе 2, следует рассматривать как «закодированное слово».В противном случае его следует рассматривать как обычный текст комментария.

   (4) Поле заголовка MIME-Version НЕ требуется для
       'закодированное слово должно быть интерпретировано в соответствии с этим
       Технические характеристики. Одной из причин этого является то, что программа для чтения почты
       не ожидается, что он будет анализировать весь заголовок сообщения перед отображением
       строки, которые могут содержать 'encoded-word's.

6.2. Отображение закодированных слов

   Любое закодированное слово, распознанное таким образом, декодируется, и, если возможно,
   результирующий незакодированный текст отображается в исходном наборе символов.ПРИМЕЧАНИЕ. Декодирование и отображение закодированных слов происходит *после*
   тело структурированного поля разбирается на токены. Поэтому
   можно скрыть «специальные» символы в закодированных словах, которые, когда
   отображаемые, будут неотличимы от «специальных» символов в
   окружающий текст. По этой и другим причинам обычно НЕ
   можно перевести заголовок сообщения, содержащий «закодированное слово», в
   незакодированная форма, которая может быть проанализирована программой чтения почты RFC 822.




Трек стандартов Мура [Страница 9] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


   При отображении определенного поля заголовка, содержащего несколько
   'закодированное-слово', любой 'линейный пробел', который разделяет пару
   соседние закодированные слова игнорируются.(Это сделано для того, чтобы можно было использовать
   несколько закодированных слов для представления длинных строк незакодированного текста,
   без необходимости отделять «закодированное слово», где пробелы встречаются в
   незакодированный текст.)

   В случае, если в будущем будут определены другие кодировки, и почта
   ридер не поддерживает используемую кодировку, он может либо (а) отображать
   'закодированное слово' как обычный текст, или (b) заменить соответствующий
   сообщение о том, что текст не может быть декодирован.

   Если программа чтения почты не поддерживает используемый набор символов, она может
   (a) отображать «закодированное слово» как обычный текст (т.д., как оказалось
   в заголовке), (б) сделать все возможное, чтобы отобразить с помощью таких
   имеющиеся символы или (c) заменить соответствующее сообщение
   указывая на то, что декодированный текст не может быть отображен.

   Если используемый набор символов использует методы переключения кода,
   отображение закодированного текста неявно начинается в «режиме ASCII». В
   Кроме того, программа чтения почты должна убедиться, что устройство вывода
   снова в «режиме ASCII» после отображения «закодированного слова».

6.3. Обработка читателем почты неправильно сформированного «закодированного слова»

   Возможно, что «закодированное слово», допустимое в соответствии с
   синтаксис, определенный в разделе 2, неправильно сформирован в соответствии с
   правила используемой кодировки.Например:

   (1) «Закодированное слово», содержащее недопустимые символы.
       для конкретной кодировки (например, "-" в "B"
       кодировке или SPACE или HTAB в кодировке «B» или «Q»)
       неправильно формируется.

   (2) Любое «закодированное слово», которое кодирует нецелое число
       символы или октеты сформированы неправильно.

   Программа чтения почты не должна пытаться отобразить текст, связанный с
   «закодированное слово», которое неправильно сформировано. Однако читатель почты
   НЕ ДОЛЖЕН препятствовать отображению или обработке сообщения, потому что
   'закодированное слово' сформировано неправильно.7. Соответствие

   Программа создания почты, заявляющая о соответствии этой спецификации.
   ОБЯЗАТЕЛЬНО убедитесь, что любая строка печатаемого ASCII без пробелов
   символы в пределах '*text' или '*ctext', которые начинаются с "=?" а также
   заканчивается на "?=" быть допустимым "закодированным словом". ("начинается" означает: в



Трек стандартов Мура [Страница 10] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


   начало тела поля, сразу после 'linear-white-space',
   или сразу после «(» для «закодированного слова» в «*ctext»;
   «заканчивается» означает: в конце тела поля, непосредственно предшествующего
   'linear-white-space' или непосредственно перед ")" для
   'закодированное слово' внутри '*ctext'.) Кроме того, любое «слово» внутри
   'фраза', начинающаяся с "=?" и заканчивающийся на "?=" должен быть допустимым
   'закодированное слово'.

   Программа чтения почты, заявляющая о соответствии этой спецификации.
   должен уметь отличать «закодированное слово» от «текста», «текста» или
   слова, в соответствии с правилами раздела 6, каждый раз, когда они появляются в
   соответствующие места в заголовках сообщений. Он должен поддерживать как "B",
   и кодировки «Q» для любого набора символов, который он поддерживает. То
   программа должна уметь отображать незакодированный текст, если символ
   установлен "US-ASCII".Для наборов символов ISO-8859-* почтовый
   программа чтения должна, по крайней мере, уметь отображать символы, которые
   также находятся в наборе ASCII.

8. Примеры

   Ниже приведены примеры заголовков сообщений, содержащих 'encoded-
   слова:

   От кого: =?US-ASCII?Q?Keith_Moore?= 
   Кому: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= 
   CC: =?ISO-8859-1?Q?Andr=E9?= Пирар 
   Тема: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
    =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

      Примечание. В первом «закодированном слове» поля «Тема» выше
      последний "=" в конце "закодированного текста" необходим, потому что каждый
      'encoded-word' должен быть автономным (символ "=" завершает
      группа из 4 символов base64, представляющих 2 октета).Вдобавок
      октет мог быть закодирован в первом «закодированном слове» (так что
      закодированное слово будет содержать точное число, кратное 3 закодированным
      октетов), за исключением того, что второе «закодированное слово» использует другой
      'charset', чем первый.

   От: =?ISO-8859-1?Q?Olle_J=E4rnefors?= 
   Кому: [email protected], [email protected]
   Тема: Время для ISO 10646?

   Кому: Дэйв Крокер 
   Копия: [email protected], [email protected]
   От: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
   Тема: Re: RFC-HDR уход и кормление





Трек стандартов Мура [Страница 11] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


   От: Натаниэль Боренштейн 
         (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
   Кому: Грег Водрей , Нед Фрид
      , Кит Мур 
   Тема: Тест нового генератора заголовков
   MIME-версия: 1.0
   Тип контента: текстовый/обычный; кодировка = ISO-8859-1

   Следующие примеры иллюстрируют, как текст, содержащий кодировку 'encoded-word's
   которые появляются в структурированном теле поля. Правила слегка
   отличается для полей, определенных как «* текст», потому что «(» и «)» не
   распознаются как разделители комментариев. [Статья 5, параграф (1)].

   В каждом из следующих примеров, если одна и та же последовательность должна была произойти
   в поле «*текст» форма «отображается как» НЕ будет рассматриваться как
   закодированные слова, но быть идентичными "закодированной форме".Это
   потому что каждое из закодированных слов в следующих примерах
   рядом с символом "(" или ")".

   закодированная форма отображается как
   -------------------------------------------------- --------------------
   (=?ISO-8859-1?Q?a?=) (а)

   (=?ISO-8859-1?Q?a?= b) (a b)

           Внутри «комментария» пробел ДОЛЖЕН быть между
           «закодированное слово» и окружающий текст. [Раздел 5,
           пункт (2)].Однако пробел не требуется между
           начальный "(", с которого начинается "комментарий", и
           'закодированное слово'.


   (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab)

           Пробел между соседними «закодированными словами» не
           отображается.

   (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab)

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

   (=?ISO-8859-1?Q?a?= (ab)
       =?ISO-8859-1?Q?b?=)

           Любое количество linear-space-white между 'encoded-word's,
           даже если он включает CRLF, за которым следует один или несколько пробелов,
           игнорируется для целей отображения.Трек стандартов Мура [Страница 12] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


   (=?ISO-8859-1?Q?a_b?=) (а б)

           Чтобы ПРОБЕЛ отображался внутри части
           закодированного текста, ПРОБЕЛ ДОЛЖЕН быть закодирован как часть
           'закодированное слово'.

   (=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b)

           Чтобы между двумя строками отображался ПРОБЕЛ
           закодированного текста, ПРОБЕЛ МОЖЕТ быть закодирован как часть одного из
           «закодированное слово».9. Ссылки

   [RFC 822] Крокер, Д., «Стандарт формата интернет-текста ARPA».
       Сообщения», STD 11, RFC 822, UDEL, август 1982 г.

   [RFC 2049] Боренштейн, Н., и Н. Фрид, «Многоцелевая интернет-почта».
       Расширения (MIME), часть пятая: критерии соответствия и примеры»,
       RFC 2049, ноябрь 1996 г.

   [RFC 2045] Боренштейн, Н., и Н. Фрид, «Многоцелевая интернет-почта».
       Расширения (MIME), часть первая: формат тел интернет-сообщений»,
       RFC 2045, ноябрь 1996 г.

   [RFC 2046] Боренштейн Н.и Н. Фрид, "Многоцелевая Интернет-почта".
       Расширения (MIME), часть вторая: типы носителей», RFC 2046,
       ноябрь 1996 г.

   [RFC 2048] Фрид, Н., Кленсин, Дж., и Дж. Постел, «Многоцелевой
       Расширения электронной почты Интернета (MIME), часть четвертая: регистрация
       Процедуры», RFC 2048, ноябрь 1996 г.



















Трек стандартов Мура [Страница 13] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


10. Вопросы безопасности

   Вопросы безопасности в этом меморандуме не обсуждаются.11. Благодарности

   Автор выражает благодарность Натаниэлю Боренштейну, Исааку Чану, Лутцу
   Доннерхаке, Пол Эггерт, Нед Фрид, Андреас М. Кирхвиц, Олле
   Ярнефорс, Майк Розин, Ютака Сато, Барт Шефер и Казухико
   Ямамото за полезные советы, проницательные комментарии и
   освещающие вопросы в ответ на более ранние версии этого
   Технические характеристики.

12. Адрес автора

   Кейт Мур
   Университет Теннесси
   107 Эйрес Холл
   Ноксвилл, Теннесси 37996-1301

   Электронная почта: [email protected]






























Трек стандартов Мура [Страница 14] 

---

Расширения заголовка сообщения RFC 2047, ноябрь 1996 г.


Приложение — изменения по сравнению с RFC 1522 (в произвольном порядке)

   + явно указать, что MIME-версия не требуется для использования
     'закодированное слово's.

   + добавить явное примечание о том, что ПРОБЕЛЫ и TAB не разрешены внутри
     «закодированное слово», объясняя, что «закодированное слово» должно выглядеть как
     'atom' парсеру RFC822.значения, если быть точным).

   + добавить примеры от Олле Ярнефорса (спасибо!), иллюстрирующие, как
     отображаются закодированные слова с соседними линейными пробелами.

   + явно перечислить термины, определенные в RFC822 и упомянутые в этом меморандуме

   + исправить опечатки в транскрипции, из-за которых одна-две строки и пара
     символы исчезают в результирующем тексте из-за причуд nroff.

   + уточнить, что закодированные слова разрешены в полях '*text' в обоих
     Заголовки RFC822 и заголовки частей тела MIME, но НЕ как параметр
     значения.+ уточнить требование обратного переключения на ASCII внутри закодированного
     часть «закодированного слова» для любой кодировки, использующей переключение кода
     последовательности.

   + добавить примечание о том, что "закодированное слово" ограничено символами "(" и ")"
     внутри комментария, но не в *тексте (как странно!).

   + исправить пример Андре Пирара, чтобы избавиться от завершающего "_" после
     =E9. (больше не нужен после 1342 г.).

   + уточнение: сразу после
     начальный "(" или непосредственно перед конечным ")", который ограничивает
     комментарий, а не только рядом с "(" и ")" *внутри* *ctext.+ добавить примечание, объясняющее, что «закодированное слово» «B» всегда будет иметь
     кратно 4 символам в части «закодированного текста».

   + добавить примечание о "=" в примерах

   + обратите внимание, что обработка "закодированных слов" происходит *после* синтаксического анализа, и
     некоторые последствия этого.

   + явно указать, что вы не можете рассчитывать на перевод между
     1522 и либо ванильный 822, либо так называемые «8-битные заголовки».

   + явно указать, что «закодированные слова недействительны в
     'строка в кавычках'.Отслеживание стандартов Мура [Страница 15]
 

Как специальные символы и символы влияют на доступность программ чтения с экрана

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

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

Что такое специальные символы?

Специальные символы обозначают что-то отличное от буквы или цифры.

Стандартные знаки препинания и символы на клавиатуре являются примерами специальных символов. Например, восклицательный знак «!» или амперсанд «&».

символов Юникода

Unicode — это глобальный стандарт кодирования.

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

символов Юникода не отображаются на стандартной клавиатуре. Хотя они распознаются большинством устройств, веб-сайтов и приложений. Например, Twitter, Facebook, Instagram и Gmail поддерживают символы Unicode. Символы Unicode также включают в себя различные символы и пиктограммы. Например астрологические, музыкальные, политические и религиозные символы.

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

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

Узнайте, как средство чтения с экрана работает с символами Unicode, из приведенного ниже твита Кена Доддса. Написанный разными стилями шрифта со специальными символами, текст гласит: «Вы думаете, что это мило — писать свои твиты и имена пользователей таким образом. Но слышали ли вы, как это звучит с такими вспомогательными технологиями, как Voiceover?»

Вы 𝘵𝘩𝘪𝘯𝘬 это 𝒸𝓊𝓉ℯ для 𝘄𝗿𝗶𝘁𝗲 ваших твитов и имен пользователей 𝖙𝖍𝖎𝖘 𝖜𝖆𝖞. Но вы 𝙡𝙞𝙨𝙩𝙚𝙣𝙚𝙙 к чему это 𝘴𝘰𝘶𝘯𝘥𝘴 𝘭𝘪𝘬𝘦 со вспомогательными технологиями, такими как 𝓥𝓸𝓲𝓬𝓮𝓞𝓿𝓮𝓻? рис.twitter.com/CywCf1b3Lm

— Кент С. Доддс (@kentcdodds) 9 января 2019 г.

Смайлики

Смайлики — это смайлики, состоящие из стандартных букв и знаков препинания. Например, используя двоеточие «:», за которым следует тире, «-» и закрывающая скобка «)», чтобы создать улыбающееся лицо. Они отличаются от «смайликов», которые используют мультяшные картинки для передачи эмоции или объекта.

Сложность смайликов в том, что некоторые программы чтения с экрана могут их прочитать. В то время как другие не могут.

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

ASCII арт

Также известное как «искусство текста», искусство ASCII использует специальные символы для формирования изображений. Текстовое искусство часто используется в Твиттере и в онлайн-чатах. Но поскольку он создан с использованием специальных символов и пробелов, он недоступен для программ чтения с экрана.

Вы можете услышать, как программа чтения с экрана работает с ASCII-графикой, в твите ниже.Трудно извлечь из этого какой-либо смысл. И считывание занимает много времени.

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

Вот запись программы чтения с экрана, объявляющую ASCII (даже не полное видео).

Если вы хотите принять участие в этих мемах доступным способом, сделайте снимок экрана и добавьте соответствующий живой текст в твит или в альтернативный текст изображения скриншота.#a11y pic.twitter.com/N9S2s51hWS

— Татьяна Мак (@TatianaTMac) 24 марта 2019 г.

Проблема со специальными символами и доступностью

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

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

.

• чрезмерное использование
• используется неправильно
• используется в декоративных целях
• используется для передачи значения, отличного от исходного символа
.

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

• человек с дислексией
• человек со слабым зрением
• человека с более низким уровнем чтения и способностями
• человека с трудностями в обучении
• не являются носителями английского языка
• человека с ограниченным временем или концентрацией внимания

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

Средства чтения с экрана и специальные символы

Средства чтения с экрана считывают содержимое экрана.Они превращают текст на экране в речь.

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

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

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

Для слов, содержащих апостроф, например «не делать», большинство программ чтения с экрана произносят полное слово. Вместо того, чтобы зачитывать знаки препинания (например, «don apostrophe t»).

Важно знать, как программы чтения с экрана обрабатывают разные символы, если вы работаете с контентом.

Настройки чтения с экрана

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

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

Пользователи также могут изменять настройки пунктуации в зависимости от своих предпочтений.

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

Например, популярная программа чтения с экрана Jaws:

• знак минус читается как - (тире). Например, он не различает, когда он используется для математических уравнений.
• использует другую интонацию для восклицательного знака, добавляя немного экспрессии
• объявляет, когда информация заключена в скобки или кавычки

Хотя встроенная программа чтения с экрана Apple, VoiceOver:

• не объявляет некоторые часто используемые специальные символы
• делает паузу только тогда, когда встречается кавычки, скобки и тире

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

Рекомендации по использованию специальных символов

Каждое средство чтения с экрана отличается. Но следование этим советам может сделать ваш контент лучше для пользователей программ чтения с экрана.

Используйте простой английский

Пользователи программы чтения с экрана могут предпочесть читать простой веб-контент на английском языке. Это потому, что он быстрее читается. Облегчение поиска информации на нужной странице.

Избегайте жаргона, лишних слов и ненужных специальных символов. Например, всегда используйте «и» вместо амперсанда.

Plain English использует стандартную пунктуацию, которая обычно более доступна для всех.

Используйте правильную грамматику и пунктуацию

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

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

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

Избегайте символов Unicode

При использовании символов Unicode спросите себя, действительно ли они нужны.Не могли бы вы вместо этого использовать стандартный текст?

Если вы хотите, чтобы ваше сообщение было понятно широкой аудитории, избегайте использования Unicode.

Тестирование программы чтения с экрана

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

Также может помочь обучение использованию программы чтения с экрана. Хотя это требует времени и приверженности, это может повысить вашу осведомленность и понимание.

Руководство по тестированию программ чтения с экрана для зрячих веб-разработчиков

Некоторые из самых популярных программ чтения с экрана включают:

JAWS (Freedom Scientific)
Полное руководство по экранному диктору (поддержка Microsoft)
Программа чтения с экрана (Dolphin Computer Access)
Специальные возможности — VoiceOver (Apple)
Начало работы на Android с TalkBack (справка по специальным возможностям Android)

специальных символов в теме письма: хорошо или плохо?

Примечание редактора: эта статья была первоначально опубликована в Web Marketing Today.В 2012 году компания «Practical Ecommerce» приобрела «Web Marketing Today». В 2016 году мы объединили два сайта, оставив «Practical Ecommerce» в качестве преемника.

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

Как специальные символы отображаются в разных строках темы электронной почты в папке «Входящие».

У этих специальных символов много названий: глифы, идеограммы, идеограммы или иногда эмодзи.Большинство маркетологов просто называют их «специальными символами». Как бы вы их ни называли, знайте, что это не образ. Каждый из них, от сердечек до стрелок, является просто символом из стандартного набора символов Unicode.

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

Ответ: иногда.

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

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

Тесты темы письма для специальных символов

Penton Marketing провела тестирование электронной почты с четырьмя различными темами, каждая из которых была направлена ​​1500 подписчикам.Вот результаты:

Результаты четырехстороннего теста строк темы электронной почты. Победила тема со специальными символами.

 

В этом тесте строка темы со специальными символами явно выбила всех конкурентов из колеи. Он выигрывал по открытиям, кликам и регистрациям.

Обратите внимание, насколько хорошо выровнены сообщение и специальные символы. Одна из лучших практик со специальными символами — использовать их там, где они имеют смысл, а не только для того, чтобы вставить их.Выигрышная строка темы здесь — прекрасный пример использования специальных символов для усиления призыва к действию. Среда — в данном случае персонажи — буквально была сообщением. Это было не просто украшение текста.

Вот еще один прекрасный пример того, как специальные символы доставляют сообщение — буквально.

Звездная тема электронного письма от интернет-магазина ModCloth.

Электронное письмо отправлено ModCloth, а пример получен от Vertical Response.

Этот пример фактически нарушает одно из «правил» специальных символов: используйте их экономно.Наилучшей практикой является использование одного специального символа в каждой строке темы электронного письма. В лучшем случае используйте два. Но если вы вернетесь к нашему предыдущему примеру — со специальными символами 1, 2, 3 — это также нарушило правило не более двух.

Специальные символы с закладками

Здесь тоже интересно использование звездочек. Многие розничные продавцы, такие как Think Fast Toys, Ulla Popken и BBOS, используют символы, обычно звезды, в начале и в конце своих тем. Они делали это регулярно в течение последнего года, даже в прошлом месяце.Обычно, когда они используют звезды, они ставят их до и после текста строки темы. Несколько розничных продавцов снова и снова использовали эту «книжку» со специальными символами, так что, вероятно, это работает для них.

Не ограничивайтесь открытыми рейтингами

Специальные символы Bookended определенно работали на BeNaughty.com, но по-другому. Для них специальные символы улучшили взаимодействие с клиентами. Меньшее количество подписчиков отметили сообщение со специальными символами как спам. Больше подписчиков также читают электронные письма со специальными символами.Согласно Return Path, электронные письма со специальными символами также пересылались чаще.

Тест специальных символов BeNaughty снизил количество жалоб на спам.

Туристическая компания Voyage Privé получила аналогичные результаты.

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

Ни Voyage Privé, ни BeNaughty не раскрывают точные показатели открытия или переходы по ссылкам для этих электронных писем, но данные их кампаний по электронной почте показывают, что при оценке того, сработали ли специальные символы, стоит не ограничиваться только показателями открытия.

Эффект подталкивания

Маркетологи по электронной почте могут увидеть преимущества специальных символов — или любого своевременного сообщения электронной почты — вне зависимости от того, нажимает подписчик или нет. Это связано с явлением, которое компания Alchemy Worx, занимающаяся маркетингом по электронной почте, называет «эффектом подталкивания».

Эффект подталкивания — это когда клиент видит сообщение электронной почты в своем почтовом ящике, но не нажимает на него. Она вообще не взаимодействует с электронной почтой, кроме как читает строку темы. Но довольно скоро — в течение 24 часов — она заходит либо в магазин, либо на сайт.В этом случае электронное письмо служило в основном медийной рекламой, за исключением того, что клиент видел рекламу в своем почтовом ящике.

Больше положительных отзывов для специальных символов

Другие маркетологи добились положительных результатов со специальными символами. Clickz сообщил о 15-процентном увеличении открываемости со специальными символами. Тем не менее, он также предупредил, что со временем новизна специальных символов может уменьшиться, а связанный с этим рост числа открытий и других показателей также может уменьшиться. Это, безусловно, возможно, и, возможно, именно поэтому мы видим меньше специальных символов в наших почтовых ящиках в этом месяце, чем в прошлом году.Они могут работать не так хорошо, поэтому маркетологи используют их меньше.

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

CheetahMail получил специальные данные символов.

• Заголовки с символами имели более высокий процент уникальных открытий в 56 процентах проанализированных брендов.
• Сердце (♥) является самым популярным символом, но оно обеспечило лишь скромный рост открываемости на 2,2 процента.
• Из 5 самых популярных символов у черного солнца с лучами самый высокий рост открываемости — 14,9%.
• Попытка использовать другой символ может добавить эффект «вау» к строкам темы. Самолеты (✈) увеличили количество уникальных открытий на 10,7%, а зонтики (☂) — на 50%.

50-процентный рост по сравнению с символом зонтика — это невероятно.Кто знал? Этот маленький зонтик может стать секретным оружием маркетолога по электронной почте.

Следите за своими почтовыми клиентами

Прежде чем отправлять следующее электронное письмо со специальными символами, убедитесь, что вы проверили, как электронное письмо выглядит во всех основных клиентах. Полезны такие инструменты, как Email on Acid или Litmus.

Вам нужно, чтобы ваша электронная почта отображалась на как можно большем количестве клиентов, потому что не все почтовые клиенты одинаково отображают специальные символы. Gmail, Hotmail и Yahoo надежно отображают специальный символ, но смартфоны — iPhone, Android и BlackBerry — не всегда показывают то, что вам нужно.Помните, что 48% писем сейчас открываются на мобильных устройствах.

Обзор того, какие почтовые клиенты хорошо отображают специальные символы.

Создание специальных символов для строк темы электронной почты

Создание специальных символов на самом деле очень просто, но некоторый опыт работы с HTML может быть полезен. Опять же, проверьте, как ваша электронная почта выглядит во всех возможных почтовых клиентах.

Вот список страниц с символами и кодом, который вам понадобится для их создания.

Проверка и еще раз проверка

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

Большинство маркетологов, вероятно, выберут более простой путь тестирования:

1. Разделите список на две части и отправьте по почте оба сегмента одновременно — один со спецсимволами, другой без;
2. Посмотрите, какая строка темы работает лучше всего;
3. Попробуйте выполнить от 2 до 3 подобных тестов с 2–3 различными наборами строк темы, со специальными символами и без них;
4. Сделайте обоснованное предположение о том, подходят ли символы для их списка или нет.

Работали ли специальные символы в ваших сообщениях электронной почты? Какие конкретные символы работают лучше всего?

.