ノート:半角カナ

記事にマッチした書き方ができなかったのですが・・・。

黎明期のパソコンが能力の問題で半角カナを用いたのと同じように、表示能力の問題で携帯電話には半角カナ文字が依然として存在している。

というのはありますよね。0null0 17:22 2003年12月13日 (UTC)

そうですね。あとは、アスキーアートでの利用が大きいですよね。これは、詳しくないので言及できませんでした。Sampo 17:30 2003年12月13日 (UTC)（本文は未ログインで書きましたが）

N88-BASICはSJISだったろうと想像するのですが、 (あの当時、わざわざ面倒な方式を採用するとは思えないので) JISだったというのは確かでしょうか?211.18.68.230

自己レスです…。ごめんなさい。どうやらSJISではなさそうですね。211.18.68.230

スタンドアロン版のn88がJISだったのは確かです（現在のISO-2022-JPとは異なるSI,SOを用いていましたが）。日本語処理は、それは面倒だったものです・・・。ただし、MS-DOS版N88はSJISでしたね。DOS版に関してはご指摘通りです。

EUCについてですが、漢字をシフトコードで囲むのではなく、半角カナをシフトコードで囲むという意味で書きました。NKFのドキュメントにそういう記述があったと記憶しているのですが・・・手元にありません。fixMe.Sampo 17:45 2003年12月13日 (UTC)

普通EUCで半角カナ/補助漢字を扱う場合、JISで通常行われるようなロッキングシフトではなく、シングルシフトを用います。例えば、半角の「フ」なら、0x8e 0xccとなり、これに続けて7bit文字を書けますから、囲まれているとは言いにくい気がします。なお、私の知識は殆んど http://euc.jp/i18n/charcode.ja.html が元です。ご参考まで。211.18.68.230

非常に参考になりました。ありがとうございます。Sampo 10:40 2003年12月21日 (UTC)

このEUCの部分以外にも、多少違和感を感じる点がありました。私は文字集合JISX0201でのカナにあたる文字はエンコーディングに依らず「半角カナ」と呼びたいのですが、SampoさんはSJISでのいわゆる「半角カナ」を中心に考えておられるかと思います。私の意見では、JISの場合には7bitで半角カナを表します(半角カナが8bitで表されている場合はJIS/SJIS混じりの文章だと思います)。また、EUCの場合には前述のように別の8bit2文字で半角カナを表します。つまり、半角カナはJIS/SJIS/EUCで相互変換可能です。半角カナを利用することによる問題点は、全角カタカナを使うのに対して優位性が無いにもかかわらず、クライアントソフトで対応するのが繁雑な点だと思います。211.18.68.230

そのあたりも付け加えてもらえます？　JISが7bitで半角カナを扱うという話は初耳なのでよくわかりません・・・Sampo 07:24 2003年12月14日 (UTC)

JISというのはそもそも何を指しているか微妙ですし、ISO2022-JPでも半角カナは使えませんから、誤解を招いているかもしれません。私は、ISO2022-JP風に7bitしか許さないまま、ISO2022準拠の範囲でJISX0201-kanaを利用するようなものを考えていました。もっと具体的には、GNU Emacsで半角カナを変換した結果を想定していました。Emacsでの変換例を挙げますと、「AアあB」(ただしアは半角カナ)を記述した場合、SJISでは「41 b1 82 a0 42」、EUCでは「41 8e b1 a4 a2 42」ですが、ISO2022-JP(正確には「ISO2022-JP風」ですが)で表すと「41 1b 28 49 31 1b 24 42 24 22 1b 28 42 42」(以上16進表記)になります。http://www.biwa.ne.jp/~tomoko/wnn/iso2022.html にもあるように、JISX0201-kana(私としては「半角カナ」と呼びたい文字集合)は文字集合としてECMAに登録されており、ISO2022で言うと「1b 28 49」でシフトできます。そもそもISO2022は7bitしか使わなくても文字コードセットをほぼ無限に変更できるような、柔軟すぎるほどの仕様なのです。N88BASICの話題でJISだとすれば面倒すぎると私が直感したのもそこでしたが、これは私の想定の方が違ったようです(ただ、それはそれでASCIIの8bit部分にJISX0201-kanaをマップし、ロッキングシフトでJISX0208のみを許し、しかも現在とはロッキングシフトのエスケープシーケンスが異なるようなもののようですから、一言でJISと言うのは語弊があるように思います。では何と呼べばいいのかはわかりませんけど…)。211.18.68.230 18:52 2003年12月14日 (UTC)

