その結果、現行開発の足を引っ張る結果になっているのもあります。
汎用機のコード体系に EBCDICコードというものがあります。
原型は AlphabetのA-Z(大文字)と0-9の数字の規定が基本になっています。
コードのbyte値がなんともユニークなんですよね。
数字の0～9のbyte値は "0" は 0xF0, "1"は0xF1,,,,,"9"は0xF9 のように連続します。
ところが "A"から"Z"は非連続なんです。
"A":0xC1 "B" :0xC2...."I":0xC9
"J":0xD1 "K" :0xD2...."R":0xD9
"S" :0xD2...."Z":0xE9
その他はBlankで未定義扱い.
Open系の感覚からすれば A-Z は連続で code++ で処理したいところ....
策定された当時は IBMが定義したことが標準となる時代で、16進の世界なのに(二進化10進を考慮してか)10個刻みにalphabetを配置していますね。
カタカナや漢字に対応するために Shift-in/out コードでモードを設定しています。
Open系のShift-JisやUnixでは当たり前に扱っているalphabetと漢字の混在ができない不便な世界となっています。汎用機のDBのUnicode化が進んでいるのでいずれは解消されるのでしょうが。過去の資産があるので、当分はEBCDIC文化のを意識して開発する局面は多いです。
ワンクマBlogの世界にいると「半角全角、半角=1byte、全角=2byte」なんて発言したら嘲笑されてしまいますが、汎用機が絡む現場では逆にUnicodeで話をすると通じません。半角全角ShiftIn/Shiftoutで何文字で何Byte という会話が飛び交ってます。
未来から振り返るので、連続していない文字コードなんて馬鹿げているように感じますが、当時の人は熟考した結果の策定だったのでしょうかね。......将来のことを考えずに適当に策定した感じもする。
一度決める変更するのに多大なコストがかかるので、標準の策定にはくれぐれも拡張性をお忘れなく。