Problemas html acentos y eñes: charset UTF-8 / ISO-8859-1

Problemas html acentos y eñes: charset UTF-8 / ISO-8859-1

La codificación de las páginas web (charset) es un problema recurrente para los webmasters, porque:

  • Depende del editor en que se haya hecho la web, si en el trabajamos por defecto en UTF-8 o ISO-8859-1. Si el archivo original estaba escrito en ISO-8859-1 y lo editamos en UTF-8, veremos los caracteres especiales mal codificados. Si guardamos ese archivo tal cual, estaremos corrompiendo la codificación original (se guardará mal, con UTF-8). Y viceversa.
  • Depende de la configuración del Apache.
  • Depende de si hay un archivo oculto .htaccess en el directorio raíz que sirve nuestra web (httpdocs, public_html o similar)
  • Depende de si se especifica en las etiquetas META de los HTML resultantes.
  • Depende de si se especifica en la cabecera de un archivo PHP.
  • Depende del charset elegido en la base de datos (si se usa una base de datos para mostrar contenidos con un CMS, tal como Joomla, Drupal, phpNuke, o una aplicación propia que sea dinámica).

Por lo general, si nunca tienen que aparecer acentos o eñes en nuestra web, nos es indiferente la codificación (aunque pueden haber otros símbolos que nos fastidien). Aunque si nuestra web está en español, lo más normal es que coloquemos acentos y eñes. Para ello, el estándar HTML está preparado para colocar todos los símbolos y acentos que nos sean necesarios, codificándolos. Así, para los acentos y eñes, deberíamos colocar:

á -> á
é -> é
í -> í
ó -> ó
ú -> ú
ñ -> ñ

Variantes valenciano-catalán-balear para acentos abiertos:

à -> à
è -> è
ò -> ò

De este modo, veremos todos caracteres correctamente, independientemente del charset.

Sin embargo, puede ser tedioso para ciertos contenidos tener que ir traduciendo nosotros manualmente los caracteres. Es en estos casos donde vale la pena perder un poco de tiempo para ajustar las distintas configuraciones.


Primero, habría que determinar en nuestra web con las etiquetas META que nuestra web debe servirse en la codificación que nosotros elijamos. O sea, dentro de :

<meta http-equiv=»Content-Type» content=»text/html; charset=UTF-8″ />

o bien

<meta http-equiv=»Content-Type» content=»text/html; charset=ISO-8859-1″ />


Si seguimos con el problema, Segundo, ver si por defecto tiene el servidor (apache) algún charset predefinido. Si es así, se ignorarán las etiquetas META del html.
En un servidor Linux, el archivo charset está en:

/etc/apache2/conf.d/charset

también puede cambiarse en el archivo httpd.conf

Debería aparecer sólo «AddDefaultCharset off», para que haga caso de las etiquetas META (lo ideal). Podemos poner, por ejemplo, «AddDefaultCharset UTF-8», y así apache siempre emitirá las webs en UTF-8. El problema es que esto afecta a todo el servidor, y si luego tenemos alguna web que vaya a usar otra codificación tendremos un problema. Por eso, lo ideal es que esté a Off y que cada web defina cómo quiere mostrarse.

Pero puede darse el caso de que nosotros no seamos los administradores del servidor y sólo tengamos un Plesk, y no podamos acceder al archivo charset por encontrarse fuera de nuestro rango de permisos. Podemos, entonces, pedirle al administrador del servidor que coloque el parámetro anterior a Off, o bien…


Alternativa 1: Colocar un archivo .htaccess en el directorio raíz de la web
Los .htaccess son archivos de configuración que sobreescriben algunas configuraciones del apache sólo para determinados casos. Hay que tener en cuenta que estos archivos:

  • Pueden funcionar total o parcialmente, dependiendo de la configuración del servidor (cuestión de seguridad).
  • Son archivos ocultos, por lo que para verlos tenéis que tener habilitada la función «ver archivos ocultos» en vuestro programa que acceda por ftp.

Este archivo .htaccess debería tener al menos una línea de este tipo

AddDefaultCharset utf-8


Alternativa 2: Colocar una directiva en php que fuerce a mostrarse en la codificación deseada
Esto es, sólo sirve si el archivo tiene extensión «.php». Recordemos que el html y el php pueden convivir en el mismo fichero, con lo que si renombramos un «.html» a «.php», el resutlado es exactamente el mismo (si tenemos instalado el php en nuestro servidor, claro está).
En la primera línea del archivo que deseemos indicarle la codificación (o lo antes posible) deberíais colocar la siguiente cabecera:

