2010/10/02

困ったことに、記事でばれるAllAboutのレベル

AllAboutの記事のクオリティに疑いが
 今まで、AllAboutってそこそこの記事を書いてると思っていて、わりと信頼できると思って読んできたのだが、こんなにひどい記事もあるのね。

 下の引用部以外もかなり時代錯誤でびっくりしました。
2005年更新の記事なんだが。ハンパないデジタル音痴っぷり。1995年でも馬鹿にされるレベル。
2005年の更新のときにAllAboutは見直さなかったのか。そもそもAllAboutには記事を見直すことがないのか(その割に、2005年に何を更新したんだ)。

引用とツッコミ

これからはメールアドレスがないと情報収集に不利です。

メールで送る情報はデジタル情報です。困ったことにデジタル情報は簡単にコピーができ著作権法上問題になっています。
—All About | 名刺でばれる会社のレベル

「困ったことに」て!!!!
「困ったことに」て!!!!
「困ったことに」てっ!!!!


つっこみ1
 名刺とメールアドレスの記事にデジタル批判をねじこんでくるて、どんだけデジタル嫌いなんだよ。

つっこみ2
 名刺にメアド書けとか、なにをいうてはるの。2005年の更新のとき何を思って更新したのか。

つっこみ3
 「URI書くな検索してもらえ」はIT化されてない企業を対象にした記事で言うことじゃない。
 検索でヒットするかは企業名に依存するし、対象読者層は確実にSEOはしてないのだから、検索つかえと言うのも頭おかしい。
 最悪、フィッシングサイトに誘導してしまったり、悪い噂を読まれたりしたらどうするの。

こんな記事を放置してきたのはなぜなのか
 100歩ゆずってAllAboutができた2001年に書いたと仮定しても、十分おかしな内容だ。お金をはらって書かせた記事とは思えない。しかし、2005年に更新したときは時代背景を見ても異常といっていい。
 その時にこの内容を見逃したのはなぜなのか。
 いまだにそのままなのなぜなのか。

 
 査読や見直しが機能してなさそうということや、記事のタイムスタンプが内容の鮮度と無関係という問題は、同じ仕組みで編集されているAllAboutの記事全般に共通の問題だと思われます(他分野の記事でも)。
 AllAboutへの信用、かなりがたおちでありますよ。
 気をつけて読もう。

2010/10/01

書きかけメモ Re: 日本語の横棒記号に絶望した

このテキストは、そもそも http://taichino.com/programming/1384 へコメントしようと書き出したものだ。
しかし、書きかけというレベルにも至っていない。
なぜなら、調べながら書いているうちに、自分の言いたいことも上記記事の言いたいこともよくわからなくなってきて、そもそも、何かを言うには自分の知識が圧倒的に足りないということに(ようやく)気づき、書きあげることを断念した、編集中のテキストと調べ物のメモの断片だからだ。
ただ、メモとして、自分のための記念として、さらしあげ公開。
いつか知識がふえたら、ちゃんとしたものがかける日がくるのか。

http://slashdot.jp/comments.pl?sid=1397&cid=33913
などを読むと、懐かしいというかなんというか。
えらく歴史のある話のわりに、きれいにまとまったという情報は見当たらない。
しかし問題意識は沈静化したようで。何が、どうなって、どうなんだ。


以下、本文


全角半角の話と、横棒記号が使い分けられないほど多いという話は、同じ領域の別の話だ。別の話のようで同じ話だ。
 Aがたくさんある
 ダッシュもたくさんある

・見た目の違う(nの幅とmの幅のダッシュ)を違う記号としたことについて、入れるなとは言えないが、いくらなんでも堂々としすぎである。お隣にどどーんと。16bitにつめこむために、ユニフィケーションして grep 毛沢東 は強行したのに?
・そもそも grep 毛沢東 は、32ビットになった今、どうなったんだ。
・骨はどうなってるんだ。
・はしごだか が実装されたのは聞いた。しかし骨がどうなったのかがわからない。

・見た目で区別できないものを使い分けることは相当むずかしい。かといって区別する手段を封じるのもナンセンスだ。


・bloggerはトラックバックできねー。どうするべか。

ユニコードがでかいのは仕方ない
Unicodeを中間コードとして経由して文字コードを変換する際も、できるだけ情報が落ちないようにしよう、ということで、あんなにも大きな文字集合になったのではなかったでしょうか。
規格の意図が違うため、多すぎるからセンスがない、とはすこし言いきれないと思います。
区別して使う人はいなくても、区別して使うシステムは多いとも思います。

ウェブで使うにはナンセンスで腹立たしい状況であることに同意しますが、それは必要があった上での必然ではないか、と思いますがどうでしょうか。

今まで、Aとaを同一視しスペースやタブや混乱した改行コードをうまいこと処理しなければならなかった状況でした。それと、根本的には変わっていないのではないか、と思います。
必要なときはプログラマーに面倒をひきうけてもらおう、という意図そのものが汚いということならば、その通りかもしれません。
しかし、そういう泥臭いことをしなかったら、普及しうる共通コードにならなかったと思うのです。



そもそも半角全角は要るの?
そもそも、な話です。

そもそも、半角全角は(互換性に対する需要以外で)要るのでしょうか?
いろいろなダッシュ、マイナス、ハイフン、罫線、横棒と同じく、互換性のためだけの過去の遺物で、そもそも今後は要らなくなっていくのではないでしょうか。
文字幅の指定を文字コードが担う現状こそが特殊に思えます。
過去のことを考えなければ、全角半角を別の記号として規格化しようと考えないと思います。

そもそも、ウェブ上でダッシュやマイナスなどを文脈から区別できるとは思いません。
そもそもウェブの文法が存在しないからです。
たとえばこんな状況ではどうでしょう:
  • 表を出力するウェブアプリケーションがあります。そのアプリはデータなしの場合、水平線(長い横長のヘアライン)を出力します。そのアプリに、陰性、陽性を入力すると、陰性を示すマイナスと水平線が同じ記号だったら、出力された表からは陰性とデータなしを区別できません。
  • 数学の参考書を書いているとき、数式をのちに指示するため、末尾にダッシュと数字をつけたい。そんなとき、ダッシュがマイナスと同じ記号なら、式のつづきなのか、式の番号なのか、区別できません。

  • あるコンテンツを、表示デバイスによって横書き表示、縦書き表示に切り替えるときは? 縦書きのときダッシュならば縦線になりますが、マイナスやハイフンは前後の数式や西欧の単語と同じ扱いで切り替えることになるでしょう。

  • 「絶対0度--273℃-の世界では、」とテキストで表すと一緒になる。-273で検索できない。ダッシュ273と同じになり、(おそらく何かの目次などが)大量にノイズとしてヒットする。

  • 解析、検索の手段が絞られ、ノイズが増えてしまいます。たとえば:「カレー3杯」がマイナス3やカレを含む。「ハレー彗星」がハレを含む。「エルニーニョ」がエルニとニョを含み「エル ニーニョ」がニとニョを含む。

最後の例などは「web上の日本語を解析するのがどんなけ面倒になるか」という言葉がそのまま当てはまると思います。 意味がまったく違うものを、見た目が(ある状況下では)似ているというだけで、同じ記号としてしまうのは問題。 同一視のための作業がいらない分、区別したいとき手がかりを文脈や辞書など他から手に入れなければならない。 情報を推測するより、情報を削るほうが簡単、という法則(今かんがえた)に則ると、 文字コードは、文字が少なすぎるより文字が多すぎるほうがまし。 世の中にはデータマイニングをする立場では関係ないが、記録したものを再生するためには情報の欠落はあってはならない。他の文字コードからの変換に限らず、マイナスとダッシュは違う意図をもって書かれることがある。そうでない人が書いたものはノイズになるが、ノイズは削りうる一方、無いデータは補えない。
1対1対応じゃない。
全角半角の対応は、Unicodeの中でも厳密なものではない。
別の文字コードとの対応はしっかり考えられたようですが(cf. ラウンドトリップ コンバージョンなど)、全角半角や半角カタカナで同一視の扱いは曖昧なものだと思います。

