UnicodeとUTF-8の違いは？　その2

1 名前：デフォルトの名無しさん [2010/11/30(火) 09:00:05 ] 富士通だとデフォルトでは生成されない frt -c -Am -M./ (なんとか.f90) でいけるのではなかろうか。いずれにせよ、 frt -help | less とかやって、"module"で検索を掛けるのが吉。 357 名前：デフォルトの名無しさん mailto:sage [2011/08/06(土) 00:15:01.41 ] もともとこのスレはUnicodeをUTF-16系のエンコーディングと勘違いした 人が立てたんだと思うが、MSだけでなくJavaもUnicode=UTF-16なんだっけ？ 358 名前：デフォルトの名無しさん [2011/08/06(土) 00:38:20.18 ] >>354 >>351 359 名前：デフォルトの名無しさん mailto:sage [2011/08/07(日) 04:48:33.66 ] >>357 おＪＡＶＡ様の"Unicode"は 　デコード時：ビッグエンディアンUTF-16、BOM許可 　エンコード時：ビッグエンディアンUTF-16、BOMあり Windowsの"Unicode"は 　デコード時：リトルエンディアンUTF-16、BOM許可 　エンコード時：リトルエンディアンUTF-16、BOMあり 360 名前：デフォルトの名無しさん mailto:sage [2011/08/07(日) 14:43:57.06 ] >>359 >UTF-16、BOM許可 冗長な表現だな。UTF-16エンコーディングスキームは常にBOM許可なんだよ。 "UTF-16LE"→BOM禁止 "UTF-16BE"→BOM禁止 "UTF-16"→BOM許可 Javaの"Unicode"は先頭のBOMを読み飛ばすから"UTF-16"。 ちなみにJavaの"UTF-8"はBOMをNBSPと認識する統一性の無い仕様。 Javaも.NETも、文字コードに表現の曖昧さのあるものは 区別できるようならないものかな 　"UTF-8"　→実行環境の規定のUTF-8表現 　"UTF-8:wBOM"　→先頭にBOM必須 　"UTF-8:w/BOM　"→先頭のFEFFはNBSP 　"UTF-8:autoBOM"　→　先頭にFEFFがあればBOM　　みたいな 361 名前：デフォルトの名無しさん mailto:sage [2011/08/07(日) 14:47:36.25 ] BOMって文字コードの一部なのか？ たとえば、「あいうえおかきくけこ」という文字列を split関数で2つに分けたとき、「(BOM)あいうえお」「(BOM)かきくけこ」になるのか？ 違うだろう？ BOMはマックバイナリみたいなもので 文字の一部ではなくファイル形式の一種だと思うんだが。 362 名前：デフォルトの名無しさん mailto:sage [2011/08/07(日) 14:55:48.67 ] BOMはデータストリームの一部で、 データストリームの先頭にあるとシグネチャと看做されます。 363 名前：デフォルトの名無しさん mailto:sage [2011/08/07(日) 15:02:40.62 ] ISO-2022のエスケープシーケンスを文字コードに含むぐらいには文字コードかな。 Unicode 6.0の16.8には「U+FEFF at the very beginning of a file or stream」とあるね。 ただの文字列がstreamに含まれるかと言えば普通の感覚ではNoだけど、 絶対ダメと断言するには表現が曖昧な気がする。 streamの定義をきかれたら「一連のcharacter」としか言いようが無いから。 364 名前：デフォルトの名無しさん mailto:sage [2011/08/07(日) 15:29:54.27 ] はっきりとin the unicode data streamと書いてる。 unicode.org/faq/utf_bom.html#bom1 Byte Order Mark (BOM) FAQ Q: What is a BOM? A: A byte order mark (BOM) consists of the character code U+FEFF at the beginning of a data stream, where it can be used as a signature defining the byte order and encoding form, primarily of unmarked plaintext files. Under some higher level protocols, use of a BOM may be mandatory (or prohibited) in the Unicode data stream defined in that protocol. [AF] 365 名前：デフォルトの名無しさん mailto:sage [2011/08/07(日) 16:33:38.94 ] 仕様でないものを仕様と勘違いする奴とか、常に正しい仕様が存在してくれていると思ってる奴とか、 プログラマやめた方がいいんじゃねーの 366 名前：デフォルトの名無しさん mailto:sage [2011/08/07(日) 23:35:37.51 ] 文盲がいるな。 >はっきりとin the unicode data streamと書いてる 一つ前のレスも読めないのか 367 名前：デフォルトの名無しさん mailto:sage [2011/08/07(日) 23:49:21.22 ] unicode data streamってのが 何かよくわからないけど、 わざわざ書いてるってことは、 特別扱い、つまり通常の文字とは別扱いなんだな。 368 名前：デフォルトの名無しさん mailto:sage [2011/08/07(日) 23:52:20.46 ] プログラム言語で扱う文字型はencoding schemeでなくencoding formの単位なので BOMになり得ない。 　encoding scheme: バイトデータ表現。BOMが付くことがある 　encoding form:「文字」単位の表現。BOMの概念無し。splitで扱うのはこっち char型(UTF-16/32文字)のFEFFはZWNBSとみなさなければならない。 それをバイトデータにエンコードして初めてBOMが付く。 369 名前：デフォルトの名無しさん mailto:sage [2011/08/07(日) 23:55:16.42 ] BOMが途中にあったらどうなるの？ 切り替わるの？ 370 名前：デフォルトの名無しさん mailto:sage [2011/08/08(月) 00:01:50.41 ] 文盲がいるな。 バイト配列をwchar_t(C)とかchar(Java)にデコードした時点でBOMは消えなきゃいけないの。 ちなみに途中にあらわれるものはBOMでなくU+FEFF文字として扱わなければならない 371 名前：デフォルトの名無しさん mailto:sage [2011/08/08(月) 01:07:46.83 ] 途中で現れるのは後方互換性のために許されてるだけで、 本当は途中に現れちゃ駄目。 372 名前：デフォルトの名無しさん mailto:sage [2011/08/08(月) 01:17:08.95 ] deprecateでも許されてるってことは、書き込むプログラムはともかく 読み込むプログラムは処理しなきゃいけないってこった 373 名前：デフォルトの名無しさん mailto:sage [2011/08/13(土) 06:53:27.25 ] Windows7HP 64bit、MS-IME2010ですが、IMEで変換中の文字コードは何でしょうか？ 質問は以下2点で、例えば、EUC-JPのテキストをエディタで編集中とします。 １．MS-IMEで変換中（この時の文字コードは？） ２．変換した文字を確定（変換中の文字コード → EUC-JPの変換は誰がどのタイミングで行っているのでしょうか？） 374 名前：デフォルトの名無しさん mailto:sage [2011/08/13(土) 10:46:33.19 ] >>373 1.ふつうはUTF-16 2.ふつうはテキストエディタの保存時 375 名前：デフォルトの名無しさん mailto:sage [2011/08/13(土) 10:57:29.48 ] >>373 普通はEUC-JPで表現できない文字も入力できて、保存時にエラーが出るよね。 ってことは編集中はEUC-JPじゃないってこった 376 名前：デフォルトの名無しさん mailto:sage [2011/08/13(土) 12:10:50.38 ] >>374-375 なるほど。 �d 377 名前：デフォルトの名無しさん mailto:sage [2011/08/14(日) 01:13:50.65 ] 他スレから来ました。 UNIXのshebangってBOMに対応できないの？ 378 名前：デフォルトの名無しさん [2011/08/14(日) 01:17:53.45 ] カーネルがバイナリファイルの先頭で #! の存在をチェックしている ところで、まずBOMの有無をチェックするように改造すれば可能かも。 379 名前：デフォルトの名無しさん mailto:sage [2011/08/14(日) 01:26:25.04 ] ファイルの先頭にFE FF 00 00を見つけたとき、 ・UTF-16BEのU+FEFF, U+0000 ・UTF-16のBOM, U+0000 ・UTF-32のBOM のいずれであるかの見分けはつくのでしょうか 380 名前：デフォルトの名無しさん mailto:sage [2011/08/14(日) 01:53:40.23 ] >>379 そのバイトオーダーでは迷う要素がどこにもないのだが… 381 名前：デフォルトの名無しさん mailto:sage [2011/08/14(日) 04:44:20.21 ] 先頭がBOMかU+feffかは、 エンコードスキームがutf-16なのかutf-16beなのか の情報が必要。 つまりエンコードスキーム情報無しに読むことは不可 382 名前：デフォルトの名無しさん mailto:sage [2011/08/14(日) 04:45:13.50 ] >>381 そのバイトオーダーでは迷う要素がどこにもないのだが… 383 名前：デフォルトの名無しさん mailto:sage [2011/08/14(日) 04:57:36.54 ] >>381 ならff fe 00 00ならどうするのよ？ 384 名前：デフォルトの名無しさん mailto:sage [2011/08/15(月) 00:39:15.78 ] >>382 FE FF 00 00ってのは例が悪くて>>383の間違いなんだろうけど、 「FE FF」にしたってBOMなのかU+FEFFなのか区別付かないよね？ 385 名前：デフォルトの名無しさん mailto:sage [2011/08/15(月) 00:50:44.72 ] Unicodeでは先頭のU+FEFFは常にBOMと解釈すべし、というルールだから、BOMであることに疑問はない。 ただしUTF-16LEによるBOM + U+0000という解釈とUTF-32LEによるBOMという解釈のどちらをとるべきかは 一意に決定する方法がない、という意味で>>383の指摘は正しいものだと思う。 386 名前：デフォルトの名無しさん mailto:sage [2011/08/15(月) 01:05:17.86 ] つ ttp://stackoverflow.com/questions/1929962/unicode-bom-for-utf-16le-vs-utf32-le バイトオーダマークであってエンコーディングを示すものじゃないから諦めろってさ 387 名前：デフォルトの名無しさん mailto:sage [2011/08/15(月) 02:30:12.19 ] >>385 >先頭のU+FEFFは常にBOMと解釈すべし んなこたーない。 Unicode 6.0.0「3.10 Unicode Encoding Schemes」D96 『In UTF-16BE, an initial byte sequence <FE FF> is interpreted as U+FEFF zero width no-break space』 D98 『In the UTF-16 encoding scheme, an initial byte sequence corresponding to U+FEFF is interpreted as a byte order mark』 UTF-16BEなら先頭のFE FFはU+FEFF。UTF-16なら先頭のFE FFはBOM。データから区別は出来ない。 388 名前：デフォルトの名無しさん mailto:sage [2011/08/18(木) 00:42:00.98 ] 先頭の<FE FF>がBOMなのかfeff文字なのか判断できないなんて、 BOM考えた奴、ばかなの？ 389 名前：デフォルトの名無しさん mailto:sage [2011/08/18(木) 07:30:27.15 ] Unicode自体が馬鹿の塊なのは欧米人以外なら即分かると思うが 390 名前：デフォルトの名無しさん mailto:sage [2011/08/18(木) 22:29:40.94 ] >>389 どの辺が馬鹿の塊なのか解説よろしく 391 名前：デフォルトの名無しさん mailto:sage [2011/08/19(金) 15:06:30.40 ] 香具師らの認識している「表意文字」とはアイコンのことだからなぁ 392 名前：デフォルトの名無しさん mailto:sage [2011/08/19(金) 20:08:38.83 ] だから今は漢字のことを表語文字と呼んだりするね 393 名前：デフォルトの名無しさん mailto:sage [2011/08/28(日) 23:49:09.53 ] >>390 当初16 bitで収まると考えていたことなんか、素人の俺にもすぐに指摘できる。 394 名前：デフォルトの名無しさん mailto:sage [2011/08/29(月) 01:00:05.33 ] >>393 かつてそう考えたミスは事実だが、今はコードポイントが U+10FFFFまでに修正され、UTF-32とUTF-8は無理の無い形で 対応出来てるだろ。 「Unicode自体が馬鹿の塊」の理由は説明出来ないのかな？ 395 名前：デフォルトの名無しさん mailto:sage [2011/08/29(月) 01:32:35.26 ] >>389でも>>393でもないが 正規化すると互換漢字が統一漢字になるところは時々キレそうになる 自分は異体字セレクタでやればいいんだけど、他人に渡す時に対応エディタがないから揉める あと他人から受け取ったファイルに互換漢字が大量に含まれてたりするともうね・・・ 396 名前：デフォルトの名無しさん mailto:sage [2011/08/29(月) 01:43:05.53 ] >>394 無理はあるだろ 16bitとか考えなきゃ、最初っからCJKなんて無謀なこともしないで済んだし、そうすればコード変換の コストも大幅に軽減されたし、i18n対応のソフトがフォントでつまずくようなことも起きなかったし 他にもさまざまな問題が事前にことごとく指摘されてたのに強行して、結局無理でした、だからな 397 名前：デフォルトの名無しさん mailto:sage [2011/08/29(月) 02:27:50.75 ] >>394 > かつてそう考えたミスは事実だが、今はコードポイントが > U+10FFFFまでに修正され、UTF-32とUTF-8は無理の無い形で > 対応出来てるだろ。 その代償として、Unicodeは複雑化してしまった。 UTF-32、UTF-16、サロゲートペア、UTF-8、なぜ一つに統一しなかったのか。 最初から世の中の文字はすべて32bitで扱うとなっていれば、プログラムも簡単だっただろうに。 OS、言語、すべてが同じUTF-32を使う。さっさと移行しておけばよかったのに。 第一の失敗UTF-16、これがあったせいでWindows、Mac、JavaはUTF-16を 標準のものとしてサポートしてしまった。今更UTF-32にはやすやすと移行できないだろう。 おかげでサロゲートペア対応とか変なモノが後で導入された。 第二の失敗UTF-8、これのせいでUnix系はASCII文字と互換性を保てるようになってしまった。 そのせいで、UTF-8はなかなか消せなくなっただろう。 もう一文字がすべて同じ32bitの世界は絶望的だよ。 398 名前：デフォルトの名無しさん mailto:sage [2011/08/29(月) 03:31:52.42 ] ＞もう一文字がすべて同じ32bitの世界は絶望的だよ。 いや、それは結合文字ある時点で絶望的だろ、と突っ込んでみる UTF-16がクソなのは同意だがUTF-8は需要多かったからどの道生まれただろうし 399 名前：デフォルトの名無しさん mailto:sage [2011/08/29(月) 08:01:59.08 ] >>395 自分の処理目的に適した基準でnormalizeすれば良いよ。decompositionだけ無くすとかね。 外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。 OSXだと互換漢字は除外してnormalizeするAPIとかも用意されてる。 400 名前：デフォルトの名無しさん mailto:sage [2011/08/29(月) 08:11:50.68 ] ぜんぜんCJK非分離の解決になっていない件 401 名前：デフォルトの名無しさん mailto:sage [2011/08/29(月) 11:17:14.00 ] 漢字は本当に、普通に見た目が違う字が出るもんなぁ 402 名前：デフォルトの名無しさん mailto:sage [2011/08/29(月) 11:41:22.44 ] >>399 要件にわざわざ『Unicode正規化(C方式)』と入ってなければ 或いは、送ったファイルが何故か相手側で正規化される、そんな可能性が無視できるなら Apple独自規格だろうがなんだろうが喜んで使おう ただ、その場合はそもそも正規化する必要がないんだけど 403 名前：デフォルトの名無しさん mailto:sage [2011/08/29(月) 11:55:21.11 ] >>399 ＞外に出す時に、必要なら改めてUnicodeの規格に沿ってnormalizeし直せば良い。 必要だからやる→>>395 自分勝手にnormalizeしたところで何の解決にもならん罠 404 名前：デフォルトの名無しさん mailto:sage [2011/08/30(火) 22:01:52.91 ] 正規化についても、みんなで仲良く正規化しないと、 いろいろ面倒なんだよなあ。 例えば、外部からきたUSBメモリ上のパス名まで正規化されているかどうかとか。 内部的には正規化してから処理するとしても、 再度書きこむ時に正規化すべきか、それとも元のままにしておくか、 元のままにしておく場合、保存しておかなければならないし。 >>397 > UTF-32、UTF-16、サロゲートペア、UTF-8、なぜ一つに統一しなかったのか。 ちょっとこの列挙の仕方はどうかと。 言わんとしていることは分からないでもないが、 最初から32bitじゃまとまらなかっただろう。 405 名前：デフォルトの名無しさん mailto:sage [2011/08/31(水) 10:41:56.92 ] 受け入れられるためには理想の仕様は諦めて妥協しないといけない、 かといって妥協しまくりのダメ仕様でも誰も使わない。 その結果を一見して「迷走」と決めつけることは誰にもできるw 406 名前：デフォルトの名無しさん mailto:sage [2011/08/31(水) 11:50:16.72 ] 16bitは必要な妥協だったとは思わんがな 407 名前：デフォルトの名無しさん mailto:sage [2011/09/01(木) 14:44:18.72 ] 根拠は？ どうなっていたのと思うの？ 408 名前：デフォルトの名無しさん mailto:sage [2011/09/01(木) 19:30:44.11 ] 必要な妥協だった、迷走ではない、と開き直るほうが簡単だよね でも互換漢字の中に統合漢字を適当に混ぜるとか、何も考えてないのは丸わかり 規格作ってるやつらは実装しなくていいんだから楽だよなあ 409 名前：デフォルトの名無しさん mailto:sage [2011/09/02(金) 12:27:42.35 ] 必要な妥協なんてものはそもそも無い。 ないものを攻撃している奴は馬鹿。 仕方ない妥協があるだけ。 410 名前：デフォルトの名無しさん mailto:sage [2011/09/02(金) 12:47:09.80 ] 仕方も工夫も色々あったけど 馬鹿が都合悪い部分放置でそのままreleaseしたんだろ なんで「仕方なかった」なんて嘘が通ると思うのか まだ「必要だった」って言い訳のほうがマシだよ 411 名前：デフォルトの名無しさん mailto:sage [2011/09/02(金) 13:14:29.07 ] >>409 >>408だけど、妥協そのものを攻撃してるんじゃなくて >>399みたいな開き直りについて言ってるだけだから 必要とか仕方ないとかそのへんの細かいニュアンスは俺の言ってる本筋とは関係ないから 412 名前：デフォルトの名無しさん mailto:sage [2011/09/02(金) 13:15:49.10 ] 安価ミスすまん >>399じゃなくて>>405ね 413 名前：デフォルトの名無しさん mailto:sage [2011/09/02(金) 15:51:45.81 ] 経緯をよく知らないけど、中国/日本の当局者に6万語で収まるのかをきちんと聞いたのか？ 単に憶測で6万語で収まると判断したのか？ 414 名前：デフォルトの名無しさん mailto:sage [2011/09/02(金) 18:11:44.98 ] Unicodeは最初からHan Unificationありき。 Xerox(とApple)でHan Unificationが研究されたから、 Unicodeが誕生のきっかけが出来た。 日本ではEmacsやArenaの多言語化を、 ISO 2022ベースでやっていた頃。 415 名前：デフォルトの名無しさん mailto:sage [2011/09/04(日) 05:22:06.88 ] >>414 最初から、というか、最初だけ。 誕生のきっかけであって、もう今ではとてもじゃないが、機能してるとは言えん 同じ字体が互換漢字・互換漢字両方で表せるのがまずおかしいのに さらにKS X 1001とかいう規格から、同じ字体で読みだけが違う互換漢字も追加されて 統一漢字＋異体字セレクタで統一漢字でも字体を変更できるようになって と思ったら異体字セレクタに汎用電子がAdobeと同じ字体を重複登録しはじめて トドメに、異なった統一漢字同士でも異体字セレクタによっては同じ字体になるんだから…… 416 名前：デフォルトの名無しさん mailto:sage [2011/09/04(日) 17:42:35.37 ] >>415 > 機能してるとは言えん はあ? 417 名前：デフォルトの名無しさん mailto:sage [2011/09/04(日) 19:33:51.55 ] うん、そうだね 418 名前：デフォルトの名無しさん mailto:sage [2011/09/05(月) 04:04:33.03 ] その通りだ 419 名前：デフォルトの名無しさん mailto:sage [2011/09/05(月) 22:01:45.96 ] >>294 アンダースコアの有る無しで意味が違う、っていうことの方が狂気の沙汰だと思う 420 名前：デフォルトの名無しさん mailto:sage [2011/09/05(月) 22:32:53.25 ] 狂気はお前だ。 421 名前：デフォルトの名無しさん mailto:sage [2011/09/06(火) 01:33:22.31 ] アンスコあるのと無いのでは全然違うだろ。 422 名前：デフォルトの名無しさん mailto:sage [2011/09/06(火) 02:42:07.11 ] アンダースコートは無い方が良い 423 名前：デフォルトの名無しさん mailto:sage [2011/09/10(土) 15:51:03.10 ] >>413 まずいよこれ無理だよ、ってのは少なくとも日本の機関や企業から結構発信してたはず 424 名前：デフォルトの名無しさん mailto:sage [2011/09/10(土) 18:02:22.29 ] 収まらないのはUnicodeが開発される前からわかっていた。 収めるためのHan Unificationが適切かどうかが議論になった。 >>414 > Unicodeは最初からHan Unificationありき。 > Xerox(とApple)でHan Unificationが研究されたから、 > Unicodeが誕生のきっかけが出来た。 425 名前：デフォルトの名無しさん mailto:sage [2011/09/10(土) 18:18:33.20 ] で、不適切だったと 426 名前：デフォルトの名無しさん [2011/09/10(土) 23:32:57.71 ] まだ天安門の頃か 427 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 00:10:00.22 ] >>423 それでも説得して変えさせることは出来なかった。 かといって代替を用意して それを普及させるだけの力もなかった。 ガラパゴス規格を作っては国内オンリーで威張る だけの親方日の丸体質では最初から無理でした。 せめて今後は上手く捻じ込む交渉術を学んでいただきたいものです。 無理か。無能なJIS関係者や学者に金撒くんじゃなくて 最初から、ロビイストに金を突っ込むのが正しいな。 428 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 00:46:24.54 ] 今更お金撒いてももう無理なんじゃない？ 文字コードには詳しくないんだけど プログラマのための文字コード入門読む限りでは 今後もシフトJISを使うのが一番安全という気がひしひしとしてくる。 実際、Windowsも内部はUnicodeだけどインタフェースはNLSを通してシフトJISを使うわけだし。 429 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 00:51:01.90 ] .Netでもそんな扱いだっけ？ 430 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:05:01.98 ] シフトJISってWindows以外じゃ使わないんだけどなあ… 431 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:09:02.77 ] シフトJISって恥ずかしいよね 432 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:21:12.38 ] Windows使いだが、業務用のバッチファイル以外でシフトJISなんか使わねーぞ。 ソースコードもHTMLもデータベースもテキストファイルも全部ウニコードにしてる。 ただメールだけはISO-2022-JPでないと文字化けする糞アプリが存在するので なかなかUTF-8に移行できない。 433 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:24:56.95 ] Visual C++がコードページにうにコードをセットできないのがすべての敗因。 コマンドプロンプトも未だにうにコード使えないし、ファイルシステム事態はうにコードを使えても ファイル名をやり取りするAPIの中にうにコード版が存在しないものが… WindowsだけシフトJISで。 434 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:32:12.35 ] >コマンドプロンプトも未だにうにコード使えないし cp 65001 435 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 01:39:37.21 ] >>433 ttp://yukarin.wiki.fc2.com/wiki/Tips 436 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 02:07:10.34 ] よし、コマンドプロンプトのうにコード問題は解決したぞ あとはVC++がlocaleにうにコードをセットできるようになってくれれば解決だ。 437 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 02:07:27.82 ] ほー。 chcp 65001すると今まで動いてた以下のコードが正しく動かないんだがどうすればいい？ 　_tsetlocale(LC_CTYPE, _T("")); 　_tprintf(_T("マンコ\n")); 438 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 02:56:46.07 ] windows のシステムロケールを変更して再起動 439 名前：デフォルトの名無しさん mailto:sage [2011/11/08(火) 08:53:05.57 ] mendoxer! 440 名前：デフォルトの名無しさん mailto:sage [2011/11/17(木) 03:47:25.53 ] 囗囘囙囚四囜囝回囟因囡团団囤囥囦囧囨囩囪囫囬园囮囯困囱囲図围囵囶囷囸囹固囻囼国图 囿圀圁圂圃圄圅圆圇圈圉圊國圌圍圎圏圐圑園圓圔圕圖圗團圙圚圛圜圝圞 441 名前：デフォルトの名無しさん mailto:sage [2011/11/19(土) 21:17:47.39 ] シフトJISはWindowsだけってことはないと思うぞ。 むしろ自分の周りだとWindows以外のシステムはいろいろあるけど 情報交換はシフトJISでまず問題がない。ユニコードにお目にかかる ことのほうが滅多にない。 442 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 04:14:11.87 ] >>441 > 情報交換はシフトJISでまず問題がない。 老害しねや 443 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 11:36:54.27 ] 最近は中国人の顧客とかも増えてるからUnicode対応じゃねーと死ぬわ俺んとこは 444 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 12:29:01.95 ] 異体字セレクタと互換漢字どっち使うにしてもUnicodeは地獄 445 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 20:58:49.78 ] 互換漢字・意自体セレクタはUnicodeよりシフトジスの方が優れていると？ 446 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 21:12:01.10 ] 中国の客とか、その時点で死だろ 447 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 21:17:11.83 ] 異体字があっても意味を区別できるヤツなんて 1000人に1も居ないんだから、異体字なんて駆逐してしまえ。 国も時代に合わせろよ。 448 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 22:39:49.13 ] 全国の渡邊さんと渡邉さんがアップをはじめたようです 449 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 02:15:21.62 ] 源規格分離のUnicodeに移行すれば、メリットは多数あってもデメリットは無いだろ。 互換漢字とか話をすり替えてユニコード批判するしかないとは。 いつまで20世紀に生きてるんだよ 450 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 13:52:38.60 ] >>444だけど、>>441書いたのは俺じゃないからな 当然だけどShift_JISが使えない規格ってのが大前提だが >>449みたいなやつも程度としては>>441と同レベルだわ デメリットないとか本気で言ってんならな そりゃ、ソフトウェアを源規格分離のUnicodeで作るだけなら楽だけど 使うやつはUnicodeのことなんてなにも分かっちゃいないんだぞ 使われてるうちにデータがどういう惨状になるか分かってんのか…… 451 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 15:03:02.41 ] >>449 は全ての問題が解決した22世紀から来た人なんだろう、多分 452 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:24:22.16 ] >>449 合成漢字とか、マイナーな漢字で問題が有るっちゃあるらしい。 だから、PDFに複数のエンコーディングを同時に使いたいという需要が あったりする。 453 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 08:26:11.02 ] 原規格分離でも、別規格の文字が同じコードポイントという致命的欠点を「前世紀に批判」と誤魔化してみても、 その致命的欠点が前世紀からそのままであるという事実は変わらないけどなw 454 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 20:20:13.17 ] >453 それは別に致命的な欠点ではないだろう 統一漢字をせっかくまとめたのに、互換漢字を作ったのが失敗なんだよ 最初から異体字はセレクタでよかった 455 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 20:50:09.36 ] 使い物にならないままでよかった、とw 456 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 20:56:22.92 ] ﾊｧ? 457 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 11:51:28.97 ] 痛い字セレクたん

---

---

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

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