Posts made by Valery Fremaux

Oui Fred, pour les deux questions : tu as en apparence deux 'utilisations' du groupe 65 dan sdeux cours différents. Ce n'est pas forcément une erreur depuis le changement de modèle des groupes. J'irai jetter un oeil.

As tu une indication du numéro de ligne qui produit cette erreur ? et du fichier php dans lequel tu l'as ?

probablement qu'en remplaçant get_record_sql() par la fonction get_records_sql(), tu élimine la mention de l'erreur (puisque get_records_sql autorise plus d'un résultat). Mais c'est peut-être cacher un autre problème. Essaye de me trouver plus de détails sur la localisation de l'erreur et je checke ce morceau de code.

Salut à Céline et les enfants.

L'informatique historique encode les caractères sur 7 bits, donc des valeurs de 0 à 127. Celà donne 128 caractères possibles, très peu pour tout imprimer. A l'époque on s'en fiche un peu : le jeu de caractère suffit à piloter une "imprimante télécommandée" (les anciens modèles IBM à boule ou à marguerite) : le télétype.

Dans la fin des années 60 apparaît le terminal cathodique, imprimant une matrice de points sur laquelle on peut évidemment imprimer toute une combinaison de glyphes. l'encodage passe de 128 à 256 valeurs (8 bits), mais une grande bataille a lieu pour savoir quels symboles prennent les 128 dernières positions. Les américains (ANSI : American National Standard Institute) imposent l'ASCII, que tout le monde ne suit pas (le système d'exploitation DOS choisit de mettre des caractères "pseudo-graphique" pour faire les bordures de fenêtres en mode texte).

L'ASCII étendu est négocié avec les européens pour englober les caractères accentués, il devient alors le latin-1. Mais d'autres variantes apparaissent pour gérer certaines particularités (tcheque, polonais, etc.). Toujours est-il que 256 codes possibles, c'est trop juste. Il n'y a rien à faire, surtout que l'informatique s'internationalise. Il faut prendre en compte le cyrillique, le grec, l'hébreu, l'arabe etc. On commence d'abord par produire des polices spéciales, qui en face des codes de caractères changent l'apparence de la lettre vue. Mais alors, suivant la police, un "a" ASCII peut valoir un "alpha" grec (assez logique sont-ils quand même), ou un autre caractère russe.

Avec cette logique, impossible d'ajouter des nouveaux caractères au delà de 256 caractères par document, et donc impossible de coder des documents multilingues.

Le Web pousse alors à trouver un format qui augmente réellement le nombre de caractères disponibles dans le même encodage : l'Unicode ("code unique") ou UTF16 qui utilise 16 bits, donc 65536 caractères. On peut penser à intégrer le chinois et les diverses représentations japonaises.

Le problème, c'est que pour 98% des textes diffusés dans l'informatique, il faut doubler le volume de code (un octet nul + le code ASCII) avec des données "inutiles". L'idée est donc de dire : si on écrit en ASCII, on écrit en 8 bits, si on veut sortir et utiliser des caractères hors ASCII, on écrit une petite séquence spéciale qui permet d'écrire un caractère "multi-octet". C'est finalement l'UTF8, puissant mais efficace.

Pourquoi le texte semble pareil dans l'éditeur de texte quand on le convertit ?

 Parce que l'éditeur est "conscient" du codage réel des caractères et sait afficher le glyphe correct. Si le fichier est en UTF8, l'éditeur va rechercher le glyphe adéquat selon la séquence multi-octet (ou la lettre simple ASCII). Même notepad sait faire cette détection (mais pas wordpad, qui ne connaît que l'ANSI !!)

Average of ratings: Utile (3)

Après avoir testé tes fichiers, il s'avèrent qu'ils passent parfaitement... une fois le fichier converti en utf8 avec un petit outil adapté

voir discussion http://moodle.org/mod/forum/discuss.php?d=75210

qui fait le point sur ces outis et les éditeurs de texte qui le font.

ci-joint, ton fichier réencodé correctement en UTF8 que j'ai importé dans ma 1.8.2, avec accents et tout. Je regarde l'export de suite...

Il n'est pas sûr que même si l'encodage interne d'Excel est en unicode, l'explortation produise de l'unicode. Il faudriat vérifier que le fichier .txt d'import est correctement encodé en UTF-8.

D'autre part je peux vérifier que l'import des fichiers ouvre bien les fichiers avec la bonne fonction de conversion "magique". (bien que ce soient des fonctions magiques, le traitement de la compatibilité, cà reste quand même un merdier au niveau développement !!).

Peux-tu me donner simplement la fin de l'URL de réception de l'import (pour pas trop fouiller dans le code), celle qui est affichée lorsque l'import est lancé ? 

 

J'ai eu un besoin d'un bloc chronomètre pour des TP sur les algorithmes de recherche de données. Le voilà finalisé pour tester. Marche bien sur 1.8.2, mais devrait fonctionner correctement dès la 1.7. Calcule au "dixième de seconde" et comptabilise aussi les secondes totales.

Se déploie très simplement en le dézippant dans"blocks" et en allant l'enregistrer dans la page d'administration. Fonctionne en local sur le navigateur, pas de configuration. Permet le démarrage l'arrêt, et la remise à zéro.

Je peux ajouter un "lap time" au besoin et permettre de paramétrer la police d'affichage...

Bonsoir à tous. 

Average of ratings: -