Fedora JP Projectが正式に発足 59
ストーリー by wakatono
まずはUTF-8からだ 部門より
まずはUTF-8からだ 部門より
mumumu 曰く、 "Fedora Core 1のリリース以来、有志が集まりwikiやMLを通して活動してきたFedora JP Projectが今日正式に発足した。本家Fedora Projectとは独立しつつ、Fedora Projectへの貢献、Fedoraに関する日本語での情報提供及び環境整備を目的とするとのこと。日本語環境がUTF-8化されたことに伴って発生している問題に対して、優先的に取り組むという姿勢には大いに期待できると思う。"
UTF-8 (スコア:1, 興味深い)
ってお願いすることはできないのでしょうか？
あんな無茶苦茶な文字コードを表に出してくるなんて
いったいどういう神経してるのかわかりません。
日本ではWin、Mac、Sunでコードに互換性がないし、
将来日本や中国が文字の定義を変更したらどうするのかとか。
unicodeには問題が多すぎるのはみんな知ってるはず。
unicodeなんて国際化からほど遠いと思ってる人、たくさん
いるんぢゃないんでしょうか？日本には...
Re:UTF-8 (スコア:3, 参考になる)
ここでその問題を語ってくれ、とはいいませんが、少なくとも旧Red Hat時代は日中韓のみEUCで、ほかはすべてUnicodeで通していた、という経緯があります。ここで、とりあえず、そういう地域差を解消して、世界的な統一ができた、ということになると思います。Unicodeがそれに相応しいかどうかはわかりませんが、いつか、文字コードの統一をして、世界どこでへいっても同じコードで不便なく使える環境があるべきだ、とは思っています。
ちなみに、Red Hatのエンタープライズ製品はまだEUCだそうです。そういう意味で、Fedoraは今後のための人柱な性格が強いのだと思っています。
もし、不満なら、本家のBugzilla [redhat.com]に投げてみてはいかがでしょうか。
Re:UTF-8 (スコア:2, すばらしい洞察)
Fedoraは新しいものをどんどん取り込む方向の、
ある意味「人柱専用」と聞いているので、こだわりのある人は
使わないほうがいいかもです。
まぁ、Linuxは他にもよりどりみどりだから、別にFedoraである
必要はないでしょうし。
使いやすいと思ったものを使えばええのではないかと。
ただ、自分がメインで使ってるディストロがEUC→UTF-8 したら、
それは声を上げてもいいとは思いますが。
（通るかどうかは別にして）
# カーネル2.6なFedora2が待ち遠しい
Re:UTF-8 (スコア:0)
(Fedora Core 1 では、UTF-8のみしか開けなかった気が）
このへん [sdri.co.jp]を自作されてる方に、Fedoraにも興味持って頂けないかしら。
Re:UTF-8 (スコア:2, 興味深い)
日本も、ISO 10646-1 は JIS X 0221 という形で国内規格となっています。今後は JIS 漢字そのものが JIS X 0221 と整合性を確保するかたちでメンテナンスされていくことでしょう。
韓国については、Unicode に対してハングルのコードポイントを変更させることに成功しましたが、それには大変な努力が必要だったはず。努力を怠らず、要求の実現にこぎつけたところに、Unicode への思い入れの強さを感じます。なぜ日本人は影でこそこそと愚痴を言うだけで、粘り強く交渉しようとしないんですか？
ja_JP.eucJPは使えます (スコア:2, 参考になる)
manの表示以外は特に困らないかな。
ja_JP.eucJPが消えたら嫌だけど。
Windows程度には違和感ないものが出来れば別にunicodeでもいいです。
UCS2だとちょっと嫌だけど。
日本人にはunicodeよりもっと困難な問題が…input methodとか。
Re:ja_JP.eucJPは使えます (スコア:0)
# ja_JP.eucJPでKONとか。
Re:UTF-8 (スコア:1)
ウェブアプリケーションを作ったりする際には非常に便利なんですが・・・Java も内部コードは UTF16 ですよね。
「将来日本や中国が文字の定義を変更したらどうするのか」とのことですが、「文字の定義を変更する」というと、具体的にどのようなことですか？
UCS32 にはまだ広大な空き領域があると思っているのですが、そこを利用してなんとかなるようなものでもないのでしょうか・・・
Re:UTF-8 (スコア:1)
Re:UTF-8 (スコア:1)
Unicode は Glyph ではないとか、言いながら
A と a は区別するは、漢字は統合するはと、
英語圏のエゴが見え隠れします。
Re:UTF-8 (スコア:1)
Re:UTF-8 (スコア:0)
TRONユーザの匂いがします。
# 当たり？
Re:UTF-8 (スコア:1)
FreeBSD ユーザです。
＞A と a は区別するは、
印刷業界の人？とか、新聞屋さん？とか
聞かれるならわかるけど、
なぜ tron ?
Re:UTF-8 (スコア:0)
>
>TRONユーザの匂いがします。
TRONのコード体系でも区別していますが何か?
># 当たり？
はずれと言うより思い違いあたり。
Re:UTF-8 (スコア:1)
日本関係者の意識的なもので決めたのですか？
Re:UTF-8 (スコア:1, 参考になる)
これはUTF-8 の互換性？
UCSとかUTF-7とか諸々を unicodeで同じものだ！と勘違いして、
互換が無いとか嘆いてるって話？
> 将来日本や中国が文字の定義を変更したらどうするのかとか。
> unicodeには問題が多すぎるのはみんな知ってるはず。
そんなこと言ってる人がいるの？
将来変更したいなら、unicodeの新バージョンで対応するのでは？
協調がなければ勝手に変更できないのがunicodeであって、
変更する側も勝手に変えても幸せにはなりません。心配しすぎでしょ。
そーじゃなくて、unicodeの問題は、EUC等と比較してより多くの
リソースを消費する点と、中韓日においては似た漢字が
同じコードとして登録されている為に、本当の書体と違う可能性が
出てしまっているってのが一番の問題でしょ。
それとて、文字数の少ないEUC等よりは利点があると感じる人も多いですよ。
Re:UTF-8 (スコア:2, 参考になる)
> これはUTF-8 の互換性？
> UCSとかUTF-7とか諸々を unicodeで同じものだ！と勘違いして、
> 互換が無いとか嘆いてるって話？
変換表がそれぞれ異なっているんですよ。
現在は、「これが正しい」って変換表がないですからねぇ。
Re:UTF-8 (スコア:2, 参考になる)
でも、これはユニコード同士の互換性の問題ではなくて、ユニコードとShift-JISの互換性の問題ですよね？EUC-JPに同じ問題があったとは知りませんでした。
と、思ったらJISとユニコードの変換表の問題 [debian.or.jp]なのですね。考えてみれば当たり前か。
私にはJISが対応すべき問題に思えるんですが、JISが作った変換表はないのでしょうか？
# For man might be free./人は自由になれるかもしれないから。
Re:UTF-8 (スコア:1)
Re:UTF-8 (スコア:2, 参考になる)
ただし、まったく役に立ちません。
問題点は何個かありますが、最大のものは以下の２点
１．MSのCP932(MSのSJIS)の変換表とぜんぜん違うので
互換性がなく、Windowsとの相互運用性が求められる
場面では使い物にならない
（イマドキ求められへんて事はないわな）
２．'\' が Yen Mark にマッピングされてしまうため
C:\Windows とか printf("\n") のような\を
バックスラッシュとして解釈しないと誤動作するような
場面ではお手上げ
救いは「規定」ではなく「参考」なので無視してもJIS違反にはなりません。
とゆーわけで、実装者は良識にしたがって無視します。
＃もっとも、笑っちゃうことにUnicode.orgに登録されている
＃SJIS変換表はJIS X 221 のものとは全然違ううえ、
＃やっぱりMSと互換性ないので、純朴なUnicode信者が
＃それを見て、実装した日本語用の変換表は、
＃ほぼ確実にバグってるとかいう
＃わはは・・
＃そういう訳で誰が悪いわけでもないんだけれども、
＃日本人がUnicodeを使うといっぱい苦痛を味わうような
＃文化的背景が出来上がっちゃってます。実質
Re:UTF-8 (スコア:1)
いつの話をされていますか? JIS X 0208 と Unicode (ISO/IEC 10646) との間のコード変換規則は， JIS X 0221:1995 の発行時に，その附属書で初めて定義され， その後，JIS X 0208:1997 が発行されたときに， (コード変換表という形ではないが，シンボル名の対応づけという形で) JIS X 0208 の規定に取り込まれ， JIS X 0221 の現行の版である JIS X 0221-1:2001 からは外されているはずですが．
それから，JIS X 0221 の附属書で出たときに「参考」だったのは， 「そもそもこの種の規定は JIS X 0208 で行うべき」 という考えだったからであり， JIS X 0208:1997 では「規定」になっています． (「規定」だからといって，使われているわけでもないけど．)
それから， Unicode.org で公開されているコード変換表は， 漢字の部分を除いて，どれも「参考」という扱いです． 特に日本語を含む EASTASIA 以下の変換表は OBSOLETE 以下の ディレクトリにあります． 参考: http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/
Re:UTF-8 (スコア:1)
UnicodeからEUC-JP、Shift_JIS、Windows-31Jへ変換するときにUnicode側で複数コードを持っている文字をまとめるという変換コードが少ない(自分で作ればある)のが問題なだけで。
SJISやWindows-31J、EUC-JPからUnicodeに変換するときに化けるというのは、該当する位置のフォントがないのが問題という場合がほとんど。これもフォントの割当て方で解決できます。
Unicodeの問題、というわけではないです。
okome
Re:UTF-8 (スコア:0)
正しい変換表というのを
Re:UTF-8 (スコア:0)
ことをぜんぜん考慮してない点ですよ。例をあげると、
これまでJISX0208では、ギリシャ文字(Α,Β,Γ,...)や
ロシア文字(А,Б,В,..)は全角文字として扱われていましたが、
Unicodeではこれを半角として扱わなくてはいけないことになっています。
そうすると、例えばncursesアプリなんかは今までEUCで表示していて
上手く表示されてたプロ
Re:UTF-8 (スコア:1)
(OS Xの文字パレットを見て…本当だ。Full-Width Formsにはローマ字と記号しか入ってない)
ncursesについてはGoogleで調べて画面表示用の関数だとしか分からなかったのですが、UTF-８を使っているときもギリシャ・ロシア文字を「全角」のフォントを使って表示するだけじゃ駄目ですか？
そもそも互換用に一部「全角」文字がある以外はUnicodeには「半角」「全角」の概念は無いはずです。互換維持のために必要なら、ギリシャ・ロシア文字を「全角」で表示しようが「半角」で表示しようがUnicodeの知ったことじゃないと思うのですが。
「全角」のロシア・ギリシャ文字と「半角」のロシア・ギリシャ文字を区別したいと言われると困りますがそもそもJISX0208でもその区別はできなかったわけですし。
# For man might be free./人は自由になれるかもしれないから。
Re:UTF-8 (スコア:1, 興味深い)
> UTF-８を使っているときもギリシャ・ロシア文字を「全角」のフォントを
使って表示するだけじゃ駄目ですか？
そうするとncursesアプリケーションのプログラムの内部で、アジア圏と
非アジア圏でそれぞれ別な処理を行わなくてはいけないのでしょうか。
たしか以前、国際化XTermのトピックでこういった場合にどう表示を
するべきかについてkubotaさんという方がかなり悩ましげにしていた
記憶があります。そのために今のXTermではUTF-8の表示モードを
いくつか用意し、互換性のためにmediumモードという
アジア圏localeを特別視したモードが作られました。
アジア圏の後方互換性を重視した結果、XtermのUTF-8表示モードの
違いによって、同じUTF-8の文字列を表示した結果が異なることに
なりました。その結果、プログラマはあるUTF-8文字を全角で表示
するのか、半角で表示するのかを知ることはできないので、
なんとなく泥臭い処理を行わなくてはいけなくなりました。
アジア圏で使われるコンソールアプリケーションを作ってる人達が
こういう状況をヒイヒイいいながら何とか自前で吸収している姿を
想像すると、ほんとうにUTF-8化に未来なんてあるのかなって思います。
Re:UTF-8 (スコア:3, 参考になる)
Unicodeは現状の各文字コードの上位互換になるように作られてますけど、「半角」のロシア文字と「全角」のロシア文字を両方マッピングした文字セットが一つもないためにこの違いがUnicode上は消えてしまったわけですな。（推測ですが。全角ロ?マ字はUnicodeにあることからすれば正しいと思います。さらに個人的には、そもそもJISはロシア文字が全角だと言っていたのかと言う疑問があります。日本のメーカーがたまたまロシア文字等を全角にしただけだったりしないでしょうか。）
以上はUnicode派としてのなんで全角ロシア等文字がないのかの言い訳ですが、問題の解決にはつながりませんね。
まず、Unicodeの立場としては利用者側でどんな幅で表示しようが知ったことじゃありません。でも、等角フォントを前提に複雑な表示を行うncursesアプリケーション等ではそれは困るので…
…結局Unicodeからすれば文字コードに期待していることが多すぎると言うしかないと思います。
付け加えればエンコーディングの問題以前に現状の日本語フォントには半角のロシア文字は含まれていないし、欧文フォントには全角のロシア文字には含まれていないと言う問題もあります。
プログラマから、ターミナルに「こういう文字は全角で表示したい」あるいは「こういう文字は半角で表示したい」と伝えられる方法を作って、シェルが複数のフォントを組み合わせて（場合によっては半角と空白等を組み合わせて）対応するか、利用者の使用しているフォントの種類に合わせて個別アプリケーションが対応するしかないのでしょう。
Unicodeに悩んでいる作者さんはこんなことは、こんなことは百も承知でもっと進んだところで悩んでいるのでしょうが、そう言う問題があると知ったのは大変に個人的に参考になりました。
# For man might be free./人は自由になれるかもしれないから。
wcwidth() なる関数が (スコア:2, 参考になる)
libcにあったりするようで。
# ちゃんと実装されてれば、 引数としてあたえたワイド文字の tty 様表示環境で期待されるカラム数が得られる
きちんと setlocale(LC_ALL, "") するという前提ならば、 何とかなりそうな気が。
コードポイントのみならず、 ロケールの国・地域情報を加味した有意義なデータが得られそうな気がします。
# たとえば、同じキリル文字(当然同一のコードポイントね)でも、 LANG が日本語圏では2カラム、 ロシアなどでは1カラムと評価されるとかね
それよりも、もはや 構成バイト数 = 占有カラム数 は成立しないということを、 プログラマはちゃんと意識しなければならないのでは、 などと思ったり。
# もっとも、 EUC-JP の半角カナだって昔からそうだった訳ですが。
― 普段は FreeBSD 使いなので AC
Re:UTF-8 (スコア:1, 参考になる)
Re:UTF-8 (スコア:0)
誤った認識に基づいた発言をしてしまい、読む人に混乱を与えてしまいました。
申し訳ありませんでした…。
全ての私の発言に-1モデレートをお願いします。
Re:UTF-8 (スコア:0)
Anonymous Cowardの発言を全て-1にするようにという、大胆な提案でしょうか？
# -1してもらうためにAC
みんなが不満を持ってるなら (スコア:1)
＃言うだけなら私でもできます。
1を聞いて0を知れ!
そう思った人がやる。 (スコア:0)
確かに「正しい」なにかに向かって伽藍で作業という手もあるだろうけど。
それとEUCに戻せば解決というわけでもないしね。
まあ、決定打になるようなものがあれば変えてよいけど、現在は文字コードとかの話をするだけで「フレームのもと(-1)」になるような気がする。
Re:そう思った人がやる。 (スコア:0)
知ったか厨とは?
Re:UTF-8 (スコア:0)
Re:UTF-8 (スコア:1)
中国語とかハングル語とかも使っている人で、UTF-8で困っている人っていますか?どんな風に困っているか教えてもらえると嬉しいのです。
私は日本語と英語しか使えないんで(しかも両方結構不自由^_^;、私が考えていないような不便な所があるのかも知れない。
vyama 「バグ取れワンワン」
とりあえずもちつけ! (スコア:0)
Re:UTF-8 (スコア:0)
文字の定義を変更したら混乱するのはUTF-8に限らないでしょ。
EUCだってShiftJISだって何だって問題になる。
MLを見ていると (スコア:1, 興味深い)
Webの方と進行を同期できないなら、MLは廃止したほうが無難かと。
ちょっときつい言い方になるが、
core1の問題点が十分に洗い出されたようにも見えないし、
惰性で着てしまっている気がする。
Re:MLを見ていると (スコア:1)
少なくとも、Wikiの書き込みは、毎日報告されているし、それなりに進んでいます。
MLは、連絡ようとして使っており、基本はWebになるのではないかと思います。
また、惰性云々ですが、まあ、否定はしません。まだスタッフもCoreの全容を掴んでいるとは言い難いし、問題点を洗い出すに至っているとは思えていません。
ただ、Bugzilla設置作業中ですので、それで改善できるのではないかと思います。疑問、要望があるなら、どんどんスタッフMLにでも投げてください。
Re:MLを見ていると (スコア:1)
何がしたいかは日本語環境を改善が多くの割合にあると思います．
#ニュースリリースも参照で
ウェブとメーリングリストの進行と同期は具体的に出てくればなるべく前向きに検討します．
個人的にweb2ml(メール投げたら掲示板に，掲示板に投げたらメーリングリストに)のようなものは個人的にはメリットデメリットの点でやらない方がいいかなと．
#前述降りの通り異論多いに結構です．
否定できない部分もありますね．全く新規に技術的に魅力が山盛りみたいなディストリビューションではないところやその他諸々で技術に長けた人がわんさか居るわけでもないところその他もろもろで一時期よりテンションは落ちてるんだか落ち着いてるんだかかもしれません．個人的にはまぁぼちぼちとというところですが．
えりゅふ
よくきたblog [blog.poyo.jp]
をを！ (スコア:0)
前から気になってたんですけど、fedoraになってからただなのをいいことにfedora本がたくさん出てますよね。
で、アップデートの仕方とかも初心者向けに解説されているんですけど、初期状態だとyumは本家の鯖読みに行きますよね。
redhatのときは商用も兼ねてたのでよかったのかも知れませんがオプソ化された以上あまりただ乗りするのもどうかと思うのですが。
国内にもミラーはありますが、やはりお金儲けに使うんだから鯖ぐらい提供してくれてもよいのではないかと思うのですが。
リーダーがインプレスの方のようですが、その辺の業界の取りまとめや話し合いとかはできないものでしょうか？
強制する訳にも行かないでしょうけど。
Re:をを！ (スコア:2, 参考になる)
やっぱり国内のミラーではあるんですが、先日 fedora@linuxml.net のメーリングリストに流れたアナウンスに Ring ですが、本家のミラーを始めたと言うのがありましたよ。
これを yum.conf に書けば yum update では本家を読みに行かなくするようには出来ると思います。
おしゃっている趣旨に対してはちょっとはずしていますかね(^^;
[base]
name=Fedora Core $releasever - $basearch - Base
baseurl=http://www.ring.gr.jp/pub/linux/fedora/linux/core/$releasever/i386/os
[updates-released]
name=Fedora Core $releasever - $basearch - Released Updates
baseurl=http://www.ring.gr.jp/pub/linux/fedora/linux/core/updates/$releasever/i386
もちろん $releaserver や $baserch は使うバージョンに合わせないといけないと思います。
今、RHL9 で FC1 のマシンは起動していないので、実際の動作は試していません、ごめんなさい。
Re:をを！ (スコア:1)
この辺 [fedora.jp]参考になりますか?
えりゅふ
よくきたblog [blog.poyo.jp]
Re:をを！ (スコア:1)
プレスリリース作業、お疲れ様でございます。
一応 ML には時々書いてますし、最初からずっと読んでますので wiki も覗いてます。
そうそう、確かに Fedora JP Project FAQ [fedora.jp] は参考になりますね。
今まで通り Fedora JP Project Front Page [fedora.jp] がコミュニティの作業場所の中心と言うことで良いのですよね。
公私共に 4 月位まで多忙で死んでますが、そのうち砂遊びしてから顔を出そうと思ってます。
今後参加が増えると良いですね。
Re:をを！ (スコア:1)
えりゅふ
よくきたblog [blog.poyo.jp]
Re:をを！ (スコア:1)
むしろKNOPPIXとかの方が向いてるような。
手軽さではかなわんし。
初心者のタイプにもよるか。
これからLINUXにどっぷり浸かろうって人はこっちの方がいいかもですね。
Re:をを！ (スコア:0)
Re:をを！ (スコア:1)
ネタにマジレス（略）ってヤツかも知れないけど「オープン化」のことでしょう。
Sistina GFSはどうなってるの？ (スコア:0)
とあるんですが、このファイルシステムに対応する予定はあるんでしょうか？