1

Tengo un problema con la Ñ en mi programa lo cual lo solucione cambiando la Ñ por &Ntilde. El html esta en UTF-8. Ni javascript ni html tienen problema con &Ntilde y php aveces. Lo que pasa es que si PHP recibe de AJAX NU&NtildeO (NUÑO) todo pasa como debería pero si PHP recibe de AJAX &NtildeA&NtildeEZ (ÑAÑEZ) lo que la variable obtiene es un "" esto solo pasa cuando lo que manda AJAX empieza con &Ntilde. Para cambiar Ñ a &Ntilde lo que hago en javascript es.

valor=valor.replace(/[Ñ]/g,"&Ntilde");

Si AJAX manda NU&NtildeO imprime NUÑO y si AJAX manda &NtildeA&NtildeEZ imprime "".

$apellido = $_POST['apellido'];
echo $apellido;

Alguien sabe por que pasa esto?

jufrfa
  • 97
  • 1
  • 12
  • 1
    Vas a necesitar emprender ***[un camino de retorno hacia tus datos](https://es.stackoverflow.com/a/59510/29967)***, para encontrar la raíz del problema. Eso te evitará aplicar conversiones de los datos a medio camino, y el rendimiento de tu aplicación se verá afectado a la corta o a la larga. – A. Cedano Nov 10 '17 at 15:53

1 Answers1

1

En vez de ponerte tú mismo a reemplazar todos los caracteres UTF-8 con todos los casos de borde que puedes obtener, mejor codifica el string al enviarlo, y decodifica al recibirlo:

var valor_codificado=encodeURIComponent(valor);
// Esto convierte "ÑAÑEZ" a "%C3%91A%C3%91EZ"

Y del lado del servidor

$apellido = urldecode($_POST['apellido']);
echo $apellido;

Edit: de dónde viene el problema?

Depende de cómo estés enviando la información al backend (por ejemplo usando un formulario con enctype='application/x-www-form-urlencoded' que es el enctype por defecto), éste podría estar recibiendo una cadena del tipo

nombre=juan&apellido=perez&telefono=5552419

Lo cual se parsea como

nombre = 'juan'
apellido = 'perez'
telefono = '5552419'

Si uno de los parámetros empieza con ampersand & lo que recibe el backend es

nombre=juan&apellido=&NtildeA&NtildeEZ&telefono=5552419

Lo que parsea el backend es

nombre = 'juan'
apellido = ''
NtildeA = ''
NtildeEZ= ''
telefono = 5552419

Este comportamiento sería distinto si tu formulario tuviera el atributo enctype='multipart/form-data'

De la misma manera, si estás haciendo la petición por ajax, el atributo contentType de la petición puede provocar que la información pase ya sea a la superglobal $_POST o pase como un payload en el body de la petición, en cuyo caso tendrías que capturarla usando algo como file_get_contents("php://input") o algún método de conveniencia que te ofrezca el framework en uso.

Edit 2

Vale la pena mencionar que el htmlentity de la Ñ es Ñ terminado en punto y coma.

ffflabs
  • 21,223
  • 25
  • 48
  • Yo iría corrigiendo en cada etapa, hasta dar con el problema. Considero que no es buena idea aplicar funciones de codificación/decodificación a medio camino. Si hay que codificar/decodificar, significa que el problema está a otro nivel más profundo y hay que llegar a él para corregirlo de raíz. – A. Cedano Nov 10 '17 at 15:56
  • Voy a añadir un edit explicando por qué pasa este fenómeno – ffflabs Nov 10 '17 at 16:02
  • Debería revisar siempre en primer lugar el editor o el origen de sus datos, para ver cómo están codificados. Si están bien, entonces, empezar a revisar desde el DOM y seguir luego en el servidor, la conexión a la base de datos y la base de datos. Si quiere utf8, todo debería estar en utf-8, y lo que no lo esté debería corregirlo en ese orden. – A. Cedano Nov 10 '17 at 16:05
  • @A.Cedano No digo lo contrario, pero tú mismo has posteado que es mejor diseñar sin asumir que conoces la configuración del backend. (Por ejemplo usando la constante del separador de carpetas en vez de un simple slash). De la misma manera la sanitización de inputs que son llenados libremente desde el front me parece una buena práctica. Con o sin utf8 habilitado, el uso de `encodeURIComponent` premitiría la entrada en cirílico, cuneiforme, runas célticas y parseltongue – ffflabs Nov 14 '17 at 15:50