Shift-JIS with JIS X 0212-1990
Koichi Yasuoka
補助漢字フリークの安岡です。sainet.or.jpの小野さんは書きました。
>ＲＯＭやＲＡＭや外部記憶装置が貧弱（高価）であった時代に、
>私たちにとって非常に助けになったものと思います。
>シフトＪＩＳを作られたかたに感謝致します。
残念ながら私は感謝できません。と言うのも小野さん自身も書かれて
いますが
>現在において、シフトＪＩＳが有効かと言うと疑問です。
>新しい標準が必要になって来ているのだと思います。
そういう「新しい標準」の一部となるはずだったJIS X 0212-1990（補助
漢字）を、Shift-JISはうまくサポートできなかったからです。同じよう
に作られていた「日本語EUC」や、ちょっと別口の「ISO-2022-JP」は、
この６年の間に難なくサポートしてくれているのに…。
===========================================================================
JIS X 0208で書けない 安岡孝一＠京都大学大型計算機センター
日本の地名ありませんか？ yas...@kudpc.kyoto-u.ac.jp
===========================================================================
Sadao Ono
In article <5102nv$1...@kudpc.kudpc.kyoto-u.ac.jp>,
yas...@kudpc.kyoto-u.ac.jp says...
>
> 補助漢字フリークの安岡です。sainet.or.jpの小野さんは書きました。
>
補助漢字や、その他の漢字や、中国の漢字や、ハングル文字や
その他の文字までＰＣで表示できれば良いですね。
Netscape for Windows では ○の中にc や○の中にR の文字は、
日本語表示にしていると「化けて」しまいます。
>
>>ＲＯＭやＲＡＭや外部記憶装置が貧弱（高価）であった時代に、
>>私たちにとって非常に助けになったものと思います。
>>シフトＪＩＳを作られたかたに感謝致します。
>
> 残念ながら私は感謝できません。と言うのも小野さん自身も書かれて
>いますが
>
>>現在において、シフトＪＩＳが有効かと言うと疑問です。
>>新しい標準が必要になって来ているのだと思います。
>
>そういう「新しい標準」の一部となるはずだったJIS X 0212-1990（補助
>漢字）を、Shift-JISはうまくサポートできなかったからです。同じよう
>に作られていた「日本語EUC」や、ちょっと別口の「ISO-2022-JP」は、
>この６年の間に難なくサポートしてくれているのに…。
>
全角日本語を無理やり押し込めてしまったものの様ですから、
補助漢字への拡張などできないのでしょうね。
シフトＪＩＳは現在もパソコン上で活躍しているのですから、
それなりに評価したいと思います。
-
ある「方法」が新しい標準には対応できないので、
新しい標準の検討対象から外す という意見には同意できます。
ある「方法」が新しい標準には対応できないので、
それが「評価に値しない」とか「くだらない」という評論が
あったとすれば同意しかねます。
恐らく、安岡さんは「シフトＪＩＳでは今の（将来の）要求に
対応できない」と言うことをおっしゃられたのだと思います。
--
シフトＪＩＳ（の開発者）に感謝するかしないかについては、
個人的趣向の問題でもあり、安岡さんと意見を交わしても
平行線になってしまうかと思います。
--
ISO-2022-JP や 日本語EUC については不勉強ですので、
何かのおり（netnews 等で) ご教授頂ければ幸いです。
--
01 05 10 15 20 25 30 35
http://www.sainet.or.jp/~ono/
Sadao Ono ( 小野 )
o...@sainet.or.jp
KANOU Hiroki
狩野＠わせだです。私も補助漢字に肩入れしてる口なんで、一言。
In article <DxHDL...@sainet.or.jp> o...@sainet.or.jp (Sadao Ono) writes:
>補助漢字や、その他の漢字や、中国の漢字や、ハングル文字や
>その他の文字までＰＣで表示できれば良いですね。
私が使っている PC ではちゃんと表示できてますが… X の上ですけど。
＃「その他の漢字」って、何ですか？
私も「できればいい」ことには異存がありません。より詳しくは、
「多くの文字集合が共存できるようなきちんとしたエンコーディングを
皆が共通して使うようになればいいですね」と言いたい所ですが。
>Netscape for Windows では ○の中にc や○の中にR の文字は、
>日本語表示にしていると「化けて」しまいます。
これは、どの文字コードを使って書かれたかによりますね。
ISO2022-JP-2 などで書かれていて、補助漢字の 2 区 77 点や 78 点の
著作権表示記号や登録商標記号を見られないとするならば、悲しむべき
は Windows の環境ですね。
でも、「主にシフト JIS で書かれた文書をブラウズする」という前提が
置かれているブラウザで、ISO8859-1 で書かれた文書をブラウズすれば、
それらの文字が「ゥ」や「ョ」に見えるのは当然でしょう？ 自動判別の
努力も、一意に決定できないケースの方がはるかに多いと思うから不毛
（山勘判別はさらに輪をかけて不毛）ですよね。
＃で、小野さんはそれらをどう区別したいわけですか？
>In article <5102nv$1...@kudpc.kudpc.kyoto-u.ac.jp>,
> yas...@kudpc.kyoto-u.ac.jp says...
>>>シフトＪＩＳを作られたかたに感謝致します。
>>
>> 残念ながら私は感謝できません。と言うのも小野さん自身も書かれて
>>いますが
>>
>>>現在において、シフトＪＩＳが有効かと言うと疑問です。
>>>新しい標準が必要になって来ているのだと思います。
>>
>>そういう「新しい標準」の一部となるはずだったJIS X 0212-1990（補助
>>漢字）を、Shift-JISはうまくサポートできなかったからです。同じよう
>>に作られていた「日本語EUC」や、ちょっと別口の「ISO-2022-JP」は、
>>この６年の間に難なくサポートしてくれているのに…。
私には、「作った人」より、その数年後に「サポートしなかった人々」
への「感謝のできなさ」の方をずっと強く感じます。
>シフトＪＩＳは、６４ｋバイト空間に、半角英数字，半角カタカナ，
>全角日本語を無理やり押し込めてしまったものの様ですから、
>補助漢字への拡張などできないのでしょうね。
拡張案がなかったわけじゃないですよ。
ftp://ftp.mei.co.jp/free/doc/misc/JISX0212.interim-report.gz
をご覧になればわかると思います。
これは、5 年半前（ああ、私がまだ高校生だった頃か）
>From: ki...@green.lime.juice.or.jp (Akio Kido)
>Newsgroups: fj.kanji
>Subject: JIS X0212 Study Group Interim report ( Revised ) (In Japanese/Kanji)
>Keywords: JIS X0212, Coded Character Set
>Message-ID: <2...@green.lime.juice.or.jp>
>Date: 7 Feb 91 05:14:00 GMT
> ＪＩＳ Ｘ０２１２ 研究会 中間報告書
>
> － 日本語文字符号の拡張法の検討 －
という名前でこの NG に投稿されていたようです。
＃JAISTの fj archive は 92 年から(fj.kanji の場合、8 月以降)
＃の記事しかないんですが、もっと古い記事、どこかにありませんか？
ここに出てくる「シフト JIS 拡張案」は結構うまいアイディアだと
思うんですが。
今までのシフト JIS として正しいコードはそのままにし、
他の文字集合は 4 バイトで表すという考えです。
1 バイト目に現在のシフト JIS で未使用のバイト値を使い、
2 バイト目で文字集合を判別し、
続く 2 バイトで文字を表現する。
というやり方です。「第三、第四水準」を作るなら、シフト JIS では
漢字 = 2 バイトという前提をやめてこのエンコーディング方式を採用
してほしいと願っています。
日本語 EUC の方は、この文書にある「単純拡張案」が採用されたので、
拡張に伴う技術的困難に大きな差があったとは思えないんですが。
＃ところで、不勉強をさらけ出すようで恥ずかしいのですが、
＃ EUC や 日本語 EUC の最終的根拠となる文書は何ですか？
過去の（ということは、現在の）シフト JIS との整合性をかなり良く
保っていながら、どうして採用されるに至らなかったか、理由をご存じの
方に伺いたいものです。
>シフトＪＩＳは現在もパソコン上で活躍しているのですから、
>それなりに評価したいと思います。
という意見には賛成できかねます。何の拡張の手も加えずに、現在も
活躍していること自体を評価できません。
>恐らく、安岡さんは「シフトＪＩＳでは今の（将来の）要求に
>対応できない」と言うことをおっしゃられたのだと思います。
他にも、
8 ビット目を立てる他のエンコーディング（世界的に見れば
もっとも広く用いられているのは ISO8859-1 です）と区別がつかない
という問題点（これは日本語 EUC も同じですが）とか、
漢字の 1 バイト目が C1 と重なったり、2 バイト目に MSB の立って
いないバイト値が来たりするため、ASCII を前提としたソフトを移植
するのに手間がかかる（EUC なら 8 bit through にするだけで、
データを通すようになる場合がほとんどですが）
とかいう問題点もあると思うのですが。
＃JIS X 0212 研究会のかつての活動に興味があります。上記の中間
＃報告の時点で、24 ドットフォントの作成を開始したそうですが、
＃完成したと言う話は聞いたことがありません。
＃データが一部でも残っているなら何とか完成させたいですよね。
--
キ守里予
TANAKA Goh
>>>>> "守岡" == 守岡 知彦 / MORIOKA Tomohiko <mor...@jaist.ac.jp> writes:
守岡> （そんだけ用意しとかないと困る漢字 ML が普通じゃな
守岡> いという話もあるが(^_^;）以上、茶々でした。
漢字 ML のメールは表示できない文字が一杯あります (^_^;
＃それ以前に内容がよくわからんかったりする… (^_^;;;;;
守岡> iso-2022-jp-2 を Windows とかの内部 code に mapping して、補助漢字の
守岡> 記号や KS C5601 の記号やローマ数字、丸付き数字とかを表示でき、いわゆる
守岡> 『機種依存文字』を iso-2022-jp-2 とかの標準に従って encode すれば良い
守岡> と思うのですがそういう MUA は無いんでしょうか？そんなに難しいことじゃ
守岡> ないと思うのですが。
＃キャラクタについての知識がないため、馬鹿な質問かもしれない
＃は思いつつ…。
こういう実装を作ろうと思うのですが、例えば丸つき数字など、具
体的にどのようにエンコードすればよいのでしょうか？
以前から疑問に思っていたのですが、ESC ( I で指示される 1 バ
イト片仮名は ISO-2022-JP-2 と宣言で適当なのでしょうか？
＃ 1 バイト片仮名の是非とか、そういった ESC シーケンスを理解
＃できない UA があることなどは、とりあえず問題にしないつもり
＃です。
参照するべき文書や本などがあれば、あわせて御紹介ください。
＃ RFC1544 をもう一度よく読みなさいというのでも構いません (^_^;
--
日本アイ・ビー・エム（株） ワークグループ開発 田中 剛
E-mail: g...@yamato.ibm.co.jp
KATAYAMA Yoshio
片山＠ＰＦＵです。
In article <527ah7$p...@daphnis.yamato.ibm.com>,
TANAKA Goh <g...@yamato.ibm.co.jp> writes:
>以前から疑問に思っていたのですが、ESC ( I で指示される 1 バ
>イト片仮名は ISO-2022-JP-2 と宣言で適当なのでしょうか？
「ISO-2022-JP-2 と宣言で適当」の意味が分からないので答えになって
いないかもしれませんが、ESC ( I は ISO-2022-JP-2 で認められてい
るエスケープシーケンスではありません。
RFC 1554 より:
| The following table gives the escape sequences and the character sets
| used in "ISO-2022-JP-2" messages. The reg# is the registration number
| in ISO's registry [ISOREG].
|
| 94 character sets
| reg# character set ESC sequence designated to
| ------------------------------------------------------------------
| 6 ASCII ESC 2/8 4/2 ESC ( B G0
| 42 JIS X 0208-1978 ESC 2/4 4/0 ESC $ @ G0
| 87 JIS X 0208-1983 ESC 2/4 4/2 ESC $ B G0
| 14 JIS X 0201-Roman ESC 2/8 4/10 ESC ( J G0
| 58 GB2312-1980 ESC 2/4 4/1 ESC $ A G0
| 149 KSC5601-1987 ESC 2/4 2/8 4/3 ESC $ ( C G0
| 159 JIS X 0212-1990 ESC 2/4 2/8 4/4 ESC $ ( D G0
|
| 96 character sets
| reg# character set ESC sequence designated to
| ------------------------------------------------------------------
| 100 ISO8859-1 ESC 2/14 4/1 ESC . A G2
| 126 ISO8859-7(Greek) ESC 2/14 4/6 ESC . F G2
>＃ RFC1544 をもう一度よく読みなさいというのでも構いません (^_^;
RFC 1554 の typo かな？
--
片山＠ＰＦＵ
TANAKA Goh
fj.net.mime にもクロスポストします。
>>>>> "片山" == KATAYAMA Yoshio <ka...@pfu.co.jp> writes:
片山> 「ISO-2022-JP-2 と宣言で適当」の意味が分からないので答えになって
片山> いないかもしれませんが、ESC ( I は ISO-2022-JP-2 で認められてい
片山> るエスケープシーケンスではありません。
はい (^_^;
最近、いわゆる半角片仮名を含んだ記事が投稿されることが多いの
ですが、ESC ( I という ESC シーケンスを含むメッセージは MIME
の charset parameter に何を指定するのが適当なのかというのが
僕の疑問です。
片山> RFC 1554 の typo かな？
typo です。
KATAYAMA Yoshio
片山＠ＰＦＵです。
In article <s1cranq...@jaist.ac.jp>,
mor...@jaist.ac.jp (守岡 知彦/ MORIOKA Tomohiko) writes:
田中剛> 漢字 ML のメールは表示できない文字が一杯あります (^_^;
> 補助漢字と CNS と GB の font を install しとけば取りあえず漢字 ML は
>OK じゃないでしょうか？(^_^)
この“漢字 ML”とは、どんな ML なんでしょうか。よろしければ、紹
介して戴きたいのですが。
--
片山＠ＰＦＵ
NISHIJIMA Takanori -- 西島孝徳
にしじま＠キヤノンです。
On 25 Sep 1996 07:17:40 GMT,
about the topic "Re: Shift-JIS with JIS X 0212-1990",
TANAKA Goh <g...@yamato.ibm.co.jp> wrote:
> 最近、いわゆる半角片仮名を含んだ記事が投稿されることが多いの
> ですが、ESC ( I という ESC シーケンスを含むメッセージは MIME
> の charset parameter に何を指定するのが適当なのかというのが
> 僕の疑問です。
この疑問なら、ftp.isi.edu:/in-notes/iana の下のどこかにある
character-sets というファイルを覗くと参考になります。
このファイル、Character Sets と言いながらエンコードの方法も
書いてあったりするわけですが、これ(タイムスタンプは96/5/16)に
よれば
JIS_Encoding
という、「どこが character set なんや」と言いたくなる "character
set" があることがわかります。これは、
JIS X 0202-1991 のスキームにしたがい、ISO-2022 エスケープ
シーケンスでコードセットを切り換える
とだけ記述されている "character set" ですので、「ESC 2/8 4/9 で
『いわゆる半角かな』を指示して表現する」ことは JIS_Encoding に
合致すると思います。もしかしたら、「いわゆる半角かな」を SO で
指示して表現するのもこれなら可能なのかもしれません。
わたしはこのような「どこまで実装してもきりがない」ような
"character set" が(いまさら)使用されることは歓迎しませんので、
「適当かどうか」の判断は保留しますけどね。
# 頭の悪いソフトウェアベンダはこの瞬間、
# 「ラッキー、バージョンアップで金を巻き上げるチャンス」
# とかなんとか思ったかもしれません。
# (↑もちろん皮肉ですよ)
--
“「半角かな」をInternetに持ち込まんとする動きに反対する会会長(意味不明)”
西島 孝徳(NISHIJIMA, Takanori) キヤノン(株)・商品開発本部DOプロジェクト
E-mail: rac...@cpdc.canon.co.jp
or rac...@studio-racsho.shibuya.tokyo.jp
Koichi Yasuoka
「française」をnetscapeで見たら「fran軋ise」に化けてし
まって、何だか悲しくなってしまった安岡です。「ISO8859-1ベタ書き」
ならまだわかるけど「＆表記」すら化けちゃうんじゃなぁ…。
狩野さん>ここに出てくる「シフト JIS 拡張案」は結構うまいアイディアだと
狩野さん>思うんですが。
アイデアとしてはね。でも「バイト数＝表示幅」という謎の信仰を
持つ方々には、とても理解できないアイデアだったんでしょう。
狩野さん>日本語 EUC の方は、この文書にある「単純拡張案」が採用されたので、
狩野さん>拡張に伴う技術的困難に大きな差があったとは思えないんですが。
日本語EUCの方はその黎明期に「NEC版EUC」の「A9xx半角カナ」の
来襲を受けたので、割と早くに「8Exx半角カナ」というまだマトモな
考えが現れて、結果的に作り手が「バイト数＝表示幅」信仰に染まら
ずにすんでいたのではないかと。これも偏った意見ですが。
守岡さん>とはいえ、この文書にあるように「拡張によりシフトＪＩＳやＥＵＣの寿命
守岡さん>をむやみに延ばしてはならない！！！」ということがいえるとおもいます。
「データの寿命」とかいういかにも「パソコン屋」の発想からする
と、逆に延命せざるを得ないような気もします。JIS X 0213も、そも
そもGBKとかBig5に対抗して、Shift-JISを拡張するために考えられて
いる規格ですしね。「パソコン屋」がJIS X 0212-1990を使いたくな
いのなら、それもいたしかたないかもしれません。
=======================================================================
安岡孝一＠京都大学大型計算機センター yas...@kudpc.kyoto-u.ac.jp
http://www.yajima.kuis.kyoto-u.ac.jp/staffs/yasuoka
=======================================================================
個人的にはまだ「&JJxxxx;表記」に望みを繋いでたりしますけど…。
Koichi Yasuoka
「バイト数＝表示幅」っていう謎の信仰に染まる人が、どうしてこう多
いのか理解に苦しむ安岡です。Subjectを変えると同時に、Followup-Toを
fj.kanjiのみにしました。
日立の仙石さんは書きました。
> nｏtscｏpe と書いた物と notscope と書いた物が、異なって見える
> と言う様な「決まり（規格）」があるのですか ?
> その様なきめごとがもしあるのなら、是非ポインタを教えて下さい。端末のフォ
>ントを選ぶ時の参考にさせて頂きます。
これに対しsainet.or.jpの小野さんは書きました。
>規格で言うとＪＩＳ－Ｘ０２０８です。 JIS-X0208 には、JIS-X0201 と
>JIS-X0202(ISO-2022) が引用として含まれています。
はあ…。で、JIS X 0208-1990のどこに「Ａ」と「A」が異なって見える
べきということが書かれてるんでしょうか。
> 注）以上は事実ですが、JIS-X0202 では、US-ASCII と JIS-X0208 を
> 同時に扱う様な物は規定されていない様に見えます。
あの、それ以前にJIS X 0202-1991には、どの文字集合とどの文字集合を
同時に使うべきかなんて、そもそも全く書かれてないんですけど。そうい
うのが書かれてるのは、たとえばRFC 1468なんじゃないですか？
>内部的に違ったコードを（入力可能で）視覚的に「同じに見せる」
>端末装置は使い勝手が悪いのではないのでしょうか？
そうですか？ 私の端末ではJIS X 0201ローマ字の「A」とUS-ASCIIの「A」
は同じに見えますけど、そんなに使い勝手は悪くないですよ。それにJIS C
6226-1978の「Ａ」とJIS X 0208-1983の「Ａ」も同じに見えますけど、その
方が便利な気がします。あ、もちろんJIS C 6226-1978の「醗」とJIS X 0208-
1983の「醗」は違って見えますけどね。
Noboru Miwa
Koichi Yasuoka wrote:
> 「バイト数＝表示幅」っていう謎の信仰に染まる人が、どうしてこう多
> いのか理解に苦しむ安岡です。
パソコンではそういうのが多いからじゃないかな。
（必ずしもバイト数＝表示幅ではないけどね）
# そういうものだと思い込ませる魔力があったりして（謎）
--
--------------------------------
Mailto:Nobor...@mb1.nkc.co.jp
--------------------------------
Tachikawa Yutaka
<e62919y...@venezia.pure.cpdc.canon.co.jp>の記事において
rac...@cpdc.canon.co.jpさんは書きました。
>> この疑問なら、ftp.isi.edu:/in-notes/iana の下のどこかにある
>> character-sets というファイルを覗くと参考になります。
ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets
をつい最近教えていただきました。
>> わたしはこのような「どこまで実装してもきりがない」ような
>> "character set" が(いまさら)使用されることは歓迎しませんので、
>> 「適当かどうか」の判断は保留しますけどね。
ISO-2022-JPも随分変な限定をしてるだけのcharsetとはいいにくい
代物だと感じていたので、他の選択肢もたくさんあることがわかった
点で私はほっとしましたから、感じ方は逆のようですね。
# NAPLPSもcharsetの方がしっくりくるな、確かに
-----
Tachikawa Yutaka (yukkun)
yut...@cc.rim.or.jp
Sadao Ono
In article <52fg06$p...@kudpc.kudpc.kyoto-u.ac.jp>, yas...@kudpc.kyoto-u.ac.jp
says...
>
> あの、それ以前にJIS X 0202-1991には、どの文字集合とどの文字集合を
>同時に使うべきかなんて、そもそも全く書かれてないんですけど。そうい
>うのが書かれてるのは、たとえばRFC 1468なんじゃないですか？
>
-----------------
(a) ISO 646 の版。
[参考] JIS X 0202 のローマ文字用７単位符号．．．
(b) ISO 646 と互換性を持った変形。すなわち．．． 略 ．．．
[参考] JIS X 0202 のローマ文字・片仮名用７単位符号．．．
(c) 6.1.1 で規定した構成を持つ他の７単位符号。 ．．．．．
[参考] JIS X 0202 の制御文字集合及び JIS X 0208 を利用するもの
．．．
-----------------
の記述があります。私にはこの (c) の [参考] が理解出来ません。
6.1.1 には、３２個の制御文字と９４（９６）個の図形文字について
記述されています。ところが[参考]には制御文字しか謳っていません。
>
>>内部的に違ったコードを（入力可能で）視覚的に「同じに見せる」
>>端末装置は使い勝手が悪いのではないのでしょうか？
>
> そうですか？ 私の端末ではJIS X 0201ローマ字の「A」とUS-ASCIIの「A」
>は同じに見えますけど、そんなに使い勝手は悪くないですよ。それにJIS C
>6226-1978の「Ａ」とJIS X 0208-1983の「Ａ」も同じに見えますけど、その
>方が便利な気がします。あ、もちろんJIS C 6226-1978の「醗」とJIS X 0208-
>1983の「醗」は違って見えますけどね。
>
0x41 （JIS の記述では 4/1)ですから全く同じに見える筈です。
JISC 6226-1978の「Ａ」とJIS X 0208-1990の「Ａ」もどちらも
文字コードは0x23,0x41( 区点では ３－３３ ）ですから同じです。
US-ASCIIの [ 0x41 ] と JIS X 0208 の [ 0x23,0x41 ] が同じに見えては、
都合が悪いと言う事です。
「醗」については：
表示する字形を変えれば違って見えますよね。
明朝で表示した「あ」とゴシックで表示した「あ」が違って
見えるのと似たような事ではありませんか？
あ、ご存じでいらっしゃるようですね。失礼致しました
-
--
Koichi Yasuoka
Subjectを変えると同時にFollowup-Toをfj.kanjiだけにしました。
京都大学大型計算機センターの安岡です。
fuka.info.waseda.ac.jpの小野康一さんは書きました。
>JIS X 0201-1976片仮名の使用を禁止したのは、
>コード系がネットワーク透過にならない危険性からということ
>よりも、JIS X 0201とJIS X 0208とで重複する文字は一方しか
>使用しないようにするという方針があったのだと推測できます。
これに対し、cc.rim.or.jpのTachikawa Yutakaさんは書きました。
>この方針自体に異議はないのですが、そういう勧告がISOであった
>とかそういう話はありますでしょうか。
新しいISO 2022では、G0～G3中に「同じ文字」が指示されている
場合、G番号の小さい方の文字を優先して使うことが規定されてい
ます。JIS X 0202も次の改正でこれに追随する予定です。
別スレッドで、jaist.ac.jpの守岡さん（あ、漢字MLに関してPFU
の片山さんからfj.kanjiに質問があったような気がするんですけど、
管理者の守岡さんが宣伝してくれないんですか？）は書きました。
>＃＃ ところで、ISO 2022 の重複符号化禁止の原則は同じ文字を含む複数の文
>＃＃ 字集合を複数の G-buffer に指示して使った場合の規定で、iso-2022-jp
>＃＃ のような場合では成立しないと思うのですがいかがでしょうか？
確かに。じゃISO-2022-JP-2のISO 8859-1やISO 8859-7は、どう思
います？ 個人的にはあれもやめちゃって、次のJIS X 0213-1998が
発表されたら
G0 US-ASCII
G1 JIS X 0213-1998 plane 1（第１～３水準）
G2 JIS X 0213-1998 plane 2（第４水準）
のSI/SOとSS2で、ISO-2022-JP-3って名前でRFCを書きたいと思って
るんですけど。もちろん
G0 US-ASCII
G1 JIS X 0213-1998 plane 1（第１～３水準）
GB 2312-80
ISO-IR-165
GB/T 12345-90
CNS 11643-1992 plane 1
KS C 5601-1992
G2 JIS X 0213-1998 plane 2（第４水準）
GB 7589-87
GB/T 13131-9x
CNS 11643-1992 plane 2
KS C 5657-1991
G3 JIS X 0212-1990
GB 7590-87
GB/T 13132-9x
CNS 11643-1992 plane 3
CNS 11643-1992 plane 4
CNS 11643-1992 plane 5
CNS 11643-1992 plane 6
CNS 11643-1992 plane 7
（その他の漢字規格）
っていうISO-2022-CJKも付けて。
=======================================================================
安岡孝一＠京都大学大型計算機センター yas...@kudpc.kyoto-u.ac.jp
http://www.yajima.kuis.kyoto-u.ac.jp/staffs/yasuoka
=======================================================================
GB/T 13131とGB/T 13132は、まだドラフトなんでしょうか？
Koichi Yasuoka
やっぱりShift-JISって、その成立時点ですでに「バイト数＝文字幅」
という謎の信仰に依っていたのね、の安岡です。だから拡張なんてそも
そも無理なのかなぁ…。
「私>」は私の記事、「小野>」はo...@sainet.or.jpさんの記事です。
私> あの、それ以前にJIS X 0202-1991には、どの文字集合とどの文字集合を
私>同時に使うべきかなんて、そもそも全く書かれてないんですけど。そうい
私>うのが書かれてるのは、たとえばRFC 1468なんじゃないですか？
小野>JIS X 0202-1991 の ６．１．５ 互換性 の項に、３つの水準として、
（JIS X 0201とJIS X 0202を間違えているので、ばっさりと略）
小野>の記述があります。私にはこの (c) の [参考] が理解出来ません。
はあ？ どこ見てるんですか？ 6.1.5のところは７単位符号の符号拡張
のレベルでしょ？ で、何でもありの(c)の例として、C0にJIS X 0201の
制御文字（ISO登録番号74でdesignateはESC 2/1 4/4）、G0にJIS X 0208
（ISO登録番号168でdesignateはESC 2/6 4/0 ESC 2/4 4/2）を呼ぶ例を
示してあるに過ぎませんけど。
で、RFC 1468はもう読まれました？
私> そうですか？ 私の端末ではJIS X 0201ローマ字の「A」とUS-ASCIIの「A」
私>は同じに見えますけど、そんなに使い勝手は悪くないですよ。
小野>JIS X 0201 のローマ字の「A」とUS-ASCIIの「A」はどちらも文字コードは
小野>0x41 （JIS の記述では 4/1)ですから全く同じに見える筈です。
文字コードが同じものは全く同じに見えるはず、という主張は（「A」
と「A」に関しては受け入れてもいいですが）全面的には受け入れられま
せん。だってそれだとUS-ASCIIの5/12（逆スラッシュ）とJIS X 0201ロー
マ字の5/12（円記号）は同じに見えなきゃならないでしょ？ それって
困りますよ。ましてISO 8859-1の5/12（Ｕウムラウト）まで同じに見え
るとなれば、コード系そのものが意味をなさなくなってしまいます。
また逆に文字コードが違っていても、例えばJIS C 6226-1978の16区19
点「鯵」とJIS X 0208-1983の82区45点「鰺」は、同じに見えるべきだと
考えます。だってこれらは「入れ換えられた文字」なんですから。
そういうことから「文字コードが同じ」と「見え方が同じ」は基本的
には無関係です。
小野>「醗」については：
小野>表示する字形を変えれば違って見えますよね。
小野>明朝で表示した「あ」とゴシックで表示した「あ」が違って
小野>見えるのと似たような事ではありませんか？
違いますよ。JIS C 6226-1978の40区16点「醗」とJIS X 0208-1983の
40区16点「醗」は、そもそも違う文字なので（異体字関係にはあるんで
しょうけど）違って見えるはずだ、と主張しているのです。もしや「ESC
2/4 4/0」と「ESC 2/4 4/2」の違いすら、理解してないんですか？
Sadao Ono
<DyM1x...@sainet.or.jp> に於いてミスタイプが有りました。
謹んで訂正させて頂きます。
In article <DyM1x...@sainet.or.jp>, o...@sainet.or.jp says...
>
>JIS X 0202-1991 の ６．１．５ 互換性 の項に、３つの水準として、
>-----------------
> (a) ISO 646 の版。
> [参考] JIS X 0202 のローマ文字用７単位符号．．．
> (b) ISO 646 と互換性を持った変形。すなわち．．． 略 ．．．
> [参考] JIS X 0202 のローマ文字・片仮名用７単位符号．．．
> (c) 6.1.1 で規定した構成を持つ他の７単位符号。 ．．．．．
> [参考] JIS X 0202 の制御文字集合及び JIS X 0208 を利用するもの
> ．．．
>-----------------
>
以上の部分に於いて、” [参考] JIS X 0202 ”（３個所）は
” [参考] JIS X 0201 ” の間違いでした。
以下の様に修正してお読み頂く様お願い申し上げます。
-----------------
(a) ISO 646 の版。
[参考] JIS X 0201 のローマ文字用７単位符号．．．
(b) ISO 646 と互換性を持った変形。すなわち．．． 略 ．．．
[参考] JIS X 0201 のローマ文字・片仮名用７単位符号．．．
(c) 6.1.1 で規定した構成を持つ他の７単位符号。 ．．．．．
[参考] JIS X 0201 の制御文字集合及び JIS X 0208 を利用するもの
．．．
-----------------
Masao Miyakoshi
宮越＠福井大学です。
In article <1996Oct2.1...@merope.opus.or.jp>, vo...@merope.opus.or.jp says...
>: 新しいISO 2022では、G0～G3中に「同じ文字」が指示されている
>: 場合、G番号の小さい方の文字を優先して使うことが規定されてい
>: ます。JIS X 0202も次の改正でこれに追随する予定です。
おっと、このあたりについて、大いに認識不足だったらしいです。
ポインタを示して貰えるとうれしいです。
#何しろ、以下の
>で、same character かどうかってのは、
>if both characters have the same nameかどうかで判断していいんですよね?
>そうすると、たとえば、
>: G0 US-ASCII
>: G1 JIS X 0213-1998 plane 1（第１～３水準）
>: G2 JIS X 0213-1998 plane 2（第４水準）
>のような例文では「1」とか「3」とか「4」とかいう字も
>ASCIIの方を使うべきだと考えていいんですよね?
という記述に賛同するか否かの、比較的重要な記述ですから。
#もっとも、自動的に正規化する手段を持つ方の場合には同じ文字に見える筈
ですけど。
--
★福井大学大学院生物化学工学専攻M1 宮越正織<Masao Miyakoshi>★
★e-mail kyr...@acbio.acbio.fukui-u.ac.jp ★
♂ またステールメイト、わざとかよ！
♀ もちろん（はぁと）！
Koichi Yasuoka
手元のいつも使ってるマシンがふっとんでしまったので、近所のマシン
から投稿する安岡です。でも他人のマシンには補助漢字がないよー。今度
スキを見てインストールしとこうっと。
私の
> 個人的にはあれもやめちゃって、次のJIS X 0213-1998が
> 発表されたら
> G0 US-ASCII
> G1 JIS X 0213-1998 plane 1（第１～３水準）
> G2 JIS X 0213-1998 plane 2（第４水準）
> のSI/SOとSS2で、ISO-2022-JP-3って名前でRFCを書きたいと思って
> るんですけど。
に対して、リコーの太田純さんは書きました。
>対話型プログラムでこのISO-2022-JP-3を受け付けるよ
>うに設計した場合、^N(SI)と^O(SO)がコードの切り替え
>に使われてしまうので、文字入力ではなくてコマンドと
>してこの文字を使いたいときに困りそうです。
そうなんですよね。^Nなんて普通「次の行」ですもんね。例えばuumと
kemacsの組合せ（もちろん両方ともこのISO-2022-JP-3準拠）みたいなの
だと、どう実装するか…。ただ普通は「^Nの直後に人間のキー入力では
あり得ないほど短い間隔をおいて0x21～0x7eが２つ以上入力された」と
いう実装で何とかならないかなぁ、とは思ってます。
>ひとつ質問です。通信路の両端がISO-2022-JP-3で合意
>しているという前提で、テキストストリームの先頭で
>> G0 US-ASCII
>> G1 JIS X 0213-1998 plane 1（第１～３水準）
>> G2 JIS X 0213-1998 plane 2（第４水準）
>を指示するアナウンサーも省略してしまおうと考えてい
>らっしゃるのですか?
いいえ、G1とG2についてはアナウンサを必要とするようにしたいと思っ
てます。ただ「ストリームの最初だけでいい」か「SIやSS2がある行には
それぞれ必ず入れておく」のどっちがいいかは迷ってるのですが。あとG0
はどうしましょ。
jaist.ac.jpの守岡さんは書きました。
> それから、名前は iso-2022-ja が良いと思います。
そうですね。ISO-2022-JPとちょっと見分けにくいけど、そっちでいき
ましょうか。
> 個人的には、G1 に ISO 8859-1, 2, 5, 7 が入った iso-2022-mul というの
>も欲しいです。特に、G1 に ISO 8859-1 が入ってないと何かと不便なのです。
うーん、ISO-8859-1、2、5、7は重複してる文字があるから、全部G1っ
てのは色々と誤解されそうな気がするんですけど…。でもどれが偉いって
わけでもないしなぁ…。
=============================================================================
「\」が「逆スラッシュ」に 安岡孝一＠京都大学大型計算機センター
「~」が「チルダ」に見えない端末は不良品 yas...@kudpc.kyoto-u.ac.jp
=============================================================================
Koichi Yasuoka
JISの漢字関係の規格は今改正中のものが多いので、ポインタのポインタ
くらいしか示せないんですが…。安岡です。私の
> 新しいISO 2022では、G0～G3中に「同じ文字」が指示されている
>場合、G番号の小さい方の文字を優先して使うことが規定されてい
>ます。JIS X 0202も次の改正でこれに追随する予定です。
に対して、福井大学の宮越さんは書きました。
>ポインタを示して貰えるとうれしいです。
うーん、現在すでに規格となったものではJIS X 0221-1995の996ページ
「(1) BASIC JAPANESE」あたりに書かれていることが参考にはなると思い
ます。ドラフトでよければJIS X 0208-1996?の「8.2指示」の最後の参考
でしょうか。どっちにしろJIS X 0202の新しい版が出るまでは、議論する
には尚早ですけど。
merope.opus.or.jpの日下部陽一さんは書きました（この記事、どうし
てfj.news.usageだけなんでしょ？ おかげで見落しちゃった）。
> で、same character かどうかってのは、
>if both characters have the same nameかどうかで判断していいんですよね?
まあ、たぶんそうなるでしょう。
>そうすると、たとえば、
>: G0 US-ASCII
>: G1 JIS X 0213-1998 plane 1（第１～３水準）
>: G2 JIS X 0213-1998 plane 2（第４水準）
>のような例文では「1」とか「3」とか「4」とかいう字も
>ASCIIの方を使うべきだと考えていいんですよね?
残念ながら２つの点でそうはいきません。守岡さんの記事読まなかった
んですか？
一つはJIS X 0208-1983の「１」っていう文字の名前として「FULLWIDTH
DIGIT ONE」ってのを使いたがる人達がいるってことです。これはUS-ASCII
の「1」っていう文字の名前である「DIGIT ONE」とは明らかに違いますね。
もう一つは、上の「例文」がISO-2022-JPを使って書かれてることです。
ISO-2022-JPではG1とかG3とかは使わないで、基本的にG0をとっかえひっ
かえして使いますから、「G番号の小さい方」ってのがそもそも成立しな
いんですよ。
そんなわけで「ASCIIの方を使うべき」ってのは、今のところ個人的趣
味に過ぎないでしょう。
Kusakabe Youichi
Koichi Yasuoka (yas...@kudpc.kyoto-u.ac.jp) wrote:
: > で、same character かどうかってのは、
: >if both characters have the same nameかどうかで判断していいんですよね?
: まあ、たぶんそうなるでしょう。
: >そうすると、たとえば、
: >: G0 US-ASCII
: >: G1 JIS X 0213-1998 plane 1（第１～３水準）
: >: G2 JIS X 0213-1998 plane 2（第４水準）
: >のような例文では「1」とか「3」とか「4」とかいう字も
: >ASCIIの方を使うべきだと考えていいんですよね?
: 残念ながら２つの点でそうはいきません。守岡さんの記事読まなかった
: んですか？
: 一つはJIS X 0208-1983の「１」っていう文字の名前として「FULLWIDTH
: DIGIT ONE」ってのを使いたがる人達がいるってことです。
「使いたがる」ってことは、
graphic characterのnamingの規則ってのは一意に決まっていないのでしょうか?
これはUS-ASCII
: の「1」っていう文字の名前である「DIGIT ONE」とは明らかに違いますね。
: もう一つは、上の「例文」がISO-2022-JPを使って書かれてることです。
: ISO-2022-JPではG1とかG3とかは使わないで、基本的にG0をとっかえひっ
: かえして使いますから、「G番号の小さい方」ってのがそもそも成立しな
: いんですよ。
なるほど。わかりやすい解説ありがとうございます。
つまり、たとえばfjで使う文字コードが、
G0とG1それぞれにASCIIとJIS X 0208あたりを「呼び出して」おいて
「切り替えて」使うようなふうになっていればいいんですよね。
そういう規則になれば、spoolのファイルサイズも減るのに :-)
ヘ_ヘ ------------------------
ミ・・ ミ vo...@merope.opus.or.jp
( ° )～ 日下部陽一
----------------------------------
Shinji Kono
河野 真治@琉球大情報工学です。
In article <1996Oct14....@merope.opus.or.jp> ,
vo...@merope.opus.or.jp (Kusakabe Youichi) writes
>「切り替えて」使うようなふうになっていればいいんですよね。
>そういう規則になれば、spoolのファイルサイズも減るのに :-)
くさかべさん、それは普通はEUCって呼ばれるものです。(そういう
意味では、SJISだってEUCだってJISだけど)
関係ないけど、X0208に、Latin-1を含めてほしいと僕は思うんです
けど、だめかなぁ。
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
Kusakabe Youichi
Shinji Kono (ko...@ie.u-ryukyu.ac.jp) wrote:
: くさかべさん、それは普通はEUCって呼ばれるものです。
EUC日本語コードと「ほとんど同じ」なわけですよね。
e-MailやfjのNewsもそれで送ることになっていればいいのにね。
MSB落とすところもいまだにあるのかもしれないけど。
: 関係ないけど、X0208に、Latin-1を含めてほしいと僕は思うんです
: けど、だめかなぁ。
きっと大幅な変更ってのはしないのでは?
それにASCIIはASCIIで割り当てないわけにはいかないだろうし。
ONO Kouichi
In article <3249.84...@rananim.ie.u-ryukyu.ac.jp>,
ko...@ie.u-ryukyu.ac.jp (Shinji Kono) wrote:
> In article <1996Oct14....@merope.opus.or.jp> ,
> vo...@merope.opus.or.jp (Kusakabe Youichi) writes
> >G0とG1それぞれにASCIIとJIS X 0208あたりを「呼び出して」おいて
> >「切り替えて」使うようなふうになっていればいいんですよね。
> >そういう規則になれば、spoolのファイルサイズも減るのに :-)
>
> くさかべさん、それは普通はEUCって呼ばれるものです。
それはISO 2022の8単位符号の話でしょう?
7単位符号でSI/SOで切替えるって話をしているんですが。
> (そういう
> 意味では、SJISだってEUCだってJISだけど)
どういう意味か判らない…
ここで言う「JIS」って何ですか?
JIS X 0202では「SJIS」とかは容認され得ないはずですが。
> 関係ないけど、X0208に、Latin-1を含めてほしいと僕は思うんです
> けど、だめかなぁ。
これも意味が判らない…
JIS X 0208にISO 8859-1を入れろって言っているんですか?
--
小野 康一
on...@fuka.info.waseda.ac.jp
Junn Ohta
fj.kanji,fj.news.usageの記事<3249.84...@rananim.ie.u-ryukyu.ac.jp>で
ko...@ie.u-ryukyu.ac.jpさんは書きました。
> >G0とG1それぞれにASCIIとJIS X 0208あたりを「呼び出して」おいて
> >「切り替えて」使うようなふうになっていればいいんですよね。
> くさかべさん、それは普通はEUCって呼ばれるものです。
日本語EUCというのは
「G0にASCII(というかJIS X0201の左半面)、G1にJIS
X0208を指示(designate)しておき、GLにG0、GRにG1
を呼び出(invoke)した状態で使う」
もののことですよね? (G2とG3もあるけど。)
くさかべさんが言いたいのは
「G0にASCII、G1にJIS X0208を指示しておき、SOやSI
でGLにG0、G1を呼び出して、つまりGLの内容を切り
替えて使う」
ものだと思うのですが、どうでしょう?
もともと通信路で使われる文字コードの話ですし、特に
断りがなければ7単位系の話と解釈すべきですよね。
関係ないですけど、
> 関係ないけど、X0208に、Latin-1を含めてほしいと僕は思うんです
> けど、だめかなぁ。
私もそうなるとうれしい...。:-)
--
太田純(Junn Ohta) (株)リコー ソフトウェア事業センター
oh...@src.ricoh.co.jp/JCF0...@niftyserve.or.jp
Tomohiko Sakamoto
In article <1996Oct14....@merope.opus.or.jp>,
vo...@merope.opus.or.jp (Kusakabe Youichi) writes:
> なるほど。わかりやすい解説ありがとうございます。
>
> つまり、たとえばfjで使う文字コードが、
> G0とG1それぞれにASCIIとJIS X 0208あたりを「呼び出して」おいて
> 「切り替えて」使うようなふうになっていればいいんですよね。
安岡さんの「わかりやすい解説」のあとに、括弧付きで「呼び出して」などと
いう間違った用語で「わかりにくい意見」を書くから、誤解する人が出てくる
んですね。
・ASCII の図形文字集合を G0集合として指示する。
(to designate a graphic character set of ASCII as the G0 set)
・JIS X 0208 を G1集合として指示する。
・SI で、G0集合を GL(列2～列7)に呼び出す。
・SO で、G1集合を GL(列2～列7)に呼び出す。
SI/SO は locking shift ですから、これは「切り替えて」と言ってもかまわ
ないでしょう。
今の、ISO-2022-JP は、
・ESC $ B の 3バイトで 漢字を「G0集合として指示し、GL に呼び出す」。
・ESC ( B の 3バイトで ASCII を「G0集合として指示し、GL に呼び出す」。
となっているので、
・SO の 1バイトで 漢字を「GL に呼出す」。
・SI の 1バイトで ASCII を「GL に呼び出す」。
コードの方がファイルサイズが小さくなるということですね。
JIS X 0208 の改正案では、これを JIS の文字コードとして規定しています。
でも、本音は、「つまり、..... いいんですよね。」からわかるように、
「JIS X 0208 にある、ASCII と同じ文字は使ってはいけない」という大義名分
が欲しいわけだ。Subject の「重複符号化禁止」のね。
--
坂本智彦 saka...@sm.sony.co.jp
Tomohiko Sakamoto
In article <3249.84...@rananim.ie.u-ryukyu.ac.jp>,
JIS X 0212 補助漢字はご存知ですよね。これの非漢字(1区～15区)には、ISO
8859-1,2,3,4,5,7 および ISO 6937-2,7,8 に含まれる文字が選定されていま
す。しかも、その区点番号は、JIS X 0208 の非漢字の同じ区点番号に文字が
割り当てられていない位置が使用されています。なぜ、こんなことをしたんで
しょう。恐らくは、補助漢字が使えない環境でも、JIS X 0208 に JIS X 0212
の非漢字を重ね合わせて使えるようにという配慮からではないでしょうか。そ
ういう意味では、JIS X 0208 に Latin-1 を含めることは出来ます。
しかし、JIS では、第3水準および第4水準という別の文字コードの拡張計画を
進めようとしています。(http:///www.tiu.ac.jp/JCS/ 参照)
--
坂本智彦 saka...@sm.sony.co.jp
Kusakabe Youichi
Tomohiko Sakamoto (saka...@sm.sony.co.jp) wrote:
: 安岡さんの「わかりやすい解説」のあとに、括弧付きで「呼び出して」などと
なるほど、「G0に」だから「指示して」の誤りですね。
: 本音は、「つまり、..... いいんですよね。」からわかるように、
: 「JIS X 0208 にある、ASCII と同じ文字は使ってはいけない」という大義名分
: が欲しいわけだ。
そういう大義名分があるといいんですが。どこかにないものか。
Shinji Kono
河野 真治@琉球大情報工学です。読み間違えた僕があほなだけです。
In article <5455d6$n...@csdnews.sm.sony.co.jp> ,
saka...@sm.sony.co.jp writes
>・SO の 1バイトで 漢字を「GL に呼出す」。
>・SI の 1バイトで ASCII を「GL に呼び出す」。
なるほどね。そうすれば、半角かなをSOとかでGLに呼び出すのとは
両立しなくなりますね。賛成はできないけど...
In article <545658$o...@csdnews.sm.sony.co.jp>,
saka...@sm.sony.co.jp (Tomohiko Sakamoto) writes:
> 恐らくは、補助漢字が使えない環境でも、JIS X 0208 に JIS X 0212
> の非漢字を重ね合わせて使えるようにという配慮からではないでしょうか。そ
> ういう意味では、JIS X 0208 に Latin-1 を含めることは出来ます。
ふーん。でもしなかったってことか。そうなっていれば、nkf で変換する
ってのも簡単だったんですけどね。
> しかし、JIS では、第3水準および第4水準という別の文字コードの拡張計画を
> 進めようとしています。(http:///www.tiu.ac.jp/JCS/ 参照)
あれあれ。tiu ってどこでしたっけ?
Tachikawa Yutaka
<5447he$5...@ns.src.ricoh.co.jp>の記事において
oh...@src.ricoh.co.jpさんは書きました。
>> くさかべさんが言いたいのは
>>
>> 「G0にASCII、G1にJIS X0208を指示しておき、SOやSI
>> でGLにG0、G1を呼び出して、つまりGLの内容を切り
>> 替えて使う」
>>
>> ものだと思うのですが、どうでしょう?
ちなみにNetNewsでは相変わらずSIやSOは御法度なんでしょうか。
それとも実際は使える環境が大部分なんでしょうか。
Koichi Yasuoka
http://www.kudpc.kyoto-u.ac.jp/~yasuoka/kanjibukuro/がやっと
動いたので、うれしい安岡です。まだデータは少ないのですが、よけ
ればどうぞ。私の
> 一つはJIS X 0208-1983の「１」っていう文字の名前として「FULLWIDTH
>DIGIT ONE」ってのを使いたがる人達がいるってことです。
に対して、merope.opus.or.jpの日下部陽一さんは書きました。
>「使いたがる」ってことは、
>graphic characterのnamingの規則ってのは一意に決まっていないのでしょうか?
いえ、基本的には「１」は「DIGIT ONE」なんですよ。ただし「これ
までの慣用的な利用との互換を目的」として「1」なんかと混在して使
う場合には「FULLWIDTH DIGIT ONE」っていう「代替名称」になっちゃ
うわけです。でも正直なところ、RFC 1468すら
> Each JIS
> X 0208 character takes up two columns, and the escape sequences do
> not take up any columns.
っていう「１と1は幅が違う」信仰に染まってる中じゃ、何を言っても…。
（sainet.or.jpの小野さん、ごめんなさい、答、書いちゃいました。こ
れが「ＡとAは違って見える」信仰の根拠の一つです。）
琉球大学工学部情報工学科の河野真治さんは書きました。
>関係ないけど、X0208に、Latin-1を含めてほしいと僕は思うんです
>けど、だめかなぁ。
これに対しsm.sony.co.jpの坂本智彦さんは書きました。
>JIS X 0212 補助漢字はご存知ですよね。これの非漢字(1区～15区)には、ISO
>8859-1,2,3,4,5,7 および ISO 6937-2,7,8 に含まれる文字が選定されていま
>す。
でも、JIS X 0212って「1/2」とかはなかったような…。
>しかし、JIS では、第3水準および第4水準という別の文字コードの拡張計画を
>進めようとしています。(http:///www.tiu.ac.jp/JCS/ 参照)
じゃ、その「拡張」にLatin-1を全部含めるように言いましょうよ。
でも本当にVULGAR FRACTION ONE HALFとかって、要ります？
Kusakabe Youichi
Koichi Yasuoka (yas...@kudpc.kyoto-u.ac.jp) wrote:
: いえ、基本的には「１」は「DIGIT ONE」なんですよ。
ですよね。わたしもそうだと思うし、そうあるべきだとも思います。
: ただし「これまでの慣用的な利用との互換を目的」として「1」なんかと混在して使
: う場合には「FULLWIDTH DIGIT ONE」っていう「代替名称」になっちゃ
: うわけです。
うーん、これはどの規格で規定しているのでしょうか?
そういうへんな概念を持ち込むから、つごうの悪い部分がどんどん
将来に持ち越され、借金が膨らむんだと思う。
そういう規格をきめた人はいったい何を考えているんでしょうね。
: でも正直なところ、RFC 1468すら
: > Each JIS
: > X 0208 character takes up two columns, and the escape sequences do
: > not take up any columns.
: っていう「１と1は幅が違う」信仰に染まってる中じゃ、何を言っても…。
たしかに...。困ったもんですね。
Koichi Yasuoka
安岡です。sainet.or.jpの小野さんは、すでに自己破綻に向かった
ので、ほっとくとして（せっかく答を書いたげたのに…）。
私の
> いえ、基本的には「１」は「DIGIT ONE」なんですよ。ただし「これ
>までの慣用的な利用との互換を目的」として「1」なんかと混在して使
>う場合には「FULLWIDTH DIGIT ONE」っていう「代替名称」になっちゃ
>うわけです。
に対し、merope.opus.or.jpの日下部陽一さんは書きました。
>うーん、これはどの規格で規定しているのでしょうか?
JIS X 0208-1997…、あ、これはまだ規格になってませんでしたね。
じゃ、JIS X 0221-1995の附属書３表３（860ページ）と解説表２（1014
ページ）かな。もちろん1000ページの“重複定義を容認する場合の対応
表作成ガイド”の前後あたりも読んどく必要があります。でもこれらは
「規定」じゃなくて「参考」や「解説」なんですよ…。
=======================================================================
安岡孝一＠京都大学大型計算機センター yas...@kudpc.kyoto-u.ac.jp
http://www.kudpc.kyoto-u.ac.jp/~yasuoka
=======================================================================
Sadao Ono
In article <1996Oct18.1...@merope.opus.or.jp>, vo...@merope.opus.or.jp
says...
>
>Koichi Yasuoka (yas...@kudpc.kyoto-u.ac.jp) wrote:
>: いえ、基本的には「１」は「DIGIT ONE」なんですよ。
>
>ですよね。わたしもそうだと思うし、そうあるべきだとも思います。
>
>: う場合には「FULLWIDTH DIGIT ONE」っていう「代替名称」になっちゃ
>: うわけです。
>
>そういうへんな概念を持ち込むから、つごうの悪い部分がどんどん
>将来に持ち越され、借金が膨らむんだと思う。
>そういう規格をきめた人はいったい何を考えているんでしょうね。
>
付属書３は、X 0221 の元規格である ISO/IEC 10646-1-1993 には無い部分と
言うことですから「日本でのローカルルール」と言うべきものかも知れません。
確かに、JIS X 0221-1995 解説を読むと、「問題の先送り」に見えます。
しかし、「ＡとAが違っている環境も認めて欲しい」との主張がある様にも
見えます。（日本的な曖昧な表現なのですが）
-
ＡとAが違っている環境はあるかたには不都合なのかも知れません。
（パソコン初心者が「dir」を「ｄｉｒ」等と打ち込んで悩む事もあります）
慣れると結構便利な面もありまして、「Ｏno」等の様にも書けます。
>
>: でも正直なところ、RFC 1468すら
>: > Each JIS
>: > X 0208 character takes up two columns, and the escape sequences do
>: > not take up any columns.
>
>: っていう「１と1は幅が違う」信仰に染まってる中じゃ、何を言っても…。
>
>たしかに...。困ったもんですね。
>
「１と1は幅が違う」信仰に染まってる．．．．等と批判するのもちと？です。
たしかに...。「１と1は幅が違う」人と「１と1を区別しない」人が
情報交換しようとすると困ってしまいます。
JIS 規格書の中で「ほとんど常識化している」と言われている「全角半角の区別」を
単純に排除する事も．．．困ったもん なのではありませんか？
（JIS X 0221-1995 解説 4.5.3.1.2 (2) 参照）
Sadao Ono
In article <547kuf$q...@kudpc.kudpc.kyoto-u.ac.jp>, yas...@kudpc.kyoto-u.ac.jp
says...
>
>> 一つはJIS X 0208-1983の「１」っていう文字の名前として「FULLWIDTH
>>DIGIT ONE」ってのを使いたがる人達がいるってことです。
>
>に対して、merope.opus.or.jpの日下部陽一さんは書きました。
>
>>「使いたがる」ってことは、
>>graphic characterのnamingの規則ってのは一意に決まっていないのでしょうか?
>
>までの慣用的な利用との互換を目的」として「1」なんかと混在して使
>う場合には「FULLWIDTH DIGIT ONE」っていう「代替名称」になっちゃ
>
>> Each JIS
>> X 0208 character takes up two columns, and the escape sequences do
>> not take up any columns.
>
エスケープシーケンスはカラムを取らない（それ自身は表示しない）。」
の様な意味でしょうか？ （英語は苦手です）
＃「個々の（全ての）JIS X 0208 文字は２カラム迄（以下）である、．．」
＃なのかも知れない？
＃（takes up to two columes なら ２カラム迄 なのかな？？）
>
>っていう「１と1は幅が違う」信仰に染まってる中じゃ、何を言っても…。
>（sainet.or.jpの小野さん、ごめんなさい、答、書いちゃいました。こ
>れが「ＡとAは違って見える」信仰の根拠の一つです。）
>
（解説 4.5.3.1.2 (2) 基礎の対応表の考え方）書かれています。
さらに：
・JISでは半角と全角の区別はしない。
・現実の実装との互換のために緊急退避的な用途で用いるために
「JIS X 0208 の非漢字部の全角文字」と「半角片仮名」を用意した。
・これらの互換文字は「遠い将来は“限りなく使用禁止に近い”
文字となる事が期待されている」
とあります。
いわゆる「問題の先送り」に見えるのですが、
「遠い将来」「禁止に近い」「期待されている」等から見ると、
「原則（ＡとAの区別をしない）を貫く意志は無い」様にも読めます。
>
> 琉球大学工学部情報工学科の河野真治さんは書きました。
>
>>関係ないけど、X0208に、Latin-1を含めてほしいと僕は思うんです
>>けど、だめかなぁ。
>
単にLatin-1を追加すると「重複定義」になってしまいます。
X 0208 英数字の所に記号を追加しても「重複定義」が発生します。
X 0201 の「ローマ文字用図形キャラクタ集合」または Latin-1 と
X 0208 を切り替えて（JIS X 0202 の手法で）使う事でしょうか。
このとき、X 0208 の「英数字と一部の記号」部分の扱いが問題で、
現在の多くの実装に合わせるか、「遠い将来」「禁止に近い」事が
「期待されている」実装をするかは自由なのではないのでしょうか？
（情報交換をする場合は当事者間の合意が必要です）
現在の X 0208 文字を全て「全角」文字と定義すれば
（ＡとAの区別をするなら）半角文字としてLatin-1を追加する事は
可能かも知れません。（原則から変えなければなりません）
Kusakabe Youichi
Sadao Ono (o...@sainet.or.jp) wrote:
: 「個々の（全ての）JIS X 0208 文字は２カラムである、
もしそうだったら
「‐」の立場ってどうなっちゃうんでしょうか?
「◯」なんてマイナスの値かも。
: の様な意味でしょうか？ （英語は苦手です）
: ＃「個々の（全ての）JIS X 0208 文字は２カラム迄（以下）である、．．」
: ＃なのかも知れない？
: ＃（takes up to two columes なら ２カラム迄 なのかな？？）
そもそも「カラム」っていう概念はその規格て定義されていないのでは?
: ・現実の実装との互換のために緊急退避的な用途で用いるために
: 「JIS X 0208 の非漢字部の全角文字」と「半角片仮名」を用意した。
: ・これらの互換文字は「遠い将来は“限りなく使用禁止に近い”
: 文字となる事が期待されている」
早くそうなってほしいものです。
「限りなく使用禁止に近い」ではなくて「使用禁止」に
「遠い将来」ではなく、「すぐにでも」
「期待される」じゃなくって「強制する」
がいいけど。
(それにしても冗談みたいな文章ですよね。)
Kusakabe Youichi
Sadao Ono (o...@sainet.or.jp) wrote:
: 慣れると結構便利な面もありまして、「Ｏno」等の様にも書けます。
で、それのどこが「便利」なのでしょうか?
: JIS 規格書の中で「ほとんど常識化している」と言われている「全角半角の区別」を
: 単純に排除する事も．．．困ったもん なのではありませんか？
いいえ。一刻も早く排除するべきです。
そうしないからこそ「ほとんど常識化している」なんていう「うそ」を信じる人が
増えるのでは?
Kusakabe Youichi
=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / (mor...@jaist.ac.jp) wrote:
: ならないことが明記される予定です。（多分、JIS X0213-1998? では
: ``CIRCLED *'' といった文字が収録されるだろうと思います）
だとすると丸付きの100～120はぜひほしいですね :-)
正とか
Macだと1～20と
大小上中下左右医財優労印控秘
などがありますね。
koisikava kazuiuki
小石川＠慶応矢上です。
ちゃちゃです。
In article <1996Oct21.1...@merope.opus.or.jp>
vo...@merope.opus.or.jp (Kusakabe Youichi) writes:
> : ならないことが明記される予定です。（多分、JIS X0213-1998? では
> : ``CIRCLED *'' といった文字が収録されるだろうと思います）
>
> だとすると丸付きの100～120はぜひほしいですね :-)
碁打ちの為に400ぐらいまで白黒反転させたもの両方の丸付き文字も欲しい。
--
慶應義塾大学理工学研究科計測工学専攻
椎木研究室 M1
小石川 和幸
mr96...@mc.st.keio.ac.jp
KATAYAMA Yoshio
片山＠ＰＦＵです。
In article <559p0i$n...@kudpc.kudpc.kyoto-u.ac.jp>,
yas...@kudpc.kyoto-u.ac.jp (Koichi Yasuoka) writes:
>>でもそんなことより、せめて常用漢字と人名漢字の旧字体は全部
>>入れて欲しいなあ…。特に人名において旧字体の使用も認めている
>>字は、絶対入れないとまずいと思う。
> 確かに。「へんがネの『福』」と「へんが示の『福』」なんて、絶対
>分離しなきゃいけませんよね。でもそうすると、「琢」は分離するのに
>どうして「啄」は分離しないんだ、って言い出す人がいそうだなぁ…。
「片山」の片は、
* *
* *
************
*
************
* *
* *
* *
* *
なので、戸籍などでは外字を作っているようです。
--
片山＠ＰＦＵ