"Hebdogiciel, les listings...": Oric1/Atmos

Le
GzavSnap
Salut à tous,

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]
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Doug713705
Le #25505852
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.

Pire, l'initulé du bouton Facebook© est lui en utf-8, raison pour
laquelle le 'ç' ne s'affiche pas correctement lorsqu'on veut afficher la
page en iso-8859-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
pdorange
Le #25506892
GzavSnap
[...]
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 ;-)

En tout cas merci de ce travail de mémoire.

--
Pierre-Alain Dorange Moof
Ce message est sous licence Creative Commons "by-nc-sa-2.0"
Olivier Miakinen
Le #25508882
[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 :

Date: Fri, 28 Jun 2013 08:31:28 GMT
Server: Apache
Last-Modified: Mon, 10 Jun 2013 17:25:41 GMT
Etag: "c02346a5-66a2-4ded011db9001"
Accept-Ranges: bytes
Content-Type: text/html
Via: 1.1 localhost.localdomain
Content-Length: 26274
Age: 1

200 OK
</>

Et en effet ce contenu est en iso-1859-1 ou iso-1859-15 (ou peut-être
cp1252).

Pire, l'initulé du bouton Facebook© est lui en utf-8, raison pour
laquelle le 'ç' ne s'affiche pas correctement lorsqu'on veut afficher la
page en iso-8859-15.



C'est une iframe dont le contenu est en utf-8, mais là, parfaitement
déclaré :

Cache-Control: private, no-cache, no-store, must-revalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Pragma: no-cache
X-Content-Type-Options: nosniff
x-xss-protection: 0
Content-Type: text/html; charset=utf-8
X-FB-Debug: sK2lUcv+TzpeqS3sTyDLm2QorWLnR+HdCjVn24Y3XIg Date: Fri, 28 Jun 2013 08:36:25 GMT
Age: 0
Via: 1.1 localhost.localdomain
Content-Length: 5200
Connection: Keep-Alive
Content-Encoding: gzip

200 OK
</>

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 #25509292
Le Fri, 28 Jun 2013 10:46:47 +0200, Olivier Miakinen

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.

Dans mon cas :

Page générée en ligne

<?php header("Content-Type: text/html; charset=UTF-8"); ?>

Page générée en local avec BOM

fputs($fp, "xEFxBBxBF");


Denis
Sergio
Le #25509402
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!

La bonne solution est :
- Soit ta page est un PHP, il faut ajouter en tête :

<?php
header('Content-type: text/html; charset=utf-8');
?>

Soit il faut ajouter dans le .htaccess

AddCharset UTF-8 .html .htm

cf : http://www.w3.org/International/O-HTTP-charset.fr.php
Denis Beauregard
Le #25509482
Le 28 Jun 2013 14:07:25 GMT, Sergio
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 :

<?php
header('Content-type: text/html; charset=utf-8');
?>

Soit il faut ajouter dans le .htaccess

AddCharset UTF-8 .html .htm

cf : http://www.w3.org/International/O-HTTP-charset.fr.php



Mon site a à la fois du UTF8 et du 1252/8961-1, donc je ne peux
pas pour le moment faire ce changement.


Denis
BertrandB
Le #25528092
Le 28/06/2013 16:07, Sergio a écrit :

<?php
header('Content-type: text/html; charset=utf-8');
?>

Soit il faut ajouter dans le .htaccess

AddCharset UTF-8 .html .htm

cf : http://www.w3.org/International/O-HTTP-charset.fr.php



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
BertrandB
Le #25528082
Le 28/06/2013 16:07, Sergio a écrit :

<?php
header('Content-type: text/html; charset=utf-8');
?>

Soit il faut ajouter dans le .htaccess

AddCharset UTF-8 .html .htm

cf : http://www.w3.org/International/O-HTTP-charset.fr.php



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
Le #25528622
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
Denis Beauregard
Le #25529422
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().

http://ca1.php.net/manual/fr/function.header.php

void header ( string $string [, bool $replace = true [, int
$http_response_code ]] )

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
Publicité
Poster une réponse
Anonyme