PostgreSQLのメーリングリストでミラクルリナックスの森山さんがEUCの仕様に関して分かりやすい分類をしてくれていたので忘れないようにメモをしておく。

4, 5, 6 は森山さんが名前を付けたものとの事だが非常に分かりやすく定義付けをしてくれていると思う。

個人的には環境は出来るだけUTF-8に統一するようにしているがそうも行かない環境もあるところが痛いところかと。

今回は本当にメモ。要約無し。
後日まとめる予定。

3 符号化文字集合（ ccs ）

A coded character set is defined to be a mapping from a set of abstract characters to the set of nonnegative integers. This range of integers need not be contiguous. In the Unicode Standard, the concept of the Unicode scalar value (cf. definition D28, in Chapter 3, "Conformance" of [Unicode]) explicitly defines such a noncontiguous range of integers.

符号化文字集合は。抽象的な文字集合から負でない整数のセットに
対応付けされている事により定義されています。
この整数の範囲は連続する必要はありません。
ユニコード標準に於いて、ユニコードスカラバリューの概念は
明らかにそのような非隣接の範囲の整数を定義します。

An abstract character is defined to be in a coded character set if the coded character set maps from it to an integer. That integer is the code point to which the abstract character has been assigned. That abstract character is then an encoded character.

抽象的なキャラクタは、符号化文字集合は抽象的なキャラクタに対する
整数での対応付けであるなら、符号化文字集合にあるように定義されます。
その整数は抽象的なキャラクタが割り当てられたコード・ポイントです。

Coded character sets are the basic object that both ISO and vendor character encoding committees produce. They relate a defined repertoire to nonnegative integers, which then can be used unambiguously to refer to particular abstract characters from the repertoire.

符号化文字集合はISOとベンダー文字符号化委員会の両方が作り出す基本的なオブジェクトです。
それらは負でない整数に定義されたレパートリーとして定義されます。
そして、レパートリーから特定の抽象的なキャラクタについて言及するのに使用することができます。

A coded character set may also be known as a character encoding, a coded character repertoire, a character set definition, or a code page.

符号化文字集合は文字エンコーディング、文字集合定義、符号化された
文字レパートリー、コードページとしても知られています。

In the IBM CDRA architecture, CP ("code page" ) values refer to coded character sets.

IBM CDRAアーキテクチャでは、CP値は符号化文字集合について言及します。

Note that this use of the term code page is quite precise and limited. It should not be -- but generally is -- confused with the generic use of code page to refer to character encoding schemes.

danさんのブログで見つけたが、なんとも言いがたい。

コーパスの母体がwebサイトである事を考えるとアダルトサイトが多くを占めること、
「ちんこ」も「チョコ」も品詞では同じ扱いであることを考えると
出現頻度が高いほうがより上位に来るのだろうなと。

因みにmecabとipadicで解析すると以下の通り。

でかいチョコ
でかい 形容詞,自立,*,*,形容詞・アウオ段,基本形,でかい,デカイ,デカイ
チョコ 名詞,一般,*,*,*,*,チョコ,チョコ,チョコ
EOS
でかいチンコ
でかい 形容詞,自立,*,*,形容詞・アウオ段,基本形,でかい,デカイ,デカイ
チンコ 名詞,一般,*,*,*,*,*
EOS

同じ、一般名詞扱い。

やはり、単語のメタ情報が少ないなと。

mecabの処理内容がいまいち理解できていないので(※1)
この手のメタ情報を付加することにより、より言語情報が充実すれば
「検索エンジン空気嫁」が実現するのではないかなと夢想してみる。

まずはmecabのソースの解析かな。

※1マルコフ連鎖がまるでさっぱり。

編集ミスの為修正中(修正した。)

文字コードを理解する為の手段としてテキストを色々いじって遊んでみた。

用意するもの

• UNIXマシン(家ではFreeBSD 6.2)
• iconv(GNU libiconv 1.11)
• 適当なテキスト(コードは何でも良いがUTF-8で用意した。)
• hd(大概UNIX機に入っている)

用意したテキストは以下の通り

% cat utf8text.txt
春
は
曙
。
ようよう赤くなり行く山際。

