RFC1556 日本語訳

Network Working Group                                      H. Nussbacher
Request for Comments: 1556                      Israeli Inter-University
Category: Informational                                  Computer Center
                                                           December 1993

Nussbacherがコメントのために要求するワーキンググループH.をネットワークでつないでください: 1556年のイスラエルの相互大学カテゴリ: 情報のコンピュータセンター1993年12月

                Handling of Bi-directional Texts in MIME

MIMEにおける双方向のテキストの取り扱い

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document describes the format and syntax of the "direction"
   keyword to be used with bi-directional texts in MIME.

このドキュメントは、双方向のテキストと共にMIMEに使用されるために「方向」キーワードの形式と構文について説明します。

Description

記述

   The MIME standards (RFC 1521 and 1522) defined methods for
   transporting non-ASCII data via a standard RFC822 e-mail system.
   Specifically, the Content-type field allows for the inclusion of any
   ISO language such as Arabic (ISO-8859-6) or Hebrew (ISO-8859-8).  The
   problem is that the these two languages are read from right to left
   and can have bi-directional data such as mixed Hebrew and English on
   the same line.

MIME規格(RFC1521と1522)は標準のRFC822電子メール・システムで非ASCIIデータを輸送するためのメソッドを定義しました。 明確に、文書内容分野はアラビア語(ISO-8859-6)かヘブライ語(ISO-8859-8)などのどんなISO言語の包含も考慮します。 問題がそれである、これらの2つの言語で、左への権利から読み込まれて、混ぜられるような双方向のデータは同じ系列でヘブライでイギリスになる場合があります。

   Fortunately, ECMA (European Computer Manufacturers Association) has
   tackled this problem previously and has issued a technical report
   called "Handling of Bi-Directional Texts".  ECMA TR/53, as it is
   called, was used to update the Standard ECMA-48 which in turn was
   used as the basis for ISO/IEC 6429 which was adopted under a special
   "fast track procedure". It is based on this information that a new
   character set is being defined which will indicate that the bi-
   directional message is either encoded in implicit mode or explicit
   mode.  The default is visual mode which requires no special character
   set other than the standard ones previously defined by ISO-8859.

幸い、ECMA(欧州コンピューター製造者協会)は以前に、この問題に取り組んで、「双方向のテキストの取り扱い」と呼ばれる技術報告書を発行しました。 ECMA TR/53は、特別な「ファストトラック手順」の下で採用されたISO/IEC6429の基礎として順番に使用されたStandard ECMA-48をアップデートするのにいわゆる使用されました。 それは新しい文字集合が定義されているという両性愛者の方向のメッセージが暗黙のモードか明白なモードでコード化されるのを示すこの情報に基づいています。 デフォルトは以前にISO-8859によって定義された標準のもの以外に、設定されなかった特殊文字を全く必要とする視覚モードです。

   Examples of new character sets for bi-directionality support:

双方向性なサポートのための新しい文字集合に関する例:

            Content-type: text/plain; charset=ISO-8859-6-e
            Content-type: text/plain; charset=ISO-8859-6-i
            Content-type: text/plain; charset=ISO-8859-8-e
            Content-type: text/plain; charset=ISO-8859-8-i

文書内容: テキスト/平野。 charset=ISO-8859-6-e文書内容: テキスト/平野。 charset=ISO-8859-6-i文書内容: テキスト/平野。 charset=ISO-8859-8-e文書内容: テキスト/平野。 charset=ISO-8859-8-i

Nussbacher                                                      [Page 1]

RFC 1556                  Bi-directional Texts             December 1993

テキスト1993年12月の双方向のNussbacher[1ページ]RFC1556

   The "i" suffix refers to implicit mode and the "e" suffix refers to
   explicit mode.

「i」接尾語は暗黙のモードを示します、そして、「e」接尾語は明白なモードを示します。

Implicit

暗黙

   Implicit directionality is a presentation method in which the
   direction is determined by an algorithm according to the type of
   characters and their position relative to the adjacent characters and
   according to their primary direction.   The complete algorithm is
   quite complex and sites wishing to implement it should refer to the
   ECMA Technical Report for further details.

隣接しているキャラクタに比例した彼らのプライマリ方向に従って、暗黙の方向性はキャラクタのタイプと彼らの位置に従って方向がアルゴリズムで決定するプレゼンテーションメソッドです。 完全なアルゴリズムはかなり複雑です、そして、それを実装したがっているサイトはさらに詳しい明細についてはECMA Technical Reportについて言及するべきです。

Explicit

