2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

ほぼ前スレ
【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

2 :デフォルトの名無しさん:05/02/24 00:08:53
文字コードを統一するのか?
アホか?

3 :デフォルトの名無しさん:05/02/24 00:37:16
アホw

4 :デフォルトの名無しさん:05/02/24 00:55:22
「文字コード乱立スレ」ってわけにもいかんし…

5 :デフォルトの名無しさん:05/02/24 01:03:38
新スレ発見! 乙 >>1
リンク貼る前に埋めんな>前スレ999-1000


6 :テンプレ作った人: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 を指定すれば一発でできそうに
書いてあるのに、実際やるとなんでダメなんだよ(w
CP20932 は微妙に変換ルールが違うみたいだしなあ(´・ω・`)

8 :デフォルトの名無しさん:05/02/24 01:41:13
IMultiLanguage Interface
http://msdn.microsoft.com/library/default.asp?url=/workshop/misc/mlang/reference/ifaces/imultilanguage/imultilanguage.asp
これは対応している予感。使ったことないから知らないけど。

9 :デフォルトの名無しさん:05/02/24 01:44:01
文字コードを統一?
TRONコードの出番か!

10 :デフォルトの名無しさん:05/02/24 03:22:46
>>7
俺は変換テーブルを実行ファイルに組み込んでいる。
200KBぐらいだけど、これで特に問題はない。

11 :デフォルトの名無しさん:05/02/24 03:26:24
ところでUTF16なんてあるの?

12 :デフォルトの名無しさん:05/02/24 03:31:23
アホなスレタイだなw
「統一」いらんじゃんw

13 :デフォルトの名無しさん:05/02/24 03:41:04
とういつ【統一】
まとまりのないばらばらな物事を1つのものにまとめること。

新しい文字コードでも作るつもりなのか?このスレ

14 :デフォルトの名無しさん:05/02/24 03:43:22
1も読めないのか。読んで言っているのなら白痴だな。

15 :デフォルトの名無しさん:05/02/24 03:44:03
>>7
うるさいことを言わなければコードページ20932がなんとなくEUC-JPに近い。
JIS X 0208 にない文字は変になるけど。



16 :デフォルトの名無しさん:05/02/24 03:48:20
スレタイも読めないのか。読んで言っているのなら白痴だな。

17 :デフォルトの名無しさん:05/02/24 04:05:24
>>13 辞書を引用し、都合のいい解釈をする
>>16 人の言葉をモジって言い返す
アホの典型

18 :デフォルトの名無しさん:05/02/24 04:26:06
ではスレタイはどんな意味で統一と入れたのか

19 :デフォルトの名無しさん:05/02/24 04:45:00
早く各種ローカルコードからUnicodeへのマッピングを統一してくれ.
あと,サロゲートペアってもうなくならんのだろうな…
結局固定ビット長で処理できねーじゃんか.

20 :デフォルトの名無しさん:05/02/24 07:08:44
まずスレタイの意味を統一すべきだな。

21 :デフォルトの名無しさん:05/02/24 10:18:07
>>19
32bitで固定

22 :テンプレ作者:05/02/24 10:57:35
他に文字コード関連のスレを立てる人がいないように「統一」の
文字を入れました。もう立っているみたいですが。

23 :デフォルトの名無しさん:05/02/24 11:01:09
普通「総合」じゃないのかな?

24 :テンプレ作者:05/02/24 11:06:15
ま、洒落と言うことにしといてくださいな。

25 :デフォルトの名無しさん:05/02/24 11:46:41
統一だろうが総合だろうがどうでもいいんだが・・・


26 :デフォルトの名無しさん: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 :デフォルトの名無しさん:05/02/24 12:53:11
> つーか、4バイトで固定するならそもそもサロゲートペアいらねーじゃん。

その通り。サロゲートペアは2バイトという幻想にとらわれた故の特殊事情であって、
もはやUnicodeとしてはサロゲートペアなんぞ使わないのが正しい。


29 :デフォルトの名無しさん:05/02/24 13:01:21
さすがに第1群以降は使わないよな?
せめて最上位バイトを内部処理用フラグとして使いたい。
まぁ外に出すときにはクリアするが。

30 :デフォルトの名無しさん:05/02/24 13:17:13
確かに文字コードは頭が痛くなる問題ですね。
早く標準が固まって欲しいです。

ただ、右から左にテキストを書くやつ(アラビア辺り?)とかは
絶望的じゃなかろうかと思ってみたりみなかったり。

31 :デフォルトの名無しさん:05/02/24 13:50:09
>>30
標準ならあるぞ。たくさん(笑)

right-to-leftの何が絶望的なんだろう? ふつうにWindowsでも扱えるは
ずだけど。



32 :デフォルトの名無しさん:05/02/24 14:08:58
ストリームの出現順の問題のことを言ってるのかな?

33 :デフォルトの名無しさん:05/02/24 14:10:04
>>30
日本語は縦書きなんだが


34 :デフォルトの名無しさん:05/02/24 14:48:10
>>30
描画方向が違うだけだと思うYO

35 :デフォルトの名無しさん:05/02/24 15:53:10
日本でも昔の看板とかは右から左

36 :デフォルトの名無しさん:05/02/24 16:03:14
笑止!それは一行一文字の縦書きにすぎぬわ!

37 :デフォルトの名無しさん:05/02/24 16:13:22
そんなわけで本文なんかを横書きにする場合では、
相当古くから(もちろん明治維新よりは後だが)
今と同じく左から右へ書いていたそうな。

38 :デフォルトの名無しさん:05/02/24 18:00:17
左←右圏でも縦書きされる場合があるらしい。看板とか。

39 :デフォルトの名無しさん:05/02/24 18:24:23
まさにアホなスレタイ
文字表示雑談スレ

40 :デフォルトの名無しさん:05/02/24 18:30:54
右から左に書く場合でも、数値だけは逆だったりするよね。
日本語にたとえれば、「。すで年2005は年今」みたいな感じ。

41 :デフォルトの名無しさん:05/02/24 18:47:29
アホなスレタイだとアホしかよってこない。
スレタイってやっぱり大事なんだね。

42 :7:05/02/24 21:50:15
>>8 動作要件に IE4 以上というのが気に掛かる・・・。
>>10 その方法を考えたけど、実行ファイルが肥大化するのと、他の Windows アプリとの
  データ互換性が保証できなくなるのがネック・・・。
>>15 >>26 一見よさげだけど、たとえば「〜」なんか化けてしまうのが致命的・・・。

みなさんどうもでつ。もう少しいろいろ検討してみまつ。

43 :デフォルトの名無しさん:05/02/24 22:52:42
>>27
ISO 10646 dis v.1

44 :デフォルトの名無しさん:05/02/25 10:20:01
>>41 意外とまともな事言ってる人もいると思うが。

45 :デフォルトの名無しさん:05/02/25 10:22:38
http://suika.fam.cx/~wakaba/-temp/wiki/wiki?ISO%2FIEC%2010646
>>43 それって、この表だとどの規格のこと?

46 :デフォルトの名無しさん:05/02/25 11:03:27
>>45
DIS 10646:19911990-12-061st DIS


47 :デフォルトの名無しさん:05/02/25 12:02:10
>>43
寝言言ってねえで素直にUTF-32でも使っとけ。

48 :デフォルトの名無しさん:05/02/25 12:26:02
>>44
Unicodeは複数コードポイントを組合わせる可変長表現なのに、
相変わらず2バイト4バイト固定とか言ってますが。

49 :デフォルトの名無しさん: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 :デフォルトの名無しさん: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;
になって(ry

56 :Winかよ!?:05/02/26 01:44:50
>>55
unsigned _int64って何だよ…

いまや#include <stdint.h>で、uint64_tじゃないのか?

57 :デフォルトの名無しさん:05/02/26 02:04:17
>>51
wchar_tはUnicodeが入るとは限らないんだけど、そのままUTF-16やUTF-32
を突っ込んでる実装が多いから良しと仮定しましょう。
wchar_tにUTF-32が並んでいても、そこから文字(grapheme)単位に処理
するにはステートマシンで区切りを探さないといけない。
 http://www.unicode.org/reports/tr29/
こういったことを理解しての発言には見えない。
加えて、ICUもそうだけどUTF-16が処理対象の場合はサロゲート込みで処
理されるからサロゲートの有無で手間は全く変わらない。

58 :デフォルトの名無しさん:05/02/26 02:04:28
>55
さすがに地球外知性とデータ送受信するようにでもならないとそこまでは……
いや、そうなったらそうなったで、向こうのコード体系を強引に押しつけられる悪寒orz

59 :デフォルトの名無しさん:05/02/26 11:29:58
>>57
> そこから文字(grapheme)単位に処理
> するには
誰もそんなこと書いてないと思うが。



60 :デフォルトの名無しさん:05/02/26 12:57:35
文字単位に処理することはあり得るだろう?

61 :デフォルトの名無しさん:05/02/26 14:23:12
あり得るけど、それこそ Shift JIS や EUC-JP でAPI/システムコールレベルでは
バイト列として扱い、それを文字に組み上げるのは各アプリケーションの責任という
考え方もあった罠。
この考え方を Unicode にあてはめてみたり、とか。char を wchar_t に変えて。

62 :デフォルトの名無しさん:05/02/26 14:42:33
>>61
> あり得るけど、それこそ Shift JIS や EUC-JP でAPI/システムコールレベルでは
> バイト列として扱い、それを文字に組み上げるのは各アプリケーションの責任という
> 考え方もあった罠。

それほど変ってないような…

そしてその「アプリケーションの責任」の技術的な部分の研究を、
一番行っているのはUnicodeの世界なのでは?


63 :デフォルトの名無しさん:05/02/26 17:38:26
結局「一文字」単位に扱おうとすると,
ステートマシンは必要になるのか…
なんかあんまり変わってないな,昔と.

64 :デフォルトの名無しさん: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 :デフォルトの名無しさん:05/02/27 00:27:02
http://www.hatena.ne.jp/1105667960

67 :57:05/02/27 00:45:01
>>59
UAX #29でも触れられているけど、文字(grapheme)単位に
処理できないと文字列の文字数を得たり、分解したりできな
いのはもちろん、比較や検索も正しく行なえない。

68 :デフォルトの名無しさん:05/02/27 01:24:33
normalize してもコードポイント一つであらわせない文字は正しく扱えません
としても、それほど困らないんだよなあ。
実装コストに見合うメリット無いし。

69 :デフォルトの名無しさん:05/02/27 02:13:31
>>67-68
内部文字コードが Unicode 化された Visual Basic 4.0 以降や Java なんかでは、
「文字列をバイト単位で切り出すにはどうすればよいですか?」という質問が
必ず FAQ になってるよな(w

70 :デフォルトの名無しさん:05/02/27 02:34:30
U+F92FとU+F98DのkIRG_KSourceが間違ってる件について
これどうやったら修正させることができるんですか
韓国のNational Bodyが言い出さない限り何人たりとも修正できないんでしょうか
とりあえずUnicode 4.1.0βのレビューで指摘してみたけどシカトされますた
ほかの指摘事項はちゃんと反映されてたから指摘そのものは届いてるはず

71 :デフォルトの名無しさん:05/02/27 13:12:20
ほかの指摘事項はたまたまほかの人が同じ指摘をしたんだろう

72 :デフォルトの名無しさん:05/02/28 07:13:00
5件あって5件ともたまたま別の人が同時に指摘したってあんまりありそうにないような
「報告ありがとう。Unihanの専門家に転送しとくよ彼が今日中に反映してくれるだろう」
みたいな返信もちゃんと返ってきたし。
正規表現が間違いだらけだったから正しいの書いて送ったけど他の誰かが一字一句
ピッタリ一致するような正規表現をたまたま同時に送ってたとかありえなーい。
つーかスクリプトに通して検査するだけで見つかるような誤りがなんでボロボロ
出てきますか? なんのために機械可読な形式で提供してますか?

73 :デフォルトの名無しさん:05/02/28 08:42:52
もう一回聞いてみればいいじゃん

74 :デフォルトの名無しさん:05/03/01 01:46:45
戸籍やってる身からすれば
康煕字典体はきっちり入っていないと

75 :デフォルトの名無しさん:05/03/02 08:36:34
ところで,Unicode って既存のコードとのラウンドトリップは考慮されてるの?
つまり Unicode に変換されたとたん,元のコードでは区別されていた文字が
同じ文字にマップされたりはしないの?
それはいわゆる機種依存文字も含めて?

76 :デフォルトの名無しさん:05/03/02 08:53:12
文字コードを作る人は馬鹿ですか?
なんで固定バイト数にしないんだよ。
先頭数ビットを国コードにして残りを文字コードに割り当てる。

似ている文字でも国ごとに別の文字コードにするべきだ。
そして検索の機能として文字コード検索と、文字形検索の二つに分ける。

77 :デフォルトの名無しさん:05/03/02 09:06:12
>>76
UNICODE棄てれば実現可能かもね


78 :デフォルトの名無しさん:05/03/02 10:18:45
>>76
そしてPhishingが横行

79 :デフォルトの名無しさん:05/03/02 10:38:34
多言語ドメインなんてくだらないものは捨てちまえ。

80 :デフォルトの名無しさん:05/03/02 14:57:31
>>76
Emacsの内部コードがそんな感じよ。文字列表現はマルチバイトだけど。
国ごとじゃなくて文字集合ごとだけど実質あまり変わらん。


81 :デフォルトの名無しさん:05/03/02 15:50:16
マジな話、文字形検索(文字コードではなく文字の形で
検索すると言う意味)って考え方ないの?

同じ形の字でも国が違えば検索に引っかからない方がいいだろうし、
同じ国でちょっと違う形の字でも同じとして検索した方がいいこともあるだろうし、
国は分からないけど、すべての国対象で似ている字を検索したいこともあると
思うんだけどなぁ。

82 :デフォルトの名無しさん:05/03/02 15:55:33
1 I l | ! i │ @ T (以下略)をどこまで一緒にするのやら

83 :デフォルトの名無しさん: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 :デフォルトの名無しさん:05/03/02 23:31:01
へとヘは?

86 :デフォルトの名無しさん:05/03/03 02:37:43
タと夕とか
トと卜とか

87 :デフォルトの名無しさん:05/03/03 04:42:46
ロとか口とか

88 :デフォルトの名無しさん:05/03/03 11:42:20
(以下略

89 :デフォルトの名無しさん:05/03/03 16:02:46
C++ で文字コード変換したいと思った場合、
Windows + IE5.5 ならば、IMultiLanguage3 を通して変換すればいいが、
UCS-4 のコードから、文字種別などの文字情報を取得するライブラリが
OS標準にないというのが悲しい。



90 :デフォルトの名無しさん:05/03/03 16:09:52
Windowsの事しか考えられないバカは去ってくれ。

91 :デフォルトの名無しさん:05/03/03 18:27:33
>>90
そりゃ言いすぎ(w

けど、
> Windows + IE5.5 ならば、IMultiLanguage3 を通して変換すればいいが、
つーのが、もうスレの主旨には全く合わないな。
それが良いかどうか語りたいようなヲタの住むスレなんだから。


92 :デフォルトの名無しさん: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 :デフォルトの名無しさん: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 :デフォルトの名無しさん:05/03/10 11:13:14
>>94
SUS的にはchar**が定義らしいが、現実的にはconst char**じゃないと
面倒なんだよな。



96 :デフォルトの名無しさん:05/03/10 13:04:58
>>83 に関連した疑問なんだが,各種日本語文字コード,Unicode間で
縦横無尽にマッピングしまくッっても安全な集合って
どこかで定義されてない??

97 :デフォルトの名無しさん:05/03/10 15:21:23
サロゲートうんこ

98 :デフォルトの名無しさん:05/03/10 21:21:44
内部はgrapheme clusterを単位にした固定長コードにでもしないと
面倒でやってられんぞ

99 :デフォルトの名無しさん:05/03/11 00:57:47
>>95
http://www.opengroup.org/onlinepubs/007908799/xsh/iconv.html
では const 付きだけど

http://www.opengroup.org/onlinepubs/007908799/xsh/iconv.h.html
には const 付いてない(つД`)

100 :デフォルトの名無しさん:05/03/11 02:55:46
>>96
\~ ̄―\〜‖…−¥¢£¬とか
CP932におけるNEC選定IBM拡張文字 とか
古えの半角カナ とかの話?

101 :デフォルトの名無しさん:05/03/11 05:35:24
@ABCDEFGH

102 :デフォルトの名無しさん:05/03/11 05:55:24
>>100 そう.そういう微妙な文字以外の
「安全な」文字の集合ってどこかでまとめてくれてないかな,と.
自鯖の掲示板で,サニタイジングのついでに警告を出したい.

103 :デフォルトの名無しさん:05/03/11 06:33:51
>>98
コードポイント3つ4つの組合せもあるから、余裕も見て内部は
1 cluster=20byte位の固定長?素晴らしい富豪設計です。

104 :デフォルトの名無しさん:05/03/11 07:00:57
>>103
任意のスカラ値の組み合わせが可能な訳じゃないからそんなに必要ない

105 :デフォルトの名無しさん:05/03/11 07:08:52
よくある実装が必要な組み合わせだけ適当にPUAに割り当てて
知らない/対応する気のないスクリプトはそのまんま素通し
どうせ未定義の符号位置に関しては素通しにせざるを得ないんだし

つーかなんでこうも過度に汎用化したがるんだろうか
シフトJISのアプリケーションがISO 2022完全実装に対応できないから駄目なんて
文句言う奴はいないのになんでUnicodeになったとたん単なる地域化じゃ許されなく
なりますか? 単に漢字をたくさん使いたいだけというささやかな望みも叶いませんか?

106 :デフォルトの名無しさん:05/03/11 18:57:03
>>102
(jisx0201左半面 or ASCII) + (jisx0208) - (\~ ̄―\〜‖…−¥¢£¬)
前提がひどく厳しいのでこんなものじゃないかしら。
ISO-2022-JPの…なんてことは言わないで頂戴。

いわゆる機種依存文字や半角カナが非互換なのは、unicode以前からの通り。
\~ ̄―\〜‖…−¥¢£¬は、unicodeの普及によって新たに生じた非互換。
(余談だけど、後者は終止unicodeのみで処理するときでさえいやらしい。)

「自鯖の掲示板」で「縦横無尽にマッピングしまく」る必要はないようにも思うが。

107 :デフォルトの名無しさん:05/03/12 19:44:53
人間はなぜ同じ過ちを繰り返すのでしょうか?

108 :デフォルトの名無しさん:05/03/13 00:39:53
>>107
過去の失敗から学ぼうとしないからだ、と何回言ったら分かるんだ

109 :デフォルトの名無しさん:05/03/13 08:59:59
>>104
HangulやDevanagariは3つ4つ平気で使うよ。

110 :デフォルトの名無しさん:05/03/13 09:14:00
>109 タイ語もたくさん使うよ。

111 :デフォルトの名無しさん:05/03/16 01:50:18
>>109-110
だから3つ4つの任意の組み合わせがすべて必要なわけじゃないだろ。
Windowsのフォントフォルダ見てもインド語のフォントは500KBもないし
実際にPUA使ってリガチャを実装してるタイ語やインド語のフォントだって
BMPの6400文字で十分に足りてる。理論上可能なすべての組み合わせを
サポートするニダ150万コードポイント必要ニダUTCは謝罪と賠償しる!
とはさすがの韓国も言ってないみたいだし。
そもそもそんなこと言い出したらIdeographic Description Sequenceなんか
最大16コードポイントの並びだし。

112 :デフォルトの名無しさん:05/03/16 06:11:24
>>111
要約すると「Windowsでは使わない、使えないから不要」ということ?
でしたら特定の実装上と限定して話しをして下さい。

ちなみにAppleのATSUIだと、PUA使ってリガチャを実装なんて変なこと
はやってないから、長いdecompositionで表現したcomplex scriptでも
glyph metamorphosis tableを使って適切なglyphを拾って来る。
この実装上では、complex scriptが扱えなかったり、ヒラギノOpenType
の豊富なglyphを使えないと粗悪品とみなされます。

24 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)