文字コード総合スレ part2

>>931
頻度が100というのがよくわからないな。頻度じゃなくて出現回数ですね。
こういう場合、上位500件とか全体の95%の条件で切り捨てするのでは?
元にしたデータはもうちょっと再現性のあるものにしないと
偏りがありますね。逆にジャンル別統計データのような形で持っておくと
あとで合成するのにいいかも。

2,3バイトでの文字コード判定というのは危ないような。
4バイトあればbigramにしてもうちょっと精度上げられそうだけど。

日本語のでかいコーパスから出したbigram頻度、どっかに
落ちてないかな。

新聞社のCD-ROMとかが使えればいいんだけど
bigram頻度出すためには全文をテキストファイルで
アクセス出来ないと駄目だよね。
ttp://cl.naist.jp/nldata/corpus/
が参考になるかも知れないけど2006年時点で
95年度版CD-ROMを対象にしているあたり鮮度に問題がある。

青空文庫は文学に偏りすぎる。

Wikipediaのデータベースのダンプをダウンロードできるので
それを使う手もある。

言語処理学会入るというのは、ちょっと躊躇うなぁ^^;
ttp://www.nak.ics.keio.ac.jp/NLP/guide/admission.html

>>933
>頻度じゃなくて出現回数ですね。

そうです。

>こういう場合、上位500件とか全体の95%の条件で切り捨てするのでは?

データ量に対する判定精度への影響具合と元データの偏りやノイズを考えて
100未満のデータを切り捨てたですよ。

>2,3バイトでの文字コード判定というのは危ないような。
>4バイトあればbigramにしてもうちょっと精度上げられそうだけど。

そうですね。現在すでにバベルは実用上まず誤判定することがない
精度を達成できてると自負してますけど、より完璧な判定の為には
bigramの導入も考えるべきですね。

今思ったんだけどUnicodeの注音字母はU+3105から始まっててU+3100〜U+3104が空いてるのは何でだろ?

世界中で言語がバラバラになったのはバベルの塔のせいなのに

イザナギが振り向いたからじゃなかったっけ？

バベルの塔が崩れたのを察知して
イザナギが振り向いたとか。

バベルの塔は崩れてないだろ。

バベルの塔って新バビロニアの頃だからせいぜい紀元前6,7世紀だよな？

W3Cの勧告の数値文字参照の部分をどう解釈したものか迷っています。勧告の原文には
The syntax "&#xH;" or "&#XH;", where H is a hexadecimal number, refers to the ISO 10646 hexadecimal character number H.
とあります。では ISO 10646 character number とは何なのかと？

BMP面以外の文字を扱う場合、IEやFirefoxはサロゲートペアを解釈して1文字として表示するようになっているようです。
例えば、𠮷(𠮷) と書いても ��(��) と書いても、
上が「土」になってる「吉」が表示さます。環境によってはカッコ内に同じ文字が見えていると思います。

これはブラウザ側での勝手な拡張なのか、それとも、ISO 10646 にサロゲートペアの使用が含まれているということなのでしょうか。

ブラウザの勝手な拡張というかお節介なだけ。
実体参照の大文字小文字の区別だとか;の省略だとかそういった
いやーな実装の一つだな。

# n文字以上入力してくださいというところにサロゲートペアで
# ねじこむとか荒業出来そうだねぇ。>セキュリティ方面
# あ、あと別に16進じゃなくて10進で書いても同じ動作だろう。

>>943
サロゲートペアを1文字と解釈するのは「バグ」
Firefox3.0では表示されないようになってるね。

この場合サロゲートペアと呼ぶのも正しく無い感じがする。
なんだかんだあったけどISO10646=UCS-4で扱っていいんだよね?
UTF-16で表現するときにだけサロゲートペアが発生する。
ISO10646とかUCSが求められている場所ではサロゲートの領域のコードが
出たら駄目でしょ。

Unicode=UCS2だとおもって今まで実装してきたのに、
突然Unicode=UTF-16だと言われても、困ります。
サロゲートペアをフォントに紐付ければいいだけだろって
そんな単純な話じゃないんですよ、みたいな。

遅くなりましたが、皆さんありがとうございます。
やはり素直に解釈すれば、ISO 10646 character number とは UCS-4 におけるコードポイント、
ということになりますね。

実は、テキスト文書に含まれる文字のうち、ある文字コードで扱えない文字を数値文字参照に
置き換える、というソフトを作成していまして、その実装をどうするかで迷っていたのです。
サロゲートペアは一切扱わない方向で行くことにします。

今気づいたけど、>>943をOpenJaneのポップアップで見ると、𠮷が土吉じゃなくて
TAMIL LETTER SSA になってる。
どうも下位16ビットしか見てないようですね。