<?php header(‘Content-Type: text/html; charset=UTF-8’); ?>


Para todos los casos donde funcione el comando «AddCharset»
– Puede especificarse el charset según la extensión del archivo. Si, por ejemplo, queremos que los «.php» sean UTF-8 y los «.html» sean ISO, podemos colocar estas dos instrucciones seguidas:

AddCharset UTF-8 .php
AddCharset ISO-8859-1 .html

Script en Bash para Backup SQL con un Dump y enviarlo al Mail.

Backup en Bash

#!/bin/sh
timestamp=$(date ‘+%d-%m-%Y@%H:%M’)
mysqldump –user=»USUARIO» –password=»CLAVE» –all-databases | gzip > /home/DIRECTORIO/basesdedatosRentasyWeb_$timestamp.sql.gz
mutt -s «Backup Diario DE USUARIO | $timestamp» -a /home/DIRECTORIO/basesdedatosRentasyWeb_$timestamp.sql.gz -c CORREO-DE-DESTINO@CORREO.COM < /root/mensajebackup.txt rm /home/DIRECTORIO/basesdedatosRentasyWeb_$timestamp.sql.gz echo "Backup hecho, enviado y borrado" #exit 0

COMPRIMIR Y DESCOMPRIMIR .GZ, .TAR.GZ, Y .ZIP POR LINEA DE COMANDOS EN LINUX

Guía de autoayuda, siempre me olvido estos comandos…

Archivos .tar.gz:
Comprimir: tar -czvf empaquetado.tar.gz /carpeta/a/empaquetar/
Descomprimir: tar -xzvf archivo.tar.gz

por ejemplo: tar -comando nombre_comprimido nombre_dir

Archivos .tar:
Empaquetar: tar -cvf paquete.tar /dir/a/comprimir/
Desempaquetar: tar -xvf paquete.tar

Archivos .gz:
Comprimir: gzip -9 index.php
Descomprimir: gzip -d index.php.gz

Archivos .zip:
Comprimir: zip archivo.zip carpeta
Descomprimir: unzip archivo.zip

FlashPolicyd + Ruby en CentOS con CPanel

CPanel modifica el yum.conf y exclude a Ruby… de su instalacion: si no sabes eso, te comes un viaje porque no se explica como con: yum install ruby
no se instala…
asi que para instalar Ruby, primero ejecutamos este comando: /scripts/installruby
(asi de corta y esperar.. )

Ahora, con Ruby instalado, podemos instalar el Flash Policyd:

> wget http://www.lightirc.com/release/flashpolicyd.zip
> unzip flashpolicyd.zip
> cd flashpolicyd
> wget https://raw.github.com/ripienaar/flashpolicyd/master/flashpolicyd.rb --no-check-certificate -O flashpolicyd.rb
> chmod a+x flashpolicyd.rb

flashpolicyd (ambos archivos)

Ejecutamos:

 ./flashpolicyd.rb --xml flashpolicy.xml --logfile flashpolicyd.log

 

 

Cambiar de Kernel de OVH a CentOS original…

Los tipo de OVH cuando instalas CentOS te meten un kernel de ellos…
Esto complica un poco el tema de la seguridad (No permite instalar CSF que utiliza: xt_connlimit ) en el servidor y su estabilidad: prefiero utilizar el orishinal que ya conozco su buen funcionamiento.

uname -r
3.2.13-grsec-xxxx-grs-ipv6-64

Este es el kernel de ellos.. para cambiarlo:

yum install kernel

Vamos a ver, se creo en /boot:

initramfs-2.6.32-431.20.3.el6.x86_64.img
vmlinuz-2.6.32-431.20.3.el6.x86_64

Ejecutá esto en el terminal:
cd /boot/grub
cp grub.conf grub.conf.bak | echo ‘Backup del archivo de conf hecho’

Ahora, ATENCION:

root@master [~]# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/md2 / ext3 errors=remount-ro 0 1
/dev/md3 /home ext3 defaults 1 2
/dev/sda4 swap swap defaults 0 0
/dev/sdb4 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
root@master [~]

/dev/md2 —> es nuestro punto de montaje de /
entonces, a tener en cuenta. Vamos a modificar el grub.conf ahora….

nano /boot/grub/grub.conf

Tiene que quedar así:

default=0
timeout=5
title linux centos6_64
root (hd0,0)
kernel /boot/vmlinuz-2.6.32-431.20.3.el6.x86_64 root=/dev/md2
initrd /boot/initramfs-2.6.32-431.20.3.el6.x86_64.img

