ja_JP.UTF-8

Linux で ja_JP.UTF-8 ロケールで暮らす方法についてのスレです。

なんで UTF-8 の変換にエンディアンが関係するんdayo!
って一瞬思ったけど、iconv の内部的には一旦 UTF-16 とかにしてるのかな?
Apple のハックのせいなんなら普通の libiconv と比較してみたらいいんじゃねーの?
それか普通の libiconv にその UTF-8-MAC を追加する方向で修正してみるとか
...ってのができないわけね。
Mac OS X が使えるなら Mac OS X 上で変換してから他のプラットフォームに持って
いくんじゃ駄目なのか?

>>174
> configureもmakeも問題なくできるのだけれども、
> iconv -f UTF-8-MAC -t UTF-8 等としてもどうもうまく動かないんです。

How?

ja_JP.UTF-8 ロケールでeuc-jpのnfs鯖をマウントするときみんなどうやってるの？
（sambaや、webdav使えばできるんだけどネ、nfsでの解決策を教えてね）

問題が本当にエンディアンのせいなら、utf8mac_mbtowc() が呼んでいる
utf8_decodestr() の引数に UTF_REVERSE_ENDIAN をセットしてみたらいいかも。
ハードコーディングになっちゃうけど。
それで駄目だったら >>176 の回答待ちか。

>>176

http://www.opensource.apple.com/darwinsource/tarballs/other/libiconv-9.tar.gz
をダウンロードして、
./configure --enable-static=yes --enable-shared=no --disable-nls --prefix=/opt/mac
としてconfigureしてmakeして、スタティックリンクしたバイナリを作って実験してみました。

ls | iconv -f UTF-8-MAC -t UTF-8
で、NKDな文字がちゃんと出てくるか調べてみたのですが、めちゃくちゃな文字化けしか起こりませんでした…

>>178
UTF_REVERSE_ENDIANをセットしてみてもしなくてもですが、めちゃくちゃに文字が化けてしまいました。

一つ怪しいかなと思うのが、
utf8mac.h: In function `utf8mac_mbtowc':
utf8mac.h:1566: warning: passing arg 6 of `utf8_decodestr' makes integer from pointer without a cast
なんてwarningがでるんですが、もしかしてこれのせいでPowerPCでしか動かないコードになっていることなんです。

でもCが全くわからないので意味はわからないのですが…

>>179
気になったので試してみたけど、
http://www.opensource.apple.com/darwinsource/tarballs/other/libiconv-10.tar.gz
や
http://www.opensource.apple.com/darwinsource/tarballs/other/libiconv-13.tar.gz
なら

-#include <libkern/OSByteOrder.h>
+//#include <libkern/OSByteOrder.h>
+#include <byteswap.h>
+#define OSSwapInt16(x) bswap_16(x)
+#define __LITTLE_ENDIAN__

という変更でいけるみたい。

nkfの最新のCVS版で、
nkf -w --utf8mac-input hoge.txt
などとすればUTF-8-MACをUTF-8に変換できる・・・はずです。
うまくいかない場合は教えてください。

あけおめage

フェどらって、OSの仕様をかえればすぐにソフトの仕様もかわると思ったのかな？

「すぐに」とは思ってないんじゃない。

使っているOSがUTF-8なのかEUC-JPなのか
簡単に判別する方法はあるでしょうか？

とりあえず、今1CDのGeeXboXを日本語対応化してみていますが
USBメモリー(vfat)上のファイル名は正常に表示されますが
HDD上のファイルがうまくいっていません。

たぶん、このHDDへのファイル保存をVineでやっているので
未だEUC-JPのVineだってところか
あるいはGeeXboX側のmount optionの問題か…手詰り。

UTF-8標準に向かったディストリビューションには
ファイル名をUTF-8化するコマンドがあるようですが
とりあえず、Vineではapt-getはできないようで…

いっそ、UTF-8標準のディストリビューションを入れちゃうか？と思ったり。
それとも、FedoraCoreからconvmvのソースとってくるほうが速いのか？
どちらにしろ、もう遅刻する時間を過ぎているので出勤しまつ orz

ちなみに、GeeXboXはlibsmbなんとかやfstabが
ラムディスクイメージの中にあるので、今私には手が出せません。

#気の迷いでパソコン一般板にGeeXboXスレ立て公開中

age
OS が UTF-8 ってのは
UTF-8 対応のロケールが入っているかどうか？という意味なんでしょうかね。

>>187
だね。kernelはutf-8対応なんかしちゃいないよ。

>>188
ん？VFATとかsmbfsなどのNLSにUTF-8が入ってるけど？
他のUTF-8/16なOSとファイルレベルで互換とらないといけないFilesystemはカーネルレベルでNLSサポートしてますよん。

それドライバの話でしょ。カーネルからはNUL端の文字列にすぎないよ。

ドライバがカーネルかどうかなんでどうでもいいから

カーネルをソースからコンパイルするときに
ファイルシステムのエンコーディングを
UTF-8だのSJISだのEUCだの指定できるのはなんなんだろうね。

>>192
ファイルシステムドライバへの指定だから、どのみち>>191だとおもわれ

EUCで書かれたシェルスクリプトをUTF-8でごちゃごちゃいじって、
おなじファイルなのに容量が増えることに愕然としたりして、
それでもいじってとりあえず動くものができたんですが、

日本語の文字化け以外にはやう゛ぁイことって何も無いですよね?

おまえ

とりあえず、LOCALEの設定箇所を調べて
そこを確認すればわかるってことでいいようですね。

それはそうと、アクセス規制の一日の間に
convmvでUTF-8ファイル名にしたら当座の目的は解決。

ともかく、ありがとうございました。

はじめてRedHatES4いれてみた。

# /etc/init.d/xinetd reload
繹・秧莨若榛 [ OK ]

ってな出力がUTF-8ででてるっぽいんだけど
これってEUC-JPに変更できないのかなあ。
ES3まではEUC-JPだったのに。

>>197
Red Hat Enterprise Linux スレッド part 24
http://pc8.2ch.net/test/read.cgi/linux/1136544255/

玄箱を Debian 化して、locale を utf8 にして、日本語manを入れたら、
euc-jp で書いてあって文字化け。orz

gentooの事例だけど
ttp://wiki.gentoo.gr.jp/index.php?%5B%5Btips%BD%B8%5D%5D#content_1_5
ttp://www.jaro68.org/needlejuice/blog/206
ttp://www.sen2or.com/index.php?itemid=1003

>>192
ファイルシステムにエンコーディングは関係ない
ファイル名を決めるのはカーネルじゃないってわからない?

ファイルシステムにエンコーディングは関係あるし。

>>202
どういう意味だろう?
とあるロケールで使用する文字コードが
ファイル名として使える文字コードの範囲内に入ってれば
何の問題も無いと思うんだが

例えばUTF-8のディストリでも、シコシコ設定書き直せば
システム全体の文字コードをEUCにもSJISにもできるわけで

>>203
CONFIG_NLS_*
mount iocharset=*
を調べるか、黙って。

>>204
NLSやcharsetはエンコードと関係あるが
カーネルがエンコードしている事の証明にはならないわけで＾＾；
「黙って」ほしいなら
「お願いですからこれ以上つっこまないでください」と懇願した上で
お前が黙れｗ

つfs/nls/*.c, fs/*fs/*.c

>>205
んじゃ NLS や charset は何がつかってるの？
ファイルシステムはドライバでカーネルじゃないとか言うつもりかｗ

>>204
エンコードはしないが関係無くは無いって事か?
トンチが効いているが言い訳っぽいな…

たとえば'/'をディレクトリの区切りと見なしてるのは、ファイルシステム
だけじゃないと思うんだな。(思うだけでソース見て回ったわけじゃないが。)
とすると、8ビットクリーンな環境ならばファイル名がutf-8やeuc-jpは問題
ないが、iso-2022(-jp)やShift_JISを使うのには困る。

>>209
禿同。

>>208
ん? iso-2022-jpを使ってファイルを取扱うシステムなんてあんの

あらら極論を持ち出して・・・

File system 自身が '/' という「文字」を抱え込んでるってのか？

macでは':'
winでは'\'

まあ、/とか考えるまでもなく、ファイルシステムに文字エンコードは影響するし。

>>214
Windowsも内部的には'/'だよ

あほ

>>216
あ、そなの？知らなかった。

>>216
ソース

NT系列では'\'が本則みたいだねえ。システムコールはもちろんどちらでも
受け付けるけど。
>>219
この一連の議論参照

システムコールがどちらも受け付けるからといって、
内部の扱いかどうかなんてわからんだろ。
ソースかバイナリを追った結果でもどこかにでてるんなら別だけど。

おっと失礼。この一連の議論ね。
http://mail.python.org/pipermail/python-list/2003-September/185195.html

>>221
DOS2.11は/だったが、(ソースは見た)、今は全く違っていても不思議はないね。

>>222
もしかして、脳晦の容量不足している？

JFSのunicodeってなに?
UCS4?

無意味に煽ってる奴のほうがよっぽど顔悪く見える

>>225
そうやって無意味に煽るのはやめなさい。

>>224
UCS2かUTF-16だとおもわれ。

>>222
DOSは switcher を変えると / *も* 使えるようになるだけだ

日本語はさ、1カラム文字と2カラム文字しかないけど
他の言語には３カラム文字とか４カラム文字とかあるの？
端末上で半角３文字分とか４文字分の文字。

>>229
画面に出る時の幅のことを言っているの? プロポーショナルフォントは
W と i で幅が何倍も違うな。

はっ。しまった。あからさまな釣りか。

>>230
固定幅のフォントでの話です。
普通の日本語対応の端末エミュレータの場合そうでしょう？
端的に言って日本語以外だとwcswidthで3や4が返る可能性があるのかないのかなんですけど。

unicode とそうでないので混じってるみたいだけど、
emacs の HELLO ファイルみると
(debian だと /usr/share/emacs/22.0.50/etc/HELLO)
Hindi とか Malayalam とか Kannada とかの
フォントセットのところに3とか4の文字がある。

>>233
ああ、やっぱあるのか。カラム数４ってどんな文字だorz
ありがとー。ちょっと対応を考えないといけないな。

unicodeって、リガチャがあるから面倒くさい。死ね。

>>234
アラビア文字みたいに横に伸びる文字なんじゃないかな。
日本語も実際には伸びる時がある(「おーーーーい」という
時の「ーーー」の部分とか)が、それを普通の文語体の文章
ではあまり使わないから困らないだけだ。

>>236
なるほど。日本語も縦書きだと３カラム分消費する奴がありますよね。
おーーーいの「−−−」をしの長いようなので書く奴。

>>235
確かにUnicodeって色々面倒だとは思うけど
Unicodeに対応するだけで各国語に対応できるのは確かに便利だと思う。

各国語には対応できるけど多国語が微妙なんだよね。

多国語でなくて多言語って言ってほしいかな。

むはぁ

>>237
くの字点のことかな。繰り返しに使う。
普通は2文字分の長さではないかと。

でさ、ファイルシステムにエンコーディングは関係あるの？

実運用上は、そんなエンコーディングの都合よりもftpdの文字化けで困るんだよね。
こればっかりはクライアント側の問題だからサーバ側ではどうにもならないし。

将来的にutf-8に統一されるなら今更eucJP使いたくないけど、
上記の理由で1台はeucJP確実なので、他も統一しないと使い勝手が悪い。
→全てeucjpで稼動。

>>243
ftpdが漢字を返すの? あ、もしや漢字ファイル名のこと?

>>243
ああ、あれで困ってEUC-JPに戻さざるを得なかった。(FTPサーバー立ててるから)
だって、UPされたファイルかたっぱしから文字化けして(LINUX上で)
何がなんだか分からんし。

そりゃ「日本語ファイルUPすんな！」って言えばいいんだけど、実際UPする人いるしな。
UP元のWindows機のファイルを全部英数字にリネームしろ！ っていうのも横暴だし。

eucjpなディレクトリツリーをsambaでローカルにのみ共有して
smbmountでiocharset=utf8でマウントして特定場所のみeucjpで
メインはutf8を共存みたいな

そういや自宅では玄箱を utf8 にしてるな。
たまに Windows マシンから samba でアクセスするが、それは
ちゃんと設定してあってファイル名は玄箱側に utf8 で書かれる
ようになっている。通常は utf8 になっている Linux マシン
から nfs (autofs) で一部をマウントして使っている。

ftp ねえ。でも ftp を使ったとしても ftp クライアントが
utf8 のファイル名に対応してさえいればいいんだよね。
そういうのってまだないのかな?

8bitスルーなら問題ないでしょ。
readline使ったヤツとか。

利用者側にftpクライアントを指定する時点で不合格じゃない？

>>249
んなこたねえと思うが。

素朴な疑問なんだけど、ある文字が何カラムになるかがロケールで決定できる
と考えるのがそもそもの間違いであって、TerminfoとかTermcapみたいな物に
そこら辺を全部面倒みて貰う方がすっきりするんじゃないの？
ここで言ってる文字幅って結局端末に依存する情報でしょ？

できるかどうかは知らんけど

文字幅? 一応 Unicode には Halfwidth と名前の付いた文字はあるけどな。
まあ、端末やプリンタで等幅の時に半分で出ることが期待された文字という
ことなんだろうが、こんな半角文字は早く消えて欲しいものだ。

別にいわゆる半角文字に限らなくてもいいんでない？
端末によっては表示できない文字だってあるだろうし、それをどう扱うかは
端末が勝手に決めればいいんじゃないの？
結果として端末によっては、?で表示されたり、〓で表示されたり、\uXXXXで
エスケープして表示されたりするかもしれないけど、それって端末の勝手だよね？
最終的に端末で表示した時にズレなきゃそれでいいんだし、ロケールで面倒
みる必要はないと思うんだけどな。
まあ、代替文字として何が表示されてるか分からないと困る場合はあるかも
しれないから、そういう時は代替文字を端末データベースに問い合わせて
教えて貰えればそれで済むんじゃない？
なんかおかしな事言ってる？

Unicode Standard Annex #11
East Asian Width
http://www.unicode.org/unicode/reports/tr11/

Draft Unicode Technical Report #30
Character Foldings
http://unicode.org/reports/tr30/

合字があるから、面倒くさいんだよ。

>>216-222
内部を覗いて見ないと分からないけど、
Win32 API では、"\" が本則っぽいな。

ファイル名の先頭に \\?\ を付けると解釈が厳格になる。
その時、"/" を受けつけなくなる。


NTFS と VFAT はファイル名は UTF-16 で格納すると決まっていて、
API やカーネル内部も UTF-16 で統一されてるから、
その点では頭を抱えずに済んでる。

Debian の次期バージョンは UTF-8 らしいけど、どんな感じになるだろう。

UNICODE も弱点は多いけど他の良い手段が思い当たらないので、
UNICODE 自身の改良に期待するしかないと思っている。

>>256 馬鹿発見

バックスラッシュと\が同じ文字コードだったとか
聞いた気がしたんだが…

勘違い？

で？

>>258
バックスラシュと\は同じコードだけど、
スラッシュと\は違うコードで、
今回の話しはスラッシュと\の話しね。

>>260
> バックスラシュと\は同じコードだけど、

ムチャ言うなよ。

>>260
http://ja.wikipedia.org/wiki/Unicode#.E6.97.A5.E6.9C.AC.E8.AA.9E.E7.92.B0.E5.A2.83.E3.81.A7.E3.81.AEUnicode.E3.81.AE.E8.AB.B8.E5.95.8F.E9.A1.8C

俺、今、Linux からおちゅ〜しゃでこのスレ見ているんだけど、
\ はバックスラッシュとして表示されます(円マークではない)。

その状態で読むとみんなして変な文章書いているように見える。w

俺、今、英語版Windows からIEでこのスレ見ているんだけど、
\ はバックスラッシュとして表示されます(円マークではない)。

その状態で読むとみんなして変な文章書いているように見える。w

俺、今、(かん高い声で！)、navi2ch！

>>262
僕もそこを見た上でレスした。
UNICODEでは本来は 半角の＼ と 半角の￥ が区別されるのは知っているよ。
しかし、

> Unicodeを利用するアプリケーションは
> 0x007F以下のコードに関しては移動させないと言う
> 暗黙のルールができている。

この事実があるから区別されてないと書いたわけです。
（Windows も Linux も区別していない。）

>>261
ムチャなことが現実になっているから
小さいながら問題になってしまっているのが悩ましい。

WAVE DASH - FULLWIDTH TILDE問題
は、海外のCDDBを利用する僕も影響を受けている。

>>266
区別していない？バックスラッシュとバックスラッシュは同じ文字なのに、どう区別するんだよ？

何がどういう風に問題なのかわからん。

SJISはともかく、EUC-JPも使い分けられないんだっけ?
ISO-2022-JPは問題ないよね。

iso-2022-jp の半角部分は jis x 0201 だから、
\ は円マークだよ。
euc-jp は半角カナ以外の半角部分は ascii らしいので
\ はバックスラッシュだと思う。

>>270
前半は嘘というかミスリーディングというか……、
ISO-2022-JPがASCIIを書けないとでも思ってんのかいな。
生半可な聞きかじりを垂れ流す前に考えるなり調べるなりしような。

Emacsで新しいファイルを作って、次の一行を入れて保存し開き直してみ。
\^[(J\^[(B
(^[はESCなのでEmacsだとC-q ESCで入力)
一つめはバックスラッシュに、二つめは円記号になるから。

すまん。
http://ja.wikipedia.org/wiki/ISO-2022-JP
ここに書いてなかったから勘違いしたよ。
http://www.ietf.org/rfc/rfc1468.txt
こっちみたらちゃんと ascii 入ってるわ。

http://www.iana.org/assignments/character-sets

>>272
「ISO646の国際基準版図形文字」って ASCII のことだろ？