Après la clôture des listings pour Amstrad, c'est au tour de l'Oric.
Plus que 3 programmes à taper... et les archives seront complétées.
Je rappelle que ce site n'est pas une résurgence miraculeuse du journal, du
serveur minitel ou d'archives officielles de l'époque.
Ouessan, créateur de ce site n'avait que pour but de partager ses quelques
programmes, sur cassette ou retapés sur émulateur.
Aujourd'hui, après des années de travail de frappe sur émulateur ou
ordinoseaures, le site regroupe près d'un millier de programmes.
Il ne s'agit malheureusement plus de collationner les cassettes, le travail
déjà effectué, ou d'attendre la diffusion des archives minitel fantôme...
La seule source utilisable reste les listings imprimés sur papier de
l'époque.
Ces listings représentent l'image de l'informatique française pendant la
période de diffusion du journal "HEBDOGICIEL"...
Au temps où la programmation avait une dimension humaine, et ce mesurée en
heures de saisie, au temps ou la mémoire limitée la longueur des programmes,
au temps ou l'on apprenait la programmation en s'acharnant à faire
fonctionner un programme qui cumulait des heures de notre temps.
Ces programmes ce méritaient, décevaient ou réjouissaient.
Mais, il est vrai que ces listings dégageaient un certain mystère... jusqu'à
la fin de la saisie.
Seul le RUN dévoilait le réel contenu du programme.
C'était ça la magie d'Hebdogiciel...
On tapait, déboguait et on jouait quelques heures...
En réalité, le temps d'utilisation de ces jeux était inférieur au temps de
la saisie... puis, on passait à un autre programme...
Pour 100 balles, tu avais un programme déjà tapé et qui marchait du premier
coup.
Mais on n'avait l'impression de ne plus mériter ce jeu...
Retrouvez les activités d' "Hebdogiciel, les listings..." sur
http://hebdogiciel.fr
et sur les réseaux sociaux [f]
Le 25-06-2013, GzavSnap nous expliquait dans fr.comp.ordinosaures :
http://hebdogiciel.fr
Il y a un problème dans l'encodage des caractères. Je ne suis pas sépcialiste mais je dirai que le contenu est annoncé commme étant de l'UTF-8 alors qu'en réalité c'est de l'iso-1859-1 ou iso-1859-15.
Le problème doit pouvoir se régler en un coup de cuillère à pot dans la configuration du serveur HTTP (déclarer le charset par défaut en iso-8859-15). Dans le cas d'Apache : http://httpd.apache.org/docs/2.2/en/mod/core.html#adddefaultcharset http://httpd.apache.org/docs/2.2/en/mod/mod_mime.html#addcharset
La meilleure solution serait probablement de passer un coup d'iconv sur l'ensemble des pages afin de les transcoder en utf-8 et d'uniformiser les contenus.
Mis à part ça, très beau travail sur cette collection de listings/logiciels. Bravo.
XP+FU2 fr.comp.infosystemes.www.auteurs -- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 25-06-2013, GzavSnap nous expliquait dans fr.comp.ordinosaures :
http://hebdogiciel.fr
Il y a un problème dans l'encodage des caractères.
Je ne suis pas sépcialiste mais je dirai que le contenu est annoncé
commme étant de l'UTF-8 alors qu'en réalité c'est de l'iso-1859-1 ou
iso-1859-15.
Le problème doit pouvoir se régler en un coup de cuillère à pot dans la
configuration du serveur HTTP (déclarer le charset par défaut en
iso-8859-15).
Dans le cas d'Apache :
http://httpd.apache.org/docs/2.2/en/mod/core.html#adddefaultcharset
http://httpd.apache.org/docs/2.2/en/mod/mod_mime.html#addcharset
La meilleure solution serait probablement de passer un coup d'iconv sur
l'ensemble des pages afin de les transcoder en utf-8 et d'uniformiser
les contenus.
Mis à part ça, très beau travail sur cette collection de
listings/logiciels. Bravo.
XP+FU2 fr.comp.infosystemes.www.auteurs
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 25-06-2013, GzavSnap nous expliquait dans fr.comp.ordinosaures :
http://hebdogiciel.fr
Il y a un problème dans l'encodage des caractères. Je ne suis pas sépcialiste mais je dirai que le contenu est annoncé commme étant de l'UTF-8 alors qu'en réalité c'est de l'iso-1859-1 ou iso-1859-15.
Le problème doit pouvoir se régler en un coup de cuillère à pot dans la configuration du serveur HTTP (déclarer le charset par défaut en iso-8859-15). Dans le cas d'Apache : http://httpd.apache.org/docs/2.2/en/mod/core.html#adddefaultcharset http://httpd.apache.org/docs/2.2/en/mod/mod_mime.html#addcharset
La meilleure solution serait probablement de passer un coup d'iconv sur l'ensemble des pages afin de les transcoder en utf-8 et d'uniformiser les contenus.
Mis à part ça, très beau travail sur cette collection de listings/logiciels. Bravo.
XP+FU2 fr.comp.infosystemes.www.auteurs -- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
[...] On tapait, déboguait et on jouait quelques heures... En réalité, le temps d'utilisation de ces jeux était inférieur au temps de la saisie... puis, on passait à un autre programme...
C'est pas tout a fit vbrai, y'avait aussi les "deuxlignes" beaucoup plus rapide a taper ;-)
[...]
On tapait, déboguait et on jouait quelques heures...
En réalité, le temps d'utilisation de ces jeux était inférieur au temps de
la saisie... puis, on passait à un autre programme...
C'est pas tout a fit vbrai, y'avait aussi les "deuxlignes" beaucoup plus
rapide a taper ;-)
[...] On tapait, déboguait et on jouait quelques heures... En réalité, le temps d'utilisation de ces jeux était inférieur au temps de la saisie... puis, on passait à un autre programme...
C'est pas tout a fit vbrai, y'avait aussi les "deuxlignes" beaucoup plus rapide a taper ;-)
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
Olivier Miakinen
[diapublication dans fr.comp.ordinosaures remise à tout hasard, suivi replacé vers fr.comp.infosystemes.www.auteurs]
Le 26/06/2013 20:53, Doug713705 répondait à GzavSnap :
http://hebdogiciel.fr
Il y a un problème dans l'encodage des caractères. Je ne suis pas spécialiste mais je dirai que le contenu est annoncé commme étant de l'UTF-8 alors qu'en réalité c'est de l'iso-1859-1 ou iso-1859-15.
Plus exactement, le charset du contenu n'est pas annoncé du tout :
Le problème doit pouvoir se régler en un coup de cuillère à pot dans la configuration du serveur HTTP (déclarer le charset par défaut en iso-8859-15). Dans le cas d'Apache : http://httpd.apache.org/docs/2.2/en/mod/core.html#adddefaultcharset http://httpd.apache.org/docs/2.2/en/mod/mod_mime.html#addcharset
Oui.
La meilleure solution serait probablement de passer un coup d'iconv sur l'ensemble des pages afin de les transcoder en utf-8 et d'uniformiser les contenus.
... ce qui ne dispensera pas GzavSnap de devoir déclarer le charset.
XP+FU2 fr.comp.infosystemes.www.auteurs
Yep.
Cordialement, -- Olivier Miakinen
[diapublication dans fr.comp.ordinosaures remise à tout hasard,
suivi replacé vers fr.comp.infosystemes.www.auteurs]
Le 26/06/2013 20:53, Doug713705 répondait à GzavSnap :
http://hebdogiciel.fr
Il y a un problème dans l'encodage des caractères.
Je ne suis pas spécialiste mais je dirai que le contenu est annoncé
commme étant de l'UTF-8 alors qu'en réalité c'est de l'iso-1859-1 ou
iso-1859-15.
Plus exactement, le charset du contenu n'est pas annoncé du tout :
Le problème doit pouvoir se régler en un coup de cuillère à pot dans la
configuration du serveur HTTP (déclarer le charset par défaut en
iso-8859-15).
Dans le cas d'Apache :
http://httpd.apache.org/docs/2.2/en/mod/core.html#adddefaultcharset
http://httpd.apache.org/docs/2.2/en/mod/mod_mime.html#addcharset
Oui.
La meilleure solution serait probablement de passer un coup d'iconv sur
l'ensemble des pages afin de les transcoder en utf-8 et d'uniformiser
les contenus.
... ce qui ne dispensera pas GzavSnap de devoir déclarer le charset.
[diapublication dans fr.comp.ordinosaures remise à tout hasard, suivi replacé vers fr.comp.infosystemes.www.auteurs]
Le 26/06/2013 20:53, Doug713705 répondait à GzavSnap :
http://hebdogiciel.fr
Il y a un problème dans l'encodage des caractères. Je ne suis pas spécialiste mais je dirai que le contenu est annoncé commme étant de l'UTF-8 alors qu'en réalité c'est de l'iso-1859-1 ou iso-1859-15.
Plus exactement, le charset du contenu n'est pas annoncé du tout :
Le problème doit pouvoir se régler en un coup de cuillère à pot dans la configuration du serveur HTTP (déclarer le charset par défaut en iso-8859-15). Dans le cas d'Apache : http://httpd.apache.org/docs/2.2/en/mod/core.html#adddefaultcharset http://httpd.apache.org/docs/2.2/en/mod/mod_mime.html#addcharset
Oui.
La meilleure solution serait probablement de passer un coup d'iconv sur l'ensemble des pages afin de les transcoder en utf-8 et d'uniformiser les contenus.
... ce qui ne dispensera pas GzavSnap de devoir déclarer le charset.
XP+FU2 fr.comp.infosystemes.www.auteurs
Yep.
Cordialement, -- Olivier Miakinen
Denis Beauregard
Le Fri, 28 Jun 2013 10:46:47 +0200, Olivier Miakinen <om+ écrivait dans fr.comp.infosystemes.www.auteurs:
Plus exactement, le charset du contenu n'est pas annoncé du tout :
J'ai eu un problème de charset quand mon hébergeur a changé un des paramètres. J'ai aussi vécu le même problème plus tard (je produis un cédérom dont j'ai une version démo sur mon site).
La solution, pour le UTF8, c'est en fait d'ajouter le BOM, soit les 3 caractères utilisés pour détecter l'UTF8.
Seamonkey, qui permet d'éditer des pages web, enlève (et donc n'ajoute pas) le BOM. J'ai édité certaines pages avec lui et le BOM avait disparu. J'ai par la suite préféré Notepad++ pour éditer ces pages. Je pense que le BOM est ajouté automatiquement par l'énoncé header() de PHP et que si on ne l'utilise pas (page web générée sur l'ordi et non en ligne), alors ce BOM n'y est pas à moins de l'ajouter à la main.
Le Fri, 28 Jun 2013 10:46:47 +0200, Olivier Miakinen
<om+news@miakinen.net> écrivait dans fr.comp.infosystemes.www.auteurs:
Plus exactement, le charset du contenu n'est pas annoncé du tout :
J'ai eu un problème de charset quand mon hébergeur a changé un
des paramètres. J'ai aussi vécu le même problème plus tard (je
produis un cédérom dont j'ai une version démo sur mon site).
La solution, pour le UTF8, c'est en fait d'ajouter le BOM, soit
les 3 caractères utilisés pour détecter l'UTF8.
Seamonkey, qui permet d'éditer des pages web, enlève (et donc
n'ajoute pas) le BOM. J'ai édité certaines pages avec lui et le
BOM avait disparu. J'ai par la suite préféré Notepad++ pour éditer
ces pages. Je pense que le BOM est ajouté automatiquement par
l'énoncé header() de PHP et que si on ne l'utilise pas (page web
générée sur l'ordi et non en ligne), alors ce BOM n'y est pas à
moins de l'ajouter à la main.
Le Fri, 28 Jun 2013 10:46:47 +0200, Olivier Miakinen <om+ écrivait dans fr.comp.infosystemes.www.auteurs:
Plus exactement, le charset du contenu n'est pas annoncé du tout :
J'ai eu un problème de charset quand mon hébergeur a changé un des paramètres. J'ai aussi vécu le même problème plus tard (je produis un cédérom dont j'ai une version démo sur mon site).
La solution, pour le UTF8, c'est en fait d'ajouter le BOM, soit les 3 caractères utilisés pour détecter l'UTF8.
Seamonkey, qui permet d'éditer des pages web, enlève (et donc n'ajoute pas) le BOM. J'ai édité certaines pages avec lui et le BOM avait disparu. J'ai par la suite préféré Notepad++ pour éditer ces pages. Je pense que le BOM est ajouté automatiquement par l'énoncé header() de PHP et que si on ne l'utilise pas (page web générée sur l'ordi et non en ligne), alors ce BOM n'y est pas à moins de l'ajouter à la main.
Le 28 Jun 2013 14:07:25 GMT, Sergio écrivait dans fr.comp.infosystemes.www.auteurs:
Le Fri, 28 Jun 2013 09:21:32 -0400, Denis Beauregard a écrit :
La solution, pour le UTF8, c'est en fait d'ajouter le BOM, soit les 3 caractères utilisés pour détecter l'UTF8.
Surtout pas ! Le serveur va interpréter ça n'importe comment!
Pourtant, cela marche dans mon cas. J'ai encore vu ce comportement récemment. J'ai envoyé sur mon site des pages bien lisibles chez moi et tant qu'il n'y avait pas le BOM, les accents ne passaient pas. C'est là que j'ai vu que Seamonkey enlevait le BOM que j'ai remis avec Notepad++.
La bonne solution est : - Soit ta page est un PHP, il faut ajouter en tête :
Mon site a à la fois du UTF8 et du 1252/8961-1, donc je ne peux pas pour le moment faire ce changement.
Denis
Le 28 Jun 2013 14:07:25 GMT, Sergio
<serge.laposte@delbono.net.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:
Le Fri, 28 Jun 2013 09:21:32 -0400, Denis Beauregard a écrit :
La solution, pour le UTF8, c'est en fait d'ajouter le BOM, soit les 3
caractères utilisés pour détecter l'UTF8.
Surtout pas ! Le serveur va interpréter ça n'importe comment!
Pourtant, cela marche dans mon cas. J'ai encore vu ce comportement
récemment. J'ai envoyé sur mon site des pages bien lisibles chez moi
et tant qu'il n'y avait pas le BOM, les accents ne passaient pas.
C'est là que j'ai vu que Seamonkey enlevait le BOM que j'ai remis
avec Notepad++.
La bonne solution est :
- Soit ta page est un PHP, il faut ajouter en tête :
Le 28 Jun 2013 14:07:25 GMT, Sergio écrivait dans fr.comp.infosystemes.www.auteurs:
Le Fri, 28 Jun 2013 09:21:32 -0400, Denis Beauregard a écrit :
La solution, pour le UTF8, c'est en fait d'ajouter le BOM, soit les 3 caractères utilisés pour détecter l'UTF8.
Surtout pas ! Le serveur va interpréter ça n'importe comment!
Pourtant, cela marche dans mon cas. J'ai encore vu ce comportement récemment. J'ai envoyé sur mon site des pages bien lisibles chez moi et tant qu'il n'y avait pas le BOM, les accents ne passaient pas. C'est là que j'ai vu que Seamonkey enlevait le BOM que j'ai remis avec Notepad++.
La bonne solution est : - Soit ta page est un PHP, il faut ajouter en tête :
Je plusoie ... l'UTF8 avec BOM est la source de telelment de problème qu'il vaut mieux éviter.
le charset peut aussi être codé dans l'netê avec une balise méta
il faut effectivement être cohérent entre le charset imposé par le serveur web (il ne devrait jamais l'imposer) le header http le meta html
Otomatic
Denis Beauregard écrivait :
C'est là que j'ai vu que Seamonkey enlevait le BOM que j'ai remis avec Notepad++.
Le BOM dans un fichier PHP, c'est, à coup sûr :
Warning: Cannot modify header information - headers already sent by …
d'autant plus que, comme sont nom l'indique : Byte Order Mark, un fichier codé utf-8 n'a absolument pas besoin de BOM puisque l'ordre des octets de codage est immuable. -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont forcément raison. Coluche
C'est là que j'ai vu que Seamonkey enlevait le BOM que j'ai remis
avec Notepad++.
Le BOM dans un fichier PHP, c'est, à coup sûr :
Warning: Cannot modify header information - headers already sent by …
d'autant plus que, comme sont nom l'indique : Byte Order Mark, un
fichier codé utf-8 n'a absolument pas besoin de BOM puisque l'ordre des
octets de codage est immuable.
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort
qu'ils ont forcément raison. Coluche
C'est là que j'ai vu que Seamonkey enlevait le BOM que j'ai remis avec Notepad++.
Le BOM dans un fichier PHP, c'est, à coup sûr :
Warning: Cannot modify header information - headers already sent by …
d'autant plus que, comme sont nom l'indique : Byte Order Mark, un fichier codé utf-8 n'a absolument pas besoin de BOM puisque l'ordre des octets de codage est immuable. -- Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont forcément raison. Coluche
Denis Beauregard
Le Sat, 06 Jul 2013 15:14:19 +0200, Otomatic écrivait dans fr.comp.infosystemes.www.auteurs:
Denis Beauregard écrivait :
C'est là que j'ai vu que Seamonkey enlevait le BOM que j'ai remis avec Notepad++.
Le BOM dans un fichier PHP, c'est, à coup sûr :
Warning: Cannot modify header information - headers already sent by …
d'autant plus que, comme sont nom l'indique : Byte Order Mark, un fichier codé utf-8 n'a absolument pas besoin de BOM puisque l'ordre des octets de codage est immuable.
Attention, il y a aussi la possibilité de générer hors-ligne un document HTML, puis de le diffuser par cédérom. Dans ce cas, il est impossible d'utiliser l'énoncé header().
La commande envoie à la sortie standard l'en-tête du fichier. Je place sur Internet certains fichiers qui sont aussi sur le cédérom. Sans ce BOM, il y a un problème de caractères et je l'ai résolu avec un BOM ajouté à la main (soit en éditant avec Notepad++, soit en écrivant au début du fichier).
Quant au BOM, comment faire la différence autrement entre 2 jeux de caractères ? L'énoncé dans les META est insuffisant.
Denis
Le Sat, 06 Jul 2013 15:14:19 +0200, Otomatic <otomatic@oto.invalid>
écrivait dans fr.comp.infosystemes.www.auteurs:
C'est là que j'ai vu que Seamonkey enlevait le BOM que j'ai remis
avec Notepad++.
Le BOM dans un fichier PHP, c'est, à coup sûr :
Warning: Cannot modify header information - headers already sent by …
d'autant plus que, comme sont nom l'indique : Byte Order Mark, un
fichier codé utf-8 n'a absolument pas besoin de BOM puisque l'ordre des
octets de codage est immuable.
Attention, il y a aussi la possibilité de générer hors-ligne un
document HTML, puis de le diffuser par cédérom. Dans ce cas, il est
impossible d'utiliser l'énoncé header().
La commande envoie à la sortie standard l'en-tête du fichier. Je place
sur Internet certains fichiers qui sont aussi sur le cédérom. Sans ce
BOM, il y a un problème de caractères et je l'ai résolu avec un BOM
ajouté à la main (soit en éditant avec Notepad++, soit en écrivant
au début du fichier).
Quant au BOM, comment faire la différence autrement entre 2 jeux
de caractères ? L'énoncé dans les META est insuffisant.
Le Sat, 06 Jul 2013 15:14:19 +0200, Otomatic écrivait dans fr.comp.infosystemes.www.auteurs:
Denis Beauregard écrivait :
C'est là que j'ai vu que Seamonkey enlevait le BOM que j'ai remis avec Notepad++.
Le BOM dans un fichier PHP, c'est, à coup sûr :
Warning: Cannot modify header information - headers already sent by …
d'autant plus que, comme sont nom l'indique : Byte Order Mark, un fichier codé utf-8 n'a absolument pas besoin de BOM puisque l'ordre des octets de codage est immuable.
Attention, il y a aussi la possibilité de générer hors-ligne un document HTML, puis de le diffuser par cédérom. Dans ce cas, il est impossible d'utiliser l'énoncé header().
La commande envoie à la sortie standard l'en-tête du fichier. Je place sur Internet certains fichiers qui sont aussi sur le cédérom. Sans ce BOM, il y a un problème de caractères et je l'ai résolu avec un BOM ajouté à la main (soit en éditant avec Notepad++, soit en écrivant au début du fichier).
Quant au BOM, comment faire la différence autrement entre 2 jeux de caractères ? L'énoncé dans les META est insuffisant.
