RFC338 日本語訳

Network Working Group                                        R.T. Braden
Request for Comments: 338                                       UCLA/CCN
NIC: 9931                                                    17 May 1972

コメントを求めるワーキンググループR.T.ブレーデン要求をネットワークでつないでください: 338UCLA/CCN NIC: 9931 1972年5月17日

                  EBCDIC/ASCII MAPPING FOR NETWORK RJE

ネットワークのためにRJEを写像するEBCDIC/ASCII

A. INTRODUCTION

A。 序論

   Under NETRJS [1], CCN's Network rje protocol [2], a virtual remote
   batch terminal may be either EBCDIC or ASCII.  CCN operates an IBM
   360/91 which performs all of its normal processing in EBCDIC.  When a
   virtual ASCII terminal signs onto NETRJS, CCN translates the "card
   reader" stream to EBCDIC and translates the "printer" stream back to
   ASCII [3].

NETRJS[1]、CCNのNetwork rjeプロトコル[2]の下では、仮想のリモートバッチ端末は、EBCDICかASCIIのどちらかであるかもしれません。 CCNはEBCDICで正常処理のすべてを実行するIBM360/91を経営します。 仮想のASCII端末がNETRJSにサインするとき、CCNは「カードリーダ」の流れをEBCDICに翻訳して、「プリンタ」の流れをASCII[3]に翻訳して戻します。

   In recent months, a number of ASCII hosts (RAND PDP-10, Utah PDP-10,
   Illinois PDP-11) have completed user processes for NETRJS.  Several
   users at these sites have noted deficiencies in the ASCII/EBCDIC
   mapping rules originally implemented in NETRJS.  Since their
   objections were well founded, we have altered the existing mapping
   and added a new one.

最近の数カ月、多くのASCIIホスト(RAND PDP-10、ユタPDP-10、イリノイPDP-11)がNETRJSのためのユーザ・プロセスを完成しています。 これらのサイトの数人のユーザが配置規則が元々NETRJSで実行したASCII/EBCDICで欠乏に注意しました。 彼らの反論がよく設立されて以来、私たちは、既存のマッピングを変更して、新しいものを加えています。

   This RFC has three purposes:

このRFCには、3つの目的があります:

      (1) to make all users of NETRJS aware of the changed ASCII mapping

(1) NETRJSのすべてのユーザを変えられたASCIIマッピングを意識するようにするように

      (2) to call this problem to the attention of the Network RJE
          Protocol Committee

(2) Network RJEの注意へのこの問題をプロトコルCommitteeと呼ぶために

      (3) to knowledge and support Joel Winett's pioneering work [4] in
          this area.

知識への(3)とジョエルWinettが開拓するサポートはこの領域で[4]を扱います。

THE EBCDIC CHIMERA

EBCDIC幻想

   A year ago, Joel Winett Published RFC #183, containing the results of
   his careful research into just what EBCDIC really means.  He sounded
   a clarion call for all EBCDIC sites to join in defining a Network
   standards mapping.  At this time, we at CCN were primarily absorbed
   in the timely implementation of the NETRJS protocol to serve an
   EBCDIC (!) user site, RAND, so we were not very supportive of his
   efforts.

1年前、ちょうどEBCDICが本当に意味することの彼の徹底した調査の結果を含むジョエルWinett Published RFC#183。 彼はすべてのEBCDICサイトがNetwork規格マッピングを定義するのに参加するというクラリオン要求を鳴らしました。 このときEBCDIC (!)ユーザの現場、RANDに役立つようにNETRJSプロトコルのタイムリーな実現にCCNの私たちを主として没頭させたので、私たちはそれほど彼の努力を支持していませんでした。

   RFC #183 is a valuable document; we hope a copy falls into the hands
   of Armonk.  It is clear from RFC #183 that EBCDIC consists of a
   standard ("basic") set of characters, combined with a number of
   overlapping ad-hoc character happenings.  Fortunately, if we exclude

RFC#183は重要書類です。 コピーがアーモンクの手になることを願っています。 RFC#183から、EBCDICが臨時のキャラクタ出来事を重ね合わせる数に結合された標準(「基本的な」)のキャラクタから成るのは、明確です。 幸い、私たちである、除外