Listo… dale: shutdown -r now
Cuando reinicie….

root@master [~]# uname -r
2.6.32-431.20.3.el6.x86_64
root@master [~]#

Joya, tenemos el kernel original de CentOS, ready to ride.

Best Regards… Amaro

 

 

DSO VS. CGI VS. SUPHP VS. FASTCGI, Diferencias entre los manejadores de PHP

Esto es interesante para saber como se debe definir los manejadores en el servidor… Según pa que se va a usar…

Una de las cosas más importantes que debe hacer un buen administrador de sistemas es adaptar el software al entorno al que está destinado, porque no tiene las mismas necesidades un servidor dedicado a sistemas de blogs que uno dedicado a streaming de vídeo o a juegos online, cada uno ha de ser configurado de la forma más óptima para su entorno.

En entornos de hosting compartido la configuración se adapta con el objetivo de satisfacer las necesidades de la mayoría de los usuarios, pero en un servidor dedicado, resulta fundamental una configuración óptima, por lo que vamos a ver las diferencias entre los handlers.

Un detalle importante es que podemos asignar un handler diferente a cada versión, de forma que podríamos tener PHP 5 con un handler de CGI y PHP 4 con un handler DSO. Vamos a ver las diferencias entre ellos.

DSO

DSO, también conocido como mod_php, cuyas siglas significan “Dynamic Shard Object”. Está considerada como la configuración más rápida, ejecutando PHP como un módulo de Apache, lo que conlleva que todos los scripts se ejecutan con el usuario “nobody”.

El problema del usuario “nobody” es que si un hacker ejecuta un exploit de PHP puede conseguir acceder a otras áreas del sistema donde el usuario “nobody” pueda tener acceso, por lo que resulta un sistema altamente vulnerable en hosting compartido o donde varios usuarios tienen acceso.

Todos los ficheros creados con un script de PHP no serán accesibles desde la web, lo que significa por ejemplo, que si subimos una imagen mediante WordPress, no podremos acceder a ella. Esto conlleva un serio problema de permisos con casi todos los sistemas CMS.

DSO es indudablemente más rápido que el resto de handlers y tiene un consumo de CPU muy bajo, pero en cuentas de hosting compartido se desaconseja por completo su uso.

CGI

CGI, cuyas siglas significan “Common Gateway Interface”, ejecuta PHP como un módulo de CGI. Por desgracia, CGI también ejecuta los procesos de PHP como el usuario “nobody”, aunque si tenemos suEXEC habilitado, podremos ver que usuario ha realizado la petición.

Este método no es más rápido ni más seguro que DSO, simplemente existe para entornos donde DSO no es posible.

suPHP

suPHP o “single user PHP”, ejecuta PHP como un módulo de CGI, pero con la principal diferencia de que los usuarios ejecutan los procesos con su nombre y no con “nobody”, por lo que la seguridad es notablemente más elevada. suPHP es la configuración por defecto en entornos como cPanel y es la más recomendada para entornos con varios usuarios, ya que conocemos en todo momento quien está ejecutando cada script.

suPHP establece correctamente los permisos de los ficheros al subirlos desde algún script como WordPress. Además, si una cuenta es comprometida, no puede afectar al resto ya que no tendría permisos para efectuar dicha escalada en el servidor.

La contrapartida es que su consumo de CPU es alto en comparación a otros métodos, y no se pueden usar sistemas de cache como Xcache o APC.

FastCGI

FastCGI, también conocido como “mod_fcgid” o FCGI, es una variación de alto rendimiento de CGI. Tiene las ventajas y los beneficios de suPHP (cada usuario ejecuta los scripts con su nombre y no con “nobody”), además de reducir notablemente el consumo de CPU y ofrecer velocidades similares a DSO. Por último, es compatible con sistemas de caché como APC o eAccelerator.

La pega de FastCGI es un elevado consumo de memoria (cada petición permanece abierta de fondo, lo que permite que los sistemas de cache puedan funcionar), pero no debería ser un problema en los servidores actuales con grandes cantidades de memoria. Si dispones de gran cantidad de ella, es la opción más recomendada.

Cambios entre sistemas

Si se modifica el handler a FastCGI o suPHP, es necesario actualizar los permisos y la propiedad de los ficheros. Para ello se han creados scripts que lo realizan de forma automatizada, como este.

Comparativa

DSO CGI SuPHP FastCGI
Bajo consumo de CPU
Bajo consumo de memoria
Ejecuta PHP con su usuario

Sólo con suEXEC
Seguridad óptima