Use certtool instead of openssl. It is less flexible but much more user friendly.1. Installation:Certtool is part of GnuTLS. On debian-based distributions you have to install the gnutls-bin package.2. Create a private key:# certtool -p –outfile server.key.pem3. Generate the self signed certificate:# certtool -s –load-privkey server.key.pem –outfile server.crt.pemYou will get a prompt to enter various informations required for a certificate. For a server certificate you only need to fill common name with the server name e.g. and validity period.For some applications, like openvpn, you may need your own certificate authority CA. These are the steps required:- create a CA key- create a self signed certificate for the CA. Say yes to the questions: “Does the certificate belong to an authority?” and “Will the certificate be used to sign other certificates?”- create a key- create a certificate using the CA key, CA certificate and the above key. For openvpn the common name is the user name.# certtool -p –outfile ca.key.pem# certtool -s –load-privkey ca.key.pem –outfile ca.crt.pem# certtool -p –outfile user.key.pem# certtool -c –load-privkey user.key.pem –load-ca-privkey ca.key.pem –load-ca-certificate ca.crt.pem –outfile user.crt.pem

viaSelf signed certificate, fast and easy | my repository.

Sous debian 64 bits

mkdir /home/tmpioncube
cd /home/tmpioncube

wget && tar -zxf ioncube_loaders_lin_x86-64.tar.gz && cd ioncube && cp /usr/lib64/php5/

echo « zend_extension=/usr/lib64/php5/ » > /etc/php5/conf.d/ioncube-loader.ini

et sa roule

The problemBy default apache2 is configured to support 150 concurrent connections. This forces all parallel requests beyond that limit to wait. Especially if, for example, active sync clients maintain a permanent connection for push events to arrive.The solutionThis is an example configuration to provide 800 concurrent connections. Please ensure that your apache is using the mpm_worker module. This allows us to serve lots of concurrent connections by using less RAM than with mpm_prefork as we are going to start much less processes.<IfModule mpm_worker_module> ServerLimit 25 StartServers 10 MinSpareThreads 75 MaxSpareThreads 250 ThreadLimit 64 ThreadsPerChild 32 MaxClients 800 MaxRequestsPerChild 10000</IfModule>Short explanation of the parameters:ServerLimit Declares the maximum number of running apache processes. If you change this value you have to restart the daemon.StartServers The number of processes to start initially when starting the apache daemon.MinSpareThreads/MaxSpareThreads This regulates how many threads may stay idle without being killed. Apache regulates this on its own very well with default values.ThreadsPerChild How many threads can be created per process. Can be changed during a reload.ThreadLimit ThreadsPerChild can be configured as high as this value during runtime. If you change this value you have to restart the daemon.MaxClients This declares how many concurrent connections we provide. Devided by ThreadsPerChild you get the suitable ServerLimit value. May be less than ServerLimit ThreadsPerChild to reserve some resources that can be engaged during runtime with increasing MaxClients and reloading the configuration.MaxRequestsPerChild Defines the number of Connections that a process can handle during its lifetime keep-alives are counted once. After that it will be killed. This can be used to prevent possible apache memory leaks. If set to 0 the lifetime is infinite.For further information on these parameters see and

viaTune apache2 for more concurrent connections – Open-Xchange.

How To Save Traffic With Apache2’s mod_deflate

Version 1.0

Author: Falko Timme <ft [at] falkotimme [dot] com>

Last edited 05/15/2006

In this tutorial I will describe how to install and configure mod_deflate on an Apache2 web server. mod_deflate allows Apache2 to compress files and deliver them to clients (e.g. browsers) that can handle compressed content which most modern browsers do. With mod_deflate, you can compress HTML, text or XML files to approx. 20 – 30% of their original sizes, thus saving you server traffic and making your modem users happier.

Compressing files causes a slightly higher load on the server, but in my experience this is compensated by the fact that the clients’ connection times to your server decrease a lot. For example, a modem user that needed seven seconds to download an uncompressed HTML file might now only need two seconds for the same, but compressed file.

By using mod_deflate you don’t have to be afraid that you exclude users with older browsers that cannot handle compressed content. The browser negotiates with the server before any file is transferred, and if the browser does not have the capability to handle compressed content, the server delivers the files uncompressed.

mod_deflate has replaced Apache 1.3’s mod_gzip in Apache2. If you want to serve compressed files with Apache 1.3, take a look at this tutorial: mod_gzip – serving compressed content by the Apache webserver

