Another topic that I would like to address is malformed HTML.
One of the questions on the forums was, are we going to talk about mistakes in web pages?
What if a real web developer forgets to close off a tag or makes a sort of subtle mistake
in punctuation?
Are we going to talk about that in the web browser that we build for this class?
And the answer is, yes!
In fact, very prescient on your part. That's a very predictive question.
We're going to get to it in unit 3, exactly the next unit.
We're going to talk about recognizing malformed HTML and JavaScript.
But in this class, we're mostly going to talk about recognizing them,
and for the particular project that we work on for our simple web browser,
if the HTML is malformed, we're not going to do anything about it.
We just won't render that part of the web page.
In practice, web browsers put a lot--a huge amount--of effort into being very forgiving.
They want to render as much information as possible, even if the web page is out of date
or written without knowledge of the standards or in any other way messed up.
This approach of keeping going is sometimes known as error recovery
or error tolerance or fault tolerance.
In unit 3, we're going to talk about breaking up tokens and seeing if they match
a particular structure, seeing if they're in the language of a formal grammar
that describes all of JavaScript or all of web pages.
You know in the real world, a lot of web pages are not.
They don't match the formal idealized grammar I've written down on the walls of Plato's cave.
Similarly, not every JavaScript program adheres to exactly the same idea of--
to pick a timely example--where the semicolons go after statements.
So in practice, what you'll often want to do if you're doing commercial software
if you want to make your customers as happy as possible by supporting everything
that they've written, you'll write about your duplicate rules.
For example, you might write one regular expression that accepts normal numbers,
but if people make a common mistake when writing numbers,
maybe they write multiple.multiple period signs or something like that,
you might write another rule that accepts those,
and maybe print out some warning but then does it's best to figure out what the value is
and keeps going.
Again, in real world industrial software development for a web browser,
this sort of error recovery when you're doing lexical analysis or syntactic analysis
is of critical importance because the vast majority of web pages are not
standards compliant.
In this class, we're going to tell you how to tell the difference between good HTML and bad,
between well-formed JavaScript and malformed JavaScript.
But I'm only going to require that you deal with well-formed strings.
Once you know how to do it the good way though,
you could do it for ill-formed strings.
You'd have all the tools after finishing this class.
It would just be more busy work, elbow grease.
It would take additional time, and it wouldn't really teach you more concepts.
That's why I'm not going to focus on it.
さらに 不正な形式のHTMLに関して お話ししましょう
フォーラムでWebページの間違いに関する 質問がありましたね
Web開発者がタグを閉じるのを忘れたり 句読点で小さな間違いをしたら
どうなるのでしょう？
この講義で作るWebブラウザで それについて話すのでしょうか？
答えはイエスです！
非常に先見の明がありますね 先を見すえた質問です
ではレッスン3に進みましょう
不正な形のHTMLとJavaScriptの 判別について話します
講義の大部分は不正な形の判別と シンプルなWebブラウザ向けの
特定のプロジェクトについての話です
HTMLが不正な形である場合 それに関しては何もしません
Webページの該当部分が表示されないだけです
実際にはWebブラウザはかなり寛大です
たとえ古いWebページであっても また知識もなく書かれていたり
めちゃめちゃな方法で書かれたものであっても できるだけ多くの情報を表示しようとします
このように とにかく進み続けようとする動作は エラー回復として知られています
エラー耐性または フォールトトレランスともいいます
レッスン3ではトークンをバラバラにして 特定の構造に適合するかを検証します
形式文法の言語で確認します
JavaScriptのすべて つまりWebページ全体を記述する文法です
実際には そうでないWebページがたくさんあります
プラトンの洞窟の壁に書いた理想的な形式文法と 現実とは合致しません
同様に すべてのJavaScripプログラムが 必ずしも同じ概念に当てはまるとは限りません
例えば文の終わりにセミコロンが続く といったことです
例えば皆さんが商用ソフトを開発する 仕事をしているとします
顧客が書いたコードをすべてサポートして 満足してもらうためには
重複した規則も記述しなければならないでしょう
例えば正規数を受容する 1つの正規表現を書くかもしれませんね
しかし人々が数字を入力する時に 共通の間違いをするとしたら
例えばドットを余分に入れるような 間違いをよくするとしたら
それを受容するような別の規則を 記述してもいいでしょう
そして警告を表示しつつ 値が何であるかを 表示するようにしてもいいでしょう
そして処理を続けます
実際はWebブラウザ向けの 商用ソフトウェア開発では
字句解析または構文解析の際の こういったエラー回復は非常に重要です
大多数のWebページは 規則に準じていないことが多いからです
この講義ではよいHTMLとよくないHTMLとの 違いを見分ける方法をお話しします
正しい形のJavaScriptとそうでないJavaScriptの 違いについても確認します
皆さんは正しい形の文字列を扱ってくださいね
一度正しい方法を理解すれば
不正な形の文字列にも対応できるはずです
この講義が終わった後には すべての技術が身についています
ただし忙しくきつい作業となるでしょう
さらに時間もかかりますし より多くを学べることはないでしょう
ですから不正な形については特に触れません
Outro tópico que eu gostaria de abordar é entrada HTML mal formada.
Uma das perguntas nos fóruns foi: Vamos falar sobre erros em páginas web?
O que acontece se um desenvolvedor web se esquece de fechar uma tag, ou comete algum tipo de erro
de pontuação?
Vamos falar sobre isso no web browser que vamos construir no curso?
E a resposta é sim!
De fato, isso é muito previdente. Essa é uma pergunta muito previdente.
Vamos ver isso na unidade 3, exatamente a próxima unidade.
Vamos falar sobre reconheciento de código HTML e JavaScript mal formado.
Mas, neste curso, vamos falar, principalemente, de reconhecer isso,
e, para o peojeto particular no qual que estamos trabalhando -- para o nosso simples web browser --
se o HTML é mal formado, não vamos fazer nada a respeito.
Não vamos exibir essa parte da página web.
Na prática, web browsers fazem um enorme esforço para serem bastante condescendentes.
Ees querem formatar o máximo de informação possível, mesmo que a página web seja desatualizada,
ou escrita sem obedecer estritamente aos padrões, ou errada de algum modo.
Essa abordagem de continuar processando é algumas vezes conhecida como recuperação de erro,
ou tolerência a erro, ou tolerância a falha.
Na unidade 3, vamos falar sobre separar tokens e ver se eles casam
com uma estrutura particular -- ver se eles estão na linguagem de uma gramática formal
que descreve todo JavaScript ou todas as páginas web.
Você sabe, no mundo real, isso não acontece, para muitas páginas web.
Elas não casam com a gramática formal idealizada, que está escrita na caverna de Platão.
De modo similar, nem todo programa Javascript adere exatamente ao mesmo padrão --
para dar um exemplo, o padrão de usar ; depois de cada comando.
Então, na prática, o que você frequentemente gostaria de fazer, se você está desenvolvendo software comercial,
se você quer que seus clientes fiquem felizes, provendo suporte a tudo
o que eles escrevem, é escrever algumas regras duplicadas.
Por exemplo, você pode escrever uma expressão regular que aceita números normais,
mas, se uma pessoa comente um erro comum ao escrever um número,
talvez escrevendo .. em lugar de ., ou algo assim,
você pode escrever uma outra regra, que aceite isso.
E talvez imprimir um aviso, mas fazer o possível para adivinhar qual seria o valor correto,
e continuar o processamento.
Mais uma vez, no mundo real de desenvolvimento de um software, para um web browser,
esse tipo de recuperação de erro, quando você está fazendo análise léxica ou análise sintática,
tem importância crítica, porque a grande maioria das páginas web
não adere totalmente aos padrões.
Neste curso, nós vamos ver como você pode distinguir entre HTML correto e incorreto,
entre JavaScript bem formado e mal formado.
Mas eu apenas vou requerer que você trate strings bem formados.
Uma vez que você saiba como fazer da maneira correta,
você poderá tratar também strings mal formados.
Você terá aprendido todas as ferramentas, quando concluir este curso.
Seria apenas um bocado mais de trabalho,
tomaria tempo adicional, mas não iria ensinar a você nenhum novo conceito.
É por isso que eu não vou focar isso.