(´-`).｡oO(Janeスレで報告してくるか……)

結局、「異体字タグ」ってこれのことなんでしょうか↓
http://www.unicode.org/Public/UNIDATA/StandardizedVariants.html

個人的な名簿の整理をしていてふと気になって調べてみたのだが...
日本語で恩恵を受けられるようになる日はいつのことやら。

MacでAJ15使ってれば
そのうちIVSの読み込み／書き出しがサポートされるんじゃね？

>>948
ユニコード(UCS-4)に変換して数値文字参照にするなら、サロゲートペアなんて
出て来ないから普通に組んで問題ないと思うよ。
数値文字参照からUCS-4にしたときに0xd800〜0xdfffが出てきたらおかしいから
弾かないと駄目。

ISO/IEC2022の表記方法で0/0とか7/15とかいう記述があるのですが、
どういう意味なのでしょうか？
どなたか教えて

書いた人の定義による、出典だせ

出典というほどのものではないですが
ここのサイトで見ました。
ttp://www.wdic.org/w/WDIC/ISO/IEC%202022

どうやら0/0は0x00, 7/15は0x7Fのように自分には見えました。
でも敢えて0/0のように記述しているのはそれなりの理由があるのでしょうね。

規格票がそういう流儀だから。

ありがと。

>>606のサイトで規格票を読める。

>>951
少し試してみました。TextEdit.appのRTFってCID埋め込めるんですね。

で、異体字を Excel とかでも使いたいんですが、
タイプセットと関係ない一般のアプリでCIDを使う訳にはいかないんでしょうねえ。

日本では公的な標準があまりに非力だから仕方なく一部で使われてるけど
CIDってそもそもそういうこと(一般的な情報交換)に使うためのものじゃないからねえ
まさにそのためにIVSが定義されようとしているわけだし

>>944
;の省略はブラウザのお節介ではなく仕様で認められてる場合がある。

>>937
昔は原規格の並びをそれなりに反映してるっぽい並びで収録されることがあったからだと
思われ(Big5のbopomofoは0xA375〜)。
BMPに余裕がなくなってきた最近ではとにかく空いてるところに詰め込む感じになってるけど

> Big5のbopomofoは0xA375〜
すまん嘘だった。0xA374〜じゃんorz

Extension Cに投票でツッコミが入りまくってAmd.5に回された。
まあレビューが正常に機能してる証拠だとも言えそうだが。
Adobe-Japan1がAmd.3に入りそうなのはいいけど早すぎて品質が心配

Wikipedia に

UCS-4
　31ビットを使うコード。4バイトを基本とするUCS。Unicodeの符号化方式であるUTF-32と似ている。
　Unicode以外のコード（0x10FFFF以降）も使用できるという点が異なっていたが、
　2006年の改訂によりUnicodeで使用できない領域には永久に文字が定義されないこととなった。
　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
って書いてあるんですけど、
ISO/IEC 10646 自体が 22〜31 ビット目を使わなくなった、ということではなくて、
ISO/IEC 10646 のサブセットである UCS-4 は 22〜31 ビット目を使わないけど、
ISO/IEC 10646 自体はまだ 22〜31 ビット目を持つ文字も使えるようになってる、
ということなのでしょうか？

ISO10646=Unicodeなので22〜31ビット目は使われない。

ISO/IEC 10646 ⊃ Unicode ではなくて？

>>967
その認識は古い。

うーん。
http://www.unicode.org/faq/unicode_iso.html
にある
＞文字コードと符号化方式は同期を取っていますが、Unicodeは実装上の適合性を重視しています。
＞このため、ISO/IEC 10646で規定していない、拡張した機能文字、文字データ、アルゴリスム、背景資料などを提供しています。
というのが微妙に分からないんですけど、
要するに ISO/IEC 10646 は文字コードや符号化方式のみを規定していて、
Unicode はそれを実際に実装する際の話も規定しているという話であってますか？

UCS は Unicode にはないよね？

Unicode は UCS にはないよね？

あいや、UCS-2 や UCS-4 という用語は Unicode にはないよね、と。

ナイアルヨ

結局 UCS の群(group)って意味なかったのかね。

UCS-3が開発されたりしてｗ

The most significant octet of this sequence shall be the group-octet.

とまで書かれていたのに・・・。

>>976
それは「BEだぞおめーら」って意味じゃ?

そういう場合に significant って使うの？

「最上位ビット」という意味の "MSB" の S は Significant だよ。

なるほど。そうなんだ。

>>969
> 文字コードと符号化方式は同期を取っていますが、

文字コードも符号化方式も
UnicodeとISO/IEC 10646の間で同期していますが、

> Unicodeは実装上の適合性を重視しています。

Unicode標準は、プラットフォームやアプリケーションが違っても、
統一的に文字を扱う事を確実にする実装上の制約も課しています。

「要するに〜？」についてはYES。
実装を規程している訳じゃなくて、
(実装するなら当然必要になるような)その他のことも規定してる。
「実装」に特にこだわってその文を解釈する必要はない。

なるほど。よくわかりました。