- 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
- 267 名前：デフォルトの名無しさん mailto:sage [2005/08/03(水) 05:31:13 ]
- なぜか文字集合の違いにしたがってる奴がいるようだが
同じJIS X 0208:1997やJIS X 0213:2004で字形が違ってたってぜんぜん不思議
じゃないのだが。喪前らこそ規格票読んでるのか?
参考:
toyohira.asablo.jp/blog/2005/07/30/38169
- 268 名前：256 mailto:sage [2005/08/03(水) 05:55:02 ]
- いちおう漏れの疑問の意図を説明しとくと、
規格に適合してるか否かを聞きたかったんじゃなくて(適合するのは分かってる)
新ＭＳ ゴシックとMeiryoはどちらも同じシステム上に標準で存在する
2004JIS対応を主張するフォントなのに、切り替えただけで文字化けが発生する
仕様なわけだが(規格上はもちろん問題ないが)、
MicrosoftはVistaに標準で存在する日本語フォントだけでもなんとかする気は
なかったのか? ってことなんだが。
文字化けが発生する「仕様」であることを世間に思い知らせるためあえてこう
したのかもしれんが、互換性を無視してそこまでdrasticな考えができるなら
IEはとっくの昔にCSS完全準拠になってるはずだし。
- 269 名前：デフォルトの名無しさん mailto:sage [2005/08/03(水) 06:59:16 ]
- >>268
まだVistaがβだからであって、正式版までには解消されている、って期待はないの？
- 270 名前：デフォルトの名無しさん mailto:sage [2005/08/03(水) 07:04:13 ]
- >>269
マジでそう期待したい。
ちなみに正式版ではどう解消されてる(する余地がある)と思う?
- 271 名前：デフォルトの名無しさん mailto:sage [2005/08/03(水) 10:21:48 ]
- 表外漢字字体表の字体に変更すると、
JIS X 0213と矛盾が生じる文字についてはどうなっているの?
- 272 名前：デフォルトの名無しさん mailto:sage [2005/08/03(水) 11:39:59 ]
- >>271
その28文字については、表外漢字字体表の字体変更しないんじゃない?
当たり前だけど。
www.yomiuri.co.jp/national/culture/news/20050729i306.htm
にもある168文字の内訳ってどこかに書いてある?
- 273 名前：デフォルトの名無しさん mailto:sage [2005/08/03(水) 12:25:41 ]
- 補助漢字を無視したいところだけど、
補助漢字はUnicodeに入っているしねー。
- 274 名前：デフォルトの名無しさん mailto:sage [2005/08/03(水) 16:34:57 ]
- >>263
> つーか「考え方」の5-(7)ってどれだよ
www.jsa.or.jp/domestic/instac/h13reports/JCSmain_Web.pdf
じゃないかな。(読んだことがある人ならすぐピンと来るはず)
internet.watch.impress.co.jp/www/column/ogata/sp13.htm
internet.watch.impress.co.jp/www/column/ogata/sp13/hyou2.htm
に、その要約があるけど、(調査報告には例示字体の表もある)
その9つのケースについて、現状のVista&Meiryoでどうなっているか、
誰かまとめてくれる人いませんかね? (僕は残念ながら持ってないです…)
- 275 名前：デフォルトの名無しさん mailto:sage [2005/08/03(水) 17:13:03 ]
- >>274
＞現状のVista&Meiryo
要はOpenTypeの'jp04'グリフってことじゃねえの？
そうであれば、基本はJIS04が変更したとおり。
ただし「微細な字形差」に関しては無視しているものもある。
- 276 名前：デフォルトの名無しさん mailto:sage [2005/08/03(水) 21:57:21 ]
- >>272
> 168文字の内訳
JIS X 0213:2004に関する経済産業省の報道発表
ttp://www.jisc.go.jp/newstopics/2005/040220kanjicode.pdf
- 277 名前：デフォルトの名無しさん mailto:sage [2005/08/04(木) 03:36:56 ]
- >>275
なんとMeiryoには'jp04' featureがない('nlck'はある)。AJ1-5相当だから
当然かもしれんが。
正式版までにサポートされるのかサードパーティー製のAJ1-6フォントを
インストールしたときに備えてAPIの口のみ用意してるのかは知らん
- 278 名前：デフォルトの名無しさん mailto:sage [2005/08/04(木) 03:41:12 ]
- >>271
別区点に追加されたほうの面区点を使えってこと
- 279 名前：デフォルトの名無しさん mailto:sage [2005/08/04(木) 03:47:56 ]
- > じゃないかな。(読んだことがある人ならすぐピンと来るはず)
5-(7)って数字の根拠が分からない。そんな章番号とかはないみたいだし
> その9つのケースについて、現状のVista&Meiryoでどうなっているか、
Meiryoは単なるAJ1-5相当のOpenTypeフォント(要するにデフォルト字形は90JIS)。
だから>>256のような「文字化け」が起きる
- 280 名前：デフォルトの名無しさん mailto:sage [2005/08/04(木) 04:12:15 ]
- > 5-(7)
ようやく分かった。2.1.5 (7)のUCS互換漢字10文字のことか。
当然2004JIS・ISO/IEC 10646:2003がやったとおりのことをやって対応
(字形変更ではなく対応するUCS符号位置のグリフを追加実装)。ヒラギノなんかと一緒。
- 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;(瘢雹)は挟まるだけだからまだマシ
<→<や>→>はその後が全部化ける
- 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にはＸＸＸという文字があるけど違う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
|
 |
