Ctrl+V в Word теряет цвета и размер шрифта? Данные целы — изменился параметр по умолчанию
2026-10-27
Tags: Windows · Буфер обмена · Руководство
Несколько месяцев назад мы выпустили RDP Clipboard Anchor. Это инструмент истории буфера обмена, специализированный на сценариях удалённого рабочего стола: всё, что скопировано внутри RDP-сессии, кэшируется и закрепляется локально, переживает обрывы связи и в любой момент доступно перетаскиванием. Его список истории спроектирован вокруг этого мостового сценария.
В мае этого года в нашем репозитории обратной связи появилась просьба: хочется категорий в истории буфера обмена и избранного для часто используемых записей. Категории и избранное — потребности универсального управления буфером обмена, выходящие за рамки RDP-моста. Запрос на самом деле указывал на другой продукт: менеджер буфера обмена для повседневной локальной работы. В этом направлении мы и запустили ClipLab.
А затем при тестировании наткнулись на проблему, о которой эта статья.
Симптом, который не сходился
Скопировать в Word текст с цветами, размером шрифта, жирным и курсивом, дать буферу обмена перезаписаться чем-то другим, затем найти эту запись в истории ClipLab и вставить обратно в Word. Цвета и размер шрифта пропали, жирный и курсив на месте.
Первый подозреваемый — мы сами: часть данных терялась при сохранении или при обратной записи. Основная работа менеджера буфера обмена — сохранить содержимое как есть и вернуть как есть; если не получается, это баг.
Поэтому сначала мы проверили данные по всей цепочке.
Сначала убедимся, что данные вообще целы
Буфер обмена Windows позволяет одному содержимому существовать одновременно в нескольких форматах. Копируя текст, Word кладёт на буфер около десятка форматов сразу: Rich Text Format, HTML Format, обычный текст плюс куча нативных форматов OLE (Embed Source, Native и прочие).
Мы написали скрипт-зонд, который через голый Win32 API (OpenClipboard / GetClipboardData) поштучно снимает сырые байты каждого формата, считает хэши и складывает в архив. Затем провели сверку из трёх шагов.
Шаг один: после копирования достать сохранённые байты из базы инструмента и сравнить с оригинальными байтами на буфере. HTML Format совпал побайтово.
Шаг два: очистить буфер, дать инструменту записать запись обратно и снова снять зондом. Хэши совпали — по-прежнему побайтовая идентичность.
Шаг три: в обход инструмента зондом вернуть в буфер исходные байты Word и вставить в Word.
Третий шаг всё равно терял цвета. Не пропал ни один байт, а Word вставлял по-прежнему так же.
Четыре варианта вставки Word
С данными всё в порядке — смотрим на поведение Word. Вставка правой кнопкой показывает четыре варианта вставки, и при переборе по одному закономерность видна:
| Вариант вставки | Цвет/размер | Жирный/курсив |
|---|---|---|
| Сохранить исходное форматирование | ✅ | ✅ |
| Использовать тему конечного документа | ✅ | ✅ |
| Объединить форматирование | ❌ | ✅ |
| Сохранить только текст | ❌ | ❌ |
Данные полны, и Word вполне способен вставить их как есть — достаточно явно выбрать «Сохранить исходное форматирование». Но при обычном Ctrl+V Word решает сам и идёт по пути «Объединить форматирование»: жирный и курсив выживают, а шрифт, цвет, размер и гарнитура отбрасываются. Это в точности совпадает с нашим симптомом.
На основании чего Word решает, какой вариант будет по умолчанию? Мы провели несколько раундов исключения. Сначала угол данных: все 16 форматов, которые Word кладёт при копировании (включая нативные OLE вроде Embed Source и Native), сняли побайтово и воспроизвели без изменений — цвета пропадали всё равно. Только RTF, только HTML — то же самое. Затем угол источника: буфер обмена хранит «владельца», а Windows не проверяет, кому принадлежит хэндл окна, переданный в OpenClipboard. Мы передали напрямую хэндл главного окна Word, воспроизвели все форматы и через GetClipboardOwner убедились, что владельцем стало собственное окно Word. Обычный Ctrl+V — всё равно «Объединить форматирование».
По пути был обходной манёвр: сначала подозревали, что в RTF не хватает привычного терминатора NUL — дополнили, вставили, пропадает так же. Хотели взять WordPad в качестве контрольной группы, но Win11 его уже удалил; вместо этого сохранили RTF в файл и открыли прямо в Word — форматирование было полным.
К этому моменту направление стало ясным: всё, что можно было проверить в данных и источнике, исчерпано, а Word стабильно выбирает «Объединить форматирование». Это не проблема данных — это устоявшаяся политика Word к «содержимому из других программ». Чем именно он отличает своё содержимое от чужого, мы не копали: на вывод это не влияло.
Настоящий переключатель — это настройка
Эта политика живёт в видимой пользователю настройке: Файл → Параметры → Дополнительно → Вырезание, копирование и вставка → «Вставка из других приложений».
В мае 2024 года команда Word объявила в официальном блоге Microsoft 365 об этом изменении значения по умолчанию в Word 2405: «Вставка из других приложений» сменилась с «Сохранить исходное форматирование» на «Объединить форматирование». То есть мы ничего не настроили неправильно — Word таков уже при установке: всё, что классифицировано как «из других приложений», а это любое содержимое, записанное обратно сторонним инструментом, Ctrl+V понижает без исключений.
Что делать
- Изменить настройку Word (рекомендуется): Файл → Параметры → Дополнительно → Вырезание, копирование и вставка; вернуть «Вставка из других приложений» на «Сохранить исходное форматирование». Один раз поменял — и навсегда. Это предпочтение самого пользователя; инструмент не должен решать за него.
- Вставка правой кнопкой: если настройку не трогать, придётся явно выбирать «Сохранить исходное форматирование» в контекстном меню — лишний клик каждый раз.
- Со стороны инструмента решения нет, его и не должно быть: любой менеджер буфера обмена с настройками по умолчанию вызывает то же самое понижение. Данные уже побайтово точны; следующий шаг — это выдавать себя за сам Word. Это не улучшение вставки, а атака с подменой личности.