WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

絵文字のカラー表示

by WebSurfer 2019年6月11日 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 2017年8月13日 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

IE11 で[戻る]ボタンが使えない

by WebSurfer 2016年8月24日 10:37

ユーザーが Power Users グループに属していると IE11 の[戻る]ボタンが使えない(グレーアウトされる)ことがあるという話を書きます。

Power Users グループ

元は MSDN Forum の「IE11で戻るボタンが使えない」という表題のスレッドでの話です。

そのスレッドを読めば話はすぐわかるのですが、備忘録として自分のブログの記事にも書いておくことにしました。

簡単に話の内容を書くと・・・

IE11 にアップグレードしたら一部のドメインユーザーで IE11 の[戻る]ボタンが使えなくなる(グレーアウトされる)という問題が発生。

ググって調べてみると、ユーザーを Power Users グループから外したら問題が解決したという記事を発見。(ただし原因は不明)

MSDN Forum の質問者さんの方でも、ユーザーを Power Users グループから外すことで問題が解消した。

・・・ということです。

ネットの情報だけで自分で検証したわけではないし、そもそも何故 Power Users グループが影響するのか不明というのがアレですが、IE11 の[戻る]ボタンが使えないという問題に遭遇したら Power Users グループに属していないか調べてみるのがよさそうです。

Tags: ,

その他

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年3月  >>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar