【UTF8】文字コード変換【SJIS】

【UTF8】文字コード変 ..

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って、日本のひらがな、カタカナが含まれるって
本当?

417:デフォルトの名無しさん
04/03/08 14:07
>>416
らしいね。
big5にも入ってるって話だぞ。

418:デフォルトの名無しさん
04/03/08 14:29
>>416
>>336

419:デフォルトの名無しさん
04/03/08 14:48
ここで UTF-8 以外のコードを提案してる人って、
SQL とかそーいうものも全部これから用意しよう、用意されるはずだ、というような
主張も imply してるって考えていいのかな。

それとも既存ライブラリやシステムと関連しない小規模な自作PG用としての提案なのかな。
そのへんはっきりさせてくれないと、批判とか批評とかしにくいと思うんだけど。

420:328
04/03/08 15:02
ねぇねぇ最初UTF-JPじゃなくてUTF-JAPANじゃなかった？

421:デフォルトの名無しさん
04/03/08 15:06
UTF-ｼﾞｬﾍﾟｰﾝ

422:デフォルトの名無しさん
04/03/08 15:07
COMPJAPAN互換？

423:デフォルトの名無しさん
04/03/08 16:22
大多数にとっては標準化を考えているのかどうか、それだけが問題じゃないのか？
こんなん考えました～だけだと誰もついてこないと思われ。

424:デフォルトの名無しさん
04/03/08 16:26
俺エンコーディング大流行の予感。

425:デフォルトの名無しさん
04/03/08 17:34
>SQL とかそーいうものも全部これから用意しよう、
>用意されるはずだ、というような
8bit目がonであればたいていOKなんだが。
あと再コンパイルが許されるならUCS-4が一番楽だろ。
C++ならインターフェース変更するだけでロジックは変わらんのだから。

426:デフォルトの名無しさん
04/03/08 18:40
質問させてください。
PHPで、EUCでソースを保存して、
CHARSETをShift_jisでブラウザ出力させたいのですが、
どうやったら出力させることができるでしょうか？
教えて下さい。お願いします。

427:デフォルトの名無しさん
04/03/08 18:41
PHPで、ソースをEUCで保存して、
Shift_jisでブラウザに表示したいのですが、
どうしたらうまくいくでしょうか？
ご存知の方、おしえてください。お願いします。

428:デフォルトの名無しさん
04/03/08 18:47
俺も新しいコードを考えてここの住人を煽ろうかな。

429:デフォルトの名無しさん
04/03/08 19:37
>>425
>8bit目がonであればたいていOKなんだが。
いや、エラー無く通るってだけじゃなくて、検索とかさ・・・

430:デフォルトの名無しさん
04/03/08 20:20
lexとかgrep関係はいろいろとあるんだけど、
それは適切なアルゴリズムでちゃーんとビルドフロムスクラッチすればOK。

431:デフォルトの名無しさん
04/03/08 20:30
>>430
面倒

432:デフォルトの名無しさん
04/03/08 20:38
>>431
ポマエラ、公開しても落としに来ないくせに。

433:デフォルトの名無しさん
04/03/08 21:39
既存のアルゴリズムで速くなければ意味ない。

434:デフォルトの名無しさん
04/03/08 22:55
古いアルゴリズムでマルチバイト対応のパターンマッチング処理は
恐ろしくムダ。
文字クラスの対応パッチなんて組み合わせが爆発するロジックのがある。

435:デフォルトの名無しさん
04/03/08 23:19
>>391
そういう優れたUTF-8というものが既に存在しているのに、なんで
新しくわざわざ欠点の多い符号化法を提唱するのかねぇ？

436:デフォルトの名無しさん
04/03/08 23:34
Unicodeの合成文字って、合成する順序は決まってるんですか?
必ず。Group-1 ---> Group-2 ---> Group3 の順序で符号を並べる
のか、それとも、順序は動でもいいのか。

順序がどうでもいいなら、完成形としては同じになるのに、符号としては
異なる文字もあることになる。

ハングル文字なんかも、合成済みの物と、素片(?)のものとがあったから、
検索するときは配慮しないと行けないような。

437:LightCone ◆sSJBc30S5w
04/03/08 23:41
>>435
日本語の文字に対するバイト数の増加が納得できないため。

438:デフォルトの名無しさん
04/03/08 23:48
>>436
順序どうでもいいよ。

配慮しないといけないよ。

現実ってこんなもん

439:デフォルトの名無しさん
04/03/08 23:51
>>438
ということは、合成文字に関しては、1バイト単位での検索ルーチンでは
対応できないということですね。

ちゃんとしたロジックを組まないと行けないんでしょうね。

440:デフォルトの名無しさん
04/03/08 23:59
>>436
URLﾘﾝｸ(www.unicode.org)
の2.10辺りとかを参照。
>　完成形としては同じになるのに、符号としては異なる文字
も「あり」。

じゃあ文字を比較するときどうすんだ、というのは
URLﾘﾝｸ(www.unicode.org)
辺りとかを参考にどうぞ。

441:デフォルトの名無しさん
04/03/09 01:18
もう面倒くさいから一文字64bitでいいよ
でかけりゃgz

442:デフォルトの名無しさん
04/03/09 01:43
合成文字は終端記号として処理すべきかギモンヌ。
なぜtexのようなシンタックスとして扱わんのかと。

443:デフォルトの名無しさん
04/03/09 09:29
>>441
さんせー

