トップページ⇒tech
1001コメント343KB

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

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさんNGNG
文字コード変換について語りましょう♪
0002.NET Messenger ServiceNGNG
お使いの Messenger は、今すぐセキュリティ アップデートが必要です。http://messenger.msn.co.jp/Help/Upgrades.aspx に移動して、アップグレードしてください。
0003デフォルトの名無しさんNGNG
MSゴシックからTerminalへの変換アツゴリズムを教えて下さい。
0004デフォルトの名無しさんNGNG
VC6環境でエディットボックス等から取得した文字列をUTF-8に変換するシンプルな方法教えて
0005デフォルトの名無しさんNGNG
単発質問の為にスレ立てるな
0006デフォルトの名無しさんNGNG
UTF-8からPOP3に変換する方法を教えて
0007デフォルトの名無しさんNGNG
かろやかに市ね
0008デフォルトの名無しさんNGNG
何語れって？
しかもUTF-8⇔SJIS限定かよ！
0009デフォルトの名無しさんNGNG
WideCharToMultiByte
0010デフォルトの名無しさんNGNG
MultiByteToWideChar
0011デフォルトの名無しさんNGNG
良スレのヨカン。
0012デフォルトの名無しさんNGNG
UTF-8⇔SJISに限定せんほうがいいな
0013デフォルトの名無しさんNGNG
そういえば、UTF-16は全然普及しないな。
0014デフォルトの名無しさんNGNG
UltraTinkoFlash
SuperJapneseIiSio
0015デフォルトの名無しさんNGNG
てか、普通の変換はもうすでにプログラミングしているので
どうせなら、機種依存文字とかやってみない？

例えば
①は、0Xad0xa1(euc_jp) 0xe20x910xa0(utf8)
0016デフォルトの名無しさんNGNG
定番のレスですまないが、まず「機種依存文字」という用語の、皆が納得できる定義から頼む。
0017デフォルトの名無しさんNGNG
じゃあたとえば、機種依存文字の場合
テーブル自作するとしよう
上の例だと

EUC_JPのファイルをバイト単位で読み込んだとき
AD　A1っていうのがあれば、　UTF-8に変換する場合　E2 91 A0に書き換えればいいって事になる
こういう辞書を作ればいいのか？
こんな具合に
EUC_JP、ISO-2022-JP、MS932、Shift_JIS、UTF-8の辞書テーブル作れば解決だよな
0018デフォルトの名無しさんNGNG
>>16
たとえばi-mode文字とか
0019デフォルトの名無しさんNGNG
UNICODEへのマッピングが未定義の文字をUNICODEにマッピングしようという話か？
0020デフォルトの名無しさんNGNG
>>18
つまり標準規格化されてないベンダ独自定義の文字？
それだと「①」とかは当てはまらないし、他のコードに変換もできそうにないけど。
0021デフォルトの名無しさんNGNG
まあ詳しい話は俺は知らないんだが
たとえばJavaなんかでも簡単に文字コード指定してやれば
どんな文字コードのファイルも任意の文字コードのファイルとして変換できる。
ただ、普通に使う文字とかは漢字（一部例外）だろうと記号だろうと大体OKなんだけど
マッピングが割り当てられてない文字は？ってなるだろ。
そういうのを、正しく修正するようなテーブルをつくればいいのではないかと思ってな。

明らかにそのコードに存在しない文字はしょうがないけど
0022デフォルトの名無しさんNGNG
>21
ヴァカですか？
0023デフォルトの名無しさんNGNG
つーか、JIS系(ISO-20022-JP, Shift_JIS, EUC-JP, ...)とUnicode系（UTF-8, UCS-2, ...)
の変換は機種依存文字でなくても変換表使うしかないわけだが。
0024　NGNG
>>13
UCS16 はかなり使われてるのにね。
0025●のテストカキコ中NGNG
http://ula2ch.muvc.net/　(このカキコは削除しても良いです)
0026デフォルトの名無しさんNGNG
>>23
その変換表をプログラムから使えるようにしようって事でないの？
0027デフォルトの名無しさんNGNG
>>16
機種依存文字とは
『日本において技術者が喜んで実装し、
　営業がユーザを囲い込むために喜んで利用する
　ちょっとだけ見た目のいい文字集合セットの名称』
0028デフォルトの名無しさんNGNG
http://apex.wind.co.jp/tetsuro/izonmoji/

たとえば、Macintosh文字の機種依存文字として
丸付き数字や「cm」「↑↓」などがある。(「」内が一文字)
0029デフォルトの名無しさんNGNG
>>28 【機種依存文字】特定機種にのみ存在する文字のこと

この定義じゃ不充分だし。英語版のOSじゃ日本語全滅ですよ？
0030デフォルトの名無しさんNGNG
「機種依存文字」なんて存在しないことがわからないのはなんでだろう。
0031デフォルトの名無しさんNGNG
>>30
別にそんな細かいこといいじゃん　ネタすれなのにマジになるなよ
0032デフォルトの名無しさんNGNG
来いよ
0033デフォルトの名無しさんNGNG
Unicode はクソ。
0034デフォルトの名無しさんNGNG
クソじゃない文字コードって何よ？
0035デフォルトの名無しさんNGNG
7bit ascii
0036デフォルトの名無しさんNGNG
Unicodeの功績:
文字コードを1つ増やしてプログラマの雇用を創出したこと
Unicodeの罪:
文字コードを1つ増やして右翼・左翼の声を大きくしたこと
0037デフォルトの名無しさんNGNG
7bit ascii はクソ、アラビア文字が表現できない。
0038デフォルトの名無しさんNGNG
UTF-16のメリットをひとつ述べよ
0039デフォルトの名無しさんNGNG
>>38
固定長



……あ、でもサロゲートペアが…………
0040デフォルトの名無しさんNGNG
>>38
中途半端で実用的
0041デフォルトの名無しさんNGNG
サロゲートを使わないと表現できない文字を使ってるのは人間じゃないから
サロゲートの事なんか考えなくてもいいんだって学校の先生がいってたよ
0042デフォルトの名無しさんNGNG
>>39
固定長なのはUCS2。
0043デフォルトの名無しさんNGNG
>>37
ま、7 bit ascii が今の文字コード問題の元凶だという意味では激しくクソだな。

- はハイフンなのかマイナスなのか
(いまは「ハイフンマイナス」だっつーことになった。何だよそれは)

~ はチルダなのかオーバーラインなのか
(規格に tilde or overline とか書くなよ…)

" の左右くらい区別しろ

...
0044デフォルトの名無しさんNGNG
>>43
昔はそんなもの厳密に区別しなくても困らなかったんだよ。
それよりリソースの制限のほうが深刻だった。
で、それらを「包摂分離」したことによって非互換が発生した
0045デフォルトの名無しさんNGNG
タイプライタなんて l と 1、 O と O を包摂していた。
0046デフォルトの名無しさんNGNG
>>41
クリンゴン人ですね
0047デフォルトの名無しさんNGNG
>>46
残念ながらクリンゴン語は却下されてUnicodeに含まれてないはずだよ
0048デフォルトの名無しさんNGNG
>47
>46のメール欄
004947NGNG
ぐは。やられた。
0050デフォルトの名無しさんNGNG
ﾌﾟｯ
0051デフォルトの名無しさんNGNG
初心者ですがよろしいでしょうか？
Java上でSJIS→UNICODE→SJISと変換をかけると、
115区～119区は「?」になってしまうようなんですが、
仕方がないんでしょうか？

実際にUNICODEで割り当てられている文字もあります。
例えば人名の「高」のはしごタイプのやつです。これは
118区にあり、SJISではFBFC、Unicodeでは9AD9です。

IBM特殊文字なのはわかりますが、コードが存在するのに
エンコードしてくれないのは何故でしょうか？
0052デフォルトの名無しさんNGNG
>>51
Windows-31J エンコーディングを使用したか?
0053デフォルトの名無しさんNGNG
>>52
使ってるのはShift_JISです。
Windows-31JってMS932のことでしたっけ？　試してみます。
0054デフォルトの名無しさんNGNG
必読ページ
http://www.ingrid.org/java/i18n/encoding/
0055デフォルトの名無しさんNGNG
>>53
Windows-31Jでやってみました。が、ダメでした。

しかしおかげさまで問題を切り分けることができました。
どうやら途中に使っているJDBCドライバの問題っぽいです。
そっち方面検証してみます。お騒がせしました。
0056デフォルトの名無しさんNGNG
データベースがEUCだったりするとたいがいうまくいかないね。
SJIS => UNICODE -> EUC -> UNICODE => SJIS
途中で、変換できないコードが混じっちゃう。

最近は、データベースの文字コードはできるだけUNICODEにしている。
それができないときは、SJIS。
JavaのWebアプリの場合だけど。
0057デフォルトの名無しさんNGNG
データーベースがUnicodeじゃないとIEのsize属性での長さチェックと
うまくかみ合わなかったり
どのみちサーバ側でチェックをする必要はあるんだけどなんか嫌
0058デフォルトの名無しさんNGNG
ICU使ってます？
0059デフォルトの名無しさんNGNG
使ってます
0060デフォルトの名無しさんNGNG
日本語でUnicodeならUTF-8よりUCS-2そのままのほうがかえって
メモリ消費少なくなったしせえへん？CJK共用漢字コード領域に
UTF-8の3バイト文字あったっけ？
0061デフォルトの名無しさんNGNG
>>60
たしかにUTF-8だと漢字や記号の一部、半角カナ類は全部3バイトだね。
でも、日本語だけならいいんだけど、ASCII文字も扱いたい場合は
UCS-2の16ビット表現はASCII部分の文字も2バイトになっちゃうからねぇ。
0062デフォルトの名無しさんNGNG
>>13
XMLの標準がUTF-8でさらに、
欧米人は本当はIS-8859-1しか使う気がなく
Unicode使ってもせいぜいUTF-8しか使わんのでしょう。
欧米系以外の外国人も英語を標準言語としており、
プログラミングなどの才には変数名などは英字のほうがわかりやすく
扱いやすくASCIIコードで事足りる記号が多いので、
無理してUTF-16を使う気を起こす人が少ないのでしょう。

まさに自分もこれに当てはまります。
0063デフォルトの名無しさんNGNG
>>62
> 欧米人は本当はIS-8859-1しか使う気がなく

そんだったら、WinもMacもUnicodeサポートしてないんじゃないの？
逆に、超漢字は、BMPしかサポートしてないというお粗末感がある。
ちなみに、Unicode Consortiumは、アメリカにあるよ。

ISO-8859-1はヨーロッパじゃあもう使いたくないでしょう。
Euroが入ってないと。
0064デフォルトの名無しさんNGNG
最近じゃ代わりに ISO-8859-15 を使うとかどうとか。＜euro
プログラム言語では内部コードが UTF-16 てのも珍しくないけど。
0065デフォルトの名無しさんNGNG
ICUのDLLがでかすぎるのだがUnicodeと日本語関係の文字コードに限定したサブセット版って誰かビルドして配布してくれてたりしないのかなあ
0066デフォルトの名無しさんNGNG
>>65
集中治療室？
0067デフォルトの名無しさんNGNG
>>63
非英語圏は英語圏産のソフトウェアの輸出先だからね。
日本が輸入最大手。
0068デフォルトの名無しさんNGNG
UTF-8って内部処理には最悪なんだって。
文字列の末尾から先頭に向かって文字を検索できないだろ。
UNIX系のgccでは標準ライブラリは一文字四バイト固定のwchar_tだし、
MSVCは二バイト固定のwchar_tなんだよね。
0069デフォルトの名無しさんNGNG
可変長なものが内部処理には向かないのはあたりまえ。
0070デフォルトの名無しさんNGNG
>>68
wchar_tはワイド文字なんだからutf-8でないのは当然なので、
wchar_tがutf-8でないことはutf-8を否定する理由にならない。

あと、末尾から先頭に向かって検索しづらい(できないわけじゃない)のは
utf-8に限った話ではない上、あるシステムが文字列を末尾から検索する
必要があるとも限らないし、それ以外のメリットとデメリットも色々ある。

もっと勉強して出直してきて。
0071デフォルトの名無しさんNGNG
コード順でソートすると一部言語が混ざるのが不味い
0072デフォルトの名無しさんNGNG
>>68
> 文字列の末尾から先頭に向かって文字を検索できないだろ。
ﾊｧ? そりゃシフトJISやEUCの話だ。
どこのバカにそんなデタラメ吹き込まれた?
>>70
UTF-8は単なるバイト列として末尾からでも検索できるはずだが。
0073デフォルトの名無しさんNGNG
>>72
>>70はできないとは書いてないけど？
可変長だから末尾から「文字として」検索するのはちょっとややこしめ、という程度の意味で書いた。
0074デフォルトの名無しさんNGNG
>>73
UTF-8のエンコード方式を理解してないだろ？
0075デフォルトの名無しさんNGNG
> 「文字として」検索する
必要がないのがUTF-8の特長なんだが。
どーでもいーけどこの程度の初歩的な知識もないくせに
知ったかぶってUnicode叩く奴大杉
0076デフォルトの名無しさんNGNG
まあUnicodeはクソだし。
0077デフォルトの名無しさんNGNG
で、そういう奴に限って何がどう糞なのか説明しない。
たまに説明したかと思ったら>>68みたいな単なる嘘だったりするし。
0078デフォルトの名無しさんNGNG
16ビットにおさめようと思って作っていた時点で糞です。
糞に何をかぶせようと糞にかわりはありません。
0079デフォルトの名無しさんNGNG
それじゃあたった8,836文字に収めようとしたJIS X 0208や
シフトJISの都合だけで11,280文字に詰め込もうとしたJIS X 0213なんて
話になりませんね。やはり時代はちょー漢字ですか?
0080デフォルトの名無しさんNGNG
Unicodeも糞だがJISも糞だ。
それを弁えて何とかするのがエンジニアだろ?
糞だ何だと言い訳する暇あったら調べるなり
なんなり、もっと悪足掻きしろよ。
0081デフォルトの名無しさんNGNG
で、悪あがきした結果がちょー感じ？
0082デフォルトの名無しさんNGNG
むしろ悪あがきした結果はExtension BやOpenTypeの字形切り換えや
language tagやvariation selectorではないかい

漏れが理解できないのは、いくらUnicodeが糞でもシフトJISよりは
マシだと思ってるんだが(理由は>>72や>>79)なんでシフトJISから
移行するだけでもあんなに拒否反応示す奴が多いの? ってあたり。
そいつが超漢字に移行しようっていうならまだ話も分かるんだが。
0083デフォルトの名無しさんNGNG
今まで使っていた物が使えないから。
0084デフォルトの名無しさんNGNG
捨てませう。
0085デフォルトの名無しさんNGNG
大昔のことで忘れたが、UTF-8って、
ビットテストすれば何バイト目が分かる仕様じゃなかったっけ？
0086デフォルトの名無しさんNGNG
・１オクテット文字か
・マルチオクテット文字の先頭オクテットか
・マルチオクテット文字の後続オクテットか

が分かる。
マルチオクテット文字の何オクテット目かは、先頭かどうか以外は分からない。
0087デフォルトの名無しさんNGNG
先頭オクテットに関しては
・何オクテット文字の先頭か
もわかるはず。
00-7F 1オクテット文字
80-BF 後続オクテット
C2-DF 2オクテット文字の先頭
E0-EF 3オクテット文字の先頭
F0-F7 4オクテット文字の先頭
※C0-C1とF5-FDはRFC3629で使用禁止になった
0088デフォルトの名無しさんNGNG
さんきぅ
単位はオクテットの方がよかったね(これまた大昔に指摘されたことだな)
ま、どっちにしてもシリアライズ向きか
Perlのutf8って、どのくらい使えるんだろう
0089デフォルトの名無しさんNGNG
>>88
http://hyam.dip.jp/hiroshi/comp/perl/perl58.htm
> foreach $name ( < * > )
> でファイル名やディレクトリ名の "機能"を拾えない。

が5.8.1でも直ってないのでまだJPerlの置き換えはできまへん
0090デフォルトの名無しさんNGNG
UNICODE 良く判らん・・・。UCS がキャラクタセットで、UTF がエンコーディング
なんだよね? UCS もキャラクタコードを持ってるという点ではエンコーディングと
考えてもいいの? 実際、Java や CLISP は内部的には UCS-2 で文字列を保持している
みたいだし。サロゲートペアとか考えなくてよくなるから、内部エンコーディングに
向いているのでしょうか?
UTF-8 が多いのは ASCII が使えれば十分な人が多いから?

各言語／ライブラリの内部エンコーディング／string のエンコーディング
Python: UTF-8?
Java: UCS-2/UTF-8
Tcl: UTF-8
Cocoa(Mac OS X): UTF-16
CLISP: UCS-2
Gauche: compile option dependent
Qt: UTF-8
Mule: has it's own encoding
XML: UTF-8 or UTF-16

自分で多言語対応文字列処理ライブラリを作る時は、UCS-2 を使うのが良いのでしょうか?
0091デフォルトの名無しさんNGNG
とりあえずPythonはUCS-2だとだけ言っておく。
0092デフォルトの名無しさんNGNG
thanx!
やっぱり固定長が便利って事だよね。
0093デフォルトの名無しさんNGNG
std::basic_string<wchar_t>
linux-gcc:glibc(UCS4)/mingw32-gcc:msvcrt(UCS2)
ワイドキャラクタは、テンプレートを使えば
ロジックはそのままで型の導出の定義を替えて再コンパイルのみ。
インターフェースが変わるだけで上流工程に影響しない。
マルチバイトはロジックにパッチを当てなきゃならんので
論理のチェックもやり直し。
0094デフォルトの名無しさんNGNG
ttp://homepage1.nifty.com/nomenclator/unicode/
0095デフォルトの名無しさんNGNG
>UTF-8 が多いのは ASCII が使えれば十分な人が多いから?