別件ですが、初期のOutlookか何かのMS製品がメール送信やネットニュースの投稿の際に、ISO2022-JPを拡張して0x0f/0x0eあたりでJISX0201-kanaへのロッキングシフトを行っていたと記憶しています。10年前くらいでしょうか。全く一般的でない方法だったので叩かれていましたし、いつの間にか消えてしまいました。ただ、このあたりにも半角カナの問題点が表れているかもしれません。MSの実装は今考えてもどうかと思うのですが、かといって規格が定まっているわけでもない以上、間違いとも言えないんですよね。規格として誰も定めないままEmacs/muleの実装が実質標準、といった調子だったとしたら、企業としては実装できないですよね。211.18.68.230 18:52 2003年12月14日 (UTC)

また、普通のJISで半角カナ混じりの文を書こうとするなら、 JISX0208とJISX0201を混在させるかと思います。211.18.68.230

上に書いたISO2022風な混在を意図していたんですが、これだけじゃ何が言いたいか意味不明ですね。JISX0201と言っても、右半分か左半分かがわからないですし、何より文字コードの話題で「JIS」は止めた方が良さそうです。 211.18.68.230 18:52 2003年12月14日 (UTC)

EUCの場合は、普通2バイトになると思います。 JISのようにシフトコード(と呼ぶのだろうか?)で囲みはしないと思います。

使用理由として、少しでもデータ通信量を削減(=料金を安く)するためにが一つと、あとは似ていますが一度に扱えるデータ量に制限がある(巨大なページを閲覧できなかったり、メール一通あたりのデータ量に制限がある)という場合に、数byteでも削減するために用いているようです。というより、用いたことがあります。表示能力とはこのことですよね?Tsk 17:35 2003年12月13日 (UTC)

確か初期のxmlか何かでは、半角カナあたりは使用すべきでないと記載されていませんでした?ちょっと資料が見当たらない……Tsk 19:55 2003年12月13日 (UTC)

折角調べたので参考に：文字コード Microsoft漢字コード Shift_JIS JIS X 0208 EUC-JP ISO-2022-JPあたりと絡んできそうですし、用語の使い方もこれらのページと統一をはかった方が良いかもしれません。211.18.68.230 18:52 2003年12月14日 (UTC)

私のスタンスについて:普段は明らかなミスなどを少し訂正したり、他人の追加を期待してミスのないことだけを書いたりしています。漫画の記事が大半、時々コンピュータ関係の記事を書くIP野郎です。今回ノートに大量に書いて、Sampoさんの書かれた文章に手を加えていないのは、そもそも根本から意見が違うのでどう編集していいかわからないからです。まず、何を半角カナと呼ぶのかについてが私とずれています。ISO-2022-JPを書いた方は私と同じような認識でいると思うのですがどちらとも読めます。また、私の意見では、半角カナが嫌われる理由として技術上の困難があるわけではなく、多くの技術者の美的センスにそぐわないことが一番の理由だと思います。実際、上に挙げたように理屈上利用する上での障害は無いわけですから、あとはクライアントソフトの対応だけですよね。このあたりで論調が私とずれてしまうので、どうしたものかと思っています。211.18.68.230 18:52 2003年12月14日 (UTC)

ええ、まさに人によって定義が違うところが大きな問題だと思います。その現状を冒頭の一文に反映させたつもりですが、続く内容の方はきっちり私の定義になってしまっていますね・・・　ノート上でもいいんで、そこら辺の認識を解説してもらえませんか？

その冒頭の一文も実は間違っていて、Shift JISの符号化がスタート地点というよりはJISX0201で規定されている気がする、ISO8859風な1バイト日本語の符号化方式（これに通称はあるんでしょうか？名前がわからないので書きようがないんですが）の8bit部分がこの問題のはじまりなんですよね。で、Sampoさんはこの符号化(MSXなどが典型例でした。その自然？な拡張としてN88BASICがあったという流れですね)や、その流れを継いだSJISなどのカタカナ部分を半角カナと呼んでおられると思います。ただ、これをJISやEUCで表現した場合も半角カナと呼ぶべきなんじゃないのか、それにしてはバイト表現にこだわりすぎていないか、というのが私の意見です。なので、定義はほとんど違わないというか、Sampoさんと私とでも最初から殆ど同じだと思うんですが…。 Yh 18:23 2003年12月21日 (UTC)

なるほど。文字集合としての半角カナを重視しておられるんですね。今の記事にうまく付け足すことはできそうな気がします。Sampo 18:35 2003年12月21日 (UTC)

技術的に美しくないのも問題のひとつなのは確かです。文章の流れ的に織り込む場所がなかったので割愛してしまいましたが。Sampo 10:40 2003年12月21日 (UTC)