I want to say first that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

1 Enable mod_deflate

If you have Apache2 installed, mod_deflate should also already be installed on your system. Now we have to enable it. On Debian, we can do it like this:

a2enmod deflate

Then restart Apache2:

/etc/init.d/apache2 restart

On other distributions you might have to edit Apache2’s configuration manually to enable mod_deflate. You might have to add a line like this to the LoadModule section:

LoadModule deflate_module /usr/lib/apache2/modules/

Make sure you adjust the path to, and restart Apache2 afterwards.

2 Configure mod_deflate

The compression of files can be configured in one of two ways: either explicit exclusion of files by extension or explicit inclusion of files by MIME type. You can enable mod_deflate for your whole Apache2 server, or just for specific virtual sites. Depending on this, either open your Apache2’s global server configuration section now or just the vhost configuration section where you want to enable mod_deflate.

2.1 Explicit Inclusion Of Files By MIME Type

If you want to compress HTML, text, and XML files only, add this line to your configuration:

AddOutputFilterByType DEFLATE text/html text/plain text/xml

This is the configuration I’m using because I don’t want to compress images or PDF files or already compressed files such as zip files.

2.2 Explicit Exclusion Of Files By Extension

If you want to compress all file types and exclude just a few, you would add something like this to your configuration (instead of the line from section 2.1):

SetOutputFilter DEFLATE

SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ \

no-gzip dont-vary

SetEnvIfNoCase Request_URI \

\.(?:exe|t?gz|zip|bz2|sit|rar)$ \

no-gzip dont-vary

SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary

This would compress all files except images (gif, jpg, and png), already compressed files (like zip and tar.gz) and PDF files which makes sense because you do not gain much by compressing these file types.

2.3 Further Configuration Directives

Regardless whether you use the configuration from section 2.1 or 2.2, you should add these lines to your configuration:

BrowserMatch ^Mozilla/4 gzip-only-text/html

BrowserMatch ^Mozilla/4\.0[678] no-gzip

BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

These lines are for some older browsers that do not support compression of files other than HTML documents.

The configuration is now finished, and you must now restart Apache2. On Debian, you do it like this:

/etc/init.d/apache2 restart

To learn about further configuration directives, take a look at Apache Module mod_deflate.

3 Testing

To test our compression, we add a few directives to our mod_deflate configuration that log the compression ratio of delivered files. Open your mod_deflate configuration and add the following lines:

DeflateFilterNote Input input_info

DeflateFilterNote Output output_info

DeflateFilterNote Ratio ratio_info

LogFormat ‘ »%r » %{output_info}n/%{input_info}n (%{ratio_info}n%%)’ deflate

CustomLog /var/log/apache2/deflate_log deflate

Make sure you replace /var/log/apache2 with your Apache2’s log directory. This could be /var/log/httpd, /var/log/httpd2, etc.

Then restart Apache2. On Debian, do it like this:

/etc/init.d/apache2 restart

Now whenever a file is requested this will be logged in /var/log/apache2/deflate_log (or to whatever file you changed it to). A typical log line looks like this:

« GET /info.php HTTP/1.1 » 7621/45430 (16%)

You see that the file info.php was requested and delivered. Its original size was 45430 bytes, and it was compressed to 7621 bytes or 16% of its original size! This is a great result, and if your web site mostly consists out of HTML, text, and XML files, mod_deflate will save you a lot of traffic, and for users with a low-bandwidth connection your site will load much faster.

If you don’t need the logging after your tests anymore, you can undo the changes from section 3 and restart Apache2.

viaHow To Save Traffic With Apache2’s mod_deflate | HowtoForge – Linux Howtos and Tutorials.

1. Installation des modules Apache

Par défaut sous Debian le module deflate est enclenché, le module headers nous serviras dans le cadre d’environnement utilisant un proxy. On enclenche donc ces deux modules au niveau d’Apache, pour cela on lance une console SHH sur notre serveur et on lance les commandes suivantes :

a2enmod deflate

a2enmod headers

On relance notre Apache pour prendre en compte les nouveaux modules :

/etc/init.d/apache2 restart

2. Optimiser la configuration du module Deflate (gzip)

Nous allons optimiser la configuration de module Deflate qui de base sous Debian est assez minimaliste, pour cela on édite le fichier suivant :

nano /etc/apache2/mods-available/deflate.conf

