アカウント名:
パスワード:
文字絵そのものが(きちんと見えれば)面白いかどうかはともかくとして、フォントがMSゴシックでないとメトリックが合わずに目茶苦茶に表示される、というのが致命的ですね。クロスプラットフォームというWWWの優れた性質を台無しにしています。
自分の環境と違う人も
# [\]←君にはこれが何に見える?
ここだけに反応。
VineLinux を 1.1 から使いはじめ、2.0CR 、 2.5CR と使い続けている私としては、最初の頃は半角バックスラッシュで表示されていたのが何時からか ( 2.5CR で RICOH のフォントが入ってから? ) 半角円記号になっていてちょっとだけ違和感を感じました。
半角バックスラッシュと言えば、昔知らずにメールの signature に使っていて、環境依存だと知って使うのを止めた記憶が。
UNIX 系使いは半角バックスラッシュに慣れている人が多いのではと勝手に思い込んでましたが、実際のところどうなんでしょう?
完全オフトピですが。
とりあえず kterm ぐらいはちゃんとバックスラッシュで表示してほしいと、東風フォント [keio.ac.jp] (kochi fixed) に変更してみました。
sl [srad.jp] の車輪もちゃんと表示されて、ちょっとうれしいです。
ついでに sl 本家 (下の方) [u-tokyo.ac.jp]、SL改造計画 [linet.gr.jp]
~ | \ の3つだけが違う。
違います。縦棒 "|" は,ASCII も JIS X 0201 も同じ縦棒です。 昔の端末やプリンターでは,ただの縦棒を:
区別するために, 真ん中に切れ目を入れた字形で表現したものもありましたが, 論理的には,ただの「縦棒」です。 ただの「縦棒」と,「真ん中に切れ目の入った縦棒」が区別されるようになったのは,ISO 8859-1 が出てきてからでしょう。 Ken Lundi が「日本語情報処理」とかでデマを流して以来, 鵜呑みにする人が増えたのは悲しい限りです。
嘘だと思った方, JIS X 0201 の最新版を入手して,"|" の文字名称 (個々の文字に割り振られた英語の名称) が,VERTICAL LINE (ただの縦棒) となっているか,BROKEN BAR (真ん中に切れ目の入った縦棒) となっているか,チェックしてみてください。
それから,1バイト英数字の範囲は,SHIFT-JIS は JIS X 0201 で EUC は ASCII だから違うものだ, という言い方も最近よく見ますが, Unicode 以前は, 「物理的には,0x5C のコードポイントの文字が円記号に見えるかもしれないが, 論理的にはバックスラッシュとして扱う」 という方式が通用していたわけで, それを,"\" が円記号 (YEN SIGN) かバックスラッシュ (REVERSE SOLIDUS) かを厳しく弁別する Unicode 以後の観点で見て, 「nkf のコード変換は間違っている」 とか言われるのも釈然としません。
皆さん,Unicode に毒されていませんか。
ここからは余談。昔から IBM 系メインフレームで使われてきた EBCDIC という符号化文字集合 (coded character set) がありまして, こいつの日本語版で EBCDIK というのがあったのですが, EBCDIC で "$" (ドル記号) のコードポイントを EBCDIK では "¥" (円記号) で置き換えていました。(お互い通貨記号なので,それが便利なこともあったのでしょう。)
で,某社のメインフレーム UNIX では EBCDIC/EBCDIK 端末で UNIX コマンドを打ち込むことができまして, 「円記号はバックスラッシュの置き換えだ」と思い込んでいた ASCII 系技術者は, 「円記号がドル記号の置き換えになっている」と思い込んだ EBCDIK 系技術者と話が通じなくて,いろいろ困ったものでした。 これを称して「裏円記号問題」と呼ぶ……っていうのは出鱈目なので信用しないように。
それから,1バイト英数字の範囲は,SHIFT-JIS は JIS X 0201 で EUC は ASCII だ から違うものだ,という言い方も最近よく見ますが, Unicode 以前は,「物理的に は,0x5C のコードポイントの文字が円記号に見えるかもしれないが,論理的にはバ ックスラッシュとして扱う」という方式が通用していたわけで,それを,"\" が円 記号 (YEN SIGN) かバックスラッシュ (REVERSE SOLIDUS) かを厳しく弁別する Unicode 以後の観点で見て,「nkf のコード変換は間違っている」とか言われるの も釈然としません。 皆さん,Unicode に毒されていませんか。
たしかに、いままでは日本国内だけで文字コードを考えればよかったのが、 Unicode の登場にともなって国際的な文字コードの整合性ということを 考えないといけなくなって、それで円記号とバックスラッシュの違いについて みんなが意識するようになった、というのは、あるかもしれません。
ですが、円記号とバックスラッシュが本来は別物であるというのは、 Unicode 登場以前だってそうですし、ISO-2022-JP だって区別しています。 ただ、日本国内だけで文字コードを議論していた時代には、 そんなの脳内変換しちゃえ、ということで、なあなあで済ませることが 可能だったけど、今後はその「なあなあ」を理解できない外国人とも つきあう頻度が上がってくる、というだけのこと。
ちなみに、円記号とバックスラッシュを同一視する(のと同じ効果がある) 規格といえば、JIS C で円記号をエスケープ文字にするということくらいの ものだと思うのですが、どうでしょうか?
実際には、その「なあなあ」をうまく明文化し、きちんとした運用規則として 確立する必要があると思います。でなければ、それこそ、Unicode の台頭によって日本の文字コード事情はめちゃくちゃにされてしまいます。 具体的には、文字コード変換ソフトの実装をどうするのか、ということに なってくると思います。
「なあなあ」って,それはもう,適当で曖昧でいい加減な日本人ですから :-)
問題は,
ってところにあるので,これを解消しない限りどうにもなりません。
対処方法は,
のどちらかしかないでしょう。
じゃあバックスラッシュ固定かというと、Windows も Macintosh も 0x5C は円記号なので、それを無視することは出来ないので却下。
Unicode に移行すればど
EUC-JP の 0x5C は、シフトJIS には変換不可能なはずなのに シフトJIS の 0x5C に変換してしまっています。 また、シフト JIS の 0x5C は、EUC-JP に変換不可能なはずなのに、 EUC-JP の 0x5C に変換してしまっています。
文字コードにまつわる話を、文字コードに基づくメディアを用いて おこなう、というのは難しいもんですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
環境依存が致命的 (スコア:1)
文字絵そのものが(きちんと見えれば)面白いかどうかはともかくとして、フォントがMSゴシックでないとメトリックが合わずに目茶苦茶に表示される、というのが致命的ですね。クロスプラットフォームというWWWの優れた性質を台無しにしています。
自分の環境と違う人も
Re:環境依存が致命的 (スコア:0)
> フォントのメトリックに依存したものを書かれるのはいやでしょう?
べつにー。
俺たちに見せる気は無いんだな、と思うだけ。
英語圏のアスキーアートは俺達に見せる気は更々無いんだなと。
そこら辺で既に悟ってます。
# [\]←君にはこれが何に見える?
Re:環境依存が致命的 (スコア:1)
ここだけに反応。
VineLinux を 1.1 から使いはじめ、2.0CR 、 2.5CR と使い続けている私としては、最初の頃は半角バックスラッシュで表示されていたのが何時からか ( 2.5CR で RICOH のフォントが入ってから? ) 半角円記号になっていてちょっとだけ違和感を感じました。
半角バックスラッシュと言えば、昔知らずにメールの signature に使っていて、環境依存だと知って使うのを止めた記憶が。
UNIX 系使いは半角バックスラッシュに慣れている人が多いのではと勝手に思い込んでましたが、実際のところどうなんでしょう?
Re:環境依存が致命的 (スコア:1)
完全オフトピですが。
とりあえず kterm ぐらいはちゃんとバックスラッシュで表示してほしいと、東風フォント [keio.ac.jp] (kochi fixed) に変更してみました。
sl [srad.jp] の車輪もちゃんと表示されて、ちょっとうれしいです。
ついでに sl 本家 (下の方) [u-tokyo.ac.jp]、SL改造計画 [linet.gr.jp]
Re:環境依存が致命的 (スコア:1)
Re:環境依存が致命的 (スコア:1, おもしろおかしい)
背面飛行中の戦闘機がロックオンした東京タワー
Re:環境依存が致命的 (スコア:0)
半角円記号(¥)。
/* 個人的には本当は半角バックスラッシュ(\)に見えてほしいAC */
この件について、歴史的経緯に詳しい人のフォローがあると嬉しいかも。
歴史的経緯 (スコア:2, 参考になる)
[ISO-646]
ASCIIの下位互換。いくつかの記号部分をとっぱらって独自定義用にした凶悪な仕様。
[JIS X0201]
ISO-646の独自定義用コードに各種記号を割り当てて日本の規格としたもの。ASCIIとは似て非なるものである。
それでもある程度ASCIIに近づけており、 ~ | \ の3つだけが違う。このなかでも特に \ は見た目が全然違うので問題の種。
[EUC]
ASCIIを原型に、他の文字セットを混在できるようにエンコードしたもの。
[ShiftJIS]
JIS-X0201を原型に、他の文字セットを混在できるようにエンコードしたもの。
# ACなのでAC
Re:歴史的経緯 (スコア:3, 参考になる)
違います。縦棒 "|" は,ASCII も JIS X 0201 も同じ縦棒です。 昔の端末やプリンターでは,ただの縦棒を:
区別するために, 真ん中に切れ目を入れた字形で表現したものもありましたが, 論理的には,ただの「縦棒」です。 ただの「縦棒」と,「真ん中に切れ目の入った縦棒」が区別されるようになったのは,ISO 8859-1 が出てきてからでしょう。 Ken Lundi が「日本語情報処理」とかでデマを流して以来, 鵜呑みにする人が増えたのは悲しい限りです。
嘘だと思った方, JIS X 0201 の最新版を入手して,"|" の文字名称 (個々の文字に割り振られた英語の名称) が,VERTICAL LINE (ただの縦棒) となっているか,BROKEN BAR (真ん中に切れ目の入った縦棒) となっているか,チェックしてみてください。
それから,1バイト英数字の範囲は,SHIFT-JIS は JIS X 0201 で EUC は ASCII だから違うものだ, という言い方も最近よく見ますが, Unicode 以前は, 「物理的には,0x5C のコードポイントの文字が円記号に見えるかもしれないが, 論理的にはバックスラッシュとして扱う」 という方式が通用していたわけで, それを,"\" が円記号 (YEN SIGN) かバックスラッシュ (REVERSE SOLIDUS) かを厳しく弁別する Unicode 以後の観点で見て, 「nkf のコード変換は間違っている」 とか言われるのも釈然としません。
皆さん,Unicode に毒されていませんか。
ここからは余談。昔から IBM 系メインフレームで使われてきた EBCDIC という符号化文字集合 (coded character set) がありまして, こいつの日本語版で EBCDIK というのがあったのですが, EBCDIC で "$" (ドル記号) のコードポイントを EBCDIK では "¥" (円記号) で置き換えていました。(お互い通貨記号なので,それが便利なこともあったのでしょう。)
で,某社のメインフレーム UNIX では EBCDIC/EBCDIK 端末で UNIX コマンドを打ち込むことができまして, 「円記号はバックスラッシュの置き換えだ」と思い込んでいた ASCII 系技術者は, 「円記号がドル記号の置き換えになっている」と思い込んだ EBCDIK 系技術者と話が通じなくて,いろいろ困ったものでした。 これを称して「裏円記号問題」と呼ぶ……っていうのは出鱈目なので信用しないように。
なあなあ (スコア:1, 参考になる)
たしかに、いままでは日本国内だけで文字コードを考えればよかったのが、 Unicode の登場にともなって国際的な文字コードの整合性ということを 考えないといけなくなって、それで円記号とバックスラッシュの違いについて みんなが意識するようになった、というのは、あるかもしれません。
ですが、円記号とバックスラッシュが本来は別物であるというのは、 Unicode 登場以前だってそうですし、ISO-2022-JP だって区別しています。 ただ、日本国内だけで文字コードを議論していた時代には、 そんなの脳内変換しちゃえ、ということで、なあなあで済ませることが 可能だったけど、今後はその「なあなあ」を理解できない外国人とも つきあう頻度が上がってくる、というだけのこと。
ちなみに、円記号とバックスラッシュを同一視する(のと同じ効果がある) 規格といえば、JIS C で円記号をエスケープ文字にするということくらいの ものだと思うのですが、どうでしょうか?
実際には、その「なあなあ」をうまく明文化し、きちんとした運用規則として 確立する必要があると思います。でなければ、それこそ、Unicode の台頭によって日本の文字コード事情はめちゃくちゃにされてしまいます。 具体的には、文字コード変換ソフトの実装をどうするのか、ということに なってくると思います。
Re:なあなあ (スコア:1)
「なあなあ」って,それはもう,適当で曖昧でいい加減な日本人ですから :-)
問題は,
ってところにあるので,これを解消しない限りどうにもなりません。
対処方法は,
のどちらかしかないでしょう。
Re:なあなあ (スコア:0)
じゃあバックスラッシュ固定かというと、Windows も Macintosh も 0x5C は円記号なので、それを無視することは出来ないので却下。
Unicode に移行すればど
それじゃ困る (スコア:1)
>論理的には,ただの「縦棒」です。
そりゃ困る!
それじゃバカボンのパパができないじゃないか!
|:3ミ
う~ん、やっぱし切れ目がないと雰囲気が出らんなぁ・・
円記号かバックスラッシュか (スコア:1, 参考になる)
- シフトJISには、半角円記号はあるが、半角バックスラッシュはない。
- EUC-JPには、半角バックスラッシュはあるが、半角円記号はない。
- ISO-2022-JP (いわゆるJIS) には、両方ある。(きちんと特定できる)。
いま、/. は EUC-JP で書かれている。 EUC-JP では、ISO-2022 で言う GL は (G0 経由で) US-ASCII であって JIS X 0201 ローマ字ではないから、0x5C は 半角バックスラッシュが正しく、半角円記号は間違い。以上。Re:円記号かバックスラッシュか (スコア:0)
正解吐ける奴ってどいつだ?
# Windowsがダメって言われたらそれまでだが
厳密には (スコア:0)
EUC-JP の 0x5C は、シフトJIS には変換不可能なはずなのに シフトJIS の 0x5C に変換してしまっています。 また、シフト JIS の 0x5C は、EUC-JP に変換不可能なはずなのに、 EUC-JP の 0x5C に変換してしまっています。
Re:厳密には (スコア:1)
こーゆーときは、どう処理するのが正解なんでしょうか?
てゆか、便宜上0x5cは現状維持の方がよさげな気がする。
ここで余計な処理入れると、\エスケープ使ってるソースコードが殲滅させられるし。
--
Ath'r'onならfloatあたりに自信が持てます
Re:厳密には (スコア:1)
iconv の仕様は知りませんが、かなり厳格だと思います。
> printf '\134' | iconv -f euc-jp -t shift_jis
iconv: (stdin): cannot convert
鵜呑みにしてみる?
Re:厳密には (スコア:0)
Re:厳密には (スコア:0)
変換できないコードは見なかったことにするのが一番。
Re:厳密には (スコア:0)
権威に従っとけ (スコア:1)
というものがあるので、
これを使っとけばこの業界的には幸せになれると思われ。
> てゆか、便宜上0x5cは現状維持の方がよさげな気がする。
もちろん現状維持( US-ASCII のバックスラッシュは JISX 0201 の円記号に変換される)だぞ。
# 他の業界については不明
# mishimaは本田透先生を熱烈に応援しています
他の例 (スコア:0)
あのうお前は何がしたいんですかと。
Re:他の例 (スコア:1, すばらしい洞察)
文字コードにまつわる話を、文字コードに基づくメディアを用いて おこなう、というのは難しいもんですね。