Normes utiles

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 :

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 :

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.

8 commentaires pour “Normes utiles

  1. On pourrait aussi ajouter la taille des adresses email : 320 caractères.

    On en a besoin assez régulièrement. 😉

  2. Bien vu 😉
    Bon, sur la même page Wikipedia, ils disent qu’à cause de limitations sur le forward path et le reverse path, la totalité de la longueur d’une adresse email est limitée à 254 caractères. Ce qui est bien pratique, parce que ça rentre dans un TINYTEXT (255 caractères maximum).

  3. Concernant les unités de mesure binaires.

    D’après Wikipédia et la norme qui est citée:
    1Mbits = 1000 bits
    1Mibits = 1024 bits
    https://en.wikipedia.org/wiki/Bit

    Il est d’usage de considérer que 1Mbits = 1024 bits.

    J’aurais tendance à penser que 1Mbits=1000bits car c’est en accord avec les autres domaines où les Mega, Tera,.. sont utilisés. Dans beaucoup de livres ou cours informatique, c’est 1Mbits=1024 bits qui est employé. Le mieux est de préciser à chaque document quelle est la convention utilisée.
    C’est amusant car cela concerne l’unité de mesure de base de l’informatique mais j’ai l’impression que ce point est à éclaircir pour beaucoup de professionnels.

  4. Et bien sur, je voulais parler de kilo (kbit) et non de Mega (Mbit)
    1 kbit = 1 000 bits
    1 Mbit = 1 000 000 bits
    Désolé pour cette erreur.

  5. @Remi : Effectivement, à un moment il semblait être à la mode de parler de MiO (mébioctets) et de GiO (gébioctets) au lieu de MO (mégaoctets) et de GO (gigaoctets). Mais l’usage semble avoir fait long feu. Pour ma part, je préfère continuer à parler de kilooctets, mégaoctets, etc. tout en restant sur des puissances de 2 et non des puissances de 10 ; simplement parce que lorsqu’on parle de la taille d’une donnée, il faut bien la stocker sur un support informatique, où les mesures se font sur des puissances de 2.

    Alors pourquoi ne pas utiliser les termes kibioctet, mébioctet, etc. ? Bah parce que c’est plus simple, c’est plus rapide, ça fait moins pédant. Et surtout, quand on dit «1 KO» la quasi-totalité des informaticiens comprennent qu’on parle de 1024 octets. Si on se met à parler de «1 KiO», c’est à ce moment que les gens vont commencer à se poser des questions un peu inutiles et s’embrouiller pour rien. Restons simples.

    Après tout, ne dit-on pas que les vrais informaticiens pensent qu’un kilomètre fait 1024 mètres ? (OK, c’est une blague éculée, mais je ne pouvais pas me retenir)

    Sinon, tu parles des bits. La logique est évidemment valable, mais on a quand même l’habitude de parler d’octets (avec la convention de 8 bits par octet). https://fr.wikipedia.org/wiki/Octet

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.