Los problemas de acentos con NetBeans

codificacion

De todas mis colaboraciones y aportes en foros especializados y blogs, el artículo que escribí hace unos años aquí con titulo La solución a los problemas con los acentos en PHP, MySQL y HTML, que trata sobre el cotejamiento de caracteres y los problemas que te puedes encontrar al usar distintas codificaciones al desarrollar tu aplicación es, sin duda, el que mas ha ayudado a otros compañeros programadores, ya que a diario recibo cientos de visitas y muchos dejais comentarios y emails de agradecimiento.

Pero entre las consultas que me suelen llegar, hay una pregunta que me hacen a menudo sobre algo que no se trata en el artículo y como es algo que ya he investigado he decidido crear un post con la solución que he podido encontrar. Y trata sobre lo complicado que se hace resolver a veces estos problemas cuando utilizamos NetBeans como IDE habitual de desarrollo.

Seguir leyendo

Anuncios
Publicado en Uncategorized | Deja un comentario

PDO prepared statements: Resumen de uso

 

Como ya indiqué en mi artículo anterior, es fundamental saber cómo utilizar PDO combinado con Sentencias Preparadas para realizar correctamente y de forma segura consultas con nuestra base de datos MySQL. Uno de los motivos para usar PDO es porque ya PHP ha declarado obsoletas la extensión mysql original, aunque tenemos la opcion de usar también la extensión MySQLi, yo personalmente prefiero usar PDO. A continuación dejo un resumen de cómo se puede usar tanto para SELECT, como para INSERT y UPDATE.

PDO también se pueden usar con Transacciones, pero eso lo veremos de forma extensa mas adelante. Seguir leyendo

Publicado en Uncategorized | Deja un comentario

¿Por qué se sigue usando mysql_query?

digital-388075_1920

¿Por qué se sigue usando todavía mysql_query? ¿Hay programadores que aún no utilizan PDO?

Últimamente me están llegando muchas consultas de programadores que se están iniciando en este apasionante mundo y de muchos otros que ya llevan tiempo programando, pero que continúan haciéndolo como les enseñaron y veo que se sigue utilizando mucho las funciones de consulta a las bases de datos de mysql_query y compañía.

Ciertamente, no entiendo el motivo por el que todavía se enseña a programar así, de hecho, no entiendo por qué desde el primer momento no se enseña a programar correctamente. Hay una gran tendencia en los cursos y masters a separar la parte de PHP del MySQL, el HTML y el CSS. Eso sin meterme en javascript, que quizás es lo único que puedo entender que se separe del resto. Hoy en día para programar una página web necesitas de estos 5 elementos y cuando aprendes a programar webs, nunca sabes si vas a trabajar en un equipo con analistas expertos que te van a indicar cómo ensamblar estas partes y te lo van a dar todo hecho, o si vas a estar sólo y tendrás que encargarte de realizar todo tu. Si una de estas partes cojea, no te vas a divertir programando y el resultado puede ser desastroso. Porque lo que está claro es que si no te diviertes programando te has equivocado de camino. Es fundamental disfrutarlo para poder pasar tantas horas delante de una pantalla y un teclado.

Seguir leyendo

Publicado en php | Deja un comentario

La solución a los problemas con los acentos en PHP, MySQL y HTML

Somos muchos los que, cuando estamos comenzando a programar, nos encontramos con un problema que a veces nos consume mucho mas tiempo del que debería y a veces al buscar una solución en la red lo complicamos todavía más, debido a la gran cantidad de información existente y a que en muchas de las webs y blogs que he estado viendo te lian mas que ayudan.

Yo voy a explicar mi método, sin entrar a ver las diferencias entre ISO 8859-1 y UTF-8, que son las dos mas comunes.

En mi caso yo siempre uso UTF-8 y la razón es que en las aplicaciones que estoy desarrollando utilizo mucho la clase SimpleXML de PHP y todos los datos extraidos con esta clase siempre están codificados en UTF-8, si mi aplicación utilizara ISO-8859-1 tendría que pasar toda la información por la función utf8_decode() de PHP, con lo que estaría sobrecargando el script sin necesidad.

La clave está en que hay que “decirle a todo” que cotejamiento es el que estamos utilizando.

1.- Codificación del documento.

En primer lugar hay que comprobar la codificación del documento, si usas DW y Windows en español posiblemente el valor de Codificación por defecto lo tendrás en Europeo occidental.

En Dreamweaver lo puedes comprobar pulsando CRTL-J, o en modificar – propiedades de pagina.

En Notepad++ lo verás en la pestaña Codificación.
Codificacion del archivo almacenado en PC

Si esto lo tienes bien, tu etiqueta <meta> del documento debería ser como sigue:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

2.- MySQL

Aquí es donde surgen la mayor parte de los problemas. Cuando creamos las tablas en la base de datos tenemos que tener especial cuidado de que todos los cotejamientos estén en utf-8. Cuando lo dejas por defecto, si utilizas phpmyadmin este proceso se convierte en una lotería y cuando termines de crear tu base de datos verás que cada cosa está cotejada de forma diferente…

Yo voy a utilizar UTF-8, si te decantas por ISO-8859-1, en todas las selecciones que nombro a continuación tendrás que elegir latin1_general_ci, si eliges latin1_spanish_ci también funcionará, pero por favor, usa en todas lo mismo.

Cotejamiento para las conexiones al servidor.

Cotejamiento de conexiones al servidor.

Cotejamiento para la base de datos

En la pestaña operaciones de la pantalla principal de la base de datos

Cotejamiento Base Datos

Cotejamiento para las tablas.

Cada tabla que creemos deberá tener el mismo cotejamiento

Cotejamiento de Tabla

Cotejamiento de Campo o Columna.

Es importante indicar el cotejamiento que va a tener el Campo, sobre todo si en este vamos a almacenar caracteres de texto. Lógicamente a un campo numérico, booleano etc no hay que indicar el cotejamiento porque su contenido no incluirán caracteres “extraños”.

Cotejamiento de Campo

3.- PHP

Por último vamos a “decirle” al Mysql en PHP cómo nos vamos a comunicar con la base de datos para que no haya ningún tipo de confusión.

Yo utilizo siempre PDO para la conexion de PHP con la base de datos, pero esto es otro tema que da para mucho. Así quedaría la conexión. Al crear el manejador de la conexión hay que incluir en el array de opciones la codificación, como sigue:

$pdo = new PDO('mysql:host= servidor; dbname=bd', $usuario, $clave, array(PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES  \'UTF8\''))

Si usas la conexion estandar, basta con añadir

mysql_set_charset('utf8');

justo despues de abrir la conexion con la base de datos.

Publicado en php | Etiquetado , , , , , , , | 93 comentarios

Cuidado con la función extract de php

Cuidado al utilizar la función extract de php.

Estos días he tenido algunos problemas que me ha costado bastante resolver y todo se debe a tratar de programar lo más rápido posible utilizando funciones que supuestamente te “facilitan” el trabajo, pero el problema está cuando utilizas una función de la cual no tienes claro su funcionamiento interno y de la que sólo conoces “lo que hace” pero no el “cómo lo hace”.

Decidí comenzar mi blog publicando esta experiencia porque después de todo el tiempo que he perdido estos días es posible que pueda ayudar a alguien que le esté pasando algo parecido y por casualidad se tope con este artículo. Y si no tienes el mismo problema al menos ya sabes que tienes que ir con cuidado con esta función.

La función en cuestión se llama extract y su utilidad es muy sencilla, simplemente convierte cada elemento de un array asociativo en una variable tomando como nombre de la variable el nombre de la clave de ese elemento.

Ejemplo:

$oferta = array(   "idOferta" => "2344",    "titulo" => "Oferta de viaje a Tanger",   "descripcion" => "Oferta de viaje que incluye Ferry ida y vuelta y alojamiento"
);
extract($oferta);
/**
*
* Obtenemos las siguientes variables: $idOferta, $titulo, $descripcion
*
**/

En mi caso el array procedía de una consulta de una tabla con 15 campos, con lo que el resultado es de un array con 15 elementos, que tras pasar por la función extract se convertía en 15 variables en una sola línea.

Hasta aquí todo bien, el problema consiste en que esta función en algún momento de su ejecución “toca” las variables de sesion ($_SESSION[]) y si no estas usando variables de sesión no importa.

El problema es que la aplicación dónde estaba usando la función extract funcionaba perferctamente, pero en el back, donde los usuarios cargan los datos de la web estaban sucediendo cosas muy extrañas, me explico.

Cuando un usuario inicia sesión en nuestro backoffice tiene una serie de permisos y privilegios, pero también se le establecen unos filtros para que solo pueda ver las ofertas que pertenecen al grupo que se les haya asignado su mantenimiento. Cada grupo corresponde con un número y al iniciar sesión queda almacenado en una variable de sesión que se llama $_SESSION[‘grupo’].

El problema surgía, y de aquí la dificultad para su localización (al menos para mi), cuando un usuario que tiene iniciada sesión en el back accedía al front (la parte de cliente) sin cerrar la sesion, concretamente a la página donde se utilizaba la función extract.

La tabla de donde procedía el array al que se le aplicaba la función extract tiene un elemento que se llama “grupo”, que no tiene nada que ver con el grupo de la sesión de usuario, pero los valores si que son similares (numeros enteros de 1 o 2 cifras).

Despues de ejecutarse extract se obtenia como resultado la variable $grupo, pero la variable $_SESSION[‘grupo’] (que pertenecía a la sesión del back) cambiaba su valor y tomaba como nuevo valor el mismo que $grupo, por esto deduzco que para pasar del array a las variables la función extract crea variables de sesión como valores intermedios.

Después de ejecutar la función extract el usuario volvía a su back y todos los filtros habían cambiado, ya no estaba viendo los productos asignados a su grupo, sino que salían otros. Y no podía volver a acceder a sus productos si no cerraba e iniciaba sesión de nuevo.

El usuario me decía que de vez en cuando se le cambiaban los productos y tenía que iniciar sesión de nuevo, pero no lo asociaba a que sucedía tras pasar por la página de cliente, por lo que estuve dos días enteros revisándome el código del backoffice y tratando de simular el fallo y todo era correcto, hasta que pude localizar que el origen del error no estaba aquí, sino en otra parte de la página totalmente diferente.

En resumen, si tienes que usar la función extract en php ten cuidado de que no exista ninguna variable de sesión que utilize el mismo nombre que alguna de las claves del array que quieres extraer…. en ninguna parte de tu web.

Publicado en php | Etiquetado , , , , , , , , | 1 Comentario