Hvorfor er bokstavene i EBCDIC ikke i rekkefĂžlge?

ASCII-standarden ble vedtatt i 1963, og i dag er det knapt noen som bruker en koding der de fÞrste 128 tegnene avviker fra ASCII. Likevel ble EBCDIC - standardkoden for IBM-mainframes og deres sovjetiske kloner ES EVM - aktivt brukt frem til slutten av forrige Ärhundre. EBCDIC forblir den primÊre koden i z/OS - standardoperativsystemet for moderne IBM Z-mainframes.

Det som umiddelbart fanger Þyet ved EBCDIC - er at bokstavene ikke fÞlger hverandre: mellom I og J og mellom R og S ble det stÄende ubrukte posisjoner (pÄ ES EVM ble det i disse mellomrommene fordelt tegn for kyrillisk). Hvem kunne ha tenkt seg Ä kode bokstaver med ujevne mellomrom mellom nabobokstaver?

Hvorfor er bokstavene i EBCDIC ikke i rekkefĂžlge?

Selve navnet EBCDIC («Extended BCDIC») antyder at denne koden, i motsetning til ASCII, ikke ble laget pÄ bar bakke, men basert pÄ den seks-bits BCDIC-kodingen, som ble brukt siden IBM 704 (1954):

Hvorfor er bokstavene i EBCDIC ikke i rekkefĂžlge?

Det er ingen direkte bakoverkompatibilitet: en praktisk egenskap ved BCDIC, som ble tapt da man gikk over til EBCDIC, var at tallene 0—9 svarte til koder 0-9. Likevel var det allerede sprang pĂ„ syv koder mellom I og J og Ă„tte koder mellom R og S i BCDIC. Hvor kom de fra?

Historien om (E)BCDIC begynner samtidig med historien om IBM - lenge fÞr de elektroniske datamaskinene. IBM ble dannet ved sammenslÄing av fire selskaper, hvorav det teknologisk mest avanserte var "Tabulating Machine Company", grunnlagt i 1896 av Herman Hollerith - oppfinneren av tabulatoren.De fÞrste tabulatorene telte bare antall hullkort som ble perforert pÄ et bestemt sted; men i 1905 begynte Hollerith produksjon av desimale tabulatorer. Hvert kort for desimal tabulator bestod av felt av vilkÄrlig lengde, og tallene skrevet i disse feltene i vanlig desimalform ble summert over hele bunken. Oppdelingen av kortet i felt ble bestemt ved Ä koble ledninger pÄ tilkoblingspanelet til tabulatoren. For eksempel, pÄ dette hullkortet fra Hollerith, oppbevart i Kongressbiblioteket, er tallet 23456789012345678 Äpenbart preget, ukjent hvordan det er delt opp i felt:

Hvorfor er bokstavene i EBCDIC ikke i rekkefĂžlge?

De mest observante kan ha lagt merke til at kortet til Hollerith har 12 rader for hull, selv om det kun trengs ti for sifrene; og i BCDIC brukes bare 12 koder fra 16 mulige for hver av de to Ăžverste bitene.

SelvfĂžlgelig er dette ikke en tilfeldig tilfeldighet. Opprinnelig planla Hollerith ekstra kolonner for “spesielle markeringer” som ikke ble summert, men bare ble talt — som i de aller fĂžrste tabulatorene. (I dag ville vi kalt dem “bitfelt”.) I tillegg kunne man blant “spesielle markeringer” angi gruppeindikatorer: hvis det under tabuleringen var behov for bĂ„de endelige summer og mellomliggende, stoppet tabulatoren nĂ„r den oppdaget en endring av en av gruppeindikatorene, og operatĂžren mĂ„tte skrive ned de mellomliggende summene fra digitale tavler til papir, nullstille tavlene, og gjenoppta tabuleringen. For eksempel, nĂ„r man oppsummerte regnskapsbalanser, kunne en gruppe kort svare til en dato eller Ă©n motpart.

Innen 1920, da Hollerith allerede hadde pensjonert seg, kom “trykkede tabulatorer” i bruk, som kunne kobles til telegrafer og selv skrive ut mellomliggende summer uten operatĂžrens inngripen. Komplikasjonen nĂ„ var Ă„ avgjĂžre hva hvert av de trykte tallene refererte til. I 1931 bestemte IBM seg for Ă„ bruke “spesielle markeringer” for Ă„ indikere bokstaver: en merking i 12. rad indikerte bokstaven fra A til I, i 11. rad — fra J til R, i nullrad — fra S til Z. Den nye “alfabetiske tabulatoren” kunne skrive ut navnet pĂ„ hver kortgruppe sammen med mellomliggende summer; samtidig ble en ubenyttet kolonne til et mellomrom mellom symbolene. Legg merke til at S angis med kombinasjonen av hull 0+2, mens kombinasjonen 0+1 opprinnelig ikke ble brukt av frykt for at to hull nĂŠrt sammen i Ă©n kolonne kunne forĂ„rsake mekaniske problemer i leseren.

Hvorfor er bokstavene i EBCDIC ikke i rekkefĂžlge?

NÄ kan vi se pÄ BCDIC-tabellen fra et litt annet perspektiv:

Hvorfor er bokstavene i EBCDIC ikke i rekkefĂžlge?

Bortsett fra at 0 og mellomrom er byttet om, bestemmer de to hĂžyeste bitene “spesielle markeringen”, som fra 1931 ble perforert i hullkortet for det tilsvarende symbolet; mens de fire laveste bitene bestemmer tallet som perforeres i hoveddelen av kortet. StĂžtte for symboler & - / ble en tabulatorene til IBM pĂ„ 1930-tallet, og koding av disse tegnene i BCDIC samsvarer med hullene som ble laget for dem. Da behovet for stĂžtte for et enda stĂžrre antall tegn oppstod, begynte man Ă„ lage en rekke spesielle merker i rad 8 — slik kunne det vĂŠre opptil tre hull i Ă©n kolonne. Dette formatet for hullkort har forblitt nesten uforandret til slutten av Ă„rhundret. I Sovjetunionen beholdt de IBM-kodene for det latinske alfabetet og tegnsetting, mens for kyrilliske bokstaver ble det laget flere spesielle merker i rad 12, 11, 0 — uten Ă„ vĂŠre begrenset til tre hull i Ă©n kolonne.

Da IBM 704 ble laget, tenkte man ikke lenge pÄ kodingen av tegn for den: man tok koden som allerede var i bruk i hullkort og bare plasserte 0 pÄ rett sted. I 1964, da man gikk fra BCDIC til EBCDIC, ble de laveste fire bitene av hvert tegn uendret, selv om de hÞyere bitene ble omstokket litt. Dermed pÄvirket hullkortformatet som Holerit valgte tidlig pÄ 1900-tallet arkitekturen til alle IBM-datamaskiner, inkludert IBM Z.

Kilde: habr.com

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster