[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 20:42 / Filesize : 257 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

文字コード統一スレ 1文字目



1 名前:とりあえず立ててみた [05/02/24 00:07:38 ]
プログラムにおける文字コードの取り扱いについて議論する統一スレッド
です。

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

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

281 名前:デフォルトの名無しさん mailto:sage [2005/08/04(木) 04:28:20 ]
Shift_JISのtext/plainやtext/htmlはどう扱うの? > Vista
(CSVなど全般的に)

>>280でいうと、追加した文字の方になったわけ?

282 名前:デフォルトの名無しさん mailto:sage [2005/08/04(木) 04:42:51 ]
>>281
CP932のマッピングに一切変更はない。
UCSのレパートリとしてしかサポートしないとずっと言い続けてた通り

283 名前:デフォルトの名無しさん mailto:sage [2005/08/04(木) 04:46:28 ]
もちろん「葛」みたいに字形が変わった字は結果的にShift_JISでも変わるけど、
それはたまたまで印刷標準字体をShift_JISで完全にサポートする気ははじめから
ないということ。

284 名前:デフォルトの名無しさん [2005/08/04(木) 23:33:35 ]
メーラーを作っているのですが、受信したメールが正しく表示されません。
JIS→Shift_JISの変換を勉強のためにも自力で変換したいのですが、
どう変換していいのか分かりません。
JISの文字コードをShift_JISに変換するときのアルゴリズムのヒントを教えていただけませんでしょうか。
1byteずつ読み込んでいって変換していかなきゃいけないというところまでは分かります。

285 名前:デフォルトの名無しさん mailto:sage [2005/08/04(木) 23:47:59 ]
勉強のために自力で変換したいという人が
検索もせずに質問するとはこれいかに

286 名前:デフォルトの名無しさん mailto:sage [2005/08/04(木) 23:50:32 ]
そのくらい調べられない奴には絶対にメーラーなんぞ作って欲しくは無い罠。

287 名前:デフォルトの名無しさん mailto:sage [2005/08/04(木) 23:52:21 ]
>>284
マジでやめてくれ。

288 名前:デフォルトの名無しさん mailto:sage [2005/08/04(木) 23:55:26 ]
言語は何よ?
>>8でどうなのよ。

perlならEncode.pmな。

289 名前:デフォルトの名無しさん mailto:sage [2005/08/04(木) 23:58:24 ]
Shift_JISのままBase64でエンコードしたほうが被害は少なそうだ。



290 名前:デフォルトの名無しさん mailto:sage [2005/08/05(金) 00:06:50 ]
iso-2022-jpと書けない時点で終どうしようもない。

291 名前:284 [2005/08/05(金) 00:31:17 ]
>勉強のために自力で変換したいという人が
>検索もせずに質問するとはこれいかに
ここ一週間調べたのですが、今ひとつ理解できるものが見つからないんです。
かなり運が悪いようです。

>そのくらい調べられない奴には絶対にメーラーなんぞ作って欲しくは無い罠。
メーラーが初めてなだけでネットワーク関係のプログラミング経験は豊富です。
バイトですが十数件のCGIも手がけました。
フリーで配布しているものもあり、結構多くの方に利用していただいています。
CGIはPerlで組んでいて、jcode.plを使っていました。

今回はC++で作っています。

292 名前:デフォルトの名無しさん mailto:sage [2005/08/05(金) 00:34:11 ]
とりあえず
つ libiconv

293 名前:デフォルトの名無しさん mailto:sage [2005/08/05(金) 00:35:00 ]
……てゆーか、jcode.pl読めばわかるんジャマイカ?

294 名前:デフォルトの名無しさん mailto:sage [2005/08/05(金) 00:35:17 ]
CGIってネットワークプログラミングに含まれていたのか。

この板の「ネットワークプログラミング」スレでCGIなんて書き込んだら
鼻で笑われるだけだけどな。

295 名前:デフォルトの名無しさん mailto:sage [2005/08/05(金) 00:42:33 ]
>>284
バベルじゃダメ?

296 名前:デフォルトの名無しさん [2005/08/05(金) 00:57:11 ]
> フリーで配布しているものもあり、結構多くの方に利用していただいています。 

フリーCGIで日本語(もちろん文字コードでんでんで)の扱いがクソレベルな物ばかり掴まされている漏れなので、
よろしければお前のCGIの配布サイトを教えてくだちい。


297 名前:デフォルトの名無しさん mailto:sage [2005/08/05(金) 01:12:38 ]
> かなり運が悪いようです。

悪いのは運ではなくて頭



298 名前:デフォルトの名無しさん mailto:sage [2005/08/05(金) 01:44:02 ]
>>284
inがJIS文字列で処理結果がshiftjis文字列のはず。バグあるはず。
そもそもcharがunsignedではない環境ではあぼーんする恐れあり。
std::string jis2sjis(const std::string& in) {
    bool is_ascii = true;
    std::string::const_iterator begin = in.begin(), end = in.end();
    std::string out;
    while (begin != end) {
        if (*begin == 0x1B) {
            if (*(begin + 1) == 0x24 && *(begin + 2) == 0x42) is_ascii = false;
            else if (*(begin + 1) == 0x28 && *(begin + 2) == 0x42) is_ascii = true;
            begin += 3;
            continue;
        }
        if (is_ascii) out.push_back(char(*begin));
        else {
            unsigned char hib = unsigned char(*begin), lob = unsigned char(*++begin);
            lob += (hib & 1) ? 0x1f : 0x7d;
            if (lob >= 0x7f) ++lob;
            hib = unsigned char(((hib - 0x21) >> 1) + 0x81);
            if (hib > 0x9f) hib += 0x40;
            out.push_back(char(hib));
            out.push_back(char(lob));
        }
        ++begin;
    }
    return out;
}

299 名前:デフォルトの名無しさん mailto:sage [2005/08/05(金) 01:47:50 ]
馬鹿は出てくるなよ…



300 名前:デフォルトの名無しさん mailto:sage [2005/08/05(金) 01:49:28 ]
>>291
完全に経験不足(ワラ

301 名前:デフォルトの名無しさん mailto:sage [2005/08/05(金) 01:54:45 ]
CJKV日中韓越情報処理
www.amazon.co.jp/exec/obidos/ASIN/4873111080/
Unicode標準入門
www.amazon.co.jp/exec/obidos/ASIN/4798100307/
国際化と日本語処理
www.amazon.co.jp/exec/obidos/ASIN/4756134815/

最後はJavaだけど、Unicode経由する場合のマッピング問題の理解にはよいでしょう。

302 名前:デフォルトの名無しさん mailto:sage [2005/08/05(金) 06:36:52 ]
Vista beta1の文字コード表がExtBに未対応なのを見ると確かにかなり暫定的なもの
である可能性は高そうだ
XPからそのまま移植しただけみたいな

303 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 18:42:06 ]
>>284
もし環境が Windows ならば、
MultiByteToWideChar -> WideCharToMultiByte と呼び出す。
IE5以上が入っていれば、
IMultiLanguage2 を取得して、ConvertString メソッドを呼び出す。
Windows 以外なら、
iconv とか、ICU とか、バベルとかその辺を使う。

304 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 18:52:06 ]
> 勉強のためにも自力で変換したい

