// 無料ツール · HTML ビューア
HTML ビューア
.html ファイルを開くか HTML を貼り付けると、その場で描画します。サンドボックスの枠で、スマートフォン・タブレット・デスクトップの 3 つの幅に切り替えられ、挙動が怪しいところは行番号つきで並びます。無料、即時、登録不要。ファイルはブラウザの外に出ません。
他の言語:EnglishDeutschEspañolFrançais日本語한국어Português (Brasil)繁體中文
.html ファイルをこの枠のどこかにドラッグするか、選んでください。FileReader でこのタブの中だけで読み込み、そこから先へは出しません。
描画は入力の 0.3 秒あとを追いかけます。指摘のほうはすぐ更新されます。
スクリプトを許可し、同一オリジンのアクセスを与えないサンドボックスの枠です。中の HTML は動きますが、このページには触れません。幅を選ぶと、スマートフォンやタブレットでのレイアウトが見られます。
HTML ファイルをブラウザで表示する手順
3 ステップ、どれもアップロードを伴いません。描画エンジンも指摘もこのページの中の 1 本のスクリプトなので、ネットワークを切っても動きます。
- HTML を開く。 .html ファイルを枠にドラッグするか、ファイル選択を使うか、HTML をそのまま貼り付けてください。ファイルはブラウザの FileReader API で読み込むので、どこにも転送されません。
- 見て、そのあと狭くして見る。 描画はサンドボックスの枠に出ます。スマートフォンなら 360px、タブレットなら 768px に切り替えてください。同じ HTML を、レイアウトが崩れがちな幅で確かめられます。
- 下の指摘を読む。 指摘には必ず出どころの行番号が付きます。枠から届かない参照、安全なページが捨てる http の画像、狭い表示を実機より良く見せてしまう viewport の欠落。
このビューアの描画のしかた
HTML は srcdoc でそのまま iframe に入ります。sandbox="allow-scripts" を付け、allow-same-origin は意図的に付けていません。実際上の意味は 3 つです。スクリプトは動くので、読み込み時に自分自身を組み立てるページはちゃんと組み上がります。枠は独自の不透明なオリジンにいるので、中身はこのページも、その保存領域も、Cookie も読めません。そして公開ホストから取ってくる CSS・フォント・画像は普通に読み込まれるので、CDN の上に作られたページは訪問者が見るのと同じ姿になります。
意図的に解決しないものが 2 種類あり、それは黙ってではなく指摘として出します。元のファイルの隣にあるもの——style.css、img/hero.png——は、枠の中に解決の基準になるフォルダがありません。自分のファイルシステムへの参照は、どのブラウザのタブでも読み込まれません。これはブラウザ側の制約で、こちらの都合ではありません。スタイルが当たっていないように見えたら、CSS を探しに行く前に指摘を読んでください。
日本語が文字化けするとき、何が起きているのか
ここが日本語のファイルでいちばん引っかかるところで、しかも仕組みははっきりしています。ファイルを選ぶと FileReader.readAsText() で読み込みますが、この API はバイト列をつねに UTF-8 として解釈します。UTF-8 で保存されたファイルなら何も起きません。Shift_JIS（CP932）や EUC-JP、ISO-2022-JP で保存された古いファイルだと、日本語のバイト列が UTF-8 として不正なので、本文が「�」（U+FFFD）や意味のない記号の羅列になります。
不思議なのは、同じファイルをダブルクリックするとちゃんと読めることです。魔法ではありません。ブラウザが自分でファイルを開くときは、バイト列と <meta charset> の宣言を見て符号化方式を決めます。FileReader はそれをしません。つまり、デスクトップでは正しく見えるのにここで化けるファイルは、たいてい本当の問題を教えてくれています——charset=utf-8 を宣言するサーバーから配信した瞬間、訪問者にはまさにこの化け方で届きます。
| ファイルの保存形式 | 宣言（meta / サーバー） | 結果 |
|---|---|---|
| UTF-8 | utf-8 | 正常 |
| Shift_JIS | utf-8（このビューアと同じ） | 「�」や記号の羅列になる |
| UTF-8 | Shift_JIS | 「譁�蟄怜喧」のような、いわゆる文字化け |
| Shift_JIS | Shift_JIS | 読めるが、公開先とツールの前提から外れていく |
直し方は一度きりです。nkf -w --overwrite page.html、または iconv -f SHIFT_JIS -t UTF-8 page.html > page-utf8.html で UTF-8 に変換します。VS Code なら右下のエンコーディング表示から「エンコード付きで保存 → UTF-8」でも構いません。そのうえで <head> の 1 行目を <meta charset="utf-8"> にしてください。これがないと、あいだに入るすべての層がまた推測を始めます。
このツールの正直な限界: エンコーディングを選ぶこともできませんし、判定もできません。見ているのは charset の宣言があるかどうかだけです。上の枠で化けていること自体が診断結果で、そこから先は変換してから戻ってきてください。他の日本語のビューアの多くは、ファイルをサーバーに送って向こう側で推測させています。ここはその代わりに、送らないことと、化けたときに理由を書くことを選びました。
スマートフォン幅で見る
多くのビューアは、そのときのウィンドウ幅の 1 カラムを出すだけです。ここは枠に 3 つの幅を用意しています。360px はおおよそ縦持ちのスマートフォン、768px は小さめのタブレット、最大はカラムの許すかぎり。枠は本物のブラウジングコンテキストなので、メディアクエリもコンテナクエリも flexbox の折り返しも、モニタの幅ではなく選んだ幅に反応します。
指摘のほうから自動的に出る注意が 1 つあります。<meta name="viewport" content="width=device-width, initial-scale=1"> がないと、実機のスマートフォンはそもそも 360 CSS ピクセルで描画しません。980 前後でレイアウトしてから縮小するので、文字は小さくなり、丁寧に書いたモバイル用のスタイルは一度も発火しません。狭い表示が正直なのは、このタグがあるときだけです。だからこそ枠の下で真っ先に指摘されます。
枠の下の指摘と、ふつうのビューアにそれがない理由
描画が答えるのは「見た目は合っているか」です。「よそでも合っているか」には答えられませんし、驚きはたいていそちら側にあります。だから指摘はすべて、行番号と、ひとつの具体的な結果に結び付けてあります。
http://の画像は、安全なページならどれも捨てます。例を読み込んでいるなら、いまその状態です。上のロゴが欠けていて、指摘がその行を指しています。- 自分のディスクへのパスは、自分の環境でしか表示されません。このサンドボックスの枠でも表示されないので、他の全員の体験の公平な予告になっています。
<!DOCTYPE html>の欠落はブラウザを互換モードに入れ、ボックスの寸法や継承する行の高さが 2001 年以前の規則になります。そうなると上の表示は、望んでいる何かの予告にはなりません。- ドキュメントではなくモジュール——
importやexport defaultで始まる中身——はそもそも描画できません。空の枠を見つめ続けるより、そう言われたほうがましです。
見るだけではなく本物のアドレスに向かうのなら、HTML ファイルを公開するのページが同じチェックを走らせ、そのままフォルダを公開する 2 つのコマンドに続きます。
// よくある質問
アップロードせずに HTML ファイルを見るにはどうすればいいですか？
ファイルをローカルで読むビューアを使ってください。このページではブラウザの FileReader API で読み込み、同じタブの中のサンドボックス iframe で描画するので、中身がサーバーに届くことはありません。ファイルをダブルクリックしてブラウザで開いても構いません。違いは、このページが「そのファイルが自分のディスクを離れたときに挙動が変わる箇所」まで教えることです。
ビューアで日本語が文字化けするのはなぜですか？
FileReader がバイト列をつねに UTF-8 として解釈するからです。ファイルが Shift_JIS や EUC-JP で保存されていると、日本語のバイト列が UTF-8 として不正になり、「�」や記号の羅列になります。ダブルクリックで開くと読めるのは、そのときブラウザがバイト列と meta charset を見て判断するためです。nkf か iconv で UTF-8 に変換し、meta charset も utf-8 にしてください。
このビューアは文字コードを判定したり選んだりできますか？
できません。見ているのは charset の宣言があるかどうかだけで、実際のエンコーディングは判定しませんし、読み込み時に符号化方式を選ぶこともできません。枠の中で化けていること自体が診断結果です。変換してから戻ってきてください。送らずに済ませることと引き換えの制約なので、正直に書いておきます。
CSS や画像がプレビューに出ないのはなぜですか？
枠には相対パスを解決する基準のフォルダがないからです。style.css や img/hero.png のような参照は、元のファイルの隣にあるファイルを指していて、srcdoc の枠の中からブラウザはそこへ届きません。https の URL から読み込むスタイルシートや画像は表示されます。解決できなかった参照は、枠の下に行番号つきで並びます。
スマートフォンでの見え方を確認できますか？
はい。枠を 360px（スマートフォン）や 768px（タブレット）に切り替えてください。メディアクエリは枠の幅に反応するので、見えているのはその幅でのレイアウトです。ただし viewport の meta タグがないファイルでは、実機は 360 CSS ピクセルを使わないため、狭い表示のほうが実物より良く見えます。その場合は指摘に出ます。
この HTML ビューアはオフラインでも使えますか？
はい。すべてこのページの中の 1 本のスクリプトで、独自のネットワーク通信はありません。ページを一度読み込めば、接続を切ってもファイルを開き続けられます。もちろん、スクリプトやフォントを CDN から取りにいく HTML は、それらなしで描画されます。
いま見ているものを、他の人が開けるページにするには？
フォルダの中に index.html として保存し、そのフォルダを公開します。clize claim yourname で無料のハンドル yourname.clize.app を取り、clize deploy ./folder --domain yourname.clize.app で HTTPS で公開します。移り住むエディタも書き出しの手順もありません。プレビューしたバイト列が、そのまま配信されるバイト列です。
次は、他の人が開ける URL にする。
上の描画はあなたのタブの中にしかありません。同じファイルを、メッセージに貼れる HTTPS のアドレスに変えるのはコマンド 2 つです。ハンドル無料、証明書は自動、何度でも公開し直せます。
$ npm i -g @clize/clize && clize login $ clize claim yourname $ clize deploy ./folder --domain yourname.clize.app[ Sites by Clize → ]