Слияние PDF без превращения всего в изображения
Правильное слияние PDF объединяет потоки страниц: шрифты, векторы и закладки остаются целыми. Растеризация страниц в изображения — другая задача, с потерями.
«Объедини эти пять PDF» может означать два разных конвейера. Один сцепляет существующие объекты страниц в один файл. Другой печатает каждую страницу в растр и упаковывает изображения в новый PDF. Оба дают одно вложение. Только первый сохраняет выделяемый текст и резкие векторы.
Что делает структурное слияние
В PDF123 Merge объединяет два или больше PDF, сцепляя объекты страниц каждого файла. Серверный путь запускает qpdf с пустой базой и --pages по входным файлам: потоки страниц переносятся как страницы, а не как снимки экрана. Встроенные шрифты, векторы и существующие закладки путешествуют вместе с этими страницами. Ничто в этом пути не растеризует страницу в изображение, поэтому цифровой договор после объединения по-прежнему можно искать и копировать.
Порядок загрузки по умолчанию становится порядком вывода. HTTP-форма принимает повторяющиеся части fileInput в одном запросе; размер пакета ограничен лимитами загрузки, а не жёстким пределом в два файла. Необязательный sortType=byFileName переупорядочивает входные файлы по имени перед объединением. Закладки из каждого источника могут сохраниться; слияние не изобретает идеальное дерево оглавления, если у входных файлов его не было.
Загрузка одного файла — это сквозной проход без изменений. Два или больше файлов становятся одним merged.pdf, страницы которого — конкатенация входных файлов в выбранном порядке. Тот же идентификатор операции выставлен в OpenAPI, MCP и pdfx merge, поэтому скрипт и щелчок в браузере не расходятся втайне в понимании «слияния».
Когда люди случайно растеризуют
Некоторые сценарии «объединения» сначала экспортируют в изображения (факс-шлюзы, приложения сканирования, печать в PDF в экранном разрешении) или сплющивают аннотации в растры до соединения. Размер файла подскакивает, OCR может понадобиться заново, а при увеличении видны пиксельные края.
Предпочитайте потоковое слияние, когда источники — уже цифровые PDF. Прибегайте к OCR, только когда входные файлы — сканы без пригодного текста, и помните, что OCR здесь возвращает Markdown (text/markdown), а не PDF с заново наложенным скрытым текстовым слоем. Растеризовать, а затем распознавать — другой продуктовый путь, нежели слияние цифровых файлов.
Если нужны изображения страниц, это задача конвертации (PDF в изображения), а не слияние. Смешение этих намерений — путь к тому, что «объединённые» файлы становятся фотоальбомами документов на много мегабайт. Сжатие после структурного слияния всё ещё может уменьшить потоки (Сжатие); оно не отменяет растровое сплющивание, которое вы уже запечатали.
Чего слияние не обещает
Слияние не нормализует размеры страниц, не унифицирует шрифты между файлами и не перестраивает оглавление с нуля. Оно не расшифровывает зашифрованные входные файлы за вас: сначала снимите защиту, если источник под паролем. Оно не заменяет формат контейнера-портфолио, которого ожидают некоторые судебные порталы; на выходе получается один обычный многостраничный PDF.
Эти ограничения одинаковы независимо от того, используете вы браузер, REST, MCP или pdfx. Операция намеренно узкая, чтобы вывод оставался предсказуемым для автоматизации. Если нужна упорядоченная многошаговая работа (слияние, затем водяной знак, затем сжатие), используйте POST /api/v1/pipeline с упорядоченным списком steps, а не изобретайте второй флаг «умного слияния».
Как это запустить
Merge PDFs в браузере или POST /api/v1/general/merge-pdfs с повторяющимися частями fileInput (Разработчикам). Из оболочки:
pdfx merge a.pdf b.pdf -o merged.pdf
Или против хостингового либо собственного базового URL:
pdfx --cloud --api-base "$API_BASE" --api-key "$KEY" merge a.pdf b.pdf -o merged.pdf
Анонимные вызовы каталога на публичном сайте не требуют ключа; ключи важны для стабильной идентичности автоматизации и для закрытых собственных серверов. О той же операции через curl и MCP тоже см. Одна операция, четыре клиента.