Braden                                                          [Page 1]

RFC 338           EBCDIC/ASCII MAPPING FOR NETWORK RJE          May 1972

1972年5月にネットワークのためにRJEを写像するブレーデン[1ページ]RFC338EBCDIC/ASCII

   special-purpose text composition programs, IBM 360 programs use only
   the 89 "basic" EBCDIC graphics [5] shown in RFC #183 as well as in
   Figure 1.  An IBM 029 "EBCDIC" keypunch can create 63 graphics: the
   89 basic EBCDIC graphics less the 26 lower case letters.  In fact,
   OS/360 requires an even smaller subset of EBCDIC, 60 characters
   commonly called the "PL/1 character set".  The PL/1 set consists of
   the 89 basic graphics, less the 26 lower case letters as well as the
   three graphics <cent sign>!" (cent sign, exclamation point, and
   quotation).

専用テキスト構成プログラム、IBM360プログラムはRFC#183と図1に示された89の「基本的な」EBCDICグラフィックス[5]だけを使用します。 IBM029の"EBCDIC"穿孔機で穿孔は63のグラフィックスを作成できます: 26が下ろすもう89のグラフィックスの基本的なEBCDIC減は手紙をケースに入れます。 事実上、OS/360はEBCDICのさらに小さい部分集合、一般的に「PL/1文字の組」と呼ばれる60のキャラクタを必要とします。 「PL/1セットは89の基本的なグラフィックスから成って、26が下ろす以下は3グラフィックス<セントのサイン>と同様に手紙をケースに入れます!」 (セント記号、感嘆符、および引用。)

C. CHARACTER MAPPING IN NETRJS

C。 NETRJSのキャラクタマッピング

   We consider now the requirements of a ASCII/EBCDIC mapping for NETRJS
   or any rje protocol.  These requirements are as follows:

私たちは現在、NETRJSのためのASCII/EBCDICマッピングかどんなrjeプロトコルの要件も考えます。 これらの要件は以下の通りです:

      Efficiency:

効率:

      The translation should be character-to-character, so that the CPU
      operation "translate" can be used and character scans obviated.
      This is important because a significant volume of character data
      may be moved during rje operations.

翻訳は、キャラクタからキャラクタであるべきです、そして、したがって、CPU操作が「翻訳されること」を使用できます、そして、キャラクタは取り除いた状態でスキャンします。 キャラクタデータの重要な量がrje操作の間、動かされるかもしれないので、これは重要です。

      Usability:

ユーザビリティ:

      (1) All of the 89 EBCDIC graphics should be mapped into
          corresponding ASCII characters.

(1) 89のEBCDICグラフィックスのすべてが対応するASCII文字に写像されるべきです。

      (2) The mapping should be as nearly transparent as possible, i.e.,
          whenever the same graphic appears in both sets, it should map
          onto itself.

(2) マッピングができるだけほとんど見え透くべきである、すなわち、同じグラフィックが両方のセットに現れるときはいつも、それはそれ自体に写像されるべきです。

      (3) To minimize the adaptation required of an EBCDIC-oriented
          programmer, the ASCII graphics should evoke the corresponding
          EBCDIC graphic, when they are not identical.