On modifie la configuration de la manière suivante :

<IfModule mod_deflate.c>

DeflateCompressionLevel 3


<Location />

AddOutputFilterByType DEFLATE text/plain

AddOutputFilterByType DEFLATE text/xml

AddOutputFilterByType DEFLATE text/html

AddOutputFilterByType DEFLATE text/css

AddOutputFilterByType DEFLATE image/svg+xml

AddOutputFilterByType DEFLATE application/xhtml+xml

AddOutputFilterByType DEFLATE application/xml

AddOutputFilterByType DEFLATE application/rss+xml

AddOutputFilterByType DEFLATE application/atom_xml

AddOutputFilterByType DEFLATE application/x-javascript

AddOutputFilterByType DEFLATE application/x-httpd-php

AddOutputFilterByType DEFLATE application/x-httpd-fastphp

AddOutputFilterByType DEFLATE application/x-httpd-eruby

SetOutputFilter DEFLATE

SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary

SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary

SetEnvIfNoCase Request_URI \.avi$ no-gzip dont-vary

SetEnvIfNoCase Request_URI \.mov$ no-gzip dont-vary

SetEnvIfNoCase Request_URI \.mp3$ no-gzip dont-vary

SetEnvIfNoCase Request_URI \.mp4$ no-gzip dont-vary

SetEnvIfNoCase Request_URI \.rm$ no-gzip dont-vary

BrowserMatch ^Mozilla/4 gzip-only-text/html

BrowserMatch ^Mozilla/4\.0[678] no-gzip

BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

# Make sure proxies don’t deliver the wrong content

Header append Vary User-Agent env=!dont-vary


Explications :

DeflateCompressionLevel 3 détermine le niveau de compression, les valeurs vont de 1 à 9, de base le choix est à 1.

AddOutputFilterByType DEFLATE xxx/xxx indiq ue le mime type des éléments à compresser.

SetOutputFilter DEFLATE active la compression.

SetEnvIfNoCase Request_URI \.(?:xxx|xxx|xxx)$ no-gzip dont-vary ne compresse pas les fichiers car ils possèdent déjà une compression.

BrowserMatch ^Xxx/x gzip-only-text/html n’active la compression des pages que sous certaines conditions selon le type de navigateur.

Header append Vary User-Agent env=!dont-vary configuration spécifique pour les proxy.

La configuration du module est terminée, il est nécessaire de relancer Apache :

/etc/init.d/apache2 restart

Pour vérifier que la compression soit fonctionnelle, vous pouvez utiliser des outils comme YSlow pour prendre les valeurs avant et après l’optimisation de votre module, pour ma part j’ai constaté un gain significatif de plus de 60 % sur la vitesse de rendu de mes projets.

viaOptimiser le Gzip de son Apache pour Google | // Développement, Open Source et contexte Web2.0.

Canonical URL is part of a problem for most blogs. Most people who concern about different versions of a URL that display the same content are likely worry about duplicate content issue. As we know, that is not good from the search engine standpoint. The solution is to www redirect — redirecting your blog from non-www to www or vice versa.

URL canonicalization goes beyond www vs non-www, but interestingly this topic alone has been discussed very often. The problem is, a lot of people get it incorrectly.

Let me elaborate…

The other day, I was browsing the WordPress plugin directories and saw many similar plugins that for www redirection using 301 permanent redirect.

What’s Wrong with “Typical” Solutions?

Don’t get me wrong. The problem is not is its simplicity. In fact, I’ve used a simpler plugin before that removes two meta header tags from standard WordPress header. If something allows me to accomplish something without modifying WordPress code everything I need to upgrade, I’ll take it if it serves a purpose.

This is quite different for 301 www redirection plugins. Most of them are not necessary anyway. One version extends functionalities to include Apache-based redirections, 404 monitoring and more.

I won’t name names, but the rest is just redundant. No, scratch that, they hurt the performance of your WordPress, although that might be just a bit.

For instance, a typical WordPress execution takes the following path:

Web browser → Web server → WordPress (PHP) → MySQL

Assuming that the data is placed within MySQL database, you need to go through the entire process, which adds delay every step of the way. The returning path is again as far, although the flow is exactly the opposite.

If your web server setup is optimized in a way that you don’t have to invoke PHP when processing static and other files (you should), you also have added CPU and memory usage to your server unnecessarily.

In other words, the cost is not only delay time, but also performance-wise.

