Nous avons souvent déploré les législateurs qui ne pigent rien à la technique, en tout cas moi je suis souvent effaré devant certaines décisions... Il semble que cette banque a cru se baser sur cette incurie notoire, ou alors c'est son ignorance crasse qu'elle a cru universelle, après tout les imbéciles ça ose tout...
Un petit tour sur Wikippedia nous dit que EBCDIC est :
bien vieux (ça remonte aux cartes perforées dont son inventeur, IBM, était un leader...) et on apprend qu'il « existe au moins 6 versions différentes bien documentées... » ;
effectivement « encore utilisé dans les systèmes AS/400 d’IBM ainsi que sur les mainframes sous MVS (aujourd'hui z/OS), VM ou DOS/VSE. »
codé sur un octet (tient, comme l'ASCII étendu...) et on lit surtout que « les bits de poids fort sont apparus après et ont permis de coder dans une colonne supplémentaire de perforation les distinctions entre chiffres et lettres, ou entre minuscules et majuscules. »
CQFD !
Mais ce n'est pas tout... Il est fait mention de l'UTF-EBCDIC dont l'apparition rend inutile toute évolution de ce codage et surtout caduques les variantes nationalisées (et des pages de codes). Une section de la page de ce dernier mentionne : « Généralement, cet encodage est rarement utilisé, même sur les mainframes basé sur l’EBCDIC et pour lesquels cet encodage a été conçu. Les systèmes de mainframes IBM basés sur l’EBCDIC, comme z/OS ou MVS, utilisent aujourd’hui généralement l’UTF-16 pour un support complet d’Unicode : par exemple, DB2 UDB, COBOL, PL/I, Java et la boîte d’outils IBM pour XML supportent tous l’UTF-16 sur les systèmes IBM. »
Le Consortium Unicode ayant été fondé en janvier 1991 et fait sa première publication en octobre 1991, ce n'était plus une nouveauté en 1995... Mais même en supposant que les équipes de développements et les outils n'étaient prêts, l'ancien système savait quand même gérer les caractères accentués... et les minuscules... en tout cas pour les caractères latins. Je ne m'explique pas l'inertie de ces institutions.
"It is seldom that liberty of any kind is lost all at once." ― David Hume
# arroseur arrosé ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal EBCDIC n'est pas compatible avec la RGPD. Évalué à 10. Dernière modification le 26 octobre 2021 à 05:55.
Nous avons souvent déploré les législateurs qui ne pigent rien à la technique, en tout cas moi je suis souvent effaré devant certaines décisions... Il semble que cette banque a cru se baser sur cette incurie notoire, ou alors c'est son ignorance crasse qu'elle a cru universelle, après tout les imbéciles ça ose tout...
Un petit tour sur Wikippedia nous dit que EBCDIC est :
CQFD !
Mais ce n'est pas tout... Il est fait mention de l'UTF-EBCDIC dont l'apparition rend inutile toute évolution de ce codage et surtout caduques les variantes nationalisées (et des pages de codes). Une section de la page de ce dernier mentionne : « Généralement, cet encodage est rarement utilisé, même sur les mainframes basé sur l’EBCDIC et pour lesquels cet encodage a été conçu. Les systèmes de mainframes IBM basés sur l’EBCDIC, comme z/OS ou MVS, utilisent aujourd’hui généralement l’UTF-16 pour un support complet d’Unicode : par exemple, DB2 UDB, COBOL, PL/I, Java et la boîte d’outils IBM pour XML supportent tous l’UTF-16 sur les systèmes IBM. »
Le Consortium Unicode ayant été fondé en janvier 1991 et fait sa première publication en octobre 1991, ce n'était plus une nouveauté en 1995... Mais même en supposant que les équipes de développements et les outils n'étaient prêts, l'ancien système savait quand même gérer les caractères accentués... et les minuscules... en tout cas pour les caractères latins. Je ne m'explique pas l'inertie de ces institutions.
"It is seldom that liberty of any kind is lost all at once." ― David Hume