Данные изображения повреждены на пути к браузеру

Question

У меня есть приложение, работающее под Drupal в среде LAMP. Он выводит изображения из базы данных. На моей персональной машине (OS X Lion) она работает правильно. На сервере dev (Amazon EC2) тот же самый код не работает. Оба сервера работают с PHP 5.3. Я подтвердил, что данные повреждаются между echo $fileData и получают его браузер. Кроме того, я подтвердил, что данные НЕ повреждены, если они закодированы в base64 (я использовал скрипт для запроса данных, декодирования и сохранения его в файл).

На стороне Drupal код находится в модуле, который создает обратный вызов меню; функция обратного вызова echos данные файла напрямую, чтобы избежать хранения всего изображения в памяти (я использовал PDO :: FETCH_BOUND с PDO :: PARAM_LOB для создания потока, но теперь он идет в строку, пока я пытаюсь найти проблему , это не так). Элемент меню имеет настраиваемый обратный вызов доставки, который практически ничего не делает. Я попытался очистить любую выходную буферизацию от идеи, что Drupal может слишком сильно пытаться поддерживать Unicode или что-то в этом роде, но это тоже не помогло.

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

Update 1:

я соединял некоторые примеры кода, но не обнаруживали ошибки; Я могу преобразовать код в модуль Drupal, чтобы проверить этот стек кода. Тем не менее, я сузил ошибку до echo $fileData. Код выглядит примерно так:

function example_menu() { 
    $pages['mpicture/%'] = array(
    'title' => 'Picture handler', 
    'page callback' => 'example_picture', 
    'page arguments' => array(1), 
    'delivery callback' => 'example_deliver_png', 
    'access callback' => TRUE, 
    'type' => MENU_CALLBACK, 
); 
} 

function example_picture($fileID) { 
    // Point 1 
    example_output_file($fileID); 
} 

function example_deliver_png($content) { 
} 

function example_output_file($fileID) { 
    $statement = db_select('mfiles', 'f') 
    ->fields('f', array('fileType', 'fileSize', 'fileData', 'fileData64', 'lastModified')) 
    ->condition('fileID', $fileID, '=') 
    ->execute(); 

    if ($file = $statement->fetchAssoc()) { 
    header('Content-Type: ' . $file['fileType']); 
    // Point 2 
    header('Content-Length: ' . $file['fileSize']); 
    echo $file['fileData']; 
    } 
} 

Это не работает. Если изменить Point 2 к этому:

// Point 2 
    header('Content-Length: ' . $file['fileSize']*4/3); 
    echo $file['fileData64']; 

Он работает правильно, до тех пор, как мой клиент запускает base64_decode на выходе. Однако, если я делаю это:

// Point 1 
    ob_start() 
    example_output_file($fileID); 
    $output = base64_encode(ob_get_clean()); 
    header('Content-Length: ' . strlen($output)); 
    echo $output; 

... он не работает с клиентом ИНГ же base64_decode. Как это могло быть?

И да, я храню данные дважды; в каждом отдельном тесте, который я запускаю, неважно, пользуюсь ли я $file['fileData'] или base64_decode($file['fileData64']), поэтому я не думаю, что это проблема с базой данных.

Update 2:

Но любопытно, что это работает:

// Point 1 
    ob_start() 
    example_output_file($fileID); 
    $output = base64_encode(trim(ob_get_clean())); 
    header('Content-Length: ' . strlen($output)); 
    echo $output; 

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

Answer 1

Я собираюсь задушить стажера. Клянусь. Не совсем, это выражение ... но я злюсь.

Вся проблема была в том, что новый файл, который он добавил, имел пустое пространство в конце его. Простой «?> \ N". Это печатное белое пространство перед каждой страницей на сервере, включая обработчик изображения. Пробел сделал изображение поврежденным.

Я думаю, что мораль здесь никогда не закрывает теги PHP в конце файлов, и черт не сомневаюсь, что все, с кем вы работаете, делают то же самое.