Do you need to execute the WordPress core just to redirect www to non-www and vice versa? The answer is NO.

Let the Web Server Do the Work

All web servers I know of support this feature. You can either 301 (permanent) or 302 (temporary) redirect right in the web browsers, either to another page within the same domain or externally to the corresponding domain.

The flow of a redirection becomes:

Web browser → Web server

If you prefer the www version and the visitor uses non-www, the server will immediately return 301 Moved Permanently code in the header, including the new URI in the Location: header.

By the way, it has to be 301 redirection if you want to solve the canonical URL problem and avoid duplicate content.

Before implementing the redirection code, make sure you have think about the version you’d like to keep. I personally prefer the non-www version simply because it is shorter.

For the curious mind, the following gibberish code uses regular expression (or regex) to match the domain. For instance, the tilde sign (^) means start of a string. You don’t need to understand it though, unless you want to dig into advanced configuration.

Note: The following solution works for every blog and web site, and it doesn’t require any type of blog platform or software to work.

WWW Redirect with Apache

Note that you should put this into .htaccess file in your root directory of your web site, even if your blog is in a sub-directory.

mod_rewrite module is required for this to work. If you have used clean URLs or fancy URLs feature for your blog (permalinks), you already have this feature.

Here is the code to redirect www to non-www:




RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]

RewriteRule ^(.*) http://%1/$1 [R=301,L]

An alternative which includes domain name is as follow:




RewriteEngine On

RewriteCond %{HTTP_HOST} ^example\.com$ [NC]

RewriteRule ^(.*)$$1 [R=301,L]

Put it close to the top or on the first line of .htaccess. You don’t have to modify a thing, edit your domain, or such. It works out of the box.

The following is the version to redirect non-www to www:




RewriteEngine On

RewriteCond %{HTTP_HOST} ^example\.com$ [NC]

RewriteRule ^(.*)$$1 [R=301,L]

WWW Redirect with nginx

WWW redirect requires rewrite module, but it is included as standard HTTP modules during compilation of nginx. All Linux distribution packages that I’ve tested with include this feature.

Add this code to the top of the page, separately from the server {} section for the preferred canonical name.

For instance, if you like to redirect to non-www, add the following code:






