文字コード総合スレ p ..
116:デフォルトの名無しさん
07/08/22 22:03:34
携帯用のWebサイト作ってるんですが、あちらの世界ではシフトJIS/半角カナが
常用されてるみたいです。で、元データはEUC/全角(?)カナのため
EUC=>Shift_JISに変換しつつ、ついでに全角カナ=>半角カナに変換してくれるような
素敵なツールはありませんか？
使うのはkshスクリプトのCGIで、今はnkfだけ通しています。jcode使うとできそう
なのですが、変換のためだけにperlを動かすのも何だかなぁと…。
117:デフォルトの名無しさん
07/08/22 23:38:46
元データをEUC/半角かなにしておいたらいいんじゃない？
118:デフォルトの名無しさん
07/08/22 23:39:16
SJIS/半角かなか
119:デフォルトの名無しさん
07/08/23 01:07:52
2バイトかな→1バイト系かな変換をsedでやればいいだけっしょ。
120:デフォルトの名無しさん
07/08/28 21:42:23
>>116
nkf に全角=>半角パッチでも送りつけたら？
121:デフォルトの名無しさん
07/08/28 22:01:56
半角カナ→全角カナならともかく、その逆をやりたがる奴がいるとはな
122:デフォルトの名無しさん
07/08/28 22:47:59
携帯用Webサイト作るときには必要らすい。
123:デフォルトの名無しさん
07/08/28 22:55:51
いつの時代の話だよ
124:デフォルトの名無しさん
07/08/28 23:02:03
クライアントはいまだにそう信じてるんだよ･･･
125:デフォルトの名無しさん
07/08/29 00:08:22
客に恥をかかせないように正すのも仕事だろうに
何段もの丸投げの下層か？
126:デフォルトの名無しさん
07/08/29 00:37:33
正しいことを言えば通ると信じられるってのは幸せだよな。
127:デフォルトの名無しさん
07/08/29 00:55:13
下層は可哀想だな
俺は幸せだ
128:デフォルトの名無しさん
07/08/29 01:10:07
言いたいことも言えない こんな世の中じゃ
129:116
07/08/30 00:59:43
結局、kc15に全=>半の変換を組み込んで、nkfと置き換えることにしました。
シェルスクリプト内の埋込みやサーバ内で扱うデータにShift_JISや半角カナ使いたくないという
単なる個人的趣味のため、最後に変換する形にしました。ちなみにこれは業務じゃないです。
まぁそういう要望もあるってことで。
130:デフォルトの名無しさん
07/08/30 05:35:00
どうやらSubmissionからやり直す模様
URLﾘﾝｸ(www.unicode.org)
前回ツッコミ損ねた人はガンガンコメントしよう
131:デフォルトの名無しさん
07/09/01 04:50:42
前回のドラフトに関してこのスレで突っ込まれてたことはおおむね修正されてる模様
132:デフォルトの名無しさん
07/09/06 23:28:55
字体差の大きい異体字は削除されたね。
やっぱ包摂扱いにしないことにして拡張Dに提案か?
133:デフォルトの名無しさん
07/09/07 22:51:53
漢字用異体字セレクタ正式決定するのだいぶ後になりそうだな。2010年以降かも?
拡張CやDもそのくらいになるかも?
134:デフォルトの名無しさん
07/09/08 04:51:26
拡張CとかDへ正式に突っ込むのは結構面倒だから
UROの最後に付け足しでね?
135:デフォルトの名無しさん
07/09/08 21:24:32
漢字のVSは中台韓越と話し合って決めた方がいいと思う。
136:デフォルトの名無しさん
07/09/09 00:34:33
必要だと主張する人が勝手に登録申請する方式です。
中台韓越が必要だと思ってるなら申請するはずです
137:デフォルトの名無しさん
07/09/09 11:00:12
漢字はVS-1～16を使わないのは何でだろ?
俺的には各国の規格の現在および過去の例示字体、康煕字典体、表外漢字字体表、3部首許容などはVS-1～16にして、
その他の異体字(俗字など)はVS-17～にした方がいいと思うのだが。
138:デフォルトの名無しさん
07/09/09 15:55:56
Adobe-Japan1の非漢字は追加しないのかな?
まだUnicodeで規定されてないものが沢山あった筈。
丸付き文字など複数のコードの組み合わせで表せるものもあるけど。
139:デフォルトの名無しさん
07/09/09 18:39:15
>>137
前スレだったかの説によればBMPのVS奪い合いを未然に防ぐためだそうだが
真偽の程は知らん
あるいはそういう使い方が将来できるように空けてるのかも
>>138
数字が2桁以上のとき合成が曖昧にならないか?
JIS X 0213の丸付き数字が収録を認められたのは合成では不可能だからという
理由があったはず
140:デフォルトの名無しさん
07/09/09 23:55:27
ひらがなに○とかはU+3042 U+20DDとかでいいけどな。
問題は○51とかだな。全部単体のコードとして追加するのもいいが、2字以上に一緒に合成用記号を付ける方法も定義しておいた方がいいかも。
あとAdobe-Japan1の文字を見てると合成用黒丸や黒四角も必要だな。縦書き用のグリフを選択するタグも。
MacJapaneseをUnicodeにエンコーディングされる際に使用されるPUAのタグと同じ機能のものをPUAでない符号位置に正式なUnicodeとして追加するべきかも。
141:デフォルトの名無しさん
07/09/10 00:04:14
合成とかいらねーじゃんかよめんどくさい
有限である文字を割り振るだけなのに何年かかってんだよボンクラども
小出しにチマチマ変更するんじゃねえよ！アホか！
142:デフォルトの名無しさん
07/09/10 01:39:53
中国とか台湾だと、名前を付けるときに漢字を新規に創作する人も
いる、と聞いたんだが、マジ? いまでもそれってアリなの?
143:デフォルトの名無しさん
07/09/10 02:56:48
>>142
人名は知らないけど、元素なんかでは新しい字を作ってるとか聞いたことがある。
144:デフォルトの名無しさん
07/09/10 06:10:17
>>143
金属元素には金偏とかそんな感じだっけ?
145:デフォルトの名無しさん
07/09/10 15:08:03
㍻㍼㍽㍾
146:デフォルトの名無しさん
07/09/10 15:57:39
マルチバイト文字の最下位１バイトが、
x0Ahやx0Dhなどの改行コードと重なるケースって
ありますか？
147:デフォルトの名無しさん
07/09/10 17:28:05
>>146
さすがに、制御コードと重なるようなエンコーディングは聞いたことないですね。
UTF-16を1オクテット単位で見ると出てくるけど。
148:デフォルトの名無しさん
07/09/10 17:46:09
>>147
ありがとうございます。
マルチバイト文字列をbyte単位でバッファリングして
操作しようと思ってるんですが、
対象エンコーディングがSJIS,EUC,UTF-8なので、
それなら問題無さそうですね。
149:デフォルトの名無しさん
07/09/10 21:36:53
>>142
中国はマジらしい。台湾もかな?
だが、近い将来制限する方針みたい。
>>143-144
90年代以降に正式名称が決定した超アクチノイド元素(104番以降)の為に新しい漢字が造られた。
Rf(104)={金盧}、Db(105)={金杜}、Sg(106)={金喜}、Bh(107)={金波}、Hs(108)={金黑}、Mt(109)={金麥}
{金盧}と{金麥}はCJK統合漢字の無印と拡張Aに全く同じ字形の漢字があったのでそれを使うことになったが、
105～108番元素を表す漢字は無かったので拡張Bに追加された。これらは俺らが生まれた後に造られた新しい漢字と言えよう。
最近正式名の決定した110番元素(Ds)、111番元素(Rg)にも漢字が当てられそれぞれ{金達}、{金侖}となった。
これらはCJK統合漢字の無印に既にある字と同形になった。これはもうこれ以上新しい漢字を造らない方針になって既にある字から選んだという事なのかな?それとも偶然かな?
あと超アクチノイド元素を示す漢字は何故かUnicodeには繁体字のみが定義され簡体字は未だ定義されてない。
何でだ?まさか統合してるってこたぁねぇよな?
150:デフォルトの名無しさん
07/09/10 23:51:25
日本だって人名漢字で制限する前は好きな漢字作ってたよ。
金偏の名前は名古屋人と大工は多いとか聞いた気がする。
151:デフォルトの名無しさん
07/09/11 00:11:39
>>149
統合するのかと思ったけどAdobe Japan1の割り当て見直したことから考えると
簡体字と繁体字の統合はなさそうだからやっぱり登録申請するんじゃね
152:デフォルトの名無しさん
07/09/11 23:47:24
西夏文字と女書の提案キター
URLﾘﾝｸ(std.dkuug.dk)
URLﾘﾝｸ(std.dkuug.dk)
153:デフォルトの名無しさん
07/09/12 21:51:43
台湾では辞書に載ってる漢字ならOKと書いてあるのをどっかで見た。
どの辞書を指してるのかなど詳しい規則については知らんが。
だが、画数最大で有名な龍×4（U+2A6A5）はOKらしくこの字2つの名前の人がいるらしい。
下の名だけで128画になる。名前書く時大変そうだな。
154:デフォルトの名無しさん
07/09/12 22:04:04
龍龍
龍龍
↑こいつですな。9ptぐらいで印刷したらつぶれて読めないだろうな。
155:デフォルトの名無しさん
07/09/12 23:54:59
URLﾘﾝｸ(www.unicode.org)
Windows Vista だが、表示されるとは思わなかった…。
156:デフォルトの名無しさん
07/09/13 02:49:34
>>153
日本も既存の名字は「辞書に載ってる漢字ならOK」で辞書は明示してなかったような
URLﾘﾝｸ(internet.watch.impress.co.jp)
>>155
VistaはExtension Bまですべて入ってる
(ただしCJK Compatibility Ideographs Supplementは全部そろってない)
157:デフォルトの名無しさん
07/09/14 23:59:10
やっぱり字体差の大きい字を統合すると問題あるよな。
例えば「日玉」は一般的に「曜」の略字だけど、似ている「旺」の異体字として使われる事もあるかも知れんし。
同じ字形の字が「曜」でも「旺」でもない全く別の字として実は存在する(した)って事になるかも知れんし。
158:デフォルトの名無しさん
07/09/15 01:13:54
AnnexSと矛盾するのが致命的
せっかくこんな努力をしてるのがぶちこわしになるし
URLﾘﾝｸ(kanji-database.sourceforge.net)
159:デフォルトの名無しさん
07/09/15 01:16:27
UTR#37には統合できない文字をVSで表すようなことをしてはいけないと
明記されてるから実にまっとうな方向の改訂案
160:デフォルトの名無しさん
07/09/16 22:21:49
「門」の手書き等で使われる略字は簡体字(U+95E8)と統合する事になったんだね。
そっちの方がいいわな。
161:デフォルトの名無しさん
07/09/16 23:05:18
そういうわけで前回ここで指摘された点はほぼ改善されてる。
別にここ見てたわけじゃなくてAnnex Sから常識的に判断すれば
必然的にそうなるってことだろうな
162:デフォルトの名無しさん
07/09/18 22:48:48
悉曇十八章まだー？
163:デフォルトの名無しさん
07/09/20 02:07:49
Siddham scriptは草案らしきものが出てるけど
まだ正式には提案されていない
164:デフォルトの名無しさん
07/09/22 00:29:00
北朝鮮の将軍様専用ハングルはUnicodeには追加されないのかな?
165:デフォルトの名無しさん
07/09/23 01:35:53
U+2E28とU+2E29に二重括弧を入れようとしてるみたい。
JIS X 0213の1-2-54と1-2-55との対応について更に混乱しそうだな。
166:デフォルトの名無しさん
07/10/03 07:25:50
>>164
KPS 9566をソースに提案されたことがあるけど
蹴られたから新たな展開がない限りは収録されないと思われ
167:デフォルトの名無しさん
07/10/05 21:20:58
もし追加されるとなると互換文字としてU+Fxxxの領域に割り当てられるだろうな。
ハングル音節ブロックの余ってるU+D7A4～U+D7AFに追加でもいいかもしんない。このままだとそこ永久に埋まりそうにないし。
168:デフォルトの名無しさん
07/10/06 04:03:43
>>167
ブロックの割り当ては16文字単位だからHangul Jamo Extended Bでも使ってないのか
169:デフォルトの名無しさん
07/10/06 05:37:35
TUF16文字列をUTF-8に変換した場合、
4バイト以上はまず来ないと思っていいですか？
170:デフォルトの名無しさん
07/10/06 05:38:39
UTF16
171:デフォルトの名無しさん
07/10/06 05:53:53
サロゲートに対応していない馬鹿なUTF-8コンバータだったら
6バイトのものを送ってくるかも
172:デフォルトの名無しさん
07/10/06 05:53:57
>>169 なぜそうなる？
173:デフォルトの名無しさん
07/10/06 06:39:33
UTF-16ではU+10FFFFまでしか表せないからじゃね?
174:デフォルトの名無しさん
07/10/06 10:18:53
>>169
6バイト
175:デフォルトの名無しさん
07/10/06 11:20:14
>>174
>>171以外ならそんな入力の場合に6バイトになるのかkwsk
176:デフォルトの名無しさん
07/10/06 11:20:34
×そんな入力
○どんな入力
177:デフォルトの名無しさん
07/10/06 11:23:48
ｽﾚﾘﾝｸ(tech板)
178:デフォルトの名無しさん
07/10/06 15:19:26
Javaは3バイトまで
179:デフォルトの名無しさん
07/10/06 17:15:03
ドイツ語圏は、ドイツ語を使う国々が集まって、表記法を統一する会議を何年かおきに
やっている。
なんで、東アジア、漢字を統一できなかったのか、残念。
180:デフォルトの名無しさん
07/10/06 17:25:36
U+10000からU+10FFFFまでは4バイト
181:デフォルトの名無しさん
07/10/06 17:27:11
>>179
ドイツ人は制定マニアだから。
そういうことが難しいからこそ、漢字圏なんじゃないのか?
182:デフォルトの名無しさん
07/10/06 17:56:29
ドイツ語圏はドイツ語圏だけど
漢字圏は中文圏じゃないし
日本語とかの別言語でも漢字を使っているからね
183:デフォルトの名無しさん
07/10/06 18:20:18
>>179 中国だって統一王朝が立つと文字の整理をやってるぞ
184:デフォルトの名無しさん
07/10/06 18:35:31
MySQLのUTF8は3バイト文字までしか対応していない
185:デフォルトの名無しさん
07/10/06 19:35:22
>>184
ありゃりゃ。みんなどうしてんの？
186:デフォルトの名無しさん
07/10/06 20:07:40
>>183
毛沢東もやった死ね
187:デフォルトの名無しさん
07/10/06 21:51:16
じゃあ漢字の統合のために台湾併合だな
188:デフォルトの名無しさん
07/10/06 23:34:15
日本もね
189:デフォルトの名無しさん
07/10/06 23:57:53
康熙字典体に統一で桶。
190:デフォルトの名無しさん
07/10/07 02:48:55
中国は文献がほとんどかえりみられなくなっては
日本から逆輸入というのを定期的に繰り返しているし。
文字の統一なんて掛け声以前の問題じゃなかろうか。
191:デフォルトの名無しさん
07/10/07 03:38:26
>>189
Unicodeはそういう方針だな。GB7589とGB7590は繁体字で入ってるし
並び順も康煕字典の部首画数順だし
192:デフォルトの名無しさん
07/10/07 05:22:31
80年代後半から90年代前半って
台湾の方が電子化進んでたよね
193:デフォルトの名無しさん
07/10/07 08:48:37
いまや日本＝秋葉原でHENTAI ANINEの国という認識だろ。
文字なんて「萌え」が残ってればおｋなんじゃね？
と秋葉帰りの外人から思われてるに違いない。
194:デフォルトの名無しさん
07/10/07 13:30:02
>>191 Unicode の康煕字典ベースは、Unicode の原典主義からの帰結やね。
並び順の、康煕字典の部首画数順はもしかして漢字文化圏のグローバルスタンダード?
>>193 向こうの濃いオタ連中は20年ぐらい前から現代日本風アイテムとして漢字を
認識してるから、それはない。
195:デフォルトの名無しさん
07/10/07 13:37:21
請け負ったWebの仕事で、UTF-8で作成してたんだが、
Shift-jisしか受け付けないサーバーだと完成間際で判明して
１から変換しなおし。何とか事なきを得たんだが、次回に
どうしてもクライアントがやりたがってる事をAjaxでやろうと
すると、どうしてもUTF-8を採用せざる負えない結果に…orz
javascriptでShift-jisからUTF-8に変換して表示させる事はできないでしょうか？
向こうのサーバー事情でPHPやらPerlは一切使わせて貰えない状況です。
何とかお助けくださいませ。。。。。。。。。。。。
196:デフォルトの名無しさん
07/10/07 14:15:38
ググレカス
197:デフォルトの名無しさん
07/10/07 14:40:15
>>194
CJKのどこからも文句の出ない並び順が康煕字典順しかなかったってことだろう
現代中国はにくづきとふなづきを統合したりしたまったく異なる部首を使ってるし
発音順は国によって全く異なるし
198:デフォルトの名無しさん
07/10/14 20:13:05
sjis,EUC,UTF8,16,32の判別ソフトをCで作っています。
UCS2も対応させたいのですが、何処か参考になるサイトは無いでしょうか
すみません、どなたか教えて下さいm(_ _)m
199:デフォルトの名無しさん
07/10/14 20:21:10
>>198
URLﾘﾝｸ(www.google.co.jp)
200:デフォルトの名無しさん
07/11/03 16:03:56
【日台中韓】韓・中・日・台が漢字の字体統一へ[11/03]
ｽﾚﾘﾝｸ(news4plus板)
201:デフォルトの名無しさん
07/11/03 19:20:21
字体統一って中国以外にメリットあるの？
202:デフォルトの名無しさん
07/11/03 19:22:45
日本すら未だに統一できてないのに秒速で漢字が増えてゆく国が統一とは
203:デフォルトの名無しさん
07/11/12 17:13:15
>>200
ウソだったらしい。もうなにがなんだか。
【日台中韓】 「中・日・韓・台の漢字統一」報道を否定！簡体字使用の変更は不可能[11/12]
ｽﾚﾘﾝｸ(news4plus板)
204:デフォルトの名無しさん
07/11/12 18:23:49
ヨタ記事をいちいち貼るなよ。
205:デフォルトの名無しさん
07/11/17 15:44:45
IMEパッドの文字の上にマウスを持っていくとでるバルーンヘルプの内容が取得できるライブラリ(関数)をしりませんか？
in:jisX0213:2004 1面, 1区, 1点
out:ucs, utf-8, Shift_JIS
見たいな、、、
206:デフォルトの名無しさん
07/11/18 00:29:36
超漢字検索の情報ウィンドウの内容を取得できるライブラリもほしい
207:デフォルトの名無しさん
07/11/20 23:35:37
JIS X 0213 面区点番号とunicodeのマッピングを
機械的に求めることはできますか？
208:デフォルトの名無しさん
07/11/21 11:39:36
テーブル引く
...というのは機械的だろうか？
209:デフォルトの名無しさん
07/11/21 13:03:01
ドイツ語は定期的にspellをドイツ語圏で統一するように会議をしているね。ま、向こうは意味まで
同じなのだが。形だけ揃えても意味ないし、朝鮮半島はハングルで統一されている。CKJで統一
する意味はないと思うのだがね。
210:デフォルトの名無しさん
07/11/21 19:13:46
perlで作ったcgiに一番ｵﾇﾇﾒなコードｋｗｓｋ
211:デフォルトの名無しさん
07/11/21 21:09:46
perlはなんでもいいよ。
Encode使えば割りとw何でもできるから。
好きなのにしな。
まあ今ならutf-8がいいだろうけど。
formにUnicodeな文字入力する奴もいるし。
212:デフォルトの名無しさん
07/11/24 02:48:07
なんかさ、gccのワイドリテラルの扱いってへんてこな感じね。
gcc3.4よか前だと単に1Byteを4Byteに展開するだけで何の文字コードでもなく、
3.4以上だとUTF-32LEになってるかのような動き。
さらにvc(UTF-16LE)とのクロスでの開発を考えると頭が痛くなるなあ・・
Win/Linuxのクロスでやってる人って内部コードってなににしてる？
213:デフォルトの名無しさん
07/11/24 02:52:40
>>212
ワイド文字をリテラルでは使わない。
UTF-8から変換。
214:デフォルトの名無しさん
07/11/24 03:07:35
ま、そだよね。基本的にはリテラルに日本語入れなきゃ円満なんだよね。
3.4以降はexec-charsetでどうとでもできそうだけど、古いのは・・
ソースをUTF-8にすればなんとか日本語入れてもコンパイルはできるか。
あぁ、でもvc7とかはUTF-8のソース確か受け付けなかったような。
ソースくらいは変換するべきか。面倒だな・・いろいろ。
215:デフォルトの名無しさん
07/11/24 04:02:12
全部\uxxxxで書いちゃえ。
216:デフォルトの名無しさん
07/11/24 04:22:36
うほ、なげやり
でもそれすらgccいけるけどvcは\u使えないとか罠があったり。。
いろいろ実験して、バッドノウハウだけ増えたな・・
vc,gccともソースがUTF-16系は不可、vcはシグニチャなしUTF-8ソース不可、
逆にgccはシグニチャありUTF-8ソース不可・・
217:デフォルトの名無しさん
07/11/24 04:45:06
いや、やっぱvcはUTF-8はBOMありなしどっちもだめだなぁ。ソースによる
みたいだ。最低だなsjisしか受け付けないのか・・。vc8なら平気かもしれないけど
vc ソースsjis 内部UTF-16LE(コンパイル時L変換)
gcc3.3以下 ソースsjis(リテラルに"表"とかだめ) 内部UTF-8(実行時iconv変換)
gcc3.4以上 ソースsjis 内部UTF-8(input-charset=cp932でgccでコンパイル時変換)
こんなしか選択肢がないような。あぁ、CVSで変換するとかならソースはもっと
自由度あるか。だりーな、Unicode対応・・。もうsjis/eucでいい気がしてきた。
218:デフォルトの名無しさん
07/11/24 15:53:48
vcがutf-8ダメだってのは、何がだめだっての？
219:デフォルトの名無しさん
07/11/24 17:14:21
vc7で、UTF-8のソースだと
#define XX "あ"
とかあるとだめだけど
#define XX "ああ"
だと平気。たぶんsjisとして処理してるから日本語リテラルが奇数バイト
だとだめみたいな感じ。
220:デフォルトの名無しさん
07/11/24 23:51:33
vc8使え。終了
221:デフォルトの名無しさん
07/11/25 10:34:26
00h～1Fh 制御文字
20h～7Fh 各国共通（1バイト文字）
80h～FFh 各国自由（1／2バイト文字）
16ビットPCを出すときに思い切って半角カナを廃止して
80h以降は日本では2バイト文字専用にすれば良かった
つーか70年代末期の最初のPCを出すときに80h以降は
予約領域かPCG領域にすれば良かったんだよな
222:デフォルトの名無しさん
07/11/25 10:36:33
あとからならどうとでも言える
カタカナだけでもいいから1バイトで処理したいという要求がどれだけ当時は切実だったことか
223:デフォルトの名無しさん
07/11/28 12:10:33
80年代前半は漢字が表示できないマシンがごろごろしてたし
1987年ごろのパソ通でも、漢字を使うと表示できないマシンが
あるから、カナ以外禁止というところもあったね。
224:デフォルトの名無しさん
07/11/28 14:01:29
テキストVRAMで漢字もOK、なPC9801も初期はJIS第2水準はオプションだったしなあ
225:デフォルトの名無しさん
07/11/28 18:40:35
>>224
初代は第1水準もオプション
226:デフォルトの名無しさん
07/11/28 18:44:17
テキストVRAMが歯抜けだったからね。＜無印PC-9801
オプションの漢字ROMボードを入れるとその隙間を埋めるRAMもついてきたってわけ。
227:デフォルトの名無しさん
07/11/29 21:02:51
おまえらいくつだよ・・おっさんばっかだな
まあ若い人は文字コードになんか興味ないか
228:デフォルトの名無しさん
07/11/29 21:29:00
28歳はおっさんですかそうですよね。
229:デフォルトの名無しさん
07/11/29 22:02:33
外見によっては22でもおっさん。
230:デフォルトの名無しさん
07/11/29 22:22:00
プログラマーは25才が卒業式です
231:226
07/11/30 00:24:07
>>227
失礼な。せめておばさんと呼べ。
232:デフォルトの名無しさん
07/11/30 07:21:18
時代背景を知らないと
テキストVRAMって文字サイズとか位置とか固定になっちゃうじゃんｗｗｗ
超バカスｗｗｗ
なんでグラフィックVRAMに全部書かないのｗｗｗ
とか言い出す奴がいそうだな。
8ビットマシンはグラフィックVRAMに漢字表示できるものもあったわけだが
233:デフォルトの名無しさん
07/11/30 08:53:49
武勇伝はチラシの裏でどうぞ
219はどうなった？
234:デフォルトの名無しさん
07/11/30 19:30:45
単にバイト列としてコンパイルしたいだけなら
#pragma setlocale("C") を入れときゃいいだけでは？
235:デフォルトの名無しさん
07/12/01 09:01:43
POSITION 160,100:PATTERN -16,KANJI$(4746)
236:デフォルトの名無しさん
07/12/01 16:08:27
KANJI$テラナツカシス
237:デフォルトの名無しさん
07/12/02 07:14:19
Unicodeはもうだめだな
サロゲートペア，異体字，半角カナ．．．問題ありすぎ
世界中の文字使えるったってほとんど意味無いしょ
第３水準で変な記号いっぱい追加されたけどそれも要らん
JISが大手PC・携帯メーカーに呼びかけて
MS，アップル，ドコモ，au，ソフトバンク，NEC，富士通，IBM
2バイト文字の最終統一規格を作るしかないんじゃないの？
8080H～FFFFHの16384字あれば十分
238:デフォルトの名無しさん
07/12/02 10:41:18
＞JISが大手PC・携帯メーカーに呼びかけて
逆だ。JISは大手に踊らされている御用団体だからね。
つーか、それができるのならJIS83辺りで統一できているはず。
# 実態は……言うまでもないよな。
＞8080H～FFFFHの16384字あれば十分
計算できる?
239:デフォルトの名無しさん
07/12/02 11:18:03
CJK互換漢字に4字追加されるみたい。
240:デフォルトの名無しさん
07/12/02 11:25:30
>>237
もうおなかいっぱい。
これ以上文字コードを増やさないでくれ。
241:デフォルトの名無しさん
07/12/02 11:45:05
しかも>>237のレベルでは…
242:デフォルトの名無しさん
07/12/02 18:39:01
UTF-8で統一されるのが楽かなあ
>>237
2バイト固定長はもう無理でしょう。というか固定長は結合文字の
存在もあるしコーディング上のメリットがないんだよなあ。
結合文字を考慮した文字検索アルゴリズムとかもうどうしていいんだか・・
243:デフォルトの名無しさん
07/12/02 19:06:21
TronコードでOK
244:デフォルトの名無しさん
07/12/02 20:31:22
>>243
TRONコードは、単に、すでにある文字集合をぶち込む枠組であって、
文字集合の整備は漢字の収集とかやったけど、処理の上位層について
TRON方面は概念を発表しただけで具体的なものは何も出てきて
いないし、現在の問題を何ら解決できるものではない。現状から見て、
たいした期待はできない。
245:デフォルトの名無しさん
07/12/03 01:24:14
グリフ単位での文字検索は諦めて、コードポイント単位で
やるしかないんじゃないの。当面は。
246:デフォルトの名無しさん
07/12/03 22:10:17
結合文字はそのコードポイントが別だから検索がめんどいんじゃないのか・・
247:デフォルトの名無しさん
07/12/03 22:22:07
このへんを実装すれば多分おｋ
URLﾘﾝｸ(www.unicode.org)
URLﾘﾝｸ(www.unicode.org)
248:デフォルトの名無しさん
07/12/03 23:03:38
UTF-8な文字「X」が文字コード AB CD EF で定義されているとして、
別の文字「Y」がこれらをシャッフルした文字コード（ AB EF CD など）で
定義されている、という組み合わせを探しています。
効率的な調べ方とかあるかしら？
249:デフォルトの名無しさん
07/12/03 23:14:28
たかだかx6だからベタでいいだろ。
250:デフォルトの名無しさん
07/12/04 01:18:41
>>249
char a[] = { 0xE3, 0x82, 0xA2, 0x00 };
char b[] = { 0xE3, 0xA2, 0x82, 0x00 };
ってしたときに、aは「ア」だけどbに割り当てられた文字はないでしょう？
そういうのをプログラム的に省きたかったんだ。無理っぽいなあ
251:デフォルトの名無しさん
07/12/04 01:25:35
>>250
んなこと悩んでいる間にベタで書けば5分掛からないだろ。わけわからん。
それともなんかのプログラムの動作中ってこと？
252:デフォルトの名無しさん
07/12/04 07:34:33
これって割り当てられてるってこと？
URLﾘﾝｸ(www.google.co.jp)
ア の検索結果 約 73,600,000 件中 1 - 10 件目 (0.05 秒)
URLﾘﾝｸ(www.google.co.jp)
㢂 の検索結果 約 2,740 件中 1 - 10 件目 (0.24 秒)
253:デフォルトの名無しさん
07/12/04 09:56:17
日本語の文字には無いけど、中国の文字にあるだろ
254:デフォルトの名無しさん
07/12/04 09:56:49
0xE3, 0xA2, 0x82 だから、文字コード 3882 だよ。
255:デフォルトの名無しさん
07/12/04 10:56:35
U+3882 はちゃんと ExtA に割りあてられてるな。
Windows なら Vista にするか対応フォントを入れれば見えるはず。
256:デフォルトの名無しさん
07/12/04 11:36:45
関数的に書くなら、
端から生成して、端からx6の組み合わせで生成して、
端からUTF-8になってないバイト列を落とすフィルタを通す、
という感じで書くかな。
257:デフォルトの名無しさん
07/12/04 12:05:37
>>251
AB CD EF は16進数の10～15ではなくて、6種類の変数A～Fという意味。
文字列処理関数のテストケースを書いてて、248 みたいな組み合わせが数通り欲しかったのさ。
文字コード一覧表を目視して解決しますた。あんがと。
>>255
ExtAってなんかの制御コード？
>>256
日本語フォントが用意されているかを調べる、というコードが書けない俺orz
258:デフォルトの名無しさん
07/12/04 12:28:23
「日本語フォント」なんて関係ないだろ。
「文字集合」で考えろ。
259:デフォルトの名無しさん
07/12/04 12:48:05
「UTF-8的にあり得る(3バイトの)バイト列」じゃなくて、
「UnicodeからJIS X 0208(あるいはCP932)にマップ可能なコードポイント」を抽出したいのか？
それはテーブル引くしかないような気がする。
260:デフォルトの名無しさん
07/12/04 12:53:57
ExtA = CJK Ideograph Extension A
U+3400～U+4DB5(Unicode3,4), U+4DBF(Unicode5)
いわゆる「機種依存文字」な漢字でUnicode2に入ってなかった奴が入った所と思った。確か
261:デフォルトの名無しさん
07/12/04 13:03:01
JIS X 0208あるいは指定した文字集合だけ考えればいいなら、
JIS X 0208の全ての区点コードをリストアップ ('あ'を例に)
↓
UTF-8の16進数表現に変換 (0xE3 0x81 0x82)
↓
バイト列をソートしたのものを一桁目に(CSV) (0x81 0x82 0xE3, 0xe3 0x81 0x82)
↓
一桁目でjoin (0x81 0x82 0xE3でjoin)
↓
join後、複数項目のあるものをリストアップ。
262:デフォルトの名無しさん
07/12/04 17:55:57
文字集合と符号化方式の概念が理解できてなかった。まさに>>259だ。
>>258、>>260-261
もthx!
263:デフォルトの名無しさん
07/12/04 23:52:17
>>233
ｽﾏﾝ、結局Linuxどうしてんのかレスなかったから見てなかった・・
Stringを自前で作って、各文字コード処理できるようにする方向でやってる
264:デフォルトの名無しさん
07/12/06 01:28:41
std::stringは結局役に立たんからね
265:デフォルトの名無しさん
07/12/06 19:00:37
EUC-JPって第2面をA121～FE7Eに配置できないのかな
第1バイトがA0～FFなら2バイト文字だと認識するようにすれば
いいと思うんだけど
266:デフォルトの名無しさん
07/12/06 20:32:41
>>260
U+4DBFに文字なんか割り当てられてたか?
ブロックの範囲と文字が収録されている範囲をごっちゃにしてる
通信用語の基礎知識あたりの鵜呑みじゃあるまいな
267:デフォルトの名無しさん
07/12/06 20:33:43
>>265
円記号問題どころの騒ぎじゃなくなります
メインフレーム各社の独自コードにはそういう変態割り当てをしたものが
けっこうあるけど
268:デフォルトの名無しさん
07/12/06 20:52:49
>>266
スマン
あたり
orz
3.0 と現行のを調べた。
レンジは 3.0 だと U+4DFF まで、5.0 だと U+4DBF まで、
中身が入ってるのは U+4DB5 まで、で合ってます？
間に入ったのは Yijing Hexagram Symbols って八卦かよw
269:デフォルトの名無しさん
07/12/06 22:09:16
>>268
うむ
ちなみにU+9FA5の後ろには本当に文字が断続的に追加されてるな
270:デフォルトの名無しさん
07/12/06 22:25:43
URLﾘﾝｸ(examples.oreilly.de)
aj16.tar.Zが更新されてる
pri108に対応していくつかのCIDにUnicodeが追加された模様
271:デフォルトの名無しさん
07/12/07 08:24:11
第１～第４＋非漢字で11233字
補助漢字で6067字
補助漢字と第３，第４でかぶるのが約2900字
11233＋6067－2900＝14400字
8080H～FFFFH＝16384字
272:デフォルトの名無しさん
07/12/07 08:42:20
>>267
それはSHift-JIS固有の問題。
273:デフォルトの名無しさん
07/12/07 09:30:20
何そのとんちんかんなレスはw
274:272
07/12/07 09:42:22
あ、ダメかｗ
言いたいのは1～2バイトに収まるようにシンプルにしてほしいってこった
275:デフォルトの名無しさん
07/12/07 10:57:54
UCS-2の過ちを繰り返すのかよw
276:デフォルトの名無しさん
07/12/07 12:51:45
繁体字とか簡体字とかハングルとか要らんだろｗ
277:デフォルトの名無しさん
07/12/07 13:41:14
ハングルという偉大な文字は必要ニダ！
278:デフォルトの名無しさん
07/12/07 13:47:08
自分に必要なありとあらゆるソフトウェアを、その独自規格に準拠したもの
のみでまかなえるなら好きにすればー?
# 文字コードが、文字集合を情報「交換」のために符号化したものである
# ということを理解してないやつがこんなにも多いのは何故だ?
279:デフォルトの名無しさん
07/12/07 13:48:26
漢字なんかいらんだろ（米国人(32)）
280:デフォルトの名無しさん
07/12/07 13:59:54
その昔、Win3.1の時代に漢字対応の必要をアメリカ人に説明しようとしたら、
通訳が「Chinese Characters」って訳しやがって説明に苦労したもんだぜ。
281:デフォルトの名無しさん
07/12/07 15:02:01
もうUTF-8で全部解決だろ
282:デフォルトの名無しさん
07/12/07 16:58:25
Unicode の符号化という点ならそうだけど
Unicode に入れられそうもない変体仮名とかを
符号化する場合を考えると Unicode だけに
頼れないし
283:デフォルトの名無しさん
07/12/07 18:32:19
plain textは諦めてくださいと遠くからUnicode神の声が聴えてきました。
ところで変体仮名のみの文字集合は既に定義されているのですか?
あるとすれば、どういう包接基準を採用しているのですか?
284:デフォルトの名無しさん
07/12/07 20:36:47
るりーる
285:デフォルトの名無しさん
07/12/07 21:04:53
>>272
>>265みたいなことをしたらShift_JISと同じ(もっと悪い)問題が起きるって
言ってるんだが。
>>282
入らないのは日本が入れろと言わないから。
異体字だって結局米国企業のAdobeが登録するまで日本は
なーーーんにもしなかった。
286:デフォルトの名無しさん
07/12/07 21:05:18
>>283
とりあえずTRONにはあるようだ
Wikipedia項目ﾘﾝｸ
287:デフォルトの名無しさん
07/12/07 21:06:31
>>283
TRONコードに住民基本台帳収録変体仮名とその他の変体仮名が入ってる。
ということは住基統一コードにも変体仮名が入ってるのか
288:デフォルトの名無しさん
07/12/07 21:12:47
こういう文字をUnicodeに入れてくれって言う場合の
日本側の窓口はどこなんだろ。経産省？
密室でやらずに一回ぐらいパブリックコメントの募集してくれよ。
289:デフォルトの名無しさん
07/12/07 21:14:56
こんだけオープンにやってて密室もへったくれもあるか
URLﾘﾝｸ(std.dkuug.dk)
IVDの前回の公開レビューだって
URLﾘﾝｸ(www.unicode.org)
終了一週間くらい前になって気づいた俺が触れて回るまで
日本で取り上げているサイトが一切なかったという関心のなさっぷり
それで密室とかなんとかいっても説得力のかけらもない
290:デフォルトの名無しさん
07/12/07 21:37:49
そこへ持ってゆく文字の選定をしている日本側の窓口の話をしてるんだが。
291:デフォルトの名無しさん
07/12/07 22:11:20
とりあえず、英語が読めない人は、翻訳者を雇わないと、
投稿手順すら分からないのではないかと。
292:デフォルトの名無しさん
07/12/07 22:17:00
>>287
wikipediaにあるわw
Wikipedia項目ﾘﾝｸ
URLﾘﾝｸ(www.chokanji.com)
TRONは何でもぶちこみ方式だろうから、
まだ異体字の包接基準はないのかな。
かなり知識がないと無理だね。
293:デフォルトの名無しさん
07/12/09 10:03:04
TRONはコード表はフリーなんだけど
その運用に事実上必要な異体字のデータベースで金稼いでるんだよね
超漢字検索で変体仮名を検索すると関連字として対応する漢字やひらがなが
出てくるし漢字から変体仮名を検索することもできる
294:デフォルトの名無しさん
07/12/09 12:07:54
いっそ日本代表は無視してUTCのfull memberになったほうが話が早いかもしれない
英語力と金が必要だけど
295:デフォルトの名無しさん
08/01/02 16:32:43
あけましておめでとうございます
結局JIS X 0221の改訂版は2007年中に出ませんでした。
JIS X 0213:2004で2004となるべきところが2003となるような誤植が
今回も発生するのでしょうか。
296:デフォルトの名無しさん
08/01/05 01:13:42
>>295
えっまぢ！？
そういや、12月20日前後の官報がデッドラインだと聞いてたんだけど、
チェックするの忘れてたよ。。。
あーあ、また関係者は地獄を見ることになるのかな・・・
297:デフォルトの名無しさん
08/01/05 01:33:09
そうこうしている間にもamendmentは増えてゆく～
298:デフォルトの名無しさん
08/01/05 01:43:49
>>296
ietf-charsetsで外人が「Hey, 内容変更が何もないのにどうして-2003が-2004
になったんだい? (大意)」みたいなことを安岡センセイに聞いてたのを思い出した。
そりゃ知らないやつは不思議に思うよなあ
299:デフォルトの名無しさん
08/01/05 06:06:50
ちゃんと出てるじゃん
制定年月日2007/12/20になってるから本当にギリギリだったみたいね
300:デフォルトの名無しさん
08/01/05 07:17:14
JISCで閲覧できる規格票が
CJKU_SR.txtをわざわざ50MBのPDFにしてたりしてワロタ
301:デフォルトの名無しさん
08/01/12 07:17:23
>>300
中の人が内規かなにかに従った結果なんだろうね
302:デフォルトの名無しさん
08/01/12 12:12:01
見た目までコントロールしたいからでしょ。
フォント環境の違いで誤解が生じないように。
303:デフォルトの名無しさん
08/01/12 12:27:42
仮にそうだとしてもフォントを埋め込めば済む話ではないの？
304:デフォルトの名無しさん
08/01/12 12:28:15
ただ数字が並んでるだけなのにどう誤解するというのだ
そもそも正文がテキストファイルなんだが
305:デフォルトの名無しさん
08/01/16 19:29:38
質問です
URLﾘﾝｸ(www.ac.cyberhome.ne.jp)
> 1文字毎をメモリに持つのではなく全てバイト列で処理すると言った方法の為、
> 他のアプリケーションとは違うi18n化の方法であり特殊ではあるが
普通のi18n対応アプリケーションは文字ごとに(codepointごとに?)
メモリに確保して、文字配列として処理されることが多い、けれども
バイト列で処理する…バイト列を喰わせても大丈夫な関数を用意して文字を操作する
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
*Javaとかのアプローチはcodepointごとに文字を操作。(分解合成がめんどい)
*Vimのアプローチはバイト列を独自関数で文字として操作。(patch workの集大成)
oniguruma とか sakura editor とか emcode.pm とか身近にあるのは
みんなpatch workの集大成なのですか？
306:デフォルトの名無しさん
08/01/16 19:40:01
> 他のアプリケーションとは違うi18n化の方法であり特殊ではあるが
ん、じぶんの理解だとここの部分の意図が汲めなくなるか…
内部で Unicode の codepoint に従って処理しているソフトは
あまりないけど…内部でなんらかのエンコードに変換して保持
してるソフトは多くて…でもVimはバイナリのまま保持するですよ…?
というような意味とか? ああなんかよくわからなくなってきた…orz
307:デフォルトの名無しさん
08/01/16 21:53:51
マルチバイト or ワイド文字と分解合成とは直交する問題だろ。
何が言いたいのだろう。
308:デフォルトの名無しさん
08/01/17 13:22:34
まともなi18nの仕事で「patch workの集大成」でないものなんてないぞ。
全ての文字、言語に通じている人間なんていないのだから。
309:デフォルトの名無しさん
08/01/17 14:09:39
仕様が実際patch workだからな
というか言語というものがそもそも...
310:デフォルトの名無しさん
08/01/18 14:46:18
>>307
URLﾘﾝｸ(anond.hatelabo.jp)
>喫煙と、麻薬や飲酒は直交する問題だと思いますが…
直行する = 相関性のみられない事象のこと = 分けて論じるべき議題
うむ。まずじぶんは小学生あたりからやり直すべきか。
てか日本語って難しいな orz
>>308-309
㌧くす。言語は日々の積み重ね。ちぃおぼえた
311:デフォルトの名無しさん
08/01/18 15:00:13
URLﾘﾝｸ(homepage.mac.com)
>「おそらく漢字ほど難しくないからそれほどでもないと思うけど、例えば
>"than" を "then" と書く若者が増えてるよ。」っと言っていました。
>「それって全く意味が違うじゃん。」っと言ったら、「orthogonalだね。」と
>言われました。「orthogonalって何？」と聞いたら、90℃（直角）との事。
>「何で180℃じゃないの？」っと聞いたら、「反対の意味って訳じゃないけど
>（左右みたいな）、ぜんぜん違う意味だから、orthogonalって言うんだよ。」
>っと教えてくれました。面白い表現ですね！
『欧米かっ！』と言わざるを得ない…。
グラフをイメージして相関性云々とか考え出すと,
なんで90度でねじれの関係になるんだ, とかわけかわからんかった orz
312:デフォルトの名無しさん
08/01/18 15:52:55
>>310
> >>307
> URLﾘﾝｸ(anond.hatelabo.jp)
> >喫煙と、麻薬や飲酒は直交する問題だと思いますが…
> 直行する = 相関性のみられない事象のこと = 分けて論じるべき議題
誤変換かもしれないが、直交と直行を混同するようでは先がおもいやられる...
313:デフォルトの名無しさん
08/01/18 16:25:40
本来の意味で使ってる可能性も・・・
314:デフォルトの名無しさん
08/01/18 17:07:36
>>310
文脈から汲めば、分けられないってことだろ
とはいえ>>312みたいな態度が一番気に食わん
315:デフォルトの名無しさん
08/01/18 17:59:53
直交ずる～というと2つのベクトルの内積(2直線の射影でもいいや)を考えるでしょ常考。
高校数学程度の概念は常識として知っておいてくださいな。
316:デフォルトの名無しさん
08/01/19 03:20:48
この文脈でそんな本来の意味の用語を使うわけないでしょ。
それくらい想像力働かせてくださいな。
317:デフォルトの名無しさん
08/01/19 07:02:46
直交⇔互いに独立
∴2つのベクトルの内積(2直線の射影でもいいや)=0
318:デフォルトの名無しさん
08/01/19 07:08:44
「2つのベクトルの内積(2直線の射影でもいいや)」が0以外の値を持つとき
それらは直交しない
つまり「直交」については最初から一貫して「本来の意味」で使われているw
馬鹿は >>315
319:デフォルトの名無しさん
08/01/19 12:20:41
数学総合スレはここですか?
320:デフォルトの名無しさん
08/01/19 14:12:35
>>319
直帰を許可します
321:デフォルトの名無しさん
08/01/21 00:06:37
ん？この流れム板のどこかのスレで見た気が。デジャヴ？
322:デフォルトの名無しさん
08/01/30 01:45:55
SJIS2004とかJISX213系の文字コード表って無いですかね
どうも変換がうまくできない・・・
323:デフォルトの名無しさん
08/01/30 07:47:52
JISCにあるじゃん
324:デフォルトの名無しさん
08/01/30 23:27:43
JISCのPDFから手で書き取れと申すか
※無料で閲覧できる奴じゃなくて購入したPDFでも手で書き取らされます
とりあえず機械可読な奴がほしかったらここでも見れ
URLﾘﾝｸ(x0213.org)
325:デフォルトの名無しさん
08/01/30 23:32:34
＞※無料で閲覧できる奴じゃなくて購入したPDFでも手で書き取らされます
ごめんJISCを甘く見てた……
326:デフォルトの名無しさん
08/01/30 23:40:52
JISC・・・ひでえな。
327:デフォルトの名無しさん
08/02/01 21:15:44
www.unicode.org落ちてる?
328:デフォルトの名無しさん
08/02/05 21:26:41
Joel Spolsky氏のブログ翻訳「ソフトウェ開発者なら絶対に最低限知っていなければならないユニコードと文字セットについて」
Servlet Garden ≫ Unicode and Character Sets (Translation)
URLﾘﾝｸ(www.t3.rim.or.jp)
329:デフォルトの名無しさん
08/02/05 23:42:35
Unicode Transformation Format 8 と UCS Transformation Format 8 で混乱するのだけど
それぞれをどう解釈したらいいんだろう？
330:デフォルトの名無しさん
08/02/05 23:56:23
略せばどっちもUTF-8。はい、同じ。
331:デフォルトの名無しさん
08/02/06 00:00:19
Unicode.orgがつけた名前
ISO/IECがつけた名前
中身おんなじ
332:デフォルトの名無しさん
08/02/06 00:11:42
互換性あるのはわかったけど、Unicodeのが4バイト、
UCSのが6バイトみたいなこと書かれてたんで5バイト目以降は違うってことかな？
333:デフォルトの名無しさん
08/02/06 00:32:16
ISO/IEC 10646はAmd2:2006で、0群17面以降には永久に文字を追加しないことにしたから
UTF-8にしたときには5オクテット以上にはならない。
Uniocde.org的には、単に追加予定なしなだけなので、UTF-8は理屈上最長の
6オクテットまで使っていいけど、でも文字入ってないよ？状態。
だから、結局中身おんなじ
334:デフォルトの名無しさん
08/02/06 01:09:46
もともとUnicode的にUTF-16の絡みで10FFFFまでになって、
おれにAmd2:2006で追従したんじゃないっけ。
どちらにしろ、今はどちらも4byteまで。
URLﾘﾝｸ(www.rfc-editor.org) 参考までにRFC
335:デフォルトの名無しさん
08/02/06 02:42:04
なるほど。納得できたありがとう。
336:デフォルトの名無しさん
08/02/06 18:15:44
いつの間にかIVS(漢字のVS)正式に決定してた。
URLﾘﾝｸ(www.unicode.org)
337:333
08/02/07 08:54:13
>>334
そうみたいね
俺古いRFC見てたわ
338:デフォルトの名無しさん
08/02/19 23:13:06
U+FDD0～U+FDEFが使用禁止になったのって何でだろう?
339:デフォルトの名無しさん
08/02/22 20:04:35
JIS X 0221:2007規格票の8. 注記3によると
「符号化文字でないことが保証された数値を必要とする内部処理」に使用するためだそうだ。
例として「表を終了させる、テキストの終わりを通知するなど」が挙げられてる
340:デフォルトの名無しさん
08/02/23 03:05:40
文字コードふぜいが表の終了とか意識するな。
341:デフォルトの名無しさん
08/02/23 08:30:49
文字集合はともかく、
符合化方式がその辺りを考慮するのは当然。
342:デフォルトの名無しさん
08/02/23 09:17:36
あとU+FFFFはBMPの最後のコードだから番兵に使うことを特に意識している
U+FFFEは言うまでもなくBOM判別用
343:デフォルトの名無しさん
08/02/23 13:25:24
ASCII にだってコントロールコードの領域があるしね
344:デフォルトの名無しさん
08/03/12 02:47:39
文字コードとやらに興味を抱き、とりあえずユニコードが標準と知り、
番号からUTF-16を使っていたのですが、
このスレの人は何を主に使っているのですか？
検索をしていると16よりも8の話題のほうが見つかるので、
実は8のほうがいいのかなと悩んだりしています。
345:デフォルトの名無しさん
08/03/12 03:08:25
つか、今、同じテキストファイルを変換してみたのですけれども、
よくよく考えたらUTF-8は可変で日本語の文章に関しては、
全てを2バイトで扱うUTF-16に比べて、
日本語部分を3バイトで扱うUTF-8は情報量が多いほど、
容量が無駄に大きくなってしまいませんか?
1.5倍ですよね。それを補うほどの使い勝手の良さがあるのでしょうか。
346:デフォルトの名無しさん
08/03/12 03:14:34
南北アメリカや西ヨーロッパの多く言語は平均すると一文字当たり2オクテット未満であらわせる。
347:デフォルトの名無しさん
08/03/12 03:27:30
後は１要素が1byteに収まるから扱いが楽、とか
まぁ日本語を基準に考えてる時点でUnicodeの思想から外れてる気はする
348:デフォルトの名無しさん
08/03/12 09:29:53
>>344
1.5倍程度でけちけちするな、多言語化ってのはそういうもんだ。
マジレスするとUTF-8側にメリットがあるというよりも、
UTF-16側がサロゲートペアやバイトオーダー、ASCII非互換、guessしずらいなど、
いろいろと面倒なのでUTF-8の方がよい。
349:デフォルトの名無しさん
08/03/12 10:57:52
WindowsがUTF-16なんで、自分のプログラムもUTF-16です。
350:デフォルトの名無しさん
08/03/12 23:33:43
ケチ臭いことを言うんだったら、ASCIIの制御文字の部分の方が勿体無いと思うけどね。
ホントにASCIIてクソだなあ。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5386日前に更新/157 KB
担当:undef