Article View: fj.sci.lang
Article #400Re: 句読点
From: NAKAMURA Hajime
Date: Sat, 23 May 1998 00:00
Date: Sat, 23 May 1998 00:00
103 lines
6131 bytes
6131 bytes
おはようございます。中村 元と申します。
In article <3565A0E0.C2D9CB4D@softweb.ne.jp>,
Fujii Toshinori 様 <tfujii@softweb.ne.jp> wrote:
> 自然言語でどうかが決まって初めてコンピュータの文字
> コードの話ができるのです。
全くその通りだと思います。
Nakamura worte:
> > Fujii殿も以前、「でも本当に誤用なのか」と述べられていますが、
> > 今はどのように判断なさっていますか?
>
> 今のところ誤用と思っています。
> 日本語としての読点と comma の関係を明確に示す資料をまだ探
> せずちょっとぐらついていますが。
「日本語としての読点と comma の関係を明確に示す資料」について
ですが、計算機テキストの問題とからませないで述べているもので
かまわないということであれば、文化庁や国立国語研究所が発行して
いる日本語の表記法の参考書が一般書店(政府刊行物を扱っている
書店)でも手に入ると思います。また、用字用語辞典や表記辞典など
にも記述があるでしょう。
> コンピューター処理でも同じ読点として存在するなら文字コード
> で分けるのでなくそれ以外の方法で形を変えるべきと思っています。
> たとえば縦書きと横書きで句読点や括弧の形が変わるのは普通に
> 行われている事です。かな漢字変換の設定よりワードプロセッサや
> できればOSレベルのテキスト表記の設定で対応するべきと思ってい
> ます。
これは、同じ文字コードが割り当てられたものをMachine(OS)の
方で縦書き用と横書き用に、さらに字形の異なった符号に表示・編集
しわけられるようにするということでしょうか。
例えば、「、」は横書き用の「てん」ですが、縦書きで「てん」を
使う際には、文字コードを変えて縦書き用の「�」を用いると思うの
ですが、これを同一の文字コードで(「文字コードをわけずに」と
いうのはこの意味ですか?)できるソフトまたはOSというものは
実際かなり出回っているものなのでしょうか? 私は横書き用と
縦書き用の符号をソフトの方で自動的に文字コードを切り替える
ことで実現しているのだとばかり思っていたのですが . . .
#グラフィック・ソフトは除きます。
「コンピューター処理」に関しては私は門外漢のため、よく分からない
のですが、横書きでの「句読点」の選択が縦書きのようには安定して
いない現状では、どの句読点をUserが採用するかという問題もあり、
なかなか一筋縄ではいかないのではないかと思うのですが。
それ故、コンピューターのInput Methodでは複数の「句読点」の組み
合わせの選択が標準機能としてあり、どの組み合わせを選ぶかはUser
にまかせるという方法をとっているのではないかと思います。
#ま、コンピューター関連の技術の進歩はめざましいものが
ありますから . . . 将来的には実現可能なのでしょうか?
ところで、先日、本屋で「JIS X 0208:1997」の資料を見たのです
が、符号(記号)表が掲載されているページで、例えば、「、」が
「読点」で「,」が「コンマ」という名称は規定ではない、という
ように書かれているのを見ました。広く世間で一般に行われている
名称をそれに付記したのであるととれる含みのある表現でした。
ということであれば、そこにある名称にとらわれることなく、
「.」「,」という文字コードのものを日本語文の横書きの句読点
として用いても何ら支障はないと解釈できるのではいかと思うの
ですが . . .
この解釈がもし正しければ、日本語Input Methodで「.」や「,」
という計算機テキストを「句読点」の選択肢の中に入れていたと
しても「誤用」ではないということになるかと思います。
さらに、「.」や「,」という文字コードのものがいったい何の
目的でJIS規格において採用されたのだろうかと考えてみるならば、
やはりこれは、日本語文で用いることを(あるいは、日本語文でも
用いることを)前提にしていたのではないかと思うのです。
というのは、これって2バイトですよね? そもそも「.」や「,」
は1バイトしか表示できない環境下では表示不可能ですよね。
一方、1バイトの"." や "," も存在しているわけです。
すると、何のためにそれらは採用されたのか? まさか、中国語や
ハングルを表記するためにわざわざ選んだとも思えない。また、
2バイトで欧文や日本語ローマ字文を書き表すためのみにわざわざ
選んだとも思えない。
ということであれば、それらはやはり漢字仮名交じりの日本語文
で(・でも)用いることを意図して選ばれたものなのではないか?
と、かように思う次第なのですが、いかがでしょうか?
加えて、日本語の文字・表記の史的変遷ということを考えるならば、
計算機が全ての表記手段に先行して存在していたということはあり
得ない。つまり、計算機テキストはそれまであった既存の手書きや
印刷における日本語の文字・表記法をかなり意識して、それを計算
機テキストでも実現できるようにしたと考えるのが自然なのでは
あるまいか。(少なくとも、規格を作る際の原点としてはあったの
ではないか)
そのJISの規格作りに国語学(日本語学)関係者が林大氏一人しか
かかわっていなかったとしても(今でも一人だけなのでしょうか)、
JCS委員の方々(でしたっけ?)が全くそれまでの日本語の文字・
表記法から遊離した形でその規格を作ったとはどうしても私には
思えないのです。
草 々
=====================================
中村 元 NAKAMURA Hajime
Mailto: jslnet@anet.ne.jp
=====================================
Technical Details
Message-ID:
<jslnet-2305980633220001@pppr02-109.big.or.jp>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<jslnet-1405981245100001@pppr02-112.big.or.jp> <355B1A7C.B2B7DC6F@softweb.ne.jp> <jslnet-1505980639130001@pppr02-132.big.or.jp> <355F2279.6AB4AB2E@softweb.ne.jp> <jslnet-2105980556160001@pppr01-052.big.or.jp> <3565A0E0.C2D9CB4D@softweb.ne.jp>Show Full Headers
Complete Article Headers
X-Google-Language: Japanese,JIS X-Google-Thread: ffb0e,88f75961563fc0de X-Google-Attributes: gidffb0e,public X-Google-Thread: febec,cc97e7cf1ff3ff11 X-Google-Attributes: gidfebec,public From: jslnet@anet.ne.jp (NAKAMURA Hajime) Subject: Re: 句読点 Date: 1998/05/23 Message-ID: <jslnet-2305980633220001@pppr02-109.big.or.jp> X-Deja-AN: 355683356 References: <jslnet-1405981245100001@pppr02-112.big.or.jp> <355B1A7C.B2B7DC6F@softweb.ne.jp> <jslnet-1505980639130001@pppr02-132.big.or.jp> <355F2279.6AB4AB2E@softweb.ne.jp> <jslnet-2105980556160001@pppr01-052.big.or.jp> <3565A0E0.C2D9CB4D@softweb.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Organization: BIGNET Newsgroups: fj.sci.lang,fj.comp.text