枕草子の第一節であるが、最初の部分に改行をわざと入れ変化を分かり易くしてみた。

hdはmanの「-C]を参照。
アスキー部分は見にくい為削除。

UTF-8

% cat utf8text.txt| hexdump -C
00000000 e6 98 a5 0a e3 81 af 0a e6 9b 99 0a e3 80 82 0a
00000010 e3 82 88 e3 81 86 e3 82 88 e3 81 86 e8 b5 a4 e3
00000020 81 8f e3 81 aa e3 82 8a e8 a1 8c e3 81 8f e5 b1
00000030 b1 e9 9a 9b e3 80 82 0a
00000038

規則性により「0a」が改行コードであることがわかる。(LF)
一行目を見やすく並べなおしてみる。

「e6 98 a5」=「春」
「0a」 =「LF」
「e3 81 af」=「は」
「0a」 =「LF」
「e6 9b 99」=「曙」
「0a」 =「LF」
「e3 80 82」=「。」

3byteの文字と１byteの制御コードになっている事が見て取れる。

UCS-4

% iconv -f UTF-8 -t UCS-4 utf8text.txt| hexdump -C
00000000 00 00 66 25 00 00 00 0a 00 00 30 6f 00 00 00 0a
00000010 00 00 66 d9 00 00 00 0a 00 00 30 02 00 00 00 0a
00000020 00 00 30 88 00 00 30 46 00 00 30 88 00 00 30 46
00000030 00 00 8d 64 00 00 30 4f 00 00 30 6a 00 00 30 8a
00000040 00 00 88 4c 00 00 30 4f 00 00 5c 71 00 00 96 9b
00000050 00 00 30 02 00 00 00 0a
00000058

４byteの固定長であることがはっきり判る。
「00 00 66 25」=「春」
「00 00 00 0a」=「LF]
改行コードも4byteである。

UCS-4はUnihan Databaseで確認可能なので確認してみる。
結果を見ると「00 00 66 25」が「春」であることが分かる。
一緒にUTF-8も確認可能。

UTF-16

% iconv -f UTF-8 -t UTF-16 utf8text.txt | hd
00000000 fe ff 66 25 00 0a 30 6f 00 0a 66 d9 00 0a 30 02
00000010 00 0a 30 88 30 46 30 88 30 46 8d 64 30 4f 30 6a
00000020 30 8a 88 4c 30 4f 5c 71 96 9b 30 02 00 0a
0000002e

指定が無いのでBOM「fe ff」がついている。（feffなのでリトルエンディアン。Core 2 Duoだしね。）

eucJP

% iconv -f UTF-8 -t eucJP utf8text.txt | hd
00000000 bd d5 0a a4 cf 0a bd ec 0a a1 a3 0a a4 e8 a4 a6
00000010 a4 e8 a4 a6 c0 d6 a4 af a4 ca a4 ea b9 d4 a4 af
00000020 bb b3 ba dd a1 a3 0a
00000027

固定長(ただし、改行コードは1BYTE)

SJIS

% iconv -f UTF-8 -t SJIS utf8text.txt | hd
00000000 8f 74 0a 82 cd 0a 8f 8c 0a 81 42 0a 82 e6 82 a4
00000010 82 e6 82 a4 90 d4 82 ad 82 c8 82 e8 8d 73 82 ad
00000020 8e 52 8d db 81 42 0a
00000027

EUCと番地が違うだけという感じ。(SJISの方が元だし逆か。)

以上のように並べてみるだけでも結構面白いかも。

元々言語学日本語専攻だったという事もあり、
かなり以前から形態素解析に対する違和感を感じていた。
(※アンチ生成文法論者だったという事も有るが。)

特に形態素の指定の仕方と分類の仕方が特にである。

日経BP曰く、
自然言語で書かれた文を「形態素」に分割する技術のこと。
形態素とは言語として意味を持つ最小単位を指す。
形態素に分割して，品詞を見分ける。

象徴的に取り出してみたが、要点は以下の通りである。

指定の仕方としては、「言語として意味を持つ最小単位」という指定はいいのだが、
最小の意味合いが曖昧でどうとでも取れてしまう所に疑問があった。