444:さっきゅん ◆GG1SfzBGbU
04/03/09 09:33
　　＿
　 /～ヽ
　(｡･-･)　｡oO( 64bitじゃぜんぜん足りませんが何か
　ﾟし-Ｊﾟ

445:デフォルトの名無しさん
04/03/09 09:40
256bitでどうだコンチクショー

446:デフォルトの名無しさん
04/03/09 10:03
>>445
どんだけ使えば気が済むんですか。

447:さっきゅん ◆GG1SfzBGbU
04/03/09 13:22
　　＿
　 /～ヽ
　(｡･-･)　｡oO( 最初からグリフでデータ交換すれば文字コードなんて概念消滅するんだけど
　ﾟし-Ｊﾟ

448:デフォルトの名無しさん
04/03/09 13:29
utf-2000とかどうか。

449:デフォルトの名無しさん
04/03/09 13:41
>>447
お前さんの言う「グリフ」ってのは「グリフイメージ」のことか？

450:デフォルトの名無しさん
04/03/09 13:42
>>448
古い。

451:デフォルトの名無しさん
04/03/09 14:34
検索どうするんだよ

452:LightCone ◆sSJBc30S5w
04/03/09 15:00
>>447
それだと、フォントが変えられないし、HTMLブラウザやコンパイラや
インタプリタに光学文字読み取り機を内蔵しなきゃならないし。

453:LightCone ◆sSJBc30S5w
04/03/09 15:02
合成文字まで考えるとやはり、結局固定長符号でも可変長符号でやる場合と
余り手間が変わらないのかな。

454:LightCone ◆sSJBc30S5w
04/03/09 15:06
合成文字がある場合は、UCS4符号を使っていたとしても、例えば「n文字目」の
ポインタを得たいとき、言わずもがな、いきなり
ptr = &linebuf[n-1]
みたいなことをやるわけにも行かず、普通は、カレント位置から順番にたどって
行くことになるだろうらら。

455:LightCone ◆sSJBc30S5w
04/03/09 15:07
合成文字まで考えると、結局、UTF8でも、ASCIIしか考慮していない
strstr()では正しく検索できないね。

456:デフォルトの名無しさん
04/03/09 16:59
>>444
この世の中に180京文字以上もあるのか？
1つの言語ごとに1億文字分のスペースあたえても余裕だと思うが。

>>合成文字
手抜きせず全部展開これ最強。

もっと富豪になれいつまでも貧乏性はｲｶﾝ

457:デフォルトの名無しさん
04/03/09 17:14
>>456
8文字しか表現できないと思ったのか？

458:LightCone ◆sSJBc30S5w
04/03/09 17:23
>>456
>この世の中に180京文字以上もあるのか？
64BITじゃ足りないというのは、合成文字も含めてのことでは?

459:デフォルトの名無しさん
04/03/09 19:56
⑳の大きいやつとか㍍とか合成顔文字とか、
そんなのをどんどん含めていくとして

まあそれでも一億は越えないよな。

460:LightCone ◆sSJBc30S5w
04/03/09 23:52
日中混合漢字テーブルを作ってみました:
URLﾘﾝｸ(www.nowsmartsoft.or.tv)

461:デフォルトの名無しさん
04/03/10 01:33
文字コード変換について語りましょう♪

462:デフォルトの名無しさん
04/03/10 03:08
たぶん24ビット（1677万文字）もあれば、合成なしで世界中の全部の文字を収録することが
出来そうな気がするが…

463:デフォルトの名無しさん
04/03/10 07:47
>>462
DecompositionやNFDを使うのは派生形や辞書順での扱いを容易に
するためであって、文字が足りないからではない。

464:デフォルトの名無しさん
04/03/10 10:37
>>463

465:デフォルトの名無しさん
04/03/10 15:11
>>464

466:デフォルトの名無しさん
04/03/10 15:15
>>465?

467:デフォルトの名無しさん
04/03/10 18:36
>>467

468:467
04/03/10 18:36
_|￣|●

469:デフォルトの名無しさん
04/03/11 16:20
Webアプリでhtmlで漢字入力した場合、サーブレットを通して最終的にJSPで表示する際、
どうしても文字化けが起こってしまいます。この場合に対処する方法としての
プログラムの記述の仕方を知っている方がいらっしゃたら教えてください。

470:デフォルトの名無しさん
04/03/11 17:30
そんなDQN言語使うからだ

471:デフォルトの名無しさん
04/03/11 18:38
言語がDQNなのではなく（ｒｙ

WebProg
URLﾘﾝｸ(pc2.2ch.net)

472:デフォルトの名無しさん
04/03/11 21:18
俺の知らない新言語が出来てるのかと思った。

473:デフォルトの名無しさん
04/03/12 00:38
質問です。
VBscriptを使って
「UTF-8」→「base64」→「UTF-8」のデコードを行いたいのですが、

ｇoogleでヒットするいろいろなサンプル関数をためしましたが、例えばこれでも
URLﾘﾝｸ(www.geocities.co.jp)
どれもbase64→SJISにデコしようとしてる？のか、日本語が文字化けします。
とんでもない見たこともないような特殊漢字に化けます。英数は正常です。

なんとかUTF-8にデコードする方法はありませんでしょうか。

y = decodeStreamSJIS(l, k) ' シフト JIS として解釈する場合。
' y = decodeStreamEUC(l, k) ' EUC として解釈する場合。

の部分に、unicode(UTF-8)にデコードするものを作ればいいのですが、いかんせん知識不足です。
目的としてはエンコードがかかったファイルをvbscriptバッチをはさみデコードするというものです。
ちなみにbasp21のデコード機能でさえ文字化けしました。
どれもみなSJISには直してくれるのですが、エンコ前の元データがUTF-8で、UTF-8にもどす
となると見つかりません。

なにか良い方法はないでしょうか。

474:デフォルトの名無しさん
04/03/12 01:05
すみません、質問です。
JSP画面で漢字表記するために必要なセンテンスって
何でしょうか？教えてください！！

475:デフォルトの名無しさん
04/03/12 06:29
>>473
base64ってバイナリをそのままエンコード、デコードするものだと思うのだが。
文字コードと何の関係が？

476:LightCone ◆sSJBc30S5w
04/03/12 22:52
URLﾘﾝｸ(www.nowsmartsoft.or.tv)

477:LightCone ◆sSJBc30S5w
04/03/12 22:55
投稿ミス(早走)りました。↑は、JIS第1水準+中国第一級。
↓が、JIS第1第2+中国第一級、第二級
URLﾘﾝｸ(www.nowsmartsoft.or.tv)

ついでに、Unicodeが、西洋の言語にヒイキ気味なことは、↓の最後の
方に書いてあります。異論あればどうぞ。
URLﾘﾝｸ(www.nowsmartsoft.or.tv)

478:473
04/03/13 12:34
>>475
確かにそうなんですけど。

479:デフォルトの名無しさん
04/03/13 12:44
>>478
VBScriptの内部コードがUTF-8だからSJIS(EUC-JP)->UTF-8変換が入ってるんじゃないか?
おそらく不要なコード変換部分をカットすれば良いだけだろう

480:デフォルトの名無しさん
04/03/13 13:14
あ、しまったマルチになってしまいました。
えっと>>479

URLﾘﾝｸ(www.geocities.co.jp)
を使っているのですが、見た感じ、
SJIS→UTF-8ってのは無いかんじですが、どのあたりでしょうか。

481:デフォルトの名無しさん
04/03/13 13:26
>>480
だからUTF-8とかSJISとかは実際のところ問題ではなくて
バイト列->内部コード変換をカットしろという話なんだが…

482:デフォルトの名無しさん
04/03/13 20:41
> 455 ：LightCone ◆sSJBc30S5w ：04/03/09 15:07
> 合成文字まで考えると、結局、UTF8でも、ASCIIしか考慮していない
> strstr()では正しく検索できないね。

お前、 wcsstr/wcswcs って知ってる？

483:LightCone ◆sSJBc30S5w
04/03/13 20:47
>>482
あなたは全く意味分かってないね。

484:LightCone ◆sSJBc30S5w
04/03/13 20:50
>>482
要するに、そういうものを使えば、あらゆる文字コードに対応できるのは
当たり前なので言うまでもないことなんだよ。

だけど､UTF8は、strstr()でさえも、合成文字以外は正しい結果を出すように
工夫されていると言うこと。

人を馬鹿にする前に自分が勉強すること。

485:デフォルトの名無しさん
04/03/14 00:08
string.h、ctype.h、regex.hなどの文字(列)に関係する関数全てが
UTF-8を使えば国際化されるのであれば話は別だが、strstrとか一部の結果だけ
取り上げて既存の文字コードより優れてると主張するのは、木を見て森を見ない馬鹿か
Markus Kuhnのような確信犯。まあ>>484は前者だろう。

486:デフォルトの名無しさん
04/03/14 01:05
OS 板に帰ってくれ。

487:LightCone ◆sSJBc30S5w
04/03/14 01:09
>>485
>UTF-8を使えば国際化されるのであれば話は別だが、strstrとか一部の結果だけ
>取り上げて既存の文字コードより優れてると主張するのは、木を見て森を見ない馬鹿か
>Markus Kuhnのような確信犯。まあ>>484は前者だろう。

UTF8の場合、何も修正しなくても大丈夫なことが多いと言うことが言えるわけで、
それが理解できないなら、UTF8について理解できてない。

488:LightCone ◆sSJBc30S5w
04/03/14 01:16
>>485
試しに、UTF8に変えたとき破綻する例上げてみなはれ。

例えば、人が解釈するなら、「文字数を出す」という関数を、
「バイト数を返す」に「意味の解釈」を修正しないと駄目だけど、
コンピュータ内部では、何も修正せずに矛盾無く辻褄が合う。

はっきり言えば、ある意味変な解釈のまま、関数同士がお互いに間違い続ける
から矛盾が生じないという事になる。

489:LightCone ◆sSJBc30S5w
04/03/14 01:17
自分が理解できないのを他人のせいにするのが流行ってまんな。2chは
大体そんなものだけど（笑）。

490:LightCone ◆sSJBc30S5w
04/03/14 01:32
というより、専門の「煽り屋」の仕業だな。多分。

なぜなら、こんな馬鹿で失礼な人、自分の周りではあったこと無いから。

よく考えたら、実際問題、こんな失礼な人間、町歩いて手もいないもんな(笑)。

491:LightCone ◆sSJBc30S5w
04/03/14 01:33
やっぱり1chの西さんの言うように、専門の煽り屋が居るって言う噂は、
本当なんだね。

492:デフォルトの名無しさん
04/03/14 03:00
最近放置気味だったのが、相手にしてもらえてうれしいようだ。

493:デフォルトの名無しさん
04/03/14 03:09
>>485 の言うとおり regex は随分変更を受けると思うが。
標準関数じゃないが、よく使われるので重大だ。

あと、１文字のバイト数が固定じゃなくなるので、
strchr は strstr で代用できるとしても、
strrchr は使えなくなってしまう。
他にも strpbrk や strtok も改変が必要。

isleadbyte も改変が必要で、
後続バイト数を返すようにする必要がある。

あとは、標準関数だけじゃなく、
独自のライブラリの関数も軒並みアウトだろうな。
まぁ、想定する文字コードが違うんだから、
１文字１文字処理していくタイプの処理が使いまわせないのは
当然っちゃー当然だけど、
Shift-JIS か EUC かって程度なら
isleadbyte 使ってりゃ何とかなることを考えると UTF-8 は随分面倒だ。
UTF-8 だと日本語は３バイト以上だし、どうやっても誤魔化せないな。

494:デフォルトの名無しさん
04/03/14 03:11
お願いします。これ以上構うと閣下の病状が極端に悪化してしまいますので
このあたりで勘弁してあげてもらえませんでしょうか。。。

495:LightCone ◆sSJBc30S5w
04/03/14 07:35
>>493
>strrchr は使えなくなってしまう。
ASCIIに対しては無修正で使えるので、これも人間側の解釈の問題で、
コンピュータ内部では全く問題が発生しません。

それに対して、これがもし、Shift_JISであったならばそうは行きません。

>regex は随分変更を受けると思うが。
どのように変更を受けるんでしょうか?(笑)

496:LightCone ◆sSJBc30S5w
04/03/14 07:36
多分、>>493も、UTF8の特性を理解してませんね。

試しに、regexの修正点を上げてみて下さい。

497:デフォルトの名無しさん
04/03/14 08:34
>>496
文字単位でマッチングしないと使い物にならないからじゃないか?
mblenなどをしっかり使っていればあまり問題は出ないはずなのだが
実際のアプリではロケールの初期化すらまともにされていなかったりする

498:LightCone ◆sSJBc30S5w
04/03/14 08:45
>>497
>文字単位でマッチングしないと使い物にならないからじゃないか?
何故?

regexの主たる目的は置換。

それに何故、文字数が必要? バイト位置で足りるはず。

せっかく、何もしなければ辻褄が合ってるのに、mblen()なんて使うと
破綻します。

499:デフォルトの名無しさん
04/03/14 08:50
単純に、こんな場所で偉ぶっていい気になってる「LightCone ◆sSJBc30S5w」が
可哀相に思えるのは私だけですか？

500:デフォルトの名無しさん
04/03/14 09:18
>>498
この界隈のｺﾃﾊﾝは相手が誤解していると思いこむ傾向が強いように見えるけど
実際は両方が誤解している場合が多そうだよ
この件も問題にしている部分が違うだけ

501:デフォルトの名無しさん
04/03/14 09:37
アホコテさらしage

502:LightCone ◆sSJBc30S5w
04/03/14 09:43
>>500
それは、違いますな。

何故かというと、ワテと話していて全く誤解が生じない人種と
あったことがあるからです。

すんなり話が通じて楽しかった。

はっきり言って、一般人と話すのは苦手です。バカの壁を感じるから。

503:LightCone ◆sSJBc30S5w
04/03/14 09:47
ワテと話していてワテが間違っていると思う人は、
まず、99.99%位、あんたの間違いだと思って大丈夫。

それに大抵の優秀な人は、深読みするのでそうそう簡単に相手の間違いを
断定しない。

はっきり言って、間違ったことを行ったときでさえ、それなりに意味の
通じる解釈をする人が多い。

2chラーで批判ばかりしている人は全くの逆で、知能の低さがすぐに分
かる。

結局、辻褄の合う解釈法が重い浮かばなくて、理解できないんだよ（笑）。

アホ

504:LightCone ◆sSJBc30S5w
04/03/14 09:49
はっきり言って、邪魔になるから、そういう人達には勉強などさせずに、
遊ばせてやったらいいんじゃないかと思ってる。

505:デフォルトの名無しさん
04/03/14 09:52
>>503
相手の発言の意図を読む意志がないと指摘しているだけなんだが
無駄な発言をして悪かったよ

506:デフォルトの名無しさん
04/03/14 09:55
>>502
> 何故かというと、ワテと話していて全く誤解が生じない人種と
> あったことがあるからです。

M-x doctorかい？

507:デフォルトの名無しさん
04/03/14 10:00
>>503
＞それに大抵の優秀な人は、深読みするのでそうそう簡単に相手の間違いを
＞断定しない。
＞
＞はっきり言って、間違ったことを行ったときでさえ、それなりに意味の
＞通じる解釈をする人が多い。

あんたはアホウだということだね。自認しているとは謙虚なやつだ（ｗ

508:デフォルトの名無しさん
04/03/14 10:04
とりあえずUnicodeいらね＞自分コード作ったという所らしいけどさ、中共政府並みの強制力とか
影響力がない個人でやるのはきついだろうねぇ。
LightConeて人がどういう人か知らんのでOS板見て来たら自分でOS作ってる人なんだね。
それならそこでの実装に限定してそっちで話してればいいんじゃなかろうか？って思う訳だが。
ム板に来てやってんのはどういうあれなんだろう？
このスレは最初は単発質問スレっぽい雰囲気だったけども、ほとんど既存のOSの上で規格として
動いてるUnicodeとローカルエンコードの変換とかの話してたと思うんだが。

なんで、このスレなんだろう？
自分コードを自分OSに実装したよの宣伝だとしたらちょっといただけないんだが。

自分で掲示板作ってそっちでやってるもんだとばっかり思ってたんだが、ここにきて煽りに対抗
するためだけに書き込みしてるみたいでちょっと痛いぞ。

ここでやってないでそっちでちゃんとした議論してた方がいいんじゃなかろうか？
老婆心だけどね。

509:LightCone ◆sSJBc30S5w
04/03/14 10:09
>>507
なんか、なんでも基準を曖昧にしたがるようだけど、取りあえず、
悪いけど、そういう人種の人たちには、ワテ自身が確信していることに
対して批判を受けたことは未だにないんだよ。

もう、答えが出てしまって、証明済みで、なんの迷いもない結論に
達しているのに、まだ反論してくる人が居るのは、ネットのみの経験
だから、違いが如実。

510:デフォルトの名無しさん
04/03/14 10:13
発作age!

511:LightCone ◆sSJBc30S5w
04/03/14 10:14
はっきり言うとね、ワテだって、結構間違うことはあるんだよ。
でも、そういう場合、
「そんなことがあったんですかいな!?」
「まいった、見落としてた!!」
「また、アホなミスをしった!!」
と思うわけ。

結局、指摘が的を射てるわけなんですよ、そういう連中は。

512:デフォルトの名無しさん
04/03/14 10:23
宣伝なら業者みたいに黙々とコピペしまくればいいのに。

513:デフォルトの名無しさん
04/03/14 10:48
すいません、コーンたんはこういう人なんです。
すごくやる気があります。それは確かです。
でも、いつも車輪をダウングレードして再発明する人なんです。
しかも、人の指摘や忠告を聞く気はサラサラなく、一方的に放送した挙句、
最後はいつも「おまえらアホだ、俺は正しいのに」で終わるのです。

514:デフォルトの名無しさん
04/03/14 12:07
正規表現の . がある。
これは任意の１文字にマッチングする。
ASCII の１文字は１バイト固定だが、
UTF-8 の１文字は１バイトとは限らない。

sed の書き方になるが、
s/a.a/aa/g
の場合、UTF-8 の "aあa" を置換しようとしても、
ASCII の regex を使うと ''あ' は３バイトなため、マッチしない。

515:デフォルトの名無しさん
04/03/14 12:14
2chは、確かに引きこもりやら、学生やらが多い。（俺も学生です・・・。）
確かにろくに分かっていないことでも、分かっているように言っている人も多いだろう。
ただし問題は時々有り得ないほど知識を持った人が紛れ込んでいること。
引きこもりばっかだと思えば、イケメンやら美人やらが紛れ込んでいるという事実。

不特定多数が集う匿名掲示板である以上、言葉遣いには気をつけるべし。

「車輪の再発明」という言葉を多用して批判する人がいるが、
こいつ自分の言葉に酔っているんだなぁと思うことはある。

516:デフォルトの名無しさん
04/03/14 12:15
で、ﾗｲﾄなんたら氏はそのあり得ないほど知識を持った人だと？

517:デフォルトの名無しさん
04/03/14 12:18
声を大にしていいたい。
日本が戦争に負けたとき、マッカーサーにより
日本は日本語を廃止し、すべて英語になるべきだった。
あまりにくだらないロスがおおすぎる。

当時まさかコンピューターでこんなロスが発生するとは
考えてもいなかったろうが。
すべて英語だったら、モジコードうんぬんなんて
こんなくだらない苦労しなくてすむのに。

518:デフォルトの名無しさん
04/03/14 12:19
暴言ｷﾀｰ

519:らいとこうん
04/03/14 12:21
ワテはOSを作れるほど知識を持った優秀な人間です。

520:LightCone ◆sSJBc30S5w
04/03/14 12:25
>>514
>正規表現の . がある。
>これは任意の１文字にマッチングする。
>ASCII の１文字は１バイト固定だが、
>UTF-8 の１文字は１バイトとは限らない。

なるほど、それは確かにそうです。
UTF-8でも無修正で完全対応とは行かない例の一つですね。

考えるまでもなく、「文字数」が意味を成している部分はことごとく
駄目になります。今の場合でも、1文字ではなく「任意の文字の列」
でいいなら、「a.*a」で行けると思います。つまり、1「文字」と
いう「文字数を数える行為」に失敗しているのが原因なのですね。

521:デフォルトの名無しさん
04/03/14 12:25
>517
お前は効率のために生きてるのか？
文化には多様性が必要だと思わないのか？

まあ始皇帝も文字と秤を統一したがったけど、
アメリカみたいなインチが主流の国も世の中にはあるからな。
当分ラクにはならんよ。

522:LightCone ◆sSJBc30S5w
04/03/14 12:36
>>514
ついでなので、「.」以外にもありますか?

523:デフォルトの名無しさん
04/03/14 12:38
文字数に関わるもの全て。 {n,m} とか。

524:デフォルトの名無しさん
04/03/14 12:41
あと文字種の考え方自体もunicodeとそれ以外じゃ違う。
perlunicodeとか見たらそれなりの準備されてるのがわかるはずだ。

525:LightCone ◆sSJBc30S5w
04/03/14 12:45
>>523
a{2,5}
とか、
(あ){2,5}
とかなら問題ないのでは?

526:デフォルトの名無しさん
04/03/14 12:46
>525 なんすかその不自然な括弧は？

527:デフォルトの名無しさん
04/03/14 12:47
あまり適当なことを言うと

> 484 名前：LightCone ◆sSJBc30S5w 投稿日：04/03/14 01:41
> 2chって、詳しい人が多いのかと思ってたけど、かなり勘違いみたいですね。
>
> そういう勘違いが起きてしまう理由は、いくつかの可能性がありますね。
>
> 一つには、来る人が多いから、全然詳しくなくて断片的な知識を持ったいさま
> ざまな人が来るため、一見もの凄く詳しい人が居るように見えるだけで、実際は、
> 断片知識の烏合の衆の集まりに過ぎない可能性。

こんな事言われちゃうよｗ

528:LightCone ◆sSJBc30S5w
04/03/14 12:48
>>526
そりゃしゃあない。

529:デフォルトの名無しさん
04/03/14 12:49
そのカッコをつければできるとしても、
そのカッコはつけたくないなぁ。

530:デフォルトの名無しさん
04/03/14 12:53
相手にしすぎると

> 515 ：デフォルトの名無しさん：04/03/14 12:14
> 2chは、確かに引きこもりやら、学生やらが多い。（俺も学生です・・・。）
> 確かにろくに分かっていないことでも、分かっているように言っている人も多いだろう。
> ただし問題は時々有り得ないほど知識を持った人が紛れ込んでいること。
> 引きこもりばっかだと思えば、イケメンやら美人やらが紛れ込んでいるという事実。
>
> 不特定多数が集う匿名掲示板である以上、言葉遣いには気をつけるべし。
>
> 「車輪の再発明」という言葉を多用して批判する人がいるが、
> こいつ自分の言葉に酔っているんだなぁと思うことはある。

こんな事言われちゃうよｗ

531:デフォルトの名無しさん
04/03/14 12:55
そして雪崩れ込むように

> 517 名前：デフォルトの名無しさん投稿日：04/03/14 12:18
> 声を大にしていいたい。
> 日本が戦争に負けたとき、マッカーサーにより
> 日本は日本語を廃止し、すべて英語になるべきだった。
> あまりにくだらないロスがおおすぎる。
>
> 当時まさかコンピューターでこんなロスが発生するとは
> 考えてもいなかったろうが。
> すべて英語だったら、モジコードうんぬんなんて
> こんなくだらない苦労しなくてすむのに。

こんな事言われちゃうよｗ

532:デフォルトの名無しさん
04/03/14 12:56
>>529
つけたくないなぁと言われても。

533:デフォルトの名無しさん
04/03/14 13:01
論旨は「バイト単位の正規表現モジュールでutf8も問題なく扱える」だったと思うが、
. や [] のことも考えてない「全然詳しくなくて断片的な知識を持った」人だったと。

まあ間違えたのは仕方ない。しかし間違った後にうだうだいってるのは無様だし、
間違いを書く前に自分で検証する姿勢が足りてないのが暴言の数々から読み取れる。

頭冷やしてきなよ。

534:デフォルトの名無しさん
04/03/14 13:01
>>525
つまり世界中のregular expressionを使ったプログラムを修正して回れってこと？
普通の人は、regular expressionのライブラリのほうを修正すると思うが。

535:デフォルトの名無しさん
04/03/14 13:04
LightCone様の足下にも及ばない厨房のくせにいきがってんじゃねーよ。

536:デフォルトの名無しさん
04/03/14 13:06
>>535
何故そこでよく分からない横槍が入るｗ

537:デフォルトの名無しさん
04/03/14 13:06
いや正規表現側で工夫してきたのが今までの日本のperl文化だからなぁ。
どこにでもあるからって理由でperl使ってた人はそこに適応するようにスクリプト側で工夫してたわけ。
それも普通じゃないってこと？

まあLightCornが破綻してるのは既に明らかだが。

538:デフォルトの名無しさん
04/03/14 13:06
>>534
普通の人はOSなんか作らないよ！

とフォローにもならない暴言を吐いてみる

539:デフォルトの名無しさん
04/03/14 13:09
話は変わるけど俺はucs2よりもutf8の方が寿命が長そうだから好きだ。
何度も書き直したくないじゃん？なら可変長のエンコーディングで通した方が将来性がある。
\0があまり登場しないから既存OSとの親和性も悪くないし。

540:デフォルトの名無しさん
04/03/14 13:10
既にucs2対応のOSでしか動かないとか、
システムコールの度にエンコード変換するとか、
そういうのはイヤですわ。

541:デフォルトの名無しさん
04/03/14 13:15
Ruby は正規表現に日本語が使えるよ！
やっぱ使えたほうが便利だよ。

542:デフォルトの名無しさん
04/03/14 13:17
文字コード総合スレあっても良かったんかなぁ。
このスレの主旨って元々はピンポイントに「変換」だし。

543:デフォルトの名無しさん
04/03/14 13:19
ひまわりなら日本語だけで書けるよ！

544:LightCone ◆sSJBc30S5w
04/03/14 13:22
正規表現ルーチンは、UTF8を使っても要修正でした。

すんません、訂正します。

これで気が済むんでっか?

545:デフォルトの名無しさん
04/03/14 13:23
自分が独りワイワイと騒いどいて何いじけてんの？子供だね。

次ページ