文字コード統一スレ 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 2 名前：デフォルトの名無しさん mailto:sage [05/02/24 00:08:53 ] 文字コードを統一するのか？ アホか？ 3 名前：デフォルトの名無しさん mailto:sage [05/02/24 00:37:16 ] アホw 4 名前：デフォルトの名無しさん mailto:sage [05/02/24 00:55:22 ] 「文字コード乱立スレ」ってわけにもいかんし… 5 名前：デフォルトの名無しさん mailto:sage [05/02/24 01:03:38 ] 新スレ発見！ 乙 >>1 リンク貼る前に埋めんな＞前スレ999-1000 6 名前：テンプレ作った人 mailto:sage [05/02/24 01:17:13 ] >>1 乙 7 名前：デフォルトの名無しさん [05/02/24 01:26:49 ] Win32 API で UTF16 を EUC-JP(-ms) にするときは、 　UTF16 →(WideCharToMultiByte)→ CP932 →(自分でがんがる)→ EUC-JP が普通なのかなあ・・・。 ドキュメントでは WideCharToMultiByte の CodePage に 51932 を指定すれば一発でできそうに 書いてあるのに、実際やるとなんでﾀﾞﾒなんだよ（ｗ CP20932 は微妙に変換ルールが違うみたいだしなあ(´･ω･`) 8 名前：デフォルトの名無しさん mailto:sage [05/02/24 01:41:13 ] IMultiLanguage Interface msdn.microsoft.com/library/default.asp?url=/workshop/misc/mlang/reference/ifaces/imultilanguage/imultilanguage.asp これは対応している予感。使ったことないから知らないけど。 9 名前：デフォルトの名無しさん mailto:sage [05/02/24 01:44:01 ] 文字コードを統一？ TRONコードの出番か！ 10 名前：デフォルトの名無しさん mailto:sage [05/02/24 03:22:46 ] >>7 俺は変換テーブルを実行ファイルに組み込んでいる。 200KBぐらいだけど、これで特に問題はない。 11 名前：デフォルトの名無しさん mailto:sage [05/02/24 03:26:24 ] ところでUTF16なんてあるの？ 12 名前：デフォルトの名無しさん mailto:sage [05/02/24 03:31:23 ] アホなスレタイだなｗ 「統一」いらんじゃんｗ 13 名前：デフォルトの名無しさん mailto:sage [05/02/24 03:41:04 ] とういつ【統一】 まとまりのないばらばらな物事を１つのものにまとめること。 新しい文字コードでも作るつもりなのか？このスレ 14 名前：デフォルトの名無しさん mailto:sage [05/02/24 03:43:22 ] 1も読めないのか。読んで言っているのなら白痴だな。 15 名前：デフォルトの名無しさん mailto:sage [05/02/24 03:44:03 ] >>7 うるさいことを言わなければコードページ20932がなんとなくEUC-JPに近い。 JIS X 0208 にない文字は変になるけど。 16 名前：デフォルトの名無しさん mailto:sage [05/02/24 03:48:20 ] スレタイも読めないのか。読んで言っているのなら白痴だな。 17 名前：デフォルトの名無しさん mailto:sage [05/02/24 04:05:24 ] >>13 辞書を引用し、都合のいい解釈をする >>16 人の言葉をモジって言い返す アホの典型 18 名前：デフォルトの名無しさん mailto:sage [05/02/24 04:26:06 ] ではスレタイはどんな意味で統一と入れたのか 19 名前：デフォルトの名無しさん [05/02/24 04:45:00 ] 早く各種ローカルコードからUnicodeへのマッピングを統一してくれ． あと，サロゲートペアってもうなくならんのだろうな… 結局固定ビット長で処理できねーじゃんか． 20 名前：デフォルトの名無しさん [05/02/24 07:08:44 ] まずスレタイの意味を統一すべきだな。 21 名前：デフォルトの名無しさん mailto:sage [05/02/24 10:18:07 ] >>19 32bitで固定 22 名前：テンプレ作者 mailto:sage [05/02/24 10:57:35 ] 他に文字コード関連のスレを立てる人がいないように「統一」の 文字を入れました。もう立っているみたいですが。 23 名前：デフォルトの名無しさん mailto:sage [05/02/24 11:01:09 ] 普通「総合」じゃないのかな？ 24 名前：テンプレ作者 mailto:sage [05/02/24 11:06:15 ] ま、洒落と言うことにしといてくださいな。 25 名前：デフォルトの名無しさん mailto:sage [05/02/24 11:46:41 ] 統一だろうが総合だろうがどうでもいいんだが・・・ 26 名前：デフォルトの名無しさん mailto:sage [05/02/24 12:01:35 ] >>7,15 ttp://msdn.microsoft.com/library/en-us/intl/unicode_81rn.asp によるとCP20932はJIS X 0208-1990 & 0121-1990だな。 27 名前：デフォルトの名無しさん [05/02/24 12:42:27 ] >>21 そりゃなんでもあまりにもスカスカ過ぎないか？ まぁメモリ潤沢な昨今のパソコンならそれでもいいと思うけど、 やっぱり2バイトくらいにとどめておいて欲しかった。 つーか、4バイトで固定するならそもそもサロゲートペアいらねーじゃん。 次の面に素直にもってくりゃよかったんだ。 28 名前：デフォルトの名無しさん mailto:sage [05/02/24 12:53:11 ] > つーか、4バイトで固定するならそもそもサロゲートペアいらねーじゃん。 その通り。サロゲートペアは2バイトという幻想にとらわれた故の特殊事情であって、 もはやUnicodeとしてはサロゲートペアなんぞ使わないのが正しい。 29 名前：デフォルトの名無しさん [05/02/24 13:01:21 ] さすがに第1群以降は使わないよな？ せめて最上位バイトを内部処理用フラグとして使いたい。 まぁ外に出すときにはクリアするが。 30 名前：デフォルトの名無しさん mailto:sage [05/02/24 13:17:13 ] 確かに文字コードは頭が痛くなる問題ですね。 早く標準が固まって欲しいです。 ただ、右から左にテキストを書くやつ(アラビア辺り?)とかは 絶望的じゃなかろうかと思ってみたりみなかったり。 31 名前：デフォルトの名無しさん mailto:sage [05/02/24 13:50:09 ] >>30 標準ならあるぞ。たくさん(笑) right-to-leftの何が絶望的なんだろう? ふつうにWindowsでも扱えるは ずだけど。 32 名前：デフォルトの名無しさん mailto:sage [05/02/24 14:08:58 ] ストリームの出現順の問題のことを言ってるのかな？ 33 名前：デフォルトの名無しさん [05/02/24 14:10:04 ] >>30 日本語は縦書きなんだが 34 名前：デフォルトの名無しさん mailto:sage [05/02/24 14:48:10 ] >>30 描画方向が違うだけだと思うYO 35 名前：デフォルトの名無しさん mailto:sage [05/02/24 15:53:10 ] 日本でも昔の看板とかは右から左 36 名前：デフォルトの名無しさん mailto:sage [05/02/24 16:03:14 ] 笑止！それは一行一文字の縦書きにすぎぬわ！ 37 名前：デフォルトの名無しさん mailto:sage [05/02/24 16:13:22 ] そんなわけで本文なんかを横書きにする場合では、 相当古くから(もちろん明治維新よりは後だが) 今と同じく左から右へ書いていたそうな。 38 名前：デフォルトの名無しさん mailto:sage [05/02/24 18:00:17 ] 左←右圏でも縦書きされる場合があるらしい。看板とか。 39 名前：デフォルトの名無しさん mailto:sage [05/02/24 18:24:23 ] まさにアホなスレタイ 文字表示雑談スレ 40 名前：デフォルトの名無しさん mailto:sage [05/02/24 18:30:54 ] 右から左に書く場合でも、数値だけは逆だったりするよね。 日本語にたとえれば、「。すで年2005は年今」みたいな感じ。 41 名前：デフォルトの名無しさん mailto:sage [05/02/24 18:47:29 ] アホなスレタイだとアホしかよってこない。 スレタイってやっぱり大事なんだね。 42 名前：7 [05/02/24 21:50:15 ] >>8 動作要件に IE4 以上というのが気に掛かる・・・。 >>10 その方法を考えたけど、実行ファイルが肥大化するのと、他の Windows アプリとの 　　データ互換性が保証できなくなるのがネック・・・。 >>15 >>26 一見よさげだけど、たとえば「〜」なんか化けてしまうのが致命的・・・。 みなさんどうもでつ。もう少しいろいろ検討してみまつ。 43 名前：デフォルトの名無しさん mailto:sage [05/02/24 22:52:42 ] >>27 ISO 10646 dis v.1 44 名前：デフォルトの名無しさん mailto:sage [05/02/25 10:20:01 ] >>41　意外とまともな事言ってる人もいると思うが。 45 名前：デフォルトの名無しさん [05/02/25 10:22:38 ] suika.fam.cx/~wakaba/-temp/wiki/wiki?ISO%2FIEC%2010646 >>43 それって、この表だとどの規格のこと？ 46 名前：デフォルトの名無しさん mailto:sage [05/02/25 11:03:27 ] >>45 DIS 10646:19911990-12-061st DIS 47 名前：デフォルトの名無しさん mailto:sage [05/02/25 12:02:10 ] >>43 寝言言ってねえで素直にUTF-32でも使っとけ。 48 名前：デフォルトの名無しさん mailto:sage [05/02/25 12:26:02 ] >>44 Unicodeは複数コードポイントを組合わせる可変長表現なのに、 相変わらず２バイト４バイト固定とか言ってますが。 49 名前：デフォルトの名無しさん mailto:sage [05/02/25 12:54:57 ] 結局シフトJISに統一されるんだよな 50 名前：デフォルトの名無しさん [05/02/25 13:29:46 ] （・∀・）ｳﾝｺｰ 51 名前：デフォルトの名無しさん [05/02/25 13:56:16 ] >>48 その「固定」ってのは sizeof wchar_t の話だと思う 52 名前：デフォルトの名無しさん [05/02/25 14:01:52 ] 総合といいたかったのか。なるほど。 53 名前：デフォルトの名無しさん [05/02/26 00:51:25 ] >>51 Linux の gcc だと sizeof(wchar_t) == 4 で、 Windows の VC++ だと sizeof(wchar_t) == 2 だったり。 54 名前：デフォルトの名無しさん mailto:sage [05/02/26 01:06:18 ] 将来の主流は、__wchar64_t になると予言しておく。 55 名前：デフォルトの名無しさん [05/02/26 01:41:31 ] typedef unsigned int wchar_t; が typedef unsigned _int64 swchar_t; になって typedef unsigned _int128 xwchar_t; になって typedef unsigned _int256 uwchar_t; になって（ｒｙ 56 名前：Winかよ!? mailto:sage [05/02/26 01:44:50 ] >>55 unsigned _int64って何だよ… いまや#include <stdint.h>で、uint64_tじゃないのか? 57 名前：デフォルトの名無しさん mailto:sage [05/02/26 02:04:17 ] >>51 wchar_tはUnicodeが入るとは限らないんだけど、そのままUTF-16やUTF-32 を突っ込んでる実装が多いから良しと仮定しましょう。 wchar_tにUTF-32が並んでいても、そこから文字（grapheme）単位に処理 するにはステートマシンで区切りを探さないといけない。 　www.unicode.org/reports/tr29/ こういったことを理解しての発言には見えない。 加えて、ICUもそうだけどUTF-16が処理対象の場合はサロゲート込みで処 理されるからサロゲートの有無で手間は全く変わらない。 58 名前：デフォルトの名無しさん mailto:sage [05/02/26 02:04:28 ] >55 さすがに地球外知性とデータ送受信するようにでもならないとそこまでは…… いや、そうなったらそうなったで、向こうのコード体系を強引に押しつけられる悪寒orz 59 名前：デフォルトの名無しさん mailto:sage [05/02/26 11:29:58 ] >>57 > そこから文字（grapheme）単位に処理 > するには 誰もそんなこと書いてないと思うが。 60 名前：デフォルトの名無しさん mailto:sage [05/02/26 12:57:35 ] 文字単位に処理することはあり得るだろう？ 61 名前：デフォルトの名無しさん [05/02/26 14:23:12 ] あり得るけど、それこそ Shift JIS や EUC-JP でAPI/システムコールレベルでは バイト列として扱い、それを文字に組み上げるのは各アプリケーションの責任という 考え方もあった罠。 この考え方を Unicode にあてはめてみたり、とか。char を wchar_t に変えて。 62 名前：デフォルトの名無しさん mailto:sage [05/02/26 14:42:33 ] >>61 > あり得るけど、それこそ Shift JIS や EUC-JP でAPI/システムコールレベルでは > バイト列として扱い、それを文字に組み上げるのは各アプリケーションの責任という > 考え方もあった罠。 それほど変ってないような… そしてその「アプリケーションの責任」の技術的な部分の研究を、 一番行っているのはUnicodeの世界なのでは? 63 名前：デフォルトの名無しさん [05/02/26 17:38:26 ] 結局「一文字」単位に扱おうとすると, ステートマシンは必要になるのか… なんかあんまり変わってないな，昔と. 64 名前：デフォルトの名無しさん mailto:sage [05/02/26 20:24:52 ] >>63 そういう領域はUnicodが解決しようとした問題領域に含まれていないものと思われ。 65 名前：デフォルトの名無しさん [05/02/26 20:48:58 ] 結局は、ASCII 系のコードしかなかった頃は基本単位（char） 1 つに 英数字程度しか入らなかったけど、Unicode では基本単位（wchar_t） 1 つに 漢字とかも入れられるようになりますたよ。 でも、国際化を考えるときは 1 基本単位＝ 1 文字と仮定するのはやめようね。 というのは変わってないということか。 66 名前：デフォルトの名無しさん mailto:sage [05/02/27 00:27:02 ] www.hatena.ne.jp/1105667960 67 名前：57 mailto:sage [05/02/27 00:45:01 ] >>59 UAX #29でも触れられているけど、文字（grapheme）単位に 処理できないと文字列の文字数を得たり、分解したりできな いのはもちろん、比較や検索も正しく行なえない。 68 名前：デフォルトの名無しさん mailto:sage [05/02/27 01:24:33 ] normalize してもコードポイント一つであらわせない文字は正しく扱えません としても、それほど困らないんだよなあ。 実装コストに見合うメリット無いし。 69 名前：デフォルトの名無しさん [05/02/27 02:13:31 ] >>67-68 内部文字コードが Unicode 化された Visual Basic 4.0 以降や Java なんかでは、 「文字列をバイト単位で切り出すにはどうすればよいですか？」という質問が 必ず FAQ になってるよな（ｗ 70 名前：デフォルトの名無しさん mailto:sage [05/02/27 02:34:30 ] U+F92FとU+F98DのkIRG_KSourceが間違ってる件について これどうやったら修正させることができるんですか 韓国のNational Bodyが言い出さない限り何人たりとも修正できないんでしょうか とりあえずUnicode 4.1.0βのレビューで指摘してみたけどシカトされますた ほかの指摘事項はちゃんと反映されてたから指摘そのものは届いてるはず 71 名前：デフォルトの名無しさん mailto:sage [05/02/27 13:12:20 ] ほかの指摘事項はたまたまほかの人が同じ指摘をしたんだろう 72 名前：デフォルトの名無しさん mailto:sage [05/02/28 07:13:00 ] 5件あって5件ともたまたま別の人が同時に指摘したってあんまりありそうにないような 「報告ありがとう。Unihanの専門家に転送しとくよ彼が今日中に反映してくれるだろう」 みたいな返信もちゃんと返ってきたし。 正規表現が間違いだらけだったから正しいの書いて送ったけど他の誰かが一字一句 ピッタリ一致するような正規表現をたまたま同時に送ってたとかありえなーい。 つーかスクリプトに通して検査するだけで見つかるような誤りがなんでボロボロ 出てきますか? なんのために機械可読な形式で提供してますか? 73 名前：デフォルトの名無しさん mailto:sage [05/02/28 08:42:52 ] もう一回聞いてみればいいじゃん 74 名前：デフォルトの名無しさん mailto:sage [05/03/01 01:46:45 ] 戸籍やってる身からすれば 康煕字典体はきっちり入っていないと 75 名前：デフォルトの名無しさん [05/03/02 08:36:34 ] ところで，Unicode って既存のコードとのラウンドトリップは考慮されてるの？ つまり Unicode に変換されたとたん，元のコードでは区別されていた文字が 同じ文字にマップされたりはしないの？ それはいわゆる機種依存文字も含めて？ 76 名前：デフォルトの名無しさん mailto:sage [05/03/02 08:53:12 ] 文字コードを作る人は馬鹿ですか？ なんで固定バイト数にしないんだよ。 先頭数ビットを国コードにして残りを文字コードに割り当てる。 似ている文字でも国ごとに別の文字コードにするべきだ。 そして検索の機能として文字コード検索と、文字形検索の二つに分ける。 77 名前：デフォルトの名無しさん mailto:sage [05/03/02 09:06:12 ] >>76 UNICODE棄てれば実現可能かもね 78 名前：デフォルトの名無しさん mailto:sage [05/03/02 10:18:45 ] >>76 そしてPhishingが横行 79 名前：デフォルトの名無しさん mailto:sage [05/03/02 10:38:34 ] 多言語ドメインなんてくだらないものは捨てちまえ。 80 名前：デフォルトの名無しさん mailto:sage [05/03/02 14:57:31 ] >>76 Emacsの内部コードがそんな感じよ。文字列表現はマルチバイトだけど。 国ごとじゃなくて文字集合ごとだけど実質あまり変わらん。 81 名前：デフォルトの名無しさん mailto:sage [05/03/02 15:50:16 ] マジな話、文字形検索（文字コードではなく文字の形で 検索すると言う意味）って考え方ないの？ 同じ形の字でも国が違えば検索に引っかからない方がいいだろうし、 同じ国でちょっと違う形の字でも同じとして検索した方がいいこともあるだろうし、 国は分からないけど、すべての国対象で似ている字を検索したいこともあると 思うんだけどなぁ。 82 名前：デフォルトの名無しさん mailto:sage [05/03/02 15:55:33 ] 1 I l | ! i │ �@ �T (以下略)をどこまで一緒にするのやら 83 名前：デフォルトの名無しさん mailto:sage [05/03/02 16:54:58 ] >>75 文字コードA →Uniocde→文字コードA と、元に戻せることは配慮されてる。 そのために互換用文字とか元規格分離の原則とかがあるわけで。 機種依存文字は、例えばJIS X 0208のShift_JISとMicrosoftのCP932と Appleの拡張Shift_JISは「別の文字コード」なので、Unicodeを介した それぞれの変換で情報が失われないことは配慮されない、という扱い。 84 名前：デフォルトの名無しさん [05/03/02 19:56:53 ] <とくを一緒にされなかっただけでも不幸中の幸い 85 名前：デフォルトの名無しさん mailto:sage [05/03/02 23:31:01 ] へとヘは？ 86 名前：デフォルトの名無しさん mailto:sage [05/03/03 02:37:43 ] タと夕とか トと卜とか 87 名前：デフォルトの名無しさん mailto:sage [05/03/03 04:42:46 ] ロとか口とか 88 名前：デフォルトの名無しさん mailto:sae [05/03/03 11:42:20 ] (以下略 89 名前：デフォルトの名無しさん mailto:sage [05/03/03 16:02:46 ] C++ で文字コード変換したいと思った場合、 Windows + IE5.5 ならば、IMultiLanguage3 を通して変換すればいいが、 UCS-4 のコードから、文字種別などの文字情報を取得するライブラリが OS標準にないというのが悲しい。 90 名前：デフォルトの名無しさん mailto:sage [05/03/03 16:09:52 ] Windowsの事しか考えられないバカは去ってくれ。 91 名前：デフォルトの名無しさん mailto:sage [05/03/03 18:27:33 ] >>90 そりゃ言いすぎ(w けど、 > Windows + IE5.5 ならば、IMultiLanguage3 を通して変換すればいいが、 つーのが、もうスレの主旨には全く合わないな。 それが良いかどうか語りたいようなヲタの住むスレなんだから。 92 名前：デフォルトの名無しさん mailto:sage [05/03/07 22:10:55 ] >>73 Unihan-4.0.1d4で修正されてますた。 つーかよく見たらUnihan-4.0.1d3のヘッダにも > Similarly, U+F92F should map to kIRG_KSource 0-523E, not 0-523F, and U+F98D should > map to kIRG_KSource 0-663C, not 0-663D. って追加されてた。正直スマンカッタ＞unicode.orgの中の人 93 名前：デフォルトの名無しさん mailto:sage [05/03/07 22:13:29 ] Unihan-4.1.0d4とUnihan-4.1.0d3の間違い 94 名前：デフォルトの名無しさん [05/03/08 01:19:00 ] iconv(3) の引数 inbuf の型が、glibc 版だと char** になってて libiconv 版だと const char** なのがイヤン 95 名前：デフォルトの名無しさん mailto:sage [05/03/10 11:13:14 ] >>94 SUS的にはchar**が定義らしいが、現実的にはconst char**じゃないと 面倒なんだよな。 96 名前：デフォルトの名無しさん [05/03/10 13:04:58 ] >>83 に関連した疑問なんだが，各種日本語文字コード，Unicode間で 縦横無尽にマッピングしまくッっても安全な集合って どこかで定義されてない？？ 97 名前：デフォルトの名無しさん mailto:sage [05/03/10 15:21:23 ] サロゲートうんこ 98 名前：デフォルトの名無しさん mailto:sage [05/03/10 21:21:44 ] 内部はgrapheme clusterを単位にした固定長コードにでもしないと 面倒でやってられんぞ 99 名前：デフォルトの名無しさん [05/03/11 00:57:47 ] >>95 www.opengroup.org/onlinepubs/007908799/xsh/iconv.html では const 付きだけど www.opengroup.org/onlinepubs/007908799/xsh/iconv.h.html には const 付いてない(つД`) 100 名前：デフォルトの名無しさん mailto:sage [05/03/11 02:55:46 ] >>96 \~￣―＼〜‖…−￥¢£¬とか CP932におけるNEC選定IBM拡張文字 とか 古えの半角ｶﾅ とかの話?

---

---

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

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