で、半角ってなんですか？
Ichiya KAMIKI
sugi...@po.ntts.co.jp (Yoshitaka 'Railway' Sugishita) writes:
> それらの状況が、私の環境における状況と異なっているのは、むしろ、当た
> り前なのです。Kazuo Fox Dohzono サンの環境と私の環境が、互いに独立に存
> 在するのですから。
独立に存在するのは事実でしょうけど対等に扱う必要もありません。
JIS X 0208 には
附属書 5 の表 1 ～ 2 でいわゆる半角カナおよび全角アルファベットを示し、
これまでの慣用的な利用との互換目的以外に使うな、と記しています。
半角アルファベットを推奨する発言に反対するのに個人の環境の存在をもって理由とすることはできません。
そもそも、こういう喧嘩を封じるために出来た規定だと思うんだけど < JIS X 0208 の 7.2 項
--
かみきいちや
Kusakabe Youichi
> JIS X 0208 には
> 附属書 5 の表 1 ～ 2 でいわゆる半角カナおよび全角アルファベットを示し、
> これまでの慣用的な利用との互換目的以外に使うな、と記しています。
もっときっちり使用を禁止すべきだったんですよね。
ヘ_ヘ ____________________________
ミ・・ ミ vo...@merope.pleiades.or.jp
( ° )～ 日下部陽一
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
Yoshitaka 'Railway' Sugishita
Ichiya KAMIKI <kam...@geocities.com> writes:
> JIS X 0208 には
> 附属書 5 の表 1 ～ 2 でいわゆる半角カナおよび全角アルファベットを示し、
> これまでの慣用的な利用との互換目的以外に使うな、と記しています。
そして、日本語で書かれた文書に JIS X 0208 に規定された英数字を使用す
るのは、「これまでの慣用的な利用との互換目的」の一つに他なりません。
> 半角アルファベットを推奨する発言に反対するのに個人の環境の存在をもって理由とすることはできません。
それ以前に、半角アルファベットを推奨するのに個人の環境の存在をもって
理由とすることはできません。
--
Yoshitaka Sugishita 杉下 宜隆 sugi...@po.ntts.co.jp
NIDE Naoyuki
In article <43d46cb2.01120...@posting.google.com>,
sugi...@po.ntts.co.jp writes:
> そして、日本語で書かれた文書に JIS X 0208 に規定された英数字を使用す
> るのは、「これまでの慣用的な利用との互換目的」の一つに他なりません。
この部分何を言いたいのかいま一つつかめないのですが、
JIS X0208は情報交換用符号の1つです。つまり、情報を交換するには文字の
表現は当事者同士で共通である必要があるので、共通の約束ごととして使うた
めにあるものです。なので、JIS X0208を使って情報を交換するなら、JIS
X0208の定めていることには従う必要があります。
で、そのJIS X0208には
> In article <GnzC4...@y.mcu.jp>
> Ichiya KAMIKI <kam...@geocities.com> writes:
> > 附属書 5 の表 1 ～ 2 でいわゆる半角カナおよび全角アルファベットを示し、
> > これまでの慣用的な利用との互換目的以外に使うな、と記しています。
のです。
ここの「これまでの慣用的な利用…以外に使うな」とは、従来のJIS X0208
やX0201が特にこれらの利用を禁じていなかったために実際にこれらが使われ
ていたのに対し、JIS X0208を改正して「今後は過去互換の目的以外にはこれ
らを使わないようにしよう」と定めたということです。
> それ以前に、半角アルファベットを推奨するのに個人の環境の存在をもって
> 理由とすることはできません。
が、Ichiya KAMIKIさんは個人の環境の存在を理由としていわゆる「半角ア
ルファベット」を推奨しているわけではありません。
Yoshitaka 'Railway' Sugishita
ni...@ics.nara-wu.ac.jp (NIDE Naoyuki) writes:
> ここの「これまでの慣用的な利用…以外に使うな」とは、従来のJIS X0208
> やX0201が特にこれらの利用を禁じていなかったために実際にこれらが使われ
> ていたのに対し、JIS X0208を改正して「今後は過去互換の目的以外にはこれ
> らを使わないようにしよう」と定めたということです。
で、日本語で書かれた文書に JIS X 0208 に規定された英数字を使用すると
いうのは、「過去互換の目的」の一つなのですから、結果として、「使わない
ようにしよう」の対象には含まれないということになりますね。
一口に「過去互換」と言っても、いろいろあります。「今までずっとこのコ
ード体系で扱ってきたのだから、変えたくはない」というのも「過去互換」の
一つです。
もちろん、重大な問題が明らかになり、明確に使用禁止にでもなれば、話は
別です。その場合は、当然、元記事（<9rgj4d$aaq$1...@news512.nifty.com>）は、
単なる“推奨”とは異なり、その理由の説明も、大きく異なる（見栄え，サイ
ズ，検索の手間などの問題ではない）ものになっていたことでしょう。そうい
うことになれば、さすがに、反論の余地はありません。
> が、Ichiya KAMIKIさんは個人の環境の存在を理由としていわゆる「半角ア
> ルファベット」を推奨しているわけではありません。
そのとおりです。
In article <43d46cb2.01120...@posting.google.com>
sugi...@po.ntts.co.jp (Yoshitaka 'Railway' Sugishita) writes:
| それ以前に、半角アルファベットを推奨するのに個人の環境の存在をもって
| 理由とすることはできません。
この文は、かみきサンが「個人の環境の存在を理由としたいわゆる『半角ア
ルファベット』の推奨を行なっている」という意味ではなく、前述の元記事が
「個人の環境の存在を理由としたいわゆる『半角アルファベット』の推奨を行
なっている」という意味です。
Ichiya KAMIKI
sugi...@po.ntts.co.jp (Yoshitaka 'Railway' Sugishita) writes:
> ni...@ics.nara-wu.ac.jp (NIDE Naoyuki) writes:
> > ていたのに対し、JIS X0208を改正して「今後は過去互換の目的以外にはこれ
> > らを使わないようにしよう」と定めたということです。
> 一口に「過去互換」と言っても、いろいろあります。「今までずっとこのコ
> ード体系で扱ってきたのだから、変えたくはない」というのも「過去互換」の
> 一つです。
それは「過去互換」という言葉を誤読しています。
あれは「さっさと移行しやがれこのボケナスども」という言葉を超婉曲に表現したものだから。
# そう思う根拠は、先のポストで「... 使うな」と書いたことに誰もクレームつけなかったこと :-)
# オチが分からない人は JIS X 0208 の原文参照のこと。
でも前回の指摘はそれが本筋なのではなくて、X0208 の 7.2 項によって、暗黙のうちに
半角アルファベットによる検索:
検索エンジンが過去との互換を考慮して(移行前の)全角アルファベットも
ヒットさせることで、当該アルファベットの単語をすべて検索。
全角アルファベットによる検索:
移行してしまった文章を除いた、まだ移行前の文章群から全角アルファベットの
単語を検索。
という検索になってしまっていることを指摘してるのが本筋です。
この二つは全く目的が異なる検索なので、どちらが良いとか悪いとかいう観点で
語られるものではないでしょう。
ついでですが、
> In article <43d46cb2.01120...@posting.google.com>
> ルファベット』の推奨を行なっている」という意味ではなく、前述の元記事が
> 「個人の環境の存在を理由としたいわゆる『半角アルファベット』の推奨を行
> なっている」という意味です。
そうですね。それは読んでて感じましたんで、
前回のポストは「それは違うだろ」という指摘も兼ねています。
# そんなくだらん理由で HALFWIDTH ALPHABET へ移行推進されてる訳ではない。
--
かみきいちや
Yoshitaka 'Railway' Sugishita
Ichiya KAMIKI <kam...@geocities.com> writes:
> あれは「さっさと移行しやがれこのボケナスども」という言葉を超婉曲に表現
> したものだから。
私は、そうは解釈しません。
本当に「さっさと移行しやがれこのボケナスども」などと考えているのであ
れば、さっさと、例えば JIS X 0208 の０３区３３点～９０点を削除（附属書
へ移すなど）してしまうべきであると考えます。
もっとも、それは、解釈の違いですから、それ以上は何とも言えません。も
ちろん、かみきサンの解釈が間違っているなどと言う根拠はありません。
> > ルファベット』の推奨を行なっている」という意味ではなく、前述の元記事が
> > 「個人の環境の存在を理由としたいわゆる『半角アルファベット』の推奨を行
> > なっている」という意味です。
> そうですね。それは読んでて感じましたんで、
> 前回のポストは「それは違うだろ」という指摘も兼ねています。
了解です。
元記事の“推奨”の根拠が、見栄え，サイズ，検索の手間などではなく JIS
X 0208 を受けてということであったとしたら、そこまで反論する気はありま
せん（そもそも、反論したくてもできません）。
Kouichi Niimi
"Yoshitaka 'Railway' Sugishita" <sugi...@po.ntts.co.jp> wrote in message news:9v25cl$q43$1...@ssgw.ss.ntts.co.jp...
> で、日本語で書かれた文書に JIS X 0208 に規定された英数字を使用すると
> いうのは、「過去互換の目的」の一つなのですから、結果として、「使わない
> ようにしよう」の対象には含まれないということになりますね。
それは解釈が違うでしょう。
過去、JIS X 0208で書かれた文書の中では2Bytes英数字が
使われた物があるが、それは修正する必要はない。またそれ
らの文書を検索するのに、2Bytes英数字を使うのはやむを得
ない。しかし、今後作成される文書については2Bytes英数字
を使うべきではない。
というのが改正されたJIS X 0208で言いたいことでしょう。(と
私は解釈してます)
だから新しい文書を検索するのなら、2Bytes英数字を使うの
は適切ではなく、古い文書を検索するのに2Bytes英数字を
使うことはある意味適切であるんですね。
でも、「同じ単語」を検索するのに、2回も「別の単語」で検索
しなくちゃいけないのは嫌です。1Bytes英数字に統一される
事を私は望んでいます。
--
新美 浩一＠知多半島の住人
ni...@gld.mmtr.or.jp
IIJIMA Hiromitsu
引用順が前後します。
杉下さん:
> 本当に「さっさと移行しやがれこのボケナスども」などと考えているのであ
> れば、さっさと、例えば JIS X 0208 の０３区３３点～９０点を削除（附属書
> へ移すなど）してしまうべきであると考えます。
ご存じないようなので、詳しく書きますね。
実は、JIS X0208 には、この文字集合を単体で、つまり、ラフな言い方を
すれば「半角文字なし、全角文字のみ」というシステムで使用するケース
も想定されています。この場合では、JIS X0208 の英数字は、外部との
テキストのやりとりにおいて、ASCII の英数字と全面的に同一視されます。
これを前提にする限り、JIS X 0208 の 03 区を本体から削るわけには
いかないんです。
ではなぜ、半角文字と併用する場合は全角の英数字を使うべきでないと
されているのかというと、それは、「同じ文字に複数のコードを割り
当てない」という大原則があるからです。
これは、単一の文字集合の中で同じ文字を重複させない（たとえば、
JIS X0213 では NEC 選定 IBM 拡張文字の一部が正式に採用されましたが、
その一方で、NEC がコードを割り当てたあとで JIS C6226-1983（後に
X0208-1983 と改番）が別のコードを割り振ってしまった文字については、
NEC が割り当てたコードのほうは削除されて別の文字に充当されています）
というだけでなく、複数の文字集合を併用する場合にも適用されるべき
こととされています。
だから、たとえば日本語と韓国語が混じった文章を ISO-2022-JP-2 文字
コードで書くとすると、全角文字のうち、JIS X0208 と KS C5601 とに
重複してあらわれる文字（具体的には、15 区までの非漢字の大半と、
かなりの数の旧漢字）は、JIS のものと KS のものを両方併有することが
できないのです。韓国語文脈中の記号類は KS のコードで、日本語文脈中
の記号類は JIS のコードで記述したいのですが、それを規格が許さない
のです。
これと同じことが ASCII/JIS X0201 と JIS X0208 との併用の場合にも
言えて、「ASCII/JIS X0201 と JIS X0208 に英数字は重複して出現して
いるので、ASCII のほうだけを使用すべし」となるわけです。
もっとも、私自身はこの規定には全面的に反対しています…こんなの、
実用を無視して規格体系の美しさだけのためにある規定じゃん、と
思うわけです。別に重複したとしても大きな問題はないじゃん、強いて
言えば Unicode とかに変換してからさらに逆変換したときに元に戻せ
なくなることくらいだけど、逆変換可能性の確保ってそれほど大きな
問題なの？問題になるならそもそもそんな不可逆変換なんかしないで
処理すればいいじゃん、ってね。
かみきさん:
> あれは「さっさと移行しやがれこのボケナスども」という言葉を超婉曲に表現
> したものだから。
杉下さん:
> 私は、そうは解釈しません。
> もっとも、それは、解釈の違いですから、それ以上は何とも言えません。も
> ちろん、かみきサンの解釈が間違っているなどと言う根拠はありません。
私も、杉下さんに全面的に同意します。
理由は…縦書き組版の可能性のあるテキストの場合。縦書き和文中に
英数字を入れる場合、90 度回転して横書きにしてほしいものは所謂
半角で、そうでなく
新 Ｗ
し ｉ
い ｎ
機 ｄ
能 ｏ
が ｗ
た ｓ
く Ｘ
さ Ｐ
ん に
。 は
、
のように組まれてほしい場合は所謂全角で、という使い分けは、
旧来普通に行われてきたと認識していますし、これは充分に
「過去互換」のうちに入ると思います。
☆
かみきさん:
> 半角アルファベットによる検索:
> 検索エンジンが過去との互換を考慮して(移行前の)全角アルファベットも
> ヒットさせることで、当該アルファベットの単語をすべて検索。
>
> 全角アルファベットによる検索:
> 移行してしまった文章を除いた、まだ移行前の文章群から全角アルファベットの
> 単語を検索。
事実は逆のようです。
すべての検索エンジンがこうだと断言するわけではありませんが、
少なくとも Google では、
○半角で入れたら、半角にしかヒットしない
○全角で入れたら、全角・半角ともヒットする
→つまり、英数字は全角で入力した方が幅広くページを探せる
という結果になりました。
実験ですが、Google に「Ｗｉｎｄｏｗｓ９５ 日本語 FAQ」と入れてみて
ください。ヒットしたページ中の半角の「Windows95」の文字は強調表示
されていますが、全角で「ＦＡＱ」と書いてある部分は強調表示されて
いません。
ちなみに私自身の意見は、全角・半角どちらで入力しても、どちらも
マッチすべき、です。
========================================================================
飯嶋 浩光 / でるもんた http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta mailto:delm...@ht.sakura.ne.jp
mailto:delm...@pop01.odn.ne.jp
West@East as Jun Nishida
google での文書ヒットにかなりの誤解があるようなので補足。
あの検索結果の「強調表示」は、アルファベットに関しては ASCII 側に特化
してタグを生成しています。
<3C15ED67...@ht.sakura.ne.jp>の記事において
delm...@ht.sakura.ne.jpさんは書きました。
> いいじまです。
> 実験ですが、Google に「Ｗｉｎｄｏｗｓ９５ 日本語 FAQ」と入れてみて
> ください。ヒットしたページ中の半角の「Windows95」の文字は強調表示
> されていますが、全角で「ＦＡＱ」と書いてある部分は強調表示されて
> いません。
この時に、「Windows95」ではなく、「Ｗｉｎｄｏｗｓ９５」というキー
ワードの部分がどうなっているか確認されたのでしょうか。たぶん強調表示
されていないと思います。
＃ といっても、私が見た限りでは「Windows95」ばかりが見つかって、
＃ 「Ｗｉｎｄｏｗｓ９５」は見つかりませんが。
試しに、「P18n ＤＣ 杏仁豆腐」というキーワードで検索してみて下さい。
＃ ・・・我ながらなんつーキーワードだ (^^;;;
ではそういうことで。
--
from West@East as Jun Nishida(r...@mb.neweb.ne.jp)
West@East as Jun Nishida
＃ 致命的な間違いがあったので Supersedes: で出直しっ。
google での文書ヒットにかなりの誤解があるようなので補足。
あの検索結果の「強調表示」は、アルファベットに関しては ASCII 側に特化
してタグを生成しています。
<3C15ED67...@ht.sakura.ne.jp>の記事において
delm...@ht.sakura.ne.jpさんは書きました。
> いいじまです。
> 実験ですが、Google に「Ｗｉｎｄｏｗｓ９５ 日本語 FAQ」と入れてみて
> ください。ヒットしたページ中の半角の「Windows95」の文字は強調表示
> されていますが、全角で「ＦＡＱ」と書いてある部分は強調表示されて
> いません。
この時に、「Windows95」ではなく、「Ｗｉｎｄｏｗｓ９５」というキー
ワードの部分がどうなっているか確認されたのでしょうか。たぶん強調表示
されていないと思います。
＃ といっても、私が見た限りでは「Windows95」ばかりが見つかって、
＃ 「Ｗｉｎｄｏｗｓ９５」は見つかりませんが。
試しに、「P17n ＤＣ 杏仁豆腐」というキーワードで検索してみて下さい。
Kusakabe Youichi
> In article <GnzC4...@y.mcu.jp>
> Ichiya KAMIKI <kam...@geocities.com> writes:
> > JIS X 0208 には
> > 附属書 5 の表 1 ～ 2 でいわゆる半角カナおよび全角アルファベットを示し、
> > これまでの慣用的な利用との互換目的以外に使うな、と記しています。
>
> そして、日本語で書かれた文書に JIS X 0208 に規定された英数字を使用す
> るのは、「これまでの慣用的な利用との互換目的」の一つに他なりません。
もしそうだとすると、「それ以外」はどんな場合でしょうね? :)
Kusakabe Youichi
> In article <Go4wq...@y.mcu.jp>
> Ichiya KAMIKI <kam...@geocities.com> writes:
> > あれは「さっさと移行しやがれこのボケナスども」という言葉を超婉曲に表現
> > したものだから。
>
> 私は、そうは解釈しません。
解釈の問題ではないですね。
Kusakabe Youichi
> 私も、杉下さんに全面的に同意します。
>
> 理由は…縦書き組版の可能性のあるテキストの場合。縦書き和文中に
> 英数字を入れる場合、90 度回転して横書きにしてほしいものは所謂
> 半角で、そうでなく
>
> 新 Ｗ
> し ｉ
> い ｎ
> 機 ｄ
> 能 ｏ
> が ｗ
> た ｓ
> く Ｘ
> さ Ｐ
> ん に
> 。 は
> 、
>
> のように組まれてほしい場合は所謂全角で、という使い分けは、
> 旧来普通に行われてきたと認識していますし、
で、幅はどこにも関係ないのでは? そもそも。
これは充分に「過去互換」のうちに入ると思います。
入りませんね。 > そういう使い方を今後すること。
Yoshitaka 'Railway' Sugishita
IIJIMA Hiromitsu <delm...@ht.sakura.ne.jp> writes:
> 実は、JIS X0208 には、この文字集合を単体で、つまり、ラフな言い方を
> すれば「半角文字なし、全角文字のみ」というシステムで使用するケース
> も想定されています。
了解です。
> ではなぜ、半角文字と併用する場合は全角の英数字を使うべきでないと
> されているのかというと、それは、「同じ文字に複数のコードを割り
> 当てない」という大原則があるからです。
なんか、利用者の都合を無視して規格制定者の都合を押し付けているとしか
思えませんね。
＃ もちろん、「だから、そんな規格は守らなくてよい」などという話には、
＃なり得ませんが。
そういうことで、
> もっとも、私自身はこの規定には全面的に反対しています…こんなの、
> 実用を無視して規格体系の美しさだけのためにある規定じゃん、と
> 思うわけです。
同意です。
Kusakabe Youichi
> 思えませんね。
そう思い込いたいのですか? :)
> > もっとも、私自身はこの規定には全面的に反対しています…こんなの、
> > 実用を無視して規格体系の美しさだけのためにある規定じゃん、と
> > 思うわけです。
>
> 同意です。
「体系」はちっとも美しくはなりませんよ。そんなことしても。
ですので「美しさのため」ではないですね。
使うための規格なのですし。
IIJIMA Hiromitsu
> > > もっとも、私自身はこの規定には全面的に反対しています…こんなの、
> > > 実用を無視して規格体系の美しさだけのためにある規定じゃん、と
> > > 思うわけです。
> >
> > 同意です。
>
> 「体系」はちっとも美しくはなりませんよ。そんなことしても。
> ですので「美しさのため」ではないですね。
> 使うための規格なのですし。
そう、規格は使うためですよね。
私の場合、「単一の文字集合（character set）の中で同じ文字に複数の
符号化表現（encoding）を割り当てない」という原則は理解できるんです。
でも、「複数の文字集合を併用する場合であっても、単一の文字には
単一の符号化表現が対応しなければならず、したがって、両集合が
同一の文字を含む場合は、その一方の使用を禁止される」ってのは、
そういう制限を設けることによってどんなメリットがあるのか、
私には全く理解できないんです。
結局のところどうなんでしょう、ご教授願えませんか？
Junn Ohta
delm...@ht.sakura.ne.jpさんは書きました。
> でも、「複数の文字集合を併用する場合であっても、単一の文字には
> 単一の符号化表現が対応しなければならず、したがって、両集合が
> 同一の文字を含む場合は、その一方の使用を禁止される」ってのは、
> そういう制限を設けることによってどんなメリットがあるのか、
そうしておけば、同じ「文字」の列は誰が書いても同じ
コードの列になる、つまり正規化されるわけで、検索や
変換その他、そのテキストを利用する際のあいまいさが
なくなって利便性が高まりますよね。
> 私には全く理解できないんです。
ほんとに? ちょっと信じられませんが...。
--
太田純(Junn Ohta) (株)リコー/新横浜事業所
oh...@sdg.mdd.ricoh.co.jp
IIJIMA Hiromitsu
> > でも、「複数の文字集合を併用する場合であっても、単一の文字には
> > 単一の符号化表現が対応しなければならず、したがって、両集合が
> > 同一の文字を含む場合は、その一方の使用を禁止される」ってのは、
> > そういう制限を設けることによってどんなメリットがあるのか、
>
> そうしておけば、同じ「文字」の列は誰が書いても同じ
> コードの列になる、つまり正規化されるわけで、検索や
> 変換その他、そのテキストを利用する際のあいまいさが
> なくなって利便性が高まりますよね。
なるほど。たしかにそっち方面のメリットはありますね。
ただ私は、比較の際にはプリプロセスとして正規化プロセスを加える
とか、あるいは検索なら曖昧検索機能を使うとかいう方法で、このメリッ
トを享受すきものだと思うんです。すでに重複符号化が過去互換目的に
限ってとはいえ許容されてしまっている以上、機械にくわせる前のデー
タが正規化されているという保証はないわけで、そうすれば、データが
正規化されていることを保証するためには、どこかで明示的に正規化処理
を施す必要があります。で、その作業が既存のアルゴリズムで十分対応
可能な以上、「重複符号化禁止のデメリット」を全員に強制してまで規定
する必要があるのか、と疑問に思うわけです。
では重複符号化禁止のデメリットとは何かというと、もとは別々の文字
集合（たとえば JIS X0208 と KS C5601 ）を用いて書かれた文章を
継ぎ合わせて新しい文章を作った場合に、元のデータとの同一性が保証
されなくなるという問題です。
たとえば JIS X0208 の文章中で KS C5601 の文章を引用して ISO-2022-
JP-2 で保存したとして（ここで Unicode の話をするとややこしくなる
ので、ISO-2022 ベースの体系を想定してください）、そこから KS の
引用部分だけを切り抜いて EUC-KR なり ISO-2022-KR なりで保存したく
なった、というケースを考えてみてください。
このとき、重複符号化を許容すれば何の問題もなく、バイト列を抜き
出して、EUC 化するなり、ISO-2022-KR なら ESC ( $ C ..... ESC ( B
を ^O ..... ^N に置換するなり、とにかく単純な処理で、引用前の
文字列が再現できます。ところが、重複符号化を禁止して KS の文字を
JIS に 正規化して記録してしまうと、引用前の文字列を再現するため
には、JIS→KS の変換テーブルを保有して表引きするか、もしくは JIS に
なってしまった文字は欠字として下駄に置き換えるかのどちらかになり、
変換処理に手間を増やすことになります。
＃なお、世の中には JIS や Unicode の「包摂」のスキームすら拒絶する
＃人がいますが、私はそこまで頑固ではありません。
まあ、重複符号化の禁止が強制ではなくて努力義務程度なら、まだ納得
するんですけどね…。
Junn Ohta
delm...@ht.sakura.ne.jpさんは書きました。
> ただ私は、比較の際にはプリプロセスとして正規化プロセスを加える
> とか、あるいは検索なら曖昧検索機能を使うとかいう方法で、このメリッ
> トを享受すきものだと思うんです。
私はそれには反対です。
> すでに重複符号化が過去互換目的に
> 限ってとはいえ許容されてしまっている以上、機械にくわせる前のデー
> タが正規化されているという保証はないわけで、そうすれば、データが
> 正規化されていることを保証するためには、どこかで明示的に正規化処理
> を施す必要があります。
それはもちろんそうする必要があるでしょう。しかしそ
の処理より下流では正規化されたものがぐじゃぐじゃに
戻ったりしないという保証がほしい。
> で、その作業が既存のアルゴリズムで十分対応
> 可能な以上、「重複符号化禁止のデメリット」を全員に強制してまで規定
> する必要があるのか、と疑問に思うわけです。
強制しないかぎり、その「使い分け」に独自の意味をも
たせたりするばかものがどんどん出てくるわけですから
ね。正規化されていないデータが残る、あるいは新たに
出現すること自体はそんなに有害ではないと思いますが、
「使い分け」はまったくもって有害です。
たとえばいわゆる「パソコン通信」の時代に、文章の末
尾に1バイト仮名文字で「つぶやき」のようなものを書
くのがよく見られました。いまでも2ch方面などではよ
く見かけられます。で、あれを2バイト仮名に変換して
引用したときに「それはオリジナルと意味が違う」など
といわれるのはイヤだ、ということですね。あとは仮名
小文字の使いかたなどもそうですが、話がだいぶ外れる
のでこれ以上ここでは書きません。
> では重複符号化禁止のデメリットとは何かというと、もとは別々の文字
> 集合（たとえば JIS X0208 と KS C5601 ）を用いて書かれた文章を
> 継ぎ合わせて新しい文章を作った場合に、元のデータとの同一性が保証
> されなくなるという問題です。
その「元のデータ」ってなに? という話なんですが、テ
キストデータにそのコード列が表現している「意味」以
上の情報があると考えるのは間違いだと思うのですよ。
だから「意味」が保存されていれば同一性は保証されて
いると見たい。
> ところが、重複符号化を禁止して KS の文字を
> JIS に 正規化して記録してしまうと、引用前の文字列を再現するため
> には、JIS→KS の変換テーブルを保有して表引きするか、もしくは JIS に
> なってしまった文字は欠字として下駄に置き換えるかのどちらかになり、
> 変換処理に手間を増やすことになります。
それが「プリプロセス」や「曖昧検索機能」より不便で
あるという理由が私には見えないのですが...。
Kusakabe Youichi
> そう、規格は使うためですよね。
>
> 私の場合、「単一の文字集合（character set）の中で同じ文字に複数の
> 符号化表現（encoding）を割り当てない」という原則は理解できるんです。
原則ですので、いくつも文字集合があると、
どこかで重なっちゃう場合はありますね。
そうするとその原則からはずれますね。
で、その場合どっちを使うかっていうだけのルールの問題と思いますが?
Kusakabe Youichi
> > そうしておけば、同じ「文字」の列は誰が書いても同じ
> > コードの列になる、つまり正規化されるわけで、検索や
> > 変換その他、そのテキストを利用する際のあいまいさが
> > なくなって利便性が高まりますよね。
>
> なるほど。たしかにそっち方面のメリットはありますね。
「なるほど」でも「そっち方面は」どころじゃなくって、
それで充分だし、逆にいえばそれだけの話では?
> ただ私は、比較の際にはプリプロセスとして正規化プロセスを加える
> とか、
とかそういうののほうが、「どっちをつかうかきめておく」や「原則として重複しな
いようにする」よりもいい方法だと思うのはなぜですか?
> すでに重複符号化が過去互換目的に
> 限ってとはいえ許容されてしまっている以上、
こういうふうに「許容」の意味を大幅に勘違いするバカなひとにためにも、
もっときちんとわかりやすく禁止するべきだと私は思いますが。> JIS