2012-03-15 11 views
5

Tengo problemas para la codificación JSON de caracteres especiales. Estos caracteres se muestran normalmente en mi computadora, en el Bloc de notas, en los navegadores e incluso en mi base de datos. Sin embargo, no codifican JSON. Un ejemplo es el siguiente:json_encode codifica cadenas con caracteres Unicode (derechos de autor) como nulos?

<? 
$array['copyright_str'] = "Copyright site.com © 2011-2012"; 
echo json_encode($array); 
?> 

El símbolo de copyright después site.com es lo que está haciendo la cadena JSON eco como {"copyright_str":null}. Si bien esto es simple, tengo usuarios que ingresan datos de perfil en una base de datos que puede ser cualquier cosa. Cuando uno de estos personajes funky aparece, rompe las cosas. ¿Cuál es una buena solución para este problema? La API codificada se basa en gran medida en la devolución de datos de la base de datos y en las cadenas de impresión en general como JSON.

Mi configuración de varios bytes son los siguientes:

 php -e phpinfo.php | grep mb 
    Configure Command => './configure' '--enable-bcmath' '--enable-calendar' '--enable-dbase' '--enable-exif' '--enable-ftp' '--enable-gd-native-ttf' '--enable-libxml' '--enable-magic-quotes' '--enable-mbstring' '--enable-pdo=shared' '--enable-sockets' '--enable-zip' '--prefix=/usr/local' '--with-apxs2=/usr/local/apache/bin/apxs' '--with-bz2' '--with-curl=/opt/curlssl/' '--with-curlwrappers' '--with-freetype-dir=/usr' '--with-gd' '--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr' '--with-jpeg-dir=/usr' '--with-kerberos' '--with-libdir=lib64' '--with-libexpat-dir=/usr' '--with-libxml-dir=/opt/xml2/' '--with-mcrypt=/opt/libmcrypt/' '--with-mhash=/opt/mhash/' '--with-mysql=/usr' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-mysqli=/usr/bin/mysql_config' '--with-openssl=/usr' '--with-openssl-dir=/usr' '--with-pcre-regex=/opt/pcre' '--with-pdo-mysql=shared' '--with-pdo-sqlite=shared' '--with-pic' '--with-png-dir=/usr' '--with-sqlite=shared' '--with-ttf' '--with-xmlrpc' '--with-xpm-dir=/usr' '--with-zlib' '--with-zlib-dir=/usr' 
    xmlrpc_error_number => 0 => 0 
    mbstring 
    Multibyte string engine => libmbfl 
    mbstring extension makes use of "streamable kanji code filter and converter", which is distributed under the GNU Lesser General Public License version 2.1. 
    mbstring.detect_order => no value => no value 
    mbstring.encoding_translation => Off => Off 
    mbstring.func_overload => 0 => 0 
    mbstring.http_input => pass => pass 
    mbstring.http_output => pass => pass 
    mbstring.internal_encoding => no value => no value 
    mbstring.language => neutral => neutral 
    mbstring.strict_detection => Off => Off 
    mbstring.substitute_character => no value => no value 

me gustaría evitar guardar cosas como &copy;. Algunos de estos datos se almacenarán como texto sin formato.

+0

¿Está compilado PHP para Unicode/MB? Y, además, ¿'json_encode' funciona correctamente en Unicode/MB? –

+0

Use el valor de ascii en su lugar –

+3

@IbrahimAzharArmar Hay muchos caracteres Unicode que * no tienen equivalente ASCII *. –

Respuesta

10

codificar datos en formato UTF-8 antes de pasarla a la función json_encode

<? 
    $array['copyright_str'] = utf8_encode("Copyright site.com © 2011-2012"); 
    echo json_encode($array); 
?> 
+2

+1, pero supone que está almacenando y manejando todos sus datos como ISO-8859-1, lo que significa que su aplicación no admitirá caracteres Unicode fuera de esa codificación. A largo plazo, es mejor migrar por completo a UTF-8. – bobince

+0

en ese caso puede usar mb_detect_encoding para verificar los datos actuales en qué formato y luego convertirlo a UTF-8 usando mb_convert_encoding –

+1

Bueno ... teniendo en cuenta que 'mb_detect_encoding' solo una conjetura aproximada que podría ser incorrecta, sí . – bobince

-4

Uso urlencode antes json_encode

<? 
$array['copyright_str'] = "Copyright site.com © 2011-2012"; 
$array['copyright_str'] = urlencode($array['copyright_str']); 
echo json_encode($array); 
?> 
+4

¿Por qué? No es una URL. Eso * alteraría los datos * y requeriría que el consumidor hiciera lo contrario. –

+0

Pero escapará del carácter de copyright y lo convertirá en '©'. La inversión es trivial. – xbonez

+0

Ese no es el problema o la solución. Imagine si es * un carácter * Unicode diferente (por ejemplo, un ☃, que es un muñeco de nieve). ¿Cómo se manejaría * ese *? Si se trata de un caso puntual, claramente * no es confiable * (a menos que haya un * error * con PHP que * solo * afecte al carácter Unciode para el símbolo de copyright). –

2

estoy codificación de datos con toneladas de UTF-8 símbolos con

json_encode($return, JSON_UNESCAPED_UNICODE) 

y funciona bien. Lo uso para codificar todo tipo de idiomas: árabe, chino, tailandés, lituano, alemán, francés, español, etc. Todos ellos tienen diferentes símbolos únicos. Oh, no he intentado codificar muñecos de nieve ☃ :)

Cuestiones relacionadas