logo
 
WebChain/2 Previous Ramdom Jump WebChain/2 Home Next
 メインメニュー
 サイト内検索

検索オプション
 ログイン
ユーザID または e-mail:

パスワード:

IDとパスワードを記憶

パスワード紛失

新規登録
 IRC(チャット)
#OS/2:*.jp
楽しみ方はこの辺参照.
フォーラム一覧   -   トピック一覧
   アプリ
     「UTF-8 encoded pages without "lang=" specification fails to use proper font for that national langua
投稿するにはまず登録を

スレッド表示 | 新しいものから 前のトピック | 次のトピック | 下へ
投稿者 トピック
orca
投稿日時: 04/07/07 01:55
Home away from home
登録日: 03/01/28
居住地:
投稿: 269
Re: langを変更
言わんとしていることは, つか, まとめてみると ・・・

まず, Mozilla内部は Unicodeで管理してるとゆーのを前提にして (ソース見たことないので, ここでは仮定てことで)

Mozillaが行っていることを推測すると, こんな感じだと思うです。
1. 指定のページを読み込む。 このとき(ヘッダーにある)サーバーから送られた文字コードでアレする (Shift_JISとか JISコードとか EUC-JPとか)
2. 内部に Unicodeとして蓄える
3. 出力(表示)する。このとき, その OSがサポートしているエンコーディグ(?)で ・・・

# サーバーからの応答にないばーいは charset=, あるいは [Character Encoding][Auto-Detect] で

たとえば, こんな風になるです (最終的には Shift_JIS)
「あ」→ 12354 ("\u3042") → 0x82 0xA0
「亜」→ 20124 ("\u4e9c") → 0x88 0x9F

んで, 本来なら
「±」→ 177 ("\u00b1") → 0x81 0x7D
横線 → (まだ調べきれてない)

でも, 起こっている現象は, Unicodeのある範囲において Shift_JISに置き換えることなく出力してるよーにさえ見える, みたいな。
「±」→ 0xb1 (半角カナの「ア」)
ほかにも 3桁, あるいは 4桁の Unicodeのとこであっても一部が表示されない訳れす (つか, 何かと間違えられている感じ)

で, 言語コードが ja とか ko とかだと(↑)こんな感じだけど, 以下のよーにすると大丈夫っぽい (今のところ)。
java script:document.body.setAttribute('lang','x-klingon')

つまり, 言語コード=ja (あるいは DBCS圏) なら, ソレを間違って OSにまかせて (Unicode渡して)しまってるのカモ, てことれす。
言語コードはホントはこんな(↓)感じれす。

例えば、諾威(ノルウェイ)語文書の中で <span lang="FR">C'est la vie.</span> と書くことが出来ます

参考:
http://www.ietf.org/rfc/rfc3066.txt
http://suika.fam.cx/~wakaba/-temp/wiki/wiki?RFC3066

言語コード=ja は, 出力寸前に使う物ではないのじゃないか, てことれす。
あるいは, OS/2の Unicodeサポートが変ってのは, 日本語版 OS/2とかは Shift_JISなんだし, 変に見えるカモだけど そんなものかもね, とも。

訂正:
最後のトコ, もともと「言語コード=ja は Unicodeに変換するときに」て書いてたけど書き間違い。
たぶん, そのとき考えてた意味は 2つ。内部コードに変換されたのを出力寸前, 再度 Shift_JISに関する処理が行われてるのは変てこと。んで, lang属性は (その部分ではなく)もっと別なトコで使うもののはず, ってことれす。
min
投稿日時: 04/07/07 11:12
Home away from home
登録日: 03/01/27
居住地: 兵庫県尼崎市/このアバターは日本システムサプライの著作物です
投稿: 227
Re: langを変更

んで, 本来なら
「±」→ 177 ("\u00b1") → 0x81 0x7D
横線 → (まだ調べきれてない)


横棒は、
「―」→ ("\u2015") → ?
0x815C 0x2015 #HORIZONTAL BAR

ひそかにま〜りんちゃん問題のとき、話題に上がってる文字のひとつですね

ちなみに、PolarbarMailerでは表示されない文字だったので、
今までおかしいことに気づいていなかっただけなのかもしれません。
(今まで表示されてなかったのが、今回バケるので、異常に気づいた?とか)
jjsuwa
投稿日時: 04/07/08 03:43
Home away from home
登録日: 03/01/26
居住地: Kami-Youga, Setagaya Ward, Tokyo, Japan, Earth, Sol, MilkyWay
投稿: 197
Re: langを変更
| Mozillaが行っていることを推測すると, こんな感じだと思うです。
の、

| 1. 指定のページを読み込む。 このとき(ヘッダーにある)サーバーから送られた文字コードでアレする (Shift_JISとか JISコードとか EUC-JPとか)
ここってMozilla独自変換なんでしたっけね確か。

| 2. 内部に Unicodeとして蓄える
実際の内部表現が確認できればどこらへんで腐ってるのがはっきりしていいんですけど、できないんだよなあ。

| 3. 出力(表示)する。このとき, その OSがサポートしているエンコーディグ(?)で ・・・
普通に考えると、ここんところはUnicode→現在のcodepage設定による表現になると思うんだけど、どうなんだろう。
# 例えばUniMapCpToUcsCp()とか使って。
jjsuwa
投稿日時: 04/07/08 04:11
Home away from home
登録日: 03/01/26
居住地: Kami-Youga, Setagaya Ward, Tokyo, Japan, Earth, Sol, MilkyWay
投稿: 197
Re: langを変更
あー、なんか見えてきたような気が。

1. HTMLソースをcharsetとか見て/自動判別してUnicode内部表現に変換するところは多分齟齬を来してはいないと思う。
# MozillaのToUCSとOS/2 ULSのFromUCSが正確な鏡像になってるかどーかってのはさて置きw
# でもまー自動判別ロジックとかもあるからここはOS/2 ULSでは置換できないと思われ。

2. 現行のOS/2がUnicode nativeでない以上、Unicode内部表現は必ず何らかのOS/2 native表現に解決されなければならないのは自明と。
 そしてそのOS/2 native表現はcodepageによって異なると。
# ここんところはMr.MikeのたまうところのクソッタレなOS/2 ULSでやるわけですがw

3. で、そのOS/2 native表現されたものをOS/2 PMで正しく表示するには、それに相応しいフォントを選んできたり、あるいはSBCS/DBCS指定をウィンドウ制御に指定したりしなければならない、と。

で、
1.の段階でencoding情報は全てUnicodeに吸収されるとしても、lang情報はそれとは別にどっかに保管してないと2.または3.で齟齬を来すのは明白ではなかろうか。
# コード化けしている、という現象からすると2.の段階でOS/2 native表現をlatin-1辺りへ決め打ちになってるのかlangがDBCS圏の時のOS/2 native表現が変なのか、のどちらかかな。

# もしかしたら上記の過程でlang情報が本当に失われてるのか、使いづらい状況になってるのか?
jjsuwa
投稿日時: 04/07/08 05:11
Home away from home
登録日: 03/01/26
居住地: Kami-Youga, Setagaya Ward, Tokyo, Japan, Earth, Sol, MilkyWay
投稿: 197
Re: langを変更
いまクソッタレなOS/2 ULSを使って確認してみたけど、

nativeの0x81 0x7dは
Shift_JISで ± で、→Unicodeだと0x00b1
Latin-1→Unicodeだと0x0081 0x007d
# Latin-1をunsigned extendするとUnicode?

nativeの0x81 0x7eは
Shift_JISで × で、→Unicodeだと0x00d7
Latin-1→Unicodeだと0x0081 0x007e

なんか、どーもMozilla内部のOS/2寄りな部分で、0x0000〜0x00ffなUnicodeはOS/2 ULSで変換せずにそのままGUI系に流しているっぽいですな。
# 1.7bでも±や×は本来の幅より狭く表示されるし

Unicode時代のSBCS圏DBCS問題:
 SBCS圏な開発者は0x0000〜0x00ffなUnicodeはnative表現で必ず1byteになると思っているw

のかも、しれない…
# あ、… も狭く表示されるw
# OS/2 ULSではUnicode 0x2026なんだけどMozillaだと0x0000〜0x00ffな何かなんだろうなぁ

=====
/* ucstest.c */

#include <string.h>
#include <stdio.h>
#include <uconv.h>

/* */
int main(int argc,
char* argv[])
{
int result;
UconvObject uconvShiftJIS, uconvLatin1;
void* fromptr;
size_t fromlen;
UniChar to[16];
UniChar* toptr;
size_t tolen;
size_t nonidentical;
unsigned int i;

if(argc < 2)
{
(void)printf("\n"
"needs 1 string argument.\n");
return 0;
}

result = UniCreateUconvObject((UniChar*)L"IBM-943", /* Shift_JIS */
&uconvShiftJIS);
result = UniCreateUconvObject((UniChar*)L"IBM-819", /* Latin-1 */
&uconvLatin1);

(void)printf("\n"
"Shift_JIS to Unicode :\n");
fromptr = argv[1];
fromlen = strlen(argv[1]);
toptr = &to[0];
tolen = 16;
nonidentical = 0;
result = UniUconvToUcs(uconvShiftJIS,
&fromptr,
&fromlen,
&toptr,
&tolen,
&nonidentical);
if(result != ULS_SUCCESS)
(void)printf("UniUconvToUcs(ShiftJIS) failed, rc=0x%08x.\n",
result);
else
{
(void)printf("%u chars, ",
16 - tolen);
for(i = 0;
i < 16 - tolen;
i++)
(void)printf("0x%04x ",
to[i]);
(void)printf("\n");
}

(void)printf("\n"
"Latin-1 to Unicode :\n");
fromptr = argv[1];
fromlen = strlen(argv[1]);
toptr = &to[0];
tolen = 16;
nonidentical = 0;
result = UniUconvToUcs(uconvLatin1,
&fromptr,
&fromlen,
&toptr,
&tolen,
&nonidentical);
if(result != ULS_SUCCESS)
(void)printf("UniUconvToUcs(Latin-1) failed, rc=0x%08x.\n",
result);
else
{
(void)printf("%u chars, ",
16 - tolen);
for(i = 0;
i < 16 - tolen;
i++)
(void)printf("0x%04x ",
to[i]);
(void)printf("\n");
}

result = UniFreeUconvObject(uconvLatin1);
result = UniFreeUconvObject(uconvShiftJIS);

return 0;
}
=====
orca
投稿日時: 04/07/08 08:08
Home away from home
登録日: 03/01/28
居住地:
投稿: 269
Re: langを変更
achainさんは書きました:
てな感じでしょうか.

ありがとございます。
いろんな意味で正しく伝わるかどーか不安なトコだけど。

んで, なんだか説明がダメダメだったっぽいので, もういちどトライしてみるです。
# ここで伝わらないよーだと, さらに伝わらないっぽいので

