パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

/.-Jでもたまに文字絵を見かけるが」記事へのコメント

  • 文字絵そのものが(きちんと見えれば)面白いかどうかはともかくとして、フォントがMSゴシックでないとメトリックが合わずに目茶苦茶に表示される、というのが致命的ですね。クロスプラットフォームというWWWの優れた性質を台無しにしています。

    自分の環境と違う人も

    • > Windowsユーザだって、Windows以外で使われているある
      > フォントのメトリックに依存したものを書かれるのはいやでしょう?
      べつにー。
      俺たちに見せる気は無いんだな、と思うだけ。

      英語圏のアスキーアートは俺達に見せる気は更々無いんだなと。
      そこら辺で既に悟ってます。
      # [\]←君にはこれが何に見える?
      • by Anonymous Coward on 2003年02月24日 19時25分 (#266753)
        》 # [\]←君にはこれが何に見える?

        半角円記号(¥)。

        /* 個人的には本当は半角バックスラッシュ(\)に見えてほしいAC */

        この件について、歴史的経緯に詳しい人のフォローがあると嬉しいかも。
        親コメント
        • 歴史的経緯 (スコア:2, 参考になる)

          by Anonymouse Coward (13650) on 2003年02月24日 21時16分 (#266833) ホームページ
          ちょっと変かも。識者のツッコミ歓迎。

          [ISO-646]
          ASCIIの下位互換。いくつかの記号部分をとっぱらって独自定義用にした凶悪な仕様。

          [JIS X0201]
          ISO-646の独自定義用コードに各種記号を割り当てて日本の規格としたもの。ASCIIとは似て非なるものである。
          それでもある程度ASCIIに近づけており、 ~ | \ の3つだけが違う。このなかでも特に \ は見た目が全然違うので問題の種。

          [EUC]
          ASCIIを原型に、他の文字セットを混在できるようにエンコードしたもの。

          [ShiftJIS]
          JIS-X0201を原型に、他の文字セットを混在できるようにエンコードしたもの。
          --


          # ACなのでAC
          親コメント
          • Re:歴史的経緯 (スコア:3, 参考になる)

            by numa (4467) on 2003年02月26日 3時03分 (#267945) ホームページ 日記
            ~ | \ の3つだけが違う。

            違います。縦棒 "|" は,ASCII も JIS X 0201 も同じ縦棒です。 昔の端末やプリンターでは,ただの縦棒を:

            • 数字の "1" (いち) や,
            • 小文字の "l" (エル) や,
            • 大文字の "I" (アイ) と

            区別するために, 真ん中に切れ目を入れた字形で表現したものもありましたが, 論理的には,ただの「縦棒」です。 ただの「縦棒」と,「真ん中に切れ目の入った縦棒」が区別されるようになったのは,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, 参考になる)

              by Anonymous Coward on 2003年02月26日 11時33分 (#268105)
              それから,1バイト英数字の範囲は,SHIFT-JIS は JIS X 0201 で EUC は ASCII だ から違うものだ,という言い方も最近よく見ますが, Unicode 以前は,「物理的に は,0x5C のコードポイントの文字が円記号に見えるかもしれないが,論理的にはバ ックスラッシュとして扱う」という方式が通用していたわけで,それを,"\" が円 記号 (YEN SIGN) かバックスラッシュ (REVERSE SOLIDUS) かを厳しく弁別する Unicode 以後の観点で見て,「nkf のコード変換は間違っている」とか言われるの も釈然としません。

              皆さん,Unicode に毒されていませんか。

              円記号とバックスラッシュの違いについては、べつに Unicode に毒されているというわけではないと思います。

              たしかに、いままでは日本国内だけで文字コードを考えればよかったのが、 Unicode の登場にともなって国際的な文字コードの整合性ということを 考えないといけなくなって、それで円記号とバックスラッシュの違いについて みんなが意識するようになった、というのは、あるかもしれません。

              ですが、円記号とバックスラッシュが本来は別物であるというのは、 Unicode 登場以前だってそうですし、ISO-2022-JP だって区別しています。 ただ、日本国内だけで文字コードを議論していた時代には、 そんなの脳内変換しちゃえ、ということで、なあなあで済ませることが 可能だったけど、今後はその「なあなあ」を理解できない外国人とも つきあう頻度が上がってくる、というだけのこと。

              ちなみに、円記号とバックスラッシュを同一視する(のと同じ効果がある) 規格といえば、JIS C で円記号をエスケープ文字にするということくらいの ものだと思うのですが、どうでしょうか?

              実際には、その「なあなあ」をうまく明文化し、きちんとした運用規則として 確立する必要があると思います。でなければ、それこそ、Unicode の台頭によって日本の文字コード事情はめちゃくちゃにされてしまいます。 具体的には、文字コード変換ソフトの実装をどうするのか、ということに なってくると思います。

              親コメント
              • by numa (4467) on 2003年02月27日 22時53分 (#269246) ホームページ 日記

                「なあなあ」って,それはもう,適当で曖昧でいい加減な日本人ですから :-)

                問題は,

                • 1つのコードポイント (0x5C) に2つの意味 (バックスラッシュと円記号) をつけている
                • どちらか一方だけならともかく,両方の意味で使っている

                ってところにあるので,これを解消しない限りどうにもなりません。

                対処方法は,

                • 0x5C の意味を一方に固定し,もう一方の字が使いたいときは何かしらのエスケープを使う (0x5C を円記号に固定するなら,C プログラムのバックスラッシュは徹底的に "??/" で代用するとか。でも,C はいいけど UNIX の sh がバックスラッシュを要求したりするので,この方法はすぐ破綻しますね)
                • 両方の文字がある別の文字コードに移行する (含 Unicode)

                のどちらかしかないでしょう。

                親コメント
              • by Anonymous Coward
                今後は、日本国内だけで都合がよければOKというような解決策は「解決策」とは看做されなくなることでしょう。ですので、円記号固定、という策は却下。

                じゃあバックスラッシュ固定かというと、Windows も Macintosh も 0x5C は円記号なので、それを無視することは出来ないので却下。

                Unicode に移行すればど

            • by primavera (9253) on 2003年02月27日 11時13分 (#268709)
              >真ん中に切れ目を入れた字形で表現したものもありましたが,
              >論理的には,ただの「縦棒」です。

              そりゃ困る!
              それじゃバカボンのパパができないじゃないか!

                |:3ミ

              う~ん、やっぱし切れ目がないと雰囲気が出らんなぁ・・
              親コメント
        • by Anonymous Coward on 2003年02月24日 19時45分 (#266768)
          • シフトJISには、半角円記号はあるが、半角バックスラッシュはない。
          • EUC-JPには、半角バックスラッシュはあるが、半角円記号はない。
          • ISO-2022-JP (いわゆるJIS) には、両方ある。(きちんと特定できる)。
          いま、/. は EUC-JP で書かれている。 EUC-JP では、ISO-2022 で言う GL は (G0 経由で) US-ASCII であって JIS X 0201 ローマ字ではないから、0x5C は 半角バックスラッシュが正しく、半角円記号は間違い。以上。
          親コメント
          • じゃあNetscape7.02もIE6SP1も、両方間違ってるって事なのね。
            正解吐ける奴ってどいつだ?

            # Windowsがダメって言われたらそれまでだが
            • by Anonymous Coward
              nkfやqkcのような、EUC-JP ←→ シフトJIS の変換ソフトでさえ、 間違ったことをやっています。

              EUC-JP の 0x5C は、シフトJIS には変換不可能なはずなのに シフトJIS の 0x5C に変換してしまっています。 また、シフト JIS の 0x5C は、EUC-JP に変換不可能なはずなのに、 EUC-JP の 0x5C に変換してしまっています。

              • EUC-JP の 0x5C は、シフトJIS には変換不可能なはずなのに シフトJIS の 0x5C に変換してしまっています。 また、シフト JIS の 0x5C は、EUC-JP に変換不可能なはずなのに、 EUC-JP の 0x5C に変換してしまっています。
                先生!
                こーゆーときは、どう処理するのが正解なんでしょうか?

                てゆか、便宜上0x5cは現状維持の方がよさげな気がする。
                ここで余計な処理入れると、\エスケープ使ってるソースコードが殲滅させられるし。
                --

                --
                Ath'r'onならfloatあたりに自信が持てます
                親コメント
              • by tix (7637) on 2003年02月28日 21時05分 (#269894) ホームページ
                0x5C が 0x5C に変換できてしまってはいけない場合は、 iconv を使いましょう。
                iconv の仕様は知りませんが、かなり厳格だと思います。

                > printf '\134' | iconv -f euc-jp -t shift_jis
                iconv: (stdin): cannot convert
                --
                鵜呑みにしてみる?
                親コメント
              • by Anonymous Coward
                厳密に処理せずに、間違っていることを承知の上で、 ええかげんに処理するのがいいんじゃないでしょうか。
              • by Anonymous Coward
                下手に処理すると、EUC -> SJIS -> EUCとかしたときに元と違う物が出来て困ります。
                変換できないコードは見なかったことにするのが一番。
              • by Anonymous Coward
                ええ、EUC-JP → ISO-8859-11 → EUC-JP と変換すると、 もとと違うものになります。あたりまえですが。それと一緒と思えばいいのです。
              • 「TOG日本語ベンダ協議会推奨日本語EUC・シフトJIS間コード変換仕様」
                というものがあるので、
                これを使っとけばこの業界的には幸せになれると思われ。

                > てゆか、便宜上0x5cは現状維持の方がよさげな気がする。

                もちろん現状維持( US-ASCII のバックスラッシュは JISX 0201 の円記号に変換される)だぞ。

                # 他の業界については不明
                --
                # mishimaは本田透先生を熱烈に応援しています
                親コメント

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

処理中...