Devo essere in grado di inviare un'immagine e alcuni campi modulo da un elemento canvas lato client a uno script PHP, finendo in $ _POST e $ _FILES. Quando invio in questo modo:
<script type="text/javascript">
var img = canvas.toDataURL("image/png");
...
ajax.setRequestHeader('Content-Type', "multipart/form-data; boundary=" + boundary_str);
var request_body = boundary + '\n'
+ 'Content-Disposition: form-data; name="formfield"' + '\n'
+ '\n'
+ formfield + '\n'
+ '\n'
+ boundary + '\n'
+ 'Content-Disposition: form-data; name="async-upload"; filename="'
+ "ajax_test64_2.png" + '"' + '\n'
+ 'Content-Type: image/png' + '\n'
+ '\n'
+ img
+ '\n'
+ boundary;
ajax.send(request_body);
</script>
$ _POST e $ _FILES entrambi tornano popolato, ma i dati dell'immagine in $ _FILES ha ancora bisogno di decodifica in questo modo:
$loc = $_FILES['async-upload']['tmp_name'];
$file = fopen($loc, 'rb');
$contents = fread($file, filesize($loc));
fclose($file);
$filteredData=substr($contents, strpos($contents, ",")+1);
$unencodedData=base64_decode($filteredData);
... al fine di salvarlo come PNG leggibile. Questa non è un'opzione in quanto sto cercando di passare l'immagine alla funzione media_handle_upload() di Wordpress, che richiede un indice per $ _FILES che punta a un'immagine leggibile. Inoltre, non posso decodificare, salvare e modificare "nome_tmp" di conseguenza, in quanto ricade sui controlli di sicurezza.
Così, ho trovato questo: http://www.webtoolkit.info/javascript-base64.html e ho cercato di fare la decodifica sul lato client:
img_split = img.split(",",2)[1];
img_decoded = Base64.decode(img_split);
ma per qualche motivo non ho ancora finire con un file leggibile quando si arriva a il PHP. Quindi la domanda è: "Perché?" o "Cosa sto facendo di sbagliato?" o "E 'anche possibile?" :-)
Qualsiasi aiuto molto apprezzato!
Grazie, Kane
Avrei impostato un 'Content-Transfer-Encoding: base64' e ho guardato [questa risposta] (http://stackoverflow.com/questions/934012/get-image-data-in-javascript) per perdere il prefisso, non l'ho provato però. – Wrikken
@Wrikken Content-Transfer-Encoding, sebbene un'intestazione MIME valida, non è un'intestazione HTTP valida. Vedi [questa appendice] (http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.5) della specifica. –
@Nathan: Ack, mio errore. Mostra che non ho mai avuto bisogno di costruire manualmente un caricamento di file :) – Wrikken