文字コード総合スレ part3
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
2007/05/27(日) 16:19:36■前スレ
文字コード総合スレ part2
http://pc11.2ch.net/test/read.cgi/tech/1143375639/
■参考サイト
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
0002デフォルトの名無しさん
2007/05/27(日) 16:31:01http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/
池田証寿
http://homepage3.nifty.com/shikeda/zatsubun.htm
0003デフォルトの名無しさん
2007/05/27(日) 16:41:09※◆ゲイの美容◆※ 01/01/21-01/01/23 <9>
http://yasai.2ch.net/gay/kako/980/980019809.html
ゲイの美容版・・・・・・ 01/07/17-01/07/22 <17>
http://yasai.2ch.net/gay/kako/995/995353433.html
ゲイの美容第３弾！ 01/08/14-01/08/28 <28>
http://yasai.2ch.net/gay/kako/997/997765965.html
ゲイの美容第６弾！ 01/11/21-01/11/27 <7>
http://yasai.2ch.net/gay/kako/1006/10063/1006327106.html
ゲイの美容 00/09/25-00/12/05 <981>
http://piza.2ch.net/gay/kako/969/969815437.html
0004デフォルトの名無しさん
2007/05/28(月) 20:22:230005デフォルトの名無しさん
2007/05/28(月) 20:30:520006デフォルトの名無しさん
2007/05/29(火) 05:29:15iモード絵文字つぶしてそんな実装することはありえないと思うけど
0007デフォルトの名無しさん
2007/05/29(火) 18:59:370008デフォルトの名無しさん
2007/05/31(木) 17:45:050009デフォルトの名無しさん
2007/05/31(木) 17:53:50すれ違い。そういうのはこっちで。
UnicodeとUTF-8の違いは？
http://pc11.2ch.net/test/read.cgi/tech/1177930957/
0010デフォルトの名無しさん
2007/05/31(木) 19:42:070011デフォルトの名無しさん
2007/05/31(木) 20:39:410012デフォルトの名無しさん
2007/05/31(木) 20:40:040013デフォルトの名無しさん
2007/06/01(金) 01:02:24他にVSで表す包摂扱いの字体差が大きい異体字には
何でよく見るのにJIS X 0213にも拡張Bにも無いんだろうと思ってた「撥」の拡張新字体なんかもあった。
「痙」の拡張新字体もあるがこれは中国簡体字のU+75C9に包摂するべきでは?「径」は中国の簡体字(旁がスの下にエ)と包摂されてるし。
「門」の手書きでよく使われる略字もあるが、これも「門」よりも中国簡体字のU+95E8のほうが近いからそっちの方が良いと思う。
U+9C75(魚箴)は強烈。いくら何でも違いすぎる。(魚針)
ひょっとしたら後で実は別字だったとか日本では異体字だが中国では別字とかになるかも知れんぞ。
中国ではってレベルじゃねーぞ。
まあU+9FBC～U+9FC2に追加されるはずの7文字もなぜか全部Unicode Submissionに
含まれてたりするからこれから精査して落とすんだろうけど。
0014デフォルトの名無しさん
2007/06/01(金) 23:26:300015デフォルトの名無しさん
2007/06/02(土) 20:15:290016デフォルトの名無しさん
2007/06/02(土) 20:31:38一番クリックした国が優勝
ハンガリーではニュース、新聞などによる報道もあり、日本は苦戦を強いられています。
皆さんも、PCひとつで簡単にできますので、ご協力お願いします！
URL貼れないので、VIPにある本スレ(クリックでスレタイ検索)に来ていただけるとありがたいです
理系の方などでクリックツール作成支援者も募集中です！
0017デフォルトの名無しさん
2007/06/03(日) 13:17:37VSが足りなくなったら増えるんじゃね?
0018デフォルトの名無しさん
2007/06/03(日) 14:00:370019デフォルトの名無しさん
2007/06/03(日) 21:16:17でも一つの文字に256以上異体字があるなんて考えられんな。まあ、漢字で止める払うはねるとか点の向きとか厳しく区別すればすぐパンクするだろうが。
U+E0020～U+E007Eにあるタグ専用の文字も非ASCIIに対応するのが追加されるかも知れん。
ttp://www.jagat.or.jp/story_memo_view.asp?StoryID=563
ここ見るとルビタグも提案されてたらしい。どうなったかは知らんが。
ひょっとしたらフォント指定とかサイズ指定の為のコードも追加されるかも?
0020デフォルトの名無しさん
2007/06/03(日) 22:34:370021デフォルトの名無しさん
2007/06/04(月) 01:40:27渡辺の辺の難しい奴はAJ16ですでに17個あるし文字鏡やGTには60個以上登録されてる
から日本語の人名異体字を含む大規模文字セットがIVDを使おうとか考え始めたら
案外簡単に突破するかも。
千寿とか万寿を符号化するにはVSが1万個必要だし。こんなジョーク文書もあった。
Proposal: Use full plane-13 for the Han variation selector
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n2429.doc
ルビタグはBMPにとっくに入ってる。
0022デフォルトの名無しさん
2007/06/04(月) 15:14:08ならそれらも将来的にはVSで規定されるかも?
0023デフォルトの名無しさん
2007/06/05(火) 05:04:35ただし統合漢字のコードポイントで表すこと(つまり金文体フォントのようなものを実装すること)
は妨げない
0024デフォルトの名無しさん
2007/06/06(水) 00:47:010025デフォルトの名無しさん
2007/06/07(木) 01:59:05各国からこれは人名用だ、という反論が多数来てとうとうこんな文書が出てきた
http://www.cse.cuhk.edu.hk/~irg/irg/irg28/IRGN1327SeparateArea.doc
0026デフォルトの名無しさん
2007/06/08(金) 22:21:49UTF-8Nを渡しても、正常に動いているように見えます。
本稼働用に、動作確認したいのですが
そこで、ASCIIしか考慮してない場合に渡すとまずい
UTF-8Nの文字はありませんか？
0027デフォルトの名無しさん
2007/06/08(金) 22:26:37「ソースコード」や「表示」などのSJISではASCIIにすると文字化けになる文字です
0028デフォルトの名無しさん
2007/06/08(金) 22:37:55文字列を分割したり途中を切り出してたりしてるプログラムなら、おかしくなり得る。
0029デフォルトの名無しさん
2007/06/08(金) 22:47:540030デフォルトの名無しさん
2007/06/08(金) 23:19:50なるほど、切り出したり特殊な加工をしないかぎりは大丈夫ですか
>>29
いや、たまたま知っていた文字コードを入力してみただけですので・・・
0031デフォルトの名無しさん
2007/06/09(土) 00:04:26ASCII じゃなくて Latin-1 で大丈夫なプログラムなら、
大抵は問題になる事はないと思われ。
7 ビット ASCII しか考慮してない場合は、
char が符号付きで、その値を unsigned char にキャストすることなしに
int にする処理が書いてあった場合、
8 ビット目のある文字を渡すと負の値になって、
それでおかしくなる可能性はある。
Latin-1 対応なら、このあたりちゃんと処理してるかと。
UTF-8(N) は多バイトの場合全部 8 ビット目が立ってるから、
Shift-JIS みたいに 2 バイト目が \ になるかも・・・とかそういう事は起こらない。
ただ、もちろんこの文字を途中でぶった切るようなことをしたら、変になる可能性はある。
普通の検索は確か問題なかったと思う。
でも、正規表現には、 . が一文字じゃなくて一バイトという扱いになってしまうとか、影響がある。
0032デフォルトの名無しさん
2007/06/09(土) 02:18:40バイトストリームとして扱うか、文字として扱うかによって違う。
0033デフォルトの名無しさん
2007/06/09(土) 02:58:15ISO-2022-JPのメッセージを80桁の端末に表示してるとき途中に折り返しが入ると
表示がおかしくなる可能性があるからだったな
そういう心配のない欧米ではquoted-printableを使ってた
0034デフォルトの名無しさん
2007/06/09(土) 07:20:16大型機がやっているMTAに勝手に折り返すのが昔あったらしい。
0035デフォルトの名無しさん
2007/06/09(土) 22:53:13RFC1468でquoted-printableに言及してる。それは使わず75桁で折り返せと。
(今読み返したら76じゃなかった)
0036デフォルトの名無しさん
2007/06/10(日) 18:39:07詳細な解説、参考になりました。
Latin-1対応？というのが気になりますが、8bitを意識していないかどうか、
プログラム次第ということですね。
正規表現が問題あるのは痛いですね。（というか、そりゃそうだわな・・・）
0037デフォルトの名無しさん
2007/06/10(日) 20:06:25"い" が 3 バイトだから。
/あ...う/ なら引っかかる。
全角文字は大体 3 バイトだから、実用上は困らないかもしれない。
ギリシャ文字やキリル文字みたいに 2 バイトのものもあるけど。
/あ.*う/ は /あいう/ にひっかかるけど、/あえいう/ にも引っかかる。
ただ、/あ.う/ として、. が多バイト文字の 1 バイト目に引っかかることはないはず。
多バイト文字の 2 バイト目以降は、1 バイト目と必ず違うようになってるから。
0038デフォルトの名無しさん
2007/06/10(日) 20:16:02「75カラム（桁）で」というのはMUAにおける表示の問題だけだと思っていいのかな?
ISO-2022-JPだと制御文字が入るからバイト数的には75を超えてしまうわけだが、
それによって影響を受けるMUA/MTAがあったりするんだろうか?
そもそもカラム（文字列幅?）って概念は明確に定義されてる?
0039デフォルトの名無しさん
2007/06/10(日) 21:48:4580桁の端末での表示上の問題だから表示されないものはカウントしない
当然プロポーショナルフォントなんて高級なものは想定してない
0040デフォルトの名無しさん
2007/06/13(水) 03:27:09お騒がせしてしまいました。
プログラムは、Squirrelっていう組み込みのスクリプト言語です。
ちなみに、このプログラムは、非UNICODEの場合でも、UTF-16 BOM付きUTF-8BOM付きの読み込みをサポートしているのですが、
UTF-16だと、読み込み時に wchar_t を charに変換するので、
読み込みで、エラーが出なくても
実質日本語が使えないという、困ったチャンでした。
（困ったチャンというか、その実装なら当り前ですけど）
>>37
なるほど、正規表現だとそういうことになるんですね。
0041デフォルトの名無しさん
2007/06/13(水) 08:19:59RFC1468って1992年でしょ。
quoted-printableって用語がMIMEだからこれも90年代入ってからだし。
そんな最近の話じゃないよ。
行折り返しが問題になるのは、端末の問題じゃなくて、
ISO-2022-JP(元々JUNETコード)が行末でASCIIに戻すと規定されていたから。
ところが例えば大型で動いているMTAの中には、(BITNETとか)
80カラム以上あると、行を分割したり、切り捨てたりするヤツがいたから、
ISO-2022-JPを考慮しなければ、ISO-2022-JPでなくなってしまう。
0042デフォルトの名無しさん
2007/06/13(水) 21:46:04ということは、もしその手のMTAのことを今でも考慮するとしたら80「桁」以内じゃなくて
「バイト」以内で折り返さないとまずいということになるんですかね?
特にISO-2022-JPだとエスケープシーケンスが入るから前者と後者は明らかに
違うわけですが。
個人的にとあるMUAに関わっているんですが、非日本人の開発者／ユーザも
もいるので（てゆうか彼らがメインだったりしてw) この手の処理をどうするか
悩ましかったりします。
0043デフォルトの名無しさん
2007/06/15(金) 05:39:20行末でASCIIに戻るのは原因と結果が逆のような。
そういう動作をする端末だかMTAだかが存在したからそう規定されたんでしょ
0044デフォルトの名無しさん
2007/06/15(金) 08:31:300045デフォルトの名無しさん
2007/06/16(土) 20:51:50(RFC1468には付いてないけど)読まない奴はいるしな
0046デフォルトの名無しさん
2007/06/17(日) 07:39:20今はMIMEに従えばいいじゃん。
MUAが行を折り返すのは、余計なお世話だな。
0047デフォルトの名無しさん
2007/06/18(月) 18:23:23>今はMIMEに従えばいいじゃん。
えっと具体的にはMIMEの何に従うということですか?
>MUAが行を折り返すのは、余計なお世話だな。
自分も個人的には改行は手で入れたい派なんですが、
ユーザーからの要望で自動改行機能を付けていたりします。
0048デフォルトの名無しさん
2007/06/18(月) 18:33:39(これ迄のバージョンではBMP外の文字は送り幅が変だったりもっと昔のバージョンでは保存したとき消失したりしてた。)
0049デフォルトの名無しさん
2007/06/18(月) 19:07:29しい。
こんな滅茶苦茶な改行には、ほとほとうんざりしてい
る。
0050デフォルトの名無しさん
2007/06/18(月) 19:10:28。こんな改行された日に
ゃ……誰かの台詞じゃ
ないけれど、「泣ける
」。
0051デフォルトの名無しさん
2007/06/19(火) 00:26:43あれ、この処理じゃ駄目ですか?
>>50
要は禁則処理が必須ってことですか。
国際化されたMUAでそれをちゃんとやろうとすると自明じゃないですね。
文字コードスレの範疇を超えてるかもw
0052デフォルトの名無しさん
2007/06/19(火) 18:11:090053デフォルトの名無しさん
2007/06/19(火) 22:30:59「VistaはShift_JIS-2004に対応」って記事を見かけるんですが、
これは「JIS X 0213:2004」の字体がUnicodeから使えるという意味であって、
Shift_JIS-2004の文字コードでの編集や保存に対応してるということではないですよね？
業務用のテキスト処理のソフトをつくるのに確認したいのですが、実機がなくて。
0054デフォルトの名無しさん
2007/06/19(火) 22:32:330055デフォルトの名無しさん
2007/06/19(火) 22:54:350056デフォルトの名無しさん
2007/06/19(火) 23:00:550057デフォルトの名無しさん
2007/06/20(水) 00:06:16> 「VistaはShift_JIS-2004に対応」
その記事書いた奴が何か勘違いしてるか
その記事を読んだおまえが何か勘違いしてる
0058デフォルトの名無しさん
2007/06/20(水) 00:16:39みつけられなかったのでここで失礼します。
だれかがsvnにcommitしたファイルが、英文字が全部
esc ( J "hoge" esc ( B
みたいにiso-2022みたいなエスケープでかこまれてしまい、
diffが取れなくなって困ってるのですが(他にもemacsで
C-sで検索が利かなくなったりとか)、
1. これは何というコードでしょうか？
2. どうやったら元に戻せますか？
(ascii文字セットで表現できる範囲はasciiに)
3. いったい何をどうやったらこんなふうになるんでしょうか？
諸賢のアドバイスをお願いします。また、もっと良いスレがあったら
誘導お願いします。
0059デフォルトの名無しさん
2007/06/20(水) 00:23:00きっと backslash のかわりに円記号が使いたかったんだろう。
0060デフォルトの名無しさん
2007/06/20(水) 00:25:500061デフォルトの名無しさん
2007/06/20(水) 00:52:12結局一旦日本語部分はEUCにして、残ったescape sequenceを
scriptでがっさり削って解決しました。
0062デフォルトの名無しさん
2007/06/20(水) 21:51:46HTMLエディタには ESC ( J を使うものが多いらしい
しかしURLの中の 0x7E は tilde のつもりだし
JavaScriptのエスケープも backslash のつもりらしい
0063デフォルトの名無しさん
2007/06/22(金) 09:26:11ので質問させてください。
C++上でUTF8をbasic_stringのように扱えるクラスかテンプレートで
フリーで使える奴ご存知の方いらっしゃいませんか？
コンストラクタでUTF8の文字列をchar配列みたいな感じで受け取って、
[index]や*単項演算子でデコードした文字コード出てくる感じのがある
とベストなんですが・・・。
0064デフォルトの名無しさん
2007/06/22(金) 09:39:380065デフォルトの名無しさん
2007/06/22(金) 17:28:50あるプログラムに
0xB4 0xC1 0xBB 0xFA
のEUC-JP文字列("漢字")を渡すと、
0xC2 0xB4 0xC3 0x81 0xC2 0xBB 0xC3 0xBA
のようになってしまいます。
自分で見たてでは 0xC2が横につく,または,0x40を引いて0xC3を横につける
という感じみたいなのですが、
何故こうなるのでしょうか。またその他の規則があるのでしょうか。
0066デフォルトの名無しさん
2007/06/22(金) 18:22:490067デフォルトの名無しさん
2007/06/22(金) 19:15:090068デフォルトの名無しさん
2007/06/22(金) 22:18:070069デフォルトの名無しさん
2007/06/23(土) 06:55:12Latin-1 から UTF-8 への変換がかかってるだけ。
0070デフォルトの名無しさん
2007/06/23(土) 08:08:040071デフォルトの名無しさん
2007/06/23(土) 08:10:19007265
2007/06/23(土) 08:57:50> Latin-1 から UTF-8 への変換がかかってるだけ。
おお、ありがとうございます。
>>70
iconvでたしかめたところ再現しました。
libiconvを使ってやるといけそうです。ありがとうございました。
0073デフォルトの名無しさん
2007/06/24(日) 21:48:41ttp://www5a.biglobe.ne.jp/~tmurakam/Flash/Unicode.html
超古いネタですまん。
0074デフォルトの名無しさん
2007/06/25(月) 20:38:370075デフォルトの名無しさん
2007/06/25(月) 20:47:26アルゴリズムとライセンスは別の話だろ？ いったいおまいさんはなにを訊きたいんだ？
0076デフォルトの名無しさん
2007/06/25(月) 21:25:04アルゴリズムにライセンスがある場合はある。
アルゴリズムにはコピーライトがない。
プログラムにはコピーライトがある。
>>74が何を聞きたいか分からない。
007774
2007/06/26(火) 01:03:32sakuraエディッタのソースを参考に文字コード判別モジュールを作ったんですが
これを含んだプログラムを素知らぬ顔で配布しちゃったらなんかやばい事になりますか？ または
作者さんに配布の是非を問えば「No」とか「金払え」みたいな回答が高い確率で返ってくるでしょうか？
0078デフォルトの名無しさん
2007/06/26(火) 01:33:59sakuraエディッタとやらのライセンスを読めよ、馬鹿。 以上、終了。
はい、次の患者さんどうぞ。
0079デフォルトの名無しさん
2007/06/26(火) 01:37:53http://sakura_editor.at.infoseek.co.jp/faq.html
0080デフォルトの名無しさん
2007/06/26(火) 01:39:190081デフォルトの名無しさん
2007/06/26(火) 02:09:250082デフォルトの名無しさん
2007/06/26(火) 06:56:15nkfのコードならコピーライト表示するだけでコピー自由。
0083デフォルトの名無しさん
2007/06/28(木) 09:37:25ワロッシュw
0084デフォルトの名無しさん
2007/07/01(日) 12:25:27対応する型は wchar でよかったでしょうか？
0085デフォルトの名無しさん
2007/07/01(日) 12:28:01あえてsinged charでも悪くないｗ。
0086デフォルトの名無しさん
2007/07/01(日) 12:32:29よくなかったでしょうか？
0087デフォルトの名無しさん
2007/07/01(日) 12:41:14char: charが符号ありの場合はunsigned charにキャストが必要なケースあり
unsigned char: C++の場合は大量にreinterpret_castが必要になることを覚悟汁
wchar_t: よかったでしょうか？
008884
2007/07/01(日) 12:55:56wchar_t でしたありがとうございます
TCHAR型を知っていると幸せになれますよ
MS専用かもわかりませんが・・・
まだコードを書く前の 分からないことの整理中でして
じっくりやりこんでいきます。
0089デフォルトの名無しさん
2007/07/01(日) 13:10:30（wchar_tがUTF-16な実装が存在するくらいだ）けど、
普通wchar_tと言ったらUCS-2、-4やUTF-16、-32とかだろう。
0090デフォルトの名無しさん
2007/07/01(日) 14:26:47wchar_t は有り得ない。
0091デフォルトの名無しさん
2007/07/01(日) 14:30:35string.hの関数とかに渡す時に
いちいちreinterpret_cast<char*>すんの超うざくね？
0092デフォルトの名無しさん
2007/07/01(日) 19:56:530093デフォルトの名無しさん
2007/07/01(日) 22:25:140094デフォルトの名無しさん
2007/07/01(日) 22:32:330095デフォルトの名無しさん
2007/07/01(日) 22:45:240096デフォルトの名無しさん
2007/07/02(月) 01:06:05データとしてUCS-2になって欲しいのか、UTF-8のままでいいのか。
0097デフォルトの名無しさん
2007/07/21(土) 17:05:030098デフォルトの名無しさん
2007/07/22(日) 13:06:000099デフォルトの名無しさん
2007/07/23(月) 01:21:00例えば 1-4-87 の「か゜」にマウスカーソルを合わせると
Unicode: U+FD61809A
UTF-16: 0x304B 0x309A
Shift JIS: -
JIS213: 1-04-87
と出てくるんですが，この「U+FD61809A」ってどういう意味なんでしょう？
Unicode も ISO/IEC 10646 も今のところ U+10FFFF までしかありませんよね？
0100デフォルトの名無しさん
2007/07/23(月) 10:54:460101デフォルトの名無しさん
2007/07/23(月) 13:13:34U+304B, U+309A はサロゲートペアじゃないんだけど、
この2つをサロゲートペアに見立てて、
サロゲートペアからコードポイントを引き出す計算を
無理やり適用したら U+FD61809A になるんじゃね？
いまやったけど
((0x304B - 0xD800) << 10) + (0x309A - 0xDC00) + 0x10000
が 0xFD61809A になる。
0102デフォルトの名無しさん
2007/07/23(月) 13:56:310103デフォルトの名無しさん
2007/07/23(月) 20:24:48なるほど，
0x10000 + (0x304B − 0xD800) × 0x400 + (0x309A − 0xDC00)
= −0x29E7F66
= 0xFD61809A − 0x100000000
という計算の結果，こうなるわけですか。
安易な計算による似たようなバグとして，
「IME パッド - 文字一覧」の Windows-31J 一覧（「シフト JIS」 一覧）で
0x81FF にマウスカーソルを合わせると
面区点コードが「1-02-97」と出てきてしまうのもありますね。
0104デフォルトの名無しさん
2007/07/24(火) 09:02:410105デフォルトの名無しさん
2007/07/27(金) 03:11:310106デフォルトの名無しさん
2007/07/27(金) 08:09:300107デフォルトの名無しさん
2007/07/27(金) 08:40:090108デフォルトの名無しさん
2007/07/28(土) 05:55:10http://www.itscj.ipsj.or.jp/domestic/sc02/irg-files/CJK_D_attributes/IRG1277_attachment.zip
50MBほどあるので注意
0109デフォルトの名無しさん
2007/07/28(土) 06:07:05http://www.cse.cuhk.edu.hk/~irg/irg/irg27/IRGN1250_Japan_Withdrawal_from_D.pdf
0110デフォルトの名無しさん
2007/07/28(土) 07:51:460111デフォルトの名無しさん
2007/07/28(土) 09:55:460112デフォルトの名無しさん
2007/08/17(金) 19:13:21●（日本語２バイトでの、黒い丸）
を、アメ公の環境、US-asciiとかで表示するために
実体参照、もしくは数字文字参照で
表したいのですが、実体参照はまず存在しないようで、
数値文字参照でも、ユニコードの文字番号が不明です。
文字番号がもしあるならそれのWEBページのURLを、
あるいはそれ以外の方法があるなら、それを教えてください。
0113デフォルトの名無しさん
2007/08/17(金) 19:19:48は自己解決した
●だった
ページはhttp://code.cside.com/3rdpage/jp/utf-8/Geometric_Shapes.html
0114デフォルトの名無しさん
2007/08/17(金) 19:33:2310進と16進と二つのやり方があるんだ？
0115デフォルトの名無しさん
2007/08/17(金) 19:55:100116デフォルトの名無しさん
2007/08/22(水) 22:03:34常用されてるみたいです。で、元データはEUC/全角(?)カナのため
EUC=>Shift_JISに変換しつつ、ついでに全角カナ=>半角カナに変換してくれるような
素敵なツールはありませんか？
使うのはkshスクリプトのCGIで、今はnkfだけ通しています。jcode使うとできそう
なのですが、変換のためだけにperlを動かすのも何だかなぁと…。
0117デフォルトの名無しさん
2007/08/22(水) 23:38:460118デフォルトの名無しさん
2007/08/22(水) 23:39:160119デフォルトの名無しさん
2007/08/23(木) 01:07:520120デフォルトの名無しさん
2007/08/28(火) 21:42:23nkf に全角=>半角パッチでも送りつけたら？
0121デフォルトの名無しさん
2007/08/28(火) 22:01:560122デフォルトの名無しさん
2007/08/28(火) 22:47:590123デフォルトの名無しさん
2007/08/28(火) 22:55:510124デフォルトの名無しさん
2007/08/28(火) 23:02:030125デフォルトの名無しさん
2007/08/29(水) 00:08:22何段もの丸投げの下層か？
0126デフォルトの名無しさん
2007/08/29(水) 00:37:330127デフォルトの名無しさん
2007/08/29(水) 00:55:13俺は幸せだ
0128デフォルトの名無しさん
2007/08/29(水) 01:10:070129116
2007/08/30(木) 00:59:43シェルスクリプト内の埋込みやサーバ内で扱うデータにShift_JISや半角カナ使いたくないという
単なる個人的趣味のため、最後に変換する形にしました。ちなみにこれは業務じゃないです。
まぁそういう要望もあるってことで。
0130デフォルトの名無しさん
2007/08/30(木) 05:35:00http://www.unicode.org/ivd/pri/pri108/index.html
前回ツッコミ損ねた人はガンガンコメントしよう
0131デフォルトの名無しさん
2007/09/01(土) 04:50:420132デフォルトの名無しさん
2007/09/06(木) 23:28:55やっぱ包摂扱いにしないことにして拡張Dに提案か?
0133デフォルトの名無しさん
2007/09/07(金) 22:51:53拡張CやDもそのくらいになるかも?
0134デフォルトの名無しさん
2007/09/08(土) 04:51:26UROの最後に付け足しでね?
0135デフォルトの名無しさん
2007/09/08(土) 21:24:320136デフォルトの名無しさん
2007/09/09(日) 00:34:33中台韓越が必要だと思ってるなら申請するはずです
0137デフォルトの名無しさん
2007/09/09(日) 11:00:12俺的には各国の規格の現在および過去の例示字体、康煕字典体、表外漢字字体表、3部首許容などはVS-1～16にして、
その他の異体字(俗字など)はVS-17～にした方がいいと思うのだが。
0138デフォルトの名無しさん
2007/09/09(日) 15:55:56まだUnicodeで規定されてないものが沢山あった筈。
丸付き文字など複数のコードの組み合わせで表せるものもあるけど。
0139デフォルトの名無しさん
2007/09/09(日) 18:39:15前スレだったかの説によればBMPのVS奪い合いを未然に防ぐためだそうだが
真偽の程は知らん
あるいはそういう使い方が将来できるように空けてるのかも
>>138
数字が2桁以上のとき合成が曖昧にならないか?
JIS X 0213の丸付き数字が収録を認められたのは合成では不可能だからという
理由があったはず
0140デフォルトの名無しさん
2007/09/09(日) 23:55:27問題は○51とかだな。全部単体のコードとして追加するのもいいが、2字以上に一緒に合成用記号を付ける方法も定義しておいた方がいいかも。
あとAdobe-Japan1の文字を見てると合成用黒丸や黒四角も必要だな。縦書き用のグリフを選択するタグも。
MacJapaneseをUnicodeにエンコーディングされる際に使用されるPUAのタグと同じ機能のものをPUAでない符号位置に正式なUnicodeとして追加するべきかも。
0141デフォルトの名無しさん
2007/09/10(月) 00:04:14有限である文字を割り振るだけなのに何年かかってんだよボンクラども
小出しにチマチマ変更するんじゃねえよ！アホか！
0142デフォルトの名無しさん
2007/09/10(月) 01:39:53いる、と聞いたんだが、マジ? いまでもそれってアリなの?
0143デフォルトの名無しさん
2007/09/10(月) 02:56:48人名は知らないけど、元素なんかでは新しい字を作ってるとか聞いたことがある。
0144デフォルトの名無しさん
2007/09/10(月) 06:10:17金属元素には金偏とかそんな感じだっけ?
0145デフォルトの名無しさん
2007/09/10(月) 15:08:030146デフォルトの名無しさん
2007/09/10(月) 15:57:39x0Ahやx0Dhなどの改行コードと重なるケースって
ありますか？
0147デフォルトの名無しさん
2007/09/10(月) 17:28:05さすがに、制御コードと重なるようなエンコーディングは聞いたことないですね。
UTF-16を1オクテット単位で見ると出てくるけど。
0148デフォルトの名無しさん
2007/09/10(月) 17:46:09ありがとうございます。
マルチバイト文字列をbyte単位でバッファリングして
操作しようと思ってるんですが、
対象エンコーディングがSJIS,EUC,UTF-8なので、
それなら問題無さそうですね。
0149デフォルトの名無しさん
2007/09/10(月) 21:36:53中国はマジらしい。台湾もかな?
だが、近い将来制限する方針みたい。
>>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には繁体字のみが定義され簡体字は未だ定義されてない。
何でだ?まさか統合してるってこたぁねぇよな?
0150デフォルトの名無しさん
2007/09/10(月) 23:51:25金偏の名前は名古屋人と大工は多いとか聞いた気がする。
0151デフォルトの名無しさん
2007/09/11(火) 00:11:39統合するのかと思ったけどAdobe Japan1の割り当て見直したことから考えると
簡体字と繁体字の統合はなさそうだからやっぱり登録申請するんじゃね
0152デフォルトの名無しさん
2007/09/11(火) 23:47:24http://std.dkuug.dk/jtc1/sc2/wg2/docs/N3297.pdf
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3287.pdf
0153デフォルトの名無しさん
2007/09/12(水) 21:51:43どの辞書を指してるのかなど詳しい規則については知らんが。
だが、画数最大で有名な龍×4（U+2A6A5）はOKらしくこの字2つの名前の人がいるらしい。
下の名だけで128画になる。名前書く時大変そうだな。
0154デフォルトの名無しさん
2007/09/12(水) 22:04:04龍龍
↑こいつですな。9ptぐらいで印刷したらつぶれて読めないだろうな。
0155デフォルトの名無しさん
2007/09/12(水) 23:54:59Windows Vista だが、表示されるとは思わなかった…。
0156デフォルトの名無しさん
2007/09/13(木) 02:49:34日本も既存の名字は「辞書に載ってる漢字ならOK」で辞書は明示してなかったような
http://internet.watch.impress.co.jp/www/column/ogata/special3.htm
>>155
VistaはExtension Bまですべて入ってる
(ただしCJK Compatibility Ideographs Supplementは全部そろってない)
0157デフォルトの名無しさん
2007/09/14(金) 23:59:10例えば「日玉」は一般的に「曜」の略字だけど、似ている「旺」の異体字として使われる事もあるかも知れんし。
同じ字形の字が「曜」でも「旺」でもない全く別の字として実は存在する(した)って事になるかも知れんし。
0158デフォルトの名無しさん
2007/09/15(土) 01:13:54せっかくこんな努力をしてるのがぶちこわしになるし
http://kanji-database.sourceforge.net/housetsu.html
0159デフォルトの名無しさん
2007/09/15(土) 01:16:27明記されてるから実にまっとうな方向の改訂案
0160デフォルトの名無しさん
2007/09/16(日) 22:21:49そっちの方がいいわな。
0161デフォルトの名無しさん
2007/09/16(日) 23:05:18別にここ見てたわけじゃなくてAnnex Sから常識的に判断すれば
必然的にそうなるってことだろうな
0162デフォルトの名無しさん
2007/09/18(火) 22:48:480163デフォルトの名無しさん
2007/09/20(木) 02:07:49まだ正式には提案されていない
0164デフォルトの名無しさん
2007/09/22(土) 00:29:000165デフォルトの名無しさん
2007/09/23(日) 01:35:53JIS X 0213の1-2-54と1-2-55との対応について更に混乱しそうだな。
0166デフォルトの名無しさん
2007/10/03(水) 07:25:50KPS 9566をソースに提案されたことがあるけど
蹴られたから新たな展開がない限りは収録されないと思われ
0167デフォルトの名無しさん
2007/10/05(金) 21:20:58ハングル音節ブロックの余ってるU+D7A4～U+D7AFに追加でもいいかもしんない。このままだとそこ永久に埋まりそうにないし。
0168デフォルトの名無しさん
2007/10/06(土) 04:03:43ブロックの割り当ては16文字単位だからHangul Jamo Extended Bでも使ってないのか
0169デフォルトの名無しさん
2007/10/06(土) 05:37:354バイト以上はまず来ないと思っていいですか？
0170デフォルトの名無しさん
2007/10/06(土) 05:38:390171デフォルトの名無しさん
2007/10/06(土) 05:53:536バイトのものを送ってくるかも
0172デフォルトの名無しさん
2007/10/06(土) 05:53:570173デフォルトの名無しさん
2007/10/06(土) 06:39:330174デフォルトの名無しさん
2007/10/06(土) 10:18:536バイト
0175デフォルトの名無しさん
2007/10/06(土) 11:20:14>>171以外ならそんな入力の場合に6バイトになるのかkwsk
0176デフォルトの名無しさん
2007/10/06(土) 11:20:34○どんな入力
0177デフォルトの名無しさん
2007/10/06(土) 11:23:480178デフォルトの名無しさん
2007/10/06(土) 15:19:260179デフォルトの名無しさん
2007/10/06(土) 17:15:03やっている。
なんで、東アジア、漢字を統一できなかったのか、残念。
0180デフォルトの名無しさん
2007/10/06(土) 17:25:360181デフォルトの名無しさん
2007/10/06(土) 17:27:11ドイツ人は制定マニアだから。
そういうことが難しいからこそ、漢字圏なんじゃないのか?
0182デフォルトの名無しさん
2007/10/06(土) 17:56:29漢字圏は中文圏じゃないし
日本語とかの別言語でも漢字を使っているからね
0183デフォルトの名無しさん
2007/10/06(土) 18:20:180184デフォルトの名無しさん
2007/10/06(土) 18:35:310185デフォルトの名無しさん
2007/10/06(土) 19:35:22ありゃりゃ。みんなどうしてんの？
0186デフォルトの名無しさん
2007/10/06(土) 20:07:40毛沢東もやった死ね
0187デフォルトの名無しさん
2007/10/06(土) 21:51:160188デフォルトの名無しさん
2007/10/06(土) 23:34:150189デフォルトの名無しさん
2007/10/06(土) 23:57:530190デフォルトの名無しさん
2007/10/07(日) 02:48:55日本から逆輸入というのを定期的に繰り返しているし。
文字の統一なんて掛け声以前の問題じゃなかろうか。
0191デフォルトの名無しさん
2007/10/07(日) 03:38:26Unicodeはそういう方針だな。GB7589とGB7590は繁体字で入ってるし
並び順も康煕字典の部首画数順だし
0192デフォルトの名無しさん
2007/10/07(日) 05:22:31台湾の方が電子化進んでたよね
0193デフォルトの名無しさん
2007/10/07(日) 08:48:37文字なんて「萌え」が残ってればおｋなんじゃね？
と秋葉帰りの外人から思われてるに違いない。
0194デフォルトの名無しさん
2007/10/07(日) 13:30:02並び順の、康煕字典の部首画数順はもしかして漢字文化圏のグローバルスタンダード?
>>193 向こうの濃いオタ連中は20年ぐらい前から現代日本風アイテムとして漢字を
認識してるから、それはない。
0195デフォルトの名無しさん
2007/10/07(日) 13:37:21Shift-jisしか受け付けないサーバーだと完成間際で判明して
１から変換しなおし。何とか事なきを得たんだが、次回に
どうしてもクライアントがやりたがってる事をAjaxでやろうと
すると、どうしてもUTF-8を採用せざる負えない結果に…orz
javascriptでShift-jisからUTF-8に変換して表示させる事はできないでしょうか？
向こうのサーバー事情でPHPやらPerlは一切使わせて貰えない状況です。
何とかお助けくださいませ。。。。。。。。。。。。
0196デフォルトの名無しさん
2007/10/07(日) 14:15:380197デフォルトの名無しさん
2007/10/07(日) 14:40:15CJKのどこからも文句の出ない並び順が康煕字典順しかなかったってことだろう
現代中国はにくづきとふなづきを統合したりしたまったく異なる部首を使ってるし
発音順は国によって全く異なるし
0198デフォルトの名無しさん
2007/10/14(日) 20:13:05UCS2も対応させたいのですが、何処か参考になるサイトは無いでしょうか
すみません、どなたか教えて下さいm(_ _)m
0199デフォルトの名無しさん
2007/10/14(日) 20:21:10http://www.google.co.jp/search?q=universalchardet
0200デフォルトの名無しさん
2007/11/03(土) 16:03:56http://news21.2ch.net/test/read.cgi/news4plus/1194067861/
0201デフォルトの名無しさん
2007/11/03(土) 19:20:210202デフォルトの名無しさん
2007/11/03(土) 19:22:450203デフォルトの名無しさん
2007/11/12(月) 17:13:15ウソだったらしい。もうなにがなんだか。
【日台中韓】 「中・日・韓・台の漢字統一」報道を否定！簡体字使用の変更は不可能[11/12]
http://news21.2ch.net/test/read.cgi/news4plus/1194847769/
0204デフォルトの名無しさん
2007/11/12(月) 18:23:490205デフォルトの名無しさん
2007/11/17(土) 15:44:45in:jisX0213:2004 1面, 1区, 1点
out:ucs, utf-8, Shift_JIS
見たいな、、、
0206デフォルトの名無しさん
2007/11/18(日) 00:29:360207デフォルトの名無しさん
2007/11/20(火) 23:35:37機械的に求めることはできますか？
0208デフォルトの名無しさん
2007/11/21(水) 11:39:36...というのは機械的だろうか？
0209デフォルトの名無しさん
2007/11/21(水) 13:03:01同じなのだが。形だけ揃えても意味ないし、朝鮮半島はハングルで統一されている。CKJで統一
する意味はないと思うのだがね。
0210デフォルトの名無しさん
2007/11/21(水) 19:13:460211デフォルトの名無しさん
2007/11/21(水) 21:09:46Encode使えば割りとw何でもできるから。
好きなのにしな。
まあ今ならutf-8がいいだろうけど。
formにUnicodeな文字入力する奴もいるし。
0212デフォルトの名無しさん
2007/11/24(土) 02:48:07gcc3.4よか前だと単に1Byteを4Byteに展開するだけで何の文字コードでもなく、
3.4以上だとUTF-32LEになってるかのような動き。
さらにvc(UTF-16LE)とのクロスでの開発を考えると頭が痛くなるなあ・・
Win/Linuxのクロスでやってる人って内部コードってなににしてる？
0213デフォルトの名無しさん
2007/11/24(土) 02:52:40ワイド文字をリテラルでは使わない。
UTF-8から変換。
0214デフォルトの名無しさん
2007/11/24(土) 03:07:353.4以降はexec-charsetでどうとでもできそうだけど、古いのは・・
ソースをUTF-8にすればなんとか日本語入れてもコンパイルはできるか。
あぁ、でもvc7とかはUTF-8のソース確か受け付けなかったような。
ソースくらいは変換するべきか。面倒だな・・いろいろ。
0215デフォルトの名無しさん
2007/11/24(土) 04:02:120216デフォルトの名無しさん
2007/11/24(土) 04:22:36でもそれすらgccいけるけどvcは\u使えないとか罠があったり。。
いろいろ実験して、バッドノウハウだけ増えたな・・
vc,gccともソースがUTF-16系は不可、vcはシグニチャなしUTF-8ソース不可、
逆にgccはシグニチャありUTF-8ソース不可・・
0217デフォルトの名無しさん
2007/11/24(土) 04:45:06みたいだ。最低だな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でいい気がしてきた。
0218デフォルトの名無しさん
2007/11/24(土) 15:53:480219デフォルトの名無しさん
2007/11/24(土) 17:14:21#define XX "あ"
とかあるとだめだけど
#define XX "ああ"
だと平気。たぶんsjisとして処理してるから日本語リテラルが奇数バイト
だとだめみたいな感じ。
0220デフォルトの名無しさん
2007/11/24(土) 23:51:330221デフォルトの名無しさん
2007/11/25(日) 10:34:2620h～7Fh 各国共通（1バイト文字）
80h～FFh 各国自由（1／2バイト文字）
16ビットPCを出すときに思い切って半角カナを廃止して
80h以降は日本では2バイト文字専用にすれば良かった
つーか70年代末期の最初のPCを出すときに80h以降は
予約領域かPCG領域にすれば良かったんだよな
0222デフォルトの名無しさん
2007/11/25(日) 10:36:33カタカナだけでもいいから1バイトで処理したいという要求がどれだけ当時は切実だったことか
0223デフォルトの名無しさん
2007/11/28(水) 12:10:331987年ごろのパソ通でも、漢字を使うと表示できないマシンが
あるから、カナ以外禁止というところもあったね。
0224デフォルトの名無しさん
2007/11/28(水) 14:01:290225デフォルトの名無しさん
2007/11/28(水) 18:40:35初代は第1水準もオプション
0226デフォルトの名無しさん
2007/11/28(水) 18:44:17オプションの漢字ROMボードを入れるとその隙間を埋めるRAMもついてきたってわけ。
0227デフォルトの名無しさん
2007/11/29(木) 21:02:51まあ若い人は文字コードになんか興味ないか
0228デフォルトの名無しさん
2007/11/29(木) 21:29:000229デフォルトの名無しさん
2007/11/29(木) 22:02:330230デフォルトの名無しさん
2007/11/29(木) 22:22:000232デフォルトの名無しさん
2007/11/30(金) 07:21:18テキストVRAMって文字サイズとか位置とか固定になっちゃうじゃんｗｗｗ
超バカスｗｗｗ
なんでグラフィックVRAMに全部書かないのｗｗｗ
とか言い出す奴がいそうだな。
8ビットマシンはグラフィックVRAMに漢字表示できるものもあったわけだが
0233デフォルトの名無しさん
2007/11/30(金) 08:53:49219はどうなった？
0234デフォルトの名無しさん
2007/11/30(金) 19:30:45#pragma setlocale("C") を入れときゃいいだけでは？
0235デフォルトの名無しさん
2007/12/01(土) 09:01:430236デフォルトの名無しさん
2007/12/01(土) 16:08:270237デフォルトの名無しさん
2007/12/02(日) 07:14:19サロゲートペア，異体字，半角カナ．．．問題ありすぎ
世界中の文字使えるったってほとんど意味無いしょ
第３水準で変な記号いっぱい追加されたけどそれも要らん
JISが大手PC・携帯メーカーに呼びかけて
MS，アップル，ドコモ，au，ソフトバンク，NEC，富士通，IBM
2バイト文字の最終統一規格を作るしかないんじゃないの？
8080H～FFFFHの16384字あれば十分
0238デフォルトの名無しさん
2007/12/02(日) 10:41:18逆だ。JISは大手に踊らされている御用団体だからね。
つーか、それができるのならJIS83辺りで統一できているはず。
# 実態は……言うまでもないよな。
＞8080H～FFFFHの16384字あれば十分
計算できる?
0239デフォルトの名無しさん
2007/12/02(日) 11:18:030240デフォルトの名無しさん
2007/12/02(日) 11:25:30もうおなかいっぱい。
これ以上文字コードを増やさないでくれ。
0241デフォルトの名無しさん
2007/12/02(日) 11:45:050242デフォルトの名無しさん
2007/12/02(日) 18:39:01>>237
2バイト固定長はもう無理でしょう。というか固定長は結合文字の
存在もあるしコーディング上のメリットがないんだよなあ。
結合文字を考慮した文字検索アルゴリズムとかもうどうしていいんだか・・
0243デフォルトの名無しさん
2007/12/02(日) 19:06:210244デフォルトの名無しさん
2007/12/02(日) 20:31:22TRONコードは、単に、すでにある文字集合をぶち込む枠組であって、
文字集合の整備は漢字の収集とかやったけど、処理の上位層について
TRON方面は概念を発表しただけで具体的なものは何も出てきて
いないし、現在の問題を何ら解決できるものではない。現状から見て、
たいした期待はできない。
0245デフォルトの名無しさん
2007/12/03(月) 01:24:14やるしかないんじゃないの。当面は。
0246デフォルトの名無しさん
2007/12/03(月) 22:10:170247デフォルトの名無しさん
2007/12/03(月) 22:22:07http://www.unicode.org/reports/tr10/
http://www.unicode.org/reports/tr15/
0248デフォルトの名無しさん
2007/12/03(月) 23:03:38別の文字「Y」がこれらをシャッフルした文字コード（ AB EF CD など）で
定義されている、という組み合わせを探しています。
効率的な調べ方とかあるかしら？
0249デフォルトの名無しさん
2007/12/03(月) 23:14:280250デフォルトの名無しさん
2007/12/04(火) 01:18:41char a[] = { 0xE3, 0x82, 0xA2, 0x00 };
char b[] = { 0xE3, 0xA2, 0x82, 0x00 };
ってしたときに、aは「ア」だけどbに割り当てられた文字はないでしょう？
そういうのをプログラム的に省きたかったんだ。無理っぽいなあ
0251デフォルトの名無しさん
2007/12/04(火) 01:25:35んなこと悩んでいる間にベタで書けば5分掛からないだろ。わけわからん。
それともなんかのプログラムの動作中ってこと？
0252デフォルトの名無しさん
2007/12/04(火) 07:34:33これって割り当てられてるってこと？
ttp://www.google.co.jp/search?hl=ja&q=%E3%82%A2
ア の検索結果 約 73,600,000 件中 1 - 10 件目 (0.05 秒)
ttp://www.google.co.jp/search?hl=ja&q=%E3%A2%82
㢂 の検索結果 約 2,740 件中 1 - 10 件目 (0.24 秒)
0253デフォルトの名無しさん
2007/12/04(火) 09:56:170254デフォルトの名無しさん
2007/12/04(火) 09:56:490255デフォルトの名無しさん
2007/12/04(火) 10:56:35Windows なら Vista にするか対応フォントを入れれば見えるはず。
0256デフォルトの名無しさん
2007/12/04(火) 11:36:45端から生成して、端からx6の組み合わせで生成して、
端からUTF-8になってないバイト列を落とすフィルタを通す、
という感じで書くかな。
0257デフォルトの名無しさん
2007/12/04(火) 12:05:37AB CD EF は16進数の10～15ではなくて、6種類の変数A～Fという意味。
文字列処理関数のテストケースを書いてて、248 みたいな組み合わせが数通り欲しかったのさ。
文字コード一覧表を目視して解決しますた。あんがと。
>>255
ExtAってなんかの制御コード？
>>256
日本語フォントが用意されているかを調べる、というコードが書けない俺orz
0258デフォルトの名無しさん
2007/12/04(火) 12:28:23「文字集合」で考えろ。
0259デフォルトの名無しさん
2007/12/04(火) 12:48:05「UnicodeからJIS X 0208(あるいはCP932)にマップ可能なコードポイント」を抽出したいのか？
それはテーブル引くしかないような気がする。
0260デフォルトの名無しさん
2007/12/04(火) 12:53:57U+3400～U+4DB5(Unicode3,4), U+4DBF(Unicode5)
いわゆる「機種依存文字」な漢字でUnicode2に入ってなかった奴が入った所と思った。確か
0261デフォルトの名無しさん
2007/12/04(火) 13:03:01JIS X 0208の全ての区点コードをリストアップ ('あ'を例に)
↓
UTF-8の16進数表現に変換 (0xE3 0x81 0x82)
↓
バイト列をソートしたのものを一桁目に(CSV) (0x81 0x82 0xE3, 0xe3 0x81 0x82)
↓
一桁目でjoin (0x81 0x82 0xE3でjoin)
↓
join後、複数項目のあるものをリストアップ。
0262デフォルトの名無しさん
2007/12/04(火) 17:55:57>>258、>>260-261
もthx!
0263デフォルトの名無しさん
2007/12/04(火) 23:52:17ｽﾏﾝ、結局Linuxどうしてんのかレスなかったから見てなかった・・
Stringを自前で作って、各文字コード処理できるようにする方向でやってる
0264デフォルトの名無しさん
2007/12/06(木) 01:28:410265デフォルトの名無しさん
2007/12/06(木) 19:00:37第1バイトがA0～FFなら2バイト文字だと認識するようにすれば
いいと思うんだけど
0266デフォルトの名無しさん
2007/12/06(木) 20:32:41U+4DBFに文字なんか割り当てられてたか?
ブロックの範囲と文字が収録されている範囲をごっちゃにしてる
通信用語の基礎知識あたりの鵜呑みじゃあるまいな
0267デフォルトの名無しさん
2007/12/06(木) 20:33:43円記号問題どころの騒ぎじゃなくなります
メインフレーム各社の独自コードにはそういう変態割り当てをしたものが
けっこうあるけど
0268デフォルトの名無しさん
2007/12/06(木) 20:52:49スマン
あたり
orz
3.0 と現行のを調べた。
レンジは 3.0 だと U+4DFF まで、5.0 だと U+4DBF まで、
中身が入ってるのは U+4DB5 まで、で合ってます？
間に入ったのは Yijing Hexagram Symbols って八卦かよw
0269デフォルトの名無しさん
2007/12/06(木) 22:09:16うむ
ちなみにU+9FA5の後ろには本当に文字が断続的に追加されてるな
0270デフォルトの名無しさん
2007/12/06(木) 22:25:43aj16.tar.Zが更新されてる
pri108に対応していくつかのCIDにUnicodeが追加された模様
0271デフォルトの名無しさん
2007/12/07(金) 08:24:11補助漢字で6067字
補助漢字と第３，第４でかぶるのが約2900字
11233＋6067－2900＝14400字
8080H～FFFFH＝16384字
0272デフォルトの名無しさん
2007/12/07(金) 08:42:20それはSHift-JIS固有の問題。
0273デフォルトの名無しさん
2007/12/07(金) 09:30:200274272
2007/12/07(金) 09:42:22言いたいのは1～2バイトに収まるようにシンプルにしてほしいってこった
0275デフォルトの名無しさん
2007/12/07(金) 10:57:540276デフォルトの名無しさん
2007/12/07(金) 12:51:450277デフォルトの名無しさん
2007/12/07(金) 13:41:140278デフォルトの名無しさん
2007/12/07(金) 13:47:08のみでまかなえるなら好きにすればー?
# 文字コードが、文字集合を情報「交換」のために符号化したものである
# ということを理解してないやつがこんなにも多いのは何故だ?
0279デフォルトの名無しさん
2007/12/07(金) 13:48:260280デフォルトの名無しさん
2007/12/07(金) 13:59:54通訳が「Chinese Characters」って訳しやがって説明に苦労したもんだぜ。
0281デフォルトの名無しさん
2007/12/07(金) 15:02:010282デフォルトの名無しさん
2007/12/07(金) 16:58:25Unicode に入れられそうもない変体仮名とかを
符号化する場合を考えると Unicode だけに
頼れないし
0283デフォルトの名無しさん
2007/12/07(金) 18:32:19ところで変体仮名のみの文字集合は既に定義されているのですか?
あるとすれば、どういう包接基準を採用しているのですか?
0284デフォルトの名無しさん
2007/12/07(金) 20:36:470285デフォルトの名無しさん
2007/12/07(金) 21:04:53>>265みたいなことをしたらShift_JISと同じ(もっと悪い)問題が起きるって
言ってるんだが。
>>282
入らないのは日本が入れろと言わないから。
異体字だって結局米国企業のAdobeが登録するまで日本は
なーーーんにもしなかった。
0286デフォルトの名無しさん
2007/12/07(金) 21:05:18とりあえずTRONにはあるようだ
http://ja.wikipedia.org/wiki/%E4%BD%8F%E6%B0%91%E5%9F%BA%E6%9C%AC%E5%8F%B0%E5%B8%B3%E5%8F%8E%E9%8C%B2%E5%A4%89%E4%BD%93%E4%BB%AE%E5%90%8D
0287デフォルトの名無しさん
2007/12/07(金) 21:06:31TRONコードに住民基本台帳収録変体仮名とその他の変体仮名が入ってる。
ということは住基統一コードにも変体仮名が入ってるのか
0288デフォルトの名無しさん
2007/12/07(金) 21:12:47日本側の窓口はどこなんだろ。経産省？
密室でやらずに一回ぐらいパブリックコメントの募集してくれよ。
0289デフォルトの名無しさん
2007/12/07(金) 21:14:56http://std.dkuug.dk/jtc1/sc2/wg2/
IVDの前回の公開レビューだって
http://www.unicode.org/ivd/pri/pri98/index.html
終了一週間くらい前になって気づいた俺が触れて回るまで
日本で取り上げているサイトが一切なかったという関心のなさっぷり
それで密室とかなんとかいっても説得力のかけらもない
0290デフォルトの名無しさん
2007/12/07(金) 21:37:490291デフォルトの名無しさん
2007/12/07(金) 22:11:20投稿手順すら分からないのではないかと。
0292デフォルトの名無しさん
2007/12/07(金) 22:17:00wikipediaにあるわw
http://ja.wikipedia.org/wiki/%E4%BD%8F%E6%B0%91%E5%9F%BA%E6%9C%AC%E5%8F%B0%E5%B8%B3%E5%8F%8E%E9%8C%B2%E5%A4%89%E4%BD%93%E4%BB%AE%E5%90%8D
http://www.chokanji.com/features/ckv4.html
TRONは何でもぶちこみ方式だろうから、
まだ異体字の包接基準はないのかな。
かなり知識がないと無理だね。
0293デフォルトの名無しさん
2007/12/09(日) 10:03:04その運用に事実上必要な異体字のデータベースで金稼いでるんだよね
超漢字検索で変体仮名を検索すると関連字として対応する漢字やひらがなが
出てくるし漢字から変体仮名を検索することもできる
0294デフォルトの名無しさん
2007/12/09(日) 12:07:54英語力と金が必要だけど
0295デフォルトの名無しさん
2008/01/02(水) 16:32:43結局JIS X 0221の改訂版は2007年中に出ませんでした。
JIS X 0213:2004で2004となるべきところが2003となるような誤植が
今回も発生するのでしょうか。
0296デフォルトの名無しさん
2008/01/05(土) 01:13:42えっまぢ！？
そういや、12月20日前後の官報がデッドラインだと聞いてたんだけど、
チェックするの忘れてたよ。。。
あーあ、また関係者は地獄を見ることになるのかな・・・
0297デフォルトの名無しさん
2008/01/05(土) 01:33:090298デフォルトの名無しさん
2008/01/05(土) 01:43:49ietf-charsetsで外人が「Hey, 内容変更が何もないのにどうして-2003が-2004
になったんだい? (大意)」みたいなことを安岡センセイに聞いてたのを思い出した。
そりゃ知らないやつは不思議に思うよなあ
0299デフォルトの名無しさん
2008/01/05(土) 06:06:50制定年月日2007/12/20になってるから本当にギリギリだったみたいね
0300デフォルトの名無しさん
2008/01/05(土) 07:17:14CJKU_SR.txtをわざわざ50MBのPDFにしてたりしてワロタ
0301デフォルトの名無しさん
2008/01/12(土) 07:17:23中の人が内規かなにかに従った結果なんだろうね
0302デフォルトの名無しさん
2008/01/12(土) 12:12:01フォント環境の違いで誤解が生じないように。
0303デフォルトの名無しさん
2008/01/12(土) 12:27:420304デフォルトの名無しさん
2008/01/12(土) 12:28:15そもそも正文がテキストファイルなんだが
0305デフォルトの名無しさん
2008/01/16(水) 19:29:38ttp://www.ac.cyberhome.ne.jp/~mattn/cgi-bin/blosxom.cgi/etc/20071221111511.htm
> 1文字毎をメモリに持つのではなく全てバイト列で処理すると言った方法の為、
> 他のアプリケーションとは違うi18n化の方法であり特殊ではあるが
普通のi18n対応アプリケーションは文字ごとに(codepointごとに?)
メモリに確保して、文字配列として処理されることが多い、けれども
バイト列で処理する…バイト列を喰わせても大丈夫な関数を用意して文字を操作する
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20071130/288467/
*Javaとかのアプローチはcodepointごとに文字を操作。(分解合成がめんどい)
*Vimのアプローチはバイト列を独自関数で文字として操作。(patch workの集大成)
oniguruma とか sakura editor とか emcode.pm とか身近にあるのは
みんなpatch workの集大成なのですか？
0306デフォルトの名無しさん
2008/01/16(水) 19:40:01ん、じぶんの理解だとここの部分の意図が汲めなくなるか…
内部で Unicode の codepoint に従って処理しているソフトは
あまりないけど…内部でなんらかのエンコードに変換して保持
してるソフトは多くて…でもVimはバイナリのまま保持するですよ…?
というような意味とか? ああなんかよくわからなくなってきた…orz
0307デフォルトの名無しさん
2008/01/16(水) 21:53:51何が言いたいのだろう。
0308デフォルトの名無しさん
2008/01/17(木) 13:22:34全ての文字、言語に通じている人間なんていないのだから。
0309デフォルトの名無しさん
2008/01/17(木) 14:09:39というか言語というものがそもそも...
0310デフォルトの名無しさん
2008/01/18(金) 14:46:18http://anond.hatelabo.jp/20070902073806
>喫煙と、麻薬や飲酒は直交する問題だと思いますが…
直行する = 相関性のみられない事象のこと = 分けて論じるべき議題
うむ。まずじぶんは小学生あたりからやり直すべきか。
てか日本語って難しいな orz
>>308-309
㌧くす。言語は日々の積み重ね。ちぃおぼえた
0311デフォルトの名無しさん
2008/01/18(金) 15:00:13>「おそらく漢字ほど難しくないからそれほどでもないと思うけど、例えば
>"than" を "then" と書く若者が増えてるよ。」っと言っていました。
>「それって全く意味が違うじゃん。」っと言ったら、「orthogonalだね。」と
>言われました。「orthogonalって何？」と聞いたら、90℃（直角）との事。
>「何で180℃じゃないの？」っと聞いたら、「反対の意味って訳じゃないけど
>（左右みたいな）、ぜんぜん違う意味だから、orthogonalって言うんだよ。」
>っと教えてくれました。面白い表現ですね！
『欧米かっ！』と言わざるを得ない…。
グラフをイメージして相関性云々とか考え出すと,
なんで90度でねじれの関係になるんだ, とかわけかわからんかった orz
0312デフォルトの名無しさん
2008/01/18(金) 15:52:55> >>307
> http://anond.hatelabo.jp/20070902073806
> >喫煙と、麻薬や飲酒は直交する問題だと思いますが…
> 直行する = 相関性のみられない事象のこと = 分けて論じるべき議題
誤変換かもしれないが、直交と直行を混同するようでは先がおもいやられる...
0313デフォルトの名無しさん
2008/01/18(金) 16:25:400314デフォルトの名無しさん
2008/01/18(金) 17:07:36文脈から汲めば、分けられないってことだろ
とはいえ>>312みたいな態度が一番気に食わん
0315デフォルトの名無しさん
2008/01/18(金) 17:59:53高校数学程度の概念は常識として知っておいてくださいな。
0316デフォルトの名無しさん
2008/01/19(土) 03:20:48それくらい想像力働かせてくださいな。
0317デフォルトの名無しさん
2008/01/19(土) 07:02:46∴2つのベクトルの内積(2直線の射影でもいいや)=0
0318デフォルトの名無しさん
2008/01/19(土) 07:08:44それらは直交しない
つまり「直交」については最初から一貫して「本来の意味」で使われているw
馬鹿は >>315
0319デフォルトの名無しさん
2008/01/19(土) 12:20:410320デフォルトの名無しさん
2008/01/19(土) 14:12:35直帰を許可します
0321デフォルトの名無しさん
2008/01/21(月) 00:06:370322デフォルトの名無しさん
2008/01/30(水) 01:45:55どうも変換がうまくできない・・・
0323デフォルトの名無しさん
2008/01/30(水) 07:47:520324デフォルトの名無しさん
2008/01/30(水) 23:27:43※無料で閲覧できる奴じゃなくて購入したPDFでも手で書き取らされます
とりあえず機械可読な奴がほしかったらここでも見れ
http://x0213.org/codetable/
0325デフォルトの名無しさん
2008/01/30(水) 23:32:34ごめんJISCを甘く見てた……
0326デフォルトの名無しさん
2008/01/30(水) 23:40:520327デフォルトの名無しさん
2008/02/01(金) 21:15:440328デフォルトの名無しさん
2008/02/05(火) 21:26:41Servlet Garden ≫ Unicode and Character Sets (Translation)
http://www.t3.rim.or.jp/~yoko-k-h/java/servlet/2008/01/31/unicode-and-character-sets-translation.html
0329デフォルトの名無しさん
2008/02/05(火) 23:42:35それぞれをどう解釈したらいいんだろう？
0330デフォルトの名無しさん
2008/02/05(火) 23:56:230331デフォルトの名無しさん
2008/02/06(水) 00:00:19ISO/IECがつけた名前
中身おんなじ
0332デフォルトの名無しさん
2008/02/06(水) 00:11:42UCSのが6バイトみたいなこと書かれてたんで5バイト目以降は違うってことかな？
0333デフォルトの名無しさん
2008/02/06(水) 00:32:16UTF-8にしたときには5オクテット以上にはならない。
Uniocde.org的には、単に追加予定なしなだけなので、UTF-8は理屈上最長の
6オクテットまで使っていいけど、でも文字入ってないよ？状態。
だから、結局中身おんなじ
0334デフォルトの名無しさん
2008/02/06(水) 01:09:46おれにAmd2:2006で追従したんじゃないっけ。
どちらにしろ、今はどちらも4byteまで。
http://www.rfc-editor.org/rfc/rfc3629.txt 参考までにRFC
0335デフォルトの名無しさん
2008/02/06(水) 02:42:040336デフォルトの名無しさん
2008/02/06(水) 18:15:44http://www.unicode.org/ivd/index.html
0338デフォルトの名無しさん
2008/02/19(火) 23:13:060339デフォルトの名無しさん
2008/02/22(金) 20:04:35「符号化文字でないことが保証された数値を必要とする内部処理」に使用するためだそうだ。
例として「表を終了させる、テキストの終わりを通知するなど」が挙げられてる
0340デフォルトの名無しさん
2008/02/23(土) 03:05:400341デフォルトの名無しさん
2008/02/23(土) 08:30:49符合化方式がその辺りを考慮するのは当然。
0342デフォルトの名無しさん
2008/02/23(土) 09:17:36U+FFFEは言うまでもなくBOM判別用
0343デフォルトの名無しさん
2008/02/23(土) 13:25:240344デフォルトの名無しさん
2008/03/12(水) 02:47:39番号からUTF-16を使っていたのですが、
このスレの人は何を主に使っているのですか？
検索をしていると16よりも8の話題のほうが見つかるので、
実は8のほうがいいのかなと悩んだりしています。
0345デフォルトの名無しさん
2008/03/12(水) 03:08:25よくよく考えたらUTF-8は可変で日本語の文章に関しては、
全てを2バイトで扱うUTF-16に比べて、
日本語部分を3バイトで扱うUTF-8は情報量が多いほど、
容量が無駄に大きくなってしまいませんか?
1.5倍ですよね。それを補うほどの使い勝手の良さがあるのでしょうか。
0346デフォルトの名無しさん
2008/03/12(水) 03:14:340347デフォルトの名無しさん
2008/03/12(水) 03:27:30まぁ日本語を基準に考えてる時点でUnicodeの思想から外れてる気はする
0348デフォルトの名無しさん
2008/03/12(水) 09:29:531.5倍程度でけちけちするな、多言語化ってのはそういうもんだ。
マジレスするとUTF-8側にメリットがあるというよりも、
UTF-16側がサロゲートペアやバイトオーダー、ASCII非互換、guessしずらいなど、
いろいろと面倒なのでUTF-8の方がよい。
0349デフォルトの名無しさん
2008/03/12(水) 10:57:520350デフォルトの名無しさん
2008/03/12(水) 23:33:43ホントにASCIIてクソだなあ。
0351デフォルトの名無しさん
2008/03/13(木) 02:21:38ISO 8859-1みたいなんじゃなくて、ASCIIが8bit、
×も≠も欲しいなんて言い出さなくて本当に良かった。
奴等が重ね打ち馬鹿で本当に良かった。
0352デフォルトの名無しさん
2008/03/13(木) 19:16:38EUC-JP 系のエンコーディング（含 eucJP-ms, CP5132）においてどういう文字が
割り当てられているかを知りたいのですが、いいウェブページはないでしょうか。
0353デフォルトの名無しさん
2008/03/13(木) 20:07:350354デフォルトの名無しさん
2008/03/13(木) 20:25:250355デフォルトの名無しさん
2008/03/13(木) 21:04:03WinならAPIとの互換性のために、メモリ上はutf16が良い。Shift_JISに変更する気はあんまり起きない。
パーサーなどで、コードポイントを等間隔で扱いたいときにはutf32にしてる。
0356デフォルトの名無しさん
2008/03/13(木) 21:27:56やはりそこら辺ぐらいですか?
まずは1バイト部分が気になっていたのですが、
>また、16進数で「21」～「7E」の文字にASCIIとJIS X 0201ローマ文字のいずれを使うかは、
>歴史的にはASCIIの方が正しいのですが、実際には使う人の自由にまかされます。
ということは例えば0x5cはreverse solidusでもyen signでも好きな方使え、ということ
なのかな? とほほー。
0357デフォルトの名無しさん
2008/03/13(木) 21:41:13ローマ数字とか、文字化ける、現象の、ことです
0358デフォルトの名無しさん
2008/03/13(木) 22:03:500359デフォルトの名無しさん
2008/03/13(木) 22:22:370360デフォルトの名無しさん
2008/03/13(木) 22:28:35numa氏が転載してくれてる
http://blog.livedoor.jp/numa2666/archives/50980727.html
0361デフォルトの名無しさん
2008/03/13(木) 22:40:03表示できない文字のことを言っている。>>357
0362デフォルトの名無しさん
2008/03/13(木) 22:41:16お国はどちらで？
0363デフォルトの名無しさん
2008/03/13(木) 23:17:280364デフォルトの名無しさん
2008/03/14(金) 09:14:19http://legacy-encoding.sourceforge.jp/wiki/
多分こっちの方がいい。
なお、IANA Charset では EUC-JP は ASCII だし、eucJP-ms, eucJP-ascii CP51932 も ASCII だぞ。
eucJP-0201 が JIS X 0201 Roman。
0365352
2008/03/14(金) 09:55:43ありがとうございます。
>なお、IANA Charset では EUC-JP は ASCII だし、eucJP-ms, eucJP-ascii CP51932 も ASCII だぞ。
>eucJP-0201 が JIS X 0201 Roman。
なるほど。JIS X 0201 Roman はマイナーですね。
なお、今ググったら ICU のサイトもヒットしたので、そっちも参照してみます。
iconv や Perl-Encode なんかはこの辺どうなってるのかな。
しかし EUC-JP 系ってナニゲにタチが悪いですね。下手すると SJIS 系より悪いのではw
0366デフォルトの名無しさん
2008/03/14(金) 11:08:59独自改変があるのは、どのコードでも同じだし。
その辺まで全部気にしたいのなら、Windows上でベンダー共同の文字拡張、
firefoxのEUC拡張とか、いろいろありすぎてやってられないと思う。
0367デフォルトの名無しさん
2008/03/14(金) 11:59:42iconv は glibc iconv と libiconv と 森山さんのパッチ済み libiconv と Citrus iconv でも違って、
「EUC-JP」での \x00-\x7F までは ASCII と考えていい、これは IANA で定義されてるから。
ただ、それより多バイトは実装による。
Perl/Encode は Shift_JIS も EUC-JP も \x00-\x7F は ASCII だね。
なお、Shift_JIS は IANA 定義では \x00-\x7F が JISX 0201Roman なことに注意。
これにしたがっている実装はあまりないが、たまにあるので地雷。
ていうか、Shift_JIS でなく Windows-31J/CP932 を使えばトラブルは少ないのでこちらの方が回避は楽。
0368352
2008/03/14(金) 13:43:47どうも有益な情報をありがとうございます。
文字コード処理にどのぐらい挙動の幅を持たせるかとかを悩んでいます。
>>365さんも書かれてますが、例えばHTMLでcharset=Shift_JIS or EUC-JPとなっている
が、拡張漢字のコードが入ってた場合（これは結構ある）にどうするかとか。
あと、差のある部分（全角記号等）をどっちだと思って処理するかとか。
0369デフォルトの名無しさん
2008/03/14(金) 14:01:57User-Agent: をみて、独自の拡張、改変にちゃんと対応するしかない。
firefoxのケースはググれば出てくる。
CP51932関連も読んでおいた方がいい。
0370デフォルトの名無しさん
2008/03/15(土) 06:16:20Shift_JISだって、CP932、Shift_JISX0213、Shift_JIS-2004などの変種がある。
むかし補助漢字を無理やり埋め込む変種もあった。
> Windows上でベンダー共同の文字拡張、
eucJP-ms?
0371デフォルトの名無しさん
2008/03/15(土) 09:41:00kwsk
そういう噂は聞いたことあるけど実際にどんな仕様だったのか調べてもわからない
0372デフォルトの名無しさん
2008/03/15(土) 10:19:31> Shift_JISX0213、Shift_JIS-2004などの変種がある。
これって名前以外に違いあるんだっけ？
0373デフォルトの名無しさん
2008/03/15(土) 10:41:07Shift_JIS-2004は、JIS X 0212:2004に基づいている。
UCS互換文字が10文字追加されている。
追加だから、表示などの用途に限れば、
Shift_JIS-2004だけで十分だが、
文字集合チェックしたければ区別する必要がある。
(>>352はそういうことをEUC-JPについて知りたいようだったので書いた)
0374デフォルトの名無しさん
2008/03/15(土) 10:54:07増やせば増やすほど混乱の種が増す。
とくに「レガシー」エンコーディングプロジェクトのくせに新しいことをやりたがる奴らは
まとめて氏ね
0375デフォルトの名無しさん
2008/03/15(土) 10:58:430376デフォルトの名無しさん
2008/03/15(土) 11:00:350377デフォルトの名無しさん
2008/03/15(土) 11:26:08thx
0378デフォルトの名無しさん
2008/03/15(土) 13:22:46当時のfj.kanjiにいくつかの提案をまとめた記事があったはず。
0379デフォルトの名無しさん
2008/03/15(土) 14:11:30当時ニュースグループには参加してなかったからログを探すのが困難だ
0380デフォルトの名無しさん
2008/03/15(土) 16:42:56>そもそもサポートする必要ないよ、とか言ってみる。
世界中のソフトが足並みを揃えられればいいんだけどね。
現実的にはより「好意的に」データを処理してくれるアプリの方が
ユーザーのウケが良くて、困ったものだ。
それに「レガシー」とはいうものの、メールでもウェブページでもまだバリバリに
使われてるわけだし。
0381デフォルトの名無しさん
2008/03/15(土) 16:54:500382デフォルトの名無しさん
2008/03/15(土) 18:46:28さすがにShift_JIS-2004をサポートした方がユーザーの受けがいいってことはないだろ
むしろ円記号や名簿の高橋さんが文字化けする! とか苦情が増えそうな気がする
0383デフォルトの名無しさん
2008/03/15(土) 18:47:21日本中のソフトだけだろ。
最近のソフトやプロトコルは日本人が口出ししない限りUTF-8のみなんて珍しくもないぞ
0384デフォルトの名無しさん
2008/03/15(土) 18:53:04> 使われてるわけだし。
まだ使われているものをサポートすることは別に反対してない。
現在誰も使ってないどころかかつて使われたことすらないものを
「よかれと思って」付け足そうとする奴は氏ねと言ってる。
ISO-2022-JP-MSとか(頓挫したけど)
NEC選定IBM拡張漢字とIBM拡張漢字にVS付けて区別するとか
正気とは思えない
0385デフォルトの名無しさん
2008/03/15(土) 18:53:560386352
2008/03/17(月) 04:46:50Win上だと例えばcharset=EUC-JPだけど実はCP51932なHTMLとかは
あんまり問題にならないのかもしれませんが、非Winだとそうでもなくて、
ちょっと情報を必要としていました。
ウェブブラウザとかメールソフトとかデータベースとか、日本人が開発の
中心にいないものも少なくないんじゃないですかね。そうすると日本語の
エンコーディングに関するバグの説明とか、面倒ですね。
0387デフォルトの名無しさん
2008/03/17(月) 05:01:27受け手が四苦八苦しているのが悪いわけではない。
0388デフォルトの名無しさん
2008/03/17(月) 08:01:19通訳が「漢字」を"chinese characters"と訳すのには閉口させられたなぁ。
現物見せてやっと話が噛み合ったよ。
0389デフォルトの名無しさん
2008/03/17(月) 12:18:12大昔、千年以上前の日本人にとっては、漢字≒中国語文字かもしれないが
現代の日本人が漢字といえば国字 Japanese characters で漢字体のものを
指すのが普通だな。
通訳は空気を読むべきだと思うが、通訳が頼りない場合は
漢字だと誤訳・誤解されるおそれがあるので日本文字 Japanese characters と
言ったほうがいいかも。
0390デフォルトの名無しさん
2008/03/17(月) 12:31:27文字コードの世界では、含めて「漢字」ということがあるからややこしい。
本来の狭い意味での「漢字」なら、
Japanese Charactersの中のChinese Charactersってことで問題ないはずだけど。
0391デフォルトの名無しさん
2008/03/17(月) 12:37:280392デフォルトの名無しさん
2008/03/17(月) 12:38:110393デフォルトの名無しさん
2008/03/17(月) 12:44:23ってな、合ってるんだけど間違ってる理解が今後増えそうで嫌だ
0394デフォルトの名無しさん
2008/03/17(月) 12:48:45それってひらがな、かたかなは含む?
0395388
2008/03/17(月) 12:55:49隙を狙って"Kanji is Japanese special character, not only Chinese."みたいなことを言った希ガス。
当然向こうは"???"となったから、「現物を見せましょう」という流れに持ってった。
# んで、「Windowsじゃそんな文字出せない」みたいなこと言われたんだよなw
0396デフォルトの名無しさん
2008/03/17(月) 13:15:36391でも392でも無いけど、俺の知っている範囲では「含まない」。
たとえば、日本語学習者とか、日本の漫画やアニメのファンが
"HiraganaやKatakanaは何とかなるけど、Kanjiはホントに難しいyo"
とか、そういう風に口にする。
0397デフォルトの名無しさん
2008/03/17(月) 13:52:28文字コードのことをちゃんと勉強してる技術者には、
KanjiっていえばHan charactersのうち日本語で使われてる文字だって伝わる。
Unicode万歳って感じだわ。
0398デフォルトの名無しさん
2008/03/17(月) 15:17:070399デフォルトの名無しさん
2008/03/17(月) 19:06:02「漢字」だと漢字だけだよな。
0400デフォルトの名無しさん
2008/03/17(月) 23:49:15Unicode 1.0では非漢字領域にもあったけどUnicode 1.1でunifyされたらしい
と安岡センセイか誰かの日記で読んだ
0401デフォルトの名無しさん
2008/03/18(火) 00:22:440402デフォルトの名無しさん
2008/03/18(火) 07:53:24"〆" は文字だっけ？ JIS では記号だけど。
0403デフォルトの名無しさん
2008/03/18(火) 08:03:36〆は0208由来の非漢字と補助漢字由来の漢字が両方入ってる
EUC-JPとラウンドトリップコンバージョンを確保する必要があるから
0404デフォルトの名無しさん
2008/03/18(火) 12:50:52アファベットかどうかやひらがなかどうかやカタカナかどうかとか
文字種別みたいなものをロジック的に判別する方法ありますか？
それともSJISとかみたいに力任せですか？
あと濁点の「が」と「かﾞ」みたいなのを正規化する方法って決まってませんか？
0405デフォルトの名無しさん
2008/03/18(火) 13:11:04>文字種
そういうAPIがあるプログラム言語とかライブラリ使え
どれがどの文字種かは >>unicode.org
>正規化
決まってる >>uniocde.org
0406デフォルトの名無しさん
2008/03/18(火) 15:00:42>正規化
結合文字の正規化目的でNFCを使うとCJK互換漢字でハマるから注意
0407デフォルトの名無しさん
2008/03/18(火) 20:19:070408デフォルトの名無しさん
2008/03/18(火) 22:28:390409デフォルトの名無しさん
2008/03/19(水) 00:28:49互換漢字を入力できずに困ったことがあったわ。
0410デフォルトの名無しさん
2008/03/19(水) 07:34:46ファイル名が Unicode ベースなファイルシステムだと何らかの正規化がなされていると
思うけど、同じ場所に「神」という名前のファイルと「神」とのいう名前のファイルを作ろうと
したら、どうなるべきなのかな?
0411デフォルトの名無しさん
2008/03/19(水) 07:43:42手元のWindowsXP/NTFSだと U+00C4 と A+U0308 を別々に作れた、なので正規化はしてないっぽい。
MacOSXだと作れないだろうね。
0412デフォルトの名無しさん
2008/03/19(水) 10:01:39> > 何らかの正規化がなされていると思うけど
Mac OS Xくらいしか知らないよ。
Windows, UNIX系ではないんじゃない？
0413デフォルトの名無しさん
2008/03/19(水) 10:08:51MacOSXでも作れる。
OSXのVFSはNFDに準じたファイル名の正規化を行うが、互換漢字は対象外
0414デフォルトの名無しさん
2008/03/19(水) 14:30:19VFSじゃないだろ?
CarbonとHFS+でやってんじゃない?
すくなくとも10.3の調査ではそうだった。
だからターミナルからUFSやNFS上にファイルを作成すれば、
ファイル名はNFDされてなかった。
0415デフォルトの名無しさん
2008/03/19(水) 17:17:53ほんとに? 正規化されてないUnicodeでファイル名を扱うっていうのは
混乱を招くような気がするのだが...
0416デフォルトの名無しさん
2008/03/19(水) 18:49:29正規化はソートや検索の時に動的にしてくれたほうが嬉しい。
0417デフォルトの名無しさん
2008/03/19(水) 19:02:26ヘテロな環境で正規化の方法が違った場合、
USBサムドライブで困るよね。
0418デフォルトの名無しさん
2008/03/19(水) 20:53:24Technical Q&A QA1173
Text Encoding in VFS
http://developer.apple.com/jp/qa/qa2001/qa1173.html
http://developer.apple.com/qa/qa2001/qa1173.html
0419デフォルトの名無しさん
2008/03/19(水) 21:16:22この文章だと10.2の頃からそうなっているみたいだけどそれは嘘。
Darwinのソースコード＆テストで調べた。
0420デフォルトの名無しさん
2008/03/19(水) 23:00:27むしろ下手な正規化(大文字と小文字の同一視とか)をされるより
個々のアプリでの扱いに任せてもらった方が混乱は少ないよ
0421デフォルトの名無しさん
2008/03/19(水) 23:19:28Mac, Winでそうだから避けられないのかねえ。
カタカナとひらがなはどうなんだとかきりがないねえ。
0422デフォルトの名無しさん
2008/03/20(木) 00:29:04そうじゃなくて、NFCとかNFDとか、上に出てたでしょ。
0423デフォルトの名無しさん
2008/03/20(木) 00:54:10まあ「VFS API」というのが実際に何を意味するかですかね。もしかして UNIX の
ファイルアクセス用の API （システムコール）程度の意味なのかも。
かつ HFS+ のことだけを念頭においているのかも。NFS とかは「例外」扱いだし。
実際 UFS や NFS は正規化はしないですね > Mac OS X
0424デフォルトの名無しさん
2008/03/20(木) 01:41:14MediaWikiでは正規化されたくない文字は文字参照にするしかないね
それでも項目名には使えない
0425デフォルトの名無しさん
2008/03/20(木) 01:43:01つ[Collation]
ただし事前処理として正規化が前提になってるのでもし互換漢字のソート順を
統合漢字と変えたかったりしたら使えない
0426デフォルトの名無しさん
2008/03/20(木) 07:50:55HFS+オンリーで「VFSが」というもの…w
0427デフォルトの名無しさん
2008/03/20(木) 23:07:19アプリ：DreamWeaverMX
DreamWeaverMXでhtmlファイルを新規作成したとき、<META>タグは以下の記述でした。
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
ここではcharsetで文字コードShift_JISを指定していますが、ページをIE6.0以降で見られることを想定した場合に
文字化けをできるだけ減らすためには、charsetの値はどのようにすればいいのでしょうか？
0428デフォルトの名無しさん
2008/03/20(木) 23:26:380429デフォルトの名無しさん
2008/03/20(木) 23:50:020430デフォルトの名無しさん
2008/03/21(金) 12:26:11了解。ありがとう
0431デフォルトの名無しさん
2008/03/23(日) 16:34:58CP51932 相当の IANA 名を定義するような動きはなかったんですかね。
Shift_JIS と Windows-31J の区別はあるんだし。
0432デフォルトの名無しさん
2008/03/24(月) 00:50:390433デフォルトの名無しさん
2008/03/24(月) 08:29:22どれぐらい多いの？
日本語で書かれているウェブページのうち、何%がEUC-JPと宣言されてい
て、そのうち何%が実際はCP51932なの？
0434デフォルトの名無しさん
2008/03/24(月) 09:39:56他のwindows-コードページの番号ってなってるコードページと一貫性がない。
0435デフォルトの名無しさん
2008/03/24(月) 11:06:440xFD～0xEFの文字がある=EUC
って解釈でいい？
0436デフォルトの名無しさん
2008/03/24(月) 14:55:390437デフォルトの名無しさん
2008/03/24(月) 19:59:200438デフォルトの名無しさん
2008/03/24(月) 20:04:290439デフォルトの名無しさん
2008/03/24(月) 20:06:570440デフォルトの名無しさん
2008/03/25(火) 00:08:24Microsoftがietf-charsetsに提案してたようだが例によって途中からｇｄｇｄ
http://mail.apps.ietf.org/ietf/charsets/msg01618.html
こんなだからみんな面倒な登録手続きなんか無視して
好き勝手にcharset使い出してカオスになるんだろうな。
そういやISO-2022-JP-2004の登録手続きはどうなりましたか安岡センセイ
http://www.jstage.jst.go.jp/article/johokanri/50/2/67/_pdf/-char/ja/
こんなもの書いてる暇があったらShift_JIS-2004登録してください
規格通りに使いたくても使えないじゃないですか
0441デフォルトの名無しさん
2008/03/25(火) 00:09:560442デフォルトの名無しさん
2008/03/25(火) 00:16:39http://mail.apps.ietf.org/ietf/charsets/msg01783.html
なんでMartin Duerstセンセイともあろうお方が今さらこんなこと言ってるの?
RFC 1192ご覧になったことあります? つーか
> We also wish to thank the following people who contributed in many
> ways towards this document.
> Zhang Zhoucai Martin J. Duerst
見てないはずがないんだけど。
何でcharset-extensionとcharset-editionはみんなに無視されたのに
今度はうまくいくとか無邪気に思い込めるわけ?
0443デフォルトの名無しさん
2008/03/25(火) 00:17:150444デフォルトの名無しさん
2008/03/25(火) 00:23:06いやそのドキュメントは有意義だと思うよ。
ちゃんとまとめて、読めるようにしとかないと、
独自コード乱発は加速するばかりだから。
0445デフォルトの名無しさん
2008/03/25(火) 01:19:23CP51932 相当の IANA 名をWindows-31Jって言うんじゃね？
テキストエンコーディングが何だろうと、文字集合は同じでしょ。
0446デフォルトの名無しさん
2008/03/25(火) 11:35:01IANA charsetの「charset」は文字集合+符号化方式のセット
0447デフォルトの名無しさん
2008/03/25(火) 11:38:59Martinセンセイにドキュメントがないだとか色々突っ込まれて力尽きてたはず。
使いたいなら後をついで進めるといいのかもしれないけど、
必要なドキュメントをJISが握ってる以上難しい気もしないでもない。
0448デフォルトの名無しさん
2008/03/25(火) 11:56:26日立のEBCDIKコード表探してるんだけど、
http://www.wdic.org/w/WDIC/EBCDIK とか
http://www.pleasuresky.co.jp/ebcdic.php3 とかじゃなくて
日立が提示してるオリジナルがいいんだけど、どっかにないですかね？
0449デフォルトの名無しさん
2008/03/25(火) 12:01:210450デフォルトの名無しさん
2008/03/25(火) 12:04:00なにこの汚いコードは
0451デフォルトの名無しさん
2008/03/25(火) 12:13:23情けねぇ…
0452デフォルトの名無しさん
2008/03/25(火) 18:13:480453デフォルトの名無しさん
2008/03/25(火) 21:14:53ドキュメントの有意義さは否定しないけど
実際にWebページやメールでそのドキュメントの通りに使えというなら
使えるようにしてくれなきゃ話が始まらない
>>447
俺はUnicodeでいいと思ってるからなー
使いたい人ががんばってくださいとしか
がんばらないで勝手に使うという最悪の選択だけはくれぐれもやめてほしい
0454デフォルトの名無しさん
2008/03/25(火) 21:21:11小文字 0xED40 纊
が
大文字 0xFA5C 纊
に変換されるのですが、この辺わかりやすく説明しているサイトないでしょうか～
0455デフォルトの名無しさん
2008/03/25(火) 21:35:00http://support.microsoft.com/kb/170559/ja
0456デフォルトの名無しさん
2008/03/25(火) 21:41:47非常に勉強になったよ。
ありがとう！
0457デフォルトの名無しさん
2008/03/26(水) 02:30:15> 実際にWebページやメールでそのドキュメントの通りに使えというなら
言ってないw
0458デフォルトの名無しさん
2008/03/26(水) 02:37:51> ケータイの絵文字や、CP932のIBM拡張文字など
はインターネットで使うべきでないとは書いてるけど、代わりに何を使えとは確かに
直接書いてはいない。でもそれなら何で今インターネットで使えるJIS X 0208:1997
ベースのShift_JISではなくわざわざShift_JIS-2004に言及してるの?
Shift_JIS-2004の絵文字のうち
> 「♪」以外は収録されていなかった
そうだけどそれらは使っていいの? いいならcharsetパラメータには何を指定すればいいの?
0459デフォルトの名無しさん
2008/03/26(水) 08:47:401. いわゆるレガシーエンコーディングの、ベンダー毎の拡張みたいのは今後積極的
にはサポートされない。
-> 新たに IANA に登録されてたりすることはない?
-> charset にない文字を使っているようなのは化けてもしょうがないって感じ?
2. IBM拡張漢字、絵文字等をどうしても使いたい場合は Unicode で。
-> Windows-31J は IANA に登録されてるからアリ?
0460デフォルトの名無しさん
2008/03/26(水) 09:54:220461デフォルトの名無しさん
2008/03/26(水) 12:14:50http://www.microsoft.com/globaldev/reference/cphome.mspx
0462デフォルトの名無しさん
2008/03/26(水) 13:04:19U+0000からU+10FFFFまで扱えるよ
0463デフォルトの名無しさん
2008/03/26(水) 13:10:39ちゃんと資料があったんですね。ありがとうございます。
0464デフォルトの名無しさん
2008/03/26(水) 13:12:18すいません、ちゃんとフォントがあって表示できる
またはIMEから入力できるものという意味でした。
0465デフォルトの名無しさん
2008/03/26(水) 13:20:32>> ケータイの絵文字や、CP932のIBM拡張文字など
>はインターネットで使うべきでないとは書いてるけど、代わりに何を使えとは確かに
>直接書いてはいない。
IANA charset登録済みのもの。
>でもそれなら何で今インターネットで使えるJIS X 0208:1997
>ベースのShift_JISではなくわざわざShift_JIS-2004に言及してるの?
なんでだろうねぇ。
Windows-31Jとして登録済みの「CP932」の方がマシだと思うんだけど。
>> 「♪」以外は収録されていなかった
>そうだけどそれらは使っていいの? いいならcharsetパラメータには何を指定すればいいの?
使っていい、Unicodeに登録されているんで、UTF-8を指定すればよい。
もちろん、JIS X 0213系のエンコーディングはダメ。
0466デフォルトの名無しさん
2008/03/27(木) 18:55:27他にも>>440の資料は突っ込みどころ大杉。
> JISにもUnicodeにも違反しており
未使用領域を使用禁止にしているJIS X 0208/0213と違ってUnicodeでPUAを
使うこと自体は何も規格に違反してない。いわば文字化けするのはUnicodeの仕様。
> Windows Vistaの方が、ある意味、正しい動作だと言える。
どっちかが正しい動作だと言うこと自体ミスリーディング。
規格を守っていても「字体化け」するのがJISやUnicodeの「仕様」。
もちろん安岡センセイがそんな初歩的なこと知らないはずがないので
確信犯なんだろうけど(とくに後者)。
0467デフォルトの名無しさん
2008/03/27(木) 20:05:380468デフォルトの名無しさん
2008/03/27(木) 20:16:540469デフォルトの名無しさん
2008/03/27(木) 20:22:49そういうのが存在する分野の話になると、そこにばっかフォーカスすることになる。
それだけを固めた例としては、ゲーハー板。
0470デフォルトの名無しさん
2008/03/28(金) 00:04:05だったらネタ振ってくれ。例えばNew ASCII配列とか。
0471デフォルトの名無しさん
2008/03/28(金) 05:47:010472デフォルトの名無しさん
2008/03/29(土) 13:19:210473デフォルトの名無しさん
2008/03/29(土) 15:58:100474デフォルトの名無しさん
2008/03/30(日) 02:19:37Aliasってことは「等価な」エンコーディングって扱いなのかな?
もしそうだとすると日本語のエンコーディングに関しては鬱なような...
0475デフォルトの名無しさん
2008/03/30(日) 04:31:26>>472-473
EBCDIKってのは日立方言だよ。
ネットではEBCDIC(カタカナ版)のことだと説明してることが多いけど、
誰かがそう書いたのをよく調べもせずに孫引きで書いている奴が多いだけ。
0476デフォルトの名無しさん
2008/03/30(日) 11:19:36「Converters with conflicting aliases」とか。
ibm-942-P12A-1999とibm-943-p15A-2003が
両方ともaliasにcp932を持ってる事の説明が付かないけど？
0477デフォルトの名無しさん
2008/04/04(金) 11:08:02Unicode 5.1のリリース予定日がやってまいりました
0478デフォルトの名無しさん
2008/04/05(土) 21:55:19StandardizedVariants.htmlにIVDに関する言及が追加されますた
0479デフォルトの名無しさん
2008/04/06(日) 02:55:20まったくこのスレのネタすら分からないけど、基本的にutf-8かutf-32?使っておけばよい?
16はなんか面倒とか聞いた覚えがあるが今はそこまで調べる気力なし…。
0480デフォルトの名無しさん
2008/04/06(日) 10:49:53基本的に UTF-8 使っておけばよし
UTF-32、というか32ビットでの処理はアプリが内部で使う場合の話で
文字コードとして意識する必要はないよ
0481デフォルトの名無しさん
2008/04/06(日) 10:58:000482デフォルトの名無しさん
2008/04/06(日) 12:53:51提案したのは部外者だけど。
0483デフォルトの名無しさん
2008/04/06(日) 20:02:59utf-8って好き嫌いがはっきりしている気がする。
0484デフォルトの名無しさん
2008/04/06(日) 20:07:05まあ仕方が無いのは分かるが。
0485デフォルトの名無しさん
2008/04/06(日) 21:08:59Unicodeのエンコード方式の一つとしてはそうなのかもしれんが…
一長一短な気もするけど、今後Unicode対応アプリを作る上ではUTF-8はchar*で扱える
面だけ取れば悪くはないのかも
XMLとかもさ
だけど、結局ファイルやストリームから読み取る分にはUTF-8でいいけど、1～4バイトの
可変長ってのがね
処理内部はUTF-16として扱うのが一番楽だね１文字２バイトと単純計算できるし、
今はサロゲートペアのことを意識する必要が無いから
文字列はそもそもリソース定義すべきだから、ソース中に文字列で埋め込まないんであれば
エンコード方式さえはっきりしてればどうでもいいや
それより、SJISでコメント書いたソースをWindowsエミュレータやリビジョン管理(ClearCaseやCVS、SVN)
で使って、実機やテスト機(Linux)ではEUCだとコンパイル時にコメントが改行されてたりするんだよねｗ
うちんとこでは、Lunuxビルドはmakefileの中でnkfで文字コード変換されてるが…
0486デフォルトの名無しさん
2008/04/06(日) 21:19:34いつかサロゲートペア対応に改良する暇はあるの？
初めからUTF-32にすればいいだろ。
0487デフォルトの名無しさん
2008/04/06(日) 21:26:20CJKでしかないから。
0488485
2008/04/06(日) 21:33:50Unicode 4.0を見てみたｗ
どう見ても、当面サロゲートペアを使う必要はなさそうだなあｗ
UTF-32でもいいんだけどさ、やっぱ１文字で４バイトってやだなー
特に理由ないんだけどさ
U+10000～を使うことが明らかなら別だけど、使わないしさ
>>487
CJKというか、CJKVのようだけどね
Unicodeは言語を識別するためのものじゃないし、それは別途ISO 639なり使って
管理するとかじゃないの？
0489デフォルトの名無しさん
2008/04/06(日) 21:37:480490485
2008/04/06(日) 21:43:44時はバブル、んな将来的なことどうでもいいとか思われそうだがｗ
Y2Kなんて、もっと早急に対応してればあんなに世間が騒ぐこともなかったんだし
結局何も起きなかったけどさｗ
0491デフォルトの名無しさん
2008/04/06(日) 21:58:14そうなるとわかっているけど対処しなかったから起こったんだ、
とつい最近どっかで読んだけど、まったくだｗ
0492デフォルトの名無しさん
2008/04/06(日) 22:12:38「過去に戻れても、やはり同じようになるよ」だな。
0493デフォルトの名無しさん
2008/04/06(日) 23:09:49>今はサロゲートペアのことを意識する必要が無いから
さすがにもう時間の問題でしょ。
そろそろ JIS X 0213 が要求に入り始めるだろうし。
0494デフォルトの名無しさん
2008/04/07(月) 01:51:070495485
2008/04/07(月) 08:49:15JIS X0213はさすがに困ったちゃんな規格を作ってくれたもんだなぁと思いつつも、いわゆる第三～第四水準に
ようやく人名漢字として略されてたものとかが扱えるとかどうとかで恩恵を受ける人もいるんだろうか？
サロゲートペアを扱うとなると、１文字=2バイトの原則が壊れるんだよなぁ
そういや、2000年だかから中国のGB2312の拡張規格GB18030は、中国大陸における文字表示可能な機器の
全てが対応する必要があるとか訊いて社内で騒ぎになって、Windows2000ではGB18030フォンとパックやら
変なAPIで4バイト文字対応してたとおもうんだけど、こいつはUnicodeとどう親和性を取るつもりなのかな？
規格上はGB18030はISO/IEC 10646を丸ごと飲み込んじゃう規格なんだけど…
0496デフォルトの名無しさん
2008/04/07(月) 13:42:22>今はサロゲートペアのことを意識する必要が無いから
サロゲートペア以外にも合成文字とかあるんですけど。
0497デフォルトの名無しさん
2008/04/07(月) 19:05:39MacOS-Xの「ヒ+゜」とかね。
いつ「普通の」データとして飛び込んでくるか分かったもんじゃない。
0498デフォルトの名無しさん
2008/04/07(月) 19:12:030500デフォルトの名無しさん
2008/04/07(月) 20:01:44Mac持ってないけど「ピ」は合成されてるの？
JISX0213の「か゜」とかじゃなくて？
0501デフォルトの名無しさん
2008/04/07(月) 20:26:25>>413のNFD
0502デフォルトの名無しさん
2008/04/07(月) 20:46:58もう現実を見るんだ。
固定バイトの文字コードなんて所詮夢だったんだよ。
0503デフォルトの名無しさん
2008/04/07(月) 21:20:350504デフォルトの名無しさん
2008/04/07(月) 21:25:050505デフォルトの名無しさん
2008/04/07(月) 22:26:300506485
2008/04/08(火) 09:22:27そうか、やはりそうなのか…
固定バイトはもはや夢物語なんだなorz
合成文字といえば、ヨーロッパのラテン文字事情なんとかならんのでしょうか？？？
ローカライズにあたって、文字列検索の曖昧検索を行うわけなのだが、Aとキーされようと、
アクセントが付いてようとウムラウトだろうと引っかからないといけないのはまぁいいとして…
A+アクセントとかはやめて欲しいのだがｗ
いったい、ヨーロッパは何言語あるんだYO!
0507デフォルトの名無しさん
2008/04/08(火) 09:43:20ないとムリポ。
（「エ」と「ヱ」を同一視するかどうかなんて日本人でも判断に困るだろ？）
0508485
2008/04/08(火) 11:31:51だよねー
今月号の「NEWTON」を読んだら、ラテン語のアルファベットは当初英語で使われるものとほぼ
同じだったとか？
その後に、フランス語やらでアクセント記号が付けられたとかどうとか…
てっきり、逆だと思ってたんだが、Unicode 1.0策定時にCJKの統合に当たってルーツの異なる文字で
似ている物を同一視しようとした件、ラテン語圏でもやはりアクセント記号はそれくらい意味のある文化
の一つなんだろうか…
幸い、自分は合成文字には今のところ携わることはなさそうだが…
中国国家標準のGB 18030をどうにかしてもらいたい…
GB 2312、ASCII、ISO/IEC 10646をうまいこと包含しているという点ではうまいこと考えたなと関心
出来るんだけど、結局は1～4バイトのマルチバイト文字ってワケで、ISO/IEC 10646を包含したとしても
変なジレンマ作ってるだけだし…
そもそも、CJKのグリフが U+3400～U+4DFE、U+4E00～U+9FFEまでしか割り振られてないじゃんか！
BMP面で足りるじゃんかー！
0509デフォルトの名無しさん
2008/04/08(火) 13:30:47ラテン語ネイティブも、油断してると、
JIS X 0208のFULLWIDTH LATIN (CAPTAL) LETTER *ってのがあるしね。
自前で実装しようとするとHALFWIDTHへの正規化を忘れちゃう。
>>508
表音音文字元祖のフェニキア文字の子孫の
ギリシャ文字でさえ発音記号はないからね。
アクセント記号はcollationの時にも、
取り払ってソートするか付いたままソートするか、
国によって標準的な取り扱いが違って難しい。
0510デフォルトの名無しさん
2008/04/08(火) 20:21:30>>GB18030
Unicodeに変換して処理するだけなんだから別に関係ないでしょ
0511デフォルトの名無しさん
2008/04/08(火) 20:49:230512485
2008/04/08(火) 21:02:50いやいや、GB 18030は現状はUnicodeでグリフのある領域はカバーしてるけど、Unicodeに無い
民族文字やらをどんどん増やす思惑があるらしい…
だったらその思惑をUnicodeコンソーシアムで提起して貰いたいものなんだが…
>>511
俺の文章？orz
どうせローカライズ以前に、各国の文言を用意するのは翻訳チームのすることで、俺は関わってないし
0513デフォルトの名無しさん
2008/04/08(火) 21:05:12他国の心配しなくてもちゃんと国際提案してくるからむしろ日本NBの怠慢ぶりを
何とかしてくれってば
0514デフォルトの名無しさん
2008/04/08(火) 21:21:000515485
2008/04/08(火) 21:46:47これは>>513の現場もそうだろうと思うのだが、日本人のSEに限らずPMに至るまで、
日本における標準化についてまともに考えている奴っている？
C++を理解するのにISO/IEC 14882を読んだり、仕様書を書くときに主語をちゃんと
付けることを意識するとかさ？
今俺が書いてる文章なんかは支離滅裂だけどorz
>>514
JIS X0213の二の舞はやめようよｗ
0516デフォルトの名無しさん
2008/04/08(火) 22:14:13書かないまでも、意識していないと所謂「とんでも」文書ができあがるわけだが。
# 「マウスボタンが押すとウインドウが表示します」とか。
0517デフォルトの名無しさん
2008/04/08(火) 22:40:59UNICODE的に、新規コードポイントの追加は、
まずは国内規格、次にUNICODEって順番じゃなかったっけ？
0518デフォルトの名無しさん
2008/04/08(火) 23:31:000519デフォルトの名無しさん
2008/04/09(水) 00:23:030520デフォルトの名無しさん
2008/04/09(水) 02:59:07なんで俺の職場の話がいきなり出てくるのか意味不明だが
日本における標準化の試みは
学者が机上の空論をあーでもないこーでもないと小田原評定のごとくこねくり回した
挙げ句黒船に全部持って行かれるのが通例。
http://www.itscj.ipsj.or.jp/domestic/mojicode/index.html
の異体字アーキテクチャの検討なんて絵に描いたようだ
0521デフォルトの名無しさん
2008/04/09(水) 08:47:51動画フォーマットとかはそうでもない気がするけど？
0522デフォルトの名無しさん
2008/04/09(水) 09:00:50ISLISP
IPv6, Mobile IP
この辺は日本の団体が組織的に関わってるよ。
0523デフォルトの名無しさん
2008/04/09(水) 09:29:05>>520が多い状況はなかなか改善できないと思う。
本来、案もレビューも書かない奴の意見なんて聞く必要ないんだ。
0524デフォルトの名無しさん
2008/04/09(水) 13:14:54意味のあることを言った奴より怒るんだよね。
0525デフォルトの名無しさん
2008/04/09(水) 23:39:09* Ideographic Variation Databaseという対案が明確に示されてる
* 日本は>>520を国際提案していない
話にもならんね
0526デフォルトの名無しさん
2008/04/11(金) 14:34:46Mac OS XのHFS+は、
さらにアルファベットの大文字小文字の同一視もやってるよな。
ファイル名としては大文字小文字が保存されているけど、
比較ではcase ignoreだからFooがあればfooでopenする。
FULLWIDTHなアルファベットも同じ。
ただしFULLWIDTHとHALFWIDTHな文字は同一視しない。
WIDTH範疇が同じ場合に限り大文字小文字を区別。
0527デフォルトの名無しさん
2008/04/11(金) 15:11:34×区別
○同一視
こうですか?
0528デフォルトの名無しさん
2008/04/11(金) 18:52:47>そのへんはそのうちCollationライブラリが何とかしてくれるから問題ない。
そういえば Unicode で日本語の文字列をソートした場合、普通はどんな並び順に
なるんでしょうか/なるべきなんでしょうか。Collation のライブラリ毎に違うんでしょうか。
unicode.org の TR10 とか見てみましたがよくわかりませんでした。
0529デフォルトの名無しさん
2008/04/11(金) 20:02:25Case SensitiveなHFS+もあるよ。
同一視する文字や使えない文字はファイルシステム毎に異なるから
あるファイル名が使えるかは単純には判断出来ない。
0530デフォルトの名無しさん
2008/04/12(土) 03:00:11既にインストーラでは選べないんじゃない?
昔使ってたが、馬鹿アプリで問題発生したので使わなくなった。
アプリ内のファイルがCapitalizedなのに、
アプリが全部大文字でアクセスしてたw
0531デフォルトの名無しさん
2008/04/17(木) 22:38:32トンパ文字の提案キター
0532デフォルトの名無しさん
2008/04/18(金) 06:22:15ARIB互換漢字についてアメリカとイギリスからIVSを使えよボケと突っ込まれてるｗ
0533デフォルトの名無しさん
2008/04/18(金) 21:35:34与えられている文字はIVSに吸収してくるとスッキリするんだけど。
今までのしがらみで無理かな。
0534デフォルトの名無しさん
2008/04/18(金) 21:48:210535デフォルトの名無しさん
2008/04/18(金) 22:25:210536デフォルトの名無しさん
2008/04/19(土) 00:09:08それ以降に定義された領域では使わないっていうアレか。
0537デフォルトの名無しさん
2008/04/19(土) 03:41:26既存の互換漢字を削除はあり得ないけど、これから追加しようとしたら突っ込まれて当然だろう
0538デフォルトの名無しさん
2008/04/20(日) 11:42:06ttp://www.unicode.org/Public/5.1.0/charts/
予告期限は過ぎてるんだけど
あともう5.2.0のディレクトリあって吹いたｗ
0539デフォルトの名無しさん
2008/04/26(土) 22:57:200540デフォルトの名無しさん
2008/04/26(土) 23:04:50いいじゃねぇの？
0541デフォルトの名無しさん
2008/04/27(日) 11:10:56来てる
0542デフォルトの名無しさん
2008/04/27(日) 20:49:590543デフォルトの名無しさん
2008/04/28(月) 03:56:41http://www.sakamura-lab.org/FONT/
4月中の公開は無理そう
つーか以前は「2006年春」って言っててそれもブッチしてなかったっけ
0544デフォルトの名無しさん
2008/04/28(月) 13:30:01結局ARIB互換漢字の追加は受理されたようだ
0545デフォルトの名無しさん
2008/04/28(月) 14:19:01http://www.arib.or.jp/english/html/overview/doc/2-STD-B24v5_1-1p3.pdf
JIS X 0213の指示には私用終端バイトを使って
JIS X 0208の独自拡張をESC 2/4 4/2で指示するという変態仕様
逆だろ…
0546デフォルトの名無しさん
2008/04/29(火) 08:16:41↓のコードは何でしょうか？
17163542
何て書いてあるのか、教えてください
よろしく
0547デフォルトの名無しさん
2008/04/29(火) 08:20:26http://love6.2ch.net/mystery/
0548デフォルトの名無しさん
2008/04/29(火) 08:23:07すみません。
文字コードじゃないんですか？
0549デフォルトの名無しさん
2008/04/29(火) 09:10:30ttp://google.com/
0550デフォルトの名無しさん
2008/05/01(木) 06:43:38やっぱり無理ですた
0551デフォルトの名無しさん
2008/05/17(土) 07:02:50問い合わせたら、「Win上のIEの挙動と同じにしている」とのこと。
具体的にはEUC-JPで0x5cが円記号で表示されるのですが。
これってreverse solidusが正解じゃなかったでしたっけ?
確かWinだとここら辺、フォントレベルでおかしなことをしてるんでしたっけ?
しかし正直なところもはやWinやIEの挙動を無視することもできず... トホホ。
0552デフォルトの名無しさん
2008/05/17(土) 08:02:14「円記号で表示される」だけだと、
エンコーディングレベルで何かやってるのか、
単にフォントがU+005Cを円記号で表示してるだけなのかわからんな。
後者ならフォント変えれば REVERSE SOLIDUS に見えるでしょ。
0553デフォルトの名無しさん
2008/05/17(土) 08:23:48Tahomaとかの欧文フォントならバックスラッシュ、
フォントリンクでかな漢字も表示出来ていい感じ。
0554デフォルトの名無しさん
2008/05/17(土) 09:44:03アプリはMac OS Xのエディタです。なんでWin上での技術的背景ではなく
ユーザーエクスペリエンスを問題にしている、とでもいいますか。
IEを「普通に」使ってる分にはEUC-JPの0x5cは円に見える訳ですよね。
あえて欧文フォントを割り当ててバックスラッシュを表示できてもそれはある意味
「化けている」のではないでしょうか。
あるいはIEはあくまでもEUC-JPの0x5cに対してU+005cを表示していて、それが
どう見えるかはフォントやユーザの設定次第、とでも理解すべきでしょうか。
でもIE、確かASCIIやUTF-8だとデフォで0x5cはバックスラッシュ... ややこしいなあ。
0555デフォルトの名無しさん
2008/05/17(土) 11:48:24人の話を聞く気がないならチラシの裏にでも書き捨てろ
0556デフォルトの名無しさん
2008/05/17(土) 12:15:02実際にIE使ってみればわかるだろクズ
0557デフォルトの名無しさん
2008/05/17(土) 12:24:31文字コードと文字フォントは別物だよ。
だから、
> あるいはIEはあくまでもEUC-JPの0x5cに対してU+005cを表示していて、それが
> どう見えるかはフォントやユーザの設定次第、とでも理解すべきでしょうか。
でOK。EUC-JPに限らずな。
0558デフォルトの名無しさん
2008/05/17(土) 15:10:460x5cというかU+005Cは、ASCIIやJIS X 0213だとUniccode基準で「REVERSE SOLIDUS」でなければおかしいけど、
一般的な日本語エンコードだとJIS X 0201基準だから「YEN SIGN」が正しい。
WindowsのOS標準和文フォントだと、0x5cというかU+005Cは「YEN SIGN」で実装。
Mac OS XのOS標準和文フォントだと、0x5cというかU+005Cは「REVERSE SOLIDUS」で実装。
Windows版のSafariでも、Shift_JIS/EUC-JP/ISO-2022-JPといった日本語エンコードなHTMLでは
和文フォントでも欧文フォントでも0x5cというかU+005CがU+00A5実装Glyph(YEN SIGN)でエイリアス表示され、
それ以外(UTF-8とか)だとフォントのU+005C実装Glyphでダイレクトに表示される。
Mozilla系ブラウザソフトでも「about:config」で、
“layout.enable_japanese_specific_transform default boolean false”を
“layout.enable_japanese_specific_transform user set boolean true”と設定変更すると、Safariと同じ挙動になる。
0559558
2008/05/17(土) 15:18:28Mac OS Xのエディタでも、設定で0x5cというかU+005CをフォントのU+005Cでダイレクトに表示するか
U+00A5実装Glyph(YEN SIGN)でエイリアス表示かで選択できるものがある。
ttp://pc.watch.impress.co.jp/docs/2006/0907/macos03.htm
ttp://pc.watch.impress.co.jp/docs/2006/0907/macos03_03.jpg
Windowsの方が日本のローカル規格的には親和な設計ではあるけど国際基準的にはいろいろ問題がある。
Mac OS Xだと国際基準的には親和な設計ではあるけど日本のローカル規格的にはいろいろ問題がある。
だから、Mac OS XやマルチプラットフォームなアプリだとOSやアプリレベルでWindowsとは違う日本ローカル規格対処策をしているものがある。
0560デフォルトの名無しさん
2008/05/18(日) 15:24:37> Mac OS XのOS標準和文フォントだと、
> 0x5cというかU+005Cは「REVERSE SOLIDUS」で実装。
Mac OS Xだと、
内部SJISアプリの0x5CはYEN SIGN（CMapは83pvまたは90pv）、
内部UnicodeアプリのU+005Cは（標準では）REVERSE SOLIDUS（CMapはUniJIS）。
0561デフォルトの名無しさん
2008/05/18(日) 22:56:43親和うんぬんの段落はちょっと短絡だろ。
もともとREVERSE SOLIDUSが要求されるところで、(例えば\n)
YEN SIGNを使ったり、YEN SIGNを表示に使ったりしていた過去があるんだから、
そんな単純に割り切れないよ。
0562デフォルトの名無しさん
2008/05/18(日) 23:23:330563デフォルトの名無しさん
2008/05/19(月) 20:40:22Unicodeで実装されてる第三、第四水準漢字ってSJISにちゃんとマッピングされてんですかね。
なんか規則性なく適当に散りばめてるだけな気がするんで
一文字一文字マッピングされてる場所指定する等で対応しないと対応出来ないのかな？
JISX213レベルでのUnicode-SJIS-EUC全部の対応表があれば嬉しいんですが、そんなのって無いですかね
0564デフォルトの名無しさん
2008/05/19(月) 20:48:10JIS2004自体に対応しているわけじゃなかったような。
0565デフォルトの名無しさん
2008/05/19(月) 21:39:56Vistaの公式ページで資料もフォントも配布されているというのに、
「されたとかいう」
「どうなってんのわかりません」
「そんなのって無いですかね」
「じゃなかったような」
とかいうヤツってナンなの？ゆとり？
ttp://www.microsoft.com/japan/windows/products/windowsvista/jp_font/
ttp://www.microsoft.com/downloads/details.aspx?FamilyID=f7d758d2-46ff-4c55-92f2-69ae834ac928&DisplayLang=ja
0566デフォルトの名無しさん
2008/05/19(月) 21:50:06何いってんだか
0567デフォルトの名無しさん
2008/05/19(月) 22:04:09これだからゆとりは困る。
これがエンコーディングの資料ではないとでも？
・Windows Vista ならびに Windows Server 2008 における JIS2004 対応に関する詳細資料
ホワイトペーパー「Microsoft Windows Vista および Windows Server 2008 における JIS X 0213:2004 (JIS2004) 対応について」(Version 1.2) は、こちら(XPS 形式、PDF 形式) をご参照ください。
・JIS X 0213:2004 / Unicode 実装ガイド
この実装ガイドでは、JIS 文字コードが Unicode 対応の JIS X 0213:2004 へ変更されたことに伴いアプリケーションへ与える影響および対応策などについて説明します。(XPS 形式 1.88 MB、PDF 形式 1.34 MB)
0568デフォルトの名無しさん
2008/05/19(月) 22:08:010569デフォルトの名無しさん
2008/05/19(月) 22:59:39Vistaの実装ではShift_JIS-2004やEUC-JIS-2004には対応していません。
JIS X 0213はUnicodeのレパートリとして実装されています。
必要なら自分で変換してください。
0570デフォルトの名無しさん
2008/05/20(火) 21:20:03オレオレ変換はやめてくれ
Shift_JISにはマッピングされていないから無理だと思っていただいた方が将来の人が助かる
0571デフォルトの名無しさん
2008/05/20(火) 21:43:150572デフォルトの名無しさん
2008/05/20(火) 22:52:150573デフォルトの名無しさん
2008/05/20(火) 22:58:09お前が使っていなくても、世間が使っている。
ほんと、DOS/Windowsの呪縛の1つだな。
0574デフォルトの名無しさん
2008/05/20(火) 23:15:090575デフォルトの名無しさん
2008/05/20(火) 23:15:15青空ｳﾝｺ工作員乙
0576デフォルトの名無しさん
2008/05/25(日) 00:59:45いつの間にかUnicodeの3面をTertiary Ideographic Plane(第三漢字面)とすることが決まってた。
現時点では1字も定義されてないが古代漢字や甲骨文字を収録するみたいだ。
0577デフォルトの名無しさん
2008/05/25(日) 01:08:50これは便利だ
0578デフォルトの名無しさん
2008/05/25(日) 16:02:100579デフォルトの名無しさん
2008/05/30(金) 01:20:21非Unicodeな文字コードとのマッピングが変わることってある？
基本的には予約領域に新しい文字が追加されていくj形という認識で合ってるのかな？
0580デフォルトの名無しさん
2008/05/30(金) 06:35:56そもそも一対一対応ですらない。
例えば、http://support.microsoft.com/kb/170559
0581デフォルトの名無しさん
2008/05/30(金) 20:36:130582デフォルトの名無しさん
2008/05/31(土) 12:20:35文字コード多すぎるだろう。
10年前のシステムならばしかたがないにしても、
現代のハードウェアやソフトウェアの質を考えたら、
行動を起こしてもいいと思うんだがなあ。
ビルちゃん、気まぐれで動かないかなあ。
0583デフォルトの名無しさん
2008/05/31(土) 13:16:570584デフォルトの名無しさん
2008/05/31(土) 13:36:150585デフォルトの名無しさん
2008/05/31(土) 14:17:36ワードで文書を作成する際に文字コードを指定されました（JIS-X0208-1982）.
しかしこの意味が全くわかりません。
普通にワードの画面を開いて文書作成しただけではこのコードにならないということでしょうか？
ググってみると、記号について何年かごとに改正されてきたコードらしいのですが
１９８３はあっても１９８２がみつかりません。また、これをワードでの文書作成時に
どう使うのかが理解できません。
ワードでの文書作成時に「挿入」から記号を挿入する際に何か特殊なことをする必要が
あるのでしょうか？その場合、どうすればいいのでしょうか？
画面下にドロップダウンがあってunicode とかJISとか選べるみたいだったのでやったのですが、
この０２０８というが見つからないし、途方にくれています。
ズブの素人なので、わかりやすく説明していただけると助かります。おねがいします。
0586デフォルトの名無しさん
2008/05/31(土) 15:58:22ビルちゃんはちゃんと動いているだろ。
気まぐれなのは相変わらずだが。(w
0587デフォルトの名無しさん
2008/05/31(土) 16:02:217ぐらい？
0588デフォルトの名無しさん
2008/05/31(土) 17:53:330589デフォルトの名無しさん
2008/05/31(土) 22:17:23> ビルちゃん、気まぐれで動かないかなあ。
一番動かないで欲しい人ですが？
0590デフォルトの名無しさん
2008/06/01(日) 00:32:59超初心者向け質問スレがちゃんとあるというのに、こんな超廃人スレに来てるＫＹなヤツってナンなの？ゆとり？
【ﾏｼﾞﾚｽ】超初心者の質問に答えるスレ93【ｴｽﾊﾟｰ】
ttp://pc11.2ch.net/test/read.cgi/win/1212070324/
0591デフォルトの名無しさん
2008/06/01(日) 00:49:35ttp://pc11.2ch.net/tech/
この板はプログラムを作る人のための板です。
プログラム・ソフトの使い方は PC 初心者板やソフトウェア板へ。
ウイルス、ハッキング・クラッキングを求めるような発言は禁止です。
Javascript は Web 制作板、CGI は Web プログラミング板へ。
業界談義、愚痴はプログラマ板へどうぞ。
ゲーム関係の話題はゲーム製作板へどうぞ。
ネタ、板とは関係の無い話題はご遠慮ください。
0592デフォルトの名無しさん
2008/06/01(日) 02:36:02いわゆる機種依存文字だけ気にしていればいいんじゃね？
>588さん
俺の予想では、文字集合を指定されたんじゃなくて、
WordがシフトJISで保存すると勘違いした奴が、1978から1983改訂の際の
文字の入れ替えについて改訂後のことだと言いたかったに一票。
0593デフォルトの名無しさん
2008/06/01(日) 03:13:41ありがとうございます！
私もこんなこと言われたの初めてで、びっくりした上、１９８２なんか
ないのに驚いたんですが、１９８３のことですかとは聞けなくて・・・。
本当にありがとうございました。
0594デフォルトの名無しさん
2008/06/01(日) 03:30:43「聞けなくて」じゃなくて聞けよ。プログラマーだろ？
想像でなく正確な仕様と要件にもとづいて仕事してくれ。
たとえば
http://www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=jp&bunsyoId=JIS+X+0208%3A1997&dantaiCd=JIS&status=1&pageNo=0
ではX 0208の履歴に1983はありませんが、って言えばいい。
0595デフォルトの名無しさん
2008/06/01(日) 03:34:42誤： 1983はありませんが
正： 1982はありませんが
つーか寝ようよ。そーゆートコだけプログラマーなのな。
0596デフォルトの名無しさん
2008/06/01(日) 11:34:51すいません、私、プログラマーとかじゃないんですよ^^;
パソコンについては、平均的な知識しかない書類作成係でして・・・・
この指示も書類作成にあたって渡されたんです。
１９８３の件を聞けないのは、この指示を出した技術者が、なんというか、
瞬間湯沸かし器なので、彼のプライドを傷つけるようなことをいったら（
１９８３のことですか？といっただけでも）、大変なことになるので・・・
0597デフォルトの名無しさん
2008/06/01(日) 11:42:56>>591をもう一度読んで
0598デフォルトの名無しさん
2008/06/01(日) 12:22:46初心者板にいる人達よりもレベルが高いと思ってきたんだ。
初心者板は起動に関してのトラブルとかばっかりだったし・・
でも、回答くれた方、ありがとう。本当に助かりました。
0599デフォルトの名無しさん
2008/06/01(日) 12:30:00どこで規格を入手すればいいんですかね。教えてエロい人
0600デフォルトの名無しさん
2008/06/01(日) 13:06:40どこでそれを入手すればいいんですかね。
0601デフォルトの名無しさん
2008/06/01(日) 13:41:51どこでそれを入手すればいいんですかね。
0602デフォルトの名無しさん
2008/06/01(日) 15:15:120603デフォルトの名無しさん
2008/06/01(日) 15:56:380604デフォルトの名無しさん
2008/06/01(日) 17:16:39それでもし間違ってたらどうすんだ。
0605デフォルトの名無しさん
2008/06/01(日) 22:00:59プログラマとしてのプライドを持った奴なら、自分で「ズブの素人」なんて言うわけわけねーだろ、常識で考えて。
しかも全角数字使ってる時点で585を超初心者だと見抜けない594ってってナンなの？ゆとり？
>>598
「あ、ごめんね」じゃねーだろ。
２ちゃんねるのルールが守れないなら、２ちゃんねるに来るな。
>>600-601
それは文字コードの話じゃねーだろ。
0606デフォルトの名無しさん
2008/06/01(日) 23:04:250607デフォルトの名無しさん
2008/06/01(日) 23:05:070608デフォルトの名無しさん
2008/06/02(月) 03:32:03過去の版の入手方法がわかんないってことでしょ。
http://www.jisc.go.jp/jis-act/reading.html
ぱっと見たけど見つからなかった。電話番号書いてあるから訊くのが早そうだな。
>>605
>>594だが何でそこまで言われにゃならんかね。
多くのプログラマーが全角英数字を毛嫌いするのは知ってるが、個人的にはありだと思うが。
少なくとも官庁相手に出す文書は全角にしてる。「Ｊａｖａ」とか「議事録４月１０日」とか。
上のリンク先でも「ＪＩＳ Ｘ ０２０１」とか「７ビット及び８ビットの２バイト情報」
って書いてるだろ。
ついでにプログラ「マー」って書いたら俺も超初心者扱いか。
0609デフォルトの名無しさん
2008/06/02(月) 04:45:040610デフォルトの名無しさん
2008/06/02(月) 04:49:400611デフォルトの名無しさん
2008/06/02(月) 06:07:08これだけ使われてるんだし。でも585が（・∀・）ｶｴﾚ!なのは同意
0612デフォルトの名無しさん
2008/06/02(月) 09:35:020613デフォルトの名無しさん
2008/06/02(月) 15:47:060614デフォルトの名無しさん
2008/06/02(月) 18:35:110615デフォルトの名無しさん
2008/06/02(月) 18:49:350616デフォルトの名無しさん
2008/06/03(火) 00:02:01ならUnicode StandardでいわゆるEAST ASIAN WIDTHがどういう扱いを受けてるのかくらい知ってるだろ？
それなのにこの場に及んでNORMALIZATIONされていない文字をまだ「ありだと思う」と言い張るその姿勢は実に見苦しい。
>>610
半角は潰れるが全角なら潰れないだと？
そんな文字サイズなら漢字は潰れまくりじゃねーか。
>>611
全角数字の扱いだけではない。
厚顔無恥で教えて君オーラ全開な文章から585の人間性を推し量れない608の稚拙さに問題がある。
>>612
知らん。
ゆとりの俺にも教えてくれ。
0617デフォルトの名無しさん
2008/06/03(火) 00:12:58今はアラビア数字の世の中なので。
0618デフォルトの名無しさん
2008/06/03(火) 00:24:02ttp://www.unicode.org/reports/tr11/
ttp://www.unicode.org/reports/tr15/
0619デフォルトの名無しさん
2008/06/03(火) 00:37:450620デフォルトの名無しさん
2008/06/03(火) 00:47:49今はユニコードの世の中なので。
0621デフォルトの名無しさん
2008/06/03(火) 01:38:200622デフォルトの名無しさん
2008/06/03(火) 02:32:460623デフォルトの名無しさん
2008/06/03(火) 02:52:09ナンみたいなヤツも作ってたんだけど確か違う名前だったような？あれってナンな（ｒｙ
ttp://www.ntv.co.jp/dash/village/05_ryou/2008/05/
0624デフォルトの名無しさん
2008/06/03(火) 02:59:42Restrictなのはわかるが、JISとUnicode規格読んでないとゆとりなんて、
このスレ、ハードル高すぎだっての。
とりあえず次スレは
【ナンなの？】文字コード総合スレ ｐａｒｔ４【←ゆとり？】
でおねがいします。
0625デフォルトの名無しさん
2008/06/03(火) 03:09:12カレーと云えばナン。カレーにライスは邪道。
ttp://food8.2ch.net/test/read.cgi/curry/1103503719/
>>624
空気嫁
0626デフォルトの名無しさん
2008/06/03(火) 10:48:10> 知らん。
> ゆとりの俺にも教えてくれ。
ttp://www.imasy.or.jp/~yotti/rfc1554jp.txt
これを書いた人
0627デフォルトの名無しさん
2008/06/03(火) 10:55:11JP-2って名前は良くなかったな。
0628デフォルトの名無しさん
2008/06/03(火) 21:53:57「mohta うさげ」でググってみたんだが、ゆとりの俺に状況が理解できん。
その昔、うさげというコミュニティが存在していて、そこにはmohtaと呼ばれる伝説の荒らしが常駐してた。
その荒らしがISO-2022-JP-2の規格の根本をまとめ上げたものの、荒らしが作った規格には反発が強く世間には定着しなかった・・・、ってことでおｋ？
それより何でこの話がㇳ突然出てきたんだ？
ISO-2022-JP-2と全角英数字と何の関係あるんだよ？
全然わかんね。
てか、ググったら木村浩一さんのサイトにこのスレがコピペされてるのを発見ｗ
ttp://www.kt.rim.or.jp/%7ekbk/zakkicho/08/zakkicho0806a.html#D20080602
0629デフォルトの名無しさん
2008/06/03(火) 22:51:53カレーと云えば飲み物。噛んで食べるヤツは邪道｡･ﾟ･(ﾉД`)･ﾟ･｡ｳｴｴｪｪﾝ
ttp://news24.2ch.net/test/read.cgi/mnewsplus/1212452680/
0630デフォルトの名無しさん
2008/06/03(火) 23:03:400631デフォルトの名無しさん
2008/06/03(火) 23:13:51ttp://wiredvision.jp/news/200805/2008050121.html
>>629
これだな
ttp://mamono.2ch.net/test/read.cgi/newsplus/1212380001/
0632デフォルトの名無しさん
2008/06/04(水) 10:14:430633デフォルトの名無しさん
2008/06/04(水) 10:34:23voidとか、lalaとか、現代版はotsuneとか、ちょっと前に言われた「モヒカン」タイプの
元祖のような奴がmohta。暴れるという形容は適用されるけど、荒らしとは違う。
mohtaの特異な点として、JIS X 0208に統一して文章を書くという性質が挙げられる。
（>>626のRFC翻訳でもそれをやっている）
Unicode化の流れに対抗したけど、というあたりは多勢に無勢というか。
0634デフォルトの名無しさん
2008/06/04(水) 10:36:12うさげ == fj.net.usage
0635デフォルトの名無しさん
2008/06/04(水) 10:38:430636デフォルトの名無しさん
2008/06/04(水) 13:56:27fj の「3馬鹿」も mohta、 lala は聞かなくなったな…
void は所を mixi に移してあいかわあらず暴れてるらしいが…
0637デフォルトの名無しさん
2008/06/04(水) 16:47:29ホントだワロタ
原文: http://www.ietf.org/rfc/rfc1554.txt
mhota訳: http://www.imasy.or.jp/~yotti/rfc1554jp.txt
一部メールアドレスまで全角だw
0638デフォルトの名無しさん
2008/06/04(水) 19:30:430639デフォルトの名無しさん
2008/06/05(木) 00:10:29ありがとう。
なんとなくわかったかも知れん。
「Unicode化の流れに対抗したけど、というあたりは多勢に無勢」とかは、青空文庫工作員と同じ構図なんだな。
つまり、全角英数字を使うヤツは「超初心者」か「極右(笑)」ってことか。
> ちょっと前に言われた「モヒカン」タイプ
知らん。
ゆとりの俺にも教えてく（ｒｙ
バブル世代にとっての「ちょっと前」は、ゆとり世代にとっては「大昔」なんだが・・・。
>>638
ゆとりの俺ですがvoidという名前だけは噂に聞いたことがあるｗ
0640デフォルトの名無しさん
2008/06/05(木) 00:32:52もう深追いしないほうがいいよ。
0641デフォルトの名無しさん
2008/06/05(木) 00:34:51「?」もこのスレでは全角の方が多いようだけど
0642デフォルトの名無しさん
2008/06/05(木) 01:16:29疑問符とか感嘆符の類はどっちでも良くね
0643デフォルトの名無しさん
2008/06/05(木) 01:44:44ttp://food8.2ch.net/test/read.cgi/curry/1071495811/
0644641
2008/06/05(木) 01:51:37概念的には同じ文字なので半角にNORMALIZEされた形にすべき、
ってのが昔のvoidの主張だった気がする。JIS X 0208もUnicodeも規格はそういう
考えだったと思う。それがこのスレ的にどうなのかなと。
たとえばUnicodeテキストでWinの「～(U+2015)」とMacの「～(U+2014)」が混ざってたら俺としては
2015に正規化したくなる。でも全角半角は事実上すべての環境で表示される字の大きさが
異なるので同じ文字としては扱いたくないなーと。
0645デフォルトの名無しさん
2008/06/05(木) 02:02:01ttp://www.geocities.jp/jugongordie/old/curryfla/curryfla.html
>>644
まぁ細かいこと気にするな
( ﾟДﾟ)⊃ ○ < ｶﾚｰﾊﾟﾝ食え
ttp://food8.2ch.net/test/read.cgi/bread/1092166761/
0646644
2008/06/05(木) 02:56:34(誤) Winの「～(U+2015)」とMacの「～(U+2014)」
(正) Winの「∥(U+2225)」とMacの「∥(U+2016)」
ん？ いつから双柱って傾いて表示されるようになった？ Vistaから？
0647デフォルトの名無しさん
2008/06/06(金) 00:53:190648デフォルトの名無しさん
2008/06/06(金) 06:36:11の図１２
0649デフォルトの名無しさん
2008/06/08(日) 00:31:44http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg30/IRGN1435_ivs-demo-irg30.pdf
>>646
メイリオだともっと露骨に斜め45度の線2本で表示される。
まあちゃんと研究してるんだろう。角度とか
0650デフォルトの名無しさん
2008/06/13(金) 07:22:05http://www.unicode.org/policies/lastresortfont_eula.html
てっきりエイプリルフールネタだと思ってたのに本気でグリフをUnicodeに収録するつもり
なんだろうか
0651デフォルトの名無しさん
2008/06/13(金) 18:24:17グリフをUnicodeに収録?
まともかく、文字が表示されないときにそれが単にグリフがないせいなのか
Unicodeの範囲に入っていないせいなのかわかるとうれしいけどね。
で前者の場合にはだいたいどこら辺の文字かもわかると。
フォントの自動置換が働く場合には特に。
0652デフォルトの名無しさん
2008/06/13(金) 22:20:54ようやく見出し文字を全部符号化したUnicode康煕字典が作れるようになるのか。
韓国なんかUNC(緊急に必要な文字)を1万字くらい収録しる! とか無理難題言ってるのに
日本の謙虚さは異常。大漢和の未収録文字くらい提案したって罰は当たらないと
思うんだが
0653デフォルトの名無しさん
2008/06/13(金) 23:34:12しゃーないのかなと思う所はある。
0654デフォルトの名無しさん
2008/06/13(金) 23:41:090655デフォルトの名無しさん
2008/06/13(金) 23:41:530656デフォルトの名無しさん
2008/06/13(金) 23:43:090657デフォルトの名無しさん
2008/06/13(金) 23:44:500658デフォルトの名無しさん
2008/06/13(金) 23:53:230659デフォルトの名無しさん
2008/06/14(土) 00:20:590660デフォルトの名無しさん
2008/06/14(土) 12:48:40(インド系文字もハングル式に実装すると数千字分くらいのコードポイントは平気で使う)
0661デフォルトの名無しさん
2008/06/15(日) 02:14:47それ実際にやったら描画・文字幅計算とかアラビア文字みたいにややこしいことにならない？
0662デフォルトの名無しさん
2008/06/15(日) 02:30:44(Hangeul Jamoブロックを使った奴ね)
Mac OS Xは(互換漢字と一部の記号を除いて)NFDだからHFS Plusのボリューム上では
ハングルはバラバラになって記録されてる
0663デフォルトの名無しさん
2008/06/15(日) 02:47:330664デフォルトの名無しさん
2008/06/15(日) 03:32:42部首の組み合わせによる表現をやりにくくしてるし
0665デフォルトの名無しさん
2008/06/17(火) 12:24:24U+1100～のHangeul Jamoブロックの組み合わせで表すことにすればよかったのに。
それかどうしても全ての組み合わせのコードが必要なら追加分はBMP外にするべきだったと思う。
0666デフォルトの名無しさん
2008/06/17(火) 12:54:01ttp://www.unicode.org/roadmaps/bmp/
0667デフォルトの名無しさん
2008/06/17(火) 20:06:18> 従来のコードで表せない字母の組み合わせは
> U+1100～のHangeul Jamoブロックの組み合わせで表す
Unicode 1.1までははそうするつもりだったのに全部収録させるためだけに
Hangul and ComputerがUnicode Consortiumのフルメンバーになったりしてだな
http://www.unicode.org/history/contributors.html
0668デフォルトの名無しさん
2008/06/19(木) 10:54:240669デフォルトの名無しさん
2008/06/19(木) 22:29:010670デフォルトの名無しさん
2008/06/19(木) 23:14:360671デフォルトの名無しさん
2008/07/02(水) 23:02:20･各国のコード体系をきちんと分けて管理（アジアごっちゃ煮鍋はやめてくれ）
･固定長フォントにおける表示文字幅（半角、全角）を明確に判別し
文字幅長のカウントが可能
（サロゲートペアみたいのはもうこりごり）
･既存の文字コード（機種依存文字含む）からの完全な変換が可能。
0672デフォルトの名無しさん
2008/07/02(水) 23:28:35たいてい失敗します。IPv6とかIA-64とかOS/2とか。
0673デフォルトの名無しさん
2008/07/02(水) 23:33:590674デフォルトの名無しさん
2008/07/02(水) 23:37:390675デフォルトの名無しさん
2008/07/03(木) 10:34:450676デフォルトの名無しさん
2008/07/04(金) 01:29:59NATみたいなことしなくてもIPv4と直接接続できればよかったのに
0677デフォルトの名無しさん
2008/07/04(金) 13:15:180678デフォルトの名無しさん
2008/07/05(土) 12:29:32http://www.unixuser.org/~euske/doc/ipv6ex/index.html
0679デフォルトの名無しさん
2008/07/05(土) 12:46:04IPv6にはこんな技術的問題点があると主張しているだけ。
彼独自の言い回しで改善を要求しているようには読めないけど、
まあそれは彼の芸風だから、誤解する奴が馬鹿なだけ。
> NATみたいなことしなくてもIPv4と直接接続できればよかったのに
こんなトンデモとは全く違うよ、djbは。
(もちろん彼の芸風はちょっと狂ってる)
0680デフォルトの名無しさん
2008/07/06(日) 10:21:20つ http://pc11.2ch.net/test/read.cgi/network/1214112105/
0681デフォルトの名無しさん
2008/07/06(日) 10:33:43“情報化時代”に追いつけるか？
審議が進む「新常用漢字表（仮）」
http://internet.watch.impress.co.jp/cda/jouyou/2008/06/19/19998.html
0682デフォルトの名無しさん
2008/07/06(日) 12:04:030683デフォルトの名無しさん
2008/07/06(日) 13:32:220684デフォルトの名無しさん
2008/07/15(火) 18:08:31数値文字参照が全く使えないと言ってるんですが、他のサイトはどうやって対応しているとかどなたか教えてくれませんか？
ぐぐってここにたどり着いたしろーとで申し訳ないんですけど、よろしくお願いします。
0685デフォルトの名無しさん
2008/07/15(火) 18:17:390686デフォルトの名無しさん
2008/07/15(火) 18:18:460687デフォルトの名無しさん
2008/07/15(火) 18:22:450688デフォルトの名無しさん
2008/07/15(火) 21:48:34docomoの公式ページで携帯コンテンツ制作者向け情報が公開されているというのに、「どなたか教えてくれませんか？」とか言ってるヤツってナンなの？ゆとり？
ttp://www.nttdocomo.co.jp/service/imode/make/
ttp://www.nttdocomo.co.jp/english/service/imode/make/
・iモード対応HTML ～3.x
文字コード : Shift_JIS
10進数値文字参照(Shift-JIS準拠数値) : &#*****;
・iモード対応HTML 4.0～ (MOVA504i～およびFOMA)
文字コード : Shift_JIS
10進数値文字参照(Shift-JIS準拠数値) : &#*****;
16進数値文字参照(Unicode準拠数値) : &#x\\\\;
・iモード対応XHTML (FOMA)
文字コード : Shift-JISおよびUTF-8
10進数値文字参照(Shift-JIS準拠数値) : &#*****;
16進数値文字参照(Unicode準拠数値) : &#x\\\\;
てか、「友達が」というヤツに限って本当は本人が当事者なんだよなｗ
auとSoftBankの携帯コンテンツ制作者向け情報もきちんと読めよｗ
ttp://www.au.kddi.com/ezfactory/
ttp://creation.mb.softbank.jp/
0689デフォルトの名無しさん
2008/07/15(火) 22:15:48出し惜しみとか最低ですね
0690デフォルトの名無しさん
2008/07/15(火) 22:31:460691デフォルトの名無しさん
2008/07/15(火) 22:34:41の人は頭わるかったんだねえ。
0692デフォルトの名無しさん
2008/07/15(火) 22:37:300693デフォルトの名無しさん
2008/07/15(火) 22:49:42ttp://pc11.2ch.net/tech/
この板はプログラムを作る人のための板です。
プログラム・ソフトの使い方は PC 初心者板やソフトウェア板へ。
ウイルス、ハッキング・クラッキングを求めるような発言は禁止です。
Javascript は Web 制作板、CGI は Web プログラミング板へ。
業界談義、愚痴はプログラマ板へどうぞ。
ゲーム関係の話題はゲーム製作板へどうぞ。
ネタ、板とは関係の無い話題はご遠慮ください。
0694デフォルトの名無しさん
2008/07/15(火) 23:17:30685と688は別人だということを推し量れないヤツってナンなの？ゆとり？
>>691
Internet Explorer 3やNetscape Navigator 3では文字参照がShift_JISのコードポイントってことを知らないヤツってナンなの？ゆとり？
0695デフォルトの名無しさん
2008/07/16(水) 01:26:09配慮されてもなー
0696デフォルトの名無しさん
2008/07/16(水) 02:25:47文字参照も同じShift_JISにするというのはあまり変だと思わないな。
1999年ならそれに加えてUnicodeに対応させるのは厳しかったのだろうし。
問題はなんでそれを今でも引きずらならなきゃならないのかということだ。
0697デフォルトの名無しさん
2008/07/16(水) 07:11:13でもIE4/NN4/HTML4でもうとっくに文字参照はUnicodeが標準になってましたよ
確かにドコモのページには「iモード対応HTML4.0対応機種以降」とか書いてるから
最初はHTML4(の文字参照)に対応してなかったようだけど。
16進文字参照が導入されたのもHTML4だから、16進で書かれたらHTML4とみなす
というのもどうにか互換性を保ちつつ拡張しようとした結果だと思われ
0698デフォルトの名無しさん
2008/07/16(水) 09:15:450699デフォルトの名無しさん
2008/07/16(水) 09:51:42メールの文字コードとかもそうだし、mldファイルのMIME-TYPEがtext/plainとかむちゃくちゃやっとったｗ
0700デフォルトの名無しさん
2008/07/16(水) 10:17:250701デフォルトの名無しさん
2008/07/16(水) 11:31:45公式も見たんですが分からなかったんで、グーグルで同じような人いないかなーって調べてたらここに来れたので、普通に聞いちゃいました。
原因も分からないし、友達外人だからいちいち説明もしてらんなかったので、手っ取り早い解決方法を模索しちゃいました。
とりあえずデータベースからの見直しをお願いしようかと思っています。
正直素人なのにあんま貶されなくて、ほっとしましたｗ
ありがとうございましたー
0702デフォルトの名無しさん
2008/08/06(水) 19:57:26http://standards.iso.org/ittf/PubliclyAvailableStandards/c046311_ISO_IEC_10646_2003_Amd_4_2008(E).zip
今回最大の変更点は、実装水準1と2が廃止されたこと。
適合を主張するすべての実装は、合成をサポートしなければならなくなりました。
0703デフォルトの名無しさん
2008/08/06(水) 22:34:33実装水準3に適合すんの無理くさいのに
0704デフォルトの名無しさん
2008/08/08(金) 00:40:010705デフォルトの名無しさん
2008/08/08(金) 02:36:230706デフォルトの名無しさん
2008/08/08(金) 20:56:57「JAPANESE NON IDEOGRAPHICS EXTENTION対応です」で逃げられる
0707デフォルトの名無しさん
2008/08/08(金) 21:18:29「ほとんど使われていないJIS X 0213の国際基準版・漢字用8ビット符号や参考に
過ぎない附属書の符号化表現は今後もサポートする予定がないので、国際規格
によるレパートリの記述方法で適合性を表現することにしました」とでも言っておけ
ばよろし。
新常用漢字やら新々人名用漢字やらで、もしIVS対応が必要になったら
もう逃げられないけどね。
# 他にどんなデメリットがあろうと2オクテットで表せるなら互換漢字のほうがマシだ
# って人は多いんだろうなあ…
0708デフォルトの名無しさん
2008/08/10(日) 23:06:48サロゲート対応は必須になるな。
0709デフォルトの名無しさん
2008/08/10(日) 23:26:49JIS X 0208で(それどころかUnicode BMPですら)表せない文字が追加されることの
インパクトをどれくらい真剣に考えてるんだろうね
0710デフォルトの名無しさん
2008/08/11(月) 19:11:53なってしまっている。初期の博物学のような眩暈のする状況。
0711デフォルトの名無しさん
2008/08/11(月) 21:20:25Unicode ないほうが楽って思ってるのは俺一人か？
0712デフォルトの名無しさん
2008/08/11(月) 21:26:180713デフォルトの名無しさん
2008/08/11(月) 22:10:12結局「糞」や「屍」同様に名付けに相応しくない字とされ追加されなかったが。
0714デフォルトの名無しさん
2008/08/11(月) 23:21:440715デフォルトの名無しさん
2008/08/11(月) 23:23:19お前は今までに実装したISO-IRの符号化文字集合の数を覚えているのか?
0716デフォルトの名無しさん
2008/08/11(月) 23:50:26Unicodeなしで、例えばIBM ICUくらいのレベルに仕上がった
文字を扱うライブラリってあるんですか？
扱う文字数も含めて。
正直、Unicodeのもたらした困難さは、
文字符合化の困難さのごく一部に過ぎません。
全世界共通の土壌を提供したメリットに比べたら無視できます。
0717デフォルトの名無しさん
2008/08/12(火) 10:43:14いいも悪いも
提唱したxeroxと共に死ねよ、規格グチャグチャにしやがって
という思いのみ
0718デフォルトの名無しさん
2008/08/12(火) 11:27:150719デフォルトの名無しさん
2008/08/12(火) 20:21:13以前よりはマシになった程度
0720デフォルトの名無しさん
2008/08/12(火) 20:33:00とりあえず、Unicodeに入ってしまえば、
ISO 8859だった奴等もそれに従う必要があるというのは大きいし、
世界を視野に入れたソフトウェア産業の思惑とも合致する。
Unicode化しておけば、L10Nの手間がかなり減る。
0721デフォルトの名無しさん
2008/08/12(火) 22:29:18UTF-8に統一してくれればいくらか楽だけど、冗長性問題あるしなぁ。
0722デフォルトの名無しさん
2008/08/12(火) 23:08:04最近では非関税障壁を消してしまうとインド人や中国人の雇用が増えるばかりで
自分たちの仕事が無くなるのを恐れてるんじゃないかと思えてくるようになった
0723デフォルトの名無しさん
2008/08/12(火) 23:17:06あんな中途半端なことしないで、完全にひっくり返しちゃった方がややこしくない気がするけど。
まあ、UTF-8でエンディアン問題が出てくるからそれはそれで面倒か。
0724デフォルトの名無しさん
2008/08/12(火) 23:33:470725デフォルトの名無しさん
2008/08/13(水) 00:09:350726デフォルトの名無しさん
2008/08/13(水) 00:27:12ビッグエンディアンでabcdefghijklmnopABCDEFGHIJKLMNOPというビット列は
リトルエンディアンだとABCDEFGHIJKLMNOPabcdefghijklmnopになると思うけど、
そうじゃなくてPONMLKJIHGFEDCBAponmlkjihgfedcbaまでひっくり返してしまうつうこと。
小さい桁から遡っていく感じですな。
こうすると冗長なゼロが頭に来なくなるから、それなりに便利な気もするけどね。
0727デフォルトの名無しさん
2008/08/13(水) 00:36:010728デフォルトの名無しさん
2008/08/13(水) 00:39:42だけど、文字の世界でまであわせる必要は無いかと思うがね
0729デフォルトの名無しさん
2008/08/13(水) 00:55:42UTF-16だとワード幅の数値だからね。
0730デフォルトの名無しさん
2008/08/13(水) 03:31:530731デフォルトの名無しさん
2008/08/13(水) 04:00:40符合化方式が複数ある程度のことが苦になる人は、
文字符合化のことなんて考えないほうがいいですよ。
ライブラリに任せなさい。
0732デフォルトの名無しさん
2008/08/13(水) 20:10:500733デフォルトの名無しさん
2008/08/13(水) 21:01:08ワードアクセスが関係するのはビッグエンディアンだけだろ。
リトルエンディアンの考え自体はワードアクセスの制限を受けない。
>>728
バイト単位でデータ交換する世の中でそれはできねーだろ。
Encoding formのUTF-16だけじゃなくてEncoding shemeのUTF-16がどうしても要る。
>>730
ネタじゃなくて真性だろ。きっと。
俺としてはビッグエンディアンみたいな統一性の無い仕様こそ嫌だね。
つーかUTF-8のエンディアン問題ってナンなの？
0734デフォルトの名無しさん
2008/08/13(水) 21:13:26>つーかUTF-8のエンディアン問題ってナンなの？
エンディアンというかBOM
UTF-8は本来そんなもんいらないはずなのに
http://www.unfindable.net/~yabuki/blog/2006/08/notepad_171819.html
0735デフォルトの名無しさん
2008/08/13(水) 22:29:30文字コードに関する情報が無いままテキストファイルが散乱する方が恐ろしいじゃねーか。
必要とか必要じゃないとかじゃなくて、あっても受け入れるのが仕様。
互換性のためなら設計ミスも押し通す。それがJavaがクオリティ。
0736デフォルトの名無しさん
2008/08/14(木) 09:35:57もしかしてビット列表記のLSB、MSBも逆に書けと言ってるのか？
0737デフォルトの名無しさん
2008/08/14(木) 20:56:49違う。書くんじゃなくて、>>723が自分のバイナリエディタで見た16進数を2進数に
書き取った時にビットが逆に並ぶようなアーキテクチャにしてくれ、と言っている。
つまり32ビット値12345678hは、
ビッグエンディアン
12 34 56 78 (0001-0010 0011-0100 0101-0110 0111-1000)
に対し、>>726式リトルエンディアンでは
1E 6A 2C 48 (0001-1110 0110-1010 0010-1100 0100-1000)
となる。
俺はノーサンキューだね。
BE/LEどちらも、ビットの順なんて定義していないことを理解して欲しい。
0738デフォルトの名無しさん
2008/08/14(木) 21:58:30そういう意味では、たとえばBE32bit数値は、Bit0～Bit31まで
素直に連続してるといえるけど。
0739デフォルトの名無しさん
2008/08/14(木) 22:59:51ならないよ。バイト内のビット順序なんて規定してない。
そもそもの間違いは、日本人が数値を書く時は繰り上がりが発生すると左に桁を
増やして書く(=桁の上位が左側)のに、16進でバイト列書く時は左から右(上位
アドレスが右側)に書くこと。
ワード内の並びなんて文字を右から左に書くか左から右に書くかで何とでも言える。
いいか？ ビッグエンディアンは多バイト整数(ここではUTF-16文字とする)を
複数書くときにワード境界で不連続になるんだ。
0740デフォルトの名無しさん
2008/08/14(木) 23:08:300741デフォルトの名無しさん
2008/08/14(木) 23:44:030742デフォルトの名無しさん
2008/08/15(金) 05:53:470743デフォルトの名無しさん
2008/08/15(金) 07:27:35＞ならないよ。バイト内のビット順序なんて規定してない。
へー。
http://www.nk.rim.or.jp/~jun/ppcasm/ppcasm02.html
＞(PowerPCは)bit0が最上位になります。ローテイト命令などでビット位置を
＞指定する場合に注意が必要です。上位16ビットは0：15、
＞下位16ビットは、16:31となることに注意してください。
0744デフォルトの名無しさん
2008/08/15(金) 08:09:11IBM と、今は亡き DGくらいなんだが、 MSB=bit0
MIPS とか SUN とかは LSB=bit0
0745デフォルトの名無しさん
2008/08/15(金) 13:30:400746デフォルトの名無しさん
2008/08/19(火) 09:04:27ﾜﾛﾀ
Unicodeはバイト(=8bit)の内部には関与しません。
0747デフォルトの名無しさん
2008/08/19(火) 22:35:39>746
いや、UTF-8の冗長性チェックは内部ビットを意識しないとできないんじゃない？
下位桁が先頭に来るようにすれば、位取り0の挿入による冗長表現の判別が簡単になるから
UTF-8で行う必要のある正当性チェックが簡単になる、ぐらいの話だよ。
>743
PowerPCは最下位桁が先頭なのか……知らんかった。
素人丸出しですな。
0748デフォルトの名無しさん
2008/08/19(火) 23:48:33だから、バイト内のビットに先頭も末尾もないってば。
だからどっちをビット0と呼ぼうと関係ないんだって。
0749デフォルトの名無しさん
2008/08/20(水) 04:11:02文字コードの変換元が判らなくて、すこし困っているのだが、
だれかこの文字コードが何だか認識できる人はいますかな？
"e2 5a fc 5b e2 eb fc 5b f2 d7".
これ、”セーラー服”ってなるのだが
UTF8 = "e382 bbe3 83bc e383 a9e3 83bc e69c 8d"
EUC-JP = "a5bb a1bc a5e9 a1bc c9fe"
shift-jis = "835a 815b 8389 815b 959e"
あきらかに違うんだよ。自動変換ミス？”ー”（UTF-8: 0xE3 0x82 0xBB）
が ”fc 5b” になる文字コードってなんかあるのかな？
偉い人、助けてください。
0750デフォルトの名無しさん
2008/08/20(水) 08:15:170x80未満のコードはそのままで、0x80以上は簡単に暗号化している感じ。
尤も、0x83は0xe2になるのに0x81が0xfcなので単純なxorなんかじゃなさそうだけど。
一対一対応はできていそうだから、サンプルがもう少しあれば解析できそうだ。
今は出勤前だから、取り敢えず電車の中で考えてみるか。
0751デフォルトの名無しさん
2008/08/20(水) 14:05:55どうやって、切り分ければいいの？
0752751
2008/08/20(水) 14:14:11この <昔の中国語(漢字はおそらくGBの範囲内)> 単語は、古来日本では
<昔の日本語(漢字はJISの範囲内じゃないかも知れない)> に相当...
の、ような文章が続く場合、<>で挟まれた間の言語の仮定方法がない
と思われるんだが…
つか、言語分からないと、辞書が引けない
0753デフォルトの名無しさん
2008/08/20(水) 14:25:320754デフォルトの名無しさん
2008/08/20(水) 14:31:55サロゲートペアでググれ
>>753
無理じゃねーよ。
もちろんlang属性でも可能。
どちらもまともな対応ブラウザは少ない。
0755デフォルトの名無しさん
2008/08/20(水) 22:20:51>>751 その『切り分け』って何だ？
>>752 Unicode系なら、人間が前後の文脈で判断するしかない。
もしISO-2022で書いてあるなら言語情報はあるので詳しい人に訊け
>>753 辞書引くって言ってるから既に文書があることが前提でしょ。
ISO-2022かlang属性ついてるかでなければ諦めろとしか言いようがない
>>754 何でここでサロゲートペアが出てくるのか理解できん
0756デフォルトの名無しさん
2008/08/20(水) 22:34:31紙に書いた時と同じだろ。文章で説明しろよ。
lang属性とか言っている奴は馬鹿か？
0757デフォルトの名無しさん
2008/08/20(水) 22:34:41一般的な文字コードでは無いね。シフトJISが文字化けしてるか独自コード(難読含む)のどちらか。
独自コードのリバースエンジニアリングはこのスレの話じゃなくなる。
0758479
2008/08/21(木) 02:27:43>>750 ありがとう、cp932であたりをつけたら、問題発見した。
原因：winzipの規格ではコードページ指定もしくは記録情報が存在しない。
（zipのソース読まなくちゃ判んないとは...規格に書いておいてくれよ...）
勝手にプログラムの方で無理矢理コード変換してるので、でたらめっぽい文字列が出てくる。
解決策：取り合えず、MSWin+JPではShift-jisでファイル自体には保存されている。
MACOSX=Unicode,Unix=UTF/EUC/S-JISどれでもありえる。文字に関係なくLocalLangで
再変換しているので、それをしなければよい。
実験用に、bash+coreutil+iconvでうごく、代用品をでっちあげてみたので、
よかったらどうぞ。
ttp://aikofan.dee.cc/aikoup1/src/f1012.xxx (txt/bash-script)
0760デフォルトの名無しさん
2008/08/21(木) 02:31:55勝手にやって失敗しているwinzipが悪いに決まってる。
0761デフォルトの名無しさん
2008/08/21(木) 05:09:22まったく普及してないけど。
0762デフォルトの名無しさん
2008/08/21(木) 14:17:120763デフォルトの名無しさん
2008/08/21(木) 15:25:29拡張されたフラグなのだからGDGDになってるのもしょうがないな。
0764デフォルトの名無しさん
2008/08/22(金) 08:28:52WindowsOSの環境で、フォルダに格納されているテキスト群の
それぞれに指定されている文字コードを一覧で表示してくれる
ツールをご存じないでしょうか？
精度はそれほど必要は無く、S-JIS/EUCを判別できる程度でも
良いのです。
googleで調べてみたのですが、なかなか見つからなくて・・・。
0765デフォルトの名無しさん
2008/08/22(金) 09:07:490766デフォルトの名無しさん
2008/08/22(金) 10:17:020767デフォルトの名無しさん
2008/08/23(土) 00:26:38ぶっちゃけ、完全なeuc/s-jis/jis判定はできないから。ソフト側で無理矢理
推測するので、間違いもあるけど。
うちでは追加でまず地域指定、あと、含まれるであろうキーワードのリストと
ファイルmimeで多少精度を上げるときもあるけど、処理の割には判定が甘い。
此ばっかりはどうにもならないな。
”勘ピューター”プログラミング、他にはどんな判定方法あったっけ？
0768デフォルトの名無しさん
2008/08/23(土) 00:46:34日本語文字の出現頻度スコアを持ってるバベルならほぼ完璧に判定できるよ。
ただ、コマンドとしては用意されてないけど。
0769デフォルトの名無しさん
2008/08/23(土) 01:16:04あと、学術論文とかで数か国語混じってると、誤判定おこすんだよなあ。
やり方としては間違っちゃいないんだろうが。
あれは、文法の前後の単語の頻度スコアはやってないから、中国文っぽいとき
（ただ単に日本語の漢字のみで文書が書かれていた場合）とか、判定ミスる。
轍書き＋前後頻度辞書での組合せでやってるのは今んトコ俺は見たことないが。
（世の中にはあるかもしれない）。FirefoxもUTFで中国文っぽい日本語では、
判定では日本語でも、フォント関係なく部分的に中国文字になるし...はあ。愚痴スマソ。
0770デフォルトの名無しさん
2008/08/23(土) 02:02:17>文書が短いとき
短いだけなら出現頻度スコアだけで十分な判定精度が得られると思うけど。
>数か国語混じってると
これは下手に対応しようとすると逆に一般的な判定精度が劣化しそうだし、
真面目にやるにはサンプリングデータの収集も面倒だし、判定用に使用する
スコアデータも膨大になってかなり大事になりそうですね。
>中国文っぽいとき
これは厳密にはどういう意味？
例えばSJISで使える文字だけつかって中文を記述したとかそんな感じ？
0771デフォルトの名無しさん
2008/08/23(土) 08:49:42ありがとうございます。皆さん親切に・・・。
いろいろと教えてもらったキーワードから、自分にあったのもを
探してみます。たった一日でこんなにアドバイスもらえるなんて・・・。
0772デフォルトの名無しさん
2008/08/23(土) 14:06:17>中国文っぽいとき いや、単に日本語だけでも、プログラムの上では
部分的に中国語判定なるものがある。悪い例（超弩級大型対空支援砲撃用戦艦）（文書に得に意味はなし
でも括弧の間だけ中文判定されたりする（中文じゃないのに）。例としてfirefoxで使用しているフォントレンダリングの
コードは、かなり手抜きで、むしろひらがな、片仮名が無ければ中文判定してんじゃないの、って言われてもしかたない
ような実装に見えてしまう...（別にそう云う訳では無いのだが）。実際、日本的な丸文字フォントがちゃんとあるのに、
その部分だけハネの強い中文体になってたりして、サロゲート、なにそれ？な状態で読んでるとかなり萎える...
つうーか、個人的には、日本でutfの空スベースを少し買収して、そこに一から日本文字のコードセットを
築いてほしい...いや、まじめにね、ラテンでДϦСDЄFԍҺIЈКМИOρ٩ᴦSϮUѴШχyZ使え、って言ったら、ブチ切れるのに、
ハネがすこし違い、少し角張っている・丸い、で一緒くたにされた、glyphおんなじって言われた方は、溜ったもんじゃないんだよ。
いや、疲れてるね、おれ。
0773デフォルトの名無しさん
2008/08/23(土) 14:09:04漢文とかじゃね？
0774デフォルトの名無しさん
2008/08/23(土) 16:44:20反対運動をするところだけど、今更どうにもなんないしなぁ
0775デフォルトの名無しさん
2008/08/23(土) 17:01:49>部分的に中国語判定なるものがある。
lang 指定とかの手掛かりも無しにそれを自動でやるのは無謀以外のなにものでもないだろｗ
それって端的に言うと
『日本語のフォントだと「骨」はこうなるけど、中文のフォントだと「骨」はこうなる。』
みたいな文章の「骨」の部分のフォントを自動判別で切り分けろって話だろ？
このクラスの自動判別を行うには文章の内容をほぼ完全に解析するような
かなり高度なAIが必須なわけで現状では無理。
0776デフォルトの名無しさん
2008/08/23(土) 17:05:05そういうヒューリスティックが必要な処理はできるだけ避ける方向で行くしか
ないのでは。htmlならlangとcharsetがあるわけだし。
そうそう、グリフに関してはデザインレベルの問題があるよね。
あう意味異体字タグが扱う話よりさらに細かいレベルの問題というか。
0777デフォルトの名無しさん
2008/08/23(土) 18:41:18langやcharsetは>>752の目的には不適だと思う。
0778デフォルトの名無しさん
2008/08/23(土) 19:16:340779デフォルトの名無しさん
2008/08/23(土) 21:27:11> 読者のことを考えると、文章だけで理解、判別できなくてはならない。
原理的に無理なものはどうしようもない。
あとは運用で何とかしてくれ。
0780デフォルトの名無しさん
2008/08/23(土) 22:11:060781デフォルトの名無しさん
2008/08/24(日) 01:11:53開いたときに人間が判断できた形式が正解っていう
0782デフォルトの名無しさん
2008/08/24(日) 01:57:38>自動でやるのは無謀以外のなにものでもない
>自動判別で切り分けろって話だろ？
そう、その通り。無理だ。それを判らず、文書のコード移行しているから
確実に後で（２０年ぐらい？）検索/UCSで問題が出てくる。
俺にどないせぇーちゅうねん...（泣き
0783デフォルトの名無しさん
2008/08/24(日) 06:30:430784デフォルトの名無しさん
2008/08/24(日) 09:37:300785デフォルトの名無しさん
2008/08/24(日) 09:43:43表現に言語情報が利用されていることがあるだけ。
多言語の混在表現は別のレイヤーで行うべき事。
文字そのもので言語を表現するのは難しいから。
最低でも文字の連である必要がある。
理想は構造化テキスト。
0786デフォルトの名無しさん
2008/08/24(日) 09:52:560787デフォルトの名無しさん
2008/08/24(日) 11:36:2320年後ぐらいなら特定の分野に特化したものなら
実用的なAIも十分実現可能な範囲だと思うぞ。
0788デフォルトの名無しさん
2008/08/24(日) 12:22:36>混在表現は別のレイヤーで行うべき
これを理解できる人は少なく、又はそれを処理できるプログラムでまともなのを見たことが（ry
ユーザから見れば、（IME Shift+Space等で）入力方式選択の時点で既に言語選択の仕事は終わっていると思われていることがある。
入力装置→InputMethod→文字コード で、IMEngineが中文、日本語と違うのに、結果行き着く文字コードが同じってことは
情報が取りこぼれしてるから、後から別レイヤにしたくてもできなくなる。(いっそJIS2022JPの方が判定し易いという皮肉つきだ)
コードポイントを別にしてくれたのなら、検索の時でも言語別に対応できるのだが(ry
愚痴をきいてくれて、あり(ry
0789デフォルトの名無しさん
2008/08/24(日) 12:57:03とりあえずお前さんがいま扱ってる真の問題領域は文字コードなんかじゃない。
形態素解析とか人工知能なんかのスレへ逝け。
0790デフォルトの名無しさん
2008/08/24(日) 13:16:10>入力装置→InputMethod→文字コード で、IMEngineが中文、日本語と違うのに、結果行き着く文字コードが同じってことは
>情報が取りこぼれしてるから、
普通は、行き先に言語設定だとかフォント設定だとかがあるんじゃないの?
ワープロだとか、検索エンジンだとか。
ウェブ検索で英語を入力しても日本語のサイトだけひっかかって欲しいときとかもあるし。
まどのみち、これ以上は国際化のスレとかかな?
0791デフォルトの名無しさん
2008/08/24(日) 13:27:32> 表現に言語情報が利用されていることがあるだけ。
多くは国情報だね。
言語情報もあるけどね。
0792デフォルトの名無しさん
2008/08/24(日) 23:57:28思うのだが。
「その他1言語」の変更の際にプログラムの改修が少なくなっただけ。
0793デフォルトの名無しさん
2008/08/25(月) 00:05:250794デフォルトの名無しさん
2008/08/25(月) 01:30:23これが否決されずにISO規格になっていればよかったのになぁ」って事でしょ。
名前だけで中身がほぼ空のUCS-32を使って、もいちど言語情報を含んだ規格を
策定しよう、なんて話は出ないんかね。
0795794
2008/08/25(月) 01:33:08○ UCS-4
#UCS-4 は 31ビットだし
0796デフォルトの名無しさん
2008/08/25(月) 02:26:12あれじゃダメなの？
使われている場面を知らないけど。
0797デフォルトの名無しさん
2008/08/25(月) 09:41:550798デフォルトの名無しさん
2008/08/25(月) 09:55:28言語指定でも国指定でもない。
JIS X 0208にはギリシャ文字もロシア文字も含まれてる。
0799デフォルトの名無しさん
2008/08/25(月) 12:34:130800デフォルトの名無しさん
2008/08/25(月) 22:40:48http://www.unicode.org/versions/Unicode5.0.0/ch16.pdf
の16.9 Tag Charactersですな。
> The characters in this block provide a mechanism for language tagging in Unicode plain
> text. The use of these characters is strongly discouraged.
とあり、また、Unicode 5.1.0のSummaryにはTag CharactersはDeprecatedだと書かれている。
Variant tagは標準になるけど、Language tagはやはりUnicode標準とすることは望ましくない
（Unicodeの役目を超えている）という結論になったのではないかと思う。
詳しい人突っ込みよろ。
0801デフォルトの名無しさん
2008/08/25(月) 23:24:08あれはISO 2022とラウンドトリップコンバージョンをするためだけに入れられたようなもの
0802デフォルトの名無しさん
2008/08/26(火) 17:51:330803デフォルトの名無しさん
2008/08/26(火) 17:59:37どうしても言語情報が必要ならHTMLでも使えばって話になる
0804デフォルトの名無しさん
2008/08/26(火) 18:12:58あまりに簡略化されているので、
簡体字の○から●を想像することはできません。
また○には、●とは違う意味も付与されていて、
『～□△▲○■◎～』という風に使います。」
『～□△▲○■◎～』の中は中国語として、
中国語の言語タグ付けるのはこの部分だけ?
○には全部付ける?
0805デフォルトの名無しさん
2008/08/26(火) 18:20:56全部つけるべきだと思うけど、逆にそう思わない根拠はなに？
0806デフォルトの名無しさん
2008/08/27(水) 00:25:36まぁ、ここまで来ると完全にスレ違いじゃね
フォント割り当てと言語の問題で文字コードには関係なさげ
0807デフォルトの名無しさん
2008/08/27(水) 00:31:490808デフォルトの名無しさん
2008/08/27(水) 02:37:54使用文字と使用言語に因果関係が無いんだから、平文じゃどうしようもないだろ
英語として使われてるアルファベットとローマ字として使われてるアルファベットは確実に区別が出来るべきだとか考えてるの？
0809デフォルトの名無しさん
2008/08/30(土) 11:10:07苦し紛れにしても、固定長の最大の利点潰すとかあり得ない
合成文字とか基地外じゃね？
もはやuniじゃないじゃん
0810デフォルトの名無しさん
2008/08/30(土) 19:09:080811デフォルトの名無しさん
2008/08/30(土) 19:35:09当初16ｂbit固定長とかさんざん嘘吐いて宣伝してたのは事実だけどね
0812デフォルトの名無しさん
2008/08/30(土) 20:37:010813デフォルトの名無しさん
2008/08/30(土) 21:57:00正規化が必要になってまで得られる利点って何？
0814デフォルトの名無しさん
2008/08/30(土) 22:02:390815デフォルトの名無しさん
2008/08/30(土) 22:04:03Complex Scriptの文字表現はどうするの？
可能な組合せ全てにprecomposed formのcode point割当てたら
かなり愉快なことになるよ。
0816デフォルトの名無しさん
2008/08/30(土) 22:39:27何もかわらんだろ
0817デフォルトの名無しさん
2008/08/31(日) 00:05:31ひとに迷惑をかけるなという教育を全くうけていないのだと
0818デフォルトの名無しさん
2008/08/31(日) 00:50:28今更そんな事言ってるのがおかしいのか
未だにそんな糞仕様が残ってるのがおかしいのか
0819デフォルトの名無しさん
2008/08/31(日) 12:12:43どういう方法を使えばいいんでしょうか？
出来ればWindowsAPI辺りで有ればいいんですが。C/C++のコードでもいいです。
0820デフォルトの名無しさん
2008/08/31(日) 19:08:070821デフォルトの名無しさん
2008/08/31(日) 19:25:57固定長でなんでも片付くと思ってそれ以外のものを糞仕様とか言い出す頭がおかしい
0822デフォルトの名無しさん
2008/08/31(日) 19:35:300823デフォルトの名無しさん
2008/08/31(日) 20:09:23CompareStringが使えると思う。LCIDで好きに指定できるはず。
標準C/C++だとstrcollとかuse_faset<collate<wchar_t> >してcompareとかなんだろうけど、
使ったことないからよくわからん。
0824デフォルトの名無しさん
2008/08/31(日) 23:28:49固定長と可変長の混在ついて糞と言ってるんだが
0825819
2008/09/01(月) 01:07:36並べるべきだとは思いますが。
逆に、Unicodeにスタンダードな並べ方があれば、それに従うのがいいかなと思うのですが。
>>823
ありがとうございます。
ちなみに、文字列リストに色々な国の言語が混在している場合に、
どの国の人から見てもおかしくないように並べるってのは、
やっぱり無理ですよね？
0826デフォルトの名無しさん
2008/09/01(月) 03:00:02ナルシスト
並列
はどう並べたいんだ?
0827デフォルトの名無しさん
2008/09/01(月) 03:37:46無理です。例えばラテンアルファベットの中には
言語によって順番が変わるものもあるので。
きっちりやりたいならここが参考になるかも。
ttp://unicode.org/reports/tr10/
0828819
2008/09/02(火) 01:22:12>>827
まだあまり読めてないですが、なんか参考になりそうな感じなので検討してみます。
ありがとうございました。
0829デフォルトの名無しさん
2008/09/02(火) 07:58:210830819
2008/09/02(火) 08:30:57とりあえず、欧州系は共存必須なんですよね。頭痛い。
0831デフォルトの名無しさん
2008/09/02(火) 10:34:360832デフォルトの名無しさん
2008/09/02(火) 20:01:14たしかSQL Serverだっけか？
0833デフォルトの名無しさん
2008/09/03(水) 07:32:04* *
＊ ムリです ＋
n ∧＿∧ n
＋ (ﾖ（* ´∀｀）E)
Y Y ＊
って言っちゃいなYO!
0834デフォルトの名無しさん
2008/09/03(水) 21:37:59死ぬお、、
0835819
2008/09/04(木) 01:40:40システムに言語モードでも設けて、ユーザが選んだ言語のロケールで
並べるっていう方法で誤魔化せるかな？
0836デフォルトの名無しさん
2008/09/04(木) 06:43:380837デフォルトの名無しさん
2008/09/04(木) 08:17:57ごまかすって言うか、それが普通じゃない
0838デフォルトの名無しさん
2008/09/04(木) 21:07:55すれ違いだったらすみません
0839デフォルトの名無しさん
2008/09/05(金) 00:19:46ちょっと古いし高いけどオライリーのハリセンボンが表紙のやつとか。
ttp://www.oreilly.co.jp/books/4873111080/
あとはこれとか
『文字符号の歴史－欧米と日本編－』
ttp://www.kyoritsu-pub.co.jp/shinkan/shin0602_02.html
文字符号の歴史－アジア編－
ttp://www.cbook24.com/shop/productdetail.aspx?sku=432012040X
0840デフォルトの名無しさん
2008/09/05(金) 08:34:38おお～ありがとうございます！
ハリセンボンのやつかなりいいお値段ですね・・・
そんだけ中身がいいのかなー
検討してみます。ありがとうございました。
0841デフォルトの名無しさん
2008/09/05(金) 09:22:17ここに常駐している連中は皆持っているだろうし、内容は良いと思うが、
残念ながら出版年が古い。
もし著者に聞いても同じことを言うだろう。
今年中に改訂版が出るから、買うならそちら。
0842デフォルトの名無しさん
2008/09/05(金) 10:01:180843デフォルトの名無しさん
2008/09/05(金) 12:31:48改訂の予定があるとは知らなかった
情報をありがとう。
更に厚くなるのかな(笑)
分冊か
0844デフォルトの名無しさん
2008/09/05(金) 21:50:22ttp://www.rutles.net/books/051.html
0845デフォルトの名無しさん
2008/09/05(金) 23:41:47持ってるし、かなり参考になったが、これだけは言っておく。
誤植多すぎ。正誤表に載ってないのもまだあるぞ。
0846デフォルトの名無しさん
2008/09/06(土) 00:03:070848デフォルトの名無しさん
2008/09/06(土) 01:55:43>>838のような質問をする人間が、1万5000円も出した本に
「第三第四水準」のお話がどこにも書いてないことがわかったら
騙されたとしか思えんだろうよ。
0849デフォルトの名無しさん
2008/09/06(土) 03:22:39できれば最新情報をキャッチアップしてるやつ
0850デフォルトの名無しさん
2008/09/06(土) 17:59:51こんな物を上げてみる→正規化した後のレンダリングの悪い例。
http://aikofan.dee.cc/aikoup1/src/f1060.png
（原因はわかりきっているが、対処不能だ）
話に乗って聞いてみるが（別に意味はない）、
誰か、文字集合と言語指定の一対一の対応ができるモンは見たことないよな？
>>819 タイ語＋英語の高速文字ソートだけで論文が出せるぐらいだ、あきらめるか
ソート部を外部プラグインにでもして、後で必要に応じて対応しろ。
0851デフォルトの名無しさん
2008/09/10(水) 19:42:330852デフォルトの名無しさん
2008/09/11(木) 09:51:310853デフォルトの名無しさん
2008/09/18(木) 08:52:39最初から、欧州系パソコンで入力されたテキストって、MAPPING表でISO-8859-?系に
1対1で変換出来るものなのかな？たぶん入力に使ったソフトに拠るような気がするけど。
どういうことかと言うと、結合文字とか、正規分解？というのが有るみたいなんだけど、
UnicodeテキストをISO-8859-?に変換するにはどうすればいいのかな、ということなんだが。
ライブラリを使うのも手なんだが、簡単に変換出来るなら自力で実装したいんで。
0854デフォルトの名無しさん
2008/09/18(木) 22:43:01>ライブラリを使う
0855デフォルトの名無しさん
2008/09/18(木) 23:39:560856853
2008/09/19(金) 01:22:01分かった、ありがとう。
0857デフォルトの名無しさん
2008/09/20(土) 02:14:250858デフォルトの名無しさん
2008/09/20(土) 08:37:120859デフォルトの名無しさん
2008/10/02(木) 16:00:180860デフォルトの名無しさん
2008/10/02(木) 21:03:440861デフォルトの名無しさん
2008/10/02(木) 23:39:530862デフォルトの名無しさん
2008/10/03(金) 00:37:220863youto
2008/10/03(金) 01:08:19.................../雲の流れる様子のソフト/
................#.............#............dotdotdotdotdot
begin
clear
end#ecs#...ENTERzonedclick,UNIBAC####OS2......dotdotdot
begin
..............dotdotdot
...............#dotdotdotdot
/modeprienfathis:mode2BASICyoutoSyntacsErrmode2clear
/Sysntacs all clear/
0864デフォルトの名無しさん
2008/10/03(金) 23:10:11オーディンだと思い出すのに数十秒かかった
0865デフォルトの名無しさん
2008/10/09(木) 03:24:57JustSystemが消えて、日本の企業0になってる。
0866デフォルトの名無しさん
2008/10/16(木) 22:26:47まあ現状追認のためにはそうするしかないだろうけど
http://d.hatena.ne.jp/NAOI/20080718
あとこの20字をIVSにねじ込んで独立した符号位置の追加提案なしで済ませたいんだろうけど
ますますカオスに…
0867デフォルトの名無しさん
2008/10/17(金) 20:09:56http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg31/IRGN1499P01-20.pdf
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg31/IRGN1499P21-40.pdf
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg31/IRGN1499P41-60.pdf
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg31/IRGN1499P61-66.pdf
http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg31/IRGN1499Mapping.txt
互換漢字2,621字の追加提案
日本NBはIVSと全面戦争する気満々ですねｗ
0868デフォルトの名無しさん
2008/10/17(金) 21:47:500869デフォルトの名無しさん
2008/10/18(土) 13:23:430870デフォルトの名無しさん
2008/10/18(土) 21:58:430871デフォルトの名無しさん
2008/10/19(日) 00:03:23ア行のエは平仮名は現在の「え」と同じ、片仮名は「ラ」の横棒を丶に変えたような字
ヤ行のエは片仮名は現在の「エ」と同じ、平仮名は「に」を続けて書いたような字だったらしい。
これらはゐゑヰヱよりも遥か前に廃れてしまったんだってさ。
0872デフォルトの名無しさん
2008/10/19(日) 02:02:020873デフォルトの名無しさん
2008/10/19(日) 06:25:41しかもそのwikipediaには出典書いてないし。
0874デフォルトの名無しさん
2008/10/21(火) 00:18:54やっとかよ。
拡張組も一緒に提案してくれ。
CONTEMPORARY LITHUANIAN LETTERSはUSIと一緒に提案されてたんだから。
0875デフォルトの名無しさん
2008/10/21(火) 01:07:46なんだこりゃ。
なぜIVSに統合せずにcompatibility ideographs?
0876デフォルトの名無しさん
2008/10/21(火) 06:28:09http://slashdot.jp/~yasuoka/journal/451203
こういうことらしい。個人名は出てないけど安岡センセイが関わってることは確実だろうし。
率直に言って安岡センセイが何言ってるのかわけわかりませんが、つーか言いがかり
としか思えないが。
一番恐れているのは
互換漢字を提案 ← 今ここ
↓
当然ながら却下される
↓
安岡センセイがへそを曲げて、提出そのものを取り下げる(もちろんIVSに再提出などしない)
日記でくだを巻く
というパターン。そうなったらAdobeがこれらをAdobe Japan1-7に収録でもしてくれないと
絶望的。
0877デフォルトの名無しさん
2008/10/21(火) 07:02:49「こと」の合字ってU+30FFじゃなくて?
「住基で必要」という理由で互換漢字の追加提案するなら同様の理由で変体仮名が来ても
おかしくはないな
0878デフォルトの名無しさん
2008/10/21(火) 07:34:49お前がやれ > 再提出
0880デフォルトの名無しさん
2008/10/22(水) 00:18:00と
みたいな
0881デフォルトの名無しさん
2008/10/22(水) 10:42:49ttp://www2.tron.org/set10.html
なぜか ttp://www2.tron.org/repertoire.html には無いが（さぼってんのか？）
つつけば連中が何を典拠にしたか出てくるんじゃね？
0882デフォルトの名無しさん
2008/10/24(金) 18:33:530883デフォルトの名無しさん
2008/10/24(金) 20:39:20無ければ、統計判断。
0884デフォルトの名無しさん
2008/10/24(金) 20:43:410885デフォルトの名無しさん
2008/10/24(金) 21:34:38文字コードの判別やってるからよかったら参考にしてくれ。
やってることは >>883 に上がってるように BOM や統計判断、それから 0x00 の
出現の有無およびその位置なんかを手掛かりに判断してます。
あと、どうしてもわからない場合は、奥の手で渡されたテキストが HTML か
なにかであると仮定し、どこかに文字エンコードの指定がずばり記述されてないか
探したりといったインチキなことまでやってます。
0886デフォルトの名無しさん
2008/10/25(土) 21:54:100887デフォルトの名無しさん
2008/10/27(月) 02:47:21什器台帳のかなはひでーな。
あれはもはや文字ですらないよ。
なんであんなもんに貴重な番号を振ってるんだか・・・
0888デフォルトの名無しさん
2008/10/27(月) 03:05:47漢字にも方言がいっぱいあるんですねえ・・・
方言に独自の番号を振ると日本語は崩壊します。
0889デフォルトの名無しさん
2008/10/27(月) 03:12:110890デフォルトの名無しさん
2008/11/02(日) 04:18:440891デフォルトの名無しさん
2008/11/02(日) 08:32:58#include<stdio.h>
#include<stdlib.h>
#include<locale.h>
int main() {
char ch[] = "Kitty on your lap";
wchar_t wch[] = L"Kitty on your lap";
setlocale(LC_ALL, "");
printf("char 型文字列 = %d¥n%s¥n" , sizeof ch,ch);
printf("wchar_t 型文字列 = %d¥n%s¥n" , sizeof wch,wch);
return 0;
}
char 型文字列 = 18
Kitty on your lap
wchar_t 型文字列 = 72
という実行結果が得られるんですが、
うまくwchar_t型のKitty on your lapを出力するには
どうすれば良いのでしょうか?
0892デフォルトの名無しさん
2008/11/02(日) 09:37:45ます環境を書いて質問する。
0893デフォルトの名無しさん
2008/11/02(日) 09:59:55なんか試行錯誤しているうちに、いろいろまざってしまいました。
私はC言語の本を一冊読み終えた程度の初心者で、
初めて日本語を扱うプログラムを書いてみようと思いトライしている最中です。
環境はhp-uxです。
ロカールはLANG=ja_JP.utf8です。
gccは
Using built-in specs.
Target: hppa2.0w-hp-hpux11.11
gcc バージョン 4.2.3
です。
まず最初に、サンプルコードの通り、
#include <stdio.h>
#include <stddef.h>
#include <locale.h>
#include <wchar.h>
int main()
{
wchar_t *nihon = L"あいう";
setlocale(LC_ALL,"");
wprintf(L"%s\n", nihon);
return 0;
}
とやりましたが、コンパイルに成功しても、表示されませんでした。
そこで、いろいろ調べていると、
wprintf(L"%ls\n", nihon);や
printf("%ls\n", nihon);
とやると成功することがわかりました。
わからないところは、なぜ、本に書いて有るとおりに
プログラムを書いても表示されなくて、
フォーマットに%lsを指定すると成功したのでしょうか?ということです。
0894デフォルトの名無しさん
2008/11/02(日) 10:01:37%ls
0895デフォルトの名無しさん
2008/11/02(日) 10:37:48その本が間違っているからでは？
0896デフォルトの名無しさん
2008/11/02(日) 12:09:070897デフォルトの名無しさん
2008/11/02(日) 12:20:32規格すら読まずに書かれている糞本の名前を晒せ。
http://docs.hp.com/ja/B2355-60128/index.html
すら読まんお前もどうかと思うが。
0898デフォルトの名無しさん
2008/11/02(日) 12:43:17スレッドの趣旨もわからないような池沼ならどんなばかげたことをやっていても不思議はない。
0899デフォルトの名無しさん
2008/11/02(日) 21:12:19＞当然ながら却下される
却下されなかった(JTC1/SC2/WG2/N3554R)
N3530はN3525と抱き合わせで議論されることが決まった
つまり互換漢字でありながら同時にIVSも振られる
0900デフォルトの名無しさん
2008/11/02(日) 22:48:07現時点ではIRGと全NBと全liaisonに意見を求めただけ。
0901デフォルトの名無しさん
2008/11/03(月) 08:42:250902デフォルトの名無しさん
2008/11/06(木) 00:41:38UniscribeもIVSに対応してなかった(´・ω・`)
まあVistaのときも最初のベータではメイリオがJIS2004字形じゃなかったりしたから
今後に期待か。
# IVS対応はDirectWriteのみとかだったらやだな
0903デフォルトの名無しさん
2008/11/06(木) 00:49:53議論の末採用は見送られるだろJKと思ってるわけだが
0904デフォルトの名無しさん
2008/11/06(木) 01:28:59というか、IVS対応など、特に日本語環境での希望事項は、今のうちに
DirectWriteやWindows 7のチームにWish出しまくったほうがいい。
0905デフォルトの名無しさん
2008/11/06(木) 12:32:570906デフォルトの名無しさん
2008/11/06(木) 12:47:07←→wcs=wide character string
0907デフォルトの名無しさん
2008/11/06(木) 12:50:340908デフォルトの名無しさん
2008/11/06(木) 13:36:51文字列の特定の部分のみ変換する場合はどうすればよいでしょうか？
0909デフォルトの名無しさん
2008/11/06(木) 14:25:14iconv(3)なら変換するサイズ指定できるが。
0910デフォルトの名無しさん
2008/11/06(木) 16:43:02一般的に「却下」は門前払い、審理を行なった上で退けるのは「棄却」やね。
0911デフォルトの名無しさん
2008/11/06(木) 18:22:530912デフォルトの名無しさん
2008/11/06(木) 22:04:14広辞苑
明鏡
0913デフォルトの名無しさん
2008/11/07(金) 20:53:430914デフォルトの名無しさん
2008/11/07(金) 23:02:11直後に支持する文字集合の改訂番号指定です。
0915デフォルトの名無しさん
2008/11/08(土) 00:17:10ようやくわかりました。ありがとうございます。
0916デフォルトの名無しさん
2008/11/08(土) 08:15:400917デフォルトの名無しさん
2008/11/08(土) 08:40:31ただFormal Syntaxで定義されてないのにも関わらず、
The JIS X 0208 standard was revised in 1990, to add two characters at
the end of the table. Although ISO 2022 specifies special additional
escape sequences to indicate the use of revised character sets, it is
suggested here not to make use of this special escape sequence in
ISO-2022-JP text, even if the two characters added to JIS X 0208 in
1990 are used.
とBackground Informationでは「ここでは推奨しない」と微妙な表現w
「使えないことにした」と書けば良かったのに。
0918デフォルトの名無しさん
2008/11/08(土) 12:39:52上の環境でSJIS、JIS、EUC、UNICODE(UTF-16)、UTF-7、UTF-8など
文字コードを判別する方法を教えてくだしあ
0919デフォルトの名無しさん
2008/11/08(土) 12:47:03それらの文字コードとして成り立っているかどうかをチェックし、
最後まで残ったものが候補。
候補が複数残った場合は判別失敗。
候補が残らなかった場合はその他の文字コード、もしくはバイナリ。
候補が１つ残った場合はその文字コードかバイナリ。
バイナリかどうかチェックするため、候補が１つに絞られても
一定バイト数チェックはした方がいい。
0920デフォルトの名無しさん
2008/11/08(土) 13:48:410921デフォルトの名無しさん
2008/11/08(土) 14:16:47>>885
0922デフォルトの名無しさん
2008/11/16(日) 02:06:022. 公開されているソースコードを流用する。
0923デフォルトの名無しさん
2008/11/16(日) 04:31:26>>918は
1. どのライブラリを使えばいいか。
2. どこに流用できるソースコードが公開されてるか。
を聞いてるんだろ
そんな無意味なレスして、馬鹿なの？
0924デフォルトの名無しさん
2008/11/16(日) 09:38:34mlang http://msdn.microsoft.com/ja-jp/library/aa767865(en-us).aspx
iconv http://www.gnu.org/software/libiconv/
ICU http://www.icu-project.org/
2. iconv, ICU のソース
文字コード判別が出来てオープンソースのテキストエディタを探す
>>885
0925デフォルトの名無しさん
2008/11/16(日) 16:56:52お前こそちゃんと文章を読め。
1,2って番号ついてるだろ。自分で判別処理書くより、なるべく
ライブラリを使った方が早いってこと。
だいたいそう思うだったら、お前が紹介すればいいじゃんか。
どうせ文句ばっかつけて何も知らないんだろ。
馬鹿はお前だ。
0926デフォルトの名無しさん
2008/11/16(日) 17:24:41だからどんだけ馬鹿なの？
>>918の書き方を見て、>>918が自分で判別コード書きたいって言ってるようにしか見えないんだ？
何でそんな馬鹿に育っちゃったの？ねぇ、なんで？
0927デフォルトの名無しさん
2008/11/16(日) 18:21:57>>918が自分で判別コード書きたいと言っているように見えたとは
言ってないだろ。
>>918の質問に対して自分で判別コード書く場合のレスが続いたから
それよりもライブラリを使った方が早いって言ったんじゃんか。
0928デフォルトの名無しさん
2008/11/16(日) 18:42:05だーかーらーライブラリ使ったほうが早いなんて常識だろ
自明だっつってんの
0929デフォルトの名無しさん
2008/11/16(日) 19:49:52だから、
それなのに自分で判別コード書くレスしかないんで、
ライブラリの方に話をもってこようとして書いたんだよ。
でも、お前と違って、ちゃんと回答している人に対して
あんまり否定的な言い方したら、失礼かなって思って、
わざと分からないように書いたの。
お前にむかついて、書いちゃったんで、もう意味ないけど。
0930デフォルトの名無しさん
2008/11/16(日) 21:02:08失礼な奴だな
0931デフォルトの名無しさん
2008/11/16(日) 21:54:44ライブラリは使ってないだろ。
0932デフォルトの名無しさん
2008/11/17(月) 13:58:540933デフォルトの名無しさん
2008/11/18(火) 02:56:15ICUは文字コード変換というより、国際化全般向けのライブラリ。
日本語対応の正規表現とか使えるようになるのが利点じゃないか
と思う。
ただ、文字コード変換とかだけに使うなら、ちょっと大物すぎる
かな。
0934デフォルトの名無しさん
2008/11/18(火) 11:17:02ICUのAPIを調べるのは。
真面目にやり出すときりがないって事が分かる。
0935デフォルトの名無しさん
2008/11/18(火) 11:49:140936デフォルトの名無しさん
2008/11/18(火) 11:51:12バカにいちいち付き合ってられん
0937デフォルトの名無しさん
2008/11/18(火) 11:56:270938デフォルトの名無しさん
2008/11/18(火) 12:22:330939デフォルトの名無しさん
2008/11/18(火) 12:59:030940デフォルトの名無しさん
2008/11/19(水) 14:25:08安岡センセイ、JTC1/SC2/WG2/N3530に御不満らしい
http://slashdot.jp/~yasuoka/journal/458659
0941デフォルトの名無しさん
2008/11/19(水) 14:50:090942デフォルトの名無しさん
2008/11/19(水) 15:58:59: (コロン)とかはフォルダ名につかえないけど
どうやって代用しようか？
D:\tool\53: ■ ＨＵＮＴＥＲｘＨＵＮＴ
D:\tool\゜・:,。*:テニスの王子様..。o○
とか
0943941
2008/11/19(水) 16:00:290944デフォルトの名無しさん
2008/11/19(水) 16:25:11つ URLエンコードに準ずる
0945デフォルトの名無しさん
2008/11/19(水) 20:10:34どゆこと？
0946デフォルトの名無しさん
2008/11/19(水) 20:18:16じゃないかね。
@なら%40とか。
まぁbase64とかpunycodeとか他にもやり方あるし、好きなの使えば？
…てかそもそもエスケープ出来ないんだっけ？
0947デフォルトの名無しさん
2008/11/19(水) 21:00:38(エスケープしなくてもそうなる可能性はあるが)
0948デフォルトの名無しさん
2008/11/19(水) 23:11:370949デフォルトの名無しさん
2008/11/19(水) 23:22:020950デフォルトの名無しさん
2008/11/20(木) 05:45:540951デフォルトの名無しさん
2008/11/20(木) 05:54:49うちの会社の連中、ファイル名とかフォルダ名に⑲とか⑳とか、算用数字を
丸で囲んだ文字をけっこう使ってる人が多いのね。19年度とか、20年度とかを
表すために。例えば ⑲東京支店決算詳細.xlsとか。
で、21とか、22とかの算用数字を丸で囲んだ文字は、用意されていない、と。
たいていの人は、文字変換しようとして、字が用意されていないことに
気づいて、（いったんは憤る人もいるかもしれないけど）諦めると思う。
(21)東京支店決算詳細.xlsとか、いくらでも表現のしようはあるから。
ただ、誰かが外字エディタでも使って、フォントを作って、ShiftJIS
（別な文字コードでもいいけど）のどこかの空いているコードにマッピングして…
しまいにはそれをファイル名やフォルダ名に使い出したときの影響、って
そういう字をインストールしていないWindowsパソコンから見たときに
・東京支店決算詳細.xlsのように、文字化けする、ってだけなのかしら。
そういう創作された字を含んだファイルとか扱ってるうちに、
Windowsエクスプローラとか、壊れたりしないのかしら。
0952デフォルトの名無しさん
2008/11/20(木) 07:01:390953デフォルトの名無しさん
2008/11/20(木) 07:12:090954デフォルトの名無しさん
2008/11/20(木) 07:14:13Unicodeには丸50まであるし、CIDフォントには丸100までのグリフが入ってる。
0955デフォルトの名無しさん
2008/11/20(木) 07:15:36全てを忘れてとりあえず寝ろ
話はそれからだ
0956デフォルトの名無しさん
2008/11/20(木) 07:30:11元はJIS X 0213な。
CIDはAdobe-Japan1-4のやつな。
0957デフォルトの名無しさん
2008/11/20(木) 07:35:030958デフォルトの名無しさん
2008/11/27(木) 20:17:28http://sites.google.com/site/unicodesymbols/Home/emoji-symbols
0959デフォルトの名無しさん
2008/11/27(木) 23:29:49いやまじで。
0960デフォルトの名無しさん
2008/11/27(木) 23:35:50実際組み込まれるのはいつの話だよってことだ
0961デフォルトの名無しさん
2008/11/28(金) 00:12:08U+2600～U+27FFあたりに似たようなものがある絵文字はそれと統合するべきだな。
あと確か俺の使ってるソフトバンクの携帯には色の違うハートマークがあったな。
これらは色が違うだけだがそういうのはどうするんだ?Unicodeでは色の指定は無いはずだが。
0962デフォルトの名無しさん
2008/11/28(金) 10:26:43まぁ、縁がないからどうでもいいですけど
0963デフォルトの名無しさん
2008/11/28(金) 12:47:50エンコーディングがUTF-8で文字集合が0208のウェブページなら
見られなくもないとかそういうレベルだよな。iモードとかは。
0964デフォルトの名無しさん
2008/11/28(金) 17:36:560965デフォルトの名無しさん
2008/11/28(金) 18:57:10どうやって判定するのでしょうか？
0966デフォルトの名無しさん
2008/11/29(土) 03:42:18ちょっとアホな方法だけど、%TEMP% フォルダの下で実際に作ってみて、
本当に作成できるかどうかで判断するのが一番確実。
0967デフォルトの名無しさん
2008/11/29(土) 04:55:27いやいや、それが一番賢い方法だよ、残念な事に
アクセス権でファイルが実際に作れるかとか、名前制限とかは実際作るのが一番手っ取り早く確実
それ以外の手段は、100倍のコストをかけても結局不確かな物でしかないからな
0968デフォルトの名無しさん
2008/11/29(土) 07:19:550969デフォルトの名無しさん
2008/11/29(土) 07:37:39具体的な話になるとな～んにも答えられないんですね
0970デフォルトの名無しさん
2008/11/29(土) 07:38:42どこのドキュメントか示されないと読みようがない
0971デフォルトの名無しさん
2008/11/29(土) 09:11:46というか、お前こそドキュメント読んでないだろ。
そのへんはドライブのフォーマットなんかにも依存する話だから、
厳密には個々の環境に依存する話になっちゃうから
アンドキュメントな領域なんだよ。
0972デフォルトの名無しさん
2008/11/29(土) 09:18:00その辺は%TEMP%じゃしょうがねえしな。
http://www.ipa.go.jp/security/awareness/vendor/programming/b08_01_main.html
あたりもイヤらしいが、そもそも板違いだろ。> Windows
0973デフォルトの名無しさん
2008/11/29(土) 10:37:210974デフォルトの名無しさん
2008/11/29(土) 13:24:390975デフォルトの名無しさん
2008/11/29(土) 19:59:23あれらのドキュメント読んで全うに実装はじめようと考えたなら、今すぐ他業種に行け公害野郎
0976デフォルトの名無しさん
2008/11/29(土) 20:24:25私にもありました
0977デフォルトの名無しさん
2008/11/29(土) 21:37:57変換元バッファと変換先バッファのサイズをどのくらいにして変換すべきですか？
0978デフォルトの名無しさん
2008/11/29(土) 21:39:370979デフォルトの名無しさん
2008/11/29(土) 21:43:24何故？
0980デフォルトの名無しさん
2008/11/29(土) 21:51:39どうせキャッシュされるんだよ
1byteづつ読むよりは256とか512とかやれば関数のオーバーヘッドが軽減されるかなって程度
もちろん全部よんでもいいがね
0981デフォルトの名無しさん
2008/11/29(土) 22:35:21実測する以外に方法はない。
俺のだと32kBか64kBが良かった。
とくに2kBを切ると一回ごとのバラツキが大きくなって
最悪値が平均の5倍とかになったりした。
大きい方はバラツキはそれほどじゃないが
パフォーマンスがゆっくり劣化していった。
0982デフォルトの名無しさん
2008/11/29(土) 23:32:01バラつきとは？
文字コード変換に使ったのは自作関数ですか？
0983デフォルトの名無しさん
2008/11/30(日) 00:02:490984デフォルトの名無しさん
2008/11/30(日) 00:18:48関数は？自作？
0985デフォルトの名無しさん
2008/11/30(日) 01:51:29関数は関係ねーよボケ
これはディスク読み込みパフォーマンスの話だろ
死ねば？
0986デフォルトの名無しさん
2008/11/30(日) 02:25:18まぁキレるなよ（笑）
0987デフォルトの名無しさん
2008/11/30(日) 02:58:250988デフォルトの名無しさん
2008/11/30(日) 03:19:480989デフォルトの名無しさん
2008/11/30(日) 03:20:45win32apiの変換関数みたいなのだとテキストが全部入るバッファを確保する以外にないね
0990デフォルトの名無しさん
2008/11/30(日) 08:53:58streamとして処理した方が汎用性は高いが性能は出し難い。
0991デフォルトの名無しさん
2008/11/30(日) 22:40:25http://pc11.2ch.net/test/read.cgi/tech/1228052369/
0992デフォルトの名無しさん
2008/11/30(日) 22:45:08【ネット】日本の絵文字が“世界進出”へ…グーグル（Google）が標準化提案 [08/11/29]
http://anchorage.2ch.net/test/read.cgi/bizplus/1228047071/
0993デフォルトの名無しさん
2008/12/01(月) 00:09:320994デフォルトの名無しさん
2008/12/01(月) 15:04:35それ、安岡センセイが提唱してたヤツだろ。
どうしてGoogleなんだ？
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/publications/JST2007-5.pdf
0995デフォルトの名無しさん
2008/12/01(月) 17:35:18http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html
将来は全部google検索で利用できるようにするつもりとか。
0996デフォルトの名無しさん
2008/12/02(火) 11:13:19何も提唱してないじゃん、それ。
0997デフォルトの名無しさん
2008/12/02(火) 15:36:260998デフォルトの名無しさん
2008/12/02(火) 15:36:580999デフォルトの名無しさん
2008/12/02(火) 15:37:281000小倉優子 ◆YUKOH0W58Q
2008/12/02(火) 15:37:581001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。