言語コードを 'x' に(あるいは SBCS圏の何かに) すると, 文字化けは直ります。 ソレは, 蓄えられた Unicodeは同じでも, 出力方法が正常になるからだと思うです。
('x' は実験的言語コードのこと http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/dirlang.html#h-8.1 )

で, lang属性が ja とか ko だと, ブラウザー側で何かアレする必要があるのかもだけど, そーゆーしがらみは置いといて, ごく単純にその処理を考えてみると ・・・

表示するときには, (蓄えてある)Unicodeの文字列から一文字ずつ取り出して, そのコードとフォントから グリフ(文字のイメージ)を得て, ソレを描画する, のを繰り返す。
Unicodeを指定してグリフを得るって APIが, OS/2にあるのかどーかは知らないけど, そーでなくても Unicode → SJIS → グリフを得る, みたいにはなってると思うです。

「――」てゆーのを例にとると, Unicodeでは "\u0097\u0097" のはずで, 正しい出力手順は
1. 最初の一文字を SJISにし, 0x97 (あるいは 0x81 0x5c) とゆー内部コードを得る
2. ソレを元にグリフを得, 描画
3. 次の一文字を SJISにし, 0x97 (あるいは 0x81 0x5c) を得る
4. 同様に描画

ところが, そこで起こっていることは
1. 最初の一文字を SJISにし, 0x97とゆー内部コードを得る
2. グリフを得るつもりが, 内部コード SJISとしては成り立たないので, 何も無し
3. 次の一文字を SJISにし, 0x97を得る
4. 先の 1バイトと組み合わせ 0x97 0x97の内部コードでグリフを得て描画

この動きは, コマンドラインでも試すことができ, たぶんソレと同じではないかと思うです。
コマンドラインでの漢字(全角文字)は, たとえば 0x97を出力するとすぐには出力されず, その次の 1バイトを待つようになってて, 決して左半分だけが先に描画されたりはしないから (当然だけど)。
こんな感じ(↓) ・・・ キーを押すと続行します
rexxtry call charout ,x2c(97); ch = SysGetKey('noecho'); call charout ,x2c(97);

少なくとも SJISに関する部分は, 内部コードを得るために使う (1) (3) だけで, そこで得た内部コードは, 文字としては完結してるはずです。
グリフを得る(らしき)トコでは, SJISに関する部分が呼び出されないよーに, あるいはその処理が不可分なもので一体となっているのなら, その部分だけ英語モードで, ・・・ なんてことを伝えることができたら
って甘いかも。(^^;
orca
投稿日時: 04/07/08 08:13
Home away from home
登録日: 03/01/28
居住地:
投稿: 269
Re: langを変更

minさんは書きました:

んで, 本来なら
「±」→ 177 ("\u00b1") → 0x81 0x7D
横線 → (まだ調べきれてない)


横棒は、
「―」→ ("\u2015") → ?
0x815C 0x2015 #HORIZONTAL BAR


Unicodeで, &#8212; とか &#x97; とか, それに他にもあるかもなので分からなかったです。
で, &#x2015 は, こちらでは化けないれす。
orca
投稿日時: 04/07/08 08:38
Home away from home
登録日: 03/01/28
居住地:
投稿: 269
Re: langを変更
なんか、どーもMozilla内部のOS/2寄りな部分で、0x0000〜0x00ffなUnicodeはOS/2 ULSで変換せずにそのままGUI系に流しているっぽいですな。

ソレはソレでよいと思うです。
文字化けせずに, ここに現れてるイメージが表示されれば。 → http://jrgraphix.net/research/unicode_blocks.php?block=1

Unicode時代のSBCS圏DBCS問題:
 SBCS圏な開発者は0x0000〜0x00ffなUnicodeはnative表現で必ず1byteになると思っているw

のかも、しれない…

その範囲を 1バイトでアレするのなら, 英語モードか何かで そのイメージに変換して欲しいし, そうでないのなら, 横棒を 0x81 0x5cの内部表現に変換するよーにて描画してほしいトコれすね。
「SJISとしての先頭 1バイト」に変換されるのが問題って気がするです。
jjsuwa
投稿日時: 04/07/08 11:50
Home away from home
登録日: 03/01/26
居住地: Kami-Youga, Setagaya Ward, Tokyo, Japan, Earth, Sol, MilkyWay
投稿: 197
Re: langを変更
| 表示するときには, (蓄えてある)Unicodeの文字列から一文字ずつ取り出して, そのコードとフォントから グリフ(文字のイメージ)を得て, ソレを描画する, のを繰り返す。
| Unicodeを指定してグリフを得るって APIが, OS/2にあるのかどーかは知らないけど, そーでなくても Unicode → SJIS → グリフを得る, みたいにはなってると思うです。

OS/2はUnicode nativeではないんで必ずUnicode→native変換してglyph描画です。
ただ、そのnative表現をlang情報によって切り替えると。
# 同様にUnicode nativeな環境であってもglyph描画にはlang情報が必要になります(将来のUnicode規格でlang情報埋込みとか取り入れる )

| 「――」てゆーのを例にとると, Unicodeでは "\u0097\u0097" のはずで, 正しい出力手順は

1. 最初の一文字をnative表現(このページはlang=jaなんでSJIS)にし、0x81 0x5cを得る
2. 上記表現からlang=jaに相応しいフォント(font pref.による)でグリフを取得、また必要であればlangによってDBCS属性を決定し、描画
3. 次の一文字を以下略
4. 同様に(ry

「――」がlang=enに書かれてたらnative表現はSJISでなくLatin-1あたり、フォントもlang=en用のやつ、そしてもちろんSBCS属性。

やはりちょっとした(しかし決定的に重要)ところで手抜きか勘違いがどこかに入ってるんでしょうね >mozilla for OS/2
jjsuwa
投稿日時: 04/07/08 12:14
Home away from home
登録日: 03/01/26
居住地: Kami-Youga, Setagaya Ward, Tokyo, Japan, Earth, Sol, MilkyWay
投稿: 197
Re: langを変更
| ソレはソレでよいと思うです。
なんかあんましよくないと思うです。lang情報がnative表現に反映されてないし。
# lang=enをLatin-1とするならそれでOK、lang=jaをShift_JISとするならしっかり変換してくれないと

| その範囲を 1バイトでアレするのなら, 英語モードか何かで そのイメージに変換して欲しいし, そうでないのなら, 横棒を 0x81 0x5cの内部表現に変換するよーにて描画してほしいトコれすね。
そーゆーことですね。

| 「SJISとしての先頭 1バイト」に変換されるのが問題って気がするです。
つーか、なんでlang=jaでLatin-1なnative表現を吐くかねー、ってことですな。

以下、妄想w

・langなしor無効なのを指定するとnative表現までは正しくなっているっぽいが、fontは正常ではない
→ langなしor無効だとUnicode→native変換で「現行プロセスのcodepage」に向けて変換しているのかもしれない。font解決はやりようがないのでfor Westernのやつで無理やり書く(DBCSはfont associationされていれば、それで書かれる)。
↑文書lang設定と現行プロセスのcodepageってゆー元々無関係な代物を関係付けてるんで、もちろんおかしい。たまたまJapaneseNLVなOS/2では日本語文書見ることが多いだけ。
jjsuwa
投稿日時: 04/07/08 12:43
Home away from home
登録日: 03/01/26
居住地: Kami-Youga, Setagaya Ward, Tokyo, Japan, Earth, Sol, MilkyWay
投稿: 197
Re: langを変更
てゆーかさ、素直に考えたら、

存在するOS/2 NLVの分だけ、そのNLVでPM環境に突っ込むnative表現のOS/2 ULS cpnameとSBCS/DBCS判定フラグのテーブルをlang=xxをキーに持てばいいだけではないか、と思うんですが。
# テーブルにないlangは現行codepageへの変換でお茶を濁すとw
# フォントはfont pref.で解決

まーなんかMike氏をしてクソッタレと言わしめるだけの何かがあるんでしょうけどね。
OS/2 ULSでMozilla Unicode→Latin-1変換すると出てこない文字があるとか。
それとも非Latin-1な文字が書かれている(本来はLatin-1であるべき、lang抜きだとLatin-1でしたっけ?)文書が余りにも多く、そして他プラットフォームMozillaだと平然と表示できるのに何でWarpzillaだと表示できねぇんだよ とかゆー苦情が相次いだとか。
orca
投稿日時: 04/07/08 15:22
Home away from home
登録日: 03/01/28
居住地:
投稿: 269
Re: langを変更
ただ、そのnative表現をlang情報によって切り替えると。
# 同様にUnicode nativeな環境であってもglyph描画にはlang情報が必要になります(将来のUnicode規格でlang情報埋込みとか取り入れる )


langてゆーのが, 環境変数 LANG (=ロケールの設定) ならば, そのとおりだと思うです。 Shift_JIS なのか EUC-JP なのか (OS/2日本語版は前者でしかありえないけど) を決定するもののこと。

HTMLの lang属性と Unicodeとの関係では, これしか見当たらなかったでし。→ 「HTMLの言語情報に関する覚え書き
将来の Unicodeってのも見つからなかったれす。

で, コレは本来, 何らかのプロセッサーで, 以下の部分を犬の種類と間違えたりしない, 日本語の文法が違うとかゆったりしない, そんなことのためのものだと思うです。 あるいは音声読み上げで, その部分を関西弁のアクセントでアレしたりとか。
<span lang="ja-関西弁">ちゃうちゃう</span>
ただし, コレ(↑)はその使い方の説明として lang属性を勝手にアレしたものなので, ホントにそーゆー記述しても多分動かないけど。

「――」がlang=enに書かれてたらnative表現はSJISでなくLatin-1あたり、フォントもlang=en用のやつ、そしてもちろんSBCS属性。

σ(^^) のトコでは, ちゃんと全角サイズで見えてます。 ただし, copy&pasteすると半角になるけど。

やはりちょっとした(しかし決定的に重要)ところで手抜きか勘違いがどこかに入ってるんでしょうね >mozilla for OS/2

たぶん, そんな感じだと思うけど, 相手が相手だけにホントにどーにもならない問題って可能性も 捨てきれなかったりして。

| ソレはソレでよいと思うです。
なんかあんましよくないと思うです。lang情報がnative表現に反映されてないし。
# lang=enをLatin-1とするならそれでOK、lang=jaをShift_JISとするならしっかり変換してくれないと

「文字化けせずに, ここに現れてるイメージが表示されれば」と書いている通りです。 "―" も全角サイズで表示できてるし, 2バイトコードにしろ 1バイトコードにしろ, 変換した内部コードがちゃんと表示されるものなら構わないカナ, と。
問題は, ソースを取り出すとき半角になってることだけど, 化けるよりもましなので, (σ(^^) にとっては) 「ソレはソレで構わない」カモ。
jjsuwa
投稿日時: 04/07/08 16:40
Home away from home
登録日: 03/01/26
居住地: Kami-Youga, Setagaya Ward, Tokyo, Japan, Earth, Sol, MilkyWay
投稿: 197
Re: langを変更
ここでのlangはHTTP headerとかHTML metaとかのlang、言語情報のことでつ。

あとUnicode→native表現と言語情報との関係は
http://www.asahi-net.or.jp/~hc3j-tkg/unicode/
の最後の方の「感想」に書かれていることが私の言いたいことを的確にあらわしてます。
jjsuwa
投稿日時: 04/07/08 16:51
Home away from home
登録日: 03/01/26
居住地: Kami-Youga, Setagaya Ward, Tokyo, Japan, Earth, Sol, MilkyWay
投稿: 197
Re: langを変更
ええーっと…

| 引用:「――」がlang=enに書かれてたらnative表現はSJISでなくLatin-1あたり、フォントもlang=en用のやつ、そしてもちろんSBCS属性。
| σ(^^) のトコでは, ちゃんと全角サイズで見えてます。 ただし, copy&pasteすると半角になるけど。
<中略>
| 問題は, ソースを取り出すとき半角になってることだけど, 化けるよりもましなので, (σ(^^) にとっては) 「ソレはソレで構わない」カモ。

私が言いたかったのは、
「現状とりあえず表示されてる/されてない論」
ではなくて
「こうすべきだ論」
なのでした。

文書ソースの文字コードは内部でどー持ってようが変換前後で齟齬を来たさず最終的にあってれば(←多分に怪しいけどね^^;;)一向に構わないですが、(文書ソースの)言語情報は最初から最後までしっかり保持してくれないと文字コード変換もグリフ取得もltr/rtlもnative GUI要素の表示設定も全てがうまくできません。
jjsuwa
投稿日時: 04/07/08 17:04
Home away from home
登録日: 03/01/26
居住地: Kami-Youga, Setagaya Ward, Tokyo, Japan, Earth, Sol, MilkyWay
投稿: 197
Re: langを変更
どんどん書くw

| で, コレは本来, 何らかのプロセッサーで, 以下の部分を犬の種類と間違えたりしない, 日本語の文法が違うとかゆったりしない, そんなことのためのものだと思うです。 あるいは音声読み上げで, その部分を関西弁のアクセントでアレしたりとか。
| <span lang="ja-関西弁">ちゃうちゃう</span>

例えば。文書エンコーディングはUTF-8として、

HTML全体はlang=enで一部分はlang=jpだったら、
最終的なGUI表現は表示の殆どはlang=enに対応したnative表現文字コードをlang=en設定にあるフォント、lang=en設定にある綴方向で、必要であればSBCS設定されたwidgetで描画/構成され、
lang=jaな一部分はlang=jpに対応したnative表現文字コードをlang=ja設定にあるフォント、lang=ja設定にある綴方向で、必要であればDBCS/MBCS設定されたwidgetで描画/構成**されなければならない**

と思うんですが。
そして<span>lang属性なんてのはもろその為にあるんだと思うんですよ。

# ja-関西弁とjaではnative表現文字コードも綴方向も同じで両方ともDBCSでフォント設定もJapaneseを共用するから表示上は同じですね。意味合いだけ。
# もし昔の横書きをrtlで綴るja-??が存在したとしてそれが指定されたらそこだけは右から左に綴る必要がありますね。フォントとかは同じであっても。
orca
投稿日時: 04/07/09 07:46
Home away from home
登録日: 03/01/28
居住地:
投稿: 269
Re: langを変更
文書ソースの文字コードは内部でどー持ってようが変換前後で齟齬を来たさず最終的にあってれば(←多分に怪しいけどね^^;;)一向に構わないですが、 (文書ソースの)言語情報は最初から最後までしっかり保持してくれないと文字コード変換もグリフ取得もltr/rtlもnative GUI要素の表示設定も全てがうまくできません。

Unicodeに変換した時点で, 元の情報には復元できないれすよね。 1対1じゃないし。 文字の方向とか lang属性とかは DOMでアレしてるので, そっちは大丈夫。
問題になるのは 「ソースをファイルに保存」みたいなこと。
もちいど, サーバーから取得するか, あるいは, Unicodeとは別にソースを保持するか。 ・・・ Mozillaがどのよーになってるのかは知らないけど。

んで ・・・
<kbd>Firefox -chat</kbd> がキーをタイプしたことを表すよーに, <em lang="ja">彼は言った <q lang="en">hey</q> と。</em> … その部分が何語で表されているか, どこの方言か? てことを表すのだと思うです。セマンティック, みたいな。

<span lang="ja">「文書」は 中国語(簡体字)だと <span lang="cn">文档</span>, 中国語(繁体字)だと <span lang="zh">文件</span> らしい。</span>
Unicode 漢字統合問題 を扱ってるページにはこんなトコがあるです → http://www.debian.or.jp/~kubota/unicode-symbols-unihan.html http://www.ritsumei.ac.jp/kic/~tyv07679/chuden/teach/code/main8.htm http://euc.jp/i18n/ucsnote.ja.html
見栄えが変わるとすれば, それは言語に合ったレンダリングを行うってこと。 たとえば「海」とか「直」って体字は, それぞれ微妙に異なったりするです。 そんなときに, lang属性でフォントを選択できたりする, と。

lang属性が仮にないとしても, Unicodeなんだから, それらしいグリフで描画されるのがホントで, lang属性は文字コード(=character encoding) には関係がないはずれす。

♥ が "?" になったり, ×がカタカナに見えたり, ソレは大きな問題に思うです。
jjsuwa
投稿日時: 04/07/09 07:57
Home away from home
登録日: 03/01/26
居住地: Kami-Youga, Setagaya Ward, Tokyo, Japan, Earth, Sol, MilkyWay
投稿: 197
Re: langを変更
| lang属性が仮にないとしても, Unicodeなんだから, それらしいグリフで描画されるのがホントで, lang属性は文字コード(=character encoding) には関係がないはずれす。

Unicode-nativeなOSならそうでしょうが残念ながらOS/2は違います。
orca
投稿日時: 04/07/09 13:05
Home away from home
登録日: 03/01/28
居住地:
投稿: 269
Re: langを変更

jjsuwaさんは書きました:
| lang属性が仮にないとしても, Unicodeなんだから, それらしいグリフで描画されるのがホントで, lang属性は文字コード(=character encoding) には関係がないはずれす。

Unicode-nativeなOSならそうでしょうが残念ながらOS/2は違います。

たとえば, U+3040 〜 U+309F の'Hiragana' のトコに U+3042 「あ」があります。 最終的にグリフを得るため, 途中で内部コードに変換する必要があるかも知れない。 でもソレは lang属性には関係ないものれす。
lang属性が何であろーと, 「あ」は「あ」です。
Javaのツールに native2ascii.exe てゆーのがあって, コレを動かすのにも lang属性に相当するものは必要ないれす。

先の「海」とゆー文字を表示するとき, 言語によっては縦棒ではなく点々です。 コレを切り換えるために lang属性は必要カモです (有効かどーかは知らないけど)。このとき現在はフォントファイルが切り替わるかもだけど, 将来においては, (もっとましな?) 異体字を指定する他の方法がアレするかも。

http://www.asahi-net.or.jp/~hc3j-tkg/unicode/ より
CJKV を含む M17N のための code set としては Unicode-1.1 は単独では使えない。 M17N に使おうと思ったら Unicode の文字列に何らかの形で言語情報等を付加する必要がある。
Unicode-3.0(?) には言語タグ、異字体タグが入るそうで、そうなると CJKV を含む M17N にも使えるようになるのかな?


単独で使うばーい 異字体を区別する方法がない (でもとりあえず普通に表示はできるはず), だから lang属性が必要になるだろうって話ですよね。

orca
投稿日時: 04/07/17 00:54
Home away from home
登録日: 03/01/28
居住地:
投稿: 269
Re: langを変更
グリフを得る手順をもいちど考えてみると ・・・
"±" (U+00b1) を例にとると, 次の方法が考えられるです。
o DBCS (Shift_JISで) 0x81 0x7D の内部コードを得て, ソレを元にグリフを得る
o SBCS 0xb1 の内部コードを得て, ソレを元にグリフを得る

# 現在は後者で, しかも日本語のコードページのソレを得ようとして化けてる, と。

で, 全角の範囲に含まれないものもあって, &isin; だと "∈" があるけど, &notin; だと, たぶん存在しないはず。
ほかにも例えばこんなのが含まれてないよーに思うです。 → &hearts; &clubs; &diams; &spades;

こんな場合, 後者の手順でグリフを得るしかないはずで, western だと なぜかうまい具合に成功してるです。
んで, その理由が「western だから」じゃ, 納得できないカモ。
Average
投稿日時: 04/07/30 11:58
Home away from home
登録日: 03/01/27
居住地: 赤羽馬鹿祭りの町赤羽
投稿: 395
Re: 「UTF-8 encoded pages without "lang=" specification fails to use proper font for that national la
CVSチェックイン調べて、挙動が変わった前後で変わったソースを差し戻す、という事をやるというのはどうか!
・・・・誰がやるのかという問題はさておき・・・
(1) 2 »
スレッド表示 | 新しいものから 前のトピック | 次のトピック | トップ

投稿するにはまず登録を
 
Powered by IBM OS/2 Warp, Apache, PHP, MySQL and XOOPS Cube