半角にはアルファベットとカタカナしかないこと、ヮがないこと、濁点や半濁点のついた文字がないことなど、はなから半角と全角は1対1に対応していません(そういう意図で作ったものでもないので当然ですが)。
半角と全角の両方をつめこんだ文字コードを作った時点で、互換性のために多くを犠牲にしたものだったのではないでしょうか。
それを、Unicodeの時代にまでひきずってきてしまったわけで、半角全角の2種類があることは負の遺産です。

半角と全角の存在を認める一方で、
(長音記号とマイナスとダッシュのような)意味が違うものを別の記号とすることを、センスがないと切りすてる間には、大きな矛盾を感じます。

全角半角にこだわった変換ライブラリ(への需要)が、レガシーな仕組みにとらわれていると思います。
その前に、ラウンドトリップコンバージョンを削ってよい状況ではレガシーフリーにできるような、ユニコードのクリーニングの仕組みを我々にほんじんは(?)目指していくべきではないでしょうか、かきかけ。

「半角と全角の2種類にするべき」という意見について、これこそ古いものだと、僕は認識しています。
Unicodeでの全角・半角のサポートは互換性のためで、これから忌み嫌われ消えるのではないかと思います。


「ナ゙ン゙デズド!?」→「な゛ん゛です゛と゛!?」or「な゛ん゛て゛す゛と゛!?」(1文字になおすほうがいいか否か)
「ほわゎん」→「ホワワン」(半角「ヮ」がないから仕方ないとはいえ元に戻らない)
「Osaka~Tokyo」→「Osaka~Tokyo」(波ダッシュをチルダにするよりも、マイナスorダッシュにするべき状況もあるのではないか)

ハイフンやマイナスも例外ではなく、アプリケーションを見据えてどうするか対応することであって、
単純に-の全角がマイナスかというとダッシュが適切な場合もあると思います。

コードポイントはU+、チルダはN、セプテット・ノネット、キビ

コードポイントえらい、チルダはN、セプテット・オクテット・ノネット、キビダンゴ などについて。

コードポイントはえらい

Unicodeはコードポイントで考えよう。
何があっても絶対だということになってる(少なくともUnicodeさんの中では)。

表記は U+数 とするので、変に0xなんとかって書かないほうがいいかもね。
数は非負の整数です。なんてシンプル。うつくしい。


チルダはN
チルダは~はNが変化したものなので、左側が山で右側が谷でなくてはならない。鼻濁音を表す。

波ダッシュは Unicode の規格本の編集(?)ミスにより混乱
なんと(事実上の)印刷ミス!!!!!

UTF-8 には BOM はない
UTF-8にはバイトオーダーがないので、BOM(Byte Order Mark)と言われることのあるものは真のBOMではない。

バックスラッシュとyen記号のややこしさは、他国でも存在!Unicodeにも今のところ救いなし!


情報の単位とか
byteって何なのよ?
バイト9bitのシステムもある
1バイトが7ビットのシステムだけでなく、9ビットのシステムもある。
むしろ現役!
UTF-9・UTF-18・36ビットワードマシンなどについて調べられたし。

バイトは本来1文字(欧文)。5ビットから12ビットまであったという伝説もある。詳しくは調べられたし。

octet以外は?
オクテット(octet)はもともと8重奏、8-組というような意味。
RFCにも 7bit = septet, 9bit = nonet という表現は見つけられたので
よって一般に2bit~10bitまでについても、duet, trio, quartet, quintet, sextet, septet, octet, nonet, dectet という表現が使われるのが自然か。11,12は対応する表現を調べられず。


キビ、メビ、ギビ、テビ、など大きい単位
キビ = 1024^1 = 2^10
メビ = 1024^2 = 2^20

kibi = kilo binary = Kio
mebi = mega binary = Mio
gibi = giga binary = Gio
tebi = tera binary = Tio
pebioctet (Pio), exbioctet (Eio), zebioctet (Zio), yobioctet (Yio), …

テラとテビに至っては一割も違う!!! 2010年現在、ハードディスクがちょうど1テラを越えたかどうかという時代で、ストレージ容量表示がなかなか適正化されないのにも合点がいくのだ(納得はいかんが)。
1 tebioctet = 2^40 octets = 1,024 Gio = 1,099,511,627,776 octets
1 teraoctet = 10^12 octets = 1,000 Go = 1,000,000,000,000 octets

ちなみに、キビダンゴ=1024だんご ということになる。