305 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 03:13:50 ]
MultiByteToWideChar がISO-2022-JPを変換できるのはWin2k以降で
IE5より条件厳しいし。

306 名前:デフォルトの名無しさん mailto:sage [2005/08/13(土) 04:25:56 ]
文字コード支離滅裂なのって日本だけなの?

307 名前:デフォルトの名無しさん mailto:sage [2005/08/13(土) 07:06:58 ]
日本の文字コード体系を真似た中台韓も同様の状況じゃなかったっけ?

308 名前:デフォルトの名無しさん mailto:sae [2005/08/13(土) 07:45:36 ]
ベトナムも。

それからEU内はISO-8859-*で扱おうとするとやっかい。
隣国間のやりとりで結構問題になった。
島国日本に比べるとずっと近くて交流が多いから。

309 名前:デフォルトの名無しさん mailto:sage [2005/08/15(月) 14:04:21 ]
まあ日本語は他の2byte圏より多少歴史がある分、面倒なしがらみも多いわけだが



310 名前:デフォルトの名無しさん mailto:sage [2005/08/15(月) 15:07:27 ]
>>309
他の2byte文字を知っての言葉か?

311 名前:デフォルトの名無しさん mailto:sage [2005/08/15(月) 15:36:10 ]
>>310
他の2byte文字とやらの説明よろ

中国は国家権力でGB18030を強制できるので楽と言えば楽だよね。