いくつかの疑問はあるが、一例として「都道府県」、「大中小」などをあげてみる。
mecabで解析してみると以下の通りである。

都道府県 名詞,一般,*,*,*,*,都道府県,トドウフケン,トドーフケン
EOS
大中小
大 接頭詞,名詞接続,*,*,*,*,大,ダイ,ダイ
中小 名詞,一般,*,*,*,*,中小,チュウショウ,チューショー
EOS

同じような言葉の使い方であるが複数の取られ方をしている。

この場合、形態素は「都」、「道」、「府」、「県」であるのか、
「都道府県」であるのか曖昧である。

分類の仕方に関しては、最小単位に分けた後、無条件に品詞分類をしていることである。
特に、何をもってして品詞とするのかをあまり煮詰めずに「品詞」としているところに疑問を持つ。

橋本文法の位置づけには
昔から色々と異論が有るのだがその辺りがまったく考慮されていないところに違和感を感じる。

また、単語(形態素でも良いが)のメタ情報が品詞だけというのも貧弱すぎると思っていた。

これが今まで思っていた形態素解析の違和感である。

先日、言語解析の調べ物をしていて、KOTONOHAが
面白い言語解析を用いていることを知った。

言語単位の指定方法である。

詳しくはKOTONOHAのサイトを参照してほしいが、
単語のメタ情報を格段に増やしたところにポイントがあると思う。

この、文献を見つけた時、長年の引っ掛かりがかなり解消されようやく
「形態素解析」（というのも怪しいが)が自分の中に落ちてきた。

解析辞書も公開されている。unidic

mecabに対応していないところが痛いところであるが、解析してみるのも面白いと思う。
とりあえずしばらくはこの辞書で遊んでみる。

UNICODE続き

ACR

Characters vs. Glyphs

キャラクターは文字をあらわす図形の抽象概念でグリフは複数の目に見える具体的な字体の事。

Compatibility Characters

キャラクターにおいては歴史的な理由により複数の図形を許可している。

また後日追記予定......。

引き続きUNICODEのメモ

ACR

抽象化済みの文字のレパートリー (Abstract Character Repertoire)
※訳しようが無いのですが勝手に無理やり訳してみました。

文字のレパートリーとは抽象化された不規則な文字セットとして定義されています。

ポイントは次の一文です。
The word abstract means that these objects are defined by convention.

abstract という単語はそれらの物体が慣習で定義されていることを意味します。
つまりは定義が曖昧だという事ですね。

後日追記予定。

以下追記

日本語の例としてはJIS X 0208があげられている。

注意!

個人的なメモなので突っ込みは歓迎ですが鵜呑みにしないでください。

UNICODEのエンコーディングモデルに関する考え。

詳細はUnicode Technical Report #17を参照(※誰か邦訳して。)

何回かに分ける予定。

UNICODEに於いて、「キャラクターエンコーディングモデル」を4つの階層に分けて考える。

１． ACR: 抽象化済み文字対称集合
抽象化済みの文字のレパートリー※1(Abstract Character Repertoire)
２． CCS: 符号化文字集合(Coded Character Set)
３． CEF: 文字符号化形式(Character Encoding Form)
４． CES: 文字符号化方式(Character Encoding Scheme)

各階層について順次詳細を記述する。

......ACRの説明の前にノーマライゼーションの方が必要かなぁ。

※1勝手訳が気に入らないので訂正。

わかり辛い文字コードの話。

説明している際に自分でも混乱するので備忘録として書留る。
UCSとUnicodeは符号化文字集合、要するに文字セット(文字表)の事。
主な違いは策定団体。
UnicodeはUnicodeConsortiumが作成した21ビットの文字集合。
Unicode 3.1など
ISO/IECはUnicodeConsortiumの文字セットを基にしてUCSを標準化したが31ビットまで拡張している。
UCS-4など
文字符号化方式は共にUTFを用いる。
8ビット単位の可変長コード（1〜4バイト）にエンコードするUTF-8等。

書いている内容に色々問題が多いので全訂正。
そのうち訂正記事を書こう。

符号化文字集合と文字符号化方式の混同は避けよう。
自戒を込めて。