USC2は情報量が足りないからサロゲートせなあかん、面倒
UCS4は無駄が多い
なによりUCSはstrcmpレベルから書き直さんとあかんよ
0096デフォルトの名無しさんNGNG
JIS X 0213はUCSだと固定長ではすまないわけだが
(サロゲートを無視しても合成もある)
0097デフォルトの名無しさんNGNG
>なによりUCSはstrcmpレベルから書き直さんとあかんよ
そんな必要ない。
// char *m = itoa<char, int>(100)
// char *w = itoa<wchar_t, long>(1234L)
template <typename C, typename I>
std::basic_string<C> itoa(I v, int radix = 10, bool caps = false) {
std::basic_string<C> buff;
C ch;
C af = (caps ? 'A' : 'a');
do {
ch = C(v % I(radix));
ch = ((ch > 9) ? (ch - C(10) + af) : (ch + C('0')));
buff += ch;
v /= I(radix);
} while (v);
std::reverse(buff.begin(), buff.end());
return buff;
}
0098デフォルトの名無しさんNGNG
>97
型が混じってるぞ。
I r = v % I(radix);
C ch = (r >= I(10))? (af + (r - I(10)) : (C('0') + r);
ってところか。
0099デフォルトの名無しさんNGNG
>>97
その調子で今まで作られた文字列処理関数すべてを書き換えてみて。
0100デフォルトの名無しさんNGNG
>>99
つーか、作るまでも無く実はSTL+BOOSTなら大抵あるだろ。
boost::format(L"%5.3f:%3d") % 12.3 % 123
漏れも公開するかな。UCSはラクチンだよ。
0101デフォルトの名無しさんNGNG
ところで内部コードがUTF-8って何かまずいことあるん？
UCS-2でも(OSによっては)出力する時点で変換しないとならないし
大して利便性は変わらないと思うんだが。

表現方法がいくつもあるほうが逆にやりづらいというかサポートするのが面倒。

0102デフォルトの名無しさんNGNG
>>101
内部はUCSでいいじゃん。すでにJavaもVBもそうなってて不都合無いだろ。
C++も標準で困らないようになってる。
わざわざ検索処理とかCのランタイム書き直すの？
0103デフォルトの名無しさんNGNG
>>102
UTF-16だろ
0104デフォルトの名無しさんNGNG
jis x 0212 って「捨て」なんですか?
0105デフォルトの名無しさんNGNG
>>96
結局、固定長で多言語を扱うというのは現実的には難しいのか。。。
0106デフォルトの名無しさんNGNG
>104
Unicodeの中に生き残ってるでしょ。
0107デフォルトの名無しさんNGNG
超超超 超漢字！
超超超超 超漢字！
0108デフォルトの名無しさんNGNG
.NET Framework的には、文字列stringはUTF-16だから、
次世代Longhornもこれに統一されるんじゃないの？
てことは、数年後にはUTF-16が事実上の標準になると。
0109デフォルトの名無しさんNGNG
文字コート関連のスレが他に無いので、ここで質問しても宜しいでしょうか?

    http://euc.jp/i18n/charcode.ja.html#chap5

上記 URL で、EUC-JP を ISO-2022 に割り当てる説明が書いてありますが、
G0 - G3 に各符合化文字集合を指示している部分は実際に何か行われている
のでしょうか。
EUC-JP はエスケープシーケンスを使わないという事ですので、エスケープ
シーケンスを使用した指示はしていないと思うのですが。
0110デフォルトの名無しさんNGNG
>>109
> 上記 URL で、EUC-JP を ISO-2022 に割り当てる説明が書いてありますが、
EUC は ISO 2022 に準拠してるとしか書いてないような…

> G0 - G3 に各符合化文字集合を指示している部分は実際に何か行われている
> のでしょうか。
定数なので普通は何もしない。

既存の ISO-2022-JP の処理系があるなら ** を指示ってのにしたがって
G0 ～ G3,GL,GR を設定すれば EUC の処理系が作れるってだけ。
(SS2 と SS3 の処理は追加しなきゃいかんかったっけ？)
0111デフォルトの名無しさんNGNG
>>109
EUC-JPは designate を省略しているが、invokeは省略しない。

ISO2022 designate invoke でググって見たら。
0112111NGNG
つうか、 ttp://euc.jp/i18n/charcode.ja.html#chap5 にちゃんと書いてあるじゃん。

指示(designate)は省略する。(あらかじめ指示してあると約束する)

EUC-JPを使うと言う取り決めは、G0,G1,G2,G3に
それぞれJIS X0201ローマ字,JIS X0208, JIS X0201カタカナ, JIS X0212を指示するという
取り決めとなるわけ。
(ただし、GOがASCIIなのかJIS X0201ローマ字なのかにはゆれがある。)

当然、呼び出し(invoke)は行う。
0113デフォルトの名無しさんNGNG
G0にJIS X 0201ローマ字を指示するEUCってあったっけ?
(実装の解釈が変というのは除いて)
JIS X 0208本体のラテン文字・漢字用8ビット符号がいちおう該当するか。
これはG2もG3も使わないけど
0114デフォルトの名無しさんNGNG
>>113
ttp://www.opengroup.or.jp/jvc/cde/euc.html
0115デフォルトの名無しさんNGNG
>>114
見事なまでにバラバラだな
0116デフォルトの名無しさんNGNG
>>110-112
レスどうもありがとうございます。
4.7 の所に省略すると書いてあるのに気付きませんでした。済みません。
エディタを作りたかったのですが、やっと ISO 2022 が理解出来ました。
どうもありがとうございました。
0117デフォルトの名無しさんNGNG
初歩的な質問ですが
EUC を SJIS に変換まではできたのですが、
この変換できた EUC のデータを
printf() 関数を使ってコンソールに出力したいので

CString szEUC;
szEUC = ....
printf( "%d\n", szEUC );

とやってみましたが うまくいきません。
EUCコードを 文字化けせずにコンソールに出力するには
何か設定が必要なのでしょうか？
0118デフォルトの名無しさんNGNG
エスパー募集ですか？
0119デフォルトの名無しさんNGNG
CString って MFCだよねぇ。
_MBCSと_UNICODEのどっちが定義されているかで入っているもの違うけど。
どっちにせよ、 CStringをそのままprintfで出力するのは反則だし。

_tprintf("%s\n", LPCTSTR(szEUC));

MFCスレで聞けば？
0120117NGNG
printf( "%d\n" szBuf ); → %s

また やってしもうたか・・・＿|￣|○
設定って、#define とかのことでした すんまそん
0121デフォルトの名無しさんNGNG
SJISしか受け付けないコンソールにEUC出力すれば、
そりゃ文字化けするわなぁ。
0122デフォルトの名無しさんNGNG
EUC-TWってSS2の後にA2～B0を付けてPlaneを識別している
みたいですけどこういうのってISO 2022的にアリなんですか?
0123122NGNG
94^3集合と考えればいちおうアリですね。
問題はISO-IRには別々の94^2集合しか登録されていないことですが。
0124デフォルトの名無しさんNGNG
内部コード UTF-8 は XML がらみのライブラリを使うときとかに多用するけど、
逆に OS 側やら他のライブラリは UTF-8 なんてこと殆どないんで、
かなりの場面でコード変換が必要になるなぁ。。
0125デフォルトの名無しさんNGNG
UCS-2って文字集合のことですよね。
UTF-16はUCS-2の符号化方式の一種ですよね。
ところで、GNUのlibiconvっていうライブラリに符号化方式としてUSC-2が使えるんだけど、
これって何か特別な使い方があるのかな。ダンプしてみたらUTF-16BEと全く同じなんですよね。
0126デフォルトの名無しさんNGNG
> UTF-16はUCS-2の符号化方式の一種ですよね。
違うと思う(前者は後者にない補助面の文字が存在してるから)
0127デフォルトの名無しさんNGNG
UCS-2の文字番号をそのまま使う符号化方式もUCS-2と呼んでるんだろう、きっと。
BMP外の文字を使わなきゃUTF-16BEと同じになるのは道理。

UTF-16類とは、サロゲートとBOM位しか違わないんでない？
0128デフォルトの名無しさんNGNG
UCS2は基本的に内部表現用なのでBE/LEどちらでもUCS2。
完全に実行環境に依存してる。
0129デフォルトの名無しさんNGNG
iconv使うと実行ファイル+数メガの.so/.dllをくっつけないといかんので困る。
0130デフォルトの名無しさんNGNG
SJIS←→UCSの変換なんてOSの変換表は
まるで信用できないからなあ
0131125NGNG
Thanks > 126-128
符号化方式としてのUCS-2ってのは使わない方がいいみたいですね。

さらに、UTF-16に関して質問なんですけど、私の認識では、UTF-16系の扱いは以下のようになってます。
・UTF-16 ＝ BOMを見てlittle endianかbig endianか判断せよ。
・UTF-16BE ＝ big endianに決まっている。
・UTF-16LE ＝ little endianに決まっている。

つまり、UTF-16はBOMがあるもので、BOMがない場合はUTF-16BEかUTF-16LEと明示的に
指定すべきものだと思っています。でもたまに「BOMなしUTF-16」とか「BOM付きUTF-16BE」
のような記述をWebサイトやアプリケーションに見受けます。
私の認識は間違ってます？
0132デフォルトの名無しさんNGNG
十数年前はチーズバーガーが１個２３０円だった。
それが、ついこの間まで１個８８円で売っていた。
これはつまり、その気になれば１個８８円で売れたモノを２３０円で売ってた訳だ。
その昔に１個２３０円で食ってたオレに言わせれば全く腹の立つ話だ。
0133デフォルトの名無しさんNGNG
じゃあたった10MBかそこらのメモリが億単位の値段だったなんて
もう詐欺みたいなものですね
とかコピペにマジレスしてみるテスト
0134デフォルトの名無しさんNGNG
>>131
好むと好まざるとに関らず、UTF-8 以外は使われなくなってくから
グズグズとそんなこと考えんで宜しい。
１０年後に UTF-16 なんて使ったら洟で笑われるぞ。
0135デフォルトの名無しさんNGNG
10年後には UTF-8 すらなくなっていますが。
0136デフォルトの名無しさんNGNG
Asciiコードは無くなるかなあ？
0137デフォルトの名無しさんNGNG
>>136
欧州市場はやっぱり無視できないから、新規の実装では使われなくなると思う。
0138デフォルトの名無しさんNGNG
UTF-8という名のASCII
0139デフォルトの名無しさんNGNG
UTF-8 って合成を考えると、一文字が最大 12 オクテットになるの??
0140デフォルトの名無しさんNGNG
>>139 21
0141デフォルトの名無しさんNGNG
どういう計算をして12オクテットになったのか謎ですが
3文字以上の合成だってあります。
0142デフォルトの名無しさんNGNG
合成で気になったんだが、合成の組み合わせと数に制限はあるのか？

例えば、U+306C U+0308 とか、U+0276 U+0328 U+0336 U+030F U+0360 とかは
Unicode文字として規格上正しいもんなのか……？
# 直感的には、明らかに正しくないことはわかってるのだが。
0143デフォルトの名無しさんNGNG
>>142
JIS X 0221の規格票をざっと眺めた感じでは、制限無しの模様。
0144デフォルトの名無しさんNGNG
>>142
残念ながらダイアクリティカルマークの
スタック(積み重ね)という概念は実在する
http://dl2.yukoncollege.yk.ca/ynlc/ynlcfonts/stacking/stacking.html
0145デフォルトの名無しさんNGNG
>>144
そこのページ雪だるまがいぱーいあって季節的にGood!
0146デフォルトの名無しさんNGNG
>好むと好まざるとに関らず、UTF-8 以外は使われなくなってくから
ISO C++ではワイドキャラクタはサポートされてますが、
マルチバイトがしっかり動く環境ではありません。
UCS-4マンセー。UCS-4でいいじゃん。
0147デフォルトの名無しさんNGNG
だったらこの文字ユニファイして領域節約してくれよ
U・C・S!! U・C・S!!
0148デフォルトの名無しさんNGNG
>>146
とりあえず、意味不明
0149デフォルトの名無しさんNGNG
正直utf-16でいい
0150デフォルトの名無しさんNGNG
正直utf-16のよさがわからない
0151デフォルトの名無しさんNGNG
WinXP用ならUTF-16もいいが
他の環境を考えると
0152デフォルトの名無しさんNGNG
UCS4だよ。一文字32ビット固定でいいやんけ。
0153デフォルトの名無しさんNGNG
合成があるってば
0154デフォルトの名無しさんNGNG
漢字圏の人間はついついUCS-4で全部解決と
思ってしまうんだよなあ。
0155デフォルトの名無しさんNGNG
その典型が昔のTRONですね
http://www.horagai.com/www/den/kanken.htm#04
最近のバージョンでは解決してるの?
0156デフォルトの名無しさんNGNG
うーん、実態はそんなに単純じゃないんだけどなあ。
TRONの関係者の中にも多言語処理の複雑さを理解している
人たちはちゃんといたよ。昔のweblogをみると多言語の問題と
取り組んで悪戦苦闘している様子がうかがえた。
合成の問題のことは頻繁に話題になっていたよ。

一応TRONでは80年代ごろから多言語処理には
4層構造(言語層、文字属、スクリプト、フォント)で対応する
ということになっていたんだけど、悲しいかな人手不足で
全然研究、ましてや実装は進まなかったんだよ。

今超漢字の販売元は組み込み向けの製品に注力していて、
超漢字にはあまり時間をかけていない様子。改善されているのも
相変わらず漢字処理が中心だよ。明るいニュースはごく最近
SUNがJavaのTRONコードへの対応を約束したことぐらいかな。
まだまだ先の道のりはながいよ。
0157デフォルトの名無しさんNGNG
> TRONの関係者の中にも多言語処理の複雑さを理解している
> 人たちはちゃんといたよ。
こんなのとか?
http://www.sumire.sakura.ne.jp/~oguma/tron/btm1999z.html#19991203

漢字がどうしても中心になるのは分からなくもないけどね
使いもしない文字のサポートが強化されたって一般受けしないばかりか
「シリア語ブラクラ」なんて汚名まで被る始末だし
0158デフォルトの名無しさんNGNG
思ったんだけど、
わざわざ全ての文字を１つの文字コードに詰め込まなくても、
JIS コードみたいに文字コードの切り替えを行うマークを導入すれば
かなりすっきりするんじゃない？
0159デフォルトの名無しさんNGNG
その切り替えタグに当たるコードは
どうすれば必要十分で、どういうルールで割り当てていく？
0160デフォルトの名無しさんNGNG
仮に一文字２バイトで固定するなら、
文字として使える領域と
切り替えタグにしか使えない領域に分割すれば
いいんじゃない？
0161あぼーんNGNG
あぼーん
0162デフォルトの名無しさんNGNG
>>158
エスケープ・シーケンス unix で検索しる。
0163デフォルトの名無しさんNGNG
>>162
Compound Text ってやつ？
なるほど、既にその手のものはあるんですな。

これで問題になることって何があるのかな？
0164デフォルトの名無しさんNGNG
>>163
まともな処理をするのがめんどうくさい。
0165デフォルトの名無しさんNGNG
そもそも、プログラミングを容易にするために（＝国際化の容易さに直結）、
シフトを追放しランダムアクセス性を付与することが、
Unicodeの重要目標だったわけで。
0166デフォルトの名無しさんNGNG
ttp://www.d2.dion.ne.jp/~kuropoo/kanban/shimbun/iwateken.jpg
↑この看板のコウの字がJIS X0208その他の文字集合に見あたらないのですが、
「工」に包摂されているんでしょうか、それとも探し方が悪いのでしょうか……？
0167デフォルトの名無しさんNGNG
>>166

MacOSX 10.3のヒラギノProに異字体として入ってるから（Stdの方には入ってないし、他のUnicodeフォントにも存在してない）文字集合としてはAdobe-ほげほげ-1.5とか以上でないと
入ってなさそうな感じですね。

印刷物に使うのはかまわないけど、インターネットとかには使えないよという警告がでますな。
0168デフォルトの名無しさんNGNG
ほうちゃんと警告が出るのか。
つーかちゃんと異体字指定の方法を標準化して
インターネットでも使えるようにしてほしいんだが
0169デフォルトの名無しさんNGNG
>>168

その辺はまだこれからの課題なんじゃないかな？
AdobeとAppleだけだもんな。今んとこ。
XにContributeされてるAdobeのフォントに日本語のが入ってくれば状況は一気に変わるのかも
知れないけど。
WinはOTFのヒラギノ購入＆インストールで対応できるのかな？
Win持ってないんで判らんのでWinの方でヒラギノ入れてるような奇特な人は試してください。
あ、でもInDesignでドキュメントが完全にコンパチブルだとか売りにしてるようだから、ちゃんと
使えるのだろうな、きっと。

0170デフォルトの名無しさんNGNG
UTF-8 から JIS X 0208 への変換テーブルってどっかない？
0171デフォルトの名無しさんNGNG
>>170
Perlかなんかで作れ。
0172デフォルトの名無しさんNGNG
>>170
ftp://unicode.org/Public/ のどっか。
0173170NGNG
UTF-8 って UNICODE を千切って可変長にねじ込んでるだけだったんだね。

http://ash.jp/ash/src/codetbl/jis0208.txt
UNICODE <-> JIS X 0208 の変換テーブルは見つかったから、これを使ってやってみるよ。
>171 >172 ありがとう
0174デフォルトの名無しさんNGNG
合成なんて、あきらめちゃっていいんじゃないの? 韓国も逃げちゃったし。
既存のコード体系でもしばしば合成を仕様に含めてるけど、まともに利用されてないしさ。
0175デフォルトの名無しさんNGNG
漢字なんて、あきらめちゃっていいんじゃないの?
既存のコード体系でもしばしば10万字もの漢字を仕様に含めてるけど(ry

というのに賛成なら別に反対しないけど。

古ハングルは合成で表すことになってるし
実際にそれを実装したフォントも存在する
デヴァーナーガリーやアラビア語のスクリプトは
重ね打ちで処理できない合成が必須
0176174NGNG
>>175
> デヴァーナーガリーやアラビア語のスクリプトは
> 重ね打ちで処理できない合成が必須

あぁ、そうなのか。そりゃ俺が浅はかだった。
0177デフォルトの名無しさんNGNG
DB(ORACLE) + JRUN(JAVA + JSP)で
日本語と韓国語を同じページ（一枚のJSP)に混在させて表示させたいのですが
文字コードの設定はどのようにしたらよろしいのでしょうか。
できればＤＢの同じカラムに日本語と韓国語を突っ込んで
DBはORACLE9iだとUTF-16でしたがUTF-8にかえてJSP側でEUC-Krにしては
日本語がばけるしshift-Jisに設定したら韓国語が化ける。
0178デフォルトの名無しさんNGNG
JSP側でUNICODE…
0179デフォルトの名無しさんNGNG
JSP側で日本語と韓国語を同時に使える文字コードを選ぶのは
ものすごく当然だと思うが何に困ってるわけ?
つーか最後の3行日本語になってない
0180デフォルトの名無しさんNGNG
> つーか最後の3行日本語になってない
韓国語を直訳でもしたんじゃないか?
0181デフォルトの名無しさんNGNG
VB.NETを使ってるんですが、
日本語文字の自動判別が出来るライブラリってありませんか？

もしくはShiftJISとeucJPを見分ける賢いやり方誰か教えて～
0182デフォルトの名無しさんNGNG
Shift_JISとeuc_jpは完全には見分けられないなあ。
0183デフォルトの名無しさんNGNG
A0 以外の Shift-JIS の半角カナが偶数個あるものは
EUC-JP と区別がつきまそん。
0184181NGNG
ありがとうございます。
半角カナが奇数個なら判別可能という事なんでしょうか？
詳しい解説キボン
0185デフォルトの名無しさんNGNG
例えば MSB の立っているバイトが奇数個だけ連続している（前後はMSBがゼロ）
場合には EUC-JP ではなさそうだな、ということはいえると思う。
0186デフォルトの名無しさんNGNG
A1～DF が２つあるやつは、
Shift-JIS の半角カナ２文字と、
EUC-JP の２バイト文字１文字と、
両方の可能性がある。
でも、奇数個なら Shift-JIS にしかなりえない。

他にも E0～FC で始まり、A1～FC で終わる文字も
Shift-JIS か EUC-JP か区別できなかったりする。
0187デフォルトの名無しさんNGNG
>>185
EUC-JPは補助漢字も考慮に入れる必要があるので、奇数個続く可能性はある。
0188デフォルトの名無しさんNGNG
文字コードだけでは区別しにくい場合でも
日本語の文章の場合、「ひらがな」が多く含まれる事が判定の一助になる場合がある。
例えばSJISだと0x81-0x83(だったか忘れたけど)が多いとか。
0189デフォルトの名無しさんNGNG
ヒューリスティックな方法だけど、いくつかのプログラム
（例えばnkfとfile(file2)とiconv）にそれぞれ判定してもらって、
多数決をとるっていうのはどーだろ？
0190デフォルトの名無しさんNGNG
UHCもGBKもEUCの上位互換になるような拡張だから
判定ミスで文字化けに悩まされてるのは日本くらいだよなあ
0191デフォルトの名無しさんNGNG
半角カナ１文字だと分かってればstrlen()一発で判別できるんだがな。
…何の役にもたたん話だが。
0192デフォルトの名無しさんNGNG
ファイル入出力をユニコードに対応させたいのですが
_wfopen()使うとWindows95シリーズを切っちゃいますよねぇ。
いっそ切っちゃおうか…、悩ましい。
0193デフォルトの名無しさんNGNG
Windowsでは、UNICODEとSJISが使われてますね。
UNICODEが多国語Winでぶつからないのは分かりますが、
SJISは多国語Winで別の国のコードとぶつかっちゃうんでしょうか？
0194デフォルトの名無しさんNGNG
>>193
ぶつからないよ。非ユニコードのマルチバイト系のAPIを使うときは
暗に陽にキャラクターセットが指定されるから、ぶつかりようが無い。
0195193NGNG
>>194
そこが凄く知りたいところです。
もっと詳しく教えて下さい。

多国語対応してますが、
Delphi/標準VCLだとASCIIしか受け入れてくれないんですが、
キャラクターセットはどこで指定されるんでしょう。
DBの中身はUTF8で画面入出力時にUTF8ToAnsi/AnsiToUtf8してますが、
画面の入出力で文字化けしたら嫌だな、と思って。
0196デフォルトの名無しさんNGNG
Windows で ANSI コードページと言った場合、おそらくは GetACP で得られる
コードページ (日本語ロケールなら CP932 のシフトJIS）への変換だと思うのですが、
これはタダの ShiftJIS ですから、JIS にある文字以外は表現できません。
こんなので答えになってるんだろうか・・・

この辺見てみては？
ttp://www.microsoft.com/globaldev/handson/dev/muiapp.mspx
0197デフォルトの名無しさんNGNG
javaではUCS-4はサポートされていないのでしょうか？
以下のソースでUnsupportedEncodingExceptionが出ました。

FileOutputStream fo = new FileOutputStream(args[0]);
String str = "A";
fo.write(str.getBytes("ISO-10646-UCS-4"));
0198デフォルトの名無しさんNGNG
java 1.4 は Unicode 3.0 だからなぁ・・・
BMP にない文字は扱えないぽ。
0199デフォルトの名無しさんNGNG
質問です。
fopenでファイルを開くときWindowsの場合、テキスト形式で開いてたら
0x1AをEOFと判断して、バイナリだと0x1AをEOFと判断しないと聞きました。
それでUnixの場合はバイナリでもテキストでも一緒とも聞いたんですが、それではUnix系はどうやってファイルの終端を確認しているんですか？
Unixのファイル終端の識別子はなんなんですか？

（なんか僕が勘違いなどしてるところがあったらズバット指摘してくれてけっこうです）
0200デフォルトの名無しさんNGNG
>>199
> （なんか僕が勘違いなどしてるところがあったらズバット指摘してくれてけっこうです）
その質問はスレ違い。
0201199NGNG
え、文字コードだからここじゃダメですか？
0202デフォルトの名無しさんNGNG
C言語の実装の詳細の話だな。
0203デフォルトの名無しさんNGNG
殆どの近代的なファイルシステムでは、「ファイルの長さ」というものがきちんと管理されているので、
適当なコードを使って終端を示す必要はありません。

一部の処理系の一部の関数において 0x1A をファイル終端としていることがあるのは、ファイル長が
128バイト単位でしか管理されていなかった CP/M という OS との互換性のためです。
0204デフォルトの名無しさんNGNG
>>203
ありがとうございます。
0205デフォルトの名無しさんNGNG
xmodemを思い出すな・・・
0206デフォルトの名無しさんNGNG
UTFとかUNICODEとか言われてもわっかんねーよ
大体おれソフト開発の際そんなこと気にしたことないしな（汗
やっぱりWeb開発者じゃないと気にしないのかな？
0207デフォルトの名無しさんNGNG
まぁアプリのジャンルや開発環境によって違うだろうね。
一生気にせずに済むのなら、それはそれで幸せだとは思う。
0208デフォルトの名無しさんNGNG
.NETとかJava開発者なら知らぬ間に使ってますよ
0209デフォルトの名無しさんNGNG
BCCで可能な限りwin32apiだけを使ってSJISをUTF8へ変換する関数がほしい…
ただしMultiByteToWideCharで直接UTF8へ変換するのはWin95では×らしいので…
0210デフォルトの名無しさんNGNG
まずUTF-16(95ならUCS-2か)に変換してからRFC3629を見てがんがる
機械的な計算だけでできるから大して難しくないよ
0211デフォルトの名無しさんNGNG
ちなみにWindows 2000でもMultiByteToWideCharでUTF-8→UTF-16は
セキュリティの問題があるので勧めない。
XPではセキュリティの問題を防ぐためにnon-shortest-formの文字を
削除するようになったとMSDNに書いてるが、削除だと別の問題が
発生するのでMB_ERR_INVALID_CHARSフラグが必要。
0212デフォルトの名無しさんNGNG
お忙しいところ失礼します。
やり方が分からないので立ち寄らせていただきました。
某板での記事からなのですが、
あるゲームのツールがヨーロッパ(たぶんITALY)で作られて、
日本語がもともと入っているデータがあって、
文字化けして表示されているんですが、
ゲーム中ではちゃんと表示されるんです。
でもそのEditorだとやはり文字化けしてしまうんです。
そこで他の方の質問からの解答で、

文字コードをS-JISからUTF-8へ変換。

とお答えになっていたのですが、
どのようにやればよいかわかりませんか？
本当にやりたいんで御願いします。

ちなみにCとか全く分かりません。
何かソフトありませんか？
OSはXPです。
0213デフォルトの名無しさんNGNG
メモ帳は UTF-8 で保存可能だ。
0214デフォルトの名無しさんNGNG
>>213
さっそくの回答ありがとうございます。
コードはどーやって変えるんでしょうか？
0215デフォルトの名無しさんNGNG
>>212
ここはそんなレベルの低い質問をするスレッドではない。

Windows XPなら、メモ帳がUTF-8に対応しているので
1, Shift JISで書かれたテキストファイルをメモ帳で開く
2, 「名前を付けて保存」のダイアログで、「文字コード」に「UTF-8」を指定
0216デフォルトの名無しさんNGNG
>>214
http://pc2.2ch.net/pcqa/
0217デフォルトの名無しさんNGNG
>>214>>215
本当にありがとうございます。
後一個だけおねがいです。
Shift JISで書くのもメモ帳ですか？
それとも何かありますか？
0218デフォルトの名無しさんNGNG
メモ帳はデフォルトで ShiftJIS だ。
0219デフォルトの名無しさんNGNG
よごしてすんませんでした。
本当助かりました、ありがとう！
0220長いと言われたので分割NGNG
遅レスだけど
もし参考になれば
>>181
自分のHPからの抜粋今のところうまくは行ってるけど・・・(C#で作ってます)
最近文字コードの勉強しだしたんで間違えてたらｽﾏｿ
あとわかりづらいとおもうけどｽﾏｿ

■1 ISO-2022-JPの判別
各ESC(0x1B～)が出た場合はISO-2022-JP(確定)

■2 UTF-8の判別
0xC0<->0xFDが出た場合はUTF-8の強い可能性
第2バイト以降が全て0x80<->0xBF内であればUTF-8の強い可能性、そうでない場合は他コード
第1バイトで指定された長さ以下の場合は他コード

■3 EUC半角の判定
第1バイトが0x8Eで第2バイトが0xA1<->0xDFな場合はEUC半角カナの可能性
ただし既に他の文字コードの強い可能性ありと判断されてない場合に限る
第2バイトがEUC半角カナ範囲外で0x80<->0xA0であるならばSJIS(確定)
以上に当てはまらない場合は不明コード
0221長いと言われたので分割2NGNG

■4 EUC補助漢字の判定
第1バイトが0x8Fで第2・3バイトが0xA1<->0xFEな場合はEUC補助漢字の強い可能性
ただし既に他の文字コードの強い可能性ありと判断されてない場合に限る
第2・3バイトどちらかが0xFD・0xFEであるならばEUC補助漢字(確定)
第2・3バイトがEUC補助漢字範囲外で0x80<->0xA0であるならばSJIS(確定)
以上に当てはまらない場合は不明コード

■5 SJISの判定
0x80<->0xA0であるならばSJIS

■6 SJIS半角カナの判定
0xA1<->0xDFが出た場合はSJIS半角カナ・EUC全角かな・カナの強い可能性
ただし既に他の文字コードの強い可能性と判断されてない場合に限る
第1バイトが0xA4か0xA5で第2バイトが[かな]0xA1<->0xF3[カナ]0xA1<->0xF6であるならば
EUC全角ひらがな・カタカナの弱い可能性
第2バイトをチェックして0xE0<->0xFEであるならばEUCの強い可能性で0xFD・0xFEの場合はEUC(確定)
第2バイトが存在しない場合はSJISの強い可能性
以上に当てはまらない場合はSJIS半角カナの強い可能性

■7 EUCの判定
0xA1<->0xFEの場合はEUCの強い可能性で0xFD・0xFEの場合はEUC(確定)
当てはまらない場合は不明コード
0222長いと言われたので分割3NGNG
[１]→ ISO-2022-JP確定
↓
[２]→UTF-8強可能性→UTF-8強可能性→次ループ(ポインタ=+UTF8サイズ)
｜　　　　　　　　　＋→他コードの強可能性→[３]へ
↓
[３]→EUC半角カナ強可能性→EUC半角カナ強可能性→次ループ(ポインタ=+1)
｜　　　　　　　　　　　　　＋→EUC半角カナ確定
｜　　　　　　　　　　　　　＋→SJIS確定
｜　　　　　　　　　　　　　＋→不明コード→次ループ(ポインタ=+1)
↓
[４]→EUC補助漢字強可能性→EUC補助漢字強可能性→次ループ(ポインタ=+1)
｜　　　　　　　　　　　　　＋→EUC補助漢字確定
｜　　　　　　　　　　　　　＋→SJIS確定
｜　　　　　　　　　　　　　＋→不明コード→次ループ(ポインタ=+1)
↓
[５]→SJIS確定
↓
[６]→SJIS半角カナ強可能性→SJIS半角カナ強可能性→次ループ(ポインタ=+1)
｜　　　　　　　　　　　　　＋→EUC全角かなカナ弱可能性→次ループ(ポインタ=+2)
｜　　　　　　　　　　　　　＋→EUC強可能性→次ループ(ポインタ=+1)
｜　　　　　　　　　　　　　＋→EUC確定
↓
[７]→EUC強可能性→次ループ(ポインタ=+1)
＋→EUC確定
↓
不明コード→次ループ(ポインタ=+1)
0223デフォルトの名無しさんNGNG
BOMは無視？
0224デフォルトの名無しさんNGNG
utf-8 → Shift_JIS （Shift_JISに無い文字はTeXのutf package用に\UTF{xxxx}）
がほしい
0225220NGNG
>>223
BOMと言うものを知らなかったので・・・
今検索してみてわかりました

UTF-8に関しては
変換するときは消したほうがよさそうですが
判別の時は特に考えなくてもいいかと
判断された文字コードをスコア化して１番多いものをその文字コードと判断してるんですが
それに対して重みをつける(通常+1を+2ぐらい)でいいかなと

そのうちUTF-16とかにも対応したいので非常に勉強になりました
ありがとうございます
0226220NGNG
とおもったらUTF-8・UTF-8Nと区別するんですね＿|￣|○

.NETのEncodingクラスには無さそうだけどためしに変換してみたら
ゴミデータが付いてきたから標準でUTF-8Nなのかなぁ
0227デフォルトの名無しさんNGNG
>>220
> 0xC0<->0xFDが出た場合はUTF-8の強い可能性
0xC0, 0xC1 が出た場合はUTF-8ではない(確定)
Unicode(U+10FFFFまで)はサポートするけどISO10646の
UCS-4(U+7FFFFFFF)はサポートしないなら0xF5-FDも除外できる
RFC2279/3629参照
0228220NGNG
>>227
RFC読みました
C0、C1がセキュリティ上禁止されていることがわかりましたので
早速条件に入れたいとおもいます

UCS-4に関してはとりあえずサポートして置きたいので入れて起きます

ありがとうございます
奥が深い・・・
0229デフォルトの名無しさんNGNG
>> 220
どこかのHPにまとまっている？
0230220NGNG
>>229
はいまとまってるとおもいますが２ｃｈで晒すほど度胸無いので・・・
最近ページ追加したばっかりでgooglebotは数回きてるんですが反映はまだ見たいです
0231デフォルトの名無しさんNGNG
予言：

　　1　0　年　後　に　は　、　U　T　F　-　6　4　が　標　準　に　な　り　ま　す　。


＿|￣|○
0232デフォルトの名無しさんNGNG
>>211
どの場合も、事前に必要バッファ長を取得してから、
バッファ長指定して呼び出せば大丈夫じゃない？
0233デフォルトの名無しさんNGNG
>>232
セキュリティの問題というのは>>227-228でもちょっと触れてるけど
たとえばディレクトリトラバーサル対策で「2E 2E」という文字列を
フィルタリングしても、「C0 AE 2E」とか書くと貫通してしまうという問題。
http://altba.com/bakera/hatomaru.aspx/glossary/0055006e00690063006f006400650020005700650062002000540072006100760065007200730061006c
あるいは「<」をnon-shortest formで送ることでXSSを発動させるとか。
http://www.cert.org/tech_tips/malicious_code_mitigation.html#3
対策としてXPではC0 AEのようなシーケンスを削除するようになった
わけだが、今度は「2E C0 AE 2E」とか書くと貫通する。
もう少しモノを考えて修正してくれMicrosoftと小一時間(ry
ただしMB_ERR_INVALID_CHARSを付けるとエラーになってくれる。
0234デフォルトの名無しさんNGNG
>>233
おお、なるほど。
勉強になります。

結局のところ、有効な対策の一つとしては、
「API側の対策をあてにせず、UTF-16 or UCS-2に変換した後に危険な文字をチェックしろ」
ってことですかね？
0235デフォルトの名無しさんNGNG
逆では?
UTF-16 or UCS-2 のままでのチェックだけではなく、
API に渡される実際の引数レベルでもチェックをするって感じ？
0236デフォルトの名無しさんNGNG
>>235
違う。
0237デフォルトの名無しさんNGNG
Shift_JISやEUC-JPやRFC1468に直接Unicode文字や補助漢字、JIS第3・第4水準の文字を
埋め込める規格を考案したけど、実用価値あるんだろうか？

Shift_JISで直接Unicode文字が使えたら機種依存文字の問題はなくなると思うんだけどね…
0238デフォルトの名無しさんNGNG
>>237
> Shift_JISやEUC-JPやRFC1468に直接Unicode文字や補助漢字、JIS第3・第4水準の文字を
> 埋め込める規格を考案したけど、実用価値あるんだろうか？

率直にいって無いだろう。でもせっかくだから言ってみたらどうだろう?
目新しいアイデアなら、ほかのところで生かせるかもしれない。
まさか制御文字の一部を使って符号化する、なんてアイデアじゃないだろうな……

それと、文字コードの話するなら
> Unicode文字
> ？
> 機種依存文字
この辺は直した方がいいよ。
0239デフォルトの名無しさんNGNG
>>237
イオさんという人が昔「拡張シフトJIS」「拡張EUC-JP」「拡張ISO-2022-JP」
とかいうの考案してましたね。サイト消えちゃったけどWayBack Machineから発掘
http://web.archive.org/web/20030211003418/www.ksky.ne.jp/~smile4me/charcode/index.htm
> Shift_JISで直接Unicode文字が使えたら機種依存文字の問題はなくなると思うんだけどね…
GBK/GB18030はGB2312と上位互換を保ったままUnicodeの文字を
全部使えますね。
Unicodeに移行しようと思ったら既存のデータを全部変換するか
捨てる必要があるシフトJISやBig5圏から見たらうらやましい限り。
0240デフォルトの名無しさんNGNG
>>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の外字」なんて怪しげな言葉を使っていますが、ご勘弁を…
0241デフォルトの名無しさんNGNG
>>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の文字コードを使用することになります。
0242デフォルトの名無しさんNGNG
・・・Unicode使うよ。。。
0243デフォルトの名無しさんNGNG
>>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互換文字のうちの漢字

説明は以上です。長文ご容赦ください。
0244デフォルトの名無しさんNGNG
1バイト部分がJIS X 0201かASCIIかによって使用禁止の区点が
変化しますがそこは曖昧なままですか?
0245デフォルトの名無しさんNGNG
>>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との互換性を考えるといいのかも。
0246デフォルトの名無しさんNGNG
> 1バイト英数字をASCIIにするのをやめてJIS X 0201にするとはっきり宣言してしまったほうが

イラネ。
0247デフォルトの名無しさんNGNG
> JIS X 0201にするとはっきり宣言してしまったほうが
それはセキュリティの問題が発生するので
すくなくともWindowsのコードページとしては採用不可能
0248デフォルトの名無しさんNGNG
すなおにUTF32使おうよ・・・
0249デフォルトの名無しさんNGNG
ということは1バイトの英数字がASCIIで、1バイトのカタカナがJIS X 0201なのが
一番いいということなのかな。

1バイトのカタカナなんて廃止してしまえ!!という強硬な意見はあると思うけど、
互換性を考えるとどうしても廃止できないと思う。
0250デフォルトの名無しさんNGNG
シフトJISの上位互換こそが特長なんだから
1バイトカナを廃止したら話にならん
互換性がなくていいならそれこそ>>248だ
0251デフォルトの名無しさんNGNG
UTF32 って何が嬉しいのでしょうか。固定長ではないのですよね?
0252デフォルトの名無しさんNGNG
BOM...かな？
0253デフォルトの名無しさんNGNG
UTF32は固定長ですがなにか？
0254デフォルトの名無しさんNGNG
合成があんだろ
0255デフォルトの名無しさんNGNG
どうせ固定長じゃないならUTF-8のほうがいい
0256デフォルトの名無しさんNGNG
utf32が固定長じゃないとかUCS4もびっくりだな
何文字使う気なんだ
0257デフォルトの名無しさんNGNG
誰か>>256を翻訳してください
0258デフォルトの名無しさんNGNG
Even UCS4 looks conventional; utf32 dosn't have the fixed size etc.
How many characters does it plan to use?
0259デフォルトの名無しさんNGNG
>>257

He said,
"UNICODE -> UNI-WORD -> UNI-LANGUAGE -> UNI-PEOPLE -> UNI-NATIONAL
-> UNI-WORLD -> UNI-PLANET -> UNI-COSMOS -> UNI-SPACE-TIME -> UTF-32"
0260デフォルトの名無しさんNGNG
UNKO
0261デフォルトの名無しさんNGNG
CPU等が速くなってんのにアプリの体感速度が変わらないとう現象の
原因を作っている人たちはココにいたんですね。。
0262デフォルトの名無しさんNGNG
NTではUnicode化したほうが速くなるが
PC初心者にお帰り
0263デフォルトの名無しさんNGNG
つーか >>261 は何を言いたいのかよくわからん
0264デフォルトの名無しさんNGNG
>>263
IT産業を支えてくれてありがとうと言っているのですよ
0265デフォルトの名無しさんNGNG
　　　　　　　　　　　　 ┏┓┏┳┓
　　　　　　　　　　　┏┛┗┻╋┛　　　　　　　　　　　　　　　＼ 　i　　　
　　　　　　　　　　　┗┓┏┓┃　　　　　　　　　　　　　　　 ── ＋ ─>>1-1000
　　　　　　　　　　　　 ┃┃┃┃　┏┳┳┓　　　　　　　　　　／/ | ＼
　　　　　　　　　　　　 ┗┛┗┛　┗╋┛┃　　　　　　　　／ 　/　|
　　　　　　　　　　　 　 　 　 　　　 　 ┗━┛　　　　　　／　　　/
　　　　　　　　　　　　　　　　　　　　　 ￣ 二─　＿
　　　　　　　　　　　　　　　　　　　　　　　　　￣ ､　　- ､
　　　　　　　　　　　　　　　　　　　　　　　　　　 -､＼　　 ＼
　　　　　　　 　 ／　　　　　　　　　　　　　　　　　 ＼＼　　　＼
　　　　 　 　 ／／　　　　　　　　　　　　　　　　　 ＼ヾ ヽ　 　　 ヽ
　 　 　 　 ／／／　　　　　　　　　　　　　　　　　＼ ヾ、 | 　 　 　　i
　　　　 ／__(　　　　　　　　　　　　　　　　　　　　　|! `i　　　　　　　 |
　　　 <_,へ　＞- 、　　　　　　 ,.-､_　　　　　　　　　|　　　　　　　　　|
　　　　　　　＼ノ人＼　　　 ／ ､ }! ＼　　　　　 　　|　　　　　　　　　|
　　　　　　　　 ＼へ〃＼／ヾ＼_ﾉ､ﾉ人　,.-､　　　 |　　　　　　　　　|
　　　　　　　　　　＼|＼rj＼ヾ /　　 ＼_ﾌ ,／　　　|! ﾘ　　　　　　　 |
　　　　　　　　　　rm＼ノ _　 Y　　 　　Lノ　　　　　 / 　　 |　　　　|
　　 　 　 　 |ヽ-r＜￣`ヾr'￣ヽ　　　　　　　　　　　/ /　 /　　　 /
　　　　　 　 | └､ノ/￣`,-`┐ {　　　　　　　　　_／ / ／　 ／／
　　　　　　　ﾚ⌒＼!_　　ｰ -{ ﾉ ｝　　　　　　　　　／　 ／ ／
　　　　　　　　　　　　￣`ー一 'ﾞ　　　　　　　　_／／_ ／
　　　　　　　　　　　　　　　　　　　　　　　＿二─ "
0266デフォルトの名無しさんNGNG
おい、お前ら字形が変わりましたよ。
ttp://www.forest.impress.co.jp/article/2004/02/24/jisx0213.html

コードは関係ないからスレ違いかもしれんが、改正前の字形で書いてると
ｵｻｰﾝ扱いになる悪寒。俺には改正後の文字が、なんか昔の字に
見えるんだけど。。。
0267デフォルトの名無しさんNGNG
経緯
１．旧字体のうち一部を新字体に「正式に」改正
２．改正されていない旧字体の一部を１．の改正からの「類推で勝手に」変更 (どこが主導でやったのかは知らないが)
３．今回２．で勝手に変更されていたのを「もともとの旧字体」に訂正

なので今回の改正で「改正後の文字が昔の字に見える」のは当たり前。
0268デフォルトの名無しさんNGNG
殆どが「書き文字としては間違いだけど、コンピュータ上では許されていた字形」を
正しい字形に戻したって感じを受けるな。
中には違いがさっぱり分からんのもあるんだが...。蟹とか灸とか粂とか。

個人的には進捗の捗の字が正しくなるのがうれしい。
0269デフォルトの名無しさんNGNG
>268
「正しさ」って何？
頻、賓、濱、捗
0270デフォルトの名無しさんNGNG
歩 渉 陟 捗 濱 瀕
0271デフォルトの名無しさんNGNG
歩 と
0272デフォルトの名無しさんNGNG
うぉ、『倶舎論』の本来の「倶」が入ってる！
産業省ﾏﾝｾｰ！
0273デフォルトの名無しさんNGNG
>>269
紙媒体の辞書に載せられるかどうか。
（載ってるかどうかとは言わないでおく）
0274デフォルトの名無しさんNGNG
DTP、フォント関連の連中は
忙しくなるな(w
0275デフォルトの名無しさんNGNG
DTP業界のフォントは78JIS字形をサポートし続けてきたから
実はほとんど影響なかったり。印刷物に使われ続けてきたん
だからまあ当然といえば当然だが。
0276デフォルトの名無しさんNGNG
何かスラドで激しくデジャヴを感じる投稿が多数あるような。
> 中には違いがさっぱり分からんのもあるんだが...。蟹とか灸とか粂とか。
そのへんは、例示字形にデザイン差を残しておくと規格がデザイン差に
関して何らかの価値判断を行ったと誤解されるおそれがあるから、
表外漢字字体表に一致させたもの(と解説に書かれてる)。
厳密にその通りのデザインで実装することを要求するものではないし、
そのような解釈はかえって表外漢字字体表の趣旨に沿わない。
何がデザイン差で何が包摂の範囲内での字体変更かも解説には
書かれてる。
0277デフォルトの名無しさんNGNG
蟹は「角」の右下と「虫」の上がくっついてるかどうかだな
微妙杉
0278デフォルトの名無しさんNGNG
鯖と鰯は良いね！
0279デフォルトの名無しさんNGNG
JIS X 0213が改正されても、JIS X 0208も一緒に改正されなければ無意味。
JIS X 0213なんて新JISキーボードと同じで、ほとんど使われていない規格なんだから。

ところで、法務省の人名用漢字追加はJIS漢字の字体をベースにするといっていたけど、
今回の改正でどう影響するんだろう？
今のところ、常用漢字・人名用漢字には2点しんにょうの字体はないけど（許容漢字を除く）、
場合によっては2点しんにょうに改正された文字が人名用漢字に追加される可能性がある。
0280デフォルトの名無しさんNGNG
後、気になったのは「辻」の字が2点しんにょうになっていること。
「表外漢字字体表」に従えば当然そうなるんだが、実際の人名（というか人の姓）で
使われているのは1点しんにょうの方が圧倒的多数。
2点しんにょうは文芸家（wが好んで使う（綾辻行人とか辻仁成など）けど、
表札とかに2点しんにょうの方が使われているのは見たことがない。

辻さんが「自分の名字の文字が『勝手に』正字に矯正されている」ことを知ったらどう思うだろうか。
人名にはまず使われていない迂とか迄とか謎とかは2点しんにょうのみにしてもいいけど、
辻は1点しんにょうと2点しんにょうの両方を規格に入れるべきだったと思う。
包摂規準に例外を作ってまでも。
0281デフォルトの名無しさんNGNG
正式には難しい字が使われてても
普段は簡単な字で書いてたりするので
（例：濱本を浜本と書いてたり）、
普段簡単な字で書いてるからといって、
その字で登録されているとは限んないけどね。
0282デフォルトの名無しさんNGNG
>>279
JIS X 0208を改正しなかった理由も解説に書かれてるね。
変更をほとんど使われていない規格だけにとどめたことで
混乱を最小限に抑えたとかいう角度の見方もある。
0283デフォルトの名無しさんNGNG
戸籍に登録されている「辻」が1点しんにょうということはありえない。
現時点で人名用漢字にも常用漢字にもないから戦後追加された
ことはないし、戦前の活字は当然すべて2点だし、
法務省は1点の「辻」は俗字扱いにしていて正字からの変更を
認めていないから既存の「辻」を持つ苗字が変えられた可能性もない。
したがって表札とかには戸籍にない略字を勝手に使っているだけだと
思われ
0284デフォルトの名無しさんNGNG
というか表札はふつう明朝体活字で書いたりしないから
1点しんにょうになるのはむしろ当然なような。
それとも点の下がグネグネした「辻」も追加すべきですかね。
0285デフォルトの名無しさんNGNG
> ところで、法務省の人名用漢字追加はJIS漢字の字体をベースにするといっていたけど、
読売の記事だとそれは去年の検討の話で
いったんご破算になったらしいんだが
今回も結局JIS漢字を元にしてるの?
0286デフォルトの名無しさんNGNG
imadoki kanji tukatteru yasi kimoi
0287デフォルトの名無しさんNGNG
>>283
電算化前の戸籍って和文タイプで打ったのもあるけど、手書きもあるよ。
たとえば漏れの本籍地は京都市だけど、戸籍謄本を取ってみたら手書きだった。
手書きの「辻」のすべてが2点しんにょうになっているとは思えない。
0288デフォルトの名無しさんNGNG
ああそうか、戸籍の電算化を阻んでるのは手書きの誤記を
これが自分の名前の字だと主張する連中だったな
> 手書きの「辻」のすべてが2点しんにょうになっているとは思えない。
むしろ手書きでは1点が普通だろ。それが活字では2点になるという
常識が戦前はあったわけだが
0289デフォルトの名無しさんNGNG
で、ののたんの名字は１点なの？２点なの？
場合によっちゃ幕の字書き換えなきゃならんのだけど
0290デフォルトの名無しさんNGNG
さすがプログラム版のスレだけあって、
漢字の話題になるといきなりレベルが低くなるな。
0291デフォルトの名無しさんNGNG
そもそも>>266が自分で言ってるがスレ違いっぽいし
0292デフォルトの名無しさんNGNG
>290
レベルの高い漢字の話題はどこでやってますか？
煽りじゃなく本当に知りたい。
0293デフォルトの名無しさんNGNG
格調高く感じを論ずるスレ四
http://academy2.2ch.net/test/read.cgi/kobun/1067856021/
0294デフォルトの名無しさんNGNG
>>293
感じって・・・
0295デフォルトの名無しさんNGNG
＿|￣|○ やられた。 古文・漢文板なんていったこと無かったから、無防備だった。
0296デフォルトの名無しさんNGNG
旧字体・別字体について
http://academy2.2ch.net/test/read.cgi/gengo/991011416/

【朝日】文字を徹底的に略すスレ【JIS】
http://academy2.2ch.net/test/read.cgi/gengo/1049173991/

【ゐゑ】舊字、舊假名遣ひで話すスレッド　三箇目
http://academy2.2ch.net/test/read.cgi/gengo/1075814605/

【常用漢字表にない漢字の代わりの漢字について
http://academy2.2ch.net/test/read.cgi/gengo/1004972973/

◆◆漢字専用スレｐａｒｔ2◆◆
http://academy2.2ch.net/test/read.cgi/kobun/1070305805/

旧かな旧漢字は伝統的でしょうか
http://academy2.2ch.net/test/read.cgi/kobun/965113447/

●教育漢字、常用漢字を有志で作り直すスレ●
http://academy2.2ch.net/test/read.cgi/kobun/1059105191/

JIS漢字
http://academy2.2ch.net/test/read.cgi/kobun/1038565269/


ちょっと集めてみたがレベルがそう違うとも思えんがね
0297デフォルトの名無しさんNGNG
ここも。

JISをもう1度、最初から作りなおせるとしたら
http://academy2.2ch.net/test/read.cgi/gengo/1052415384/
0298292NGNG
サンクスコ。
なるほど、レベルの違うスレもあれば、そうでないのもあって面白い。

結局、バカのせいなんだよな。
「かほる」なんて名前が昔から使われていると思うようなバカと一緒。

スレ違いなのでAC。
0299デフォルトの名無しさんNGNG
さ、
0300デフォルトの名無しさんNGNG
さんびゃくー！！
0301デフォルトの名無しさんNGNG
m17n-libがもうすぐ公開だな
使い物になるのだろうか
0302290NGNG
いや、どこのスレだって無責任なレスがほとんどなんだけどさ、
言語学版あたりの文字コード関連スレだと、
かなーり詳しい奴が張り付いてて、すぐに突っ込みが入る。

しょーがないから俺が突っ込んでおくと、
戸籍での「辻」は一点も二点もありだ。っつーか、
しんにょうはすべて一点でも二点でも認められているわけだが。
0303LightCone ◆sSJBc30S5w NGNG
UNICODEのUTF-8の日本語向けの符号を考えてみました:
http://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utf.htm

UTF-8と違って、JIS第一、第二までは、2BYTEで表せます。

まだ、仕様を考えている途中なので、この符号を用いたプログラムは一つ
もありません。

何か問題点や、嘘を書いてる点などが見つかりましたらご指摘頂ければ幸い
です（つまり添削お願いします）。
0304デフォルトの名無しさんNGNG
>>303
変換にテーブルが必要な時点でUTFと名乗るのは問題がある。
俺コードとかって名前なら別にどうでもいいんだけど。
0305デフォルトの名無しさんNGNG
>>303
>多バイト文字途中への検索ヒットを簡単に回避可能

正規表現で回避しているようだけど、回避のための
修正が必要な時点で、UTF-8と比べて汎用的とはいいがたいなぁ。
(strcmpを使っているなら細工をして再コンパイル等が必要だけど
UTF-8は修正の必要もない)
0306デフォルトの名無しさんNGNG
>>303
> 何か問題点や、
単にまた混乱の元を追加するだけってことかな。
0307デフォルトの名無しさんNGNG
みんなUTF-8で結構おなか一杯だからなぁ。
0308デフォルトの名無しさんNGNG
>>303
Unicodeを混ぜることができる,EUC-JP/シフトJISの一種と考えたら
そこそこ面白い。
0309デフォルトの名無しさんNGNG
>>308
その手の拡張は>>239にもあるし>>240-にもあるしおなかいっぱい
0310デフォルトの名無しさんNGNG
主にどういう局面で利用される事を想定してるんだろうか。
UTF-8でも少しサイズが大きい程度で、そんなに気にならないんだけど。
独自にやる苦労に見合うだけの結果が得られるかは微妙だ。
打算計算を抜きにすれば、自作のOSで自作の文字コード使って
色々実験するのは楽しそうとは思うけどね。(^^;
0311LightCone ◆sSJBc30S5w NGNG
>>308, >>309
「Unicodeを混ぜることの出来るEUC-JP/SJIS」に、「簡単に逆戻り可能」な
性質を取り入れたような感じなんです。

ちなみに、>>239の符号では、逆戻りは出来ないと思いますが、
さらに、「\」コードを含んでいるので、色々と問題があると思います。

というわけで、いかがでしょうか。

新しいコードは、みんなが使い始めるか、よっぽど良い性質がない限り、
抵抗感がある物かも知れませんが。
0312LightCone ◆sSJBc30S5w NGNG
>>310
>主にどういう局面で利用される事を想定してるんだろうか。
>UTF-8でも少しサイズが大きい程度で、そんなに気にならないんだけど。

そう思われる人が多いのであれば、せっかくでしたが、余り意味がないかも
知れません。

でも、今まで2BYTE表せていた文字に3BYTEを当てるのに抵抗がある人には、
需要があるのではないかと思うんです。

その点だけでは、>>239の符号もいいと思いますが、UTF-JAPANの方は、
逆戻り可能の性質を持っている点や、多バイト文字に\コード等を含んで
ない点で、解析やエディタ作りなどにおいて、真価を発揮する場面がある
のではないかと思います。

EUCも、2バイトの範囲では逆戻り可能ですけど。>>239に書かれている拡張EUC:
http://web.archive.org/web/20030218074331/www.ksky.ne.jp/~smile4me/charcode/xeucjp.htm
においては、UTF-16,UTF-32対応する3バイト以上のコードでは、逆戻りが
出来なくなっているようですし。
0313LightCone ◆sSJBc30S5w NGNG
>>304
この符号の場合、基本的に地域や言語ごとに違う変換テーブルを用意する
必要がありますね。それをOSがサポートして、欲しいフォーマットに
まで変換を世話してくれればアプリの負担は減るとは思うんですが。

全世界で全く同じコードを用いたいのであれば、漢字が３バイトになって
しまうのは、元々やむを得ないかも知れない。
0314LightCone ◆sSJBc30S5w NGNG
>>305
UTF-8の場合、strcmp()は、単純な昔ながらの1バイト単位の比較のまま
無修正で利用できてしまうんですよね。

それは凄い性質ではあると思いますが、結局、コードを無修正で済ました
いばっかりに、データサイズが大きくなる犠牲を払っているんだと思うん
です。

0315LightCone ◆sSJBc30S5w NGNG
なお、

UTF-JAPANを、「UTF-COMPACT-JAPAN」と改名して、
「UTF-COMPACT-ARABIA」
「UTF-COMPACT-CHINA」
なども定義すれば、strcmp()等の修正は、言語数分まで及ばずに
一回だけで済むかも知れませんね。
0316LightCone ◆sSJBc30S5w NGNG
>>237 から続く発言は、なんと先月のものなんですね！

うまく合併できないかな。
0317LightCone ◆sSJBc30S5w NGNG
>>261の
>CPU等が速くなってんのにアプリの体感速度が変わらないとう現象の
>原因を作っている人たちはココにいたんですね。。

これは、今まで2バイトで表現できていた物を3バイトにしようとすることとも
その一つかな。

全世界の文字を使えるのはいいことではあるけれど、日本人が、英語と
JIS第一,第二以外の言語を使用する頻度は低いし、文字集合はUNICODEを
使うにしても、地域ごとに違った符号があってもいいのではないかな。
0318LightCone ◆sSJBc30S5w NGNG
UTF-COMPACTの変換テーブルは、OSが提供するだろうから、
UTF-COMPACT-xxxxx用のアプリは、いずれのxxxxx言語にも
無修正で対応できるのではないだろうか?
0319LightCone ◆sSJBc30S5w NGNG
例えば、HTMLヘッダに、

<meta http-equiv="Content-Type" content="text/html;
charset=
utf-compact-japan">
~~~~~~~~~~~~~~~~~

を書いておけばいいんじゃないかな。

SJISや、EUC-JPでやってることと何ら変わりないと思うし。
0320デフォルトの名無しさんNGNG
アメ公がUTF-16嫌ってUTF-8に走るのとまったく同じ論法だよね
自分たちが使いもしない文字のことなんてどうでもいいと思うのは
世界共通というか
0321LightCone ◆sSJBc30S5w NGNG
>>320
でも、自分たちの地域で効率を上げることにも、一利はあると思うんです。

UNICODEを全否定しているわけではなく、符号長に地域ごとに偏りを
持たせるだけですし。
0322LightCone ◆sSJBc30S5w NGNG
SFみたいな世界になって、文字種が爆発的に増えた場合、やっぱり、
地球では地球語に短い符号を割り当てるんじゃないかな。

そういう意味で、偏りを持たせる発想は、古くさい考えではないと思う。
0323デフォルトの名無しさんNGNG
だったらローカルコードでいいし
地域の数だけ馬鹿でかい変換テーブル持つなんて馬鹿の極み
0324デフォルトの名無しさんNGNG
日本語が多くてサイズが増えるのが嫌なら、UTF-16を使えばいいのでは？
0325デフォルトの名無しさんNGNG
> 制御コード、特殊記号、\コードを含まず
C1文字は制御コードじゃありませんか
そうですか
0326デフォルトの名無しさんNGNG
> JIS X 0213 2000 JIS第三、第四 4344字
今さら2000年版かよ
0327デフォルトの名無しさんNGNG
> 情報交換用漢字符号系
つーかずいぶんと古い資料参照してるな
0328デフォルトの名無しさんNGNG
そもそもたった一つのインプリで他言語をカバーしようとしたのがUnicodeじゃないの？
それを地域ごとに独自テーブル作ったら意味ないじゃん
0329デフォルトの名無しさんNGNG
> /[^\x81-\xde]任意の文字列/
「任意の文字列」が先頭だったらヒットしなくなるね
0330328NGNG
失礼
X他言語
O多言語
0331328NGNG
そもそも
UTF-JAPAN
ってのがかっこわるいよね
せめて
UTF-JPとかUTF-jaとかにすればいいのに
0332デフォルトの名無しさんNGNG
せめてもう少し間隔おいて自演したら？
0333デフォルトの名無しさんNGNG
> SJISや、EUC-JPでやってることと何ら変わりないと思うし。
なんら変わりなく欠点を引き継いでどうするんだよ
0334デフォルトの名無しさんNGNG
>>332
誰に言ってるんですか?
0335デフォルトの名無しさんNGNG
ちょっと考えてはみたけど、UTF-8越えは難しいな。
使っててあまり不満ねーもの。（慣れたのもある）
その俺コードで外人と文書のやり取りする時はどうする気なんだ？

>>331
確かに微妙な名前だ。

>>333
文字集合がUnicodeでやろうと思えば多くの文字を表現出来る点が重要なんじゃね？
サイズを気にするなら圧縮で十分って気がするけど。
0336LightCone ◆sSJBc30S5w NGNG
中国には、JIS第一水準と同様に、「第一級漢字」が定まっていて:
http://www.kishugiken.co.jp/cn/code09c.html
このようになってます↑

ご覧の通り、JIS第一、第二水準と重複する部分も多く、興味深いのです。

これと、JIS第一水準を合わせた部分を2BYTEで表せるような、UNICODE符号を
作れば、中国人と日本人の両方にメリットがあるかも知れないと思うのですが、
いかがですか?
0337LightCone ◆sSJBc30S5w NGNG
ちなみに、UNICODEのCJK統合漢字部分は、頻度の低い漢字も何も考えずに
並べてあり、頻度毎に分類できないので、どうしても22000文字程度
をまとめて符号化する必要があります。ASCII符号と互換性を持たせ
つつ、これら全ての文字集合を2BYTEで表現しきることは、ほぼ不可能
です。

しかし、中国の第一級、第二級漢字と、日本のJIS第一、第二水準漢字
には重複する部分が多く、それらの「和集合」の文字なら、2BYTEで
表せる範囲の数ではないかと踏んでるんです。
0338デフォルトの名無しさんNGNG
各文字に割り振るコードの順番にも意味があるから、単に足し合わせれば良いという物でも
ないと思うけど。
0339LightCone ◆sSJBc30S5w NGNG
大体の目安としては、一万五千字程度の文字なら、ASCII符号と互換性
を持たせ、「逆戻り可能」で、しかも、後続バイトを付ければUCS-4全体
を表現しきれるような、2BYTEの符号を作る事が出来ると見ています。
0340LightCone ◆sSJBc30S5w NGNG
>>338
せっかく、JIS第一水準で五十音順、第二水準で部首順になってるのが、
中国の文字セットと合成した際に失われると言うこと?
0341デフォルトの名無しさんNGNG
GB18030は何文字格納できるんだっけか？
0342LightCone ◆sSJBc30S5w NGNG
UNICODEでは、部首順らしいので、統合する際にそれにならえばいい
のでは?
0343LightCone ◆sSJBc30S5w NGNG
>>341
わても知らんので、調べて。
0344デフォルトの名無しさんNGNG
>>342
コテハンには聞いていない。
0345デフォルトの名無しさんNGNG
150万文字ぐらい入るんだっけか＞GB18030
0346デフォルトの名無しさんNGNG
>>345
うん。約1,611,668文字かな。
0347デフォルトの名無しさんNGNG
ちなみに、GB18030は、逆戻り不可だし、検索も複数バイト文字の途中で
ヒットする。
0348LightCone ◆sSJBc30S5w NGNG
UNICODEの新符号「UTFCP」を発案しました:

http://nowsmartsoft.or.tv/nws/Japanese/nwsos_utf.htm

2バイトの符号で1万5千文字以上を表せて、なおかつ、文字列を文字単位で
正確に逆戻りできる、UNICODE符号です。UCS-4全体を表現できます。

また、多バイト符号にASCII符号を一切含まないので、英大文字小文字変換に
対しても安定です。

理論上、日本語のJIS第一、第二水準漢字、中国語の第一級、第二級漢字の両方
をコードページの切り替えなしに2BYTE符号で表せますので、
UTF8に比べ、頻度の高い日本語や中国語の文章が2/3に(50%減)コンパクトに
なります。


いかがでしょう？ (^_^;)
0349デフォルトの名無しさんNGNG
ハードディスクが何百GBになる時代に、テキストファイルの容量が数十%減ったくらいでは
あまり利点を感じないけどなぁ。

むしろ、>>240-243みたいに(書いたの漏れだけど)EUC-JPやShift_JISの完全上位互換規格を
考えたほうがまだ意味があると思う。
0350デフォルトの名無しさんNGNG
情報の冗長性を取り除いて小さくまとめようとすると
たいてい少し複雑な演算が必要になるよね。
UTF8と張り合うなら演算量も念頭にいれる必要があるかも。

UCS4とUTF8の変換では１～２個の条件分岐と
長さ*(シフト、OR、AND)演算＋入出力程度で変換してる。
0351デフォルトの名無しさんNGNG
>>348
各文字コードの主要な正規表現エンジン各々での探索コストの大まかな比較をやってみてほしい。
0352デフォルトの名無しさんNGNG
ただでさえ混乱している文字コード周りの処理をさらに混乱させないでくれ。
0353デフォルトの名無しさんNGNG
>>348
「俺コード」を作るな。
有用だと信じるなら、IETFとかUnicode.orgにでも提案しろ。
0354デフォルトの名無しさんNGNG
>>352-353
作るのは勝手なんじゃね？
気に入らないなら使わなけりゃ良いだけ。
案が未熟だというだけで作る事自体を否定するものではないかと。

因みに俺もUTF8で不満は無い。
文字コードみたいなもので冒険せずに他で頑張った方が良いんじゃないかと。
高いリスクを冒した結果、成功したところで見返りは小さい。
0355デフォルトの名無しさんNGNG
まあ、独自Unicode系CESなんて、普及するわけもないから、
悪影響も少ないわな。機種依存文字なんかはすぐに悪影響が出るけど。
0356デフォルトの名無しさんNGNG
俺アプリのベースエンコーディングに使う為の独自エンコーディングの開発ならオケですか？
0357デフォルトの名無しさんNGNG
俺OSのベースエンコーディングに使う為の独自エンコーディングの開発ならオケです。
0358デフォルトの名無しさんNGNG
>>350
1つの文字を複数の表現で符号化できる規則は可能なら避けたほうがいい
UTF-8で避けようとすると加減算が余分に入るけど
0359デフォルトの名無しさんNGNG
お前ら釣られるなよw
0360デフォルトの名無しさんNGNG
>>358
UTF-8は一つのコードに対して複数の表現は許していないはずだけど
文字とか字形の話…？
0361デフォルトの名無しさんNGNG
>>360
・・・・は？
0362LightCone ◆sSJBc30S5w NGNG
UTFCPについて、詳しく書いておきました。
符号の読み取りや、逆戻りの状態遷移図やソースプログラムもあります。
また、1バイト単位の正規表現ルーチンでも検索に利用できることも分かったので
書いておきました。

http://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utf.htm
0363デフォルトの名無しさんNGNG
2chで宣伝とは・・・
0364デフォルトの名無しさんNGNG
>>362
gobackUTFCP が動くとは思えないのだが。
0365LightCone ◆sSJBc30S5w NGNG
>>364
動くと私は思います。

動かないと思われる例を挙げてみて下さい。(^_^;)
0366デフォルトの名無しさんNGNG
>>362
だから○とか×じゃなくて探索コストで比較しろって。
あんたが主張する利点は対象データの処理がUTF8に比べて
速いということだろ。今の状態では説得力0だ。
0367デフォルトの名無しさんNGNG
>>366
いい加減放置しろって・・・
明らかな宣伝ということで削除依頼もしておいた。
0368LightCone ◆sSJBc30S5w NGNG
>>366
速いという事じゃなく、サイズがコンパクトと言うこと。
ディスクに保存するときは速いだろうけど。
0369デフォルトの名無しさんNGNG
>>368
んなんだから、院試に落ちるんだよ。
偉そうなお題目なんてのは後にしろ。時間の無駄だ。
0370LightCone ◆sSJBc30S5w NGNG
>>369
どの大学の、何学科の院試か知りませんが、工学部の院で良ければ、
東大でも受かります。
0371LightCone ◆sSJBc30S5w NGNG
第一、京大の理学部物理学科だって、研究室によれば簡単に受かるし。
0372デフォルトの名無しさんNGNG
>>365
動く動かないは別として、初期状態が符号列の最後のバイトに
なければならないというのがダメダメ。
そんな前提を置いた上でなら、EUCだってSJISだって

「複数バイト文字の最後のバイトから高々符号長分遡るだけで、
その符号の先頭バイトを発見可能」

って言えてしまうんだが。
0373LightCone ◆sSJBc30S5w NGNG
>>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では、最後尾バイトからスタートする限りは大丈夫。
0374LightCone ◆sSJBc30S5w NGNG
ちなみに、SJISでは、例えば、
ラャc ---> 0x83, 0x89, 0x83, 0x83, 0x63
宴ツ ---> 0x89, 0x83, 0x83, 0x63

のように、最悪のケース、1000バイトも遡っても、遡り始めた文字が、
半角なのか全角なのか判断付きかねる文字列を作れる。

つまり、「ツ」なら全角、「c」なら半角なのだが、その区別が長く遡っても
なかなか付かないような文字列が存在し得リますです。
0375デフォルトの名無しさんNGNG
>>374
UTF8より優れているにしろ使われなきゃどうしようもない。
こんなとこよりもっと有効なところで発表すれば？
0376デフォルトの名無しさんNGNG
>>374
自分のコードがまったくおんなじ問題を抱えているのに
気付いていないんだろうか？

＃こういうのリアルタイムで見たの久しぶりだな...
0377デフォルトの名無しさんNGNG
>>365
符号が DBA で、現在位置が A のとき。
0378デフォルトの名無しさんNGNG
> LightCone
まずは自分のOSで使用してみたら？
せっかく独自のOSを開発しているんだから。
0379デフォルトの名無しさんNGNG
結論: wchar_t使えやボケ
0380デフォルトの名無しさんNGNG
>>358
UTF-8では禁止されたはず。
確かそれ周りのセキュリティーホールもあったような。
（特定文字のチェックをすり抜けるようなやつ）
0381デフォルトの名無しさんNGNG
>>380
イチから作るなら「禁止」じゃなくて理論上重複符号化がありえない
設計にしたほうがいいって趣旨。UTF-8の場合は互換性の問題から
不可能だったわけだが。
セキュリティホールの話は>>232-あたりで出てるね
0382デフォルトの名無しさんNGNG
UTF-8はtransformation format of ISO 10646なんだから
UCSに戻して使うのが本来の使い方。
それを正しく把握していれば重複符号化が可能でも何ら問題無い。
0383デフォルトの名無しさんNGNG
>>363
宣伝ではなくて、突っ込み貰うのが目的なんだろ。
叩き台出してみてマシになるかどうかという。
置き換えるには既にUTF-8が広がり過ぎていると思うが。
0384LightCone ◆sSJBc30S5w NGNG
>>377
>符号が DBA で、現在位置が A のとき。

そんなのは全く問題ありませんよ。あなたが全く理解してないだけです。

http://www.nowsmartsoft.or.tv/images/UTFCP-BW.png
↑の図を見てもすぐ分かることだし、下の関数冒頭を見ても分かる通り、
*ptr <= 0x7f の判定が真になるので、すぐに、「A」に場合分けできて、
1バイト符号に分類されます。

unsigned char *gobackUTFCP( unsigned char *ptr )
{
if ( *ptr <= 0x7f ) {
//(1) A
ptr--;
}
...
0385デフォルトの名無しさんNGNG
>>382
> UTF-8はtransformation format of ISO 10646なんだから
> UCSに戻して使うのが本来の使い方。

まったくです。
情報交換用コードと情報処理用コードは分けて考えるべきなのに、
UTF-8をそのまま処理することを考えているのは愚かすぎます。

> それを正しく把握していれば重複符号化が可能でも何ら問題無い。

それはどうかと思いますが。
見識の低い人が実装することもあるわけですし。
0386LightCone ◆sSJBc30S5w NGNG
逆戻りがなぜ可能か分かりにくい人が多いようですので、
解説しておきます。ご覧アレ:
http://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utfcp.htm

これで。UTFCP符号が間違いなく逆戻りできることの証明になって
いると思います。
0387385NGNG
>>386
そもそも情報交換用コードで逆戻りする必要がありません。
0388LightCone ◆sSJBc30S5w NGNG
>>387
ASCIIもオンメモリで、32BITで保持するつもりなんでっしゃろか?
0389デフォルトの名無しさんNGNG
>>388
必要ならそうするんでは?
ASCIIだけでよい文脈なら1バイトで処理すればいいし、
そうでないなら4バイトで処理すればいいですし。
あと保持というのがよく分かりません。UTF-*とUCS*の
どちらで保持するかは文脈によるのでは。
0390デフォルトの名無しさんNGNG
ときどきいるよね。自称大発見とか大発明とか。
そろそろ春も近いしね。
0391LightCone ◆sSJBc30S5w NGNG
>>385
そもそも、情報交換用なら、BOCU圧縮を使えば、UTF8よりコンパクトに
なる:
http://www-6.ibm.com/jp/developerworks/unicode/010921/j_u-binary.html

UTF8は、情報処理用としてもかなり考慮されていて、ASCII用に書かれ
た古い検索ルーチンや文字処理ルーチンを無修正でUnicodeに対応でき
る特徴をっている。こんな特性は、よく知られている他の可変長符号に
はない。
0392デフォルトの名無しさんNGNG
別に内部コードとしてUTF-8を採用することが
禁止されてるわけでもないのに愚か過ぎるだの見識が低いだの
とまで言われなければならない理由は何ですか
0393デフォルトの名無しさんNGNG
>>383
意見を求めているふりをして人の話などぜんぜん
聞くつもりがないところを見る限り違うような気がします。
では何が目的なのかと言われてもさっぱり分かりませんが
0394デフォルトの名無しさんNGNG
>>391
> UTF8は、情報処理用としてもかなり考慮されていて、ASCII用に書かれ
> た古い検索ルーチンや文字処理ルーチンを無修正でUnicodeに対応でき
> る特徴をっている。こんな特性は、よく知られている他の可変長符号に
> はない。

それはEUC-JPでも普通に行われてきたのでは?^^;
「問題が出ないようにしてある」のと「情報処理用に作ってある」のとは別です。
EUC-JPでもShift JISでもISO-2022-JPでも、内部処理用に使おうと思えば
可能です。実際そういうソフトウェアもあるわけですし。
ただ、その場合処理が複雑になるしその分エンバグする可能性も高いわけです。

> そもそも、情報交換用なら、BOCU圧縮を使えば、UTF8よりコンパクトに
> なる:
> http://www-6.ibm.com/jp/developerworks/unicode/010921/j_u-binary.html

ここまでするなら、レイヤーを分けて普通にハフマン符号化した方が良いと思うんだけど。
0395LightCone ◆sSJBc30S5w NGNG
>>394
>それはEUC-JPでも普通に行われてきたのでは?^^;
多分、UTF8の特性をご存じない。

EUC-JPでは、全角文字をASCII用のstrstr()で探そうとすると、
別の全角文字の途中にヒットしてしまうことがあるが、UTF8では
ない。
0396デフォルトの名無しさんNGNG
>>395
> EUC-JPでは、全角文字をASCII用のstrstr()で探そうとすると、
> 別の全角文字の途中にヒットしてしまうことがあるが、UTF8では
> ない。

確かにそうですね。失念していました。
0397396NGNG
ですが情報処理コードとして適切でないのは明らかです。
strstr()して得た開始位置は、全体の何文字目なのでしょうか?
0398デフォルトの名無しさんNGNG
ところで疑問なのは
なんでUTFCPとUTF-JAPANと言う二つの符号化方式を用意したかだ。
0399デフォルトの名無しさんNGNG
それを言うならUCSの一単位は一文字とは限りませんが。
結合音節文字とかご存知ありませんか。
固定長によるインデックスアクセスですべて済まそうと
考えること自体が漢字文化圏の幻想です。
0400デフォルトの名無しさんNGNG
400get
盛り上がってきました
0401デフォルトの名無しさんNGNG
>>384
「if ( ptr[-1] <= 0x7f )」だろマヌケ。
それとも、DBA の B を指すのが正解なのか?
0402デフォルトの名無しさんNGNG
>>399
> 固定長によるインデックスアクセスですべて済まそうと
> 考えること自体が漢字文化圏の幻想です。

この考えは「どうせAという処理をしなければならないのだから
Bという処理が増えてもかまわない」と言っているようで奇妙
です。問題を分割することは基本なのに。
0403デフォルトの名無しさんNGNG
>>398
自分のOS作るのにどういう文字コードをメインに据えるかを考えているらしい。
UTF-8だと漢字のサイズが大きいから気に入らないそうだ。
OSとセットでもなけりゃ独自コードの生き残りは辛そうだから、
良い機会と言えば良い機会なんだろうが。
超漢字が無かったらTRONコードなんて……。
0404デフォルトの名無しさんNGNG
>>402
「どうせ文字数を数えなくてはいけないのだから文字の間に
マッチしたかどうか判定する必要があっても構わない」
というのは奇妙ですよね。要は程度の問題です。
そもそもUCS*ではstrstr()一切使えないし
(charが16ビットや32ビットでない限り)
0405LightCone ◆sSJBc30S5w NGNG
>>401
マヌケなのはあなたです。Aを指すのが正解で、*ptr <= 0x7fのままで
間違ってません。
0406LightCone ◆sSJBc30S5w NGNG
>>398
最初思いついたのが、UTF-JPで、複数バイト文字に、A-Z, a-zなどを
含んでいるのが、欧米人が何も考えずにstrupr()する人が多い事情を
考えると良くないと指摘されて、頭を悩めて作ったのが、UTFCPです。

UTFCPは苦労して導きました。0x80以上だけを使って逆戻り出来る
符号としては、これ以上コード・ポイントは増やせないかも。
0407デフォルトの名無しさんNGNG
てかコテハンでうだうだやるのもほどほどに。
俺様規格考えた～まではまぁ、いいかもしれないが、その先はここでやらんと自サイトに掲示板でも
作ってそこで勝手にやってて欲しいな。

面白いとおもった香具師はそっちで反応するだろう。少なくともここでやられては迷惑なだけだ。
0408デフォルトの名無しさんNGNG
>>407
どうせ余所でやっても見ないし。俺はここでやってくれてかまわないよ。
別のネタを話すにしても並行して話せばいいだろう。今までもそうやって
きたんだから。
0409LightCone ◆sSJBc30S5w NGNG
>>407
分かりました。

UTFCP符号について興味のある人は、下記の「UTFCP符号について」ス
レッドで議論を継続するようにして下さい:

http://www.nowsmartsoft.or.tv/bbs/test/read.cgi/NWSOS/
0410デフォルトの名無しさんNGNG
俺もここでやるのは構わないけど、コテハンでやるなら
多少煽り口調で言われても落ち着いてキレずにやって欲しいのぅ。
0411LightCone ◆sSJBc30S5w NGNG
>>410, >>408, >>407
個人的にはどっちでもいいです。
0412デフォルトの名無しさんNGNG
だんだん本性を現してきたな。
自分の巣に帰りなよ。貴公子さんよ。
http://pc.2ch.net/test/read.cgi/os/1075632569/
0413デフォルトの名無しさんNGNG
>>403
でもそのOSがあんな前時代的な仕様ではねぇ・・・
0414デフォルトの名無しさんNGNG
>>413
？
何か困る事でも？
0415デフォルトの名無しさんNGNG
>>414
>>403 生き残りは辛そうだから、
0416デフォルトの名無しさんNGNG
そういや、中国のGB2312って、日本のひらがな、カタカナが含まれるって
本当?
0417デフォルトの名無しさんNGNG
>>416
らしいね。
big5にも入ってるって話だぞ。
0418デフォルトの名無しさんNGNG
>>416
>>336
0419デフォルトの名無しさんNGNG
ここで UTF-8 以外のコードを提案してる人って、
SQL とかそーいうものも全部これから用意しよう、用意されるはずだ、というような
主張も imply してるって考えていいのかな。

それとも既存ライブラリやシステムと関連しない小規模な自作PG用としての提案なのかな。
そのへんはっきりさせてくれないと、批判とか批評とかしにくいと思うんだけど。
0420328NGNG
ねぇねぇ最初UTF-JPじゃなくてUTF-JAPANじゃなかった？
0421デフォルトの名無しさんNGNG
UTF-ｼﾞｬﾍﾟｰﾝ
0422デフォルトの名無しさんNGNG
COMPJAPAN互換？
0423デフォルトの名無しさんNGNG
大多数にとっては標準化を考えているのかどうか、それだけが問題じゃないのか？
こんなん考えました～ だけだと誰もついてこないと思われ。
0424デフォルトの名無しさんNGNG
俺エンコーディング大流行の予感。
0425デフォルトの名無しさんNGNG
>SQL とかそーいうものも全部これから用意しよう、
>用意されるはずだ、というような
8bit目がonであればたいていOKなんだが。
あと再コンパイルが許されるならUCS-4が一番楽だろ。
C++ならインターフェース変更するだけでロジックは変わらんのだから。
0426デフォルトの名無しさんNGNG
質問させてください。
PHPで、EUCでソースを保存して、
CHARSETをShift_jisでブラウザ出力させたいのですが、
どうやったら出力させることができるでしょうか？
教えて下さい。お願いします。
0427デフォルトの名無しさんNGNG
PHPで、ソースをEUCで保存して、
Shift_jisでブラウザに表示したいのですが、
どうしたらうまくいくでしょうか？
ご存知の方、おしえてください。お願いします。
0428デフォルトの名無しさんNGNG
俺も新しいコードを考えてここの住人を煽ろうかな。
0429デフォルトの名無しさんNGNG
>>425
>8bit目がonであればたいていOKなんだが。
いや、エラー無く通るってだけじゃなくて、検索とかさ・・・
0430デフォルトの名無しさんNGNG
lexとかgrep関係はいろいろとあるんだけど、
それは適切なアルゴリズムでちゃーんとビルドフロムスクラッチすればOK。
0431デフォルトの名無しさんNGNG
>>430
面倒
0432デフォルトの名無しさんNGNG
>>431
ポマエラ、公開しても落としに来ないくせに。
0433デフォルトの名無しさんNGNG
既存のアルゴリズムで速くなければ意味ない。
0434デフォルトの名無しさんNGNG
古いアルゴリズムでマルチバイト対応のパターンマッチング処理は
恐ろしくムダ。
文字クラスの対応パッチなんて組み合わせが爆発するロジックのがある。
0435デフォルトの名無しさんNGNG
>>391
そういう優れたUTF-8というものが既に存在しているのに、なんで
新しくわざわざ欠点の多い符号化法を提唱するのかねぇ？
0436デフォルトの名無しさんNGNG
Unicodeの合成文字って、合成する順序は決まってるんですか?
必ず。Group-1 ---> Group-2 ---> Group3 の順序で符号を並べる
のか、それとも、順序は動でもいいのか。

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

ハングル文字なんかも、合成済みの物と、素片(?)のものとがあったから、
検索するときは配慮しないと行けないような。
0437LightCone ◆sSJBc30S5w NGNG
>>435
日本語の文字に対するバイト数の増加が納得できないため。
0438デフォルトの名無しさんNGNG
>>436
順序どうでもいいよ。

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

現実ってこんなもん
0439デフォルトの名無しさんNGNG
>>438
ということは、合成文字に関しては、1バイト単位での検索ルーチンでは
対応できないということですね。

ちゃんとしたロジックを組まないと行けないんでしょうね。
0440デフォルトの名無しさんNGNG
>>436
ttp://www.unicode.org/versions/Unicode4.0.0/ch02.pdf
の2.10辺りとかを参照。
> 完成形としては同じになるのに、符号としては異なる文字
も「あり」。

じゃあ文字を比較するときどうすんだ、というのは
ttp://www.unicode.org/reports/tr15/tr15-23.html
辺りとかを参考にどうぞ。
0441デフォルトの名無しさんNGNG
もう面倒くさいから一文字64bitでいいよ
でかけりゃgz
0442デフォルトの名無しさんNGNG
合成文字は終端記号として処理すべきかギモンヌ。
なぜtexのようなシンタックスとして扱わんのかと。
0443デフォルトの名無しさんNGNG
>>441
さんせー
0444さっきゅん ◆GG1SfzBGbU NGNG
　　＿
　 /～ヽ
　(｡･-･)　｡oO( 64bitじゃぜんぜん足りませんが何か
　ﾟし-Ｊﾟ
0445デフォルトの名無しさんNGNG
256bitでどうだコンチクショー
0446デフォルトの名無しさんNGNG
>>445
どんだけ使えば気が済むんですか。
0447さっきゅん ◆GG1SfzBGbU NGNG
　　＿
　 /～ヽ
　(｡･-･)　｡oO( 最初からグリフでデータ交換すれば文字コードなんて概念消滅するんだけど
　ﾟし-Ｊﾟ
0448デフォルトの名無しさんNGNG
utf-2000とかどうか。
0449デフォルトの名無しさんNGNG
>>447
お前さんの言う「グリフ」ってのは「グリフイメージ」のことか？
0450デフォルトの名無しさんNGNG
>>448
古い。
0451デフォルトの名無しさんNGNG
検索どうするんだよ
0452LightCone ◆sSJBc30S5w NGNG
>>447
それだと、フォントが変えられないし、HTMLブラウザやコンパイラや
インタプリタに光学文字読み取り機を内蔵しなきゃならないし。
0453LightCone ◆sSJBc30S5w NGNG
合成文字まで考えるとやはり、結局固定長符号でも可変長符号でやる場合と
余り手間が変わらないのかな。
0454LightCone ◆sSJBc30S5w NGNG
合成文字がある場合は、UCS4符号を使っていたとしても、例えば「n文字目」の
ポインタを得たいとき、言わずもがな、いきなり
ptr = &linebuf[n-1]
みたいなことをやるわけにも行かず、普通は、カレント位置から順番にたどって
行くことになるだろうらら。
0455LightCone ◆sSJBc30S5w NGNG
合成文字まで考えると、結局、UTF8でも、ASCIIしか考慮していない
strstr()では正しく検索できないね。
0456デフォルトの名無しさんNGNG
>>444
この世の中に180京文字以上もあるのか？
1つの言語ごとに1億文字分のスペースあたえても余裕だと思うが。

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


もっと富豪になれいつまでも貧乏性はｲｶﾝ
0457デフォルトの名無しさんNGNG
>>456
8文字しか表現できないと思ったのか？
0458LightCone ◆sSJBc30S5w NGNG
>>456
>この世の中に180京文字以上もあるのか？
64BITじゃ足りないというのは、合成文字も含めてのことでは?
0459デフォルトの名無しさんNGNG
⑳の大きいやつとか㍍とか合成顔文字とか、
そんなのをどんどん含めていくとして

まあそれでも一億は越えないよな。
0460LightCone ◆sSJBc30S5w NGNG
日中混合漢字テーブルを作ってみました:
http://www.nowsmartsoft.or.tv/nws/Japanese/japan_china.htm
0461デフォルトの名無しさんNGNG
文字コード変換について語りましょう♪
0462デフォルトの名無しさんNGNG
たぶん24ビット（1677万文字）もあれば、合成なしで世界中の全部の文字を収録することが
出来そうな気がするが…
0463デフォルトの名無しさんNGNG
>>462
DecompositionやNFDを使うのは派生形や辞書順での扱いを容易に
するためであって、文字が足りないからではない。
0464デフォルトの名無しさんNGNG
>>463
0465デフォルトの名無しさんNGNG
>>464
0466デフォルトの名無しさんNGNG
>>465?
0467デフォルトの名無しさんNGNG
>>467
0468467NGNG
_|￣|●
0469デフォルトの名無しさんNGNG
Webアプリでhtmlで漢字入力した場合、サーブレットを通して最終的にJSPで表示する際、
どうしても文字化けが起こってしまいます。この場合に対処する方法としての
プログラムの記述の仕方を知っている方がいらっしゃたら教えてください。
0470デフォルトの名無しさんNGNG
そんなDQN言語使うからだ
0471デフォルトの名無しさんNGNG
言語がDQNなのではなく（ｒｙ

WebProg
http://pc2.2ch.net/php/
0472デフォルトの名無しさんNGNG
俺の知らない新言語が出来てるのかと思った。
0473デフォルトの名無しさんNGNG
質問です。
VBscriptを使って
「UTF-8」→「base64」→「UTF-8」のデコードを行いたいのですが、

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

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

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

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

なにか良い方法はないでしょうか。
0474デフォルトの名無しさんNGNG
すみません、質問です。
JSP画面で漢字表記するために必要なセンテンスって
何でしょうか？教えてください！！
0475デフォルトの名無しさんNGNG
>>473
base64ってバイナリをそのままエンコード、デコードするものだと思うのだが。
文字コードと何の関係が？
0476LightCone ◆sSJBc30S5w NGNG
http://www.nowsmartsoft.or.tv/nws/Japanese/jpcn1.htm
0477LightCone ◆sSJBc30S5w NGNG
投稿ミス(早走)りました。↑は、JIS第1水準+中国第一級。
↓が、JIS第1第2+中国第一級、第二級
http://www.nowsmartsoft.or.tv/nws/Japanese/jpcn12.htm

ついでに、Unicodeが、西洋の言語にヒイキ気味なことは、↓の最後の
方に書いてあります。異論あればどうぞ。
http://www.nowsmartsoft.or.tv/nws/Japanese/unciode.htm
0478473NGNG
>>475
確かにそうなんですけど。
0479デフォルトの名無しさんNGNG
>>478
VBScriptの内部コードがUTF-8だからSJIS(EUC-JP)->UTF-8変換が入ってるんじゃないか?
おそらく不要なコード変換部分をカットすれば良いだけだろう
0480デフォルトの名無しさんNGNG
あ、しまったマルチになってしまいました。
えっと>>479

http://www.geocities.co.jp/SiliconValley/4334/unibon/asp/base64.html
を使っているのですが、見た感じ、
SJIS→UTF-8ってのは無いかんじですが、どのあたりでしょうか。
0481デフォルトの名無しさんNGNG
>>480
だからUTF-8とかSJISとかは実際のところ問題ではなくて
バイト列->内部コード変換をカットしろという話なんだが…
0482デフォルトの名無しさんNGNG
> 455 ：LightCone ◆sSJBc30S5w ：04/03/09 15:07
> 合成文字まで考えると、結局、UTF8でも、ASCIIしか考慮していない
> strstr()では正しく検索できないね。

お前、 wcsstr/wcswcs って知ってる？
0483LightCone ◆sSJBc30S5w NGNG
>>482
あなたは全く意味分かってないね。
0484LightCone ◆sSJBc30S5w NGNG
>>482
要するに、そういうものを使えば、あらゆる文字コードに対応できるのは
当たり前なので言うまでもないことなんだよ。

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

人を馬鹿にする前に自分が勉強すること。
0485デフォルトの名無しさんNGNG
string.h、ctype.h、regex.hなどの文字(列)に関係する関数全てが
UTF-8を使えば国際化されるのであれば話は別だが、strstrとか一部の結果だけ
取り上げて既存の文字コードより優れてると主張するのは、木を見て森を見ない馬鹿か
Markus Kuhnのような確信犯。まあ>>484は前者だろう。
0486デフォルトの名無しさんNGNG
OS 板に帰ってくれ。
0487LightCone ◆sSJBc30S5w NGNG
>>485
>UTF-8を使えば国際化されるのであれば話は別だが、strstrとか一部の結果だけ
>取り上げて既存の文字コードより優れてると主張するのは、木を見て森を見ない馬鹿か
>Markus Kuhnのような確信犯。まあ>>484は前者だろう。

UTF8の場合、何も修正しなくても大丈夫なことが多いと言うことが言えるわけで、
それが理解できないなら、UTF8について理解できてない。
0488LightCone ◆sSJBc30S5w NGNG
>>485
試しに、UTF8に変えたとき破綻する例上げてみなはれ。

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

はっきり言えば、ある意味変な解釈のまま、関数同士がお互いに間違い続ける
から矛盾が生じないという事になる。
0489LightCone ◆sSJBc30S5w NGNG
自分が理解できないのを他人のせいにするのが流行ってまんな。2chは
大体そんなものだけど（笑）。
0490LightCone ◆sSJBc30S5w NGNG
というより、専門の「煽り屋」の仕業だな。多分。

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

よく考えたら、実際問題、こんな失礼な人間、町歩いて手もいないもんな(笑)。
0491LightCone ◆sSJBc30S5w NGNG
やっぱり1chの西さんの言うように、専門の煽り屋が居るって言う噂は、
本当なんだね。
0492デフォルトの名無しさんNGNG
最近放置気味だったのが、相手にしてもらえてうれしいようだ。
0493デフォルトの名無しさんNGNG
>>485 の言うとおり regex は随分変更を受けると思うが。
標準関数じゃないが、よく使われるので重大だ。

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

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

あとは、標準関数だけじゃなく、
独自のライブラリの関数も軒並みアウトだろうな。
まぁ、想定する文字コードが違うんだから、
１文字１文字処理していくタイプの処理が使いまわせないのは
当然っちゃー当然だけど、
Shift-JIS か EUC かって程度なら
isleadbyte 使ってりゃ何とかなることを考えると UTF-8 は随分面倒だ。
UTF-8 だと日本語は３バイト以上だし、どうやっても誤魔化せないな。
0494デフォルトの名無しさんNGNG
お願いします。これ以上構うと閣下の病状が極端に悪化してしまいますので
このあたりで勘弁してあげてもらえませんでしょうか。。。
0495LightCone ◆sSJBc30S5w NGNG
>>493
>strrchr は使えなくなってしまう。
ASCIIに対しては無修正で使えるので、これも人間側の解釈の問題で、
コンピュータ内部では全く問題が発生しません。

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

>regex は随分変更を受けると思うが。
どのように変更を受けるんでしょうか?(笑)
0496LightCone ◆sSJBc30S5w NGNG
多分、>>493も、UTF8の特性を理解してませんね。

試しに、regexの修正点を上げてみて下さい。
0497デフォルトの名無しさんNGNG
>>496
文字単位でマッチングしないと使い物にならないからじゃないか?
mblenなどをしっかり使っていればあまり問題は出ないはずなのだが
実際のアプリではロケールの初期化すらまともにされていなかったりする
0498LightCone ◆sSJBc30S5w NGNG
>>497
>文字単位でマッチングしないと使い物にならないからじゃないか?
何故?

regexの主たる目的は置換。

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

せっかく、何もしなければ辻褄が合ってるのに、mblen()なんて使うと
破綻します。
0499デフォルトの名無しさんNGNG
単純に、こんな場所で偉ぶっていい気になってる「LightCone ◆sSJBc30S5w」が
可哀相に思えるのは私だけですか？
0500デフォルトの名無しさんNGNG
>>498
この界隈のｺﾃﾊﾝは相手が誤解していると思いこむ傾向が強いように見えるけど
実際は両方が誤解している場合が多そうだよ
この件も問題にしている部分が違うだけ
0501デフォルトの名無しさんNGNG
アホコテさらしage
0502LightCone ◆sSJBc30S5w NGNG
>>500
それは、違いますな。

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

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

はっきり言って、一般人と話すのは苦手です。バカの壁を感じるから。
0503LightCone ◆sSJBc30S5w NGNG
ワテと話していてワテが間違っていると思う人は、
まず、99.99%位、あんたの間違いだと思って大丈夫。

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

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

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

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

アホ
0504LightCone ◆sSJBc30S5w NGNG
はっきり言って、邪魔になるから、そういう人達には勉強などさせずに、
遊ばせてやったらいいんじゃないかと思ってる。
0505デフォルトの名無しさんNGNG
>>503
相手の発言の意図を読む意志がないと指摘しているだけなんだが
無駄な発言をして悪かったよ
0506デフォルトの名無しさんNGNG
>>502
> 何故かというと、ワテと話していて全く誤解が生じない人種と
> あったことがあるからです。

M-x doctorかい？
0507デフォルトの名無しさんNGNG
>>503
＞それに大抵の優秀な人は、深読みするのでそうそう簡単に相手の間違いを
＞断定しない。
＞
＞はっきり言って、間違ったことを行ったときでさえ、それなりに意味の
＞通じる解釈をする人が多い。

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

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

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

ここでやってないでそっちでちゃんとした議論してた方がいいんじゃなかろうか？
老婆心だけどね。
0509LightCone ◆sSJBc30S5w NGNG
>>507
なんか、なんでも基準を曖昧にしたがるようだけど、取りあえず、
悪いけど、そういう人種の人たちには、ワテ自身が確信していることに
対して批判を受けたことは未だにないんだよ。

もう、答えが出てしまって、証明済みで、なんの迷いもない結論に
達しているのに、まだ反論してくる人が居るのは、ネットのみの経験
だから、違いが如実。
0510デフォルトの名無しさんNGNG
発作age!
0511LightCone ◆sSJBc30S5w NGNG
はっきり言うとね、ワテだって、結構間違うことはあるんだよ。
でも、そういう場合、
「そんなことがあったんですかいな!?」
「まいった、見落としてた!!」
「また、アホなミスをしった!!」
と思うわけ。

結局、指摘が的を射てるわけなんですよ、そういう連中は。
0512デフォルトの名無しさんNGNG
宣伝なら業者みたいに黙々とコピペしまくればいいのに。
0513デフォルトの名無しさんNGNG
すいません、コーンたんはこういう人なんです。
すごくやる気があります。それは確かです。
でも、いつも車輪をダウングレードして再発明する人なんです。
しかも、人の指摘や忠告を聞く気はサラサラなく、一方的に放送した挙句、
最後はいつも「おまえらアホだ、俺は正しいのに」で終わるのです。
0514デフォルトの名無しさんNGNG
正規表現の . がある。
これは任意の１文字にマッチングする。
ASCII の１文字は１バイト固定だが、
UTF-8 の１文字は１バイトとは限らない。

sed の書き方になるが、
s/a.a/aa/g
の場合、UTF-8 の "aあa" を置換しようとしても、
ASCII の regex を使うと ''あ' は３バイトなため、マッチしない。
0515デフォルトの名無しさんNGNG
2chは、確かに引きこもりやら、学生やらが多い。（俺も学生です・・・。）
確かにろくに分かっていないことでも、分かっているように言っている人も多いだろう。
ただし問題は時々有り得ないほど知識を持った人が紛れ込んでいること。
引きこもりばっかだと思えば、イケメンやら美人やらが紛れ込んでいるという事実。

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

「車輪の再発明」という言葉を多用して批判する人がいるが、
こいつ自分の言葉に酔っているんだなぁと思うことはある。
0516デフォルトの名無しさんNGNG
で、ﾗｲﾄなんたら氏は そのあり得ないほど知識を持った人だと？
0517デフォルトの名無しさんNGNG
声を大にしていいたい。
日本が戦争に負けたとき、マッカーサーにより
日本は日本語を廃止し、すべて英語になるべきだった。
あまりにくだらないロスがおおすぎる。

当時まさかコンピューターでこんなロスが発生するとは
考えてもいなかったろうが。
すべて英語だったら、モジコードうんぬんなんて
こんなくだらない苦労しなくてすむのに。
0518デフォルトの名無しさんNGNG
暴言ｷﾀｰ
0519らいとこうんNGNG
ワテはOSを作れるほど知識を持った優秀な人間です。
0520LightCone ◆sSJBc30S5w NGNG
>>514
>正規表現の . がある。
>これは任意の１文字にマッチングする。
>ASCII の１文字は１バイト固定だが、
>UTF-8 の１文字は１バイトとは限らない。

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

考えるまでもなく、「文字数」が意味を成している部分はことごとく
駄目になります。今の場合でも、1文字ではなく「任意の文字の列」
でいいなら、「a.*a」で行けると思います。つまり、1「文字」と
いう「文字数を数える行為」に失敗しているのが原因なのですね。
0521デフォルトの名無しさんNGNG
>517
お前は効率のために生きてるのか？
文化には多様性が必要だと思わないのか？

まあ始皇帝も文字と秤を統一したがったけど、
アメリカみたいなインチが主流の国も世の中にはあるからな。
当分ラクにはならんよ。
0522LightCone ◆sSJBc30S5w NGNG
>>514
ついでなので、「.」以外にもありますか?
0523デフォルトの名無しさんNGNG
文字数に関わるもの全て。 {n,m} とか。
0524デフォルトの名無しさんNGNG
あと文字種の考え方自体もunicodeとそれ以外じゃ違う。
perlunicodeとか見たらそれなりの準備されてるのがわかるはずだ。
0525LightCone ◆sSJBc30S5w NGNG
>>523
a{2,5}
とか、
(あ){2,5}
とかなら問題ないのでは?
0526デフォルトの名無しさんNGNG
>525 なんすかその不自然な括弧は？
0527デフォルトの名無しさんNGNG
あまり適当なことを言うと

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

こんな事言われちゃうよｗ
0528LightCone ◆sSJBc30S5w NGNG
>>526
そりゃしゃあない。
0529デフォルトの名無しさんNGNG
そのカッコをつければできるとしても、
そのカッコはつけたくないなぁ。
0530デフォルトの名無しさんNGNG
相手にしすぎると

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

こんな事言われちゃうよｗ
0531デフォルトの名無しさんNGNG
そして雪崩れ込むように

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

こんな事言われちゃうよｗ
0532デフォルトの名無しさんNGNG
>>529
つけたくないなぁと言われても。
0533デフォルトの名無しさんNGNG
論旨は「バイト単位の正規表現モジュールでutf8も問題なく扱える」だったと思うが、
. や [] のことも考えてない「全然詳しくなくて断片的な知識を持った」人だったと。

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

頭冷やしてきなよ。
0534デフォルトの名無しさんNGNG
>>525
つまり世界中のregular expressionを使ったプログラムを修正して回れってこと？
普通の人は、regular expressionのライブラリのほうを修正すると思うが。
0535デフォルトの名無しさんNGNG
LightCone様の足下にも及ばない厨房のくせにいきがってんじゃねーよ。
0536デフォルトの名無しさんNGNG
>>535
何故そこでよく分からない横槍が入るｗ
0537デフォルトの名無しさんNGNG
いや正規表現側で工夫してきたのが今までの日本のperl文化だからなぁ。
どこにでもあるからって理由でperl使ってた人はそこに適応するようにスクリプト側で工夫してたわけ。
それも普通じゃないってこと？


まあLightCornが破綻してるのは既に明らかだが。
0538デフォルトの名無しさんNGNG
>>534
普通の人はOSなんか作らないよ！


とフォローにもならない暴言を吐いてみる
0539デフォルトの名無しさんNGNG
話は変わるけど俺はucs2よりもutf8の方が寿命が長そうだから好きだ。
何度も書き直したくないじゃん？なら可変長のエンコーディングで通した方が将来性がある。
\0があまり登場しないから既存OSとの親和性も悪くないし。
0540デフォルトの名無しさんNGNG
既にucs2対応のOSでしか動かないとか、
システムコールの度にエンコード変換するとか、
そういうのはイヤですわ。
0541デフォルトの名無しさんNGNG
Ruby は正規表現に日本語が使えるよ！
やっぱ使えたほうが便利だよ。
0542デフォルトの名無しさんNGNG
文字コード総合スレあっても良かったんかなぁ。
このスレの主旨って元々はピンポイントに「変換」だし。
0543デフォルトの名無しさんNGNG
ひまわりなら日本語だけで書けるよ！
0544LightCone ◆sSJBc30S5w NGNG
正規表現ルーチンは、UTF8を使っても要修正でした。

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

これで気が済むんでっか?
0545デフォルトの名無しさんNGNG
自分が独りワイワイと騒いどいて何いじけてんの？子供だね。
0546デフォルトの名無しさんNGNG
>>544
こっちはコーンたんが何言おうともはや気にしてないけど。
0547デフォルトの名無しさんNGNG
という訳で終ー了ー。
0548デフォルトの名無しさんNGNG
見てて不憫になってきた。
0549デフォルトの名無しさんNGNG
文字が UTF-8 が表現されるとすると、

strrchr("あいあい", 'あ');

とかいう１文字逆検索ができない。
'あ' は３バイトだし、UTF-8 は最長６バイトだから、
こういう表記自体に問題があるかもな。
文字列の逆検索があれば代用できるんだけど...。

あと、strpbrk, strtok, strspn, strcspn の第二引数も改変が必要。
こういう１文字＝１バイトを仮定されると困る処理は軒並みアウトだ。
0550デフォルトの名無しさんNGNG
ungetc()とかきっと1バイトしか戻せないよ……。
0551デフォルトの名無しさんNGNG
英語圏のプログラムで、設定ファイルを読んだりログを書いたりする程度ならまあ改造なしでも通るけどさ。その程度だよな。
0552デフォルトの名無しさんNGNG
結局書き直しまくりだねぇ
0553デフォルトの名無しさんNGNG
regexはcharacter classとcollation orderも扱うのだが、
何故UTF-8など修正無しでOKだと思ったんだろう。
0554デフォルトの名無しさんNGNG
Perlなんかでも正規表現は漢字1文字が2バイトになるって分かって書いてきたからね。
そういう感覚を前提にしたら、検索で誤マッチしないだけで充分ってことでは。
0555デフォルトの名無しさんNGNG
collationなんてやりだしたら修正どころじゃないな
0556デフォルトの名無しさんNGNG
glibcのregex国際化

http://lc.linux.or.jp/lc2001/papers/dfa-i18n-paper.pdf
http://lc.linux.or.jp/lc2002/papers/hasegawa0918h.pdf
0557デフォルトの名無しさんNGNG
>上述の通り、我々の実装はDFA をベースとしている。
>このため、NFA ベースの実装では避けられないback tracking の問題
>が生じない。
NFAベースでもバックトラック無しの実装をアップしとるのに。
複数の状態変数のパラレルな遷移という例で。
>しかし、Single UnixSpecification[3] などの規格において、
>あるコードポイントに文字が割り当てられているかどう
>かをエンコーディングから独立に調べる方法が用意されていない。
着眼点が悪い。
実は既に正規表現式から必要最小限な集合を抽出する方式がある。
つまり、入力値の範囲ではなく、パターン自体にその答えがある。
オーバーヘッド無し、むしろ従来より高性能な実装は可能。
と、ここで書いてみる。
どうせダウンロードとしてないんだろうな。
従来と違うアプローチの実装例をいくつも出したのに。
0558デフォルトの名無しさんNGNG
>>554
いつの時代のperlの話だよ。.を1byteと見做すなんて。

PCRE is short for Perl Compatible Regular Expressions.
http://www.regular-expressions.info/pcre.html
0559デフォルトの名無しさんNGNG
それから、printf系がUTF-8で問題ないって言う人いるけど、
%c, %lcが全く駄目じゃん。範囲限定で使えないことはないレベル。
0560デフォルトの名無しさんNGNG
複数回 %c すればー、ということじゃない？
改変するとすれば、アドレス渡すようにしないといかんのかな。
そもそも文字リテラルの仕様をどうすればいいんだろうか？
0561デフォルトの名無しさんNGNG
>>558
現状ではこの手のツールの漢字対応って大抵無理やり動かすパッチだけど。
ggrepの日本語対応パッチで比較回数が爆発したりとかするやつあったし。
0562デフォルトの名無しさんNGNG
漢字対応って一体何の話? ここはUnicodeのスレですよ?
>>553の言っていること理解できる?
0563デフォルトの名無しさんNGNG
ああ、すまん、マルチバイト対応だ。打ち間違い。
0564デフォルトの名無しさんNGNG
>>558
一般人にもっとも馴染みの深いプロバイダのおまけCGI環境だと今でも普通だが。
0565デフォルトの名無しさんNGNG
>>559
さすがにそれは言いがかりだろ。
マルチバイトでcharに入らない時点でどう転んでも無理。
wchar_tでwprintf使ってなさいってこった。
0566デフォルトの名無しさんNGNG
>>564
まさかそれが正しいことだと思ってるんじゃなかろうな・・・
0567デフォルトの名無しさんNGNG
>>565
いや、だから>>559は「どう転んでも無理」という話をしているのだが・・・
0568デフォルトの名無しさんNGNG
>>564
その環境100%信頼してバッチジョブで
漢字ファイル名の自動リネームに使うとあぼーん。
Rubyも1.8になるまで不具合連発だったし、今でも警戒してる。
0569デフォルトの名無しさんNGNG
そこはバッドノウハウで回避ですよ。
0570デフォルトの名無しさんNGNG
バッドノウハウ？
ちゃんと再設計すりゃいいじゃんか、アルゴリズムを変えて。
マルチバイトの対応は10年たっても20年たっても不完全。
0571デフォルトの名無しさんNGNG
>>570
おつむの弱い人ですか?
アルゴリズムて 誰がregexライブラリ設計の話してるの…
0572デフォルトの名無しさんNGNG
>>571
551から554,556,558の流れなんだけど。
0573デフォルトの名無しさんNGNG
571はLightCone
0574デフォルトの名無しさんNGNG
彼は名無しで煽らないよ。
0575デフォルトの名無しさんNGNG
いやぁ、ときたま名無しのLightConeがまぎれているような気がするんだが。
なぁ、>>574
0576デフォルトの名無しさんNGNG
>>562
誰も突っ込んでないようだが、
このスレは別に Unicode のスレじゃない。
0577デフォルトの名無しさんNGNG
文字コード総合スレあった方が良かったかな？
僅かな需要はあるのかも。
0578Shift_JISNGNG
私の頃忘れないで…
古い欠点ばかりの女とお思いでしょう。けどわたし…(ﾓｼﾞﾓｼﾞ
0579デフォルトの名無しさんNGNG
UTF8とSJISのスレだと勘違いされてもしかたないタイトルだな。
0580デフォルトの名無しさんNGNG
java厨ならその2つだけでなんとかなるからな
0581デフォルトの名無しさんNGNG
なるかボケ
0582デフォルトの名無しさんNGNG
質問です。
VBscriptでUTF8からSJISに変換という
関数や方法はあるのでしょうか。
0583デフォルトの名無しさんNGNG
>582
ふつーに変換DLLをインポートできねーの？サーバサイドだよね？
0584デフォルトの名無しさんNGNG
できれば、VBscript内で行いたいです。
そのＶＢscriptファイルををダブルクリックすると
指定したUTF8のファイルを読み込み、SJISに変換したものを
別ファイルとして吐き出す
っていうのを作りたいのです。
0585デフォルトの名無しさんNGNG
んー、UTF8からUCS2への変換はふつーに書けるよね。
UCS32からCP932への変換はAPI呼ぶとか自前でテーブル持つとかでできるね
0586デフォルトの名無しさんNGNG
>>585
basp21
の「kconv」を使ってはみたのですが、どうもうまくいきません。
使い方間違っているのでしょうか・・
0587デフォルトの名無しさんNGNG
UTF8 ─自前ルーチン→ UCS2 ─WideCharToMultiByte→ SJIS

UTF8 → UCS2
http://www.linux.or.jp/JM/html/LDP_man-pages/man7/utf-8.7.html
0588デフォルトの名無しさんNGNG
やはりこれってのはスレがたつほどなんで
文字コード知識ある人でも難しい問題なんですか？
basp21でできそうだったんですが・・・できないものですね。
0589デフォルトの名無しさんNGNG
ﾜﾗﾀ
0590デフォルトの名無しさんNGNG
普通の人でもある程度書けるけど正確さを目指すと規格の曖昧さで苦労する問題です。

588はもーちょっと修行すれ。もしくはちゃんとコードとエラー内容を出して質問すれ。
0591デフォルトの名無しさんNGNG
>>587
WideCharToMultiByte使うなら、Win95での動作を想定しなくてよければ
MultiByteToWideCharでUTF-8＞UCS-2変換すればいいと思うが。
0592デフォルトの名無しさんNGNG
MSLU入れてもその辺アップデートされないの？
0593デフォルトの名無しさんNGNG
>>592
unicow.dll(だっけ?)をリンクしているアプリからしか使えない。
VBScriptからという条件じゃ無理
0594デフォルトの名無しさんNGNG
すみません、全くの初心者なのですが、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 $_;
}
という風なやり方も試してみましたが、結果は同じでした。
どこがいけないのでしょうか？
どなたか詳しい方、よろしくお願いします。
0595デフォルトの名無しさんNGNG
perlは門外漢なんだが、入力と出力が同じファイル名でいいの？
ファイルが空になるような。
0596デフォルトの名無しさんNGNG
windowsだと確実にダメなはず。出力を開いた時点でファイルサイズが０になる。
0597デフォルトの名無しさんNGNG
結局のところ
UTF8→ShiftSJIS
直変換は無理ってこと？
0598デフォルトの名無しさんNGNG
BASP使っては無理？
0599デフォルトの名無しさんNGNG
結局変換コード自前で書いたとしても、
UTF8 から UCS2 のコードを求めて
それを SJIS に変換するってコードを書くことになるしな。
まぁ、１文字１文字変換した方が
余計なバッファが要らない分効率はいいかとは思うけど、
変換に MultiByteToWideChar/WideCharToMultiByte を使うと
呼び出しコストが高そうなので、全部自前で組まないと意味が無いかも。

ただ、使用言語が VBScript なので、ひょっとしたらひょっとするかも？
0600デフォルトの名無しさんNGNG
ShiftSJIS 。

ムリでもなんでもねーよ。てめーがヘタなだけだ
0601594NGNG
594です。
無理なのでしょうか？できるのでしょうか？
perlのスレとかに行ったほうがわかるのでしょうか？
0602デフォルトの名無しさんNGNG
>601 inとoutで開くファイル名変えれ。それだけだ。
0603デフォルトの名無しさんNGNG
簡単に変換する方法ないですか？
0604デフォルトの名無しさんNGNG
つかお前誰だ
0605デフォルトの名無しさんNGNG
http://www.vector.co.jp/soft/win95/util/se314832.html
これを元に、なんとかできないかな
0606デフォルトの名無しさんNGNG
パイナリファイル
0607デフォルトの名無しさんNGNG
JISの半角カナなんだけどさ
ESCJ と shift-out と 7bit が続く場合と ESC I の後に 7bitが続く場合は ASCII扱いでOK?
7bitの場合で他（というとESC I +shift-out+7bitのことだが）はX201扱いでOK?
0608デフォルトの名無しさんNGNG
やや意味不明。ESC J って、ESC ( J のことか？

そうだとして、SO の後は G1 に何が入っているかによる。
日本ではX0202の右側を入れることが多いかな。

ESC ( I の後は X0201右側が G0 に designate されているから、
7bitならX0201右側しかない。

「7bitの場合で他」って、なんで一通りに決まる？
ESC ( I SO の後は、最初の場合と同じで G1 に何が入っているかによる。
0609デフォルトの名無しさんNGNG
↑のX0202はX0201のことな
0610デフォルトの名無しさんNGNG
JIS の半角カナって、M$ の仕様拡張じゃなかった？
0611デフォルトの名無しさんNGNG
おまえはこのスレにいる資格なし
0612デフォルトの名無しさんNGNG
いまどきこんなDQNエンコード使ってるほうが悪いんだよ
0613デフォルトの名無しさんNGNG
>>608
X0201右側って何? 片仮名用図形文字集合のこと?
0614デフォルトの名無しさんNGNG
> ESC ( I の後は X0201右側が G0 に designate されているから、
> 7bitならX0201右側しかない。
これ以前にG1～G3がGLに呼び出されていれば
そこに何が入っているかによる。
ESC 2/8 FでG0に何が指示されようと関係ない。
(一意な符号化が要求されている場合は使用可能な文字が
変わるかもしれないけど)
0615デフォルトの名無しさんNGNG
>>614
> これ以前にG1～G3がGLに呼び出されていれば
> そこに何が入っているかによる。
そうだった。SOとかLS2/LS3が先行してる場合があるか。

>>613
そのつもり。
0616デフォルトの名無しさんNGNG
>>615
7bitで「右側」という表現に違和感を感じたので。
確かにX0201に規定されている8ビット符号は片仮名をGRに
呼び出すものしかないけど
0617デフォルトの名無しさんNGNG
>612 悪いな。IRC関連なんだよ
0618デフォルトの名無しさんNGNG
IRCの日本語文字コードってISO-2022-JPじゃなかったっけ?
0619デフォルトの名無しさんNGNG
age
0620デフォルトの名無しさんNGNG
BOMありUTF-8などというばかげたものが禁止されていないのはなぜですか？
0621デフォルトの名無しさんNGNG
>>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等でも
同様ですが
0622デフォルトの名無しさんNGNG
>>620
Byte Order Mark の何たるかをご存知でない
お間抜けちゃんがこの業界を仕切っているからでぬるぽ。
0623デフォルトの名無しさんNGNG
いきなりレベルの低い話になりますが、～問題は皆どうやって
回避してますか？
0624デフォルトの名無しさんNGNG
~→～のこと?
0625デフォルトの名無しさんNGNG
WAVE DASH(～)が\u301cにマッピングされる問題でしょ。
0626625NGNG
失礼、「U+301C」の方が良いですね。
0627デフォルトの名無しさんNGNG
iconvもglibcも使うときはSJISじゃなくてCP932を指定してる。
emacsもCP932変換テーブルを作って、さらにutf-8 decode部分を書き換え。

実際どうなんだろう、SJISが必要な人って、どれぐらいいるんだろう？
大部分の人はCP932が欲しいわけで、SJISじゃないと思うのだけど、
そうでもない？
0628デフォルトの名無しさんNGNG
>>621
> でも付けて違反とはISO 10646にもRFCにも規定はないですね
どういう場合に付けてはいけないか(というか付いてたときZWNBSP
ではなくBOMであると解釈してはいけないか)はRFC 3629で
明確化された
0629デフォルトの名無しさんNGNG
>>627
Unicode→SJISで、「どっちが来てもいいように」対応することは可能だけど
SJIS→Unicodeだと、どっちにするか決めないといけない
という問題がありますね。
それと、OracleのNLSのような、ハック不可能な領域だとかなりどうしようも
ない気が。

そういえば、JavaはもうShift_JISがWINDOWS-31JじゃなくてSJISのエイリアス
になってるんでしたっけ。これ、困る人が多いんじゃないのかなあ。
0630デフォルトの名無しさんNGNG
> Unicode→SJISで、「どっちが来てもいいように」対応することは可能だけど
U+005CとかU+007Eが来たときどう変換する?
Shift_JISがX0208の附属書1どおりじゃなくて
1バイト部分はASCIIであるとみなせば対応は可能だけど
0631デフォルトの名無しさんNGNG
>>630
実際問題として、ASCIIと見なさないと、使い物にならないでしょう。
\にどういうグリフが当てられていようと、日本人もそれをエスケープ記号や
パスのデリミタとして(バックスラッシュと同じ意味で)使っているんだから、
他のコードポイント割り当てたら、はっきり言って実用上はお話にならない。

従来通りFontの問題として対応するのが「今のところは」現実的じゃないの。
0632デフォルトの名無しさんNGNG
エスケープ記号はともかくパスのデリミタはWindowsの場合だから
それは単にエンコーディングとしてCP932を想定しているというだけの
話だと思うんだけど。
実際Appleの変換表は円記号をU+00A5に割り当てるし
0633デフォルトの名無しさんNGNG
そのエスケープ記号が大問題だと思うが。
世の多くのプログラミング言語だのTeXだのシェルだのにおいて
メタキャラクタとして使われてるんだから。既存のソースの類が突然にして
コンパイル不能な屑の山になるでしょ。

無論DOS, Windowsユーザにとっちゃパス区切りであることの方が
さらに問題だが。
0634デフォルトの名無しさんNGNG
>>631
そりゃ、プログラマ至上主義だね。
普通の文書に半角円記号使ってた人は困る。
0635デフォルトの名無しさんNGNG
>>634
そしてTerminal上でバックスラッシュと円記号の混乱でうめき、SafariでWebの円記号がバックスラ
ッシュになってもがくOSXユーザが湧いてでてくると。
0636デフォルトの名無しさんNGNG
>>632
Mac OS Xだと、Shift JISのprogramを、
UTF-8で保存して、REVERSE SOLIDUS(0x5c)のつもりが、
YEN SIGN(0xa5)になって悩んでいる学生さんが、
既にいらっしゃいますよ。

Terminal.appで、YEN SIGNが出力されていても、(\nとか)
教科書にYEN SIGN書いてあんだもん、初級の人はわけが分からないよね。
0637デフォルトの名無しさんNGNG
Safariの ~ が ～ になっちゃうよ問題とか。
0638デフォルトの名無しさんNGNG
「どっちが来てもいいように」対応するというのも
そんな簡単じゃない。
たとえばPARALLEL TOとDOUBLE VERTICAL LINEしか違わない
名前のファイルが同じディレクトリにあると、どちらか片方しか
開けないとかどっちが開かれるかわからないとか、
どっちが作成されるか分からないとか。
そもそも両者を同一視したいというのは日本だけの都合であって、
たとえばGBKには両方とも存在するから勝手に同一視されたら
多分困る。
0639デフォルトの名無しさんNGNG
<item1 name="セーター" price="\500" image="c:\image\item1.jpg">
みたいなのをきちんと utf-8 にする処理は多言語対応では難しいよね・・・
0640デフォルトの名無しさんNGNG
>>639
> <item1 name="セーター" price="\500" image="c:\image\item1.jpg">

と記述するcoding systemがyenとbackslashを区別できていれば問題ないし、
区別できていないのなら、それはコード変換とは別ドメインの問題だろ。
0641デフォルトの名無しさんNGNG
見た感じXMLっぽいがそれなら
price="&yen;500"
と書くことで曖昧さがなくなる
0642デフォルトの名無しさんNGNG
>>640
Shift_JISは問題ないの?
0643デフォルトの名無しさんNGNG
>>641
xml 的には後半の \ は ¥ にするや否や、というような話。スレ違いだけど。

>>640
元のコードが Shift_JIS の場合、どんな風に変換されるべき？
0644デフォルトの名無しさんNGNG
>>643
後半はしたら駄目に決まってる
0645デフォルトの名無しさんNGNG
ところがShift JISで書いた場合は、両方でOKなわけだ。
0646デフォルトの名無しさんNGNG
両方HALFWIDTH YEN SIGNでOKなわけだ。
0647デフォルトの名無しさんNGNG
>>645
意味がわからん
「両方」って何と何のことで何が「OK」なの?
>>646
HALFWIDTH YEN SIGNなんてものはない
ただのYEN SIGNならある
0648デフォルトの名無しさんNGNG
LightConeは?
0649デフォルトの名無しさんNGNG
>>648
LightCone乙
0650デフォルトの名無しさんNGNG
書き込みがないな。
またLightConeが来てくれないかな。
0651デフォルトの名無しさんNGNG
iso-8859-22って、いわゆるなに？

iso-8859-1って、いわゆるLatin1でいいの？
0652デフォルトの名無しさんNGNG
8859-22 なんてあったのか？
16までなら聞いたことがあるが。
0653デフォルトの名無しさんNGNG
EZ端末からPOST形式でフォームをサブミットすると
x-up-destcharset=17
というのが勝手に送られるのですが、
これって何のためのものでしょうか？
0654デフォルトの名無しさんNGNG
で、それがなんの関係があると？
0655デフォルトの名無しさんNGNG
>>654
誤爆?
0656デフォルトの名無しさんNGNG
>>655
残念。ちゃんとした回答。
0657デフォルトの名無しさんNGNG
>>656
>>653への回答か? スレ違いだと言いたいのか?
0658デフォルトの名無しさんNGNG
>>220 さんのページってどこですか？
0659デフォルトの名無しさんNGNG
EUC補助漢字の判定 でぐぐってみたらわかりました。
使える文字コード判定ってあんまり情報ないので助かります
0660デフォルトの名無しさんNGNG
>>399

UCS4で正規化すりゃ万事解決。

32ビットコードはMuleとかで先例もあるし。
0661デフォルトの名無しさんNGNG
wcschrでヒットしたその位置は何文字目? という問いに
簡単に答えられない点が問題。X0208の範囲に限定するなら
そうでもないがそれならそもそも4バイトもいらん
正規化がUnicode Normalizationのことを指してるなら
UTF-8の文字数を先頭から数えても大して変わらんような…
0662デフォルトの名無しさんNGNG
>>660
遅レス乙!
0663デフォルトの名無しさんNGNG
>>660
コードポイントと文字は１対１対応ではない。
NFCで正規化しても複数コードポイントの組合せで
１文字を表すケースはいくらでもある。
0664デフォルトの名無しさんNGNG
たしかに↓とか読んでると気が遠くなってくるな。
http://www.horagai.com/www/moji/devnag.htm

アラビア語や上の例みたいに文字を分かち書きしない言語では
「一文字」っていう単位がそもそもそれほど明確じゃないのかも。

日本語は「単語」を分かち書きしないけど
時枝文法とか文法のとらえ方次第で「単語」も変わるしそもそも
日本人は単語の区切りなんてふだん意識してないみたいな感じか。
（助詞とか）

素人なので間抜けな事いってるかも知れないが。
0665デフォルトの名無しさんNGNG
>>663
というかそれはまさに>>399で言ってることそのものなわけで
文盲にマジレスしても無駄かと
0666デフォルトの名無しさんNGNG
ｐｃ関係詳しい方！
ぜひこの暗号解けないものでしょうか！？

325argf493rdtr521styh075artg625agfa113ller041fsre.2122ffj7343qer7813fda
0667デフォルトの名無しさんNGNG
それをこのスレにもってくる神経を疑う
0668デフォルトの名無しさんNGNG
>>667
その謎を解くのだ。
0669デフォルトの名無しさんNGNG
>>666
↓↓US-ASCII復号による解読結果です↓↓
325argf493rdtr521styh075artg625agfa113ller041fsre.2122ffj7343qer7813fda
0670デフォルトの名無しさんNGNG
325|argf
493|rdtr
521|styh
075|artg
625|agfa
113|ller
041|fsre
.
2122|ffj
7343|qer
7813|fda
0671デフォルトの名無しさんNGNG
BASE64?
0672デフォルトの名無しさんNGNG
英大文字をまったく含まないというのは
BASE64にしては不自然すぎるな
0673デフォルトの名無しさんNGNG
JISを元にした文字コードとunicodeとの変換表が複数ある状況は
なんとかならんのかね。それが正しかろうがなんだろうがとにかく
統一されてさえいれば楽に使えるのに、バラバラだからいらぬ変換
の手間がかかってわけわからん状況に。勘弁してくれよう。
0674デフォルトの名無しさんNGNG
なんともならんでしょうね。
0675デフォルトの名無しさんNGNG
JISは対応が存在するだけまだマシなほうですよ
Big5やKPS9566なんてそもそも変換できない場合があるし
0676デフォルトの名無しさんNGNG
まあ、応用によって変換表が違うのは当然って文字の組み合わせもあるでしょう。
*→＊,×, ※など。あまりいい例じゃないからもっといいのきぼん↓
0677デフォルトの名無しさんNGNG
printf("値段は \\%dです\n", Nedan);
\\は&yen;(¥)1文字に変換されるのが理想だし、\nはバックスラッシュとnに変換してくれないと困るし。
0678デフォルトの名無しさんNGNG
もう、面倒だから\記号使うのやめよう。
printf("値段は %d円です\n", Nedan);
で良いじゃないか。

ごたごたに巻き込まれたくないPGより。
0679デフォルトの名無しさんNGNG
￥ でいいよ
0680デフォルトの名無しさんNGNG
age
0681デフォルトの名無しさんNGNG
>>679
I/Oライブラリに勝手に\に変換されたり…
最近2chでも~→～があるみたいだし。
0682デフォルトの名無しさんNGNG
文字のことは中国人に任せときゃいいんだよ
漢字のほんの一部を借りて使ってるだけの日本人なんかに何が出来るんだ
0683デフォルトの名無しさんNGNG
>>682
マッカーサーに従って、日本語で文章を書くのを止める、とか？
0684デフォルトの名無しさんNGNG
>>682
アルファベットも中国人任せか?
0685デフォルトの名無しさんNGNG
>>681
~→～はSafariの悪戯だろ
0686デフォルトの名無しさんNGNG
SJIS、EUC、JIS、UTF-8を判別するアルゴリズムを紹介しているページってどっかある？
ttp://kasumi.sakura.ne.jp/~gm/gpj/dev/tips/other/kanji.shtml
を参考にしているんだけどイマイチはっきりしないところがあるので…
0687デフォルトの名無しさんNGNG
イマイチはっきりしないところを書いてくれないとはっきりしない。
0688デフォルトの名無しさんNGNG
age
0689デフォルトの名無しさんNGNG
ｸﾞｸﾞﾙさんのキャッシュは日本語サイトの \ を＼にするから激しく困る(`Д´)

ｸﾞｸﾞﾙさんのﾃﾞｶﾁﾝｺ！ヽ(｀Д´)ノ世界最早男！
0690686NGNG
遅レスｽﾏｿ
>>687
具体的には判定箇所が具体的に書かれていないところ

例：
> 0x80 <-> 0xA0であるならばSJIS
　SJISと言うことは第1バイトか？
> 0xA1 <-> 0xDFが出た場合はSJIS半角カナ・EUC全角かな・カナの強い可能性
　これも第1バイト？
> 0xA1 <-> 0xFEの場合はEUCの強い可能性で0xFD・0xFEの場合はEUC(確定)
　第1バイトと第2バイトの両方？
0691デフォルトの名無しさんNGNG
文字コード判別・変換クラスてのがあるけど
ttp://kasumi.sakura.ne.jp/~gm/gpj/dev/tips/net/txtenc.shtml
0692デフォルトの名無しさんNGNG
>>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)は仕方
ないから＼になる、ということではないかな。

不整合に見えるけど、単に時間差があるだけでしばらく待ってると保存時にも変
換されたものでデータが入れ替わって揃うのかも。それでもページが更新されな
いとキャッシュデータが書き換わらない可能性はあるが。
0693デフォルトの名無しさんNGNG
Perl6だとYEN SIGN(U+00A5)に演算子として意味を割り当てるので、
扱いとしては完全にREVERSE SOLIDUSと別にせざるを得ないらしいじゃん。
日本語Windowsユーザはどうするのか。
本当はUnicodeに移行してればこんなことで悩まなくなってるはずなんだが、
問題解決に絞るべき知恵のなかったMSKKが
「0x5cは見掛けYEN SIGN、意味は場合によって世界標準Unicodeにおける
U+005C(REVERSE SOLIDUS)かYEN SIGN」
なんつー考えナシUnicodeを始めてしまったもんだから、
21世紀になっても悩みがつきないわけだなあこれが。
0694デフォルトの名無しさんNGNG
そこでUnicodeの再設計ですよ
0695デフォルトの名無しさんNGNG
>>693
MS の CP932 では EUC-JP と同様に 0x5C は Unicode の \u005C にマッピングされてるわけで、
MS 的には CP932 <-> Unicode の相互変換で違う文字になるなんてことは無いはず。
Shift_JIS なんてやめて、CP932 に移行すべき。

しかしC# の XMLWriter で CP932 で書き出すと、encoding="Shift_JIS" になる orz...
0696デフォルトの名無しさんNGNG
0x5cは、全員バックスラッシュにすれば済む話じゃん。
￥マークは全角で使用して、半角の￥は存在しないと思えば良い。
それよりも、日本語Windowsで0x5cをバックスラッシュで表示してくれないのが困る。
0697デフォルトの名無しさんNGNG
勉強になりそうなので読んでいますが、
CP932? REVERSE SOLIDUS?…(´･ω･｀) もうついていけません…。

たとえばWindows環境では、フォントによって\がバックスラッシュで
表示されたり \のままだったりしますが、これというのはつまり
フォントごとに、その文字コードに対応する文字イメージが
異なっているというだけなんでしょうか。それともハードウェアの
レベルで何かが起こっているんでしょうか。

文字コードと、実際に画面に表示される文字イメージが
どこでどう関連づけられているのか、いまひとつ分かりません。
0698デフォルトの名無しさんNGNG
>>697
文字イメージが違うだけ。0x5cは0x5cのまま何も変わっていない。
フォントを書き換えれば、バックスラッシュにできるんだが、改造はしたくない。
マイクロソフトが強制的にバックスラッシュにしてくれればありがたいのだが。
0699デフォルトの名無しさんNGNG
>>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がパス区切り文字に使っていた文字が重なってしまった不幸な偶然を恨むしかない。
0700デフォルトの名無しさんNGNG
まあそれでも「～」あたりの混乱よりはマシだな。
0701697NGNG
>>698-699
なるほど、だんだん分かってきました。
もう少し分からないんですが、たとえばマルチバイトモードから
Unicodeモードに切り替えてコンパイル・実行したとすると、
文字コード自体は変わってしまっても見た目は(概ね?)同じ
ですよね。
同じフォントから同じ文字イメージを取り出すには、この
文字コードの違いを吸収する仕組みが必要だと思うのですが、
どのようになっているのでしょうか。

文字セットごとに「文字イメージ位置検索テーブル」のような
ものが用意されていて、文字コードからフォント内の文字イメージ
位置を検索できるようになっているのではと想像してみたのですが
実際のところはどうなっているのでしょうか。
0702デフォルトの名無しさんNGNG
>>701
最近のGUIベースのOSだと、フォントセットは大抵 Unicode でのコードポイントにたいして
タイプフェイスが割り当てられています。そうして文字コードから Unicode のコードポイントに
変換する仕組みも別途存在します。「どのようになっている」かは、OSやウィンドウシステムに
よって異なります。
0703697NGNG
>>702
なるほど、フォント内の文字の並びが何に従っているのか次に
質問しようと思っていたところなんですが、Unicode に合わせて
あるんですね。その上で、文字コードをUnicode の文字コードに
変換する仕組みが備わっている(仕組みは環境ごとに異なる)という
ことなんですね。納得致しました。
ご回答ありがとうございました。
0704デフォルトの名無しさんNGNG
>>703
欧文フォントなんかだと、Unicode ではなく ISO 8859-1 (Latin-1) で入ってたりするものもある。
0705686NGNG
>>691
できました。thx
サンプルコードあったのか…気が付かなかった…il||li ○|￣|＿
0706デフォルトの名無しさんNGNG
>>697
http://euc.jp/i18n/ucsnote.ja.html読めばあ?
0707697NGNG
>>704
Unicode とは並び方の異なるものもあるんですね。そのような
フォントの場合はどう扱っているのでしょう。Unicode のコード
ポイントに変換する方法では上手くいきませんよね…。使用する
フォントがどんな文字セットのコードポイントに一致しているか
という情報も、どこからか取り出しているのでしょうか。

>>706
ありがとうございます。
記号の読み方などバッチリ出てますね^^;
内容的にはまだよく分からない部分もありますが、
とりあえず最後まで読みすすめてみようと思います。
0708706NGNG
>>707
そんな難しいことは書いてないです。
良く書けているページなので何回も読んでみてください。
先入観を取り払えば、理解できるはずです。

ちなみに>>698は間違っているのでスルーしてください。
文字実体、グリフという概念を理解してない。
0709デフォルトの名無しさんNGNG
JIS X201はもはや業界のお荷物でしかない
0710デフォルトの名無しさんNGNG
和文フォントはWinの文字コード表でみると円記号の上に
ツールチップで"REVERSE SOLIDUS"と出るのが激しく間抜けだ。

せめてREVERSE SOLIDUSのグリフをどこかに突っ込んでおいてくれよう。
0711デフォルトの名無しさんNGNG
JIS X 0208的には1区32点(＼)がREVERSE SOLIDUSなんだけど、またもやMSが(略
0712デフォルトの名無しさんNGNG
>>711
Microsoft のは CodePage 932 っていう、彼らの定義したコーディングシステムなわけで、
文句言うのはよいけど「JISと違うやん」ってのは文句にすらなってないような･･･

日本のコンピュータ言語関連の書籍でも、ソースコードのREVERSE SOLIDUSを \ で
印字してるものが結構あるよね。あれってどういう習慣から来ているんだろう・・・
0713デフォルトの名無しさんNGNG
PC-9801
0714デフォルトの名無しさんNGNG
>>712
X0201の影響じゃ？てかISO/IEC646だかであのあたりは国毎に勝手にしる！ってのが未だに尾を引いてるだけかと。

0715デフォルトの名無しさんNGNG
>>712
> 日本のコンピュータ言語関連の書籍でも、ソースコードのREVERSE SOLIDUSを \ で
> 印字してるものが結構あるよね。あれってどういう習慣から来ているんだろう・・・

凄い文章だな。
0716デフォルトの名無しさんNGNG
>>712
でもさー、JISとCP932って相互変換できるのに、対応する文字が
それぞれ別のunicodeへマッピングされるのってすごい使いにくい
んだよね。なんとかしてくれよ...
0717デフォルトの名無しさんNGNG
>>712
そう思うんならMS明朝の0x5cのグリフが円記号なのは納得いかん。
0718デフォルトの名無しさんNGNG
ISO-2022-JPとEUC-jpとShift JIS(JISに載ってるやつ)とCP932は含む文字の集合が違うのに、
たいていの人はそれらの間で1対1の変換が出来ると思っている。
また、文字コード変換{ライブラリ, プログラム}もそうであるように見せかけている。この辺が混乱の元だろう。
「危ない文字(コード)は使わない」ということをリテラシーとして教えるべきだ。
0719デフォルトの名無しさんNGNG
「危ない文字(コード)は使わない」ってことなら
危ない文字(コード)を表にでもして教えてよ。（出来れば理由も）
あとお勧めの変換ソフトがあるなら教えて！
0720デフォルトの名無しさんNGNG
その環境で、何の文字コードを使うかは何処で決定されるのでしょうか？
windos環境とunix環境のそれぞれの決定のされかたを簡単でいいんで教えてください。
0721デフォルトの名無しさんNGNG
man locale
0722デフォルトの名無しさんNGNG
>>719
論外:
・いわゆる環境依存文字(丸付き数字など)
・JIS X 0201 片仮名(いわゆる半角カタカナ)
・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う

避けた方が無難:
・JIS X 0208でASCIIと同じ名前のもの(いわゆる全角英数記号類。疑問符とか)
・和字間隔(いわゆる全角スペース)
・JIS X 0208のYEN SIGN(漢字の「円」を使う)
0723デフォルトの名無しさんNGNG
>>722
しかしunicodeはさむと従来は何の問題もなく同じだった「～」なんかも
違う文字になっちゃうからな～。
0724デフォルトの名無しさんNGNG
ちょっと話題からずれてしまうかもしれませんが
teknap http://masternap.org/teknap/ で
UTF-8 のファイル名を Shift-JIS に変換して共有したいのですが
ソースコードへのパッチの当て方が分かるかたいませんか。
0725デフォルトの名無しさんNGNG
age
0726デフォルトの名無しさんNGNG
age
0727デフォルトの名無しさんNGNG
関係ないけど、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によると、この文章で使っている、いわゆる全角丸括弧や全角疑問符も
いけないことになってしまいますね。
いわゆる半角丸括弧や半角疑問符は幅が詰まりすぎているから使いたくないんですけどね。
0728デフォルトの名無しさんNGNG
何度も書くようだけど、このままWindowsにJIS X 0213:2004が採用されたら、
辻さんや樋口さんや榊原さんの大半が困ってしまう事態が起きるということは
もっと世間に認知されていてもよいと思うんですけどね。

「字体が変わる」のは防げないにしても（防げるに越したことはないが）、
「以前の字体が（事実上）出せない」のは固有名詞にも配慮していないので、
固有名詞にも対応すべきである工業規格としてまずいと思います。（※1）

（※1）この点で、「現に地名・人名などの固有名詞に用いられている字体にまで
及ぶものでもない」としている表外漢字字体表とは軌を異にします。
なお、表外漢字字体表では「現に」と表記しているとおり、表外漢字字体表発表以降の
地名・人名は表外漢字字体表に従うことを要望している（そして、実際に表外漢字字体表に
沿う形で人名用漢字が追加された）のですが、なんと市町村合併で最近誕生した
「葛城市」（奈良県）と「薩摩川内市」（鹿児島県）はそれに従っていません
（官報に記載された「葛」と「薩」の字体が、表外漢字字体表の印刷標準字体と異なっている）。

幸い、1面1区から1面13区までの間に40字弱の保留領域（ただし非漢字領域ですが）が
ありますので、ここに「互換用漢字」としてJIS X 0208:1997の例示字体どおりの
「辻」「樋」「榊」などを追加するのもよいでしょう。あと、「葛」「薩」もですね。
できればJIS X 0208:1997の例示字体ではなく、JIS X 0213:2004で変更されたほうの字体
（つまり、表外漢字字体表の印刷標準字体）のほうを「互換用漢字」にしたいのですが、
再々変更は避けたいので、いかんともしがたいところです。
0729デフォルトの名無しさんNGNG
>>727
詰まりすぎでないフォントを使えばいいのでは?
0730デフォルトの名無しさんNGNG
もうリッチな環境なんだからUTF-32で
CJKとか使えなすぎ
0731デフォルトの名無しさんNGNG
>>727
> 一足飛びにUTF-7に移行するような気もしないでもないのですが、
ぷっ
+MHcwYw-
0732デフォルトの名無しさんNGNG
>>694
そんなことしたら新旧混在して混乱に拍車を掛けますがな
0733デフォルトの名無しさんNGNG
>・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う
えーとすみません
煽りじゃ無しにこの一文の意味が本気で分かりません
0734デフォルトの名無しさんNGNG
>>727
確か UTF-7 は過渡期の産物で、MIME を併用した UTF-8 が本命じゃなかったけ？
0735デフォルトの名無しさんNGNG
主にメールのために考えられたはずだけど、
現実的にはUTF-8 + base64が多いな。無用の長物だな。
0736デフォルトの名無しさんNGNG
>>712
JIS C (JIS X 3010)に円記号を使っていいと書いてる
0737デフォルトの名無しさんNGNG
>>728
ケチケチせずに半角カナの領域削ればいい。
どうせWindowsは採用する気ないんだから
ISO/IEC 10646への追加要求のソースになってくれさえすれば
誰も実装しなくても問題はない
0738デフォルトの名無しさんNGNG
>>727
> 1段落目
なりません。

> P.S.
これについては >>729 の人が書いている通り。

>>733
値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。
0739デフォルトの名無しさんNGNG
そもそもJIS X 2013:2004に完全対応なら符号化表現の名称は
ISO-2022-JP-2004でなくてはならんし。
これはIANAに登録されていないのでメールで使ってはならない。
0740デフォルトの名無しさんNGNG
コピペしたら間違いまでコピペしてしまったorz
JIS X 0213:2004ね
0741デフォルトの名無しさんNGNG
>>722
>・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う
>>733
> えーとすみません
> 煽りじゃ無しにこの一文の意味が本気で分かりません
>>738
> 値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。

「JIS X 0201のREVERSE SOLIDUS」？？？
「CP932で(略)REVERSE SOLIDUS」？？？
0742デフォルトの名無しさんNGNG
>>741
後者。
0743デフォルトの名無しさんNGNG
・CP932で0x5cを円記号として扱う

って事ですか?
0744デフォルトの名無しさんNGNG
>>743
そうです。
0745デフォルトの名無しさんNGNG
> 値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。
ひどい目にあったところが実際にあるんでしょうか？
国内のインターネット通販やってる所って遭遇する可能性が．．．
0746デフォルトの名無しさんNGNG
Googleの検索結果上ではよく文字化けしてる
0747デフォルトの名無しさんNGNG
>>745
「ウリの環境だとウォンと書いてるニダ、それ以上は払わないニダ」
0748デフォルトの名無しさんNGNG
韓国語版WindowsのU+005CにはWON SIGNのグリフが入ってるから
円記号問題と似たようなことが起こるらしいな
0749デフォルトの名無しさんNGNG
>>747
日本側が中小だと実際にそれでごねて契約の十分の一しか支払われなかった
ケースもあるらしい。
0750デフォルトの名無しさんNGNG
>>749
嘘つきは泥棒の始まりか
0751デフォルトの名無しさんNGNG
>>728
「市町村合併 字体」とかでぐぐると分かるけど
>当用漢字表以外の漢字についても、当用漢字字体表の字体に準じた
>字体を用いてもよい。
みたいですね。この時点ですでに表外漢字字体表とは
食い違っているという…
0752デフォルトの名無しさんNGNG
>>751
字体表は答申どまりで内閣告示にならなかったからな。
朝日新聞とかにも無視されてるし（内閣告示だったら無視できなかったはず）。
字体表を尊重しているのなんて、
国語審議会のメンバーを送り込まれたJIS X 0213:2004だけじゃねえか。
0753デフォルトの名無しさんNGNG
人名用漢字部会も。
「芦」はなぜか簡易慣用字体のほうが採用されたけど。
0754デフォルトの名無しさんNGNG
ひょろっと書いた自作のユニコードライブラリを
鬼門・合成に対応させようか迷っとります。
コンパクトな構造が崩れる悪寒。そこまでサポートする意味あるのか…。

欧米人の心境が１㍉㍑くらいわかったような気分す。
0755デフォルトの名無しさんNGNG
>>754
ISO 10646-1は全てのシステムが合字処理を実装することを要求
していないよ。実装レベル分けされていて、合字のない実装は
Level-1に分類される。
0756デフォルトの名無しさんNGNG
ここで質問して良いのか分かりませんが、
Unicodeでのエスケープシーケンス一覧はどこかにありますか？
0757デフォルトの名無しさんNGNG
Unicodeはエスケープシーケンスなんか使いませんが
0758デフォルトの名無しさんNGNG
単にunicodeの一覧の話か？
0759デフォルトの名無しさんNGNG
UTF-8 指示用の「ESC % G (1B 25 47)」というのが規定されてはいる。
X の Compound Text で使われているようだ。
0760デフォルトの名無しさんNGNG
とりあえずここにまとめられてるのでぜんぶだとおもう。

http://www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm
0761デフォルトの名無しさんNGNG
JIS/SJIS/EUCから変換されたunicodeテキストがあります。
ただし変換表がどれか(MS系かJIS系かとか)わかりません。

これを適当に自動判別して元のJIS/SJIS/EUCに戻せるような
ライブラリってないですかね? perlのモジュールになってる
と楽なんですけど。
0762デフォルトの名無しさんNGNG
JIS(っていうかISO-2022-JPだよね？)だったのか、EUC-JPだったのか、
あるいはShift_JISだったのか、を判別したいんですか？ だったら無理。

変換表がどっちなのかを判別したいんですか？
だったらそれなりに可能だろうけど、既存のライブラリはたぶんない。
わりと簡単に作れるので、勉強だと思ってガンバレ。
0763デフォルトの名無しさんNGNG
>>762
変換表をどっちか判別したいだけです。紛らわしい書き方ですまん。
同じ変換表で変換されたものの元がJISかEUCかを判定したいわけでは
もちろんありません(全く同じ結果になるからできるわけないし(笑))。

で、既存のライブラリはなさげですか。どっちかの変換でしか現れない
文字に着目して判定できるとは思うのですが、きちんと漏れなく調べる
のが面倒なのであればいいなと期待していたのですが。
0764デフォルトの名無しさんNGNG
「XML日本語プロファイル」がいちおう既存の変換表を網羅しているはず
だから(Apple除く)それを参考にして作れ
0765デフォルトの名無しさんNGNG
0766デフォルトの名無しさんNGNG
質問いいですか

OS Windows2000 Japanese version(韓国語言語インストール済み)
開発言語 VB6.0

テキストファイルを読み込んでその内容をテキストボックスに出力させるプログラムをつくったのですが
文字化けしてしまいます。

テキストファイルには、韓国語と日本語がはいっています。
テキストファイルはUnicode形式で保存しています。
これをバイナリ－データとして開いてそれぞれ変数に代入して
テキストボックスに出力しています。

Unicode形式なのに韓国語が文字化けしてしまうのです。
どうしてでしょうか？
0767デフォルトの名無しさんNGNG
代入しているコードを貼らずに質問とな。
0768デフォルトの名無しさんNGNG
>>766
Textbox自体がUNICODEの表示に対応していないから。
WebBrowserコントロールにでも出せばいい
0769デフォルトの名無しさんNGNG
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形式のテキストファイルを読みこんで出力するだけなのですが
どうしても文字化けしてしまいます。
0770デフォルトの名無しさんNGNG
VBスレへどぞー、って感じだな。
0771デフォルトの名無しさんNGNG
>>768の通りなんだけどな。
VBの中はUnicodeだけど、外から見える部分は勝手にAnsiてかShift_JISにしちゃうんよ。
コントロールしかり。
0772デフォルトの名無しさんNGNG
>>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

ですが、上の→の行でファイルを読みこんで変数に代入するときに
文字化けしたものが代入されているのですが、これは内部処理ではないのでしょうか？
0773デフォルトの名無しさんNGNG
>>772
Input 文が、勝手に「ファイルの中身はShift_JISだ」と仮定して変換しちゃってるんだと思う。
VB スレで訊いてみて。
0774デフォルトの名無しさんNGNG
だったら日本語も表示されないでそ
と思ったら、「日本語は化けない」とは言っていないのか。
0775デフォルトの名無しさんNGNG
ありがとうございます。VBスレで聞いてみます。
長々すみませんでした。あ、日本語は化けてません。
0776謎！NGNG
02 - \202\307\202\361\202\310\202\306\202\253\202\340\201B.mp3
この文字列を読める日本語に変換するにはどういう解釈をすればいいでしょうか。
\はバックスラッシュです。
元となっているエンコーディングが分かりませんし
数値も256を超えるのがあったりしてシングルバイトの文字列でもないようです。

よろしくおねがいします。
0777デフォルトの名無しさんNGNG
>>776
「どんなときも。」であってるよな…
だったら、\の後は8進数だよ。文字コードはSJIS。
0778謎！NGNG
>>777
8進数！謎が解けました。どうもありがとうございます。
0779謎！NGNG
付け加えて、>>776のフォーマット（書式？）の名前は一般的には何と呼ばれていますか？
Googleで検索して調べようにもキーワードがわかりません、、、
0780デフォルトの名無しさんNGNG
単に、表示側の対処法の違いだけだと思うけど
0781デフォルトの名無しさんNGNG
>>779
Cの規格書的には、octal escape sequenceだな。
JIS翻訳版なら8進逆斜線表記。

0782デフォルトの名無しさんNGNG
ナル文字としてよく使う'\0'も実はその8進表記。
0783デフォルトの名無しさんNGNG
てか、普通に 0 ってかくと字句解析的には8進表記とみなされるんじゃなかったっけ？
0784デフォルトの名無しさんNGNG
その通り。
0785デフォルトの名無しさんNGNG
その通りだが、0が8進数なのと、\0が8進エスケープシーケンスなのとは、
次元がまったく違うので、Cの規格書を読んで、Cスレにでも行け
0786デフォルトの名無しさんNGNG
質問なのですが、

Windows2000のコントロールパネルの項目にある「地域のオプション」についてなのですが、
韓国語のソフトをインストールして使用したいので、システムロケールを韓国語にしたのですが、
ユーザーロケールも韓国にしないといけないのでしょうか？
ユーザーロケールは通貨や単位の表記法の設定と書いてあるのですが、
やはりシステムロケールとユーザーロケールが食い違うとうまく表示してくれないのでしょうか？
0787デフォルトの名無しさんNGNG
とりあえずユーザーロケールはそのままでも動くんじゃないか？
駄目みたいだったらユーザーロケールも変えてみれば良いじゃないか。
0788デフォルトの名無しさんNGNG
>>786
板違い
0789謎！NGNG
>>781さん、どうもありがとうございました。おかげさまで必要な情報も検索で得られました。
0790デフォルトの名無しさんNGNG
BMP内のUnicode Standard 4.0の文字ができるだけたくさん表示できるtrue typeフォントを教えてください。
Arialの穴が多少なりとも埋まるとありがたいのですが。
0791デフォルトの名無しさんNGNG
Code2000とかはどうなんだろ
0792デフォルトの名無しさんNGNG
インド語とか、ただ文字が入ってるだけだとUnicode Standardの文字表を
表示する役にしか立たんぞ
0793デフォルトの名無しさんNGNG
>>791 >>792
レスが遅れましたが、ありがとうございます。
今から入れてみます。
0794デフォルトの名無しさんNGNG
MTで使用するのにEUC－JPかUTF-８って
結局どっちがお勧めだと思いますか？
0795デフォルトの名無しさんNGNG
「MT」とは何か
0796デフォルトの名無しさんNGNG
たぶんメルセンヌツイスターかマルチスレッドと思われる。
EUC-JPやUTF-8との絡みがよく分からんが、きっとこのあと説明してくれるのだろう。

まかり間違ってもGoogleで調べればすぐ分かるような、Movable Typeのことではあるまい。
0797デフォルトの名無しさんNGNG
はあ？
マニュアルトランスミッションのことに決まってるじゃん
0798デフォルトの名無しさんNGNG
Magnetic TapeじゃなかったのかYO
0799デフォルトの名無しさんNGNG
その調べればすぐわかるMovable Typeのこと
でも文字コードの設定を変えるのは簡単だけど、
結局世の中使ってる奴がバラバラで統一されて無いもんだからこまるのさ
でもって、みんなはどっちを選択してんのかなって思ったわけ

ちなみに自分は最近EUCからUTFへ変えてみた
0800デフォルトの名無しさんNGNG
Movable Type なら専用スレで聞いた方が早くね？
0801デフォルトの名無しさんNGNG
ここが２ちゃんでよかったな
0802796NGNG
>>799
UTF-8を選ぶでしょ。
Googleで調べてみれば、多くの人がそっちへ乗り換えてるはず。
それにUTF-8なら、Windowsでもきちんとバックスラッシュが表示されるし(どうでもいい?)。

でも俺はUnicodeは嫌いだから、あえてEUC-JPを使いたい。
0803デフォルトの名無しさんNGNG
>>802

794=799 そうなんだよね
実は俺も同じような考えで、時代の流れには従うしかないか
ってわけでUTF-8に乗り換えたんだけど
やっぱUnicodeっていまいち好きじゃあないんだよね

796のような発言でちゃらかす人は、そういうすぐに検索かかるほど
一般的なもので使用可能な統一文字コードを開発＆普及さして欲しいもんですな
気長に待ってますよ
0804デフォルトの名無しさんNGNG
■関連サイト(ノード)
┣ http://rightp2p.s68.xrea.com/node/
┣ http://www.stereoz.net/node/
┗ http://moejump.s6.x-beat.com/node.php
■関連サイト(本体・BBS・その他)
┣ http://rightp2p.s68.xrea.com/
┣ http://phphp.s58.xrea.com/
┣ http://www.stereoz.net/
┣ http://printf.jugem.jp/
┗ http://www.ero8.com/
0805796NGNG
>>803
おいおい、ちゃらかすって...。
プログラム板で「MT」って書いたから、一番可能性の高い物を出してやったのに。 :)

まず聞く場所が違う、MTで通じるわけがない(エスパー募集中?)、「Unicodeが好きじゃない」なんて
前提が書いてない、いろいろ問題がありすぎるんだよ。

君はねえ、ISO-2022を使いなさい。あれが今のところベスト。
0806デフォルトの名無しさんNGNG
関連スレでも出てたけど、
http://www.unicode.org/versions/corrigendum3.html
なんか笑えるね。
0807デフォルトの名無しさんNGNG
>>806
関連スレってどこ?

しかし、Unicodeもぼろぼろだな。GB18030で中国は離反するしな。
あれはなかなかうまかった。さすが計略に長けた中国。
0808デフォルトの名無しさんNGNG
そんなに簡単にバレるものは計略とは言わない
0809デフォルトの名無しさんNGNG
GB18030の採用に関する解釈が正反対なのが笑える
http://www2.xml.gr.jp/log.html?MLID=xmlmoji&N=814
0810デフォルトの名無しさんNGNG
>>809
GB18030なんて一言も出てきてないぞ。
だいたいこれ、2000年6月の話だし。
0811デフォルトの名無しさんNGNG
日本語については既存の文字コードとの変換を一意に
決められずに乱立を許した時点でunicodeは失敗したと
思うね。
0812デフォルトの名無しさんNGNG
MSとAppleとSunとJISCが話し合って変換テーブルを統一するなんて
現実的にあり得そうもないことをしなくちゃならなかったんだから、
失敗は必然だったとか言ってみる。
0813デフォルトの名無しさんNGNG
unicodeが失敗って、どこの世界の住民？
unicode以上に国際的な文字コードってなに？
0814デフォルトの名無しさんNGNG
TRONコードにきまってるだろ
0815デフォルトの名無しさんNGNG
>>813
> unicode以上に国際的な文字コードってなに？

ISO-2022。
でも現実としては、今のところUnicode。

> unicodeが失敗って、どこの世界の住民？

あきらかに失敗だよ。作りが悪すぎる。それでも使わざるをえない。
すぐ分かるのはUTF-16のサロゲートペア。他にもたくさんあるよー。
0816デフォルトの名無しさんNGNG
一文書中にアラビア語と韓国語を交えた日本語とかを書くには
Unicodeは便利です。
0817デフォルトの名無しさんNGNG
>>815
それはUTF-16の問題であってUNICODEの問題ではないでしょ。
UCS-4的にはまとまってるわけで。

どっちかというと言語タグとかの方が問題だとは思うが・・・

ISO-2022が理想かというと激しく疑問だし。

TRONコード? 窓から捨てちゃってよ。

実際マルチランゲージ対応しようとするとUNICODEが無難だとは思うがなぁ。
UNICODE <-> ISO-2022 とか UNICODE <-> EUC を考えると
頭が痛くなるのは同意するけどね。
0818デフォルトの名無しさんNGNG
>>817
Unicodeのそもそもは「16ビットに収めたい」ってところが出発点だから、
UTF-16のダメさはUnicodeのダメさと直結してるんだよ。

# そうでなければ、ISO-10646 DISを否決する必要がなかった。

だからCJKのunificationなんて、少し考えればやばそうなことをやっちゃったわけで。

あのころISO-2022が現実的でなかったのは、その複雑さとステートフルなところだったんだけど、
今となってみると、Unicodeの方がよっっっっぽど複雑なんだよね。なんだかな。
0819デフォルトの名無しさんNGNG
当初日本人の多くは積極的に係わらなかったから、
# それ仕方なかったことだったと思うけれど
あんまりチェックできなくて、>>812,>>806みたいな問題をたくさん残してしまったね。
0820デフォルトの名無しさんNGNG
>>818
もう少し勉強しよう。UCS-2は16bitに収まってます。
UTF-16はUCS-4をカバーしようとしてサロゲートペアなんて出てきたわけで。
(もはや)UNICODE＝16bitではありません。

UNICODEってISO-2022に比べて「っ」が4つ並ぶような複雑さですかね？
よっぽどISO-2022のほうが複雑だと思うのですが･･･。
0821デフォルトの名無しさんNGNG
>>816
しかし日本語と中国語を混ぜては書けない。

同じ文字があるから、言語タグや上位レイヤーの助け無しにはどちらの言語か分からないし、
結果として字体もヘンテコなものになるだろう。
0822デフォルトの名無しさんNGNG
>>820
君が勉強しなさい。
そもそも、UnicodeはBMPに全部収めるつもりだったんだよ(と言えば分かるか?)。
しかし全然収まらないから、サロゲートペアで16面ほど追加せざるをえなかったの。
0823デフォルトの名無しさんNGNG
ISO-2022なんて、実装しようとしたら結局内部的に固定長コードに
置き換えることになるんだがなあ。
初めから内部UCS-4にしとくのと大差ない。
0824822NGNG
>>823
それはそうなんだけど、その話をするにはまず、外部交換コードと内部処理コードを
分けて考える必要がある。

# じゃないと、そういう考え方をしたことがない人が理解出来ずに暴れ出す。
0825デフォルトの名無しさんNGNG
>>823
UCS-4を使っても固定長にはならないよ。
複数のcode pointを組合せて表現する文字は沢山ある。
0826デフォルトの名無しさんNGNG
ばか゜か゛
0827デフォルトの名無しさんNGNG
つーかなんでISO 2022とUnicodeの対立になるか意味不明なんですが。
外部交換コードはISO 2022だけど内部処理コードはUnicodeって無茶苦茶ありうる
0828デフォルトの名無しさんNGNG
そんな可逆性が保証できないものを内部コードに採用した設計者はクビだ
0829デフォルトの名無しさんNGNG
>>828
きちんと変換を定義すれば可逆にできるでしょ。外部との
やりとりはISO 2022しか使わないんだから、誰かが好き勝手
な変換表使ってISO 2022からUnicodeに変換したあとで渡して
くる心配はいらないわけで。

あとでなぜそうしたか知る人が失われた頃、内部ユニコード
ならそのままもらえば変換しなくてイイジャンとかヴァカが
考えてはまりそうではある。
0830デフォルトの名無しさんNGNG
「骨」問題も可逆にできるの？
0831デフォルトの名無しさんNGNG
確かに内部をUnicode系にすると、CJKVの漢字の使い分けできないな。
0832デフォルトの名無しさんNGNG
当然UCS-4にするんでしょう?

それでもISO-2022-JPじゃなくて、
ISO 2022 + ISO character set registry全体と可逆かどうかなんて目眩しそうだけど…
0833デフォルトの名無しさんNGNG
>>828 >>831
まったくだ。

>>829 >>832
UCS-4にしたとして、言語情報をどうやって持つんだい。言語タグ? 上位レイヤー?

>>830
もちろんダメだし、それだけではなく日本語と中国語の漢字の区別が吹っ飛ぶ。
0834デフォルトの名無しさんNGNG
>>833
>日本語と中国語の漢字の区別が吹っ飛ぶ。

大袈裟すぎ。可読性に影響を与えるほどの違いなんかねえよ。
細かい区別は符号化文字集合のスコープ外。
骨とかを区別したいなら、XMLなりPDFなり好みのフォーマットで交換しやがれ。
0835デフォルトの名無しさんNGNG
>>834
グリフの違いだと勘違いしちゃってるんだよね。

まず、検索・翻訳が出来ない。もちろん読み上げもできない。
一度言語情報が失われると、後からの追加は非常に難しい。
0836デフォルトの名無しさんNGNG
>>835
原則論としては、言語情報とそれに依存する処理はUnicodeのスコープ外。
ただし読み上げなどのためには言語タグが用意されている。
で、何か問題でも？
0837デフォルトの名無しさんNGNG
また、それだけではない。

>>834 の人は分かってるみたいだけど、包摂基準という物がある。
たとえば、カタカナの「ロ」と漢字の「口」(くち)は、非常に似ているが同じ文字にはしない。
なぜなら、意味が違う、音が違うからだ。

同じように、漢字という物も義(意味)、音、形がある。
Unicodeの漢字の包摂は形しか見てない。
表音文字であるアルファベットを使う人たちにとって、表意文字の概念は理解しにくいからね。
結局、漢字の一番大事な「義」は無視して包摂されることになってしまった。
0838デフォルトの名無しさんNGNG
>>836
言語タグは使うべきではない、と規格に書いてあるね。
あれは「一応言い訳としてつけておきました」程度の物。

> で、何か問題でも？

問題あるよ。君はプレインテキストでは検索はしないの?
0839デフォルトの名無しさんNGNG
>>837
>結局、漢字の一番大事な「義」は無視して包摂されることになってしまった。

無視されてねえよ（Noncognate Rule）。
0840デフォルトの名無しさんNGNG
>>838
>言語タグは使うべきではない、と規格に書いてあるね。

「言語タグは使うべきではない」なんてどこに書いてある？
XMLと併用するときはUnicodeではなくXMLのほうのタグを使えって話ならあったが。
0841デフォルトの名無しさんNGNG
>>839
そういう意味ではない。
たとえば、それぞれの言語での意が違う漢字でも「同じ文字」として扱われている。

あと、>>836 に対してさらに。

> ただし読み上げなどのためには言語タグが用意されている。

あらかじめ、「読み上げが必要である」って誰が判断するんだい?
それは読み上げソフトウェアを使って読む側が判断することで、書き手が判断できる事じゃない。
0842デフォルトの名無しさんNGNG
>>841
漢字統合に文句があるのか、言語情報がないことに文句があるのか、どっち？

>たとえば、それぞれの言語での意が違う漢字でも「同じ文字」として扱われている。
そんなのは漢字に限った話ではない。

>あらかじめ、「読み上げが必要である」って誰が判断するんだい?
だから言語情報は与えることもできるけど
あくまでオプションだというのがUnicodeの考え方だろ。
常に情報は多けりゃ多いほどいいってもんじゃないだろうに。
0843デフォルトの名無しさんNGNG
5.10 Language Information in Plain Text より。

A common misunderstanding about Unicode Han Unification is the mistaken belief that
Han characters cannot be rendered properly without language information. This idea
might lead an implementer to conclude that language information must always be added to
plain text using the tags. However, this implication is incorrect. The goal and methods of
Han Unification were to ensure that the text remained legible.

Unicodeについてのありがちな誤解は、「漢字は言語情報無しにはきちんと表示出来ないからHan Unificationは間違いだ」と信じられていることだ。
この考えは、実装者に「プレインテキストには、必ず言語情報をタグで付けなければならない」と思わせる可能性がある。
しかしながら、この実装は間違いだ。
Han Unificationの目標と構想は、テキストを読みやすく残しておくためのものだからだ。

ようするに、この文章を書いたヤツは
「英語とドイツ語のaが同じであるのと同じ程度に、日本語と中国語の骨は同じだ」
と思っている。表音文字の論理を表意文字にあてはめちゃってるんだよ。lol
0844デフォルトの名無しさんNGNG
>>843
>「英語とドイツ語のaが同じであるのと同じ程度に、日本語と中国語の骨は同じだ」

同じだろ。
プレーンテキストの基準は可読性。「骨」は読み間違いようがない。
ローマン体「H」とドイツの伝統的なフラクトゥール体の「H」など、
ラテンスクリプトにも同様の例がある。
0845デフォルトの名無しさんNGNG
>>844

> ローマン体「H」とドイツの伝統的なフラクトゥール体の「H」など、
> ラテンスクリプトにも同様の例がある。

だから表音文字と表意文字を同じにするなよ。
「起源のラテン語が同じでスペルが似ているから、同じ単語にしろ」ってのと同じことだ。
0846デフォルトの名無しさんNGNG
>>842
> そんなのは漢字に限った話ではない。
> あくまでオプションだというのがUnicodeの考え方だろ。

設計がダメダメなんだよ。検索の適合率(precision)を考えたことがあるのか?
0847デフォルトの名無しさんNGNG
>>845
たとえが不適切。問題外。「同じ単語にしろ」ってのは、
ごく初期の誤解だらけのUnicode批判に見られた言い方と同じ。
0848デフォルトの名無しさんNGNG
>>847
それは反論になっていないが。
0849デフォルトの名無しさんNGNG
>>846
>検索の適合率(precision)を考えたことがあるのか?

もうちょい具体的に頼む。
0850デフォルトの名無しさんNGNG
>>849
適合率と再現率を知らないなら、
http://www.internetclub.ne.jp/EASY/20030204.html
ここの最初を読んで。

それをふまえて、
「言語情報の無いUnicodeなテキストから検索をしたときに、別の言語の漢字がひっかかってしまい、
適合率が下がる」
0851デフォルトの名無しさんNGNG
そもそも漢字の統合にもっともな理由があるなら、ここまで「Unicodeの設計はクソ」なんて言わない。
# それでもかなりまずいが。

もともとは「全ての文字を16ビットに収めたい」という、無謀な考えから始まったもの。
おかげで日本人はかなり割を食う羽目になってしまった。
中国は乱暴だが賢明だ。
GB18030で文字集合のコントロールを自国に取り戻し、すくなくとも中国語は検索・表示できるようにした。
0852デフォルトの名無しさんNGNG
>>850
すでに書いたことの繰り返しになるけどさ、
言語情報のあるのとないのを比べたら、あるほうが高機能に決まってる。
だからといって情報量をとにかく増やせばいいってもんじゃないだろ。

要はプレーンテキストをどの程度コンパクトなものにするかについての
考え方の違い。
0853デフォルトの名無しさんNGNG
>>851
韓国もひどい話で、最初は母音・子音の合成でOKだと言っていたのに、合成文字のサポートに不安をおぼえたのか
後から全文字追加させるし。結果、16ビットの幻想崩壊の引き金になった。
0854デフォルトの名無しさんNGNG
>>852
その考え方は、「中国語と日本語の漢字は同じ文字で、違いは属性で表せる」という考えが基盤になっているね。
こっちは、「そもそも別の文字だ」と言っている。
0855デフォルトの名無しさんNGNG
>>854
そゆこと。
0856852NGNG
まぎらわしいコメントだったので名前欄に入れてもう一度。

>>854
そゆこと。
0857デフォルトの名無しさんNGNG
まー、漢字ぐらいなら可愛い問題だな。
ハイフンとか地獄だぞ。
0858デフォルトの名無しさんNGNG
>>857
あれは笑えるな。あと有名なのは鉛筆ネタか?
「漢字はUnifyしちゃうけど、ベンダの文字はどれだけ似てても別にする」という、これまた初期Unicode推進者の
頭の悪さを露呈するような内容。

でもJIS X 0208の丸も良い勝負だったりする。
○←丸印
◯←大きな丸(合成用丸)
おまけ:
〇←漢数字ゼロ
0859デフォルトの名無しさんNGNG
>>854
意味が違う字の包摂なんてJISでもやっちゃってるじゃん。柿とか。
0860デフォルトの名無しさんNGNG
だからTRONコードにしろって
0861デフォルトの名無しさんNGNG
>>821
文字コードの指定と言語の指定は基本的に無関係。
http://www.asahi-net.or.jp/~wq6k-yn/lang.html
>>828
ほんの一例を挙げるとWindowsやMacでEUCのWebページを見ている場合とか。
誰かMicrosoftとAppleをクビにして国産PCにはBTRON採用を義務付けてください。
なんて絵空事は置いといて
>>833
なんか妙な方向に話が行ってるけど可逆性が保証できないのはISO 2022の「仕様」。
GBとJISの使い分けで「骨」のカギの向きを区別できると考えるのは
JIS X 0201と0208の使い分けで「全角」と「半角」を区別できると考えるのと
同じくらい間違ってる。
逆に内部ISO 2022系で外部UCSという場合もありうる。Unicode化されてない
テキストエディタでUTF-8を入出力する場合とか。内部コードに変換できない
Unicodeの文字は可逆にならないけどそれもISO 10646の「仕様」。
>>845
「make」が「負け」なのか「作る」なのかは言語情報なしでは判別できない。
JIS X 0201だったら前者でUS-ASCIIだったら後者ですかまさか
>>859
それどころかnon cognate ruleがあるUnicodeならunifyされない字もJISだと
包摂されちゃう。
0862デフォルトの名無しさんNGNG
そんな中、颯爽とUnicode 4.1.0β登場ですよ。
0863862NGNG
なんとなく日本人に関係ありそうなとこだけ独断と偏見で挙げるね。
ソースはUnicodeData-4.0.1,txtと同-4.1.0d8.txtを比較しただけ。
もっといろいろ詳しく知りたいなら本家Unicode.orgを参照のこと。

追加:
　31C0..31CF CJK BASIC STROKE
　9FA6..9FBB CJK UNIFIED IDEOGRAPH
　FA70..FAD9 CJK COMPATIBILITY IDEOGRAPH
　FE10..FE19 PRESENTATION FORM FOR VERTICAL CHARACTER

変更:
　30FB KATAKANA MIDDLE DOT : General Category Pc->Po
　FF0F FULLWIDTH SOLIDUS : Bidi Class ES->CS
　FF65 HALFWIDTH KATAKANA MIDDLE DOT : General Category Pc->Po
0864デフォルトの名無しさんNGNG
>>861
> GBとJISの使い分けで「骨」のカギの向きを区別できると考えるのは
> JIS X 0201と0208の使い分けで「全角」と「半角」を区別できると考えるのと
> 同じくらい間違ってる。

それはすでに同じ文字として見なしているからであって、別の文字だという主張に対する反論になっていない。
0865デフォルトの名無しさんNGNG
>>861
> 「make」が「負け」なのか「作る」なのかは言語情報なしでは判別できない。
> JIS X 0201だったら前者でUS-ASCIIだったら後者ですかまさか

無いところから生成する必要はない。
必要な物を捨てていると言っている。

> それどころかnon cognate ruleがあるUnicodeならunifyされない字もJISだと
> 包摂されちゃう。

何を指しているのか思いつかない。例はある?
0866デフォルトの名無しさんNGNG
スレタイとはなれてる気もするが良スレの予感 :-)
0867デフォルトの名無しさんNGNG
文字コード関係スレは常に糞スレから始まって、
知識の鎬合いスレと化する。
0868デフォルトの名無しさんNGNG
>>864
参考までに聞いておきたいんだが、お前さんの「主張」だと
以下のうち「別の文字」となるのはどのケースかな？

1. GB 2312の「一」とJIS X 0208の「一」
2. GB 2312の「骨」とGB 12345の「骨」
3. GB 2312の「骨」とCNS 11643の「骨」
4. CNS 11643の「骨」とKS X 1001の「骨」
0869デフォルトの名無しさんNGNG
A
Ａ
Α
А

上記4つは、JISコードではそれぞれ別のコードが割り当てられているし
Unicodeでも別のコードが割り当てられている。
しかも4つのどれもが、「アルファベット大文字の1番目」

ていうか俺にも万人が納得できる解がどれなのか判断つかねっ
0870デフォルトの名無しさんNGNG
それぞれの相反する解に支持者がいる以上、
万人が納得する解はあり得ないと思われ。
0871デフォルトの名無しさんNGNG
>>869
0201の「A」を一緒にすんなよ。
0872デフォルトの名無しさんNGNG
>>869
> ていうか俺にも万人が納得できる解がどれなのか判断つかねっ

包括的な解はともかく、個々の文字の選択場面でも既に問題が出ている。
Mac OS Xの"コトエリ"は、-を入力して変換すると、
横棒系の文字を大量に候補に出す。
起動環境を日本語環境にしてあってもEN DASHが候補に含まれている。

ただ、こういう雑多な問題は、ここ数年になんとか解決するかも知れない。
・UTF-8への移行が一気に進む、あるいは
・日本語環境の起動においては、JISに含まれない文字を選択肢に出さない
など。
0873デフォルトの名無しさんNGNG
Unicodeの設計が嫌いな俺様が来ましたよ。

>>868
コンテキストより、Shift JISであると仮定する。後付けの明文化だが、文字集合はJIS X 0201とJIS X 0208とする。
# ここで「いやCP932だ」とか「普通ASCII」などは話がそれるので勘弁。

(1) A……JIS X 0201の「LATIN CAPITAL LETTER A」
(2) Ａ……JIS X 0208の「LATIN CAPITAL LETTER A」
(3) Α……JIS X 0208の「GREEK CAPITAL LETTER ALPHA」
(4) А……JIS X 0208の「CYRILLIC CAPITAL LETTER A」

(1)と(2)は同じ文字、(1)≠(3)、(1)≠(4)。
# (2)を慣用的な利用との互換として「FULLWIDTH LATIN CAPITAL LETTER A」とみなせば全部別の文字だが、
# それはあくまで例外である。

> Unicodeでも別のコードが割り当てられている。

Unicodeも(1)と(2)を別の文字とみなす事は出来る。しかしUnicode StandardもJISと同じく
「(FULL|HALF)WIDTHは慣用的な利用との互換のため、こんなの使わずに文字幅は上位レイヤーでやれ」
という立場。これは >>861 の人も触れているね。

> JIS X 0201と0208の使い分けで「全角」と「半角」を区別できると考えるのと
> 同じくらい間違ってる。
0874873NGNG
ここで、話の流れが分かっていない人が
「JIS X 0208では漢字に『CJK UNIFIED IDEOGRAPH-*』という名前が付いているんだから、unifyには問題ない」
という反論をするかも知れないのであらかじめ書いておく。

>>864 で書いたが、それはすでにunifyしてしまったためにそういう名前がついているわけだ。
俺は「UnicodeのCJK Unificationは設計としておかしかった」と言っているわけ。
unifyの損失についてはすでに書いた( >>835 >>837 >>850 )。
それに対し、unifyの唯一の理由は「Unicodeを16ビットに収めるため」という、今考えてみれば頭が痛くなるような理由。
# もちろん、あの当時でも分かっている人たちは反対していた。
0875デフォルトの名無しさんNGNG
>>874
漢字も基本的にアルファベットと見なせると思うけど。カタカナ「ロ」と漢字
の「口」はアルファベットとして違うからunifyできない。でも日本語として
の「骨」と中国語としての「骨」はアルファベットとして同じだからunifyで
きる。英語のAとフランス語のAがunifyできるのと同じように。「骨」という
記号そのものに言語情報は含まれていないのではないか。言語情報は後から附
加するものだと思う。
0876デフォルトの名無しさんNGNG
>>875
> の「骨」と中国語としての「骨」はアルファベットとして同じだから

そうなの?

>>873 の (1) と (3) のような関係じゃないかと思うんだけど。
0877デフォルトの名無しさんNGNG
グリフも少し違うからcapitalじゃなくて小文字のaとαかな。
0878デフォルトの名無しさんNGNG
(1)と(3)というよりは(1)と(4)かも。
0879デフォルトの名無しさんNGNG
ふーん。
とあるローカルな符号化方式で符号化された既存データとの相互変換で、バイトストリーム的に
ロスレスに元に戻せるという可逆性については皆さん案外重視してないんですね・・・

実際に世にある既存システムでは、全角半角が入れ替わったりしたらそれなりに問題視される
ケースもあると思うけど・・気のせいかも知れない。
0880デフォルトの名無しさんNGNG
いや、localなcoding systemに変換するmailerでPGPとかまるで駄目でしょ。
WindowsやMacはShift_JISに変換してfolderに保存するの多いけど。
0881デフォルトの名無しさんNGNG
>>875
> でも日本語としての「骨」と中国語としての「骨」はアルファベットとして同じだから

そう、ここなんだよね。
Unicodeのunifyを知らなかったら、ほとんどの日本人は「別の文字」と見なしていると思うんだけどな。
なまじunifyされた現状を知っているから、同じ文字だと思いこんでるだけで。
0882デフォルトの名無しさんNGNG
>>881
少なくともunifyは意味によってするわけじゃない
もちろんグリフでもない
0883デフォルトの名無しさんNGNG
>>882
意味によってunifyしたのもあるし、グリフのみでunifyしちゃったのもあるが。
0884デフォルトの名無しさんNGNG
>>883
どのような基準でunifyすべきだと思う？
0885デフォルトの名無しさんNGNG
意味でunifyするなら日本語の母と中国語の娘みたいなのも全部unifyされるんだろうな
グリフでもunifyしたらロも口も□も同じになるんだろうな
やっぱunicodeは支持できない
0886デフォルトの名無しさんNGNG
>>872
EN DASHはJIS X 0213に含まれてる(3区92点)から日本語環境で出てきておっけー。
JIS X 0213は伊達にEN DASHを含んでいる訳ではなく、「校正必携」を典拠と
して (規格票 p.304)、現代日本で使われている記号として収録している。
0887デフォルトの名無しさんNGNG
そだね。けど、ISO-2022-JPに含まれないから、
日本語環境だとtext/plain; charset=UTF-8にすべきだとおもうけど、
GB2312になっちゃうんだよ。Mail.appでさ。
0213使ったEUC系にする方法もあると思うけど、
メーラだからUTF-8が一般的だよね。
0888デフォルトの名無しさんNGNG
>>872
ことえりはOSXのずっと前からUnicodeベースのインプットメソッドに
なっている。クライアントアプリケーションがUnicodeを扱えればその
まま渡すし、Shift_JISベースなら変換して渡す。
OSXでShift_JISベースのアプリに対してはEN DASHは候補には上がる
が、入力はできないと明示される。

>>887
それはMail.appの使い方次第、System Preferences/Internationalで
のLanguagesの設定も優先使用するencodingに影響する。
0889デフォルトの名無しさんNGNG
>>885
・文字は本質的に視覚的存在であり、個別具体的な字形を抽象化した概念である。
・文字はある表記系(script)の中における差異によって特定される。
・表記系が異なれば形が同一に見えても別の文字とみなす。

従って、形に基づいて包摂するのは正しい。
しかしその包摂は表記系をまたがることはできない。(例: ロと口は包摂不可)
また、同一表記系の中で区別される形の差異は包摂できない。(例: 土と士は包摂不可)

ここで困難なのは、表記系の中で「同じ文字」とみなされる区別が必ずしも
文字の使用者の間で合意されないケースがあること。例えば「骨」問題。
「とにかく分けちゃえ」という意見もあるが(坂村健)、分離したらしたで、「骨」
のカギの部分を「人」の形に作った書き方をどちらで符号化したら良いかという
問題が生じ、きりがない。

ここまでくると、文字コードという技術的な問題ではなく、言語学的、文献学的
問題になる。西洋近代の言語学は文字を単なる音の移しとしか見なかったため、
文字の研究は遅れている。

0890デフォルトの名無しさんNGNG
日本語の「谷」（たに）と中国語（簡体字）の「谷」（≒日本語の「穀」）のようなものも
「グリフでunify」になってしまうのだろうか？
0891デフォルトの名無しさんNGNG
「意味の違いを無視してグリフでunify」と「グリフの違いを無視して意味でunify」の
2つがあることが問題なのかな？
Unicodeに限った問題ではなく、JIS X 0208でもある問題だけど。
0892デフォルトの名無しさんNGNG
>>889
表記系なんてものはないよ。別に日本語が漢字とひらがなとかたかなで表記さ
れなければならない義理はない。ローマ字で表記しようが、ヘブライ文字で表
記しようが、全く新しい文字を作り出して表記しても日本語は日本語だ。
0893Unicodeの設計が嫌いな人NGNG
>>889
> ここまでくると、文字コードという技術的な問題ではなく、言語学的、文献学的
> 問題になる。西洋近代の言語学は文字を単なる音の移しとしか見なかったため、
> 文字の研究は遅れている。

表音文字だけを使ってきた人たちには、表意表音文字を本質的には理解出来ないだろうね。
漢字なんてしょせん絵文字程度としか思っていない。
これは別にけなしているわけではなく、人は未知なるものを理解する事は非常に困難だからだ。

Unicodeの問題点を俺なりに総括すると、「文化の領域に踏み込みすぎた」という事だな。
unifyなんて必要なら後からやればいいんだよ。テーブル引くだけなんだから。
逆にいったんunifyしちゃうと分離はほとんど不可能なんだし。
あと正規化も同様。文脈によって全然違うんだから、わざわざ泥沼に入らんでもいいのに。
0894デフォルトの名無しさんNGNG
>>893
ラテン文字＝表音文字、漢字＝表意文字という図式に凝り固まりすぎなんじゃないの？
漢字だって表音的に使われることだって山ほどあるだろ？
ラテン文字一つ一つに意味を持たせる場合だってあるだろ。

> 表音文字だけを使ってきた人たちには、表意表音文字を本質的には理解出来ないだろうね。

んなことない。バカにしすぎ。
0895デフォルトの名無しさんNGNG
>>894
> 漢字だって表音的に使われることだって山ほどあるだろ？

当たり前だ。>>893 で表意表音文字と書いてるだろ。

> ラテン文字一つ一つに意味を持たせる場合だってあるだろ。

はいはい、例外を出して一般化しないようにね。
確かにaは最初、zは最後、という風に文字自身に意味を持たせる文脈はある。
しかしそんなことを考えながら単語から成る文章を理解するのか?

> んなことない。バカにしすぎ。

こう誤解されそうだから、>>893 でわざわざ書いたのにな。読んでないのか?
相手が理解出来ないからこそ、表意文字を使う人たちはきちんと意見を伝える必要があるんだよ。
もちろん礼儀を持ってね。別に相手は悪意がある訳じゃないんだから。
0896デフォルトの名無しさんNGNG
>>895
> はいはい、例外を出して一般化しないようにね。

別に一般化などしていない。ラテン文字＝表音文字、漢字＝表意文字という一
般化はできないということだけを言っているわけ。漢字が表音表意文字ならラ
テン文字、その他の文字だって表音表意文字だ。

多分あなたは文字というものを言語に一対一に対応するようなものだと考えて
いる。例えば日本語と中国語は別言語だから日本語の文字である「骨」と中国
語の「骨」は別の文字である。だからunifyすべきじゃない、というような。
こういう意見には賛成できない。
0897デフォルトの名無しさんNGNG
ﾏﾀｰﾘ砲発射！

_|￣| (((●ｺﾛｺﾛ
0898デフォルトの名無しさんNGNG
>>896
> 漢字が表音表意文字ならラテン文字、その他の文字だって表音表意文字だ。

意味が分からん。解説よろしく。

> 多分あなたは文字というものを言語に一対一に対応するようなものだと考えて
> いる。

そんな単純ではないんだが。今まで書いたのからそう読めるんだろうか。

> こういう意見には賛成できない。

なぜ?
0899デフォルトの名無しさんNGNG
>>898
> 意味が分からん。解説よろしく。

自分で「確かにaは最初、zは最後、という風に文字自身に意味を持たせる文脈はある。」などと書いてるじゃないか。
ヘブライ文字や梵字も表意的に使わることがある。その他いろいろあるだろう。
要するにすべての文字は表意的にも表音的にも使われることがあるということ。

> そんな単純ではないんだが。今まで書いたのからそう読めるんだろうか。

「骨」に関しては「日本語と中国語は別言語だから日本語の文字である「骨」
と中国語の「骨」は別の文字である。だからunifyすべきじゃない」というこ
とだろ？

0900デフォルトの名無しさんNGNG
>>899
> 要するにすべての文字は表意的にも表音的にも使われることがあるということ。

おいおい……。>>895 は読んでくれた?
「しかしそんなことを考えながら単語から成る文章を理解するのか?」と続いてるんですけど。

> 「骨」に関しては「日本語と中国語は別言語だから日本語の文字である「骨」
> と中国語の「骨」は別の文字である。だからunifyすべきじゃない」ということだろ？

あのねえ、そんな単純じゃないんだよ。
そういう考え方*も*あるし、実用的・技術的な面から見ても問題点がある。そのへんはもう書いた。
テーブルを作ってしまえばunifyするのはすごく簡単なことだ。しかし逆変換はほぼ不可能。
そしてunifyの理由であった「Unicodeを16ビットにおさめる」は、とっくに破綻している。
よってUnicodeの設計はダメダメですね、という話なんだが。
0901デフォルトの名無しさんNGNG
>>900
> 「しかしそんなことを考えながら単語から成る文章を理解するのか?」と続いてるんですけど。

言語の原理的なことを言っているわけ。ラテン文字＝表音文字、漢字＝表意文
字ということはないということが伝わればそれでいい。

> そういう考え方*も*あるし、実用的・技術的な面から見ても問題点がある。そのへんはもう書いた。

unifyのことを言っている。「骨」をunifyするべきじゃないのは「そういう考え方」に基くんだろう？
文字の「義」が違うからunify不能だと。

> テーブルを作ってしまえばunifyするのはすごく簡単なことだ。しかし逆変換はほぼ不可能。

逆変換などする必要はない。Aを英語とフランス語とに区別する必要がないという意味で。
言語＝文字の集合じゃない。

> よってUnicodeの設計はダメダメですね、という話なんだが。

設計にはいろいろ無理があることは知っている。ただ多くの文字を統一的に扱
かおうとすること、それにともなうunifyには賛同できる。

# キリがないのでこの辺で
0902デフォルトの名無しさんNGNG
>>901
> # キリがないのでこの辺で

正直俺もこの辺で切り上げたい。

なぜなら、「同じ文字かどうか」というのは多分に文化的な問題だからだ。
これは専門の人が一生かけて一文字包摂できるかどうかというレベルの話だと思うし、軽々しく扱うのは畏れ多いことだ。

# HALFWIDTH、FULLWIDTHは別。あれには俺は文化的なものを見いだしていない。
# あんな恥ずかしい区別、さっさと捨ててしまうべきだ。

だからこそいったんunifyしてしまうと、その区別はもう二度と取り戻せないわけで、逆変換不能なunifyを
Unicodeが軽々しくやってしまったのは完全に失敗だ。
0903デフォルトの名無しさんNGNG
>>901
でもまぁ、せっかく書いてくれたんだし返事はしよう。

> 言語の原理的なことを言っているわけ。ラテン文字＝表音文字、漢字＝表意文字と
> いうことはないということが伝わればそれでいい。

一般的には「ラテン文字=表音文字、漢字=(表音)表意文字」だが。
あくまで例外としてラテン文字に表意を持たせることがあるという程度。
たとえば普通、文章中に"text"という単語が出てきた場合、t, e, x, tのそれぞれの文字に意味は無いだろう。
しかし「文章」という言葉の場合は、二つの文字に意味があり、そこから単語の意味が組み立てられているわけだ。

> 文字の「義」が違うからunify不能だと。

だから違うって。ブール代数とか苦手な人? 命題が真な時、逆も裏も真とは限らないんだよ。
0904デフォルトの名無しさんNGNG
ちょっと横槍だけど

>>902
># HALFWIDTH、FULLWIDTHは別。あれには俺は文化的なものを見いだしていない。
># あんな恥ずかしい区別、さっさと捨ててしまうべきだ。

もう既に絵文字と言う文化ができてるから、
俺的には残ってもいいんじゃないかなぁと思ってる。

確かに技術的にはテキストでイメージを表現しようとするのは
間違った事かもしれんけどここまで発展した絵文字が失われるのは惜しい。
0905デフォルトの名無しさんNGNG
>>904
君が引用している部分は、
「一応書かないとまたアホが全角半角言い出すからなぁ。でもこの部分には返事が付かないといいな」
と思いながら書いた。

> もう既に絵文字と言う文化ができてるから、
> 俺的には残ってもいいんじゃないかなぁと思ってる。

戦争でも起こらん限り、駆逐は難しいね。
0906デフォルトの名無しさんNGNG
FULL, HALFは互換のために仕方ないだろ。
もしUnicode的になくしたとしたら、FULLの方をなくしたわけだろうけど、
今以上にアンチUnicodeの嵐になっているぞ。

ただこういう疵をUnicodeは新たに作ってしまったな。
# JIS 1978→1982や補助漢字も凄いけどな。
0907905NGNG
>>906
言ってる内容は概ねその通りだが、

> もしUnicode的になくしたとしたら、FULLの方をなくしたわけだろうけど、

これは違うよ。互換用のだけ「FULLWIDTH」「HALFWIDTH」が付いてる。

「HALFWIDTH KATAKANA LETTER A」……JIS X 0201由来の「ア」
「FULLWIDTH QUESTION MARK」……JIS X 0208由来の「?」
0908906NGNG
ああ、俺は「FULLの方」っていうのはグリフの事を言ってしまっていたよ。
0909デフォルトの名無しさんNGNG
ところで>>868に答える人はいないのか？
0910デフォルトの名無しさんNGNG
>>909
1～4、全て別。
0911デフォルトの名無しさんNGNG
>>910　0点
0912デフォルトの名無しさんNGNG
㍘
0913デフォルトの名無しさんNGNG
>>910 満点
0914デフォルトの名無しさんNGNG
結局、32ビットコードの文字集合を新たに製作して、そこに文字を
「グリフが違えばすべて違う文字と考える」
ように収録するのが最も一般的な解決方法だろうか？

AdobeのCIDは「グリフが違えばすべて違う文字と考える」考え方だよね。
それを全言語・全文字に拡張すれば…
0915デフォルトの名無しさんNGNG
それだと使うときかなり困ると思うけど……
現状でも満足になされていない、ハイフン類の使い分け問題みたいなのが
もっと拡大するので、ただ書くだけならいいけど、機械処理に困る。
0916デフォルトの名無しさんNGNG
>>914
それ「超漢字」じゃん。
0917デフォルトの名無しさんNGNG
龍龍
龍龍
↑これユニコードに入ってたっけ？
0918デフォルトの名無しさんNGNG
>>917
U+2A6A5
http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=2A6A5
0919デフォルトの名無しさんNGNG
助かりました。まさか入っているとは。
0920デフォルトの名無しさんNGNG
興*4はないっぽいけどね。Simsun (Founder Extended)入れとけば楽に探せる。
0921デフォルトの名無しさんNGNG
ていうかUnihan Radical-Stroke Index使って自分で探せるようになると便利よ。
ttp://www.unicode.org/charts/unihanrsindex.html

知らない人のために簡単に説明。知ってる人は読み飛ばして下せぇ。

・Strokes in radical: 部首の画数を選択
・Minimum & Maximum: 探したい漢字の(部首を除いた)最小画数と最大画数を選択
・Use UTF-8: 漢字の画像を表示するか自分のマシンのフォントで表示するか選択
・部首の画像から検索したい部首をひとつ選択
・submit後、一覧から目的の漢字をみつけてクリック→詳細情報

どこから来た漢字なのかや、各国での読み、異体字とか色々載ってるんで、
文字コード関係以外の時でも結構使えます。
0922デフォルトの名無しさんNGNG
ありがとうございます。そんな便利なものがあったのですね。
これから活用します。
0923デフォルトの名無しさんNGNG
>>915
>>914
漢字だけに関して言えば
[ロケールコード][文字コード][異体字(グリフバリエーション?)番号]
がビット固定長で並んでるのが理想だと思う。
検索するときは異体字コードはマスクして無視するとか。

ただ、世の中にはリガチャしまくりで「どこからどこまでを１文字とするか」
が立場や処理によって変わる文字とかいろいろあるからなぁ、、

UNICODEのフル実装は個人や１企業の手に余る気がする、、、

フォントやPnPのドライバみたくオンデマンドで
必要なロケールの処理モジュールをダウンロードすればすむ様な
仕組みはできないものか。

それがロケール単位でいいのかって議論もあろうけども。

0924デフォルトの名無しさんNGNG
トンパはない。
0925デフォルトの名無しさんNGNG
ちょっと気になったのだが。
龍龍
龍龍
U+2A6A5だから、これはUCS-4で定義される文字になるわけですね。
ちょっと古い記事などを読むと、UCS-4で群00面00（=UCS-2）以外には
まだ文字は配置されていない、とか書いてあるが、現在、既に配置は
始まっているということなのか？
0926デフォルトの名無しさんNGNG
Unicode 3.1.0で初めてBMP外に配置された。
詳しくはDerivedAge.txtを参照のこと。
0927デフォルトの名無しさんNGNG
>>921
おぉぅ、興*4あったわ（U+2053B）。ｽﾏｿ
0928デフォルトの名無しさんNGNG
CJK Unified Ideographs Extension B を眺めてると結構楽しいな
変な漢字があったりとかして
0929デフォルトの名無しさんNGNG
書き順が想像付かないやつとか普通の漢字にはありえない曲線とかあるなｗ
0930デフォルトの名無しさんNGNG
>>925
> UCS-4で定義される文字になるわけですね
「UCS-4で表現されうる文字になるわけですね」が正しい、と突っ込んでみる
0931デフォルトの名無しさんNGNG
>>864
> それはすでに同じ文字として見なしているからであって、別の文字だという主張に対する反論になっていない。
だってISO 2022はそういう仕様だって言ってるだけだもん。
あくまで別の文字だと主張して区別したい人にとってもはやISO 2022は使い物にならない。
それこそ鎖国してTRON使わせるくらいしか道はない。
# 話の枕は「unicode以上に国際的な文字コード」なのにどうして「鎖国」って結論になるんだ
そもそも何を根拠に別の文字だって主張してるのか謎なんだけど
0932デフォルトの名無しさんNGNG
>>865
> 何を指しているのか思いつかない。例はある?
>>859
つーか97JISの解説嫁。類型異字でもかまわず包摂しますが何か? と高らかに
宣言してるぞ
0933デフォルトの名無しさんNGNG
>>874
> 俺は「UnicodeのCJK Unificationは設計としておかしかった」と言っているわけ。
何も考えないで丸ごと詰め込むほうが設計としておかしい。
> unifyの損失についてはすでに書いた( >>835 >>837 >>850 )。
だからLATIN SMALL LETTERをUnifyしたらプレーンテキストで「make」の検索も
翻訳もできない。
> もちろん読み上げもできない。
グリフがまったく同じでも読みごとに別のコードを振るべきだと思う?
<丶｀∀´>＜思うニダ
> それに対し、unifyの唯一の理由は「Unicodeを16ビットに収めるため」という、
> 今考えてみれば頭が痛くなるような理由。
アメリカ人はもっと凄いこと言ってたようだけど。
http://www2.xml.gr.jp/log.html?MLID=xmlmoji&N=1553
統合漢字の原案(HCC)を出したのは中国。
0934デフォルトの名無しさんNGNG
>>876
> そうなの?
> >>873 の (1) と (3) のような関係じゃないかと思うんだけど。
日本人は日本の漢字で漢文を書くし中国人は古典も簡体字化してる。
違うスクリプトとは思えない(むろん言語は違う)。
0935デフォルトの名無しさんNGNG
>>881
> Unicodeのunifyを知らなかったら、ほとんどの日本人は「別の文字」と見なしていると思うんだけどな。
そりゃ漢字の知識がないだけ。ほとんどの中国人は「同じ文字」とみなす。
アルファベットの知識がなかったら2種類の「g」が違う文字に見えるかもしれない。
0936デフォルトの名無しさんNGNG
>>880
むしろNormalizatinしないで署名したりダイジェスト作ったりするのがだめ。
「必要なら後からテーブル引いてUnifyすればいい」という発想だと
そのときどんなテーブル使ってたのか分からないと署名の検証ができなくなる。
0937デフォルトの名無しさんNGNG
>>936
binaryに対する署名のようにAS ISでいいじゃん。
PGP/MIMEなんかでは、canonicalizationって言ってもline endingだけだし。

0938デフォルトの名無しさんNGNG
>>935
確かに、日本人であっても2種類の「骨」が「別の文字」に見える人は「漢字の知識」がないと
言われても仕方ないかもしれない。「別の字体」に見える、ならまだしも。

下を丸める「g」と下を丸めない「g」も「別の文字」に見える人は「アルファベットの知識」がないと
言われても仕方がないと思うが、「別の字体」に見えるというのなら「アルファベットの知識」が
ないとは言い切れない。
0939デフォルトの名無しさんNGNG
>>923
以下、[ ]で囲ったのは実際にはそれぞれがビットを表していると考えてほしい。

「辺」を表すのが[日本語][辺][異体字0]で、
「邊」を表すのが[日本語][辺][異体字1]で、
「邉」を表すのが[日本語][辺][異体字2]で(以下ry
みたいな構成がいいということになるのかな?

繁体字中国語では
「邊」を表すのが[繁体字中国語][邊][異体字0]で、
簡体字中国語では
「しんにょう+力」を表すのが[簡体字中国語][しんにょう+力][異体字0]で…となるのかな?

異体字ビットは何ビットくらいあれば必要十分なんだろうか?
1文字につき2^6=64くらいかな?
0940デフォルトの名無しさんNGNG
> 異体字ビットは何ビットくらいあれば必要十分なんだろうか?
実際やるとしたら、UnicodeのVariation Selectorを使うのが現実解かなぁ……。
FE00-FE0Fの16コードポイントでCJKV等の言語を割り当てて、
E0100-E01EFの240コードポイントで言語ごとに字形テーブルとノーマライズを標準化する。
094136305/01/18 14:57:09
すみません。シェルの中における漢字の文字コード
についてなのですが二つのシェルにおいて同じマシン
で同じ漢字書いたとき文字コードがかわるという
こはあるんでしょうか？実際一方では動作して、
もう一方では動作しないという現象が起きてしまって
いるのです。この問題に対しての解決方法があれば
どなたかおしえていただけないでしょうか？
お願いします。
0942デフォルトの名無しさん05/01/18 15:26:16
何をやったのかを、第三者にも分かるように書かないと。
とりあえず、2つのシェルの環境変数とかロケールとかは全く同じでも再現する？
0943デフォルトの名無しさん05/01/18 15:37:05
>>941
・両者ともにその「漢字」に対応したバイナリかどうか
・ロケール等の環境変数は合っているか
・端末側の文字コードは合っているか
とか確認してみてはどうでしょう。

漏れはシェルによって日本語通らなくなったりするのは
わりと当たり前って思ってるな・・・
0944デフォルトの名無しさん05/01/18 16:06:35
何で漢字テキストを書いたかも書いてないしな。
スレ違いだろ。UNIX板の初心者スレがいいんじゃないの?
094536305/01/18 17:25:01
ありがとうございます。わかりづらくてすみません。
自分の今やっていることはテキスト文章の編集をやっていて
sedである部分を削除しようと思いsedの中に削除目的の
日本語を入れたところ、うまく消えなかったのです。

cat $f | grep -v '#'| grep -v '^$'| cut -f2- | sed 's/^/<s> /'| sed 's/$/\
<\/s>/'| sed 's/\/読み未登録//g'
このような感じで書きました。(ファイル名はtextmake.csh)
そこから試行錯誤して理由は良くわからないのですが
そのシェルとは別のシェルの中にはじめに作ったシェル
を入れ、textmake.csh | sed 's/\/読み未登録//g'
このようにしたら上手く削除できたのです。
後で調べてみたら前の最初のシェルはシフトＪＩＳで
後のシェルはeucのコードになっていたみたいだった
のです。それでなぜなのだろうと思い。質問したという
わけなのです。環境変数などがわからないので調べて
みようと思います。
0946デフォルトの名無しさん05/01/18 17:30:25
シェルってシェルスクリプトのことかYO!
おじさんビックリだ。
0947デフォルトの名無しさん05/01/18 17:36:05
>>945
シェルスクリプト書いた奴に聞きなよ。
使ったエディタとその環境を。
0948デフォルトの名無しさん05/01/18 20:14:08
> ・シェルスクリプトのことをシェルってゆーな
by UNIX板 シェルスクリプト総合スレ >>1
094936305/01/19 10:31:07
なんかスレ違いだったみたいかなぁ。すいません！
ありがとうございました。
0950お願いします05/01/19 10:58:05
論理式eが与えられた時、eと等価なCNFを求める述語cnf/2を定義せよ。
という問題がわかりません。
誰か教えてくれませんか？
0951デフォルトの名無しさん05/01/19 11:07:36
マルチかつスレ違い。氏ね。
0952デフォルトの名無しさん05/01/25 13:38:52
JIS X 0213にも「異体字を表す制御文字」を追加することができないだろうか？
確か第1面にも30文字程度の空き区点（バラバラに存在する）があったはずなので、
そこを「異体字を表す区点」にしてしまえば比較的簡単に異体字を表現することができる。

ほとんど使われていないJIS X 0213を捨ててしまって、また別のJIS X 0208上位互換の
文字コード体系を作ればすっきりした体系になるのはわかってはいるのだが、
JIS X 0212でさえ完全には捨て切れない現状を考えると…
0953デフォルトの名無しさん05/01/25 13:48:59
ttp://headlines.yahoo.co.jp/hl?a=20050125-00000401-yom-soci
だからどうという程のものでもないがな。
0954デフォルトの名無しさん05/01/25 14:44:44
まぁ現状よりましになるんじゃない？ ていうか今までがひどかったのか。
0955デフォルトの名無しさん05/01/26 09:44:44
JISの中の人は、また包摂の解説→議論やらないといけないね…
0956デフォルトの名無しさん05/01/26 15:13:00
そしてあの包摂基準では国語審議会側やら何やらを納得させられないので(ry
0957デフォルトの名無しさん05/01/31 18:47:26
かなりずれるが
草かんむり、３画に　４画派・大修館書店が「決断」
http://news.goo.ne.jp/news/asahi/shakai/20050131/K2005013101680.html

　３画か４画か――漢和辞典で長い間、揺れていた「草かんむり」の画数が、
大修館書店が出した「新・漢語林」で３画に変わった。同書店は世界最大の
漢和辞典、諸橋轍次の「大漢和辞典」（１９６０年）を発行している老舗（しにせ）。
中国の古い文書を読もうとする専門家が頼りにする「大漢和」では４画だ。
常用漢字や人名用漢字の３画に追随するのは、「大きな決断」だった。

　「新・漢語林」部首解説によると、草かんむりは、
国語審議会の表外漢字字体表（００年）やＪＩＳ漢字で３画とされ、
明朝体活字は３画で作られている。真ん中が切れた形の４画は
「漢和辞典の見出し字を除いて極めて少ない」という。

　「新・漢語林」編集部の円満字二郎さんは「表外漢字字体表がきっかけで、
電子辞書に搭載するにも３画、４画両方では負担が大きい。
諸般の事情を考えて決断したのに残念ながら反響は全くありません」という。
0958デフォルトの名無しさん05/01/31 18:48:12
> 残念ながら反響は全くありません
に少々受けてしまった
0959デフォルトの名無しさん05/02/04 22:00:42
SJISとUnicodeの半角ｶﾅ←→全角カナ変換をする
ツールを作りたいんですが、この辺のノウハウに
ついての詳しい情報ありませんか？
半角全角変換のみで、SJISとUNICODEの変換は
必要ないです。
0960デフォルトの名無しさん05/02/04 23:03:29
以前倪永茂氏のAlgorithmCollectionという有名なホームページに
あったな、今は削除されているけど。
0961デフォルトの名無しさん05/02/04 23:57:52
wchar_t Hankaku2Zenkaku(wchar_t wc)
{
if(wc == L' ') return L'　';
else if(wc < L'ｦ' || wc > L'ﾟ') return wc;
else if(wc >= L'ｱ' && wc <= L'ｵ') return L'ア' + (wc - L'ｱ') * 2;
else if(wc >= L'ｶ' && wc <= L'ﾁ') return L'カ' + (wc - L'ｶ') * 2;
else if(wc >= L'ﾂ' && wc <= L'ﾄ') return L'ツ' + (wc - L'ﾂ') * 2;
else if(wc >= L'ﾅ' && wc <= L'ﾉ') return L'ナ' + (wc - L'ﾅ');
else if(wc >= L'ﾊ' && wc <= L'ﾎ') return L'ハ' + (wc - L'ﾊ') * 3;
else if(wc >= L'ﾏ' && wc <= L'ﾓ') return L'マ' + (wc - L'ﾏ');
else if(wc >= L'ﾔ' && wc <= L'ﾖ') return L'ヤ' + (wc - L'ﾔ') * 2;
else if(wc >= L'ﾗ' && wc <= L'ﾛ') return L'ラ' + (wc - L'ﾗ');
else if(wc == L'ﾜ') return L'ワ';
else if(wc == L'ｦ') return L'ヲ';
else if(wc == L'ﾝ') return L'ン';
else if(wc >= L'ｧ' && wc <= L'ｫ') return L'ァ' + (wc - L'ｧ') * 2;
else if(wc >= L'ｬ' && wc <= L'ｮ') return L'ャ' + (wc - L'ｬ') * 2;
else if(wc == L'ｯ') return L'ッ';
else if(wc == L'ｰ') return L'ー';
else if(wc == L'ﾞ') return L'゛';
else if(wc == L'ﾟ') return L'゜';

return wc;
}
0962デフォルトの名無しさん05/02/04 23:59:32
int Zenkaku2Hankaku(wchar_t wc, wchar_t *ans)
{
if(wc == L'　'){ *ans = L' '; return 1; }
else if(wc == L'ワ'){ *ans = L'ﾜ'; return 1; }
else if(wc == L'ヲ'){ *ans = L'ｦ'; return 1; }
else if(wc == L'ン'){ *ans = L'ﾝ'; return 1; }
else if(wc == L'゛'){ *ans = L'ﾞ'; return 1; }
else if(wc == L'゜'){ *ans = L'ﾟ'; return 1; }
else if(wc == L'ー'){ *ans = L'ｰ'; return 1; }
else if(wc < L'ァ' || wc > L'ロ'){ *ans = wc; return 1; }
else if(wc == L'ッ'){ *ans = L'ｯ'; return 1; }
else if(wc >= L'ァ' && wc <= L'オ'){
int x = (wc - L'ァ');
*ans = ((x % 2) ? (L'ｱ' + (x / 2)) : (L'ｧ' + (x / 2)));
return 1;
}else if(wc >= L'カ' && wc <= L'チ'){
int x = (wc - L'カ');
*ans = L'ｶ' + (x / 2);
if(x % 2){
*(ans+1) = L'ﾞ';
return 2;
}else{
return 1;
}
0963デフォルトの名無しさん05/02/05 00:00:03
}else if(wc >= L'ツ' && wc <= L'ト'){
int x = (wc - L'ツ');
*ans = L'ﾂ' + (x / 2);
if(x % 2){
*(ans+1) = L'ﾞ';
return 2;
}else{
return 1;
}
}else if(wc >= L'ナ' && wc <= L'ノ'){
*ans = L'ﾅ' + (wc - L'ナ');
return 1;
}else if(wc >= L'ハ' && wc <= L'ホ'){
int x = (wc - L'ハ');
*ans = L'ﾊ' + (x / 3);
if((x % 3) == 1){
*(ans+1) = L'ﾞ';
return 2;
}else if((x % 3) == 2){
*(ans+1) = L'ﾟ';
return 2;
}else{
return 1;
}
}else if(wc >= L'マ' && wc <= L'モ'){
*ans = L'ﾏ' + (wc - L'マ');
return 1;
0964デフォルトの名無しさん05/02/05 00:00:44
}else if(wc >= L'ャ' && wc <= L'ヨ'){
int x = (wc - L'ャ');
*ans = ((x % 2) ? (L'ﾔ' + (x / 2)) : (L'ｬ' + (x / 2)));
return 1;
}else if(wc >= L'ラ' && wc <= L'ロ'){
*ans = L'ﾗ' + (wc - L'ラ');
return 1;
}

return 0;
}
0965デフォルトの名無しさん05/02/07 20:54:12
>>957
この新漢語林読んだんだけど、なぜか芸亭（ウンテイ）の芸だけが4画で残っているの。
草冠を3画に統一するんだったら、ゲイとウンを餘と余みたいに同一文字の扱いにするか、
「同一字形だけど別字」にしたほうがよいと思ったんだけどなぁ。
0966デフォルトの名無しさん05/02/15 19:54:00
Jcode-1.99_04 make とおりまんた。
かんきょうは OpenBlock S200 , perl 5.6.1 でし。
よかったね。

[a@obss Jcode-1.99_04]$ make test
make[1]: Entering directory `/home/a/src/Jcode-1.99_04/Unicode'
make[1]: Leaving directory `/home/a/src/Jcode-1.99_04/Unicode'
PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/lib/perl5/5.6.1/ppc-linux -I/usr/lib/p
erl5/5.6.1 -e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t
t/append.....ok
t/convert....ok
t/getcode....ok
t/h2z........ok
t/length.....ok
t/mime.......ok
t/new........ok
t/perl581....skipped
all skipped: Perl 5.8.1 or later required
t/regex......skipped
all skipped: Perl 5.8.1 or later required
t/tr.........ok
All tests successful, 2 tests skipped.
Files=10, Tests=220, 119 wallclock secs (90.21 cusr + 25.26 csys = 115.47 CPU)
make[1]: Entering directory `/home/a/src/Jcode-1.99_04/Unicode'
No tests defined for Jcode::Unicode extension.
make[1]: Leaving directory `/home/a/src/Jcode-1.99_04/Unicode'
[a@obss Jcode-1.99_04]$
0967デフォルトの名無しさん05/02/15 21:19:29
>>959
窓ならLCMapString
0968デフォルトの名無しさん05/02/19 01:15:40
学校の宿題教えて禁止
ここのスレはみんなが見てますやめましょう
0969デフォルトの名無しさん05/02/19 01:17:02
学校で宿題出されました。どなたか解答お願いできませんでしょうか？
0970デフォルトの名無しさん05/02/20 22:28:34
あまり真剣に考えてもらわなくてもいいんですが、

多少間違ってても、判定不可という結論でもいいから
主にSJIS,EUC,UTF-8で書かれた短い文章のコードを判定するのに
上手い方法はありませんかね？

というか、ぶっちゃけ2ch内に張られた
googleとかwikiへのリンクのURLエンコードされた部分を
iconv辺りを使ってSJISに直して表示してリンクしたら面白いかな、と
ちょっと思ってみただけなんで
判定不可ならそのまま%xx%yyで表示すればよいだけなんで。
0971デフォルトの名無しさん05/02/21 01:36:35
SJISにしか出てこない値が出てきたらSJIS
EUCにしか出てこない値が・・・（以下略
0972デフォルトの名無しさん05/02/21 04:43:01
ASCIIにしか出てこない値が出てきたらASCII
0973デフォルトの名無しさん05/02/21 05:46:07
色々切り替えて読めればそれ
0974デフォルトの名無しさん05/02/21 21:45:22
EBCDICとかどうよ
0975デフォルトの名無しさん05/02/21 21:46:02
なにが？
0976デフォルトの名無しさん05/02/21 21:55:27
EBCDIKでどうよ
0977デフォルトの名無しさん05/02/21 22:01:00
>>970
SJISのシーケンスを受理するオートマトン、
EUCのシーケンスを受理するオートマトン、
UTF-8のシーケンスを受理するオートマトン、
を用意して、入力バイト列を3つのオートマトンに入れてみる。
入力が終ったときに、受理したままのオートマトンが1つだけなら、
その文字コードで確定。

確定しない場合があるので、そういうときは追加の知識を使うしかない
(google で ie= パラメータがあったら～、とか)

0978デフォルトの名無しさん05/02/21 22:06:24
↓オートマトン
0979デフォルトの名無しさん05/02/21 22:28:46
メェェー
0980デフォルトの名無しさん05/02/21 22:39:27
SJISのシーケンスを受理するヤギ、
EUCのシーケンスを受理するヤギ、
UTF-8のシーケンスを受理するヤギ、
を用意して、印刷物を3匹のヤギに食わせてみる。
食い終ったときに、「メェェー」って言ったヤギが1匹だけなら、
その文字コードで確定。

二匹啼いたときは、一匹殺せば無問題。


0981デフォルトの名無しさん05/02/21 22:44:47
それじゃぁ手始めに979を殺すということで
0982デフォルトの名無しさん05/02/21 23:14:52
>>970
|多少間違ってても、判定不可という結論でもいいから
|主にSJIS,EUC,UTF-8で書かれた短い文章のコードを判定するのに
|上手い方法はありませんかね？

たぶん変換コード書いた人なら悟ってると思うけど、
3種類出力させて、判断は人間にまかせるのが簡単確実。
問題はその表示のしかたをどう分かりやすくできるかだが…
0983デフォルトの名無しさん05/02/21 23:50:46
確実に判定することは不可能だけど
実用上は980^H^H77の方法でほとんど困らないと思う
利用者としてはリンク開くときに常に3択やらされるたらいやだなぁ
0984デフォルトの名無しさん05/02/21 23:52:10
前半は980で、
二匹鳴いたら二匹並べればいいだろ。
0985デフォルトの名無しさん05/02/22 02:39:43
やっぱむやみにヤギを殺すのはよくないよね
0986デフォルトの名無しさん05/02/22 03:46:34
べつに
0987デフォルトの名無しさん05/02/22 11:07:32
というかさ、ヤギじゃなくてヒツジじゃないの？
0988デフォルトの名無しさん05/02/22 14:42:16
IE5 以上を入れているならばならば、IMultiLanguage にそんなメソッドがあったような？
0989デフォルトの名無しさん05/02/23 00:32:02
  SJISのシーケンスを受理するヒツジが一匹、
  EUCのシーケンスを受理するヒツジが二匹、
  UTF-8のシーケンスを受理するヒツジが三匹、
  .
  .
  zzz
0990デフォルトの名無しさん05/02/23 14:46:57
次スレは？
0991デフォルトの名無しさん05/02/23 14:54:35
【UTF8】文字コード変換 二匹目【SJIS】
0992デフォルトの名無しさん05/02/23 15:35:36
次スレ立てるなら文字コード統一スレとか
Unicodeスレとかがいいんじゃね？
0993デフォルトの名無しさん05/02/23 21:35:57
文字コード統一スレ 1文字目

プログラムにおける文字コードの取り扱いについて議論する統一スレッド
です。

ほぼ前スレ
【UTF8】文字コード変換【SJIS】
http://pc5.2ch.net/test/read.cgi/tech/1063177450/

参考ホームページ
Unicode Home Page
http://www.unicode.org/
Java Character Encodings
http://www.ingrid.org/java/i18n/encoding/
euc.JP: tech docs, BeOS tools
http://euc.jp/
ISO-IR - 2.8.1 Coding systems with Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm
ISO-IR - 2.8.2 Coding Systems without Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm


こんなんでどうですか？
0994デフォルトの名無しさん05/02/23 21:49:38
>>970
結局んとこは確率になるからなぁ
特に極短い文だとね

IMultiLanguage2::DetectInputCodepage
でもできるけど識別率はどんなもんだろ
試してないからわからんが中国語とかも識別できるだろうからいいかも？

あとは>>691ででてた
ttp://www.gprj.net/dev/tips/net/txtenc.shtml
これか？
これも識別率はわからん
C#だけど
0995デフォルトの名無しさん05/02/23 23:39:52
>>994
多分みんな作ったことあるんだろうな(笑) 俺もある。
短い文だと誤判定が多くなるねー。
いわゆる「半角カタカナ」などというものが滅んでしまえば、かなり楽なんだが。
# 正確にはカタカナのJIS X 0201の方

泥臭いけど、日本語としての特徴を使えば認識率はあがるよ。
漢字ばかりになることはないとか、ひらがなは半分以上であるとか、そういうので点数をつける。
EUC-JPとしてみれば10点、Shift-JISなら25点というふうに。
0996デフォルトの名無しさん05/02/23 23:45:39
もとの質問の対象がURL中の文字列つーのがきついよね。
0997デフォルトの名無しさん05/02/23 23:56:34
>>993 に一票
>>995 gaucheの実装がそんな感じだね。ソースも切り取りやすくてすてき。
099899305/02/23 23:58:43
立てられませんでした。どなたかお願いします。
0999デフォルトの名無しさん05/02/23 23:59:22
999
1000デフォルトの名無しさん05/02/24 00:00:14
1000ならunicode死滅
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。