- 1 名前：デフォルトの名無しさん [03/09/10 16:04]
- 文字コード変換について語りましょう♪
- 610 名前：デフォルトの名無しさん mailto:sage [04/03/24 01:02]
- JIS の半角カナって、M$ の仕様拡張じゃなかった？
- 611 名前：デフォルトの名無しさん mailto:sage [04/03/24 01:13]
- おまえはこのスレにいる資格なし
- 612 名前：デフォルトの名無しさん mailto:sage [04/03/24 09:27]
- いまどきこんなDQNエンコード使ってるほうが悪いんだよ
- 613 名前：デフォルトの名無しさん mailto:sage [04/03/24 09:50]
- >>608
X0201右側って何? 片仮名用図形文字集合のこと?
- 614 名前：デフォルトの名無しさん mailto:sage [04/03/24 10:06]
- > ESC ( I の後は X0201右側が G0 に designate されているから、
> 7bitならX0201右側しかない。
これ以前にG1〜G3がGLに呼び出されていれば
そこに何が入っているかによる。
ESC 2/8 FでG0に何が指示されようと関係ない。
(一意な符号化が要求されている場合は使用可能な文字が
変わるかもしれないけど)
- 615 名前：デフォルトの名無しさん mailto:sage [04/03/24 10:18]
- >>614
> これ以前にG1〜G3がGLに呼び出されていれば
> そこに何が入っているかによる。
そうだった。SOとかLS2/LS3が先行してる場合があるか。
>>613
そのつもり。
- 616 名前：デフォルトの名無しさん mailto:sage [04/03/24 10:26]
- >>615
7bitで「右側」という表現に違和感を感じたので。
確かにX0201に規定されている8ビット符号は片仮名をGRに
呼び出すものしかないけど
- 617 名前：デフォルトの名無しさん mailto:sage [04/03/24 22:29]
- >612 悪いな。IRC関連なんだよ
- 618 名前：デフォルトの名無しさん mailto:sage [04/03/29 10:48]
- IRCの日本語文字コードってISO-2022-JPじゃなかったっけ?
- 619 名前：デフォルトの名無しさん [04/03/30 01:46]
- age
- 620 名前：デフォルトの名無しさん [04/05/05 19:26]
- BOMありUTF-8などというばかげたものが禁止されていないのはなぜですか？
- 621 名前：デフォルトの名無しさん [04/05/05 20:13]
- >>620 UTF-8を自動識別できるから(ｗ
ASCII/ANSI互換がメリットなのだから、BOMは付けるべきではないというのが
一般論。でも付けて違反とはISO 10646にもRFCにも規定はないですね
Use caseによるんじゃないですか？
XMLやHTMLなら、encodingパラメータでコードセットを取得できるので不要、
でもそうでないものやencoding指定が無い場合は識別方法が7fhコードが
含まれているかとかあやふやな、確実に特定する手段無いし・・・
それはS-JIS、GB 2312、Big5、KS C5601(KS X1001)、CNS 11643等でも
同様ですが
- 622 名前：デフォルトの名無しさん mailto:sage [04/05/05 20:14]
- >>620
Byte Order Mark の何たるかをご存知でない
お間抜けちゃんがこの業界を仕切っているからでぬるぽ。
- 623 名前：デフォルトの名無しさん mailto:sage [04/05/05 22:54]
- いきなりレベルの低い話になりますが、〜問題は皆どうやって
回避してますか？
- 624 名前：デフォルトの名無しさん mailto:sage [04/05/06 07:38]
- ~→〜のこと?
- 625 名前：デフォルトの名無しさん mailto:sage [04/05/06 07:59]
- WAVE DASH(〜)が\u301cにマッピングされる問題でしょ。
- 626 名前：625 mailto:sage [04/05/06 08:02]
- 失礼、「U+301C」の方が良いですね。
- 627 名前：デフォルトの名無しさん mailto:sage [04/05/06 10:13]
- iconvもglibcも使うときはSJISじゃなくてCP932を指定してる。
emacsもCP932変換テーブルを作って、さらにutf-8 decode部分を書き換え。
実際どうなんだろう、SJISが必要な人って、どれぐらいいるんだろう？
大部分の人はCP932が欲しいわけで、SJISじゃないと思うのだけど、
そうでもない？
- 628 名前：デフォルトの名無しさん mailto:sage [04/05/06 11:28]
- >>621
> でも付けて違反とはISO 10646にもRFCにも規定はないですね
どういう場合に付けてはいけないか(というか付いてたときZWNBSP
ではなくBOMであると解釈してはいけないか)はRFC 3629で
明確化された
- 629 名前：デフォルトの名無しさん mailto:sage [04/05/06 13:54]
- >>627
Unicode→SJISで、「どっちが来てもいいように」対応することは可能だけど
SJIS→Unicodeだと、どっちにするか決めないといけない
という問題がありますね。
それと、OracleのNLSのような、ハック不可能な領域だとかなりどうしようも
ない気が。
そういえば、JavaはもうShift_JISがWINDOWS-31JじゃなくてSJISのエイリアス
になってるんでしたっけ。これ、困る人が多いんじゃないのかなあ。
- 630 名前：デフォルトの名無しさん mailto:sage [04/05/06 16:46]
- > Unicode→SJISで、「どっちが来てもいいように」対応することは可能だけど
U+005CとかU+007Eが来たときどう変換する?
Shift_JISがX0208の附属書1どおりじゃなくて
1バイト部分はASCIIであるとみなせば対応は可能だけど
- 631 名前：デフォルトの名無しさん mailto:sage [04/05/06 20:09]
- >>630
実際問題として、ASCIIと見なさないと、使い物にならないでしょう。
\にどういうグリフが当てられていようと、日本人もそれをエスケープ記号や
パスのデリミタとして(バックスラッシュと同じ意味で)使っているんだから、
他のコードポイント割り当てたら、はっきり言って実用上はお話にならない。
従来通りFontの問題として対応するのが「今のところは」現実的じゃないの。
- 632 名前：デフォルトの名無しさん mailto:sage [04/05/06 23:53]
- エスケープ記号はともかくパスのデリミタはWindowsの場合だから
それは単にエンコーディングとしてCP932を想定しているというだけの
話だと思うんだけど。
実際Appleの変換表は円記号をU+00A5に割り当てるし
- 633 名前：デフォルトの名無しさん mailto:sage [04/05/07 00:26]
- そのエスケープ記号が大問題だと思うが。
世の多くのプログラミング言語だのTeXだのシェルだのにおいて
メタキャラクタとして使われてるんだから。既存のソースの類が突然にして
コンパイル不能な屑の山になるでしょ。
無論DOS, Windowsユーザにとっちゃパス区切りであることの方が
さらに問題だが。
- 634 名前：デフォルトの名無しさん mailto:sage [04/05/07 03:27]
- >>631
そりゃ、プログラマ至上主義だね。
普通の文書に半角円記号使ってた人は困る。
- 635 名前：デフォルトの名無しさん mailto:sage [04/05/07 08:16]
- >>634
そしてTerminal上でバックスラッシュと円記号の混乱でうめき、SafariでWebの円記号がバックスラ
ッシュになってもがくOSXユーザが湧いてでてくると。
- 636 名前：デフォルトの名無しさん mailto:sage [04/05/07 09:14]
- >>632
Mac OS Xだと、Shift JISのprogramを、
UTF-8で保存して、REVERSE SOLIDUS(0x5c)のつもりが、
YEN SIGN(0xa5)になって悩んでいる学生さんが、
既にいらっしゃいますよ。
Terminal.appで、YEN SIGNが出力されていても、(\nとか)
教科書にYEN SIGN書いてあんだもん、初級の人はわけが分からないよね。
- 637 名前：デフォルトの名無しさん mailto:sage [04/05/07 09:48]
- Safariの ~ が 〜 になっちゃうよ問題とか。
- 638 名前：デフォルトの名無しさん mailto:sage [04/05/07 09:53]
- 「どっちが来てもいいように」対応するというのも
そんな簡単じゃない。
たとえばPARALLEL TOとDOUBLE VERTICAL LINEしか違わない
名前のファイルが同じディレクトリにあると、どちらか片方しか
開けないとかどっちが開かれるかわからないとか、
どっちが作成されるか分からないとか。
そもそも両者を同一視したいというのは日本だけの都合であって、
たとえばGBKには両方とも存在するから勝手に同一視されたら
多分困る。
- 639 名前：デフォルトの名無しさん mailto:sage [04/05/07 12:57]
- <item1 name="セーター" price="\500" image="c:\image\item1.jpg">
みたいなのをきちんと utf-8 にする処理は多言語対応では難しいよね・・・
- 640 名前：デフォルトの名無しさん mailto:sage [04/05/07 13:15]
- >>639
> <item1 name="セーター" price="\500" image="c:\image\item1.jpg">
と記述するcoding systemがyenとbackslashを区別できていれば問題ないし、
区別できていないのなら、それはコード変換とは別ドメインの問題だろ。
- 641 名前：デフォルトの名無しさん mailto:sage [04/05/07 13:24]
- 見た感じXMLっぽいがそれなら
price="¥500"
と書くことで曖昧さがなくなる
- 642 名前：デフォルトの名無しさん mailto:sage [04/05/07 13:33]
- >>640
Shift_JISは問題ないの?
- 643 名前：デフォルトの名無しさん mailto:sage [04/05/07 16:13]
- >>641
xml 的には後半の \ は ¥ にするや否や、というような話。スレ違いだけど。
>>640
元のコードが Shift_JIS の場合、どんな風に変換されるべき？
- 644 名前：デフォルトの名無しさん mailto:sage [04/05/07 16:56]
- >>643
後半はしたら駄目に決まってる
- 645 名前：デフォルトの名無しさん mailto:sage [04/05/08 04:06]
- ところがShift JISで書いた場合は、両方でOKなわけだ。
- 646 名前：デフォルトの名無しさん mailto:sage [04/05/08 04:07]
- 両方HALFWIDTH YEN SIGNでOKなわけだ。
- 647 名前：デフォルトの名無しさん mailto:sage [04/05/08 09:10]
- >>645
意味がわからん
「両方」って何と何のことで何が「OK」なの?
>>646
HALFWIDTH YEN SIGNなんてものはない
ただのYEN SIGNならある
- 648 名前：デフォルトの名無しさん [04/05/09 05:04]
- LightConeは?
- 649 名前：デフォルトの名無しさん mailto:sage [04/05/09 20:00]
- >>648
LightCone乙
- 650 名前：デフォルトの名無しさん [04/05/18 10:46]
- 書き込みがないな。
またLightConeが来てくれないかな。
- 651 名前：デフォルトの名無しさん [04/05/18 18:31]
- iso-8859-22って、いわゆるなに？
iso-8859-1って、いわゆるLatin1でいいの？
- 652 名前：デフォルトの名無しさん mailto:sage [04/05/19 02:37]
- 8859-22 なんてあったのか？
16までなら聞いたことがあるが。
- 653 名前：デフォルトの名無しさん [04/05/20 19:14]
- EZ端末からPOST形式でフォームをサブミットすると
x-up-destcharset=17
というのが勝手に送られるのですが、
これって何のためのものでしょうか？
- 654 名前：デフォルトの名無しさん mailto:sage [04/05/20 19:20]
- で、それがなんの関係があると？
- 655 名前：デフォルトの名無しさん [04/05/20 19:23]
- >>654
誤爆?
- 656 名前：デフォルトの名無しさん mailto:sage [04/05/20 19:24]
- >>655
残念。ちゃんとした回答。
- 657 名前：デフォルトの名無しさん [04/05/20 19:48]
- >>656
>>653への回答か? スレ違いだと言いたいのか?
- 658 名前：デフォルトの名無しさん mailto:sage [04/05/21 18:41]
- >>220 さんのページってどこですか？
- 659 名前：デフォルトの名無しさん mailto:sage [04/05/21 18:58]
- EUC補助漢字の判定 でぐぐってみたらわかりました。
使える文字コード判定ってあんまり情報ないので助かります
- 660 名前：デフォルトの名無しさん mailto:sage [04/05/22 01:41]
- >>399
UCS4で正規化すりゃ万事解決。
32ビットコードはMuleとかで先例もあるし。
- 661 名前：デフォルトの名無しさん mailto:sage [04/05/22 02:12]
- wcschrでヒットしたその位置は何文字目? という問いに
簡単に答えられない点が問題。X0208の範囲に限定するなら
そうでもないがそれならそもそも4バイトもいらん
正規化がUnicode Normalizationのことを指してるなら
UTF-8の文字数を先頭から数えても大して変わらんような…
- 662 名前：デフォルトの名無しさん [04/05/22 09:25]
- >>660
遅レス乙!
- 663 名前：デフォルトの名無しさん mailto:sage [04/05/22 21:37]
- >>660
コードポイントと文字は１対１対応ではない。
NFCで正規化しても複数コードポイントの組合せで
１文字を表すケースはいくらでもある。
- 664 名前：デフォルトの名無しさん mailto:sage [04/05/22 22:37]
- たしかに↓とか読んでると気が遠くなってくるな。
www.horagai.com/www/moji/devnag.htm
アラビア語や上の例みたいに文字を分かち書きしない言語では
「一文字」っていう単位がそもそもそれほど明確じゃないのかも。
日本語は「単語」を分かち書きしないけど
時枝文法とか文法のとらえ方次第で「単語」も変わるしそもそも
日本人は単語の区切りなんてふだん意識してないみたいな感じか。
（助詞とか）
素人なので間抜けな事いってるかも知れないが。
- 665 名前：デフォルトの名無しさん mailto:sage [04/05/22 23:31]
- >>663
というかそれはまさに>>399で言ってることそのものなわけで
文盲にマジレスしても無駄かと
- 666 名前：デフォルトの名無しさん mailto:sage [04/05/24 02:59]
- ｐｃ関係詳しい方！
ぜひこの暗号解けないものでしょうか！？
325argf493rdtr521styh075artg625agfa113ller041fsre.2122ffj7343qer7813fda
- 667 名前：デフォルトの名無しさん mailto:sage [04/05/24 08:55]
- それをこのスレにもってくる神経を疑う
- 668 名前：デフォルトの名無しさん mailto:sage [04/05/24 09:33]
- >>667
その謎を解くのだ。
- 669 名前：デフォルトの名無しさん mailto:sage [04/05/24 10:45]
- >>666
↓↓US-ASCII復号による解読結果です↓↓
325argf493rdtr521styh075artg625agfa113ller041fsre.2122ffj7343qer7813fda
- 670 名前：デフォルトの名無しさん mailto:sage [04/06/04 22:06]
- 325|argf
493|rdtr
521|styh
075|artg
625|agfa
113|ller
041|fsre
.
2122|ffj
7343|qer
7813|fda
- 671 名前：デフォルトの名無しさん mailto:sage [04/06/07 11:25]
- BASE64?
- 672 名前：デフォルトの名無しさん mailto:sage [04/06/09 06:26]
- 英大文字をまったく含まないというのは
BASE64にしては不自然すぎるな
- 673 名前：デフォルトの名無しさん mailto:sage [04/07/06 12:32]
- JISを元にした文字コードとunicodeとの変換表が複数ある状況は
なんとかならんのかね。それが正しかろうがなんだろうがとにかく
統一されてさえいれば楽に使えるのに、バラバラだからいらぬ変換
の手間がかかってわけわからん状況に。勘弁してくれよう。
- 674 名前：デフォルトの名無しさん mailto:sage [04/07/06 13:31]
- なんともならんでしょうね。
- 675 名前：デフォルトの名無しさん mailto:sage [04/07/08 04:21]
- JISは対応が存在するだけまだマシなほうですよ
Big5やKPS9566なんてそもそも変換できない場合があるし
- 676 名前：デフォルトの名無しさん mailto:sage [04/07/08 11:52]
- まあ、応用によって変換表が違うのは当然って文字の組み合わせもあるでしょう。
*→＊,×, ※など。あまりいい例じゃないからもっといいのきぼん↓
- 677 名前：デフォルトの名無しさん mailto:sage [04/07/08 16:43]
- printf("値段は \\%dです\n", Nedan);
\\は¥(¥)1文字に変換されるのが理想だし、\nはバックスラッシュとnに変換してくれないと困るし。
- 678 名前：デフォルトの名無しさん mailto:sage [04/07/08 16:49]
- もう、面倒だから\記号使うのやめよう。
printf("値段は %d円です\n", Nedan);
で良いじゃないか。
ごたごたに巻き込まれたくないPGより。
- 679 名前：デフォルトの名無しさん mailto:sage [04/07/08 21:18]
- ￥ でいいよ
- 680 名前：デフォルトの名無しさん [04/07/28 08:02]
- age
- 681 名前：デフォルトの名無しさん mailto:sage [04/07/28 08:33]
- >>679
I/Oライブラリに勝手に\に変換されたり…
最近2chでも~→〜があるみたいだし。
- 682 名前：デフォルトの名無しさん mailto:sage [04/07/28 09:10]
- 文字のことは中国人に任せときゃいいんだよ
漢字のほんの一部を借りて使ってるだけの日本人なんかに何が出来るんだ
- 683 名前：デフォルトの名無しさん mailto:sage [04/07/28 13:46]
- >>682
マッカーサーに従って、日本語で文章を書くのを止める、とか？
- 684 名前：デフォルトの名無しさん mailto:sage [04/07/28 22:02]
- >>682
アルファベットも中国人任せか?
- 685 名前：デフォルトの名無しさん mailto:sage [04/07/28 22:38]
- >>681
~→〜はSafariの悪戯だろ
- 686 名前：デフォルトの名無しさん mailto:sage [04/10/02 21:36:08]
- SJIS、EUC、JIS、UTF-8を判別するアルゴリズムを紹介しているページってどっかある？
ttp://kasumi.sakura.ne.jp/~gm/gpj/dev/tips/other/kanji.shtml
を参考にしているんだけどイマイチはっきりしないところがあるので…
- 687 名前：デフォルトの名無しさん mailto:sage [04/10/03 00:31:32]
- イマイチはっきりしないところを書いてくれないとはっきりしない。
- 688 名前：デフォルトの名無しさん [04/10/04 04:34:15]
- age
- 689 名前：デフォルトの名無しさん mailto:sage [04/10/04 13:53:50]
- ｸﾞｸﾞﾙさんのキャッシュは日本語サイトの \ を＼にするから激しく困る(`Д´)
ｸﾞｸﾞﾙさんのﾃﾞｶﾁﾝｺ！ヽ(｀Д´)ノ世界最早男！
- 690 名前：686 mailto:sage [04/10/05 02:18:46]
- 遅レスｽﾏｿ
>>687
具体的には判定箇所が具体的に書かれていないところ
例：
> 0x80 <-> 0xA0であるならばSJIS
SJISと言うことは第1バイトか？
> 0xA1 <-> 0xDFが出た場合はSJIS半角カナ・EUC全角かな・カナの強い可能性
これも第1バイト？
> 0xA1 <-> 0xFEの場合はEUCの強い可能性で0xFD・0xFEの場合はEUC(確定)
第1バイトと第2バイトの両方？
- 691 名前：デフォルトの名無しさん mailto:sage [04/10/05 02:22:48]
- 文字コード判別・変換クラスてのがあるけど
ttp://kasumi.sakura.ne.jp/~gm/gpj/dev/tips/net/txtenc.shtml
- 692 名前：デフォルトの名無しさん mailto:sage [04/10/05 08:14:19]
- >>689
これいいなあ。でもどうせなら＼ではなく、逆に全角(じゃなくてU+00A5でもい
いが)の￥にするのが正しいと思う……それはさておき。
日本語圏、とりわけShift_JIS(とMSKK的Unicode)では
\ (0x5c) が文字として意味をなさない
(コードポイントとしての機能しかない) から、仕方ないとも言えるんだよ。
Shift_JISでは0x5cはYEN SIGNという定義なんだけど、実際の使われ方は
REVERSE SOLIDUS (ASCIIでの0x5c)でもあるという状態なんだから。
EUC-JPはShift_JISと違って0x5cがREVERSE SOLIDUSなんで、EUC-JPなページの
キャッシュでは0x5cは0x5cのままになってるよ。
ああなった理由を考察すると、クロールしたデータをキャッシュとして保存する
ときはUTF-8に変換するが0x5cは0x5cのまま通してしまった。一方、キャッシュ
を出力するときはShift_JISに変換するのだが、このときShift_JISでは0x5cが
YEN SIGNであってREVERSE SOLIDUSではないので、0x5c(REVERSE SOLIDUS)は仕方
ないから＼になる、ということではないかな。
不整合に見えるけど、単に時間差があるだけでしばらく待ってると保存時にも変
換されたものでデータが入れ替わって揃うのかも。それでもページが更新されな
いとキャッシュデータが書き換わらない可能性はあるが。
- 693 名前：デフォルトの名無しさん mailto:sage [04/10/05 08:50:29]
- Perl6だとYEN SIGN(U+00A5)に演算子として意味を割り当てるので、
扱いとしては完全にREVERSE SOLIDUSと別にせざるを得ないらしいじゃん。
日本語Windowsユーザはどうするのか。
本当はUnicodeに移行してればこんなことで悩まなくなってるはずなんだが、
問題解決に絞るべき知恵のなかったMSKKが
「0x5cは見掛けYEN SIGN、意味は場合によって世界標準Unicodeにおける
U+005C(REVERSE SOLIDUS)かYEN SIGN」
なんつー考えナシUnicodeを始めてしまったもんだから、
21世紀になっても悩みがつきないわけだなあこれが。
- 694 名前：デフォルトの名無しさん mailto:sage [04/10/05 13:11:27]
- そこでUnicodeの再設計ですよ
- 695 名前：デフォルトの名無しさん mailto:sage [04/10/05 13:30:33]
- >>693
MS の CP932 では EUC-JP と同様に 0x5C は Unicode の \u005C にマッピングされてるわけで、
MS 的には CP932 <-> Unicode の相互変換で違う文字になるなんてことは無いはず。
Shift_JIS なんてやめて、CP932 に移行すべき。
しかしC# の XMLWriter で CP932 で書き出すと、encoding="Shift_JIS" になる orz...
- 696 名前：デフォルトの名無しさん [04/10/05 14:26:23]
- 0x5cは、全員バックスラッシュにすれば済む話じゃん。
￥マークは全角で使用して、半角の￥は存在しないと思えば良い。
それよりも、日本語Windowsで0x5cをバックスラッシュで表示してくれないのが困る。
- 697 名前：デフォルトの名無しさん mailto:sage [04/10/05 14:58:38]
- 勉強になりそうなので読んでいますが、
CP932? REVERSE SOLIDUS?…(´･ω･｀) もうついていけません…。
たとえばWindows環境では、フォントによって\がバックスラッシュで
表示されたり \のままだったりしますが、これというのはつまり
フォントごとに、その文字コードに対応する文字イメージが
異なっているというだけなんでしょうか。それともハードウェアの
レベルで何かが起こっているんでしょうか。
文字コードと、実際に画面に表示される文字イメージが
どこでどう関連づけられているのか、いまひとつ分かりません。
- 698 名前：デフォルトの名無しさん [04/10/05 15:13:26]
- >>697
文字イメージが違うだけ。0x5cは0x5cのまま何も変わっていない。
フォントを書き換えれば、バックスラッシュにできるんだが、改造はしたくない。
マイクロソフトが強制的にバックスラッシュにしてくれればありがたいのだが。
- 699 名前：デフォルトの名無しさん mailto:sage [04/10/05 15:45:15]
- >>697
Shift_JISの0x20〜0x7FはASCIIに似てASCIIじゃない文字セット(JIS X 0201)だというのが混乱の原因。
0xA5はASCIIではREVERSE SOLIDUS(バックスラッシュ)なんだけど、JIS X 0201ではYEN SIGN。
で、「\」この文字をUnicodeに変換するとき、Shift_JISはYEN SIGNに割り当てるのに、
cp932(Shift_JISをMSが拡張したもの)ではREVERSE SOLIDUSに割り当てる。
MS的には、Unicodeに変換したときにパス区切り文字が使えなくなると困るから
こうせざるを得なかったようだ。JIS X 0201がASCIIから変更した箇所と、
MSがパス区切り文字に使っていた文字が重なってしまった不幸な偶然を恨むしかない。
- 700 名前：デフォルトの名無しさん mailto:sage [04/10/05 16:20:55]
- まあそれでも「〜」あたりの混乱よりはマシだな。
- 701 名前：697 mailto:sage [04/10/05 16:31:42]
- >>698-699
なるほど、だんだん分かってきました。
もう少し分からないんですが、たとえばマルチバイトモードから
Unicodeモードに切り替えてコンパイル・実行したとすると、
文字コード自体は変わってしまっても見た目は(概ね?)同じ
ですよね。
同じフォントから同じ文字イメージを取り出すには、この
文字コードの違いを吸収する仕組みが必要だと思うのですが、
どのようになっているのでしょうか。
文字セットごとに「文字イメージ位置検索テーブル」のような
ものが用意されていて、文字コードからフォント内の文字イメージ
位置を検索できるようになっているのではと想像してみたのですが
実際のところはどうなっているのでしょうか。
- 702 名前：デフォルトの名無しさん mailto:sage [04/10/05 16:39:23]
- >>701
最近のGUIベースのOSだと、フォントセットは大抵 Unicode でのコードポイントにたいして
タイプフェイスが割り当てられています。そうして文字コードから Unicode のコードポイントに
変換する仕組みも別途存在します。「どのようになっている」かは、OSやウィンドウシステムに
よって異なります。
- 703 名前：697 mailto:sage [04/10/05 17:02:28]
- >>702
なるほど、フォント内の文字の並びが何に従っているのか次に
質問しようと思っていたところなんですが、Unicode に合わせて
あるんですね。その上で、文字コードをUnicode の文字コードに
変換する仕組みが備わっている(仕組みは環境ごとに異なる)という
ことなんですね。納得致しました。
ご回答ありがとうございました。
- 704 名前：デフォルトの名無しさん mailto:sage [04/10/05 18:05:15]
- >>703
欧文フォントなんかだと、Unicode ではなく ISO 8859-1 (Latin-1) で入ってたりするものもある。
- 705 名前：686 mailto:sage [04/10/05 23:45:34]
- >>691
できました。thx
サンプルコードあったのか…気が付かなかった…il||li ○|￣|＿
- 706 名前：デフォルトの名無しさん mailto:sage [04/10/06 01:12:14]
- >>697
euc.jp/i18n/ucsnote.ja.html読めばあ?
- 707 名前：697 mailto:sage [04/10/06 17:50:44]
- >>704
Unicode とは並び方の異なるものもあるんですね。そのような
フォントの場合はどう扱っているのでしょう。Unicode のコード
ポイントに変換する方法では上手くいきませんよね…。使用する
フォントがどんな文字セットのコードポイントに一致しているか
という情報も、どこからか取り出しているのでしょうか。
>>706
ありがとうございます。
記号の読み方などバッチリ出てますね^^;
内容的にはまだよく分からない部分もありますが、
とりあえず最後まで読みすすめてみようと思います。
- 708 名前：706 mailto:sage [04/10/06 22:47:40]
- >>707
そんな難しいことは書いてないです。
良く書けているページなので何回も読んでみてください。
先入観を取り払えば、理解できるはずです。
ちなみに>>698は間違っているのでスルーしてください。
文字実体、グリフという概念を理解してない。
- 709 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:07:24]
- JIS X201はもはや業界のお荷物でしかない
- 710 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:45:03]
- 和文フォントはWinの文字コード表でみると円記号の上に
ツールチップで"REVERSE SOLIDUS"と出るのが激しく間抜けだ。
せめてREVERSE SOLIDUSのグリフをどこかに突っ込んでおいてくれよう。
|
 |
