Lo que siempre recomiendo a mis clientes es que no utilicen caracteres especiales en los nombres de archivos, ya sean las imágenes, archivos pdf, etc.
Y dirán, ¿qué son los caracteres especiales?, pues esos que se salen de las letras «normales» (ni acentos, ni ç o ñ) y los números.
Lo ideal es que WordPress «limpiase» esos nombres de archivos y los subiese con nombres estándar, en minúsculas, sin espacios y solo letras y números sin nada raro.
El problema
Pero muchas veces heredamos instalaciones antiguas, con muchas entradas, codificaciones incorrectas en la Base de Datos, etc. Pero lo que me he encontrado en esta ocasión al pasar una web con muchas imágenes de este tipo (como casmiseta-niño-rojo-chillón.jpg) a un servidor Vultr HF a medida, es que dichos archivos se mostraban con «caracteres raros».
Pero lo peor no era eso, sino que no coincidían con los guardados en la base de datos y, por lo tanto, eran errores 404.
Aunque subiese el archivo vía SFTP forzando a UTF-8 desde Filezilla, se mostraba con los caracteres extraños en el sistema de archivos.
También probé a comprimirlos en zip, subir y descomprimir y el mismo problema. Bien, aquí ya estaba localizado el problema y era el soporte de UTF-8 por parte del sistema operativo.
Aviso: esto es algo que no os va a pasar en ningún hosting, ya que por defecto están configurados correctamente para trabajar con UTF-8.
La solución
La solución obvia era habilitar el soporte para UTF-8. Primero comprobamos los locale del sistema:
# localeY efectivamente, vemos que está configurado en LANG=en_US al igual que las demás variables, en lugar de tener LANG=en_US.UTF-8 o LANG=es_ES.UTF-8 si lo tenemos configurado en español. Así que nos queda reconfigurarlo, para lo que ejecutamos:
# locale-gen "en_US.UTF-8"O si lo estamos configurando para español:
# locale-gen "es_ES.UTF-8"Y a continuación:
# dpkg-reconfigure localesSeguimos los pasos seleccionando nuestro locale y el mismo por defecto:
Y ya tenemos el sistema bien configurado, que ya debería estar previamente y por defecto como UTF-8, pero en este caso es debido a un pequeño bug en la instalación.
Podemos volver a cargar bash ejecutando source ~/.bashrc (o el sistema que tengamos como zsh con su correspondiente comando source ~/.zshrc) y comprobar con # locale que ahora sí que está correctamente configurado:
