【UTF8】文字コード変 ..
239:デフォルトの名無しさん
04/02/11 23:36
>>237
イオさんという人が昔「拡張シフトJIS」「拡張EUC-JP」「拡張ISO-2022-JP」
とかいうの考案してましたね。サイト消えちゃったけどWayBack Machineから発掘
URLﾘﾝｸ(web.archive.org)
> Shift_JISで直接Unicode文字が使えたら機種依存文字の問題はなくなると思うんだけどね…
GBK/GB18030はGB2312と上位互換を保ったままUnicodeの文字を
全部使えますね。
Unicodeに移行しようと思ったら既存のデータを全部変換するか
捨てる必要があるシフトJISやBig5圏から見たらうらやましい限り。
240:デフォルトの名無しさん
04/02/12 12:14
>>238
端的にいうと、JIS X 0208の未定義領域を利用して、Unicodeのサロゲートペアみたいに、
面サロゲート、区サロゲート、点サロゲートの3文字(合計6バイト)を組み合わせて
(サロゲートトリオと呼ぶことにします)JIS X 0208にない文字を表現するんです。
たとえば面サロゲートは09区〜12区、14区〜15区、85区〜88区のどこか、
区サロゲートは93区、点サロゲートは94区を使用することにします。
13区と89区〜92区はWindowsの外字と衝突するので使用しません。
多分面サロゲートは940文字も要らない(*1)と思うので85区〜88区だけでいい
(*2)とは思いますが。
(*1)使える総文字数は940*94*94-(940+94+94)=8304712文字
(*2)使える総文字数は376*94*94=(376+94+94)=3321772文字
>>238
すみません。「?」はJIS X 0201/ASCIIのほうを使用しろということでしょうか。
「機種依存文字」は「JIS X 0208未定義文字」、「Unicode文字」は
「Unicodeに含まれてJIS X 0208に含まれていない文字」のほうが正しい言い方ですね。
上のほうでも「Windowsの外字」なんて怪しげな言葉を使っていますが、ご勘弁を…
241:デフォルトの名無しさん
04/02/12 13:18
>>240の続きです。
85区01点はJIS X 0213第1面(第3水準)に収録されている文字のうち、
JIS X 0208に含まれない文字を区点番号はそのままで収録します。
JIS X 0208に含まれている文字の場所は空けておき、使用禁止にします。
同じように、85区02点はJIS X 0213第2面(第4水準)に収録されている
文字を収録します。
85区03点はJIS X 0212(補助漢字)を収録します。
Unicodeに収録されている文字は0x000000〜0x10FFFFの1114112文字
(サロゲートペアは使用を禁止するが、文字数には含めておく)ですが、
これを94進法でサロゲートトリオの各サロゲートを求めます。
面サロゲートは全部で127個必要になりますので、85区04点〜86区36点を
使用することにします。
86区37点〜89区94点はとりあえず保留領域にしますが、将来の拡張として
大漢和辞典に収録されている漢字でJISやUnicodeにない文字や、
人名・地名用の異体字を収録する領域にしておきます。
同じ文字がJIS X 0201、JIS X 0208、JIS X 0213、JIS X 0212、Unicodeに
重複して収録されていることもありますが、この場合、
JIS X 0201 > JIS X 0208 > JIS X 0213 > JIS X 0212 > Unicode
の順番に優先して文字コードを使用することにします。
たとえばJIS X 0213、JIS X 0212、Unicodeに重複して収録されている文字は
JIS X 0213の文字コードを使用することになります。
242:デフォルトの名無しさん
04/02/12 13:24
・・・Unicode使うよ。。。
243:デフォルトの名無しさん
04/02/12 13:26
>>240-241の続きです。
これだけの文字(>>240参照)を使用することになると、すべての文字を
収録したフォントを製造することが難しくなります。
そこで、フォントに「収録基準」を設け、それをフォントのパッケージに
明示することによってフォントの収録文字数を明らかにします。
収録基準0 JIS X 0201(またはASCII) + JIS X 0208
収録基準1 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213
収録基準2 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212
収録基準3 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeの漢字(BMPのみ)(*3)
収録基準4 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeの漢字(BMP以外を含む)(*3)
収録基準5 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeのすべての文字
(*3)CJK統合漢字、CJK互換漢字、CJK互換文字のうちの漢字
説明は以上です。長文ご容赦ください。
244:デフォルトの名無しさん
04/02/12 14:13
1バイト部分がJIS X 0201かASCIIかによって使用禁止の区点が
変化しますがそこは曖昧なままですか?
245:デフォルトの名無しさん
04/02/12 16:14
>>240の総文字数が誤っていたので訂正します。
(*1)使える総文字数は94*94-(940+94+94)+940*94*94=8313548文字
(*2)使える総文字数は94*94-(376+94+94)+376*94*94=3330608文字
>>244
だよねぇ。
1バイト英数字をASCIIにするのをやめてJIS X 0201にするとはっきり宣言してしまったほうが
Shift_JISとの互換性を考えるといいのかも。
246:デフォルトの名無しさん
04/02/12 16:25
> 1バイト英数字をASCIIにするのをやめてJIS X 0201にするとはっきり宣言してしまったほうが
イラネ。
247:デフォルトの名無しさん
04/02/12 16:32
> JIS X 0201にするとはっきり宣言してしまったほうが
それはセキュリティの問題が発生するので
すくなくともWindowsのコードページとしては採用不可能
248:デフォルトの名無しさん
04/02/12 17:12
すなおにUTF32使おうよ・・・
249:デフォルトの名無しさん
04/02/12 18:05
ということは1バイトの英数字がASCIIで、1バイトのカタカナがJIS X 0201なのが
一番いいということなのかな。
1バイトのカタカナなんて廃止してしまえ!!という強硬な意見はあると思うけど、
互換性を考えるとどうしても廃止できないと思う。
250:デフォルトの名無しさん
04/02/12 18:13
シフトJISの上位互換こそが特長なんだから
1バイトカナを廃止したら話にならん
互換性がなくていいならそれこそ>>248だ
251:デフォルトの名無しさん
04/02/13 01:17
UTF32 って何が嬉しいのでしょうか。固定長ではないのですよね?
252:デフォルトの名無しさん
04/02/13 01:39
BOM...かな？
253:デフォルトの名無しさん
04/02/13 01:53
UTF32は固定長ですがなにか？
254:デフォルトの名無しさん
04/02/13 02:11
合成があんだろ
255:デフォルトの名無しさん
04/02/13 02:20
どうせ固定長じゃないならUTF-8のほうがいい
256:デフォルトの名無しさん
04/02/13 02:29
utf32が固定長じゃないとかUCS4もびっくりだな
何文字使う気なんだ
257:デフォルトの名無しさん
04/02/13 04:09
誰か>>256を翻訳してください
258:デフォルトの名無しさん
04/02/13 07:45
Even UCS4 looks conventional; utf32 dosn't have the fixed size etc.
How many characters does it plan to use?
259:デフォルトの名無しさん
04/02/13 11:07
>>257
He said,
"UNICODE -> UNI-WORD -> UNI-LANGUAGE -> UNI-PEOPLE -> UNI-NATIONAL
-> UNI-WORLD -> UNI-PLANET -> UNI-COSMOS -> UNI-SPACE-TIME -> UTF-32"
260:デフォルトの名無しさん
04/02/13 12:28
UNKO
261:デフォルトの名無しさん
04/02/13 12:51
CPU等が速くなってんのにアプリの体感速度が変わらないとう現象の
原因を作っている人たちはココにいたんですね。。
262:デフォルトの名無しさん
04/02/13 13:26
NTではUnicode化したほうが速くなるが
PC初心者にお帰り
263:デフォルトの名無しさん
04/02/13 13:58
つーか >>261 は何を言いたいのかよくわからん
264:デフォルトの名無しさん
04/02/13 14:05
>>263
IT産業を支えてくれてありがとうと言っているのですよ
265:デフォルトの名無しさん
04/02/13 16:40
┏┓┏┳┓
┏┛┗┻╋┛ ＼ i
┗┓┏┓┃ ─ ＋ ─>>1-1000
┃┃┃┃ ┏┳┳┓ ／/ | ＼
┗┛┗┛ ┗╋┛┃ ／ / |
┗━┛ ／ /
￣ 二─ ＿
￣ ､ - ､
-､＼ ＼
／ ＼＼ ＼
／／ ＼ヾ ヽ ヽ
／／／ ＼ ヾ、 | i
／__( |! `i |
<_,へ ＞- 、 ,.-､_ | |
＼ノ人＼ ／ ､ }! ＼ | |
＼へ〃＼／ヾ＼_ﾉ､ﾉ人 ,.-､ | |
＼|＼rj＼ヾ / ＼_ﾌ ,／ |! ﾘ |
rm＼ノ _ Y Lノ / | |
|ヽ-r＜￣`ヾr'￣ヽ / / / /
| └､ノ/￣`,-`┐ { _／ / ／ ／／
ﾚ⌒＼!_ ｰ -{ ﾉ ｝ ／ ／ ／
￣`ー一 'ﾞ _／／_ ／
＿二─ "
266:デフォルトの名無しさん
04/02/25 00:01
おい、お前ら字形が変わりましたよ。
URLﾘﾝｸ(www.forest.impress.co.jp)
コードは関係ないからスレ違いかもしれんが、改正前の字形で書いてると
ｵｻｰﾝ扱いになる悪寒。俺には改正後の文字が、なんか昔の字に
見えるんだけど。。。
267:デフォルトの名無しさん
04/02/25 00:30
経緯
１．旧字体のうち一部を新字体に「正式に」改正
２．改正されていない旧字体の一部を１．の改正からの「類推で勝手に」変更 (どこが主導でやったのかは知らないが)
３．今回２．で勝手に変更されていたのを「もともとの旧字体」に訂正
なので今回の改正で「改正後の文字が昔の字に見える」のは当たり前。
268:デフォルトの名無しさん
04/02/25 00:42
殆どが「書き文字としては間違いだけど、コンピュータ上では許されていた字形」を
正しい字形に戻したって感じを受けるな。
中には違いがさっぱり分からんのもあるんだが...。蟹とか灸とか粂とか。
個人的には進捗の捗の字が正しくなるのがうれしい。
269:デフォルトの名無しさん
04/02/25 00:58
>268
「正しさ」って何？
頻、賓、濱、捗
270:デフォルトの名無しさん
04/02/25 01:01
歩 渉 陟 捗 濱 瀕
271:デフォルトの名無しさん
04/02/25 01:12
歩 と
272:デフォルトの名無しさん
04/02/25 01:19
うぉ、『倶舎論』の本来の「倶」が入ってる！
産業省ﾏﾝｾｰ！
273:デフォルトの名無しさん
04/02/25 01:24
>>269
紙媒体の辞書に載せられるかどうか。
（載ってるかどうかとは言わないでおく）
274:デフォルトの名無しさん
04/02/25 01:52
DTP、フォント関連の連中は
忙しくなるな(w
275:デフォルトの名無しさん
04/02/25 02:58
DTP業界のフォントは78JIS字形をサポートし続けてきたから
実はほとんど影響なかったり。印刷物に使われ続けてきたん
だからまあ当然といえば当然だが。
276:デフォルトの名無しさん
04/02/25 03:14
何かスラドで激しくデジャヴを感じる投稿が多数あるような。
> 中には違いがさっぱり分からんのもあるんだが...。蟹とか灸とか粂とか。
そのへんは、例示字形にデザイン差を残しておくと規格がデザイン差に
関して何らかの価値判断を行ったと誤解されるおそれがあるから、
表外漢字字体表に一致させたもの(と解説に書かれてる)。
厳密にその通りのデザインで実装することを要求するものではないし、
そのような解釈はかえって表外漢字字体表の趣旨に沿わない。
何がデザイン差で何が包摂の範囲内での字体変更かも解説には
書かれてる。
277:デフォルトの名無しさん
04/02/25 10:49
蟹は「角」の右下と「虫」の上がくっついてるかどうかだな
微妙杉
278:デフォルトの名無しさん
04/02/25 13:05
鯖と鰯は良いね！
279:デフォルトの名無しさん
04/02/27 02:23
JIS X 0213が改正されても、JIS X 0208も一緒に改正されなければ無意味。
JIS X 0213なんて新JISキーボードと同じで、ほとんど使われていない規格なんだから。
ところで、法務省の人名用漢字追加はJIS漢字の字体をベースにするといっていたけど、
今回の改正でどう影響するんだろう？
今のところ、常用漢字・人名用漢字には2点しんにょうの字体はないけど（許容漢字を除く）、
場合によっては2点しんにょうに改正された文字が人名用漢字に追加される可能性がある。
280:デフォルトの名無しさん
04/02/27 04:15
後、気になったのは「辻」の字が2点しんにょうになっていること。
「表外漢字字体表」に従えば当然そうなるんだが、実際の人名（というか人の姓）で
使われているのは1点しんにょうの方が圧倒的多数。
2点しんにょうは文芸家（wが好んで使う（綾辻行人とか辻仁成など）けど、
表札とかに2点しんにょうの方が使われているのは見たことがない。
辻さんが「自分の名字の文字が『勝手に』正字に矯正されている」ことを知ったらどう思うだろうか。
人名にはまず使われていない迂とか迄とか謎とかは2点しんにょうのみにしてもいいけど、
辻は1点しんにょうと2点しんにょうの両方を規格に入れるべきだったと思う。
包摂規準に例外を作ってまでも。
281:デフォルトの名無しさん
04/02/27 04:23
正式には難しい字が使われてても
普段は簡単な字で書いてたりするので
（例：濱本を浜本と書いてたり）、
普段簡単な字で書いてるからといって、
その字で登録されているとは限んないけどね。
282:デフォルトの名無しさん
04/02/27 09:15
>>279
JIS X 0208を改正しなかった理由も解説に書かれてるね。
変更をほとんど使われていない規格だけにとどめたことで
混乱を最小限に抑えたとかいう角度の見方もある。
283:デフォルトの名無しさん
04/02/27 09:21
戸籍に登録されている「辻」が1点しんにょうということはありえない。
現時点で人名用漢字にも常用漢字にもないから戦後追加された
ことはないし、戦前の活字は当然すべて2点だし、
法務省は1点の「辻」は俗字扱いにしていて正字からの変更を
認めていないから既存の「辻」を持つ苗字が変えられた可能性もない。
したがって表札とかには戸籍にない略字を勝手に使っているだけだと
思われ
284:デフォルトの名無しさん
04/02/27 09:24
というか表札はふつう明朝体活字で書いたりしないから
1点しんにょうになるのはむしろ当然なような。
それとも点の下がグネグネした「辻」も追加すべきですかね。
285:デフォルトの名無しさん
04/02/27 09:28
> ところで、法務省の人名用漢字追加はJIS漢字の字体をベースにするといっていたけど、
読売の記事だとそれは去年の検討の話で
いったんご破算になったらしいんだが
今回も結局JIS漢字を元にしてるの?
286:デフォルトの名無しさん
04/02/27 09:52
imadoki kanji tukatteru yasi kimoi
287:デフォルトの名無しさん
04/02/27 10:15
>>283
電算化前の戸籍って和文タイプで打ったのもあるけど、手書きもあるよ。
たとえば漏れの本籍地は京都市だけど、戸籍謄本を取ってみたら手書きだった。
手書きの「辻」のすべてが2点しんにょうになっているとは思えない。
288:デフォルトの名無しさん
04/02/27 11:34
ああそうか、戸籍の電算化を阻んでるのは手書きの誤記を
これが自分の名前の字だと主張する連中だったな
> 手書きの「辻」のすべてが2点しんにょうになっているとは思えない。
むしろ手書きでは1点が普通だろ。それが活字では2点になるという
常識が戦前はあったわけだが
289:デフォルトの名無しさん
04/02/27 15:50
で、ののたんの名字は１点なの？２点なの？
場合によっちゃ幕の字書き換えなきゃならんのだけど
290:デフォルトの名無しさん
04/02/27 17:16
さすがプログラム版のスレだけあって、
漢字の話題になるといきなりレベルが低くなるな。
291:デフォルトの名無しさん
04/02/27 17:39
そもそも>>266が自分で言ってるがスレ違いっぽいし
292:デフォルトの名無しさん
04/02/27 22:10
>290
レベルの高い漢字の話題はどこでやってますか？
煽りじゃなく本当に知りたい。
293:デフォルトの名無しさん
04/02/27 22:16
格調高く感じを論ずるスレ四
ｽﾚﾘﾝｸ(kobun板)
294:デフォルトの名無しさん
04/02/27 22:17
>>293
感じって・・・
295:デフォルトの名無しさん
04/02/27 22:21
＿|￣|○ やられた。 古文・漢文板なんていったこと無かったから、無防備だった。
296:デフォルトの名無しさん
04/02/27 22:53
旧字体・別字体について
ｽﾚﾘﾝｸ(gengo板)
【朝日】文字を徹底的に略すスレ【JIS】
ｽﾚﾘﾝｸ(gengo板)
【ゐゑ】舊字、舊假名遣ひで話すスレッド 三箇目
ｽﾚﾘﾝｸ(gengo板)
【常用漢字表にない漢字の代わりの漢字について
ｽﾚﾘﾝｸ(gengo板)
◆◆漢字専用スレｐａｒｔ2◆◆
ｽﾚﾘﾝｸ(kobun板)
旧かな旧漢字は伝統的でしょうか
ｽﾚﾘﾝｸ(kobun板)
●教育漢字、常用漢字を有志で作り直すスレ●
ｽﾚﾘﾝｸ(kobun板)
JIS漢字
ｽﾚﾘﾝｸ(kobun板)
ちょっと集めてみたがレベルがそう違うとも思えんがね
297:デフォルトの名無しさん
04/02/27 23:09
ここも。
JISをもう1度、最初から作りなおせるとしたら
ｽﾚﾘﾝｸ(gengo板)
298:292
04/02/27 23:20
サンクスコ。
なるほど、レベルの違うスレもあれば、そうでないのもあって面白い。
結局、バカのせいなんだよな。
「かほる」なんて名前が昔から使われていると思うようなバカと一緒。
スレ違いなのでAC。
299:デフォルトの名無しさん
04/02/29 03:37
さ、
300:デフォルトの名無しさん
04/02/29 03:37
さんびゃくー！！
301:デフォルトの名無しさん
04/02/29 20:02
m17n-libがもうすぐ公開だな
使い物になるのだろうか
302:290
04/03/01 13:22
いや、どこのスレだって無責任なレスがほとんどなんだけどさ、
言語学版あたりの文字コード関連スレだと、
かなーり詳しい奴が張り付いてて、すぐに突っ込みが入る。
しょーがないから俺が突っ込んでおくと、
戸籍での「辻」は一点も二点もありだ。っつーか、
しんにょうはすべて一点でも二点でも認められているわけだが。
303:LightCone ◆sSJBc30S5w
04/03/03 21:26
UNICODEのUTF-8の日本語向けの符号を考えてみました:
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
UTF-8と違って、JIS第一、第二までは、2BYTEで表せます。
まだ、仕様を考えている途中なので、この符号を用いたプログラムは一つ
もありません。
何か問題点や、嘘を書いてる点などが見つかりましたらご指摘頂ければ幸い
です（つまり添削お願いします）。
304:デフォルトの名無しさん
04/03/04 03:07
>>303
変換にテーブルが必要な時点でUTFと名乗るのは問題がある。
俺コードとかって名前なら別にどうでもいいんだけど。
305:デフォルトの名無しさん
04/03/04 07:40
>>303
>多バイト文字途中への検索ヒットを簡単に回避可能
正規表現で回避しているようだけど、回避のための
修正が必要な時点で、UTF-8と比べて汎用的とはいいがたいなぁ。
(strcmpを使っているなら細工をして再コンパイル等が必要だけど
UTF-8は修正の必要もない)
306:デフォルトの名無しさん
04/03/04 09:25
>>303
> 何か問題点や、
単にまた混乱の元を追加するだけってことかな。
307:デフォルトの名無しさん
04/03/04 11:16
みんなUTF-8で結構おなか一杯だからなぁ。
308:デフォルトの名無しさん
04/03/04 11:32
>>303
Unicodeを混ぜることができる,EUC-JP/シフトJISの一種と考えたら
そこそこ面白い。
309:デフォルトの名無しさん
04/03/04 12:43
>>308
その手の拡張は>>239にもあるし>>240-にもあるしおなかいっぱい
310:デフォルトの名無しさん
04/03/04 13:21
主にどういう局面で利用される事を想定してるんだろうか。
UTF-8でも少しサイズが大きい程度で、そんなに気にならないんだけど。
独自にやる苦労に見合うだけの結果が得られるかは微妙だ。
打算計算を抜きにすれば、自作のOSで自作の文字コード使って
色々実験するのは楽しそうとは思うけどね。(^^;
311:LightCone ◆sSJBc30S5w
04/03/04 16:31
>>308, >>309
「Unicodeを混ぜることの出来るEUC-JP/SJIS」に、「簡単に逆戻り可能」な
性質を取り入れたような感じなんです。
ちなみに、>>239の符号では、逆戻りは出来ないと思いますが、
さらに、「\」コードを含んでいるので、色々と問題があると思います。
というわけで、いかがでしょうか。
新しいコードは、みんなが使い始めるか、よっぽど良い性質がない限り、
抵抗感がある物かも知れませんが。
312:LightCone ◆sSJBc30S5w
04/03/04 16:42
>>310
>主にどういう局面で利用される事を想定してるんだろうか。
>UTF-8でも少しサイズが大きい程度で、そんなに気にならないんだけど。
そう思われる人が多いのであれば、せっかくでしたが、余り意味がないかも
知れません。
でも、今まで2BYTE表せていた文字に3BYTEを当てるのに抵抗がある人には、
需要があるのではないかと思うんです。
その点だけでは、>>239の符号もいいと思いますが、UTF-JAPANの方は、
逆戻り可能の性質を持っている点や、多バイト文字に\コード等を含んで
ない点で、解析やエディタ作りなどにおいて、真価を発揮する場面がある
のではないかと思います。
EUCも、2バイトの範囲では逆戻り可能ですけど。>>239に書かれている拡張EUC:
URLﾘﾝｸ(web.archive.org)
においては、UTF-16,UTF-32対応する3バイト以上のコードでは、逆戻りが
出来なくなっているようですし。
313:LightCone ◆sSJBc30S5w
04/03/04 16:46
>>304
この符号の場合、基本的に地域や言語ごとに違う変換テーブルを用意する
必要がありますね。それをOSがサポートして、欲しいフォーマットに
まで変換を世話してくれればアプリの負担は減るとは思うんですが。
全世界で全く同じコードを用いたいのであれば、漢字が３バイトになって
しまうのは、元々やむを得ないかも知れない。
314:LightCone ◆sSJBc30S5w
04/03/04 16:53
>>305
UTF-8の場合、strcmp()は、単純な昔ながらの1バイト単位の比較のまま
無修正で利用できてしまうんですよね。
それは凄い性質ではあると思いますが、結局、コードを無修正で済ました
いばっかりに、データサイズが大きくなる犠牲を払っているんだと思うん
です。
315:LightCone ◆sSJBc30S5w
04/03/04 16:54
なお、
UTF-JAPANを、「UTF-COMPACT-JAPAN」と改名して、
「UTF-COMPACT-ARABIA」
「UTF-COMPACT-CHINA」
なども定義すれば、strcmp()等の修正は、言語数分まで及ばずに
一回だけで済むかも知れませんね。
316:LightCone ◆sSJBc30S5w
04/03/04 16:57
>>237 から続く発言は、なんと先月のものなんですね！
うまく合併できないかな。
317:LightCone ◆sSJBc30S5w
04/03/04 17:02
>>261の
>CPU等が速くなってんのにアプリの体感速度が変わらないとう現象の
>原因を作っている人たちはココにいたんですね。。
これは、今まで2バイトで表現できていた物を3バイトにしようとすることとも
その一つかな。
全世界の文字を使えるのはいいことではあるけれど、日本人が、英語と
JIS第一,第二以外の言語を使用する頻度は低いし、文字集合はUNICODEを
使うにしても、地域ごとに違った符号があってもいいのではないかな。
318:LightCone ◆sSJBc30S5w
04/03/04 17:04
UTF-COMPACTの変換テーブルは、OSが提供するだろうから、
UTF-COMPACT-xxxxx用のアプリは、いずれのxxxxx言語にも
無修正で対応できるのではないだろうか?
319:LightCone ◆sSJBc30S5w
04/03/04 17:10
例えば、HTMLヘッダに、
<meta http-equiv="Content-Type" content="text/html;
charset=
utf-compact-japan">
~~~~~~~~~~~~~~~~~
を書いておけばいいんじゃないかな。
SJISや、EUC-JPでやってることと何ら変わりないと思うし。
320:デフォルトの名無しさん
04/03/04 17:25
アメ公がUTF-16嫌ってUTF-8に走るのとまったく同じ論法だよね
自分たちが使いもしない文字のことなんてどうでもいいと思うのは
世界共通というか
321:LightCone ◆sSJBc30S5w
04/03/04 17:34
>>320
でも、自分たちの地域で効率を上げることにも、一利はあると思うんです。
UNICODEを全否定しているわけではなく、符号長に地域ごとに偏りを
持たせるだけですし。
322:LightCone ◆sSJBc30S5w
04/03/04 17:36
SFみたいな世界になって、文字種が爆発的に増えた場合、やっぱり、
地球では地球語に短い符号を割り当てるんじゃないかな。
そういう意味で、偏りを持たせる発想は、古くさい考えではないと思う。
323:デフォルトの名無しさん
04/03/04 17:38
だったらローカルコードでいいし
地域の数だけ馬鹿でかい変換テーブル持つなんて馬鹿の極み
324:デフォルトの名無しさん
04/03/04 17:41
日本語が多くてサイズが増えるのが嫌なら、UTF-16を使えばいいのでは？
325:デフォルトの名無しさん
04/03/04 17:41
> 制御コード、特殊記号、\コードを含まず
C1文字は制御コードじゃありませんか
そうですか
326:デフォルトの名無しさん
04/03/04 17:43
> JIS X 0213 2000 JIS第三、第四 4344字
今さら2000年版かよ
327:デフォルトの名無しさん
04/03/04 17:43
> 情報交換用漢字符号系
つーかずいぶんと古い資料参照してるな
328:デフォルトの名無しさん
04/03/04 17:44
そもそもたった一つのインプリで他言語をカバーしようとしたのがUnicodeじゃないの？
それを地域ごとに独自テーブル作ったら意味ないじゃん
329:デフォルトの名無しさん
04/03/04 17:44
> /[^\x81-\xde]任意の文字列/
「任意の文字列」が先頭だったらヒットしなくなるね
330:328
04/03/04 17:45
失礼
X他言語
O多言語
331:328
04/03/04 17:47
そもそも
UTF-JAPAN
ってのがかっこわるいよね
せめて
UTF-JPとかUTF-jaとかにすればいいのに
332:デフォルトの名無しさん
04/03/04 17:48
せめてもう少し間隔おいて自演したら？
333:デフォルトの名無しさん
04/03/04 17:49
> SJISや、EUC-JPでやってることと何ら変わりないと思うし。
なんら変わりなく欠点を引き継いでどうするんだよ
334:デフォルトの名無しさん
04/03/04 17:51
>>332
誰に言ってるんですか?
335:デフォルトの名無しさん
04/03/04 18:41
ちょっと考えてはみたけど、UTF-8越えは難しいな。
使っててあまり不満ねーもの。（慣れたのもある）
その俺コードで外人と文書のやり取りする時はどうする気なんだ？
>>331
確かに微妙な名前だ。
>>333
文字集合がUnicodeでやろうと思えば多くの文字を表現出来る点が重要なんじゃね？
サイズを気にするなら圧縮で十分って気がするけど。
336:LightCone ◆sSJBc30S5w
04/03/05 00:09
中国には、JIS第一水準と同様に、「第一級漢字」が定まっていて:
URLﾘﾝｸ(www.kishugiken.co.jp)
このようになってます↑
ご覧の通り、JIS第一、第二水準と重複する部分も多く、興味深いのです。
これと、JIS第一水準を合わせた部分を2BYTEで表せるような、UNICODE符号を
作れば、中国人と日本人の両方にメリットがあるかも知れないと思うのですが、
いかがですか?
337:LightCone ◆sSJBc30S5w
04/03/05 00:17
ちなみに、UNICODEのCJK統合漢字部分は、頻度の低い漢字も何も考えずに
並べてあり、頻度毎に分類できないので、どうしても22000文字程度
をまとめて符号化する必要があります。ASCII符号と互換性を持たせ
つつ、これら全ての文字集合を2BYTEで表現しきることは、ほぼ不可能
です。
しかし、中国の第一級、第二級漢字と、日本のJIS第一、第二水準漢字
には重複する部分が多く、それらの「和集合」の文字なら、2BYTEで
表せる範囲の数ではないかと踏んでるんです。
338:デフォルトの名無しさん
04/03/05 00:19
各文字に割り振るコードの順番にも意味があるから、単に足し合わせれば良いという物でも
ないと思うけど。
339:LightCone ◆sSJBc30S5w
04/03/05 00:23
大体の目安としては、一万五千字程度の文字なら、ASCII符号と互換性
を持たせ、「逆戻り可能」で、しかも、後続バイトを付ければUCS-4全体
を表現しきれるような、2BYTEの符号を作る事が出来ると見ています。
340:LightCone ◆sSJBc30S5w
04/03/05 00:27
>>338
せっかく、JIS第一水準で五十音順、第二水準で部首順になってるのが、
中国の文字セットと合成した際に失われると言うこと?
341:デフォルトの名無しさん
04/03/05 00:28
GB18030は何文字格納できるんだっけか？
342:LightCone ◆sSJBc30S5w
04/03/05 00:29
UNICODEでは、部首順らしいので、統合する際にそれにならえばいい
のでは?
343:LightCone ◆sSJBc30S5w
04/03/05 00:30
>>341
わても知らんので、調べて。
344:デフォルトの名無しさん
04/03/05 00:30
>>342
コテハンには聞いていない。
345:デフォルトの名無しさん
04/03/05 02:12
150万文字ぐらい入るんだっけか＞GB18030
346:デフォルトの名無しさん
04/03/05 13:18
>>345
うん。約1,611,668文字かな。
347:デフォルトの名無しさん
04/03/05 13:49
ちなみに、GB18030は、逆戻り不可だし、検索も複数バイト文字の途中で
ヒットする。
348:LightCone ◆sSJBc30S5w
04/03/06 00:44
UNICODEの新符号「UTFCP」を発案しました:
URLﾘﾝｸ(nowsmartsoft.or.tv)
2バイトの符号で1万5千文字以上を表せて、なおかつ、文字列を文字単位で
正確に逆戻りできる、UNICODE符号です。UCS-4全体を表現できます。
また、多バイト符号にASCII符号を一切含まないので、英大文字小文字変換に
対しても安定です。
理論上、日本語のJIS第一、第二水準漢字、中国語の第一級、第二級漢字の両方
をコードページの切り替えなしに2BYTE符号で表せますので、
UTF8に比べ、頻度の高い日本語や中国語の文章が2/3に(50%減)コンパクトに
なります。
いかがでしょう？ (^_^;)
349:デフォルトの名無しさん
04/03/06 01:44
ハードディスクが何百GBになる時代に、テキストファイルの容量が数十%減ったくらいでは
あまり利点を感じないけどなぁ。
むしろ、>>240-243みたいに(書いたの漏れだけど)EUC-JPやShift_JISの完全上位互換規格を
考えたほうがまだ意味があると思う。
350:デフォルトの名無しさん
04/03/06 07:53
情報の冗長性を取り除いて小さくまとめようとすると
たいてい少し複雑な演算が必要になるよね。
UTF8と張り合うなら演算量も念頭にいれる必要があるかも。
UCS4とUTF8の変換では１〜２個の条件分岐と
長さ*(シフト、OR、AND)演算＋入出力程度で変換してる。
351:デフォルトの名無しさん
04/03/06 08:13
>>348
各文字コードの主要な正規表現エンジン各々での探索コストの大まかな比較をやってみてほしい。
352:デフォルトの名無しさん
04/03/06 12:06
ただでさえ混乱している文字コード周りの処理をさらに混乱させないでくれ。
353:デフォルトの名無しさん
04/03/06 12:21
>>348
「俺コード」を作るな。
有用だと信じるなら、IETFとかUnicode.orgにでも提案しろ。
354:デフォルトの名無しさん
04/03/06 13:50
>>352-353
作るのは勝手なんじゃね？
気に入らないなら使わなけりゃ良いだけ。
案が未熟だというだけで作る事自体を否定するものではないかと。
因みに俺もUTF8で不満は無い。
文字コードみたいなもので冒険せずに他で頑張った方が良いんじゃないかと。
高いリスクを冒した結果、成功したところで見返りは小さい。
355:デフォルトの名無しさん
04/03/06 14:12
まあ、独自Unicode系CESなんて、普及するわけもないから、
悪影響も少ないわな。機種依存文字なんかはすぐに悪影響が出るけど。
356:デフォルトの名無しさん
04/03/06 19:34
俺アプリのベースエンコーディングに使う為の独自エンコーディングの開発ならオケですか？
357:デフォルトの名無しさん
04/03/06 20:49
俺OSのベースエンコーディングに使う為の独自エンコーディングの開発ならオケです。
358:デフォルトの名無しさん
04/03/06 21:35
>>350
1つの文字を複数の表現で符号化できる規則は可能なら避けたほうがいい
UTF-8で避けようとすると加減算が余分に入るけど
359:デフォルトの名無しさん
04/03/07 01:11
お前ら釣られるなよw
360:デフォルトの名無しさん
04/03/07 03:20
>>358
UTF-8は一つのコードに対して複数の表現は許していないはずだけど
文字とか字形の話…？
361:デフォルトの名無しさん
04/03/07 04:05
>>360
・・・・は？
362:LightCone ◆sSJBc30S5w
04/03/07 19:28
UTFCPについて、詳しく書いておきました。
符号の読み取りや、逆戻りの状態遷移図やソースプログラムもあります。
また、1バイト単位の正規表現ルーチンでも検索に利用できることも分かったので
書いておきました。
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
363:デフォルトの名無しさん
04/03/07 19:34
2chで宣伝とは・・・
364:デフォルトの名無しさん
04/03/07 22:20
>>362
gobackUTFCP が動くとは思えないのだが。
365:LightCone ◆sSJBc30S5w
04/03/07 22:54
>>364
動くと私は思います。
動かないと思われる例を挙げてみて下さい。(^_^;)
366:デフォルトの名無しさん
04/03/07 23:02
>>362
だから○とか×じゃなくて探索コストで比較しろって。
あんたが主張する利点は対象データの処理がUTF8に比べて
速いということだろ。今の状態では説得力0だ。
367:デフォルトの名無しさん
04/03/07 23:05
>>366
いい加減放置しろって・・・
明らかな宣伝ということで削除依頼もしておいた。
368:LightCone ◆sSJBc30S5w
04/03/07 23:09
>>366
速いという事じゃなく、サイズがコンパクトと言うこと。
ディスクに保存するときは速いだろうけど。
369:デフォルトの名無しさん
04/03/07 23:19
>>368
んなんだから、院試に落ちるんだよ。
偉そうなお題目なんてのは後にしろ。時間の無駄だ。
370:LightCone ◆sSJBc30S5w
04/03/07 23:24
>>369
どの大学の、何学科の院試か知りませんが、工学部の院で良ければ、
東大でも受かります。
371:LightCone ◆sSJBc30S5w
04/03/07 23:25
第一、京大の理学部物理学科だって、研究室によれば簡単に受かるし。
372:デフォルトの名無しさん
04/03/08 00:13
>>365
動く動かないは別として、初期状態が符号列の最後のバイトに
なければならないというのがダメダメ。
そんな前提を置いた上でなら、EUCだってSJISだって
「複数バイト文字の最後のバイトから高々符号長分遡るだけで、
その符号の先頭バイトを発見可能」
って言えてしまうんだが。
373:LightCone ◆sSJBc30S5w
04/03/08 00:36
>>372
>そんな前提を置いた上でなら、EUCだってSJISだって
>「複数バイト文字の最後のバイトから高々符号長分遡るだけで、
>その符号の先頭バイトを発見可能」
>って言えてしまうんだが。
言えません。
例えば、SJISでは、
全角「キ」のコードは、0x83, 0x4c
全角「ャ」("キャ"などの小さい"ヤ")のコードは、0x83,0x83
半角「c」のコードは、0x63
全角「宴」のコードは、0x89, 0x83
全角「ツ」のコードは、0x83, 0x63
となり、
キャc ---> 0x83, 0x4c, 0x83, 0x83, 0x63
宴ツ ---> 0x89, 0x83, 0x83, 0x63
となるので、cにあるとき遡ると、0x63,0x83,0x83と
なり、ツの最後のバイトにあるとき遡ると、0x63,0x83,0x83となり、
全く同一になり、cなのか、ツなのか区別が付かない。
EUCでは、最後尾バイトからスタートする限りは大丈夫。
UTF8では、どこからスタートしても大丈夫。
UTFCPでは、最後尾バイトからスタートする限りは大丈夫。
374:LightCone ◆sSJBc30S5w
04/03/08 00:44
ちなみに、SJISでは、例えば、
ラャc ---> 0x83, 0x89, 0x83, 0x83, 0x63
宴ツ ---> 0x89, 0x83, 0x83, 0x63
のように、最悪のケース、1000バイトも遡っても、遡り始めた文字が、
半角なのか全角なのか判断付きかねる文字列を作れる。
つまり、「ツ」なら全角、「c」なら半角なのだが、その区別が長く遡っても
なかなか付かないような文字列が存在し得リますです。
375:デフォルトの名無しさん
04/03/08 00:50
>>374
UTF8より優れているにしろ使われなきゃどうしようもない。
こんなとこよりもっと有効なところで発表すれば？
376:デフォルトの名無しさん
04/03/08 01:02
>>374
自分のコードがまったくおんなじ問題を抱えているのに
気付いていないんだろうか？
＃こういうのリアルタイムで見たの久しぶりだな...
377:デフォルトの名無しさん
04/03/08 01:46
>>365
符号が DBA で、現在位置が A のとき。
378:デフォルトの名無しさん
04/03/08 01:57
> LightCone
まずは自分のOSで使用してみたら？
せっかく独自のOSを開発しているんだから。
379:デフォルトの名無しさん
04/03/08 02:14
結論: wchar_t使えやボケ
380:デフォルトの名無しさん
04/03/08 02:17
>>358
UTF-8では禁止されたはず。
確かそれ周りのセキュリティーホールもあったような。
（特定文字のチェックをすり抜けるようなやつ）
381:デフォルトの名無しさん
04/03/08 03:33
>>380
イチから作るなら「禁止」じゃなくて理論上重複符号化がありえない
設計にしたほうがいいって趣旨。UTF-8の場合は互換性の問題から
不可能だったわけだが。
セキュリティホールの話は>>232-あたりで出てるね
382:デフォルトの名無しさん
04/03/08 05:07
UTF-8はtransformation format of ISO 10646なんだから
UCSに戻して使うのが本来の使い方。
それを正しく把握していれば重複符号化が可能でも何ら問題無い。
383:デフォルトの名無しさん
04/03/08 07:02
>>363
宣伝ではなくて、突っ込み貰うのが目的なんだろ。
叩き台出してみてマシになるかどうかという。
置き換えるには既にUTF-8が広がり過ぎていると思うが。
384:LightCone ◆sSJBc30S5w
04/03/08 08:45
>>377
>符号が DBA で、現在位置が A のとき。
そんなのは全く問題ありませんよ。あなたが全く理解してないだけです。
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
↑の図を見てもすぐ分かることだし、下の関数冒頭を見ても分かる通り、
*ptr <= 0x7f の判定が真になるので、すぐに、「A」に場合分けできて、
1バイト符号に分類されます。
unsigned char *gobackUTFCP( unsigned char *ptr )
{
if ( *ptr <= 0x7f ) {
//(1) A
ptr--;
}
...
385:デフォルトの名無しさん
04/03/08 10:20
>>382
> UTF-8はtransformation format of ISO 10646なんだから
> UCSに戻して使うのが本来の使い方。
まったくです。
情報交換用コードと情報処理用コードは分けて考えるべきなのに、
UTF-8をそのまま処理することを考えているのは愚かすぎます。
> それを正しく把握していれば重複符号化が可能でも何ら問題無い。
それはどうかと思いますが。
見識の低い人が実装することもあるわけですし。
386:LightCone ◆sSJBc30S5w
04/03/08 10:58
逆戻りがなぜ可能か分かりにくい人が多いようですので、
解説しておきます。ご覧アレ:
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
これで。UTFCP符号が間違いなく逆戻りできることの証明になって
いると思います。
387:385
04/03/08 10:58
>>386
そもそも情報交換用コードで逆戻りする必要がありません。
388:LightCone ◆sSJBc30S5w
04/03/08 11:00
>>387
ASCIIもオンメモリで、32BITで保持するつもりなんでっしゃろか?
389:デフォルトの名無しさん
04/03/08 11:11
>>388
必要ならそうするんでは?
ASCIIだけでよい文脈なら1バイトで処理すればいいし、
そうでないなら4バイトで処理すればいいですし。
あと保持というのがよく分かりません。UTF-*とUCS*の
どちらで保持するかは文脈によるのでは。
390:デフォルトの名無しさん
04/03/08 11:14
ときどきいるよね。自称大発見とか大発明とか。
そろそろ春も近いしね。
391:LightCone ◆sSJBc30S5w
04/03/08 11:20
>>385
そもそも、情報交換用なら、BOCU圧縮を使えば、UTF8よりコンパクトに
なる:
URLﾘﾝｸ(www-6.ibm.com)
UTF8は、情報処理用としてもかなり考慮されていて、ASCII用に書かれ
た古い検索ルーチンや文字処理ルーチンを無修正でUnicodeに対応でき
る特徴をっている。こんな特性は、よく知られている他の可変長符号に
はない。
392:デフォルトの名無しさん
04/03/08 11:28
別に内部コードとしてUTF-8を採用することが
禁止されてるわけでもないのに愚か過ぎるだの見識が低いだの
とまで言われなければならない理由は何ですか
393:デフォルトの名無しさん
04/03/08 11:32
>>383
意見を求めているふりをして人の話などぜんぜん
聞くつもりがないところを見る限り違うような気がします。
では何が目的なのかと言われてもさっぱり分かりませんが
394:デフォルトの名無しさん
04/03/08 11:34
>>391
> UTF8は、情報処理用としてもかなり考慮されていて、ASCII用に書かれ
> た古い検索ルーチンや文字処理ルーチンを無修正でUnicodeに対応でき
> る特徴をっている。こんな特性は、よく知られている他の可変長符号に
> はない。
それはEUC-JPでも普通に行われてきたのでは?^^;
「問題が出ないようにしてある」のと「情報処理用に作ってある」のとは別です。
EUC-JPでもShift JISでもISO-2022-JPでも、内部処理用に使おうと思えば
可能です。実際そういうソフトウェアもあるわけですし。
ただ、その場合処理が複雑になるしその分エンバグする可能性も高いわけです。
> そもそも、情報交換用なら、BOCU圧縮を使えば、UTF8よりコンパクトに
> なる:
> URLﾘﾝｸ(www-6.ibm.com)
ここまでするなら、レイヤーを分けて普通にハフマン符号化した方が良いと思うんだけど。
395:LightCone ◆sSJBc30S5w
04/03/08 11:38
>>394
>それはEUC-JPでも普通に行われてきたのでは?^^;
多分、UTF8の特性をご存じない。
EUC-JPでは、全角文字をASCII用のstrstr()で探そうとすると、
別の全角文字の途中にヒットしてしまうことがあるが、UTF8では
ない。
396:デフォルトの名無しさん
04/03/08 11:43
>>395
> EUC-JPでは、全角文字をASCII用のstrstr()で探そうとすると、
> 別の全角文字の途中にヒットしてしまうことがあるが、UTF8では
> ない。
確かにそうですね。失念していました。
397:396
04/03/08 11:48
ですが情報処理コードとして適切でないのは明らかです。
strstr()して得た開始位置は、全体の何文字目なのでしょうか?
398:デフォルトの名無しさん
04/03/08 11:53
ところで疑問なのは
なんでUTFCPとUTF-JAPANと言う二つの符号化方式を用意したかだ。
399:デフォルトの名無しさん
04/03/08 11:56
それを言うならUCSの一単位は一文字とは限りませんが。
結合音節文字とかご存知ありませんか。
固定長によるインデックスアクセスですべて済まそうと
考えること自体が漢字文化圏の幻想です。
400:デフォルトの名無しさん
04/03/08 12:03
400get
盛り上がってきました
401:デフォルトの名無しさん
04/03/08 12:11
>>384
「if ( ptr[-1] <= 0x7f )」だろマヌケ。
それとも、DBA の B を指すのが正解なのか?
402:デフォルトの名無しさん
04/03/08 12:30
>>399
> 固定長によるインデックスアクセスですべて済まそうと
> 考えること自体が漢字文化圏の幻想です。
この考えは「どうせAという処理をしなければならないのだから
Bという処理が増えてもかまわない」と言っているようで奇妙
です。問題を分割することは基本なのに。
403:デフォルトの名無しさん
04/03/08 12:46
>>398
自分のOS作るのにどういう文字コードをメインに据えるかを考えているらしい。
UTF-8だと漢字のサイズが大きいから気に入らないそうだ。
OSとセットでもなけりゃ独自コードの生き残りは辛そうだから、
良い機会と言えば良い機会なんだろうが。
超漢字が無かったらTRONコードなんて……。
404:デフォルトの名無しさん
04/03/08 12:52
>>402
「どうせ文字数を数えなくてはいけないのだから文字の間に
マッチしたかどうか判定する必要があっても構わない」
というのは奇妙ですよね。要は程度の問題です。
そもそもUCS*ではstrstr()一切使えないし
(charが16ビットや32ビットでない限り)
405:LightCone ◆sSJBc30S5w
04/03/08 13:10
>>401
マヌケなのはあなたです。Aを指すのが正解で、*ptr <= 0x7fのままで
間違ってません。
406:LightCone ◆sSJBc30S5w
04/03/08 13:13
>>398
最初思いついたのが、UTF-JPで、複数バイト文字に、A-Z, a-zなどを
含んでいるのが、欧米人が何も考えずにstrupr()する人が多い事情を
考えると良くないと指摘されて、頭を悩めて作ったのが、UTFCPです。
UTFCPは苦労して導きました。0x80以上だけを使って逆戻り出来る
符号としては、これ以上コード・ポイントは増やせないかも。
407:デフォルトの名無しさん
04/03/08 13:16
てかコテハンでうだうだやるのもほどほどに。
俺様規格考えた〜まではまぁ、いいかもしれないが、その先はここでやらんと自サイトに掲示板でも
作ってそこで勝手にやってて欲しいな。
面白いとおもった香具師はそっちで反応するだろう。少なくともここでやられては迷惑なだけだ。
408:デフォルトの名無しさん
04/03/08 13:22
>>407
どうせ余所でやっても見ないし。俺はここでやってくれてかまわないよ。
別のネタを話すにしても並行して話せばいいだろう。今までもそうやって
きたんだから。
409:LightCone ◆sSJBc30S5w
04/03/08 13:24
>>407
分かりました。
UTFCP符号について興味のある人は、下記の「UTFCP符号について」ス
レッドで議論を継続するようにして下さい:
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
410:デフォルトの名無しさん
04/03/08 13:24
俺もここでやるのは構わないけど、コテハンでやるなら
多少煽り口調で言われても落ち着いてキレずにやって欲しいのぅ。
411:LightCone ◆sSJBc30S5w
04/03/08 13:26
>>410, >>408, >>407
個人的にはどっちでもいいです。
412:デフォルトの名無しさん
04/03/08 13:37
だんだん本性を現してきたな。
自分の巣に帰りなよ。貴公子さんよ。
ｽﾚﾘﾝｸ(os板)
413:デフォルトの名無しさん
04/03/08 13:43
>>403
でもそのOSがあんな前時代的な仕様ではねぇ・・・
414:デフォルトの名無しさん
04/03/08 13:48
>>413
？
何か困る事でも？
415:デフォルトの名無しさん
04/03/08 13:51
>>414
>>403 生き残りは辛そうだから、
416:デフォルトの名無しさん
04/03/08 13:59
そういや、中国のGB2312って、日本のひらがな、カタカナが含まれるって
本当?
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5396日前に更新/262 KB
担当:undef