312 名前:デフォルトの名無しさん mailto:sage [2005/08/15(月) 16:34:39 ]
>>311
質問を質問で返すなよ

313 名前:デフォルトの名無しさん mailto:sage [2005/08/15(月) 18:18:36 ]
>>312
311!=310なんで別に返してるわけじゃないよ。説明よろ。


314 名前:デフォルトの名無しさん mailto:sage [2005/08/15(月) 23:46:02 ]
何が聞きたいんだ

315 名前:デフォルトの名無しさん mailto:sage [2005/08/15(月) 23:48:45 ]
他の2byte文字圏が日本語に負けず劣らず面倒であることの証明だろ

316 名前:デフォルトの名無しさん mailto:sage [2005/08/16(火) 00:38:40 ]
他の2byte文字って何?

317 名前:デフォルトの名無しさん mailto:sage [2005/08/16(火) 00:52:27 ]
だからそれを説明しろといってるんだろ

318 名前:デフォルトの名無しさん mailto:sage [2005/08/16(火) 00:55:44 ]
スネークマンショーのつもりかよ

319 名前:デフォルトの名無しさん mailto:sage [2005/08/16(火) 01:36:30 ]
だ〜れ〜?



320 名前:デフォルトの名無しさん mailto:sage [2005/08/16(火) 03:14:03 ]
CJKVだろ
ttp://www.amazon.co.jp/exec/obidos/ASIN/4873111080
でも読め

321 名前:デフォルトの名無しさん mailto:sage [2005/08/18(木) 09:58:24 ]
ここでいいのかなぁ…Windowsで文字コードの判定に
IMultiLanguage2::DetectInputCodepageを使ってみました。Googleのページ
(UTF-8)すらまともに判定できていませんが、精度はこんなものでしょうか?

322 名前:デフォルトの名無しさん [2005/08/18(木) 10:01:59 ]
質問なので上げときます。

323 名前:デフォルトの名無しさん mailto:sage [2005/08/18(木) 11:35:39 ]
試さずに言うけど、googleのトップページなんて
文字量が少ないんだから判定しにくいのも当然なのでは?

324 名前:デフォルトの名無しさん mailto:sage [2005/08/18(木) 12:51:53 ]
文字コードの範囲限定してないし…

325 名前:321 mailto:sage [2005/08/18(木) 14:28:28 ]
トルコ語(Windows)と判定されました。

>>324
指定方法ってあるんでしょうか?

326 名前:デフォルトの名無しさん mailto:sage [2005/08/18(木) 14:49:00 ]
せっかくメタタグあるんだから、MLDETECTCP_HTML指定してやれば
まともに判断してくれまいか。

つうか、Win32Apiスレの話だよな、こんなの。

327 名前:デフォルトの名無しさん mailto:sage [2005/08/18(木) 17:13:11 ]
どうするよ「表」

文字コードが何種できてもいいけどさ
5c入るコードに文字振るのやめない?
どんどん増えてく

328 名前:デフォルトの名無しさん mailto:sage [2005/08/18(木) 18:19:13 ]
>>326
読み込むのがHTMLとは限らないんですよ。次のページのコードも
参考にしましたが…
DOBON.NET .NET Tips - 文字コードを判別する
ttp://dobon.net/vb/dotnet/string/detectcode.html

329 名前:デフォルトの名無しさん mailto:sage [2005/08/18(木) 18:29:38 ]
あきらめの悪い奴だな



330 名前:>>321 mailto:sage [2005/08/18(木) 18:32:19 ]
>>329
>>328のサイトので我慢します。

331 名前:デフォルトの名無しさん mailto:sage [2005/08/18(木) 18:42:33 ]
>>330
C++でもいいんならバベルはどうだ?
サンプリングしたデータを下にスコアリングを行うからかなりの精度で判別するぞ。

332 名前:321 mailto:sage [2005/08/18(木) 18:56:46 ]
>>331
ありがとうございます、Babelの存在を忘れていました。一応C♯とC++を
考えているので、考慮に入れたいと思います。

333 名前:デフォルトの名無しさん mailto:sage [2005/08/20(土) 00:41:24 ]
>>327
意味不明

334 名前:デフォルトの名無しさん mailto:sage [2005/08/20(土) 02:53:04 ]
>>333
もちろん意味わかっててそう言ってるんだよな。

335 名前:デフォルトの名無しさん mailto:sae [2005/08/20(土) 08:31:29 ]
0x22, 0x27, 0x2Fとかきりがないけどな。
いまやUTF-8の時代だし。

336 名前:デフォルトの名無しさん mailto:sage [2005/08/20(土) 13:34:04 BE:39938742- ]
>>328
このページの判定ルーチンは、一バイト目に0のあるバイナリファイルを食わせると、
配列の外にアクセスして例外が起きそうな気が。

337 名前:デフォルトの名無しさん mailto:sage [2005/08/20(土) 14:48:40 ]
まあ.NETならそれを足がかりにバッファオーバーフロー起こして攻略とかできないから

338 名前:デフォルトの名無しさん mailto:sage [2005/08/20(土) 14:52:07 ]
>>335
だいたいそれならISO-2022-JPを真っ先に滅ぼさなきゃならない
(実際日本語を想定してないメールゲートウェイでトラブルの元になってる)
ことには気付いてるんだろうかね

339 名前:デフォルトの名無しさん mailto:sage [2005/08/20(土) 23:16:21 ]
>>338
> (実際日本語を想定してないメールゲートウェイでトラブルの元になってる)

( ゚д゚)

(つд⊂)ゴシゴシ

(;゚д゚)

(つд⊂)ゴシゴシ
  _, ._
(;゚ Д゚)





340 名前:デフォルトの名無しさん mailto:sage [2005/08/21(日) 02:55:12 ]
ESCを捨てるゲートウェイの話とか聞いたことない?

341 名前:デフォルトの名無しさん mailto:sage [2005/08/21(日) 06:57:30 ]
ISO-2022-JP の問題なら今は ESC よりも瘢雹だろう。


342 名前:デフォルトの名無しさん mailto:sage [2005/08/21(日) 10:38:35 ]
amp;(瘢雹)は挟まるだけだからまだマシ
<→&lt;や>→&gt;はその後が全部化ける

343 名前:デフォルトの名無しさん mailto:sage [2005/08/21(日) 17:22:03 ]
utf-8の日本語
すでに複数存在するって本当?

344 名前:デフォルトの名無しさん mailto:sage [2005/08/22(月) 00:42:02 ]
>>338
いつの話だよ。
MIMEエンコードもしてないメールなの?

Structual fieldなら問題外だし。



345 名前:デフォルトの名無しさん mailto:sage [2005/08/22(月) 04:15:44 ]
瘢雹でぐぐればそういうメールアーカイブがバリバリ現役なのは分かると思いますが。
いくら綺麗事を並べたところでascii圏の認識なんてそんなもん。

346 名前:デフォルトの名無しさん mailto:sage [2005/08/22(月) 19:39:20 ]
メールアーカイブなんぞメールのトラブルとは何の関係もないやんけ


347 名前:デフォルトの名無しさん mailto:sage [2005/08/22(月) 22:19:43 ]
>>343
MicrosoftとAppleとLinux(つーかglibc?)とJavaとJISで全部ちょこっとづつ違うんじゃなかったっけ。
「〜」等の記号のコードポイントが違ったり正規化表現が違ったり。(正規化はUnicodeの範疇だけど)

348 名前:デフォルトの名無しさん mailto:sage [2005/08/23(火) 05:22:31 ]
>>346
メールのトラブルじゃなきゃ何が起きてもいいわけじゃないし

349 名前:デフォルトの名無しさん mailto:sage [2005/08/23(火) 07:05:13 ]
>>347
それはUTF-8ではなくShift_JISの方
そして違うのはコードポイントというかUCSへのマッピング



350 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 02:10:00 ]
>>349
でも全部UTF-8で処理するCGI作ってWinとMacからそれぞれ「スケジュール2005年4月〜9月」などと入力してPOSTしたら、「〜」が異なるコードポイントでやってきますですよ?


351 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 02:17:29 ]
そもそもWinとMacでは同じに見えても違う波線だから当然と言えば当然。

352 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 06:44:13 ]
>>350
だからUTF-8の方は一種類なんだって。
1. あるUTF-8にはXXXという文字があるけど違うUTF-8にはない、みたいなことはない。
2. あるUTF-8のYYYというコードポイントの文字はZZZだけど違うUTF-8では別の文字、みたいなこともない。

でもShift_JISでは、1. も2. も現実に起こってるの。
で、そのいろいろ微妙に違うShift_JIS達をユニコードに変換するときに、それぞれがいろいろ微妙に違う変換テーブルを使ってるのが原因。
UTF-8側の問題じゃないの。OK?

353 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 07:54:01 ]
原規格との変換テーブルを規定しないUnicode側の問題だろ。

354 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 08:26:17 ]
むかしは規定してたけどな。
きっと管理しきれなくなってやめたんだろうなぁ……。
ちゃんとやろうとするなら、SJISだけでいくつの方言を面倒みないといけないやら。

355 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 08:32:03 ]
> でも全部UTF-8で処理するCGI作って


356 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 08:39:26 ]
ていうかユニコード側が規定してもベンダが従うとは限らないし、
ベンダはマッピングを変更したり増やしたりもするだろうし、
ユニコード側にそれの管理をさせるのは無茶だろ。

混乱の元だってのは確かにその通りかもしれないけど、他にどうしろと?

357 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 08:52:17 ]
よしUTF-128ぐらいで手を打とうじゃないか
言語問わず、今現在使われてる部分は意地でも文字振りません

358 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 16:22:59 ]
Unicodeがマッピング・テーブルを公開していた頃も
ベンダはそれに従ってなかったし。

359 名前:デフォルトの名無しさん [2005/08/24(水) 18:55:15 ]
>>357
UTF-8でも、36bitコードまでリニアな拡張で扱えるが。



360 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 19:11:20 ]
それはUTF-8ではない。

361 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 19:31:36 ]
>36bitコード
( ´д)ヒソ(´д`)ヒソ(д` )

362 名前:デフォルトの名無しさん [2005/08/24(水) 20:05:55 ]
>>360
だから、「UTF-8の *リニアな拡張* 」だって言ってんだろ?
先頭バイトの上位ビットに7個1が並んでいたら、↓ 36bitになるだろうが。

11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx


363 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 21:23:35 ]
UTF-8 符号化では 0xfe と 0xff のバイトは絶対に使用しない。

364 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 21:35:56 ]
拡張って言葉の意味が分からないの?

365 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 21:36:49 ]
ちなみに0xfeと0xffを使わない理由はUTF-16のBOMが100%判別できるようにするためだな

366 名前:347=350 mailto:sage [2005/08/24(水) 22:50:04 ]
>>351 >>352
ええと、理屈はわかるんですが、現実として、WinとMacとLinuxの混在環境
で全部UTF-8に統一しても、人間から見たら「同じ」と認識されるはずの
ものが異なるバイトパターンを構成するために、システム的には「同じ」
にならないと言う問題があって、これを解決するためには、どこかで
UTF-8 to UTF-8変換をする必要があるのではないでしょうか。

この状況を称して「UTF-8の日本語はすでに複数存在する」と言っても
過言ではない、と思うんですけれども。


367 名前:デフォルトの名無しさん mailto:sage [2005/08/24(水) 22:59:33 ]
> UTF-8 to UTF-8
お前が言わんとすることに似たようなことは既に存在する。
www.google.co.jp/search?hl=ja&c2coff=1&q=Unicode+%E6%AD%A3%E8%A6%8F%E5%8C%96&lr=lang_ja

368 名前:デフォルトの名無しさん [2005/08/24(水) 23:02:00 ]
>>366
UTF-8は文字エンコードの規格。
見た目は同じで違う文字、というのは文字セットの問題。
だから、UTF-8云々の議論はかみ合わない。

それに、バイトパターンが一致しないのは、BOM有無とか改行の問題じゃないの?
あるいは、UTF-8なら本来2バイトで表せる文字を3バイトで記録するような誤った実装の
アプリを使っているとか、サロゲートペアをそのまま2文字で扱うエラーとか…

369 名前:366 mailto:sage [2005/08/25(木) 00:49:19 ]
>>367
ぅぃ。問題自体が今さらなのは承知しております。

が、その対策が、この関数/メソッドを呼べばOK!にはなってなくて、
未だにアプリケーション毎の個別対応に依存しているようにしか
見えないのはどうしたものかと。

Javaの世界ですら、10年前から既知の問題なのにどこにも(ベンダ依存
マッピング問題を含む)統一されたフレームワークが見あたりません……。

私が知らないだけだったら、是非教えてください。




370 名前:366 mailto:sage [2005/08/25(木) 01:02:13 ]
>>368
厳密にはそうなんですが、現状は、
Conten-Type: text/html; charset="UTF-8"

