J'ai le rêve qu'un jour, il existera un outil pour faire des requêtes de données avec formatage qui ira chercher l'information sur internet et affichera les résultats. Un navigateur de données au lieu d'un navigateur de documents.

Quel type d'informations? Les listes officielles (nom de ville, régions, pays, nom des mois, nom des semaines, unités internationales, etc...), les listes d'entreprises, les bottins téléphoniques, des listes de traductions, etc.

Exemple d'application:

1. Choisir la source des données. exemple: nom des mois sur wikipédia ou sur bdlq (http://66.46.185.79/bdl/gabarit_bdl.asp?id=3619)
2. Sélection des champs voulus (selon la source). exemple: position1, "Nom des mois"
3. Choisir un format (pré déterminé par le type de données) ou le créer soi-même : exemple: PHP = array( {!{ %d{position 1}=>%s{Nom des mois} }!} ).
4. Obtenir les données et les utilisés.
5. On pourra peut-être croisé des requêtes ensuite et ajouter des restrictions.

La création des listes / source de données se fera à l'aide de formulaires librement accessible sur le web (style wiki). Des convertisseurs HTML vers base de données pourraient être créer pour utiliser le contenu HTML existant.

Voici un début: web data

Dans la série de mes convertisseurs avec des textareas : un convertisseur des vcards de linkedin vers un format csv pour l'importation dans Iceweasel ou vers un pseudo format XML.

Utilité? Avoir mes contacts de linkedin dans Iceweasel et me faire un pseudo-parser de vcard pour le plaisir de coder.

Vincent se demandait hier pourquoi il avait écrit 138 caractères dans son espace twitter et que l'application twitter lui avait dit qu'il avait plus de 140 caractères après son "post". L'informatique, c'est une question de chiffres, de 0 et de 1, de conventions, de manque de visions des besoins et de paresses.

Explication: un caractère est représenté par un graphique qui est associé à un nombre. Il existe différentes tables qui associe les lettres à différent nombre. Par exemple, la lettre "A" majuscule est associé au nombre décimal "65" selon la table ASCII. Lors de la programmation des premières tables de caractères, l'anglais était utilisé et il existait 128 caractères. Les programmeurs, des anglophones, ont spécifié qu'un caractère, un "char / character" était représenté par 8 bits, un octet. Aux 128 caractères de base, on pouvait ajouter 128 caractères supplémentaires dans une table étendue. On a eu une multitude de tables étendues qui spécifiait des caractères supplémentaires sur 8 bits / 1 octets. On pouvait spécifier des lignes, des symboles, des accents, des pictogrammes.

Lors de la conception des bases de données relationnelles, les programmeurs, encore une fois, ont décidé d'utiliser les "char"s comme unité de mesure pour les champs de type "chaîne de caractères". Une chaîne de caractères est un bout de phrase, de texte. Ils ont encore spécifié qu'un "char" équivalait à 1 octet, 8 bits. Lorsque les tables avaient seulement 256 symboles, un "char" était encodé en 1 octet/8 bits.

Les développeurs de langages de programmation ont développé des fonctions pour calculer la longueur des chaînes de caractères. Or, ils ont développés des fonctions qui calculent le nombre d'octets des chaînes de caractères et non le nombre de caractères.

Un jour, des développeurs ont voulu réunir et unifier toutes les tables de caractères. Au lieu d'avoir ASCII, ISO-8859-1, windows-1252, ISO-8859-15, etc, ils voulaient avoir une seule table. Une table qui associe 1 caractère à 1 nombre. Or, ils y avaient tellement de caractères différents (penser seulement au pictogrammes des Chinois) qu'un octet (256 possibilités) ne pouvait être suffisant. Ils ont développés, en autre, une table qui se nomme UTF-8 (Universal character set Transformation Format 8 bits). Cette table a une particularité, les caractères sont représentés par des nombres à taille variable. Les 128 premiers caractères sont encodé sur 8 bits, ensuite 2048 sur 16 bits, 65536 sur 24 bits et 2091752 sur 32 bits. Or c'est là que les fonctions des programmeurs ne retourne plus des résultats cohérents. Les fonctions qui étaient sensées retourner le nombre de caractères, retourne en fait le nombre d'octets utilisés par l'encodage. Anciennement, tout était 1 caractère = 1 octet. Avec UTF-8, c'est variable, 1 caractère = 1, 2, 3 ou 4 octets.

En PHP5 par exemple, un langage qui utilise beaucoup les noms de fonction du langage C, la fonction strlen() retourne le nombre d'octets encodés et non le nombre de caractères. PHP5 possède une fonction mb_strlen() qui compte le nombre de caractères. Si un "é" est encodé en 2 octets en PHP5, alors strlen() retourne 2 et mb_strlen() retourne 1. Le PHP5 a été codé en utilisant l'encodage US-ASCII par défaut. Les fonctions multi-bytes (mb_) ont été ajouté par la suite.

Pour le Javascript, il a été développé avec l'Unicode en tête. Par défaut, les chaînes de caractères sont en Unicode et la propriété "length" retourne le nombre de caractères, pas le nombre d'octets encodé.

Bien que les nouvelles bases de données supportent les encodages à taille variable, généralement les types de base utilisent toujours le concept de 1 char = 1 octet. Donc, si un administrateur de base de données spécifie une taille de champ à 140 chars, le champ est limité à 140 octets et non pas 140 caractères.

Une des forces de l'informatique est de développer des technologies distinctes qui répondent à des besoins spécifiques. Une des faiblesses de l'informatique est l'interopérabilité des technologies distinctes (faire parler plusieurs technologies ensemble). Un site Web qui effectue des transactions utilisent plusieurs technologies (par exemple): HTTP, URI, HTML, Javascript, PHP, système de fichiers du serveur, SQL, base de données.

Dans le cas de Twitter, le compteur leur page est en Javascript (Unicode) et compte le nombre de caractères et non pas le nombre d'octets utilisés. Lors de la vérification sur leur serveur, ils utilisent une fonction qui compte le nombre d'octets. Puisqu'on peut quand même afficher des chaînes de 280 octets, je dirais que leur base de données supporte plus de 140 octets et qu'ils n'utilisent pas la bonne fonction de calcul sur leur serveur.