Как получить PDF, созданный с помощью PHP WkHtmlToPdf для загрузки с Slim 3 без нарушения кодировки
Я создаю PDF из HTML, используя php wkhtmltopdf
Если я сохраню файл прямо на моем сервере, PDF-файл работает
$pdf->saveAs('/path/to/mypdf.pdf');
Если я сначала преобразую его в строку, а затем сохраню в файл с php, файл pdf будет работать.
$content = $pdf->toString();
$file = '/path/to/mypdf.pdf';
file_put_contents($file, $content);
Но независимо от того, какие заголовки я пытался включить, загруженный файл PDF не работает, и когда я проверяю его, он полон символов ((который, насколько я знаю, обычно исходит из неправильной кодировки)
Я перепробовал каждую конфигурацию заголовка, которую смог придумать, и все равно получаю тот же результат:
Вот пара моих попыток:
$response = $response->withHeader( 'Content-type', 'application/pdf' );
$content = $pdf->toString();
$response->write($content);
а также
$response = $response->withHeader('Content-Type', 'application/pdf');
$response = $response->withHeader('Pragma', "public");
$response = $response->withHeader('Content-disposition', 'attachment; filename=test.pdf');
$response = $response->withHeader('Content-Transfer-Encoding', 'binary');
$response = $response->withHeader('Content-Length', strlen($content));
$response = $response->write($content);
return $response;
Вот пример содержимого из файлов PDF до и после загрузки:
перед загрузкой:
%PDF-1.4
1 0 obj
<<
/Title (˛ˇMyPDF Test type1)
/Creator (˛ˇwkhtmltopdf 0.12.3)
/Producer (˛ˇQt 4.8.7)
/CreationDate (D:20170312220641+02'00')
>>
endobj
3 0 obj
<<
/Type /ExtGState
/SA true
/SM 0.02
/ca 1.0
/CA 1.0
/AIS false
/SMask /None>>
endobj
4 0 obj
[/Pattern /DeviceRGB]
endobj
7 0 obj
<<
/Type /XObject
/Subtype /Image
/Width 301
/Height 181
/BitsPerComponent 8
/ColorSpace /DeviceGray
/Length 8 0 R
/Filter /FlateDecode
>>
stream
xúÌ]w@Gfl£É†R,®à
å
[DçöœäΩ˜D£±ã[å∆ª£bÕg"v
®{/ÿQ∞+E§fi|ª;≥w{ª≥ºF>˘˝°∑;˝«ÓÏõ˜fiº!,|ÇÍU∂!§·P¡ªÇgÖåú$,}ªœ€uÒ—ÎåÔ/Ôûfl∑í£ïºí•ÇÇ]%õ)·)’á*}~=r˜mFF∆ãQ·≠‹Kà’V=®Æµk÷®^›fløJï ï¸|+VÙˆ™‡QäPt)$"Ã$a˝ï1©ëdFn_ÕøA◊´ÜÚˆ‚&n2äñ9FÂæ]M"õÂ&∫7
3îìØ—ÅîΩ}*˝ΩkÄ4Nªÿ¨£ƒ9Ké"(ôŒπL2#·3‰:æπ+c|$◊áYJd´Ùê˛¸"ê\z¿CL˚o‘≤ƒf∑;#É,–ÿv3˝ˇ©2í£h¯úÓfiJ©|«>n/i™]2…™˙Ä U∏üÍ∑W†˝¸≈˛∏¸•œ ‡JŸ“.J.Y
YøäÁ≤
ª-fi‰ù‚Û£vd-∆&÷{ ‹˛ãŒòŒÁeêZñÿ≠W≤*˝ÆYJÚ£áI)ö˜¢™ã’†≤ü©⁄zÛ‘—cßn`5ˇ‹Ö_¬ı¢Ær˝K¸©O≤Bo©ÎV^Ÿ1(¥A`@˝–Å≥7_»Sß<j-RÖÓdπ›Ảò‹ õ|ém|€GD´¯zTñ_§‹e:)a√˙
ÇX€S·pPèd
»PÚ`EXvRŸNKÆ©sF
после загрузки:
PDF-1.4
1 0 obj
<<
/Title (���M�y�P�D�F� �T�e�s�t� �t�y�p�e�1)
/Creator (���w�k�h�t�m�l�t�o�p�d�f� �0�.�1�2�.�3)
/Producer (���Q�t� �4�.�8�.�7)
/CreationDate (D:20170312222109+02'00')
>>
endobj
3 0 obj
<<
/Type /ExtGState
/SA true
/SM 0.02
/ca 1.0
/CA 1.0
/AIS false
/SMask /None>>
endobj
4 0 obj
[/Pattern /DeviceRGB]
endobj
7 0 obj
<<
/Type /XObject
/Subtype /Image
/Width 301
/Height 181
/BitsPerComponent 8
/ColorSpace /DeviceGray
/Length 8 0 R
/Filter /FlateDecode
>>
stream
x��]w@Gߣ��R,��
�
[D��ϊ��D���[����b�g"v
�{/�Q�+E��|�;�w{���F>����;�����!,|��U�!��P���g���$,}���u����/
�߷��������]%�)�)��*}~=r�mFFƋQ��K��V=���k�
n2��9F�]M"��&�7
3���с��}*��k�4N�ج��9K�"(�ιL2#�3�:��+c|$ׇYJd�����"�\z�CL�oԲ�f�;#�,��v3���2��h����J�|�>n/i�]2ɪ���U���W�����������J��.J.Y
Y���
�-����vd-�&�{ ���Θ��e�Z�حW�*��YJ�I)�����ՠ����z���c�n`5�܅_����r�K��O�Bo��V^�1(�A`@�Ё�7_�S�<j-R��d��A����ʛ|�m|�GD��zT�_��e:)a��
1 ответ
Одна вещь, которую я заметил, заключалась в том, что в вашем PDF-файле нет рекомендованного двоичного комментария под строкой заголовка.
Из справочника PDF:
Примечание. Если файл PDF содержит двоичные данные, как это делают большинство (см. Раздел 3.1, "Лексические условные обозначения"), рекомендуется, чтобы за строкой заголовка сразу следовала строка комментария, содержащая как минимум четыре двоичных символа, то есть символы, чьи коды 128 или больше. Это обеспечит правильное поведение приложений передачи файлов, которые проверяют данные в начале файла, чтобы определить, следует ли рассматривать содержимое файла как текст или как двоичный файл.
например.
%PDF-1.4
%����
Это написано в узле как %\xFF\xFF\xFF\xFF
Я не уверен, что эквивалент в PHP будет.
Я не вижу никаких опций в phpwkhtmltopdf или wkhtmltopdf, которые, по-видимому, имеют к этому прямое отношение, но были 'encoding' => 'UTF-8'
в качестве опции для команды оболочки.
Я бы порекомендовал изучить варианты в этой области, поскольку, очевидно, что что-то между сервером и вами повреждает Unicode в файле.