Lorsqu’on développe ou simplement que l’on conçoit un système ou une application, il y a parfois des choses pour lesquelles il convient de faire des choix de manière éclairée. Ce qui est bien, c’est que des gens intelligents prennent du temps à normaliser tout un tas de concepts, et qu’il devient assez simple de bénéficier de cette intelligence.
Voici les quelques normes qui m’ont semblé importantes.

Organismes de normalisation

Pour commencer, il est toujours intéressant d’avoir une idée des principaux organismes de normalisation qui existent :

• Organisation Internationale de Normalisation (ISO)
• World Wide Web Consortium (W3C)
• Internet Engineering Task Force (IETF)
• European association for standardizing information and communication systems (ECMA)
• American National Standards Institute (ANSI)
• Association Française de Normalisation (AFNOR)

Sans oublier l’importance du système international d’unités (dérivé du système métrique) !

Encodage des caractères

De nos jours, il n’y a aucune bonne raison pour ne pas utiliser l’Unicode pour toutes les chaînes de caractères, qu’il s’agisse du stockage en base de données, de la communication client/serveur, ou des pages Web générées. L’encodage UTF-8 présente l’avantage de ne requérir qu’un seul octet pour les caractères faisant partie de la table ASCII standard (au contraire des encodage UTF-16 et UTF-32 qui prennent respectivement au moins 2 et 4 octets), ce qui est un bon compromis quand on échange du texte dans un alphabet dérivé des caractères latins (oui, parce que pour les alphabets asiatiques, notamment, l’UTF-8 peut consommer plus d’espace que l’UTF-16, en prenant 3 octets par caractères au lieu de 2).

Il y a un article sur le sujet, écrit par Joel Spolsky, que tout le monde doit avoir lu :

• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• Traduction en français

Dates

Pour les dates, le mieux est de respecter la norme ISO 8601, qui prévoit de les écrire de la forme « 2006-11-14T20:15:17+01:00 ».

En PHP, il suffit d’utiliser le paramètre « c » dans la fonction date(). Par exemple :

$date = date('c', 0);

Donnera :

1970-01-01T01:00:00+01:00

Concernant les semaines de l’année, la norme ISO 8601 présente plusieurs moyen de calculer la première semaine et la dernière semaine de l’année (cf. article sur Wikipédia). Un moyen simple de le calculer est que la première semaine contient forcément le 4 janvier, et la dernière semaine contient toujours le 28 décembre.

Il est aussi à remarquer que la norme ISO 8601 précise de manière très claire que le lundi est le premier jour de la semaine. N’en déplaise à ceux qui mettent le dimanche en premier (notamment en Amérique du nord)…

Pays

Les pays peuvent être représenté en utilisant la norme ISO 3166-1 alpha-2, qui code les pays sur deux lettres majuscules.

Langues

Les langues sont représentées en utilisant la norme ISO 639-1, qui code virtuellement toutes les langues connues en utilisant 2 lettres minuscules.
Pour voir la liste des codes : Liste des codes ISO 639-1

Monnaies

Les monnaies sont représentées en utilisant la norme ISO 4217, qui code les monnaies sur 3 lettres majuscules.

Papier

Les formats standards à la norme ISO 216 (A4, A3, RA3, SRA3, …) sont préférés. Il existe toutefois des formats américains non standards qu’il faut souvent prendre en compte : letter, ledger, legal, semi-letter, executive, tabloid, …

Adresse email

Le format des adresses email est défini par les RFC 5321 et 5322. Tout ça est bien expliqué sur Wikipedia. Attention, il y a tout un tas de caractères spéciaux qui sont autorisés dans les adresses email, et qu’on n’a pas l’habitude de voir. Il y a même une syntaxe pour placer des commentaires dans les adresses (c’est quand même bizarre, je ne suis pas certain de vouloir valider une adresse contenant un commentaire).

Espace de stockage

Pour stocker certaines informations, il faut prévoir suffisamment de place pour y enregistrer des textes qui peuvent parfois être assez longs (cf. l’article Wikipédia sur les noms de lieux les plus longs).

Habituellement, j’utilise les tailles suivantes :

• Nom et prénom d’une personne : 80 caractères
• Adresse : 100 caractères
• Code postal : 10 caractères
• Nom de ville : 50 caractères
• Nom de pays : 50 caractères
• Adresse IP : 39 caractères (pour stocker aussi bien des IPv4 que des IPv6)
• Code ISBN : 17 caractères
• Adresse email : 255 caractères

Identifiants

La question de la longueur des identifiants de clé primaire en base de données est quelque chose de délicat. Il est nécessaire de pouvoir contenir des identifiants suffisamment grands pour ne pas risquer de problème, mais en même temps il vaut mieux éviter de consommer de l’espace inutilement car cela peut être exponentiel avec l’augmentation du nombre de lignes en base.

Un bon moyen pour répondre à cette question est de réfléchir au rythme auquel les données vont s’ajouter. Si vous avez en moyenne une nouvelle ligne par minute, vous pouvez tenir plus de 8000 ans avant de remplir un entier 32 bits non signé (un INT UNSIGNED dans MySQL, par exemple). Si par contre vous avez 20 nouvelles lignes chaque seconde, ce même entier mettra moins de 7 ans pour se remplir… et il vaut peut-être mieux passer tout de suite sur 64 bits (dans ce cas, même avec un million d’enregistrements par seconde vous pouvez tenir plus de 500 mille ans).

Petite info (glanée sur StackOverflow) concernant les access_token de l’API Facebook : leur taille augmente au fil du temps, et il ne faut surtout pas les stocker dans une chaîne limitée à 255 caractères (typiquement un VARCHAR ou un TINYTEXT), alors que c’était leur recommandation à une époque lointaine. Il vaut mieux utiliser un SMALLTEXT.

Edit : Ajout d’infos sur les adresses email. Cf. commentaires (merci Mathias).
Edit 2 : Ajout du paragraphe sur les identifiants.