export LANG=ja_JP.UTF-8
のように、文字セットの情報は交換してないので、事実上UTF-8というだけで
文字セットまで含んでしまってます。せめてUTF-8-msとかUTF-8-appleのよう
に区別してくれたら〜(;_;)

ちなみにバイトパターンについては、「スケジュール4月〜9月」という文字列
を、Windowsのメモ帳とMac OS Xのテキストエディットで入力、エンコーディ
ングはどちらもUTF-8で保存すると、以下のようになります。
od -j 3 -tx1 win.txt (BOMが入るので頭3バイト切り捨ててます)
0000003 e3 82 b9 e3 82 b1 e3 82 b8 e3 83 a5 e3 83 bc e3
0000023 83 ab 34 e6 9c 88【ef bd 9e】39 e6 9c 88
od -tx1 mac.txt
0000000 e3 82 b9 e3 82 b1 e3 82 b8 e3 83 a5 e3 83 bc e3
0000020 83 ab 34 e6 9c 88【e3 80 9c】39 e6 9c 88
おや、MacでもNFCなのか。WebDAVのリクエストはNFDで投げてくるので、
てっきりNFDになるのかと……。


371 名前:デフォルトの名無しさん mailto:sage [2005/08/25(木) 02:16:26 ]
MACのwebdavリクエストってかなり行儀悪いよねえ

俺も複数あるようにとれちゃうけど、
とにかくあれだUTF-8って統括してるってのりじゃないんだ

マッピング誰がつけたの?


372 名前:デフォルトの名無しさん mailto:sage [2005/08/25(木) 05:15:33 ]
>>370
厳密な指定が無い限りユーザが何を入力するかは好み(運)次第でしょ。
MacOSXのinput methodだとU+301C WAVE DASHの方が入力し易いけど、
U+FF5E FULLWIDTH TILDEも入力できるし、WindowsのIMEで「から」を
入力するとU+301C WAVE DASHになるみたいだし。

MacOSXではHFS+との互換性や同じファイル名を作らせないためにVFSは
NFDにnormalizeしてるけど、NFC/NFD/複雑な合成文字のいずれも扱えます。
developer.apple.com/ja/qa/qa2001/qa1173.html

373 名前:デフォルトの名無しさん mailto:sage [2005/08/25(木) 08:02:25 ]
>>370
あほ? (w

374 名前:デフォルトの名無しさん mailto:sage [2005/08/25(木) 08:48:22 ]
>>370
だからUTF-8の問題ではないだから、UTF-8-msとかUTF-8-appleとかを作って解決すべき問題ではないの。

375 名前:デフォルトの名無しさん mailto:sage [2005/08/25(木) 08:54:41 ]
euc.jp/i18n/ucsnote.ja.html
これだろ?

UnicodeじゃなくてJIS X 0208に限っても、
−〜ー─と利用者が入力し間違う余地はある。

これを文字コード(のエンコーディング)の問題だと思う奴は馬鹿じゃないの?

376 名前:デフォルトの名無しさん mailto:sage [2005/08/25(木) 14:11:34 ]
>>370
これ読んで出直し。
www.unicode.org/reports/tr17/


377 名前:デフォルトの名無しさん mailto:sage [2005/08/25(木) 15:23:50 ]
Content-Typeがutf-8で萎えた、こだわって欲しかった

こんなんに任せてっからだめなんだよ!そのうちUとuの変換表作り始めるぜ

378 名前:デフォルトの名無しさん mailto:sage [2005/08/26(金) 06:02:23 ]
>>374
GNU libiconvはNFDが扱えないため、DarwinのlibiconvはUTF-8にだけNFCへの
normalizerを追加してUTF-8-MACと称してます。
Darwin的にはUTF-8の問題ではない物をUTF-8-APPLEを作って解決するのはありw

379 名前:デフォルトの名無しさん mailto:sage [2005/08/26(金) 07:13:57 ]
そもそもAppleのNFDって互換漢字をNormalizeしないよな
されたらそれはそれで困るけど。



380 名前:デフォルトの名無しさん mailto:sage [2005/08/26(金) 07:15:27 ]
↑はHFS+に格納する場合

381 名前:デフォルトの名無しさん mailto:sage [2005/08/26(金) 15:03:48 ]
>>380
詳しく






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<257KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef