Archive for the ‘Other’ Category

{ 2012.9.25 }

円マークについて

    はてなブックマーク - 円マークについて
    このエントリーをはてなブックマークに追加

    こんにちは。フクダです。

    ほんっと今更ですが。円マークについての問題です。

    今回の問題

    Windowsのブラウザで円マークが入れられなくね?

    というお話です。

    なんとなくスルーしていたのですが、気づけばIE8でもfirefoxでもChromeでもGoogleの検索フォームに円マークを入れようとすると、バックスラッシュになってしまっています。

    なんとなくの感覚ですが、バックスラッシュになるのって、Macの方じゃないの?て感じだったのですが
    手元にあるMac+Safariで試したところ、逆に円マークになってる?!

    \ ← これがWindowsで入力した円マーク
    ¥ ← これがMacで入力した円マーク

    ※Fusic Developers' Weblog では、入力はバックスラッシュで見えて、公開すると円マークでみえるらしいΣ(゚∀゚ノ)ノ

    調べたり、聞いているうちに二つの原因パターンがありました。

    その1:font-familyが違う


     サイトのfont-familyが円マークに対応していない場合です。
     この場合、WindowsとかMacとか関係なく バックスラッシュとして表示されます。

    その2:Macで半角円マークをキーを押したときの文字コードが違う


     実は使ってる文字コードが違うという事実!

    上に書いた円マークの文字コードを
    ココのサイトで調べてみました。
    結果が10進数なので、16進数になおすと

    \ (0x5C)← これがWindowsで入力した円マーク
    ¥ (0xA5)← これがMacで入力した円マーク

    になりました。
    そのため、Googleなどのサイトでは0x5Cをバックスラッシュ、0xA5を円マークとして表示しているのです

    Googleでみた円コード

    Googleでみた円コード

    ちなみに、通常エスケープ文字としては『0XC5』を使います。

    問題点


    これらをふまえて出てきた問題点は以下のような感じ。
    ■表示
    ・font-familyによって円マークがバックスラッシュとして表示されてしまう。
     金額表示なのにバックスラッシュとして表示されては意味がないです
     (まぁバックスラッシュとして表示されててもスルーしてしまってますが。。。)
    ■動作周り
    ・円マークとして登録したいのに、できない
    ・Macで円マークを登録したのに、Windowsで検索しようとすると文字コードが違うために検索に引っかからない
    ・サーバの処理によっては0xA5を全角円マークとして処理してしまったりする

    解決策


    表示については金額円マークには全角を使いましょう。ていうのが今のところの回避策のようです。
    なんてったって、Apple自体、金額表示は全角円マークつかってますからね

    処理については、フレームワークも実は考慮して作ってあったりするっぽいので、大問題にはならない気がします。
    処理を入れる必要があるのであれば、0xA5⇒0x5Cに変換して統一するかな?と思います。

      はてなブックマーク - JAWS-UGでAWS採用事例の話をしてきました
      このエントリーをはてなブックマークに追加

      Fusic 平田です。
      JAWS-UG 福岡勉強会のLT枠で、事例の話をしてきました。

      で、いくつか補足や訂正などなど。

      CloudFrontは不要?

      今のところS3が十二分に速いとは言え、当然CloudFrontのほうがその数倍は速いです。
      で、「外れました」と言ってましたが実際は今もCloudFrontで元気に動作しておりました。
      誤解を与えてしまい、大変申し訳ありません。。。

      ただまあ、東京リージョンのS3は国内からアクセスするとかなりの速度が出ます。
      シンガポールのS3とざっくり比較してみたら3.7倍くらい速かったですし、さくらVPS+Apacheと比較してもおおよそ同等でした。
      # 計算違いでなければ、HTTPで35~40Mbpsくらいは出ています。

      s3fsをちょっと補足

      公式はGoogle Codeのほうにあります。
      かなり駆け足で喋ったので、改めて資料を見ていただくのがいいと思いますが。
      実際にマウントしてみると、体感で分かるくらいのラグは生じます。
      今回は採用しましたが、場面によっては採用できないこともありそうです。

      ZENPRE for iPhone

      今回のLTはZENPRE+iPhoneで行いました。
      1/2倍速で聞きたかったと言われるくらいに駆け足でプレゼンしたのですが、3G回線でもほぼ問題なく。

      screen1

      アプリを起動して、右下の「設定」を選択すると

      「Fastest Mode」のON/OFFが切り替えられます。
      これはiPhone側にスライド画像を表示しないモードで、非常に高速です。
      ちゃっちゃとページめくる派なので、このモードなしでは生きていけません。
      今回のLTくらいのスピードでも気持ちよくプレゼンできます。:-)

      まとめ

      と言いたいんですが、特に事例2のほうは構成固まってなかったりもするので、まとまった時点でまた話ができればと思います。

        はてなブックマーク - 公開鍵暗号のちょっとした誤解
        このエントリーをはてなブックマークに追加

        初めまして。Fusicで副社長をしている浜崎です。

        社内全体が「副社長も書けよ」な雰囲気になり、なんとなく書くことになりました。

        納富と同様、とても長いこと技術から離れているので、さて何を書こうかと悩んだわけですが、少しさかのぼって、学生時代の社会インフラに関する研究の一環として取り組んでいた「暗号」について話したいと思います。当時に暗号を専門とする先生から得た知識なのですが、公開鍵暗号に関して、誤解されて広まっている情報についてです。

        公開鍵暗号とは?

        さて本題に入る前に、公開鍵暗号とはなんやねん?ということについて書いておきます。

        そもそも暗号というのは、ある情報を秘匿的にやりとりするための手段なのですが、公開鍵暗号もその手段の1つです。公開鍵暗号は、暗号化のために用いる「公開鍵」と復号化のために用いる「秘密鍵」という異なる別の鍵を用いることで成り立つ暗号方式のことです。これは1976年にデフィーとヘルマンによって発表されました。

        それまで暗号といえば、共通鍵暗号という方式が主流でした。これは、暗号化と復号化に同じ「共通鍵」を用いることで成り立つ暗号方式です。例えばお互い秘匿情報をやりとりする場合は、事前に「共通鍵」を共有しておき、その鍵で暗号化・復号化を行うことで秘匿情報のやりとりを成り立たせています。この概念は一般社会でも広く応用されている考え方で、例えば野球やバレーボールにおけるブロックサインなんかも広義ではその枠組みに入るんではないかと思います。

        ただ、この共通鍵暗号には問題がありました。それは前述した、事前に「共通鍵」を共有しておくことをどうやってするか?という配送問題です。共通鍵が漏れてしまった場合、それで暗号化されたものを第三者が復号化出来てしまうわけですから、当然共通鍵そのものも秘密にやりとりしなければなりません。じゃあまたそれを秘密に通信するために別の鍵を作って、またそれを秘密に・・なんてことをしてても一向に解決はしないわけです。また、例えば100人の人と別個に秘匿通信をする場合、管理すべき共通鍵は100通りとなり、それも煩雑です。

        そのような問題を解決したのが公開鍵暗号です。これは鍵の配送問題や管理の煩雑さを解決する手段としてとても有効なものです。フローは以下の通りです。

        1. 情報の受信者(以下A)は、暗号化用の鍵(公開鍵、以下P)と復号化用の鍵(秘密鍵、以下S)を作成する。

        2. 続いてAは、Pのみを広く公開する。SはA自身が厳重に管理する。

        3. Aに対して秘密の情報を送りたい送信者(以下B)は、公開されているPを用いて、情報を暗号化してAに送信する。

        4. 暗号化された情報を受け取ったAは、Sを用いて復号化する。

        この方法を用いることで、AさんはPを広く公開すればよいだけなので、配送問題がクリアされます。

        この公開鍵暗号には、ElGamal暗号や楕円曲線暗号等いくつかの方式がありますが、最もメジャーな方式は、1977年、つまり公開鍵暗号が発表された翌年に、Rivest、Shamir、Adlemanにより発表されたRSA暗号でしょう。これは素因数分解の困難さを利用したものなのですが、SSL通信等で用いられている方式です。ただこのRSA暗号が、本日の標題である誤解を引き起こしている要因になっているのです。

        公開鍵暗号の誤解

        その誤解は以下のようなものです。

        秘密鍵Sで暗号化したものは公開鍵Pで復号化できる

        これってよくよく考えると暗号化の意味がない(だって誰でも復号できるんで)わけなんですが、この記述がなされたものが多く出回っているのは事実です。例えば日本ベリサインの公開鍵暗号について解説したページでも同様の記載が見受けられます。

        このような誤解を招いた理由は、前述した公開鍵暗号方式の1つであるRSA暗号がそのような性質を持つためなのです。つまり、秘密鍵Sで暗号化したものを公開鍵Pで復号化する対称性の性質を持っているんですね。公開鍵暗号を代表する最もメジャーな方式がそのような性質を持つため、公開鍵暗号自体がそのような性質を持つと勘違いしてしまっているということです。実際に他の方式ではそのような性質を持たないものもありますんで、公開鍵暗号の定義としては問題ありかなと思います。

        とまぁ、つらつら書きましたが、私は暗号の専門外なのでうかつなことが書けないなぁ〜と思いながら最後まで来てしまいました。でも昔学んでいたことをほじくり返してみるのもいいですね。よい機会でした。では、みなさん、よいお年を!