server {

listen 80;


rewrite ^/(.*)$1 permanent;


The word permanent is key. It turns the redirect into 301 redirection. After this block, you may configure the domain without www.

Here is the code for redirecting non-www to www:






server {

listen 80;


rewrite ^/(.*)$1 permanent;


WWW Redirect with lighttpd

This trick requires mod_redirect module. You should put it close to the top of the configuration file before other redirect or rewrite rules.

Redirecting www to non-www can be done with the following code:




$HTTP[« host »] =~ « ^www\.(.*)$ » {

url.redirect = ( « ^/(.*) » => « http://%1/$1 » )


This version redirects non-www to www inside the same domain. Substitute with your domain.




$HTTP[« host »] =~ « ^example\.com$ » {

url.redirect = ( « ^/(.*) » => «$1 » )


How to Edit Server Configuration

Usually web hosting providers allow you to edit configuration options per directory. Just drop a .htaccess on the root directory of your web documents. You can edit this directly by loging into your web hosting account or use the cPanel editor (or any web administration interface).

You don’t need to restart or reload your Apache server because it will read .htaccess in a directory when accessing it.

For lighttpd and nginx, you should have direct access to your configuration file. If not, ask your admin to edit it for you. Don’t forget to reload or restart to apply the new configuration.

viaHow to WWW Redirect the Right Way! (Apache, nginx and lighttpd).

Change the default Apache character set

By default, Red Hat Enterprise Linux 4 sets the default character set in Apache to UTF-8. Your specific web application may need for the character set to be set to a different value, and the change can be made fairly easily. Here’s an example where the character set is changed to ISO-8859-1:

First, adjust the AddDefaultCharset directive in /etc/httpd/conf/httpd.conf:

#AddDefaultCharset UTF-8

AddDefaultCharset ISO-8859-1

Then, reload Apache and check your headers:

# /etc/init.d/httpd reload

# curl -I localhost

HTTP/1.1 403 Forbidden

Date: Thu, 08 Nov 2007 22:18:14 GMT

Server: Apache/2.0.52 (Red Hat)

Accept-Ranges: bytes

Content-Length: 3985

Connection: close

Content-Type: text/html; charset=ISO-8859-1

viaChange the default Apache character set | Racker Hacker.

Configuration de processus apache au poil …

5 février 2011 par Gaëtan Laisser une réponse »

salut à tous …

Aujourd’hui on va parler configuration de processus apache … J’ai eu l’occasion en 3-4 jours de connaitre des problèmes sur plusieurs serveurs différents liée à une surconsommation de mémoire due à apache et à sa gestion des processus faisant littéralement planter mon blog (ça swap mal un RPS! donc 2 crash de la machine en 24 heures … avec les nouveaux prix des serveurs dédiés de chez … je risque probablement de migrer prochainement 😉 ).

Néanmoins ce genre d’incident n’empêche pas de revoir sa configuration, d’autant plus que comme pas mal d’administrateur débutant, l’installation d’un serveur web consiste en un simple apt-get install apache2 (en prenant le temps quand même d’installer modsecurity et les dernières règles depuis le site officiel) et pis c’est tout.

On se retrouve donc avec une configuration qui plafonne à 150 clients max en simultanés, sachant que mon blog n’a que 200 visites par jours, cette configuration est vraiment surestimée.

1.L’estimation du nombre de visiteurs/connexions

La première chose à savoir c’est bien entendu, le nombre de visite, mais aussi le nombre de fichiers auxquels les personnes auront accès lors de leurs première visite, car lors d’une visite, on télécharge la page html, mais aussi toutes ses ressources liées (css, js, images, …), pour un site moyen, il y a entre 20 et 50 connexions quasi simultanée (avec entre 1 et 10 secondes d’écart, suivant son type de connexion).

Pour mon site, j’utilise un CDN, hébergé par google (GAE), qui stock toutes mes données statiques (js,css,images), résuisant de façon assez significative le nombre de connexion sur mon serveur, comme le prouve le pannel de ressource de chrome :

Il n’y a donc qu’une seule requête effectuée sur mon serveur lors de la connexion d’un visiteur, le reste étant directement lié au domaine (hébergé sur appengine et donc ne consommant pas de ressource pour mon serveur web).

Sachant qu’en plus de n’avoir que 200 visiteurs par jours, je n’ai donc que 200 connexions http à gérer (gràce au CDN, ce qui n’est pas le cas de tout les serveurs …).

En partant de ces chiffres, je peux désormais passer à l’étape suivante :

2.Découverte de la cible

Apache ayant plusieurs type de fonctionnement, suivant qu’il soit en prefork ou en worker, nous devons donc savoir à quoi nous avons à faire pour ensuite le configurer :

sudo aptitude search apache2|grep « ^i »

qui renvoit le type de serveur installé, ici un mpm prefork (surligné en jaune) :

Je peux donc passer à la suite :

3.Détection de la menace

On peut passer à la configuration!! Comme je suis en mpm_prefork, j’ai juste à trouver les lignes correspondantes, qui par défaut contiennent ceci :

<IfModule mpm_prefork_module>

StartServers 5

MinSpareServers 5

MaxSpareServers 10

MaxClients 150

MaxRequestsPerChild 0


Ce qui signifie :

* StartServers : nombre de serveur démarré par défaut

* MinSpareServers : nombre de serveur de « rechange » EN PLUS du nombre de StartServers (donc par défaut 10 processus au démarrage!!!).

* MaxSpareServers : nombre maximal de serveur de « rechange », si ces serveurs ne sont pas utilisés, leurs processus sont tués!! BOUCHERIE!!! (façon Flander’s Company 😉 )

* MaxClients : Nombre de clients simultanées … en prefork, il s’agit du nombre de process max qui peuvent être crée. Son nombre multiplié à la taille moyenne d’un processus apache ne doit pas dépasser la taille de la ram dispo (sinon le kernel devra lutter pour libérer ce qu’il peux).

* MaxRequestsPerChild : nombre de requête qu’un processus va faire avant de mourir (0 = infinie), si vos applications web (phpmyadmin, wp, …) bouffe beaucoup de mémoire, cette mémoire sera consommée jusqu’à ce que le processus soit tué, donc plus vous avez d’application gourmande et plus ce chiffre est élevé, plus apache va consommé de mémoire (et si en plus ce chiffre est 0, la mémoire ne sera jamais libéré!!).

Il y a donc de l’optimisation à faire !!

4.Les calculs pour l’éradication de la menace

Mes petits calculs pour optimiser la bête et ne plus utiliser le swap lorsqu’apache déconne : Un RPS chez OVH (probablement un SC chez d’ici peut).

J’ai donc 512Mo de ram (493636 ko pour être exact 😉 ) à partager entre plusieurs services : MYSQL et Apache principalement.

En faisant quelque test, avec unMaxRequestsPerChild à 3, un process apache en fin de vie utilisera 50Mo (avec en application principal WordPress).

Avec ma machine et les contraintes de services j’ai donc : 120Mo (Mysql) + 100Mo (Système : IPS, …) + 100Mo (libre pour des bursts ou autre) = 320Mo, il me reste donc 200Mo de libre pour apache (200Mo/50Mo) = 4 processus.

Donc par défaut, ma machine pourra avoir 3/4 processus apache qui tourne en continue avec plusieurs processus apache en burst. Sachant qu’en plus le kernel est censé un peu gérer la mémoire lorsque ça devient serré, ça devrait pouvoir tenir mon nombre de visiteurs, sans avoir à exploser ma mémoire inutilement … au pire, les visiteurs patienteront 😉

Note : Mon calcul est très sévère, mon serveur peut faire tourner facilement une dizaine de processus apache sans trop de soucie, mais lors de pic de fréquentation élevé, il va commencer à swaper et devenir très lent (sur les RPS le disque dur est en réseau à 1Mo/s ..). Mais, avec cette configuration, je peux servir 3/4 clients par seconde, ce qui est amplement suffisant au vue de mes besoins.

5.Mise en place de la configuration

J’ai donc remplacé mon ancienne configuration par celle-ci, qui correspond à mes besoins actuelle.

<IfModule mpm_prefork_module>

StartServers 2 #démarrage de 2 processus

MinSpareServers 1 #1 processus de rechange par défaut donc 3 processus au démarrage

MaxSpareServers 3 #3 processus de rechange max, le reste étant tué lorsqu’il rentre en inactivité

MaxClients 12 #12 process max (12 processus*40Mo = 480Mo Max pour apache en cas de gros coup dur), 40Mo étant la taille moyenne d’un processus apache.

MaxRequestsPerChild 3 #une fois que le process à fait 3 réponse, il se tue et un autre est crée, histoire de renouveler la mémoire


Et on oublie pas de redémarrer 😉 . Après plusieurs heures de fonctionnement, mon RPS a toujours 100Mo de libre (à part lorsque le nombre de visiteur augmente de façon importante), ce qui était plus ou moins le but de cette configuration.


Si votre machine fait uniquement tourner un serveur apache (sur une machine stable), il n’y a pas besoin d’être aussi strict que je l’ai été (il n’y a pas de mal à swapper 😉 ), mais visiblement chez OVH, dès qu’une machine swap (et pas seulement sur les RPS apparement), elle ne répond plus très bien et si apache est mal configuré, il faudra généralement redémarrer apache pour le forcer à libérer toute la mémoire qu’il vampirise, ce qui peut poser problème pour des serveurs de jeux ou autre …

Pour mes calculs je me suis basé sur la valeur moyenne de la mémoire consommée par MES processus apaches (cette taille peut dépendre des modules utilisés et de leurs configurations : mod_php, mod_security, …). Cette taille peut donc changer, suivant votre configuration.

viaConfiguration de processus apache au poil … » Le Blog du grand loup Zeur.

UTF-8 PHP MYSQL (histoire d’encodage)

* Accueil

* UTF-8 PHP MySql

* Barre de progression d’upload en PHP

Encodage et programmation

Les caractères qui s’affichent sur les écrans d’ordinateur, comme toute donnée informatique, ne sont qu’une sucession de 0 et de 1 du point de vue de la machine. C’est le nombre et l’ordonnance de ces bits qui définissent la norme d’un encodage. Plus le nombre de bit sera élevé, plus l’encodage supportera de caractères.

Les problèmes que l’on peut rencontrer lors du passage à l’UTF-8 viennent de cette différence de norme avec l’encodage européen ISO. Entre ces deux normes les problèmes vont se situer au niveau des caractères « spéciaux » comme les caractères accentués.

A côté des problèmes que cela peut impliquer, l’UTF-8 permet de gérer un plus grand nombre de caractères, donc de gérer des langues aux glyphes exotiques, ce que ne permet pas l’iso avec ses 256 possibilités.

Mais si l’UTF-8 permet de telles choses c’est qu’il est codé sur plus de bits que l’ISO, et si cela influe sur l’affichage, cela influe forcément sur le traitement des chaînes au niveau de la programmation et du stockage en base de données.

Imaginons que l’on veuille connaître la longueur de cette chaîne : ‘éé’. Basiquement un langage comptera le nombre de bits que contient cette chaîne.

Une fonction dédié à cette tâche trouvera 16 bits, soit deux octets, soit deux caractères en ce qui concerne l’ISO. En revanche cette même fonction trouvera 32 bits sur un encodage UTF-8, donc renverra une valeur de 4 caractères si elle croit avoir affaire à de l’ISO…tel est le problème.

Ce tutoriel couvrira donc la mise en place d’un environnement conforme, son utilisation ainsi qu’une reconnaissance rapide des problèmes d’affichage entre l’UTF-8 et l’ISO.

Plus d’infos sur l’encodage -> les bases

Plus d’infos sur l’encodage -> UTF-8

Préparation de l’environnement

Pour être sûr que tout fonctionne correctement il est impératif que l’ensemble de l’environnement soit aux normes afin de ne pas tout mélanger, oublier d’enregistrer ses sources au bon format et toutes les configurations du serveur deviennent aussi efficaces que le néant.

Editeurs et BOM

Les fichiers doivent être encodés en utf-8. A priori simple, cela dépendra du bon vouloir de l’éditeur de texte.

Certains éditeurs spécifient en début de fichier un marqueur d’ordre des octets (bom en anglais), qui plus est inutile pour l’utf-8.

Le fait d’insérer ce caractère au début d’un fichier php (donc avant la balise d’ouverture <?php) pourra provoquer une erreur du type « headers already sent ».

Il faut donc veiller à ne pas laisser l’éditeur insérer un tel caractère (notepad ou encore scite si l’on ne spécifie pas « UTF-8 Cookie »).

Plus d’infos sur le BOM


Pour le code HTML il suffit de spécifier l’encodage à l’aide de cette balise :

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


Historiquement apache travail en ISO-8859-1, c’est donc dans cette norme qu’il risque d’envoyer ses entêtes.

L’instruction à modifier dans le httpd.conf ou dans un .htaccess :

AddDefaultCharset UTF-8

Sinon via php :

header(‘Content-type: text/html; charset=UTF-8’);

Pour connaître l’entête utilisé par un serveur apache il suffit de regarder l’encodage lors de la réception d’une page à l’aide de son navigateur (à peu de choses près en fonction de la famille : affichage -> encodage).

Sinon ici.

! L’entête http fait autorité face à la balise meta !


Mysql supporte pleinement l’UTF-8 depuis la version 4.1. Les instructions données ici fonctionneront à partir cette architecture et un développement sérieux en UTF-8 se fera à l’aide d’un milésimme égale ou postèrieur à celle-ci.

Donc oui il est possible de stocker des données unicode dans une base 3.23, mais il faut s’attendre à ce qu’une chaîne de 25 caractères cyrilliques soit tronqué dans un champs varchar de 40 (sans parler des problèmes liés aux fonctions SQL).

Dans le cas présent l’ensemble des instructions se fera à l’aide de commandes sql et non pas à partir de directives de compilation ou d’instructions du my.cnf.

Exemple de la création d’une base :



COLLATE utf8_bin;

CHARACTER SET -> spécifie l’encodage

COLLATE -> spécifie la collation (« l’attitude » de mysql envers les données)

utf8 -> orthographe propre à mysql (absence du « – » entre utf et 8)

utf8_bin -> cette collation rend la comparaison de chaîne sensible à la casse (au contraire de utf8_general_ci)

Chaque table d’une base peut avoir son propre jeu de caractère/collation, de même que chaque colonne.

Exemple de création de table:



gen_ci VARCHAR(30) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL


Si MySQL n’est pas configuré par défaut pour l’UTF-8 il faut lui préciser la manière dont elle doit traiter les caractères contenus dans une requête SQL à l’aide de cette instruction :

SET NAMES ‘utf8’;


PHP travail nativement en ISO, ce n’est qu’à partir de la v6 qu’il basculera entièrement en UTF-8.

Deux modules permettent de gérer différents types d’encodages, mbstring et iconv.

mbstring s’occupe de la manipulation de chaînes tandis qu’iconv permet de convertir différents types d’encodages. Les conversions entre ISO et UTF-8 peuvent se réaliser à l’aide des fonctions utf8_encode() et utf8_decode(). Une conversion à partir ou à destinations d’une autre norme nécessitera les fonctions du module iconv.

D’autres fonctions supportent différents charsets sous réserve de l’indiquer, tel que html_entities() (dont on pourra se passer au profit de htmlspecialschar() une fois les problématiques d’encodage apréhendées…html_entities ne s’occupe que de des caractères latins).


Une fois le module activé et correctement configuré à l’aide du php.ini mbstring permettra la manipulation de chaînes en UTF-8. Plusieurs fonctions qui reprennent les fonctions usuelles de PHP lui sont associés.

Il faudra utiliser par exemple mb_strlen() au lieu de strlen() (une autre méthode plus pénalisante au niveau performance existe pour continuer à utiliser les fonctions standarts tout en se servant de mbstring -> voir lien ci dessous).

Une configuration fonctionnel pour l’UTF-8 (dans l’ordre) :

; Langage par défaut


; Jeu de caractère interne

mbstring.internal_encoding= UTF-8

; Jeu de caractères par défaut pour les données d’entrée HTTP


; Jeu de caractères par défaut pour les données de sortie HTTP


; Ordre de détection des jeux de caractères

mbstring.detect_order= auto

A défaut d’avoir accès au php.ini les directives de configuration peuvent être spécifiées dans le http.conf-.htaccess (ex: php_value mbstring.language « UTF-8 ») ou à l’aide de la fonction ini_set() (sauf pour mbstring.language qui est une configuration de type PHP_INI_PERDIR => à stipuler dans un php.ini, httpd.conf ou un .htaccess) ou bien encore des fonctions propres à mbstring (mb_internal_encoding(), mb_http_output(), …)

Ne pas passer par le php.ini permet également de travailler avec des configurations différentes sur son poste de travail, donc d’éviter des incompatibilités.

A tire d’exemple la directive « mbstring.http_input=UTF-8 » semblera ne pas faire passer les données $_GET et $_POST sur un site en ISO (réception d’une chaîne vide).

Plus d’infos sur mbstring


A part l’activation du module il n’y a pas de configuration particulière pour ce qui est de la conversion entre différents encodages (pour ce qui est du traitement de chaîne mbstring est plus complet).

Plus d’infos sur iconv


Une fois mis en place les bonnes configurations et les scripts sql exécutés (création de la base et d’une table) , vous pouvez commencer par tester ce script :


mysql_connect(« serveur », »login », »pass »);

mysql_select_db(« toto_utf »);

//necessaire seulement après la connection

mysql_query(« SET NAMES ‘utf8′ »);

mysql_query(« insert into tutu values(‘tдtд’,’tдtд’) »);

mysql_query(« insert into tutu values(‘Tдtд’,’Tдtд’) »);

//difference des collations en ce qui concerne la casse

$res=mysql_query(« select * from tutu where bin=’tдtд' »);

echo ‘nombre de « tдtд » trouvé avec utf8_bin : ‘.mysql_num_rows($res).'<br />’;

$res=mysql_query(« select * from tutu where gen_ci=’tдtд' »);

echo ‘nombre de « tдtд » trouvé avec utf8_general_ci : ‘.mysql_num_rows($res).'<br />’;

//utilisation d’une fonction mbstring


echo ‘longueur de « tдtд » sans mbstring : ‘.strlen($chaine[0]).'<br />’;

echo ‘longueur de « tдtд » avec mbstring : ‘.mb_strlen($chaine[0]).'<br />’;


Reconnaissance rapide des problèmes d’affichage UTF-8 ISO

Si la page affiche des caractères de ce type : « Ã© », « Ã® », « Ã », …

=> Les données ont été enregistrées au format UTF-8, et le navigateur les affiche en pensant avoir affaire à de l’ISO.

Si la page affiche des caractères de ce type : « � »

=> Les données ont été enregistrées au format ISO, et le navigateur les affiche en pensant avoir affaire à de l’UTF-8.

Si les données sont codées en dur dans la page, voir l’encodage de l’éditeur de texte, l’header apache et la balise meta « charset ».

Si les données proviennent de la base, vérifier le format de stockage et les méthodes de lecture et d’insertion (SET NAMES et charset).

Si les données proviennent de l’extérieur (web services, rss, …), penser à convertir les chaînes de caractère (utf8_encode-decode et fonctions du module iconv).

viaTutoriel sur UTF-8 avec PHP et MySQL.