明白

   Explicit directionality is a presentation method in which the
   direction is explicitly defined by using control sequences which are
   interleaved within the text and are used for direction determination.
   This presentation method is also defined in ECMA TR/53, which defines
   three new control functions and updates 22 existing control functions
   in the ECMA-48 standard.

明白な方向性は方向が明らかにテキストの中ではさみ込まれて、方向決断に使用される制御配列を使用することによって定義されるプレゼンテーションメソッドです。 このプレゼンテーションメソッドは、また、ECMA TR/53で定義されて、ECMA-48規格で22の既存のコントロール機能をアップデートします。(ECMA TR/53は3つの新しいコントロール機能を定義します)。

Visual

視覚

   Visual directionality is a presentation method that displays text
   according to the primary display direction only, which is left to
   right.  All text is viewed in the same direction which is the primary
   display direction.  The displaying application is not aware of the
   contents direction and displays the text as if it were a uni-
   directional text.  The composing application needs to prepare the
   text in such a way that it will be displayed correctly.  No control
   characters or algorithms are used to determine how the data is to be
   displayed. This is the simplest of all methods and the default method
   for use with MIME encoded texts.

視覚方向性は右に残されるプライマリディスプレイ方向だけに従ってテキストを表示するプレゼンテーションメソッドです。 すべてのテキストがプライマリディスプレイ方向であるのと同じ方向として見られます。 表示アプリケーションは、コンテンツ方向を意識していなくて、まるでそれがuniの方向のテキストであるかのようにテキストを表示します。 構成アプリケーションは、正しくそれを表示するような方法でテキストを準備する必要があります。 どんな制御文字もアルゴリズムも、表示するデータがことである方法を決定するのに使用されません。 すべてのメソッドでこれは最も簡単です、そして、MIMEとの使用のためのデフォルトメソッドはテキストをコード化しました。

References

参照

   [ECMA TR/53] Handling of Bi-Directional Texts, European Computer
                Manufacturers Association, 114 Rue du Rhone, CH-1204,
                Geneva, Switzerland, June 1992.

1992年6月のBi方向のTexts、欧州コンピューター製造者協会114Rue du CH-1204、ジュネーブローヌ(スイス)の[ECMA TR/53]取り扱い。

   [ISO-6429]   Information Technology - Control Functions for Coded
                Character Sets, 3rd edition, December 15, 1992.

[ISO-6429]情報Technology--1992年12月15日にCoded文字コード、3番目の版のためにFunctionsを制御してください。

   [ISO-8859]   Information Processing -- 8-bit Single-Byte Coded
                Graphic Character Sets, Part 6: Arabic alphabet, ISO
                8859-6, 1988.

[ISO-8859] 情報処理--8ビットの単一のバイトは図形文字セット、パート6をコード化しました: アラビア文字、ISO8859-6、1988。

Nussbacher                                                      [Page 2]

RFC 1556                  Bi-directional Texts             December 1993

テキスト1993年12月の双方向のNussbacher[2ページ]RFC1556

   [ISO-8859]   Information Processing -- 8-bit Single-Byte Coded
                Graphic Character Sets, Part 8: Latin/Hebrew alphabet,
                ISO 8859-8, 1988.

[ISO-8859] 情報処理--8ビットの単一のバイトは図形文字セット、パート8をコード化しました: ラテン語の、または、ヘブライのアルファベット、ISO8859-8、1988。

   [RFC822]     Crocker, D., "Standard for the Format of ARPA Internet
                Text Messages", STD 11, RFC 822, UDEL, August 1982.

[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。

   [RFC1521]    Borenstein N., and N. Freed, "MIME (Multipurpose
                Internet Mail Extensions) Part One: Mechanisms for
                Specifying and Describing the Format of Internet
                Message Bodies", Bellcore, Innosoft, September 1993.

解放された[RFC1521]Borenstein N.、およびN.、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、Bellcore、Innosoft、1993年9月。

   [RFC1522]    Moore K., "MIME Part Two: Message Header Extensions for
                Non-ASCII Text", University of Tennessee,
                September 1993.

[RFC1522]ムーアK.、「パートTwoをまねてください」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、テネシー大学、1993年9月。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's Address

作者のアドレス

   Hank Nussbacher
   Computer Center
   Tel Aviv University
   Ramat Aviv
   Israel

ハンクNussbacherコンピュータセンターテルアビブ大学Ramat Avivイスラエル

   Fax: +972 3 6409118
   Phone: +972 3 6408309
   EMail: hank@vm.tau.ac.il

Fax: +972 3 6409118は以下に電話をします。 +972 3 6408309 メール: hank@vm.tau.ac.il

Nussbacher                                                      [Page 3]

Nussbacher[3ページ]