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
自分が独りワイワイと騒いどいて何いじけてんの？子供だね。
546:デフォルトの名無しさん
04/03/14 13:26
>>544
こっちはコーンたんが何言おうともはや気にしてないけど。
547:デフォルトの名無しさん
04/03/14 13:29
という訳で終ー了ー。
548:デフォルトの名無しさん
04/03/14 13:29
見てて不憫になってきた。
549:デフォルトの名無しさん
04/03/14 13:32
文字が UTF-8 が表現されるとすると、
strrchr("あいあい", 'あ');
とかいう１文字逆検索ができない。
'あ' は３バイトだし、UTF-8 は最長６バイトだから、
こういう表記自体に問題があるかもな。
文字列の逆検索があれば代用できるんだけど...。
あと、strpbrk, strtok, strspn, strcspn の第二引数も改変が必要。
こういう１文字＝１バイトを仮定されると困る処理は軒並みアウトだ。
550:デフォルトの名無しさん
04/03/14 13:51
ungetc()とかきっと1バイトしか戻せないよ……。
551:デフォルトの名無しさん
04/03/14 14:25
英語圏のプログラムで、設定ファイルを読んだりログを書いたりする程度ならまあ改造なしでも通るけどさ。その程度だよな。
552:デフォルトの名無しさん
04/03/14 14:28
結局書き直しまくりだねぇ
553:デフォルトの名無しさん
04/03/14 16:14
regexはcharacter classとcollation orderも扱うのだが、
何故UTF-8など修正無しでOKだと思ったんだろう。
554:デフォルトの名無しさん
04/03/14 16:32
Perlなんかでも正規表現は漢字1文字が2バイトになるって分かって書いてきたからね。
そういう感覚を前提にしたら、検索で誤マッチしないだけで充分ってことでは。
555:デフォルトの名無しさん
04/03/14 17:06
collationなんてやりだしたら修正どころじゃないな
556:デフォルトの名無しさん
04/03/14 17:28
glibcのregex国際化
URLﾘﾝｸ(lc.linux.or.jp)
URLﾘﾝｸ(lc.linux.or.jp)
557:デフォルトの名無しさん
04/03/14 20:07
>上述の通り、我々の実装はDFA をベースとしている。
>このため、NFA ベースの実装では避けられないback tracking の問題
>が生じない。
NFAベースでもバックトラック無しの実装をアップしとるのに。
複数の状態変数のパラレルな遷移という例で。
>しかし、Single UnixSpecification[3] などの規格において、
>あるコードポイントに文字が割り当てられているかどう
>かをエンコーディングから独立に調べる方法が用意されていない。
着眼点が悪い。
実は既に正規表現式から必要最小限な集合を抽出する方式がある。
つまり、入力値の範囲ではなく、パターン自体にその答えがある。
オーバーヘッド無し、むしろ従来より高性能な実装は可能。
と、ここで書いてみる。
どうせダウンロードとしてないんだろうな。
従来と違うアプローチの実装例をいくつも出したのに。
558:デフォルトの名無しさん
04/03/15 00:10
>>554
いつの時代のperlの話だよ。.を1byteと見做すなんて。
PCRE is short for Perl Compatible Regular Expressions.
URLﾘﾝｸ(www.regular-expressions.info)
559:デフォルトの名無しさん
04/03/15 00:15
それから、printf系がUTF-8で問題ないって言う人いるけど、
%c, %lcが全く駄目じゃん。範囲限定で使えないことはないレベル。
560:デフォルトの名無しさん
04/03/15 00:34
複数回 %c すればー、ということじゃない？
改変するとすれば、アドレス渡すようにしないといかんのかな。
そもそも文字リテラルの仕様をどうすればいいんだろうか？
561:デフォルトの名無しさん
04/03/15 01:04
>>558
現状ではこの手のツールの漢字対応って大抵無理やり動かすパッチだけど。
ggrepの日本語対応パッチで比較回数が爆発したりとかするやつあったし。
562:デフォルトの名無しさん
04/03/15 01:10
漢字対応って一体何の話? ここはUnicodeのスレですよ?
>>553の言っていること理解できる?
563:デフォルトの名無しさん
04/03/15 01:12
ああ、すまん、マルチバイト対応だ。打ち間違い。
564:デフォルトの名無しさん
04/03/15 09:43
>>558
一般人にもっとも馴染みの深いプロバイダのおまけCGI環境だと今でも普通だが。
565:デフォルトの名無しさん
04/03/15 09:49
>>559
さすがにそれは言いがかりだろ。
マルチバイトでcharに入らない時点でどう転んでも無理。
wchar_tでwprintf使ってなさいってこった。
566:デフォルトの名無しさん
04/03/15 09:50
>>564
まさかそれが正しいことだと思ってるんじゃなかろうな・・・
567:デフォルトの名無しさん
04/03/15 09:51
>>565
いや、だから>>559は「どう転んでも無理」という話をしているのだが・・・
568:デフォルトの名無しさん
04/03/15 09:55
>>564
その環境100%信頼してバッチジョブで
漢字ファイル名の自動リネームに使うとあぼーん。
Rubyも1.8になるまで不具合連発だったし、今でも警戒してる。
569:デフォルトの名無しさん
04/03/15 10:00
そこはバッドノウハウで回避ですよ。
570:デフォルトの名無しさん
04/03/15 10:06
バッドノウハウ？
ちゃんと再設計すりゃいいじゃんか、アルゴリズムを変えて。
マルチバイトの対応は10年たっても20年たっても不完全。
571:デフォルトの名無しさん
04/03/15 10:12
>>570
おつむの弱い人ですか?
アルゴリズムて 誰がregexライブラリ設計の話してるの…
572:デフォルトの名無しさん
04/03/15 11:16
>>571
551から554,556,558の流れなんだけど。
573:デフォルトの名無しさん
04/03/15 14:51
571はLightCone
574:デフォルトの名無しさん
04/03/15 21:00
彼は名無しで煽らないよ。
575:デフォルトの名無しさん
04/03/15 22:12
いやぁ、ときたま名無しのLightConeがまぎれているような気がするんだが。
なぁ、>>574
576:デフォルトの名無しさん
04/03/16 01:28
>>562
誰も突っ込んでないようだが、
このスレは別に Unicode のスレじゃない。
577:デフォルトの名無しさん
04/03/16 02:12
文字コード総合スレあった方が良かったかな？
僅かな需要はあるのかも。
578:Shift_JIS
04/03/16 02:24
私の頃忘れないで…
古い欠点ばかりの女とお思いでしょう。けどわたし…(ﾓｼﾞﾓｼﾞ
579:デフォルトの名無しさん
04/03/16 07:59
UTF8とSJISのスレだと勘違いされてもしかたないタイトルだな。
580:デフォルトの名無しさん
04/03/16 15:43
java厨ならその2つだけでなんとかなるからな
581:デフォルトの名無しさん
04/03/16 23:12
なるかボケ
582:デフォルトの名無しさん
04/03/16 23:52
質問です。
VBscriptでUTF8からSJISに変換という
関数や方法はあるのでしょうか。
583:デフォルトの名無しさん
04/03/17 01:00
>582
ふつーに変換DLLをインポートできねーの？サーバサイドだよね？
584:デフォルトの名無しさん
04/03/18 00:11
できれば、VBscript内で行いたいです。
そのＶＢscriptファイルををダブルクリックすると
指定したUTF8のファイルを読み込み、SJISに変換したものを
別ファイルとして吐き出す
っていうのを作りたいのです。
585:デフォルトの名無しさん
04/03/18 00:42
んー、UTF8からUCS2への変換はふつーに書けるよね。
UCS32からCP932への変換はAPI呼ぶとか自前でテーブル持つとかでできるね
586:デフォルトの名無しさん
04/03/18 00:50
>>585
basp21
の「kconv」を使ってはみたのですが、どうもうまくいきません。
使い方間違っているのでしょうか・・
587:デフォルトの名無しさん
04/03/18 03:00
UTF8 ─自前ルーチン→ UCS2 ─WideCharToMultiByte→ SJIS
UTF8 → UCS2
URLﾘﾝｸ(www.linux.or.jp)
588:デフォルトの名無しさん
04/03/18 23:20
やはりこれってのはスレがたつほどなんで
文字コード知識ある人でも難しい問題なんですか？
basp21でできそうだったんですが・・・できないものですね。
589:デフォルトの名無しさん
04/03/18 23:40
ﾜﾗﾀ
590:デフォルトの名無しさん
04/03/18 23:40
普通の人でもある程度書けるけど正確さを目指すと規格の曖昧さで苦労する問題です。
588はもーちょっと修行すれ。もしくはちゃんとコードとエラー内容を出して質問すれ。
591:デフォルトの名無しさん
04/03/19 11:21
>>587
WideCharToMultiByte使うなら、Win95での動作を想定しなくてよければ
MultiByteToWideCharでUTF-8＞UCS-2変換すればいいと思うが。
592:デフォルトの名無しさん
04/03/19 12:36
MSLU入れてもその辺アップデートされないの？
593:デフォルトの名無しさん
04/03/19 13:13
>>592
unicow.dll(だっけ?)をリンクしているアプリからしか使えない。
VBScriptからという条件じゃ無理
594:デフォルトの名無しさん
04/03/19 22:04
すみません、全くの初心者なのですが、perl 5.8.2での質問です。
test.txtという、shift-jisで保存されたテキストファイルがあります。
（ファイル名も、置かれているディレクトリも常に同じ。）
このファイルを、utf-8に変換したいのですが、やり方がわかりません。
いろんなサイトを参考にして、何種類かやり方があるようなことがわかり、
試しに、
use utf8;
$input_filename ='C:\hoge\test.txt';
$output_filename ='C:\hoge\test.txt';
open my $in,'<:encoding(shift_jis)',$input_filename or die "open $input_filename: $!\n";
open my $out,'>:encoding(utf8)',$output_filename or die "open $output_filename: $!\n";
while(<$in>){print $out $_;
}
close($in) or die "read $input_filename: $!\n";
close($out) or die "write $output_filename: $!\n";
という風に書いてみましたが、結果はtest.txtの中が空になるだけでした。
また、別のやり方として、
use utf8;
$input_filename ='C:\hoge\test.txt';
$output_filename ='C:\hoge\test.txt';
use Encode qw(from_to);
open my $in, "<", $input_filename or die;
open my $out, ">", $output_filename or die;
while(<$in>){
from_to($_, "shift_jis", "utf8");
print $out $_;
}
という風なやり方も試してみましたが、結果は同じでした。
どこがいけないのでしょうか？
どなたか詳しい方、よろしくお願いします。
595:デフォルトの名無しさん
04/03/19 22:53
perlは門外漢なんだが、入力と出力が同じファイル名でいいの？
ファイルが空になるような。
596:デフォルトの名無しさん
04/03/19 23:01
windowsだと確実にダメなはず。出力を開いた時点でファイルサイズが０になる。
597:デフォルトの名無しさん
04/03/20 01:24
結局のところ
UTF8→ShiftSJIS
直変換は無理ってこと？
598:デフォルトの名無しさん
04/03/20 01:25
BASP使っては無理？
599:デフォルトの名無しさん
04/03/20 02:24
結局変換コード自前で書いたとしても、
UTF8 から UCS2 のコードを求めて
それを SJIS に変換するってコードを書くことになるしな。
まぁ、１文字１文字変換した方が
余計なバッファが要らない分効率はいいかとは思うけど、
変換に MultiByteToWideChar/WideCharToMultiByte を使うと
呼び出しコストが高そうなので、全部自前で組まないと意味が無いかも。
ただ、使用言語が VBScript なので、ひょっとしたらひょっとするかも？
600:デフォルトの名無しさん
04/03/20 06:22
ShiftSJIS 。
ムリでもなんでもねーよ。てめーがヘタなだけだ
601:594
04/03/20 08:57
594です。
無理なのでしょうか？できるのでしょうか？
perlのスレとかに行ったほうがわかるのでしょうか？
602:デフォルトの名無しさん
04/03/20 09:59
>601 inとoutで開くファイル名変えれ。それだけだ。
603:デフォルトの名無しさん
04/03/20 13:08
簡単に変換する方法ないですか？
604:デフォルトの名無しさん
04/03/20 13:34
つかお前誰だ
605:デフォルトの名無しさん
04/03/20 22:01
URLﾘﾝｸ(www.vector.co.jp)
これを元に、なんとかできないかな
606:デフォルトの名無しさん
04/03/20 22:21
パイナリファイル
607:デフォルトの名無しさん
04/03/24 00:06
JISの半角カナなんだけどさ
ESCJ と shift-out と 7bit が続く場合と ESC I の後に 7bitが続く場合は ASCII扱いでOK?
7bitの場合で他（というとESC I +shift-out+7bitのことだが）はX201扱いでOK?
608:デフォルトの名無しさん
04/03/24 00:50
やや意味不明。ESC J って、ESC ( J のことか？
そうだとして、SO の後は G1 に何が入っているかによる。
日本ではX0202の右側を入れることが多いかな。
ESC ( I の後は X0201右側が G0 に designate されているから、
7bitならX0201右側しかない。
「7bitの場合で他」って、なんで一通りに決まる？
ESC ( I SO の後は、最初の場合と同じで G1 に何が入っているかによる。
609:デフォルトの名無しさん
04/03/24 00:52
↑のX0202はX0201のことな
610:デフォルトの名無しさん
04/03/24 01:02
JIS の半角カナって、M$ の仕様拡張じゃなかった？
611:デフォルトの名無しさん
04/03/24 01:13
おまえはこのスレにいる資格なし
612:デフォルトの名無しさん
04/03/24 09:27
いまどきこんなDQNエンコード使ってるほうが悪いんだよ
613:デフォルトの名無しさん
04/03/24 09:50
>>608
X0201右側って何? 片仮名用図形文字集合のこと?
614:デフォルトの名無しさん
04/03/24 10:06
> ESC ( I の後は X0201右側が G0 に designate されているから、
> 7bitならX0201右側しかない。
これ以前にG1～G3がGLに呼び出されていれば
そこに何が入っているかによる。
ESC 2/8 FでG0に何が指示されようと関係ない。
(一意な符号化が要求されている場合は使用可能な文字が
変わるかもしれないけど)
615:デフォルトの名無しさん
04/03/24 10:18
>>614
> これ以前にG1～G3がGLに呼び出されていれば
> そこに何が入っているかによる。
そうだった。SOとかLS2/LS3が先行してる場合があるか。
>>613
そのつもり。
616:デフォルトの名無しさん
04/03/24 10:26
>>615
7bitで「右側」という表現に違和感を感じたので。
確かにX0201に規定されている8ビット符号は片仮名をGRに
呼び出すものしかないけど
617:デフォルトの名無しさん
04/03/24 22:29
>612 悪いな。IRC関連なんだよ
618:デフォルトの名無しさん
04/03/29 10:48
IRCの日本語文字コードってISO-2022-JPじゃなかったっけ?
619:デフォルトの名無しさん
04/03/30 01:46
age
620:デフォルトの名無しさん
04/05/05 19:26
BOMありUTF-8などというばかげたものが禁止されていないのはなぜですか？
621:デフォルトの名無しさん
04/05/05 20:13
>>620 UTF-8を自動識別できるから(ｗ
ASCII/ANSI互換がメリットなのだから、BOMは付けるべきではないというのが
一般論。でも付けて違反とはISO 10646にもRFCにも規定はないですね
Use caseによるんじゃないですか？
XMLやHTMLなら、encodingパラメータでコードセットを取得できるので不要、
でもそうでないものやencoding指定が無い場合は識別方法が7fhコードが
含まれているかとかあやふやな、確実に特定する手段無いし・・・
それはS-JIS、GB 2312、Big5、KS C5601(KS X1001)、CNS 11643等でも
同様ですが
622:デフォルトの名無しさん
04/05/05 20:14
>>620
Byte Order Mark の何たるかをご存知でない
お間抜けちゃんがこの業界を仕切っているからでぬるぽ。
623:デフォルトの名無しさん
04/05/05 22:54
いきなりレベルの低い話になりますが、～問題は皆どうやって
回避してますか？
624:デフォルトの名無しさん
04/05/06 07:38
~→～のこと?
625:デフォルトの名無しさん
04/05/06 07:59
WAVE DASH(～)が\u301cにマッピングされる問題でしょ。
626:625
04/05/06 08:02
失礼、「U+301C」の方が良いですね。
627:デフォルトの名無しさん
04/05/06 10:13
iconvもglibcも使うときはSJISじゃなくてCP932を指定してる。
emacsもCP932変換テーブルを作って、さらにutf-8 decode部分を書き換え。
実際どうなんだろう、SJISが必要な人って、どれぐらいいるんだろう？
大部分の人はCP932が欲しいわけで、SJISじゃないと思うのだけど、
そうでもない？
628:デフォルトの名無しさん
04/05/06 11:28
>>621
> でも付けて違反とはISO 10646にもRFCにも規定はないですね
どういう場合に付けてはいけないか(というか付いてたときZWNBSP
ではなくBOMであると解釈してはいけないか)はRFC 3629で
明確化された
629:デフォルトの名無しさん
04/05/06 13:54
>>627
Unicode→SJISで、「どっちが来てもいいように」対応することは可能だけど
SJIS→Unicodeだと、どっちにするか決めないといけない
という問題がありますね。
それと、OracleのNLSのような、ハック不可能な領域だとかなりどうしようも
ない気が。
そういえば、JavaはもうShift_JISがWINDOWS-31JじゃなくてSJISのエイリアス
になってるんでしたっけ。これ、困る人が多いんじゃないのかなあ。
630:デフォルトの名無しさん
04/05/06 16:46
> Unicode→SJISで、「どっちが来てもいいように」対応することは可能だけど
U+005CとかU+007Eが来たときどう変換する?
Shift_JISがX0208の附属書1どおりじゃなくて
1バイト部分はASCIIであるとみなせば対応は可能だけど
631:デフォルトの名無しさん
04/05/06 20:09
>>630
実際問題として、ASCIIと見なさないと、使い物にならないでしょう。
\にどういうグリフが当てられていようと、日本人もそれをエスケープ記号や
パスのデリミタとして(バックスラッシュと同じ意味で)使っているんだから、
他のコードポイント割り当てたら、はっきり言って実用上はお話にならない。
従来通りFontの問題として対応するのが「今のところは」現実的じゃないの。
632:デフォルトの名無しさん
04/05/06 23:53
エスケープ記号はともかくパスのデリミタはWindowsの場合だから
それは単にエンコーディングとしてCP932を想定しているというだけの
話だと思うんだけど。
実際Appleの変換表は円記号をU+00A5に割り当てるし
633:デフォルトの名無しさん
04/05/07 00:26
そのエスケープ記号が大問題だと思うが。
世の多くのプログラミング言語だのTeXだのシェルだのにおいて
メタキャラクタとして使われてるんだから。既存のソースの類が突然にして
コンパイル不能な屑の山になるでしょ。
無論DOS, Windowsユーザにとっちゃパス区切りであることの方が
さらに問題だが。
634:デフォルトの名無しさん
04/05/07 03:27
>>631
そりゃ、プログラマ至上主義だね。
普通の文書に半角円記号使ってた人は困る。
635:デフォルトの名無しさん
04/05/07 08:16
>>634
そしてTerminal上でバックスラッシュと円記号の混乱でうめき、SafariでWebの円記号がバックスラ
ッシュになってもがくOSXユーザが湧いてでてくると。
636:デフォルトの名無しさん
04/05/07 09:14
>>632
Mac OS Xだと、Shift JISのprogramを、
UTF-8で保存して、REVERSE SOLIDUS(0x5c)のつもりが、
YEN SIGN(0xa5)になって悩んでいる学生さんが、
既にいらっしゃいますよ。
Terminal.appで、YEN SIGNが出力されていても、(\nとか)
教科書にYEN SIGN書いてあんだもん、初級の人はわけが分からないよね。
637:デフォルトの名無しさん
04/05/07 09:48
Safariの ~ が ～ になっちゃうよ問題とか。
638:デフォルトの名無しさん
04/05/07 09:53
「どっちが来てもいいように」対応するというのも
そんな簡単じゃない。
たとえばPARALLEL TOとDOUBLE VERTICAL LINEしか違わない
名前のファイルが同じディレクトリにあると、どちらか片方しか
開けないとかどっちが開かれるかわからないとか、
どっちが作成されるか分からないとか。
そもそも両者を同一視したいというのは日本だけの都合であって、
たとえばGBKには両方とも存在するから勝手に同一視されたら
多分困る。
639:デフォルトの名無しさん
04/05/07 12:57
<item1 name="セーター" price="\500" image="c:\image\item1.jpg">
みたいなのをきちんと utf-8 にする処理は多言語対応では難しいよね・・・
640:デフォルトの名無しさん
04/05/07 13:15
>>639
> <item1 name="セーター" price="\500" image="c:\image\item1.jpg">
と記述するcoding systemがyenとbackslashを区別できていれば問題ないし、
区別できていないのなら、それはコード変換とは別ドメインの問題だろ。
641:デフォルトの名無しさん
04/05/07 13:24
見た感じXMLっぽいがそれなら
price="¥500"
と書くことで曖昧さがなくなる
642:デフォルトの名無しさん
04/05/07 13:33
>>640
Shift_JISは問題ないの?
643:デフォルトの名無しさん
04/05/07 16:13
>>641
xml 的には後半の \ は ¥ にするや否や、というような話。スレ違いだけど。
>>640
元のコードが Shift_JIS の場合、どんな風に変換されるべき？
644:デフォルトの名無しさん
04/05/07 16:56
>>643
後半はしたら駄目に決まってる
645:デフォルトの名無しさん
04/05/08 04:06
ところがShift JISで書いた場合は、両方でOKなわけだ。
646:デフォルトの名無しさん
04/05/08 04:07
両方HALFWIDTH YEN SIGNでOKなわけだ。
647:デフォルトの名無しさん
04/05/08 09:10
>>645
意味がわからん
「両方」って何と何のことで何が「OK」なの?
>>646
HALFWIDTH YEN SIGNなんてものはない
ただのYEN SIGNならある
648:デフォルトの名無しさん
04/05/09 05:04
LightConeは?
649:デフォルトの名無しさん
04/05/09 20:00
>>648
LightCone乙
650:デフォルトの名無しさん
04/05/18 10:46
書き込みがないな。
またLightConeが来てくれないかな。
651:デフォルトの名無しさん
04/05/18 18:31
iso-8859-22って、いわゆるなに？
iso-8859-1って、いわゆるLatin1でいいの？
652:デフォルトの名無しさん
04/05/19 02:37
8859-22 なんてあったのか？
16までなら聞いたことがあるが。
653:デフォルトの名無しさん
04/05/20 19:14
EZ端末からPOST形式でフォームをサブミットすると
x-up-destcharset=17
というのが勝手に送られるのですが、
これって何のためのものでしょうか？
654:デフォルトの名無しさん
04/05/20 19:20
で、それがなんの関係があると？
655:デフォルトの名無しさん
04/05/20 19:23
>>654
誤爆?
656:デフォルトの名無しさん
04/05/20 19:24
>>655
残念。ちゃんとした回答。
657:デフォルトの名無しさん
04/05/20 19:48
>>656
>>653への回答か? スレ違いだと言いたいのか?
658:デフォルトの名無しさん
04/05/21 18:41
>>220 さんのページってどこですか？
659:デフォルトの名無しさん
04/05/21 18:58
EUC補助漢字の判定 でぐぐってみたらわかりました。
使える文字コード判定ってあんまり情報ないので助かります
660:デフォルトの名無しさん
04/05/22 01:41
>>399
UCS4で正規化すりゃ万事解決。
32ビットコードはMuleとかで先例もあるし。
661:デフォルトの名無しさん
04/05/22 02:12
wcschrでヒットしたその位置は何文字目? という問いに
簡単に答えられない点が問題。X0208の範囲に限定するなら
そうでもないがそれならそもそも4バイトもいらん
正規化がUnicode Normalizationのことを指してるなら
UTF-8の文字数を先頭から数えても大して変わらんような…
662:デフォルトの名無しさん
04/05/22 09:25
>>660
遅レス乙!
663:デフォルトの名無しさん
04/05/22 21:37
>>660
コードポイントと文字は１対１対応ではない。
NFCで正規化しても複数コードポイントの組合せで
１文字を表すケースはいくらでもある。
664:デフォルトの名無しさん
04/05/22 22:37
たしかに↓とか読んでると気が遠くなってくるな。
URLﾘﾝｸ(www.horagai.com)
アラビア語や上の例みたいに文字を分かち書きしない言語では
「一文字」っていう単位がそもそもそれほど明確じゃないのかも。
日本語は「単語」を分かち書きしないけど
時枝文法とか文法のとらえ方次第で「単語」も変わるしそもそも
日本人は単語の区切りなんてふだん意識してないみたいな感じか。
（助詞とか）
素人なので間抜けな事いってるかも知れないが。
665:デフォルトの名無しさん
04/05/22 23:31
>>663
というかそれはまさに>>399で言ってることそのものなわけで
文盲にマジレスしても無駄かと
666:デフォルトの名無しさん
04/05/24 02:59
ｐｃ関係詳しい方！
ぜひこの暗号解けないものでしょうか！？
325argf493rdtr521styh075artg625agfa113ller041fsre.2122ffj7343qer7813fda
667:デフォルトの名無しさん
04/05/24 08:55
それをこのスレにもってくる神経を疑う
668:デフォルトの名無しさん
04/05/24 09:33
>>667
その謎を解くのだ。
669:デフォルトの名無しさん
04/05/24 10:45
>>666
↓↓US-ASCII復号による解読結果です↓↓
325argf493rdtr521styh075artg625agfa113ller041fsre.2122ffj7343qer7813fda
670:デフォルトの名無しさん
04/06/04 22:06
325|argf
493|rdtr
521|styh
075|artg
625|agfa
113|ller
041|fsre
.
2122|ffj
7343|qer
7813|fda
671:デフォルトの名無しさん
04/06/07 11:25
BASE64?
672:デフォルトの名無しさん
04/06/09 06:26
英大文字をまったく含まないというのは
BASE64にしては不自然すぎるな
673:デフォルトの名無しさん
04/07/06 12:32
JISを元にした文字コードとunicodeとの変換表が複数ある状況は
なんとかならんのかね。それが正しかろうがなんだろうがとにかく
統一されてさえいれば楽に使えるのに、バラバラだからいらぬ変換
の手間がかかってわけわからん状況に。勘弁してくれよう。
674:デフォルトの名無しさん
04/07/06 13:31
なんともならんでしょうね。
675:デフォルトの名無しさん
04/07/08 04:21
JISは対応が存在するだけまだマシなほうですよ
Big5やKPS9566なんてそもそも変換できない場合があるし
676:デフォルトの名無しさん
04/07/08 11:52
まあ、応用によって変換表が違うのは当然って文字の組み合わせもあるでしょう。
*→＊,×, ※など。あまりいい例じゃないからもっといいのきぼん↓
677:デフォルトの名無しさん
04/07/08 16:43
printf("値段は \\%dです\n", Nedan);
\\は¥(¥)1文字に変換されるのが理想だし、\nはバックスラッシュとnに変換してくれないと困るし。
678:デフォルトの名無しさん
04/07/08 16:49
もう、面倒だから\記号使うのやめよう。
printf("値段は %d円です\n", Nedan);
で良いじゃないか。
ごたごたに巻き込まれたくないPGより。
679:デフォルトの名無しさん
04/07/08 21:18
￥ でいいよ
680:デフォルトの名無しさん
04/07/28 08:02
age
681:デフォルトの名無しさん
04/07/28 08:33
>>679
I/Oライブラリに勝手に\に変換されたり…
最近2chでも~→～があるみたいだし。
682:デフォルトの名無しさん
04/07/28 09:10
文字のことは中国人に任せときゃいいんだよ
漢字のほんの一部を借りて使ってるだけの日本人なんかに何が出来るんだ
683:デフォルトの名無しさん
04/07/28 13:46
>>682
マッカーサーに従って、日本語で文章を書くのを止める、とか？
684:デフォルトの名無しさん
04/07/28 22:02
>>682
アルファベットも中国人任せか?
685:デフォルトの名無しさん
04/07/28 22:38
>>681
~→～はSafariの悪戯だろ
686:デフォルトの名無しさん
04/10/02 21:36:08
SJIS、EUC、JIS、UTF-8を判別するアルゴリズムを紹介しているページってどっかある？
URLﾘﾝｸ(kasumi.sakura.ne.jp)
を参考にしているんだけどイマイチはっきりしないところがあるので…
687:デフォルトの名無しさん
04/10/03 00:31:32
イマイチはっきりしないところを書いてくれないとはっきりしない。
688:デフォルトの名無しさん
04/10/04 04:34:15
age
689:デフォルトの名無しさん
04/10/04 13:53:50
ｸﾞｸﾞﾙさんのキャッシュは日本語サイトの \ を＼にするから激しく困る(`Д´)
ｸﾞｸﾞﾙさんのﾃﾞｶﾁﾝｺ！ヽ(｀Д´)ノ世界最早男！
690:686
04/10/05 02:18:46
遅レスｽﾏｿ
>>687
具体的には判定箇所が具体的に書かれていないところ
例：
> 0x80 <-> 0xA0であるならばSJIS
SJISと言うことは第1バイトか？
> 0xA1 <-> 0xDFが出た場合はSJIS半角カナ・EUC全角かな・カナの強い可能性
これも第1バイト？
> 0xA1 <-> 0xFEの場合はEUCの強い可能性で0xFD・0xFEの場合はEUC(確定)
第1バイトと第2バイトの両方？
691:デフォルトの名無しさん
04/10/05 02:22:48
文字コード判別・変換クラスてのがあるけど
URLﾘﾝｸ(kasumi.sakura.ne.jp)
692:デフォルトの名無しさん
04/10/05 08:14:19
>>689
これいいなあ。でもどうせなら＼ではなく、逆に全角(じゃなくてU+00A5でもい
いが)の￥にするのが正しいと思う……それはさておき。
日本語圏、とりわけShift_JIS(とMSKK的Unicode)では
\ (0x5c) が文字として意味をなさない
(コードポイントとしての機能しかない) から、仕方ないとも言えるんだよ。
Shift_JISでは0x5cはYEN SIGNという定義なんだけど、実際の使われ方は
REVERSE SOLIDUS (ASCIIでの0x5c)でもあるという状態なんだから。
EUC-JPはShift_JISと違って0x5cがREVERSE SOLIDUSなんで、EUC-JPなページの
キャッシュでは0x5cは0x5cのままになってるよ。
ああなった理由を考察すると、クロールしたデータをキャッシュとして保存する
ときはUTF-8に変換するが0x5cは0x5cのまま通してしまった。一方、キャッシュ
を出力するときはShift_JISに変換するのだが、このときShift_JISでは0x5cが
YEN SIGNであってREVERSE SOLIDUSではないので、0x5c(REVERSE SOLIDUS)は仕方
ないから＼になる、ということではないかな。
不整合に見えるけど、単に時間差があるだけでしばらく待ってると保存時にも変
換されたものでデータが入れ替わって揃うのかも。それでもページが更新されな
いとキャッシュデータが書き換わらない可能性はあるが。
693:デフォルトの名無しさん
04/10/05 08:50:29
Perl6だとYEN SIGN(U+00A5)に演算子として意味を割り当てるので、
扱いとしては完全にREVERSE SOLIDUSと別にせざるを得ないらしいじゃん。
日本語Windowsユーザはどうするのか。
本当はUnicodeに移行してればこんなことで悩まなくなってるはずなんだが、
問題解決に絞るべき知恵のなかったMSKKが
「0x5cは見掛けYEN SIGN、意味は場合によって世界標準Unicodeにおける
U+005C(REVERSE SOLIDUS)かYEN SIGN」
なんつー考えナシUnicodeを始めてしまったもんだから、
21世紀になっても悩みがつきないわけだなあこれが。
694:デフォルトの名無しさん
04/10/05 13:11:27
そこでUnicodeの再設計ですよ
695:デフォルトの名無しさん
04/10/05 13:30:33
>>693
MS の CP932 では EUC-JP と同様に 0x5C は Unicode の \u005C にマッピングされてるわけで、
MS 的には CP932 <-> Unicode の相互変換で違う文字になるなんてことは無いはず。
Shift_JIS なんてやめて、CP932 に移行すべき。
しかしC# の XMLWriter で CP932 で書き出すと、encoding="Shift_JIS" になる orz...
696:デフォルトの名無しさん
04/10/05 14:26:23
0x5cは、全員バックスラッシュにすれば済む話じゃん。
￥マークは全角で使用して、半角の￥は存在しないと思えば良い。
それよりも、日本語Windowsで0x5cをバックスラッシュで表示してくれないのが困る。
697:デフォルトの名無しさん
04/10/05 14:58:38
勉強になりそうなので読んでいますが、
CP932? REVERSE SOLIDUS?…(´･ω･｀) もうついていけません…。
たとえばWindows環境では、フォントによって\がバックスラッシュで
表示されたり \のままだったりしますが、これというのはつまり
フォントごとに、その文字コードに対応する文字イメージが
異なっているというだけなんでしょうか。それともハードウェアの
レベルで何かが起こっているんでしょうか。
文字コードと、実際に画面に表示される文字イメージが
どこでどう関連づけられているのか、いまひとつ分かりません。
698:デフォルトの名無しさん
04/10/05 15:13:26
>>697
文字イメージが違うだけ。0x5cは0x5cのまま何も変わっていない。
フォントを書き換えれば、バックスラッシュにできるんだが、改造はしたくない。
マイクロソフトが強制的にバックスラッシュにしてくれればありがたいのだが。
699:デフォルトの名無しさん
04/10/05 15:45:15
>>697
Shift_JISの0x20～0x7FはASCIIに似てASCIIじゃない文字セット(JIS X 0201)だというのが混乱の原因。
0xA5はASCIIではREVERSE SOLIDUS(バックスラッシュ)なんだけど、JIS X 0201ではYEN SIGN。
で、「\」この文字をUnicodeに変換するとき、Shift_JISはYEN SIGNに割り当てるのに、
cp932(Shift_JISをMSが拡張したもの)ではREVERSE SOLIDUSに割り当てる。
MS的には、Unicodeに変換したときにパス区切り文字が使えなくなると困るから
こうせざるを得なかったようだ。JIS X 0201がASCIIから変更した箇所と、
MSがパス区切り文字に使っていた文字が重なってしまった不幸な偶然を恨むしかない。
700:デフォルトの名無しさん
04/10/05 16:20:55
まあそれでも「～」あたりの混乱よりはマシだな。
701:697
04/10/05 16:31:42
>>698-699
なるほど、だんだん分かってきました。
もう少し分からないんですが、たとえばマルチバイトモードから
Unicodeモードに切り替えてコンパイル・実行したとすると、
文字コード自体は変わってしまっても見た目は(概ね?)同じ
ですよね。
同じフォントから同じ文字イメージを取り出すには、この
文字コードの違いを吸収する仕組みが必要だと思うのですが、
どのようになっているのでしょうか。
文字セットごとに「文字イメージ位置検索テーブル」のような
ものが用意されていて、文字コードからフォント内の文字イメージ
位置を検索できるようになっているのではと想像してみたのですが
実際のところはどうなっているのでしょうか。
702:デフォルトの名無しさん
04/10/05 16:39:23
>>701
最近のGUIベースのOSだと、フォントセットは大抵 Unicode でのコードポイントにたいして
タイプフェイスが割り当てられています。そうして文字コードから Unicode のコードポイントに
変換する仕組みも別途存在します。「どのようになっている」かは、OSやウィンドウシステムに
よって異なります。
703:697
04/10/05 17:02:28
>>702
なるほど、フォント内の文字の並びが何に従っているのか次に
質問しようと思っていたところなんですが、Unicode に合わせて
あるんですね。その上で、文字コードをUnicode の文字コードに
変換する仕組みが備わっている(仕組みは環境ごとに異なる)という
ことなんですね。納得致しました。
ご回答ありがとうございました。
704:デフォルトの名無しさん
04/10/05 18:05:15
>>703
欧文フォントなんかだと、Unicode ではなく ISO 8859-1 (Latin-1) で入ってたりするものもある。
705:686
04/10/05 23:45:34
>>691
できました。thx
サンプルコードあったのか…気が付かなかった…il||li ○|￣|＿
706:デフォルトの名無しさん
04/10/06 01:12:14
>>697
URLﾘﾝｸ(euc.jp)読めばあ?
707:697
04/10/06 17:50:44
>>704
Unicode とは並び方の異なるものもあるんですね。そのような
フォントの場合はどう扱っているのでしょう。Unicode のコード
ポイントに変換する方法では上手くいきませんよね…。使用する
フォントがどんな文字セットのコードポイントに一致しているか
という情報も、どこからか取り出しているのでしょうか。
>>706
ありがとうございます。
記号の読み方などバッチリ出てますね^^;
内容的にはまだよく分からない部分もありますが、
とりあえず最後まで読みすすめてみようと思います。
708:706
04/10/06 22:47:40
>>707
そんな難しいことは書いてないです。
良く書けているページなので何回も読んでみてください。
先入観を取り払えば、理解できるはずです。
ちなみに>>698は間違っているのでスルーしてください。
文字実体、グリフという概念を理解してない。
709:デフォルトの名無しさん
04/10/08 11:07:24
JIS X201はもはや業界のお荷物でしかない
710:デフォルトの名無しさん
04/10/08 11:45:03
和文フォントはWinの文字コード表でみると円記号の上に
ツールチップで"REVERSE SOLIDUS"と出るのが激しく間抜けだ。
せめてREVERSE SOLIDUSのグリフをどこかに突っ込んでおいてくれよう。
711:デフォルトの名無しさん
04/10/08 12:17:57
JIS X 0208的には1区32点(＼)がREVERSE SOLIDUSなんだけど、またもやMSが(略
712:デフォルトの名無しさん
04/10/08 12:32:42
>>711
Microsoft のは CodePage 932 っていう、彼らの定義したコーディングシステムなわけで、
文句言うのはよいけど「JISと違うやん」ってのは文句にすらなってないような･･･
日本のコンピュータ言語関連の書籍でも、ソースコードのREVERSE SOLIDUSを \ で
印字してるものが結構あるよね。あれってどういう習慣から来ているんだろう・・・
713:デフォルトの名無しさん
04/10/08 13:21:16
PC-9801
714:デフォルトの名無しさん
04/10/08 15:04:37
>>712
X0201の影響じゃ？てかISO/IEC646だかであのあたりは国毎に勝手にしる！ってのが未だに尾を引いてるだけかと。
715:デフォルトの名無しさん
04/10/09 14:58:11
>>712
> 日本のコンピュータ言語関連の書籍でも、ソースコードのREVERSE SOLIDUSを \ で
> 印字してるものが結構あるよね。あれってどういう習慣から来ているんだろう・・・
凄い文章だな。
716:デフォルトの名無しさん
04/10/12 18:04:57
>>712
でもさー、JISとCP932って相互変換できるのに、対応する文字が
それぞれ別のunicodeへマッピングされるのってすごい使いにくい
んだよね。なんとかしてくれよ...
717:デフォルトの名無しさん
04/10/12 19:26:18
>>712
そう思うんならMS明朝の0x5cのグリフが円記号なのは納得いかん。
718:デフォルトの名無しさん
04/10/14 00:32:17
ISO-2022-JPとEUC-jpとShift JIS(JISに載ってるやつ)とCP932は含む文字の集合が違うのに、
たいていの人はそれらの間で1対1の変換が出来ると思っている。
また、文字コード変換{ライブラリ, プログラム}もそうであるように見せかけている。この辺が混乱の元だろう。
「危ない文字(コード)は使わない」ということをリテラシーとして教えるべきだ。
719:デフォルトの名無しさん
04/10/14 02:48:47
「危ない文字(コード)は使わない」ってことなら
危ない文字(コード)を表にでもして教えてよ。（出来れば理由も）
あとお勧めの変換ソフトがあるなら教えて！
720:デフォルトの名無しさん
04/10/14 02:56:32
その環境で、何の文字コードを使うかは何処で決定されるのでしょうか？
windos環境とunix環境のそれぞれの決定のされかたを簡単でいいんで教えてください。
721:デフォルトの名無しさん
04/10/14 02:57:41
man locale
722:デフォルトの名無しさん
04/10/14 04:28:43
>>719
論外:
・いわゆる環境依存文字(丸付き数字など)
・JIS X 0201 片仮名(いわゆる半角カタカナ)
・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う
避けた方が無難:
・JIS X 0208でASCIIと同じ名前のもの(いわゆる全角英数記号類。疑問符とか)
・和字間隔(いわゆる全角スペース)
・JIS X 0208のYEN SIGN(漢字の「円」を使う)
723:デフォルトの名無しさん
04/10/14 11:24:06
>>722
しかしunicodeはさむと従来は何の問題もなく同じだった「～」なんかも
違う文字になっちゃうからな～。
724:デフォルトの名無しさん
04/10/15 03:39:30
ちょっと話題からずれてしまうかもしれませんが
teknap URLﾘﾝｸ(masternap.org) で
UTF-8 のファイル名を Shift-JIS に変換して共有したいのですが
ソースコードへのパッチの当て方が分かるかたいませんか。
725:デフォルトの名無しさん
04/10/16 15:00:13
age
726:デフォルトの名無しさん
04/10/17 03:19:24
age
727:デフォルトの名無しさん
04/10/18 20:31:59
関係ないけど、WindowsがJIS X 2013:2004に完全対応すると言われている2006年以降に
JIS X 2013:2004に完全対応したISO-2022-JP-3
（あるいは、ISO-2022-JP-3-StrictやISO-2022-JP-3-Compatible）って
メールの文字コードの主流になるのでしょうか？
一足飛びにUTF-7に移行するような気もしないでもないのですが、
メールソフトが間違えて（あるいは対応していなくて）ISO-2022-JPでデコードしてしまうと
ひどいことになってしまうのですが…
P.S.
>>722によると、この文章で使っている、いわゆる全角丸括弧や全角疑問符も
いけないことになってしまいますね。
いわゆる半角丸括弧や半角疑問符は幅が詰まりすぎているから使いたくないんですけどね。
728:デフォルトの名無しさん
04/10/18 20:57:15
何度も書くようだけど、このままWindowsにJIS X 0213:2004が採用されたら、
辻さんや樋口さんや榊原さんの大半が困ってしまう事態が起きるということは
もっと世間に認知されていてもよいと思うんですけどね。
「字体が変わる」のは防げないにしても（防げるに越したことはないが）、
「以前の字体が（事実上）出せない」のは固有名詞にも配慮していないので、
固有名詞にも対応すべきである工業規格としてまずいと思います。（※1）
（※1）この点で、「現に地名・人名などの固有名詞に用いられている字体にまで
及ぶものでもない」としている表外漢字字体表とは軌を異にします。
なお、表外漢字字体表では「現に」と表記しているとおり、表外漢字字体表発表以降の
地名・人名は表外漢字字体表に従うことを要望している（そして、実際に表外漢字字体表に
沿う形で人名用漢字が追加された）のですが、なんと市町村合併で最近誕生した
「葛城市」（奈良県）と「薩摩川内市」（鹿児島県）はそれに従っていません
（官報に記載された「葛」と「薩」の字体が、表外漢字字体表の印刷標準字体と異なっている）。
幸い、1面1区から1面13区までの間に40字弱の保留領域（ただし非漢字領域ですが）が
ありますので、ここに「互換用漢字」としてJIS X 0208:1997の例示字体どおりの
「辻」「樋」「榊」などを追加するのもよいでしょう。あと、「葛」「薩」もですね。
できればJIS X 0208:1997の例示字体ではなく、JIS X 0213:2004で変更されたほうの字体
（つまり、表外漢字字体表の印刷標準字体）のほうを「互換用漢字」にしたいのですが、
再々変更は避けたいので、いかんともしがたいところです。
729:デフォルトの名無しさん
04/10/18 21:12:49
>>727
詰まりすぎでないフォントを使えばいいのでは?
730:デフォルトの名無しさん
04/10/18 23:15:56
もうリッチな環境なんだからUTF-32で
CJKとか使えなすぎ
731:デフォルトの名無しさん
04/10/19 00:01:36
>>727
> 一足飛びにUTF-7に移行するような気もしないでもないのですが、
ぷっ
+MHcwYw-
732:デフォルトの名無しさん
04/10/19 00:36:12
>>694
そんなことしたら新旧混在して混乱に拍車を掛けますがな
733:デフォルトの名無しさん
04/10/19 00:42:00
>・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う
えーとすみません
煽りじゃ無しにこの一文の意味が本気で分かりません
734:デフォルトの名無しさん
04/10/19 04:01:43
>>727
確か UTF-7 は過渡期の産物で、MIME を併用した UTF-8 が本命じゃなかったけ？
735:デフォルトの名無しさん
04/10/19 07:52:39
主にメールのために考えられたはずだけど、
現実的にはUTF-8 + base64が多いな。無用の長物だな。
736:デフォルトの名無しさん
04/10/19 08:15:06
>>712
JIS C (JIS X 3010)に円記号を使っていいと書いてる
737:デフォルトの名無しさん
04/10/19 09:49:47
>>728
ケチケチせずに半角カナの領域削ればいい。
どうせWindowsは採用する気ないんだから
ISO/IEC 10646への追加要求のソースになってくれさえすれば
誰も実装しなくても問題はない
738:デフォルトの名無しさん
04/10/19 19:23:16
>>727
> 1段落目
なりません。
> P.S.
これについては >>729 の人が書いている通り。
>>733
値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。
739:デフォルトの名無しさん
04/10/19 19:44:51
そもそもJIS X 2013:2004に完全対応なら符号化表現の名称は
ISO-2022-JP-2004でなくてはならんし。
これはIANAに登録されていないのでメールで使ってはならない。
740:デフォルトの名無しさん
04/10/19 19:45:32
コピペしたら間違いまでコピペしてしまったorz
JIS X 0213:2004ね
741:デフォルトの名無しさん
04/10/19 23:54:35
>>722
>・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う
>>733
> えーとすみません
> 煽りじゃ無しにこの一文の意味が本気で分かりません
>>738
> 値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。
「JIS X 0201のREVERSE SOLIDUS」？？？
「CP932で(略)REVERSE SOLIDUS」？？？
742:デフォルトの名無しさん
04/10/20 01:48:46
>>741
後者。
743:デフォルトの名無しさん
04/10/20 10:03:35
・CP932で0x5cを円記号として扱う
って事ですか?
744:デフォルトの名無しさん
04/10/20 14:36:42
>>743
そうです。
745:デフォルトの名無しさん
04/10/22 03:57:53
> 値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。
ひどい目にあったところが実際にあるんでしょうか？
国内のインターネット通販やってる所って遭遇する可能性が．．．
746:デフォルトの名無しさん
04/10/22 09:57:55
Googleの検索結果上ではよく文字化けしてる
747:デフォルトの名無しさん
04/10/22 11:53:40
>>745
「ウリの環境だとウォンと書いてるニダ、それ以上は払わないニダ」
748:デフォルトの名無しさん
04/10/22 13:21:17
韓国語版WindowsのU+005CにはWON SIGNのグリフが入ってるから
円記号問題と似たようなことが起こるらしいな
749:デフォルトの名無しさん
04/10/22 13:40:26
>>747
日本側が中小だと実際にそれでごねて契約の十分の一しか支払われなかった
ケースもあるらしい。
750:デフォルトの名無しさん
04/10/22 16:05:33
>>749
嘘つきは泥棒の始まりか
751:デフォルトの名無しさん
04/10/25 17:55:53
>>728
「市町村合併 字体」とかでぐぐると分かるけど
>当用漢字表以外の漢字についても、当用漢字字体表の字体に準じた
>字体を用いてもよい。
みたいですね。この時点ですでに表外漢字字体表とは
食い違っているという…
752:デフォルトの名無しさん
04/10/25 18:42:21
>>751
字体表は答申どまりで内閣告示にならなかったからな。
朝日新聞とかにも無視されてるし（内閣告示だったら無視できなかったはず）。
字体表を尊重しているのなんて、
国語審議会のメンバーを送り込まれたJIS X 0213:2004だけじゃねえか。
753:デフォルトの名無しさん
04/10/25 19:15:06
人名用漢字部会も。
「芦」はなぜか簡易慣用字体のほうが採用されたけど。
754:デフォルトの名無しさん
04/10/28 06:53:30
ひょろっと書いた自作のユニコードライブラリを
鬼門・合成に対応させようか迷っとります。
コンパクトな構造が崩れる悪寒。そこまでサポートする意味あるのか…。
欧米人の心境が１㍉㍑くらいわかったような気分す。
755:デフォルトの名無しさん
04/10/28 12:29:56
>>754
ISO 10646-1は全てのシステムが合字処理を実装することを要求
していないよ。実装レベル分けされていて、合字のない実装は
Level-1に分類される。
756:デフォルトの名無しさん
04/11/10 22:17:25
ここで質問して良いのか分かりませんが、
Unicodeでのエスケープシーケンス一覧はどこかにありますか？
757:デフォルトの名無しさん
04/11/10 22:55:38
Unicodeはエスケープシーケンスなんか使いませんが
758:デフォルトの名無しさん
04/11/11 00:48:03
単にunicodeの一覧の話か？
759:デフォルトの名無しさん
04/11/11 05:43:47
UTF-8 指示用の「ESC % G (1B 25 47)」というのが規定されてはいる。
X の Compound Text で使われているようだ。
760:デフォルトの名無しさん
04/11/11 05:54:20
とりあえずここにまとめられてるのでぜんぶだとおもう。
URLﾘﾝｸ(www.itscj.ipsj.or.jp)
URLﾘﾝｸ(www.itscj.ipsj.or.jp)
761:デフォルトの名無しさん
04/11/11 10:09:30
JIS/SJIS/EUCから変換されたunicodeテキストがあります。
ただし変換表がどれか(MS系かJIS系かとか)わかりません。
これを適当に自動判別して元のJIS/SJIS/EUCに戻せるような
ライブラリってないですかね? perlのモジュールになってる
と楽なんですけど。
762:デフォルトの名無しさん
04/11/11 23:15:20
JIS(っていうかISO-2022-JPだよね？)だったのか、EUC-JPだったのか、
あるいはShift_JISだったのか、を判別したいんですか？ だったら無理。
変換表がどっちなのかを判別したいんですか？
だったらそれなりに可能だろうけど、既存のライブラリはたぶんない。
わりと簡単に作れるので、勉強だと思ってガンバレ。
763:デフォルトの名無しさん
04/11/12 10:03:30
>>762
変換表をどっちか判別したいだけです。紛らわしい書き方ですまん。
同じ変換表で変換されたものの元がJISかEUCかを判定したいわけでは
もちろんありません(全く同じ結果になるからできるわけないし(笑))。
で、既存のライブラリはなさげですか。どっちかの変換でしか現れない
文字に着目して判定できるとは思うのですが、きちんと漏れなく調べる
のが面倒なのであればいいなと期待していたのですが。
764:デフォルトの名無しさん
04/11/12 12:26:15
「XML日本語プロファイル」がいちおう既存の変換表を網羅しているはず
だから(Apple除く)それを参考にして作れ
765:デフォルトの名無しさん
04/11/22 16:15:28
766:デフォルトの名無しさん
04/11/25 12:18:47
質問いいですか
OS Windows2000 Japanese version(韓国語言語インストール済み)
開発言語 VB6.0
テキストファイルを読み込んでその内容をテキストボックスに出力させるプログラムをつくったのですが
文字化けしてしまいます。
テキストファイルには、韓国語と日本語がはいっています。
テキストファイルはUnicode形式で保存しています。
これをバイナリ－データとして開いてそれぞれ変数に代入して
テキストボックスに出力しています。
Unicode形式なのに韓国語が文字化けしてしまうのです。
どうしてでしょうか？
767:デフォルトの名無しさん
04/11/25 12:38:52
代入しているコードを貼らずに質問とな。
768:デフォルトの名無しさん
04/11/25 12:47:40
>>766
Textbox自体がUNICODEの表示に対応していないから。
WebBrowserコントロールにでも出せばいい
769:デフォルトの名無しさん
04/11/25 14:39:51
Private Sub Command1_Click()
Dim lngFileNum As Long
Dim strText As String
lngFileNum = FreeFile
Open "d:\VB\test.dat" For Input As #lngFileNum
Input #lngFileNum, strText
Label1.Caption = strText
Close #lngFileNum
End Sub
コードをかかずにすみませんでした。
テキストボックスではなくてラベルボックスでした
unicode形式のテキストファイルを読みこんで出力するだけなのですが
どうしても文字化けしてしまいます。
770:デフォルトの名無しさん
04/11/25 14:53:40
VBスレへどぞー、って感じだな。
771:デフォルトの名無しさん
04/11/26 05:24:45
>>768の通りなんだけどな。
VBの中はUnicodeだけど、外から見える部分は勝手にAnsiてかShift_JISにしちゃうんよ。
コントロールしかり。
772:デフォルトの名無しさん
04/11/26 07:40:18
>>768
>>771
そうだったのですか！ありがとうございます。
Private Sub Command1_Click()
Dim lngFileNum As Long
Dim strText As String
lngFileNum = FreeFile
Open "d:\VB\test.dat" For Input As #lngFileNum
→Input #lngFileNum, strText
Label1.Caption = strText
Close #lngFileNum
End Sub
ですが、上の→の行でファイルを読みこんで変数に代入するときに
文字化けしたものが代入されているのですが、これは内部処理ではないのでしょうか？
773:デフォルトの名無しさん
04/11/26 11:42:44
>>772
Input 文が、勝手に「ファイルの中身はShift_JISだ」と仮定して変換しちゃってるんだと思う。
VB スレで訊いてみて。
774:デフォルトの名無しさん
04/11/26 12:04:22
だったら日本語も表示されないでそ
と思ったら、「日本語は化けない」とは言っていないのか。
775:デフォルトの名無しさん
04/11/26 12:14:45
ありがとうございます。VBスレで聞いてみます。
長々すみませんでした。あ、日本語は化けてません。
776:謎！
04/11/26 17:38:46
02 - \202\307\202\361\202\310\202\306\202\253\202\340\201B.mp3
この文字列を読める日本語に変換するにはどういう解釈をすればいいでしょうか。
\はバックスラッシュです。
元となっているエンコーディングが分かりませんし
数値も256を超えるのがあったりしてシングルバイトの文字列でもないようです。
よろしくおねがいします。
777:デフォルトの名無しさん
04/11/26 18:16:40
>>776
「どんなときも。」であってるよな…
だったら、\の後は8進数だよ。文字コードはSJIS。
778:謎！
04/11/26 18:44:41
>>777
8進数！謎が解けました。どうもありがとうございます。
779:謎！
04/11/26 20:38:23
付け加えて、>>776のフォーマット（書式？）の名前は一般的には何と呼ばれていますか？
Googleで検索して調べようにもキーワードがわかりません、、、
780:デフォルトの名無しさん
04/11/26 21:07:51
単に、表示側の対処法の違いだけだと思うけど
781:デフォルトの名無しさん
04/11/26 22:09:18
>>779
Cの規格書的には、octal escape sequenceだな。
JIS翻訳版なら8進逆斜線表記。
782:デフォルトの名無しさん
04/11/26 22:14:15
ナル文字としてよく使う'\0'も実はその8進表記。
783:デフォルトの名無しさん
04/11/26 22:25:57
てか、普通に 0 ってかくと字句解析的には8進表記とみなされるんじゃなかったっけ？
784:デフォルトの名無しさん
04/11/26 23:11:18
その通り。
785:デフォルトの名無しさん
04/11/27 00:38:12
その通りだが、0が8進数なのと、\0が8進エスケープシーケンスなのとは、
次元がまったく違うので、Cの規格書を読んで、Cスレにでも行け
786:デフォルトの名無しさん
04/11/27 10:22:28
質問なのですが、
Windows2000のコントロールパネルの項目にある「地域のオプション」についてなのですが、
韓国語のソフトをインストールして使用したいので、システムロケールを韓国語にしたのですが、
ユーザーロケールも韓国にしないといけないのでしょうか？
ユーザーロケールは通貨や単位の表記法の設定と書いてあるのですが、
やはりシステムロケールとユーザーロケールが食い違うとうまく表示してくれないのでしょうか？
787:デフォルトの名無しさん
04/11/27 12:03:18
とりあえずユーザーロケールはそのままでも動くんじゃないか？
駄目みたいだったらユーザーロケールも変えてみれば良いじゃないか。
788:デフォルトの名無しさん
04/11/27 16:35:39
>>786
板違い
789:謎！
04/11/27 23:32:55
>>781さん、どうもありがとうございました。おかげさまで必要な情報も検索で得られました。
790:デフォルトの名無しさん
04/12/08 02:19:26
BMP内のUnicode Standard 4.0の文字ができるだけたくさん表示できるtrue typeフォントを教えてください。
Arialの穴が多少なりとも埋まるとありがたいのですが。
791:デフォルトの名無しさん
04/12/08 02:52:36
Code2000とかはどうなんだろ
792:デフォルトの名無しさん
04/12/09 21:23:51
インド語とか、ただ文字が入ってるだけだとUnicode Standardの文字表を
表示する役にしか立たんぞ
793:デフォルトの名無しさん
04/12/14 03:41:39
>>791 >>792
レスが遅れましたが、ありがとうございます。
今から入れてみます。
794:デフォルトの名無しさん
04/12/17 05:10:50
MTで使用するのにEUC－JPかUTF-８って
結局どっちがお勧めだと思いますか？
795:デフォルトの名無しさん
04/12/17 10:59:20
「MT」とは何か
796:デフォルトの名無しさん
04/12/17 11:06:57
たぶんメルセンヌツイスターかマルチスレッドと思われる。
EUC-JPやUTF-8との絡みがよく分からんが、きっとこのあと説明してくれるのだろう。
まかり間違ってもGoogleで調べればすぐ分かるような、Movable Typeのことではあるまい。
797:デフォルトの名無しさん
04/12/17 12:29:51
はあ？
マニュアルトランスミッションのことに決まってるじゃん
798:デフォルトの名無しさん
04/12/17 14:30:37
Magnetic TapeじゃなかったのかYO
799:デフォルトの名無しさん
04/12/17 14:58:41
その調べればすぐわかるMovable Typeのこと
でも文字コードの設定を変えるのは簡単だけど、
結局世の中使ってる奴がバラバラで統一されて無いもんだからこまるのさ
でもって、みんなはどっちを選択してんのかなって思ったわけ
ちなみに自分は最近EUCからUTFへ変えてみた
800:デフォルトの名無しさん
04/12/17 17:25:24
Movable Type なら専用スレで聞いた方が早くね？
801:デフォルトの名無しさん
04/12/17 18:52:27
ここが２ちゃんでよかったな
802:796
04/12/17 20:57:06
>>799
UTF-8を選ぶでしょ。
Googleで調べてみれば、多くの人がそっちへ乗り換えてるはず。
それにUTF-8なら、Windowsでもきちんとバックスラッシュが表示されるし(どうでもいい?)。
でも俺はUnicodeは嫌いだから、あえてEUC-JPを使いたい。
803:デフォルトの名無しさん
04/12/18 01:34:15
>>802
794=799 そうなんだよね
実は俺も同じような考えで、時代の流れには従うしかないか
ってわけでUTF-8に乗り換えたんだけど
やっぱUnicodeっていまいち好きじゃあないんだよね
796のような発言でちゃらかす人は、そういうすぐに検索かかるほど
一般的なもので使用可能な統一文字コードを開発＆普及さして欲しいもんですな
気長に待ってますよ
804:デフォルトの名無しさん
04/12/18 01:37:21
■関連サイト(ノード)
┣ URLﾘﾝｸ(rightp2p.s68.xrea.com)
┣ URLﾘﾝｸ(www.stereoz.net)
┗ URLﾘﾝｸ(moejump.s6.x-beat.com)
■関連サイト(本体・BBS・その他)
┣ URLﾘﾝｸ(rightp2p.s68.xrea.com)
┣ URLﾘﾝｸ(phphp.s58.xrea.com)
┣ URLﾘﾝｸ(www.stereoz.net)
┣ URLﾘﾝｸ(printf.jugem.jp)
┗ URLﾘﾝｸ(www.ero8.com)
805:796
04/12/18 01:42:54
>>803
おいおい、ちゃらかすって...。
プログラム板で「MT」って書いたから、一番可能性の高い物を出してやったのに。 :)
まず聞く場所が違う、MTで通じるわけがない(エスパー募集中?)、「Unicodeが好きじゃない」なんて
前提が書いてない、いろいろ問題がありすぎるんだよ。
君はねえ、ISO-2022を使いなさい。あれが今のところベスト。
806:デフォルトの名無しさん
04/12/18 01:48:37
関連スレでも出てたけど、
URLﾘﾝｸ(www.unicode.org)
なんか笑えるね。
807:デフォルトの名無しさん
04/12/18 02:35:30
>>806
関連スレってどこ?
しかし、Unicodeもぼろぼろだな。GB18030で中国は離反するしな。
あれはなかなかうまかった。さすが計略に長けた中国。
808:デフォルトの名無しさん
04/12/18 07:56:22
そんなに簡単にバレるものは計略とは言わない
809:デフォルトの名無しさん
04/12/19 19:07:18
GB18030の採用に関する解釈が正反対なのが笑える
URLﾘﾝｸ(www2.xml.gr.jp)
810:デフォルトの名無しさん
04/12/19 19:22:06
>>809
GB18030なんて一言も出てきてないぞ。
だいたいこれ、2000年6月の話だし。
811:デフォルトの名無しさん
04/12/20 15:05:56
日本語については既存の文字コードとの変換を一意に
決められずに乱立を許した時点でunicodeは失敗したと
思うね。
812:デフォルトの名無しさん
04/12/20 15:14:09
MSとAppleとSunとJISCが話し合って変換テーブルを統一するなんて
現実的にあり得そうもないことをしなくちゃならなかったんだから、
失敗は必然だったとか言ってみる。
813:デフォルトの名無しさん
04/12/20 16:33:12
unicodeが失敗って、どこの世界の住民？
unicode以上に国際的な文字コードってなに？
814:デフォルトの名無しさん
04/12/20 16:45:30
TRONコードにきまってるだろ
815:デフォルトの名無しさん
04/12/20 20:15:00
>>813
> unicode以上に国際的な文字コードってなに？
ISO-2022。
でも現実としては、今のところUnicode。
> unicodeが失敗って、どこの世界の住民？
あきらかに失敗だよ。作りが悪すぎる。それでも使わざるをえない。
すぐ分かるのはUTF-16のサロゲートペア。他にもたくさんあるよー。
816:デフォルトの名無しさん
04/12/20 21:39:18
一文書中にアラビア語と韓国語を交えた日本語とかを書くには
Unicodeは便利です。
817:デフォルトの名無しさん
04/12/20 23:10:21
>>815
それはUTF-16の問題であってUNICODEの問題ではないでしょ。
UCS-4的にはまとまってるわけで。
どっちかというと言語タグとかの方が問題だとは思うが・・・
ISO-2022が理想かというと激しく疑問だし。
TRONコード? 窓から捨てちゃってよ。
実際マルチランゲージ対応しようとするとUNICODEが無難だとは思うがなぁ。
UNICODE <-> ISO-2022 とか UNICODE <-> EUC を考えると
頭が痛くなるのは同意するけどね。