半角カナが嫌われる更にもう一つの理由として、ソフトウェアでは対応していてもフォントが存在しない環境がありうる、ということも挙げられるでしょう。

つまり、いわゆる全角漢字が表示できるにも関わらず、半角カナのフォントが存在しないために半角カナを表示できない環境が存在し得るということです。具体的には、過去に触ったSolaris 2.6 の X Window Systemがそのような環境だったと記憶しています。 X Window Systemでのフォントは基本的に文字集合ごとに管理されており、日本語の文章に不用意に半角カナを混ぜることは無意味に2つの文字集合の文字を利用していることになります。 ISO2022-JPが半角カナを含んでいないのは、このような側面もあるのではないでしょうか。Yh 02:03 2003年12月20日 (UTC)

フォントが存在しない点に関して加筆してみました。不足なところが有れば補ってくださいませ。Sampo 10:40 2003年12月21日 (UTC)

Sampoさん、文字集合と符号化方式が異なるというのはOKですか？ 0xa1～0xdfは、「JISX0201(の右側)という文字集合に関して Shift JISという符号化を行った際のバイト表現」であって、 EUCにした場合に最初に1バイト0x8eが付加されて次にShift JISと同じ0xa1～0xdfの1バイトが続いて半角カナのバイト表現になることは言わば偶然です。偶然というと語弊があるかもしれませんが、別の符号化方式の話を混同して論じているのは誤解があるかミスリードを狙っているように見えます。 Shift JISの半角カナとEUCの通常の漢字のバイト表現が重なるからエスケープするのではなく、そもそもそういう符号化なんです。

また、EUCの半角カナを処理できない処理系というのを私は知りません。上のフォントの問題であれば表示できないだけのことです。 SJISの処理系との文書交換を考えると、 EUCで半角カナをサポートすることは十分意味があります。パッと思いつくだけでもnkf、Jcode.pm、PHP、PostgreSQLあたりは半角カナをEUCで扱えます。 Windowsでも例えばxyzzyはEUCの半角カナを扱えるかと思います。

おそらく、私が書き足さない分を汲み取って追記して頂いたのかと思います。私の中でも徐々に整理が出来てきて、ようやく書き足せそうな気がしてきました。 Yh 20:01 2003年12月20日 (UTC)

集合と符号化が別の次元であるというのは理解しているつもりですが、次の行からのご指摘が記事のどの部分についてのことなのかよくわかりません・・・

すみません、EUCのところの説明に関してのつもりでした。「日本語の1文字目に当たるコードは半角カナに重なるように配置されている。そのため…」のあたりです。どういう符号化をするかは言わば自由ですから、半角カナの1表現である0xa0～0xdfがEUCでは日本語の1バイト目として既に使われているからといって、エスケープ文字に続けて書く理由にはなりません。まあ、ご理解いただいているのであれば僕が勘ぐり過ぎなだけかと思います。

言葉の定義が曖昧でしたね。「8bit拡張ASCIIでの半角カナ領域」と厳密に述べるべきところでした。Sampo 18:35 2003年12月21日 (UTC)

半角カナをサポートしない処理系の存在については、http://euc.jp/i18n/charcode.ja.html からの受け売りですが、これはもしかしてフォントとして持っていない処理系のことを指しているのでしょうかね？Sampo 10:40 2003年12月21日 (UTC)

上記の文章で問題にしているのは、日本語の文字数をカウントするような場合に補助漢字が3バイトであることをプログラマが知らないために文字区切りを間違うことがある、ということを指していそうな気がします。で、話の流れで表示が崩れがちな半角カナの話もしてみた程度じゃないですかね…？ちょっと微妙な気がします。

EUCで積極的に半角カナを使う人間がいないというのは事実だと思います。メリット云々より前に、Unix/linux環境だと半角カナの入力がそもそも難しいですから。

ま、このへんは卵と鶏の関係でしょうね。(^^;)Sampo 18:35 2003年12月21日 (UTC)

ISO-2022-JPと半角カナ

要約でミスりましたが、RFC 1468でISO-2022-JPには半角カナは含まれないと明記してあるため、該当リンク先の記述は誤りであるとの判断で削りました。--Canadie 2007年5月21日 (月) 08:19 (UTC)[返信]

「ISO-2022-JPに…追加」は確かに変なので、除去は妥当だとおもいます。ISO-2022-JPでは「独自拡張」として紹介するようにしてみました[1]。ISO/IEC 2022#ISO-2022-JPに書いたほうがいいだろうか。 --Hatukanezumi 2007年5月21日 (月) 15:03 (UTC)[返信]