WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

絵文字のカラー表示

by WebSurfer 11. June 2019 12:18

Unicode 絵文字の表示が IE11 と Edge で異なるという話を書きます。異なるというのは絵文字用のカラーフォントの指定が無くても Edge はカラー表示されるが、IE11 では白黒になるということです。

Segoe UI Emoji 指定

ちなみに、Edge 以外のブラウザでも Chrome, Firefox, Opera はカラーフォント指定無しでカラー表示されます。

(確認したブラウザはこの記事を書いた時点の最新版で、Windows 10 Pro 64-bit バージョン 1903 上で動く、IE11 11.116.18362.0, Edge 44.18362.1.0, Chrome 75.0.3770.80, Firefox 67.0.1, Opera 60.0.3255.151 です)

Wondows OS での Unicode 絵文字のカラーフォントは Windows 8.1 からサポートされるようになり、そのフォント名は Segoe UI Emoji といいます。

ただし、Unicode 絵文字全部のフォントが実装されているわけではなく、サポートされているカラー文字は 743 文字のみだそうです。(全部で 2344 文字だそうです)

詳しくは @IT の記事「OpenTypeカラーフォント」の "Windowsの新しいカラーフォント" のセクションに書いてありますので読んでください。

Segoe UI Emoji がサポートしている絵文字については、Windows 8.1 以降なら IE11 で font-family に "Segoe UI Emoji" を指定すれば上の画像のようにカラーで表示されます。

上の画像は紹介した @IT の記事からダウンロードできるサンプルコードを IE11 に表示させたものです。興味がありましたらダウンロードして、いろいろなブラウザで試してみると良いと思います。

font-family に "Segoe UI Emoji" を指定しない場合は IE11 では以下の画像のように白黒になります。(このフォントは何か不明ですが Segoe UI Symbol ではないかと思われます)

IE11 でフォント指定なし

ところが、Edge の場合はフォントの指定は一切無しで以下の画像のように大多数の絵文字がカラー表示されます。Chrome, Firefox, Opera も同様です。

Edge でフォント指定なし

以前は Edge でもフォントに "Segoe UI Emoji" を指定しない場合は IE11 同様白黒表示だったのですが、2017 年の 6 月頃から自動検出してカラー化するようになったようです。

その経緯は Microsoft Developer Issue #7900499 の Make emoji look good without explicit "Segoe UI Emoji" assignment にありますので読んでください。

上の記事が書かれた 2016 年 6 月ごろは Edge もフォント指定 "Segoe UI Emoji" がないと白黒表示だったそうです。(当時は Chrome もだめで、Firefox だけは自動検出してカラー化していたそうですが)

それが、MICROSOFT EDGE TEAM からの回答に "Nolan L. Jan 15, 2017 This is fixed in Edge 15.15010.1002." とあるように、Edge では自動検出が可能になって、font-family に "Segoe UI Emoji" を指定しなくてもカラー化されるようになったようです。ちなみに、Chrome は 53 から対応したそうです。

IE11 は "Note that IE11 still has the black-and-white emoji, though" と書いてある通りで、カラー化するには依然として font-family に "Segoe UI Emoji" の設定が必要です。

なお、font-family に "Segoe UI Emoji" の設定をした場合と、その設定はせずブラウザ任せにした場合は若干カラー化の結果が異なります。上の一番上と一番下の画像を見比べてみてください。

Tags: , , ,

その他

IE11 と Referer

by WebSurfer 13. August 2017 17:02

ASP.NET 4 の Web Forms アプリで、クエリ文字列に日本語を含めて要求をかけた場合、Windows 10 の IE11 と Edge ではポストバックの際 Referer が送信されないという話を書きます。(ASP.NET 4.5 では問題は解消されています。ASP.NET 3.5 以下は未確認です)

Fiddler によるキャプチャ

そもそもの原因は Windows 10 の IE11 や Edge ではなく、ASP.NET 4(3.5 以前も?・・・未確認です)が応答の form 要素に設定する action 属性にあるようです。

例えば、IE11 のアドレスバーに直接以下の URL(クエリ文字列は "日本語" を UTF-8 のパーセントエンコードしたものです)を入力して直接ページを GET 要求したとします。

http://aspnet4site/test.aspx?P1=%e6%97%a5%e6%9c%ac%e8%aa%9e

そうすると、ASP.NET により応答の form 要素の action 属性に設定される URL は以下のようになります。

action="./test.aspx?P1=%u65e5%u672c%u8a9e"

つまり、要求 URL のクエリ文字列の "日本語" は UTF-8 のパーセントエンコーディングなのに、応答の form 要素の action 属性に設定されるのは Unicode のパーセントエンコーディングになってしまいます。そこに問題があるようです。

具体的には下にアップした簡単なサンプルのページ test.aspx で再現できます。

上の画像は、UTF-8 でパーセントエンコーディングした "日本語" をクエリ文字列に含めた URL を IE11 のアドレスバーに直接入力して test.aspx を要求し、表示されたページで 2 回ポストバックを行ったときの Fiddler によるキャプチャ画像です。

上の画像の #1 が初回の要求・応答で、#3 が 1 回目のポストバック、#4 が 2 回目のポストバックの際の要求・応答です。

問題は 2 回目のポストバックのときで、ブラウザからリファラが送信されません。Edge も同様で 2 回目のポストバックの際はリファラは送信されません。

どのような動きになるかと言うと・・・

#1 の初回要求に対して ASP.NET が返す応答の form 要素の action 属性に同じページの URL が設定されますが、URL に含まれるクエリ文字列の "日本語" は Unicode のパーセントエンコーディング %u65e5%u672c%u8a9e となってしまいます。

なので、1 回目のポストバックの時は要求 URL に含まれるクエリ文字列は %u65e5%u672c%u8a9e となります。上の画像の #3 を見てください。

ただし、1 回目のポストバックの際にブラウザから送信されるリファラは、最初の要求の URL(すなわちアドレスバーに直接入力した URL)になります。つまり、クエリ文字列の "日本語は" UTF-8 のパーセントエンコーディングなので問題なくリファラとして送信されます。問題は 2 回目以降です。

2 回目のポストバックの時(上の画像の #4)は、1 回目のポストバックの際の要求 URL(すなわちクエリ文字列の "日本語" が %u65e5%u672c%u8a9e)をリファラとして送信するはずですが、Windows 10 の IE11 と Edge では送信されません。3 回目、4 回目も同様です。

Microsoft の公式文書が見つけられないので想像ですが、Windows 10 の IE11 と Edge ではセキュリティ対策が強化され、URL に UTF-8 として解釈できないコードがあるとリファラを送信しないということではないかと思っています。

ちなみに、Windows 7 の IE11 では %u65e5%u672c%u8a9e となってしまっていてもリファラは送信されるそうです(聞いた話で未検証・未確認)。Chrome 60.0.3112.90, Firefox 54.0.1 では %u65e5%u672c%u8a9e でも送信されることは確認しました。

やはり、URL にはクエリ文字列を含めて ASCII 文字のみ使用することで徹底するのがよさそうです。

サンプルページ test.aspx

<%@ Page Language="C#" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        if (Request.UrlReferrer != null)
        {
            Label1.Text = Request.UrlReferrer.ToString();
        }
        else
        {
            Label1.Text = "無し";
        }
    }
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <h1>Page B</h1>
    <asp:Button ID="Button1" runat="server" Text="Button" />
    <br />
    UrlReferrer: 
    <asp:Label ID="Label1" runat="server"></asp:Label>
    </form>
</body>
</html>

Tags: , ,

ASP.NET

Visual Studio で Edge 利用

by WebSurfer 18. February 2017 14:26

先日買った Windows 10 Pro 64-bit のノート PC に旧マシンから開発環境を移していますが、Visual Studio で開発中の Web アプリを Edge で開けないという問題に遭遇しました。一応解決したので、自分が行った解決方法を備忘録として書いておきます。

Windows 10 には Microsoft Edge という新しいブラウザが標準として搭載されています。

その Edge を使うと、Visual Studio から開発中の Web アプリを開けないだけでなく、Edge を単独で立ち上げてアドレスバーにローカル IIS で動くように設定した Web アプリの URL を入力しても表示されません。

ググって調べてみると、Edge はセキュリティが厳しくなって、ローカルホスト(ホスト名に関係なく IP アドレス 127.0.0.1 がアクセス先のホスト)へのアクセスが制限されているそうです。

解決策として、Edge のアドレスバーに about:flags と入力して表示される「開発者向け設定」で[ローカルホスト ループバックを許可する]にチェックを入れて Edge を再起動するという記事がいくつか見つかりました。

ローカルホストループバックの許可

で、早速自分もやってみました・・・が、ダメでした。(涙) 依然として Edge はローカルホストにはアクセスできません。当然 Visual Studio からローカルホストの Web アプリを開くこともできません。

さらにググって調べてみると、コントロールパネルから開く「インターネットオプション」で、ローカルイントラネットゾーンに含めるサイトの定義を変更するという記事を見つけました。

イントラネット Web サイトの設定

具体的には上の画像のように、[セキュリティ]タブ ⇒[ローカルイントラネット]⇒[サイト(S)]で表示される「ローカルイントラネット」ダイアログで[ほかのゾーンに指定されてないローカル (イントラネット) のサイトをすべて含める(Z)]のチェックを外します。

結果、Visual Studio 2010 / 2015 ともローカルホストの Web アプリを Edge で開くことができるようになりました。もちろん Edge を単独で立ち上げてアドレスバーにローカルホストの URL を入力しても表示できます。

Edge でのローカルホストサイト表示

上の画像は、Visual Studio 2015 のテンプレートを使って自動生成させたインターネット用 Web サイトアプリケーションです。

ローカル IIS 上でホスト名 websiteproject.com で動くように設定し、hosts ファイルでそのホスト名の IP アドレスを 127.0.0.1 に設定し、Visual Studio 2015 でサイトを開いて実行させています。

(ググって調べた記事の中に CheckNetIsolation.exe コマンドを使って設定するというものがいくつかありました。Edge のアドレスバーに about:flags として設定できなかった古いバージョンではそれを使っていたようです。なお、CheckNetIsolation.exe コマンドが「インターネットオプション」の変更まで行ってくれるかどうかは分かりません)

Tags: , ,

DevelopmentTools

About this blog

2010年5月にこのブログを立ち上げました。その後 ブログ2 を追加し、ここは ASP.NET 関係のトピックス、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  June 2019  >>
MoTuWeThFrSaSu
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

View posts in large calendar