¿Cómo utilizar BLOB con JSON y PHP?

Tengo una base de datos remota con MySQL, y estoy almacenando fotos de los usuarios de mi aplicación en la base de datos como una fila de la base de datos con el tipo LONGTEXT.

Transforme las fotos en una cadena con Base64.

Me conecto a mi base de datos remota con JSON y PHP, porque esto, tengo que usar Base64, porque como sé, JSON y PHP necesitan enviar cadenas en los parámetros, y con Base64 puedo transformar la foto en una cadena.

Funciona bien, pero es muy lento. Cuando estoy cargando una foto de 100 KB, se necesita mucho tiempo, pero cuando estoy cargando una foto de 5 KB, solo toma dos o tres segundos.

Un amigo me dijo que usar BLOB en lugar de Base64, pero ¿cómo puedo utilizar BLOB con JSON y una conexión PHP a la base de datos? Además, necesito almacenar las imágenes en una fila de la tabla USER . Esto se debe a que los usuarios no tienen privilegios para cargar archivos en el servidor remoto, pero pueden cargar fotos al cargarlos como una cadena en una fila de la tabla USER .

Gracias

EDITAR:

Este es el código en el que toma un tiempo looot esperando (espera en la línea: while ((line = reader.readLine()) != null) { , está esperando en reader.readLine() )

Este código obtiene un usuario de la base de datos remota, toma un loooooot de tiempo para mostrar al usuario en mi aplicación

 public Friend RetrieveOneUser(String email) { Friend friend=null; String result = ""; //the parameter data to send ArrayList<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>(); nameValuePairs.add(new BasicNameValuePair("email",email)); //http post InputStream is=null; try{ HttpClient httpclient = new DefaultHttpClient(); HttpPost httppost = new HttpPost(this.BaseURL + this.GetOneUser_URL); httppost.setEntity(new UrlEncodedFormEntity(nameValuePairs)); HttpResponse response = httpclient.execute(httppost); HttpEntity entity = response.getEntity(); is = entity.getContent(); }catch(Exception e){ Log.e("log_tag", "Error in http connection "+e.toString()); } //convert response to string try{ BufferedReader reader = new BufferedReader(new InputStreamReader(is,"iso-8859-1"),8); StringBuilder sb = new StringBuilder(); String line = null; while ((line = reader.readLine()) != null) { sb.append(line + "\n"); } is.close(); result=sb.toString(); }catch(Exception e){ Log.e("log_tag", "Error converting result "+e.toString()); } //parse json data try{ JSONArray jArray = new JSONArray(result); for(int i=0;i<jArray.length();i++) { JSONObject json_data = jArray.getJSONObject(i); friend=new Friend(json_data.getString("email"),json_data.getString("password"), json_data.getString("fullName"), json_data.getString("mobilePhone"), json_data.getString("mobileOperatingSystem"),"",json_data.getString("photo")); } } catch(JSONException e){ Log.e("log_tag", "Error parsing data "+e.toString()); } return friend; } 

Segmente la solicitud en dos partes:

  • Primero descarga el JSON con todo, excepto la imagen, devuelve una referencia a la imagen como una URL
  • Segunda descarga de la imagen como un bloque binario, potencialmente de forma asíncrona dependiendo de la aplicación

Supongo que tienes algo como http://example.com/userinfo/xxx como un punto final que devuelve el JSON? Agregue un punto final como http://example.com/userinfo_image/xxx para devolver sólo la imagen y, a continuación, puede devolverla como un fragmento binario en lugar de Base64 codificándolo en el JSON.

Esto significa que usted hace dos peticiones HTTP en lugar de una, pero dependiendo de la aplicación puede ser capaz de hacer la carga de la imagen asincrónicamente, y si es así normalmente obtener una gran ganancia en el tiempo de respuesta de aplicación percibida desde la perspectiva de los usuarios.

Para obtener información sobre imágenes de carga perezosa en el fondo, vea la publicación en el blog de desarrolladores de Android para obtener una muestra:

http://android-developers.blogspot.com/2010/07/multithreading-for-performance.html

Si no puede cargar perezoso de la imagen considerar hacer solicitudes paralelas para la imagen y el JSON al mismo tiempo. Con la versión binaria de la imagen teniendo mucho menos ancho de banda de la red, y un procesamiento mucho menos una vez que obtenga los datos en el teléfono, todavía debe parecer mucho más rápido.

¿Por qué no volcar su imagen como un archivo en el servidor y devolver la url del archivo escrito en su json? Éste es realmente cómo usted debe hacer lo que usted quiere hacer puesto que el HTTP es el protocolo que usted debe utilizar para transferir imágenes sobre la tela.

Código similar a esto debe hacer lo que quiera en el servidor

  //code to get your row from database //Code that writes it to a file. $Data = $row['myblobfield']; $fp = fopen('myimgname.jpg', 'w'); fwrite($fp, $Data); fclose($fp); 

Esto escribirá sus blob o campos longtext como un archivo en su servidor que puede descargar desde su aplicación móvil. A continuación, puede eliminar estos archivos temporales después de un intervalo.

Espero que esto sea útil

Para responder a su pregunta: No, JSON no admite datos binarios, debe escapar de alguna manera antes de enviarlo. Guardarlo como BLOB en MySQL no va a arreglar los problemas de infraestructura más importantes que tiene.

De lo que yo entiendo que tiene un dispositivo Android que está subiendo una imagen a un servidor PHP, este servidor PHP es la codificación de la imagen a Base64, poniendo que en una cadena JSON y luego publicarlo a un control remoto (¿cómo remoto es remoto? En todo el mundo en el espacio en órbita alrededor de la luna) servidor MySQL a través de una interfaz HTTP de algún tipo, que el servidor MySQL está almacenando la imagen Base64 como LONGTEXT. Para recuperar la imagen, el cliente Android envía una solicitud a PHP, PHP envía una solicitud al servidor MySQL remoto, PHP tiene que descodificar a Base64 la imagen y enviarla.

Esto es horriblemente ineficiente, vas a sufrir latencia en cada paso del camino.

Editar: bien parece que esto es un problema del lado del cliente y no un problema del lado del servidor …

Si ese es el caso, entonces me gustaría sugerir la comprobación de los mensajes @ Subiendo imágenes a un servidor PHP de Android, ya que deberían tener algunos ejemplos más eficientes.

¿La lentitud proviene de la codificación json / base64 de 100K de datos, o del hit de la base de datos? Es probablemente de la codificación, y poner los archivos en el sistema de archivos (como todo el mundo en los comentarios está llorando), en pequeña escala, no va a hacer un poco de diferencia.

Hacer algunas mediciones en las diferentes partes de la operación, y tratar de determinar por qué es lento. No sé de qué otra manera obtendrías una imagen en una cadena codificada json sin base64, supongo que podrías intentar escapar de todo, lo que podría ser tan lento, y espero que el analizador no se ahogue en él.

¿Está utilizando la función json_encode en php o construye manualmente la cadena? Trate de construir manualmente. ¿Es usted base64 codificación de datos sin procesar de la base de datos, o es codificado antes de su almacenado, debe codificar antes de su almacenado para ahorrar tiempo al salir.

  • Subir imagen de la aplicación PhoneGap Cordova
  • Android - skia decoder-> decodificar devuelto falso
  • Autenticación de Firebase en el sitio web de wordpress
  • ¿Por qué el audio subido está dañado cuando la subida es claramente exitosa?
  • ¿Cuál es mejor para redirigir, resolución de pantalla o agente de usuario?
  • Utilice la función PHP openssl_verify () para verificar Firma y datos creados por Android Client APP
  • tools / android devuelto no puede encontrar sdkmanager.jar
  • Archivo de imagen de Android enviado a archivo de imagen de carga de php es el tipo de aplicación / octet-stream y no image / jpeg?
  • Symfony2 - Cómo comprobar si estamos siendo llamados desde un dispositivo móvil
  • Enviar la imagen de Base64 desde Android con JSON a php webservice, decodificar, guardar en SQL
  • Implementación C2DM código PHP
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.