(3) EBCDIC指向のプログラマに必要である適合を最小にするために、ASCIIグラフィックスは対応するEBCDICグラフィックを喚起するべきです、それらが同じでないときに。

   Theses considerations led us to incorporate Winett's rules II (a) and
   III (b) (see page 4 of the RFC #183) into NETRJS:

論文問題は、私たちがWinettの規則II(a)とIII(b)(RFC#183のうちの4ページを参照する)をNETRJSに取り入れるように導きました:

        ASCII                EBCDIC
        -----                ------
          |                     |

ASCII EBCDIC----- ------ | |

          ~                 <bent bar>

~<折り曲げ筋>。

          \                 <cent sign>

\<セント記号>。

Braden                                                          [Page 2]

RFC 338           EBCDIC/ASCII MAPPING FOR NETWORK RJE          May 1972

1972年5月にネットワークのためにRJEを写像するブレーデン[2ページ]RFC338EBCDIC/ASCII

   This defines all 89 basic EBCDIC graphics in terms of ASCII.
   However, there is still a question of how to map the 6 "maverick"
   ASCII characters ( []{}^` ) which are not in EBCDIC and not in the
   list above.

これはASCIIに関してすべての89の基本的なEBCDICグラフィックスを定義します。 'しかしながら、どう6人の「一匹おおかみ」ASCII文字( []を写像するかに関する質問がまだある、^、'、)、上記のリストにあるのではなく、EBCDICにない。

   We could (and did) take the view that all CCN users are concerned
   only with writing and executing normal 360 programs using EBCDIC and
   that they would enter one of the maverick ASCII graphics only in
   error.  Our original choice, therefore, was to map the mavericks in
   the input into EBCDIC question marks.  We also assumed that, if a
   user needs to access a larger subset of EBCDIC than the basic 89, he
   should do so by doing his rje directly in EBCDIC.

私たちは取ることができました。(and did)はすべてのCCNユーザがEBCDICを使用することで通常の360のプログラムをしか書いて、実行しないのに関係があって、一匹おおかみASCIIグラフィックスの1つを間違うだけ、そして入れるだろうという意見を取ります。 私たちのオリジナルの選択はしたがって、入力でEBCDIC疑問符に一匹おおかみを写像することでした。 また、私たちは、ユーザが、基本的な89よりEBCDICのさらに大きい部分集合にアクセスする必要があるなら彼が直接EBCDICで彼のrjeをすることによってそうするべきであると思いました。

   We now realize that there were two deficiencies in the original
   mapping rules.

私たちは、今、オリジナルの配置規則には2つの欠乏があったとわかります。

      1. The 360 program may be intended to manipulate ASCII text from
          the Network.  In that case, the Network user needs to have all
          ASCII characters, including the mavericks, uniquely mapped
          into EBCDIC in some (standard) manner.

1. 360プログラムがNetworkからのASCIIテキストを操ることを意図するかもしれません。 その場合、Networkユーザは一匹おおかみを含むASCII文字が何らかの(標準)の方法でEBCDICに唯一写像したすべてを必要とします。

      2. The present mapping is convenient only if a user at an AT&T
          Model 33/35 Teletype (or simulator thereof) needs a different
          mapping for ease of use.

2. AT&T Model33/35テレタイプ(または、それのシミュレータ)におけるユーザが使いやすさのための異なったマッピングを必要とする場合にだけ、現在のマッピングは便利です。

   For the first case, we have changed the mapping of the 6 maverick
   ASCII characters from "?", using instead Winett's rules III (c) and
   III (d):

最初のケースのために、私たちは“?"から6人の一匹おおかみASCII文字のマッピングを変えました、代わりにWinettの規則III(c)とIII(d)を使用して:

      ASCII             EBCDIC
      -----             ------
        [                X'AD'
        ]                X'BD'
        {                X'8B'
        }                X'9B'
        ^                X'71'
        `                X'79'

ASCII EBCDIC----- ------ '[X'AD']X'BD'X'8B'X'9B'^X71年''X79年'

   For the user with a Model 33/35 Teletype, we have expanded the set of
   virtual remote batch terminal types, adding "TTY" to "ASCII" and
   "EBCDIC".  A user establishes his virtual remote batch terminal as
   type TTY by either doing his initial ICP to socket 15 (vs. 11 for
   EBCDIC, 13 for ASCII), or by doing an ICP to Socket 1 and entering
   the command "TTYRJS" (vs. "RJS" for EBCDIC, "ARJS" for ASCII).  The
   mapping used by NETRJS for a TTY remote is:

Model33/35テレタイプをもっているユーザに関しては、私たちはリモートバッチの仮想の端末タイプのセットを膨張させました、「ASCII」と"EBCDIC"に"TTY"を加えて。 ユーザは、タイプTTYとソケット15(ASCIIのための13対EBCDICのための11)に彼の初期のICPをするか、Socket1にICPをして、またはコマンド「TTYRJS」(EBCDICのための「RJS」に対してASCIIのための「ARJS」)を入れることによって、彼の仮想のリモートバッチ端末を書き立てます。 TTYにリモートな状態でNETRJSによって使用されたマッピングは以下の通りです。

Braden                                                          [Page 3]

RFC 338           EBCDIC/ASCII MAPPING FOR NETWORK RJE          May 1972

1972年5月にネットワークのためにRJEを写像するブレーデン[3ページ]RFC338EBCDIC/ASCII

   Model 33          Corresponding
   Graphic               ASCII               EBCDIC
   --------          -------------           ------
      \                   \                   <bent bar>

モデルの33の対応するグラフィックASCII EBCDIC-------- ------------- ------ \\<折り曲げ筋>。

    <up arrow>            ^                     |

矢の>^への<。|

    <left arrow>          _                     _

<左向きの矢>_ _

      [                   [                  <cent sign>

[<セント記号>。

      ]                   ]                   X'BD'

] ] X'BD'

   This is ugly, but it is probably the best we can do.

これは醜いのですが、それはたぶん私たちが尽くすことができるベストです。

D. CONCLUSIONS

D。 結論

   It is obvious that one pair of translation tables won't do the job;
   NETRJS needs (at least) two mappings for each direction.  How long
   will it be before an important set of users appears with a different
   terminal character set, requiring yet a different mapping? [6] An rje
   server site needs to be prepared to provide a variety of translation
   tables, and perhaps to allow a user to specify his own table(s); this
   mini-subset of "Date Reconfiguration Service" might be necessary to
   prevent translation-table-proliferation.  The tendency in Network
   discussions has been to put the burden upon the user sites to adapt
   to different conventions.  In the real world of users and servers,
   the server will often have to do the adapting.

1組の変換テーブルが仕事しないのは、明白です。 NETRJSは各指示あたり(少なくとも)の2つのマッピングを必要とします。 重要なセットのユーザが異なった端末の文字の組にもかかわらず、必要にもかかわらず、異なったマッピングと共に現れるまで、どれくらいかかるでしょうか? [6] rjeサーバサイトは、さまざまな変換テーブルを前提として、ユーザに恐らく彼自身のテーブルを指定させるように準備される必要があります。 「日付の再構成サービス」のこのミニ部分集合が、翻訳テーブル増殖を防ぐのに必要であるかもしれません。 Network議論における傾向は異なったコンベンションに順応するためにユーザの現場に負担を置くことです。 ユーザとサーバの本当の世界では、サーバがしばしば適合しなければならないだろうこと。

NOTES AND REFERENCES

注意と参照

      [1] R.T. Braden, Interim NETRJS Specifications, RFC #189 (NIC
          #7133), July 15, 1971.

[1] R.T.ブレーデン、当座のNETRJS仕様、RFC#189(NIC#7133)、1971年7月15日。

      [2] Please note that "RJS" is the proper name of a particular rje
          package written at CCN the generic name for remote batch
          service is "rje".

[2] 「RJS」はパッケージが"rje"であるとリモートバッチサービスのためのCCNでの総称に書かれている特定のrjeの正式名称です。

      [3] Notice that the mapping question discussed in this RFC is
          significant only for the virtual card reader and printer
          connections in NETRJS.  The punch connection is always
          transparent, i.e., never translated.  The remote operator
          connections use the extended EBCDIC/ASCII mapping including
          the maverick characters, but this is not important since
          operator commands require only a limited character set.

[3] NETRJSでのバーチャルカード読者とプリンタ接続だけに、このRFCで議論したマッピング問題が重要であるのに注意してください。 パンチ接続は、いつもわかりやすく、すなわち、決して翻訳されていません。 リモートオペレータ接続は一匹おおかみキャラクタを含む拡張EBCDIC/ASCIIマッピングを使用しますが、オペレータコマンドが限られた文字の組だけを必要とするので、これは重要ではありません。

      [4] Joel Winett, "_The_ EBCDIC Codes and their Mapping to ASCII",
          RFC #183 (NIC #7127), July 21, 1971.

「[4]ジョエルWinett」、__EBCDIC Codes、およびASCIIへの彼らのMapping、」、1971年7月21日のRFC#183(NIC#7127)。

Braden                                                          [Page 4]

RFC 338           EBCDIC/ASCII MAPPING FOR NETWORK RJE          May 1972

1972年5月にネットワークのためにRJEを写像するブレーデン[4ページ]RFC338EBCDIC/ASCII

      [5] Winett lists only 88 basic EBCDIC graphics, excluding the
          space which he regards as a control character.  This is a
          matter of taste, but we find it less confusing to include the
          space as a graphic.

[5] 彼が制御文字と見なすスペースを除いて、Winettは88の基本的なEBCDICグラフィックスだけを記載します。 これは好き好きですが、私たちは、グラフィックとしてスペースを含むのが、より少ない混乱させることであることがわかりました。

      [6] CCN recently received a new Teletype-replacement terminal.
          This machine has a bastardized graphic character set -- mostly
          ASCII, with a sprinkling of both (!) EBCDIC and TTY.

[6] CCNは最近、新しいテレタイプ交換端末を受けました。 ほとんどaがあるASCIIが両方を散在させて、このマシンで私生児と認定された図形文字を設定する、(!) EBCDICとTTY。

              +-------------------------------------+
              |                          Full ASCII |
              | a b ... z  | ` ^ { }  ~             |
              |                                     |
        +-----+-------------------------------------+--------------+
        |33/35|                                     |   AT&T TWX   |
        |     |          `   [   ]                  | (Mod 33/35   |
        |     |                                     |      tty)    |
 +------+-----+------+-----------------------+      |              |
 |Basic |     |      |                       |      |              |
 |EBCDIC|     |      |     <SP>              |      |              |
 |      |     |   "  |     A B ... Z         |      | <left arrow> |
 |      |     |   !  |     0 1 ... 9         |      |              |
 |      |     |      |     + - * / ( )       |      |  <up arrow>  |
 |      |     |      |     . , ' =           |      |              |
 |      |     |      |     $ &               |      |              |
 |      |     |      |   < > : ? % # @       |      |              |
 |      |     |      |                       |      |              |
 |      +-----+------+-----------------------+------+--------------+
 |            |      |                       |      |
 |            |      |        _              |      |
 |            |      |                       |      |
 |            +------+-----------------------+------+
 |                   |                       |
 |                   | PL/1   <bent bar> |   |
 |                   |  Set                  |
 |                   +-----------------------+
 |                           <cent sign>     |
 |  Basic EBCDIC                             |
 +-------------------------------------------+

+-------------------------------------+ | 完全なASCII| | b z…| ` ^ { } ~ | | | +-----+-------------------------------------+--------------+ |33/35| | AT&Tテレックス| | | ` [ ] | (モッズ風の33/35| | | | tty) | +------+-----+------+-----------------------+ | | |基本的| | | | | | |EBCDIC| | | <SP>。| | | | | | " | B… Z| | <左向きの矢>。| | | | ! | 0 1 ... 9 | | | | | | | + - * / ( ) | | 矢の>への<。| | | | | . , ' = | | | | | | | $ & | | | | | | | <>: ? % # @ | | | | | | | | | | | +-----+------+-----------------------+------+--------------+ | | | | | | | | _ | | | | | | | | +------+-----------------------+------+ | | | | | PL/1<折り曲げ筋>。| | | | セットします。| | +-----------------------+ | <セント記号>。| | 基本的なEBCDIC| +-------------------------------------------+

               Figure 1.  Character Sets Commonly Abused

図1。 一般的に乱用された文字コード

[This RFC is also available in .PS and .PDF format.]

[また、このRFCも.PSと.PDF形式で利用可能です。]

        [This RFC was put into machine readable form for entry]
    [into the online RFC archives by Helene Morin, Viagenie, 12/99]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ヘレーネのモーリン、ViagenieによるオンラインRFCアーカイブへの12/99]

Braden                                                          [Page 5]

RFC 338           EBCDIC/ASCII MAPPING FOR NETWORK RJE          May 1972

1972年5月にネットワークのためにRJEを写像するブレーデン[5ページ]RFC338EBCDIC/ASCII

Braden                                                          [Page 6]

ブレーデン[6ページ]