Correções ortográficas diversas.

appendices/userlandnaming.xml

@@ -6,7 +6,7 @@
   O seguinte guia tem como objetivo orientar em como escolher nome para identificadores
   em código PHP em espaço de usuário. Quando escolher nome para qualquer código que crie símbolos
   no escopo global, é importante levar em conta as seguintes
-  orientações para previnir que futuras versões do PHP entrem em conflito
+  orientações para prevenir que futuras versões do PHP entrem em conflito
   com o seus símbolos.
  </para>
 

install/fpm/configuration.xml

@@ -556,7 +556,7 @@
       <listitem>
        <para>
         Especifica a prioridade de nice(2) a ser aplicada ao processo (somente se informado).
-        Esse valor pode variar de -19 (prioridade máxima) to 20 (prioridade mínima).
+        Esse valor pode variar de -19 (prioridade máxima) a 20 (prioridade mínima).
         Valor padrão: não definido.
        </para>
       </listitem>

install/unix/debian.xml

@@ -53,7 +53,7 @@
   <title>Controle melhor as configurações</title>
    <simpara>
     Até então o PHP foi instalado apenas com os meus módulos principais. É bem
-    provável que módulos adicionais serão desejados, como
+    provável que módulos adicionais sejam desejados, como
     <link linkend="book.mysql">MySQL</link>,
     <link linkend="book.curl">cURL</link>,
     <link linkend="book.image">GD</link>,

install/unix/lighttpd-14.xml

@@ -82,7 +82,7 @@ fastcgi.server = ( ".php" =>
    de esforço é requerido. Configurar a variável de ambiente <envar>PHP_FCGI_CHILDREN</envar>
    controla quantos processos filhos do PHP irão iniciar para lidar com as requisições que chegam.
    Configurar <envar>PHP_FCGI_MAX_REQUESTS</envar> irá determinar por quanto tempo (em requisições) cada
-   filho ficará ativo. Aqui está um script bach simples para ajudar a iniciar processos PHP.
+   filho ficará ativo. Aqui está um script bash simples para ajudar a iniciar processos PHP.
   </para>
 
   <example>

install/unix/nginx.xml

@@ -93,7 +93,7 @@ cp sapi/fpm/php-fpm /usr/local/bin
    <para>
     É importante evitar que o Nginx passe requisições ao processo interno
     do PHP-FPM se o arquivo não existe, fazendo com que se impeça
-    injeção a arbitrária de script.
+    a injeção arbitrária de scripts.
    </para>
    <para>
     Isto pode ser feito configurando-se a diretiva

reference/filesystem/functions/fpassthru.xml

@@ -3,7 +3,7 @@
 <refentry xml:id="function.fpassthru" xmlns="http://docbook.org/ns/docbook">
  <refnamediv>
   <refname>fpassthru</refname>
-  <refpurpose>Imprime todo os dados restantes de um ponteiro de arquivo</refpurpose>
+  <refpurpose>Imprime todos os dados restantes de um ponteiro de arquivo</refpurpose>
  </refnamediv>
 
  <refsect1 role="description">

reference/pdo/pdostatement/getcolumnmeta.xml

@@ -22,7 +22,7 @@
    <simpara>
     Alguns drivers podem não implementar o método
     <methodname>PDOStatement::getColumnMeta</methodname>,
-    já que ele é opcional. Entretanto, todo os
+    já que ele é opcional. Entretanto, todos os
     <link linkend="pdo.drivers">drivers PDO</link>
     documentados neste manual implementam este método.
    </simpara>

security/apache.xml

@@ -11,7 +11,7 @@
     de acesso interno, você terá que fazer com que o banco de dados seja acessível ao usuário
     "nobody". Isso significa que um script malicioso pode acessar e modificar
     o banco de dados, mesmo sem um usuário e senha. É possível que um web spider
-    pode passar em uma página web de administração do banco de dados
+    possa passar em uma página web de administração do banco de dados
     e remover todos os bancos de dados. Você pode se proteger contra isso
     usando autorização do Apache, ou você pode desenvolver
     seu modelo de acesso próprio usando LDAP, arquivos &htaccess;, etc. e incluir
@@ -33,14 +33,14 @@
    <simpara>
     Aumentar as permissões do usuário do Apache para a de administrador é
     extremamente perigoso e pode comprometer o sistema inteiro, então executar com sudo,
-    com chroot, ou então executar como root não deve ser considerados por
+    com chroot, ou então executar como root não deve ser considerado por
     aqueles que não são profissionais em segurança.
    </simpara>
    <simpara>
     Existem algumas soluções mais simples. Usando a diretiva
     <link linkend="ini.open-basedir">open_basedir</link> pode-se controlar e restringir quais
     diretórios o <acronym>PHP</acronym> tem permissão de usar. Você também pode configurar
-    áreas exclusivas para o Apache, restringir todas as atividades web para arquivo
+    áreas exclusivas para o Apache, restringir todas as atividades web para arquivos
     que não sejam de algum usuário ou do sistema.
    </simpara>
   </chapter>

security/cgi-bin.xml

@@ -26,13 +26,13 @@
        role="url">http://my.host/cgi-bin/php?/etc/passwd</filename>
       </simpara>
       <simpara>
-       A informação de consulta em uma URL depois da interrogração (<literal>?</literal>) é
+       A informação de consulta em uma URL depois da interrogação (<literal>?</literal>) é
        passada como argumentos de linha de comando para o interpretador pela
        interface CGI. Normalmente os interpretadores abrem e executam o arquivo
        especificado como primeiro argumento na linha de comando.
       </simpara>
       <simpara>
-       Quando invocado como binárgio CGI, o <command>php</command> se recusa a interpretar os
+       Quando invocado como binário CGI, o <command>php</command> se recusa a interpretar os
        argumentos de linha de comando.
       </simpara>
      </listitem>
@@ -67,7 +67,7 @@
        No PHP, as diretivas de tempo de execução <link
        linkend="ini.cgi.force-redirect">cgi.force_redirect</link>, <link
        linkend="ini.doc-root">doc_root</link> e <link
-       linkend="ini.user-dir">user_dir</link> podem ser usadas para previnir
+       linkend="ini.user-dir">user_dir</link> podem ser usadas para prevenir
        esse ataque, se a árvore de documentos do servidor tiver qualquer diretório
        com restrições de acesso. Veja abaixo para uma explicação completa
        de combinações diferentes.
@@ -80,7 +80,7 @@
     <title>Caso 1: apenas arquivos públicos são disponibilizados</title>
 
     <simpara>
-     Se o seu servidor não tiver qualquer conteúdo que não é restringido
+     Se o seu servidor não tiver qualquer conteúdo que não seja restringido
      por senha ou por IP, não há necessidade para essas opções de
      configuração. Se seu servidor web não permitir que você faça
      redirecionamento, ou o servidor não tem uma maneira de
@@ -123,11 +123,11 @@ AddHandler php-script .php
     </programlisting>
     <simpara>
      Essa opção só foi testada com o servidor Apache, e confia
-     no Apache para configura a variável de ambiente não-padrão do CGI
+     no Apache para configurar a variável de ambiente não-padrão do CGI
      <envar>REDIRECT_STATUS</envar> em requisições redirecionadas. Se seu
      servidor web não suporta nenhuma maneira de dizer se a requisição é
-     direta ou rediracionada, você não pode usar essa opção e você deve usar
-     uma das outras maneira de executar a versão do CGI documentada
+     direta ou redirecionada, você não pode usar essa opção e você deve usar
+     uma das outras maneiras de executar a versão do CGI documentada
      aqui.
     </simpara>
    </sect1>
@@ -136,14 +136,14 @@ AddHandler php-script .php
     <title>Caso 3: configurando doc_root ou user_dir</title>
     <simpara>
      Para incluir conteúdo ativo, como script e executáveis, nos
-     diretórios de documentos do servidor é algumas vezes consideread uma
+     diretórios de documentos do servidor é algumas vezes considerada uma
      prática insegura. Se, por conta de um erro de configuração, os scripts
      não são executados mas mostrados como documentos HTML normais, isso
      pode resultar em vazamento de propriedade intelectual ou informação
-     de segurança, como senhas. Portanto, muitos administradores preferirão
-     configura outra estrutura de diretório para scripts que são acessíveis
+     de segurança, como senhas. Portanto, muitos administradores preferem
+     configurar outra estrutura de diretório para scripts que são acessíveis
      apenas pelo CGI do PHP, e, portanto, sempre
-     interpretados e não enviado ao navegador.
+     interpretados e não enviados ao navegador.
     </simpara>
     <simpara>
      Além disso, se o método para assegurar que as requisições não são
@@ -153,7 +153,7 @@ AddHandler php-script .php
      seja diferente do diretório raiz dos documentos do servidor web.
     </simpara>
     <simpara>
-     Você pode configura a raiz de documentos dos scripts PHP pela
+     Você pode configurar a raiz de documentos dos scripts PHP pela
      diretiva de configuração <link linkend="ini.doc-root">doc_root</link> no
      <link linkend="configuration.file">arquivo de configuração</link>, ou
      você pode criar a variável de ambiente

security/current.xml

@@ -4,7 +4,7 @@
   <chapter xml:id="security.current" xmlns="http://docbook.org/ns/docbook">
    <title>Mantendo-se Atualizado</title>
    <simpara>
-    PHP, como qualquer outro sistema grande, está sobre constante revisão e
+    PHP, como qualquer outro sistema grande, está sob constante revisão e
     melhoramento. Cada versão nova normalmente incluirá mudanças, sejam grandes
     ou pequenas, para melhorar a segurança e reparar falhas, erros de
     configuração, e outros problemas que podem afetar a segurança geral
@@ -12,7 +12,7 @@
    </simpara>
    <simpara>
     Como outras linguagens de script e programas de nível de sistema, a melhor
-    política é atualizar frequentemente e manter-se atento as novas
+    política é atualizar frequentemente e manter-se atento às novas
     versões e suas mudanças.
    </simpara>
   </chapter>

security/database.xml

@@ -5,7 +5,7 @@
 
    <simpara>
     Hoje em dia, bancos de dados são componentes cardinais de qualquer aplicação web
-    permitindo que websites forneçam conteúdo dinâmico variável. Um vez que informações muito
+    permitindo que websites forneçam conteúdo dinâmico variável. Uma vez que informações muito
     sensíveis e/ou secretas podem ser guardadas em um banco de dados, proteger seus
     bancos de dados é essencial.
    </simpara>
@@ -34,7 +34,7 @@
      <simpara>
       O primeiro passo é sempre criar o banco de dados, a não ser que você queira
       usar um de terceiros. Quando um banco de dados é criado, ele é
-      atribuído a um dono, que executou os comandos de criação. Normalmente, só
+      atribuído a um dono, o mesmo que executou os comandos de criação. Normalmente, só
       o dono (ou um superusuário) pode fazer algo com os objetos naquele
       banco de dados, e para permitir que outros usuários usem, privilégios devem
       ser concedidos.
@@ -61,7 +61,7 @@
      Deve-se estabelecer as conexões sobre SSL para criptografar as
      comunicações cliente/servidor para aumentar a segurança, ou você pode usar ssh
      para criptografar a conexão de rede entre clientes e o servidor de banco de dados.
-     Se uma dessa opções for usada, o monitoramento do seu tráfego e obtenção
+     Se uma dessas opções for usada, o monitoramento do seu tráfego e obtenção
      de informação sobre seu banco de dados serão dificultados para um possível atacante.
     </simpara>
     <!--simpara>
@@ -242,7 +242,7 @@ union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from use
     </para>
     <para>
      Instruções <literal>UPDATE</literal> e <literal>INSERT</literal> também podem
-     ser abusados em ataques.
+     ser abusadas em ataques.
      <example>
      <title>
       De recuperando uma senha ... para ganhando mais privilégios (qualquer banco de dados)
@@ -357,7 +357,7 @@ $result = mssql_query($query);
       A maneira recomendada de evitar ataques de injeção de SQL é informar todos os
       dados em instruções preparadas. Usar instruções parametrizadas não é o suficiente
       para evitar SQL injection, mas é a maneira mais rápida e segura de fornecer dados
-      a instruções SQL. Todo os dados dinâmicos em <literal>WHERE</literal>,
+      a instruções SQL. Todos os dados dinâmicos em <literal>WHERE</literal>,
       <literal>SET</literal>, e <literal>VALUES</literal> precisam ser
       substituídos por âncoras. Os dados em si serão informados durante a
       execução, e serão enviados separadamente do comando SQL.
@@ -388,7 +388,7 @@ $stmt->execute(["%{$productId}%"]);
      </para>
 
      <simpara>
-      Instruções preparadas são fornecidos
+      Instruções preparadas são fornecidas
       <link linkend="pdo.prepared-statements">no PDO</link>,
       <link linkend="mysqli.quickstart.prepared-statements">no MySQLi</link>,
       e por outras bibliotecas de bancos de dados.
@@ -407,7 +407,7 @@ $stmt->execute(["%{$productId}%"]);
       <itemizedlist>
        <listitem>
         <simpara>
-         Nunca se conecte no banco de dados utilizando um usuário administrador ou dono
+         Nunca se conecte ao banco de dados utilizando um usuário administrador ou dono
          dos objetos do banco. Sempre utilize usuários com privilégios mínimos.
         </simpara>
        </listitem>
@@ -446,7 +446,7 @@ $stmt->execute(["%{$productId}%"]);
        </listitem>
        <listitem>
         <simpara>
-         Nunca imprimi nenhum dado ou erros específico do banco de dados, especialmente
+         Nunca imprimi nenhum dado ou erro específico do banco de dados, especialmente
          dados referentes a schema. Veja também <link
          linkend="security.errors">exibição de erros</link> e <link
          linkend="ref.errorfunc">funções de manipulação e log de erros</link>.

security/errors.xml

@@ -5,10 +5,10 @@
    <title>Relatando Erros</title>
    <para>
     Com relação a segurança, relatório de erros é uma faca de dois gumes.
-    Pode beneficiar o aumento da segurança, ou fornecer informaçao ao atacante.
+    Pode beneficiar o aumento da segurança, ou fornecer informação ao atacante.
    </para>
    <para>
-    Uma tática padrão de ataque involve determinar como um sistema funciona entrando
+    Uma tática padrão de ataque envolve determinar como um sistema funciona entrando
     dados incorretos e checando os tipos e contextos dos erros
     que são retornados. Isso permite que um cracker sonde
     por informações sobre o servidor, para determinar possíveis fraquezas.
@@ -40,7 +40,7 @@
     ou outra informações perigosas. Especialmente perigoso é rodar
     código de fontes conhecidas com tratadores de depuração integrados, ou usar
     técnicas de depuração comuns. Se o atacante pode determinar qual
-    técnica gerá você estiver usando, eles podem tentar, por força-bruta,
+    técnica geral você estiver usando, eles podem tentar, por força-bruta,
     enviar várias strings de depuração comuns para a página:
     <example>
      <title>Explorando variáveis comuns de depuração</title>
@@ -81,14 +81,14 @@
     Um erro geral do PHP ou do sistema de arquivos indicam quais permissões
     o servidor web tem, assim como a estrutura e organização dos
     arquivos no servidor web. Códigos de erros escritos pelo desenvolvedor podem
-    agravar o problema, levando pela exploração fácil de informação até então
+    agravar o problema, levando à exploração fácil de informação até então
     "escondida".
    </para>
    <para>
     Existem três soluções principais para esse problema. A primeira é
     verificar exaustivamente todas as funções, e tentar compensar pelo volume dos
     erros. A segunda é desabilitar completamente os relatórios de erros
-    no código de produção. A terceira é usar as funções personalizávies
+    no código de produção. A terceira é usar as funções personalizáveis
     de tratamento de erro do PHP para criar seu próprio tratador de erro.
     Dependendo da sua política de segurança, você pode perceber que todas são
     aplicáveis à sua situação.
@@ -99,7 +99,7 @@
     aumentar a segurança de seu código e achar uso de variáveis que pode ser perigoso.
     Ao testar o seu código, antes de colocar em produção, com <constant>E_ALL</constant>, você pode
     rapidamente encontrar áreas onde suas variáveis podem sofrer alterações nocivas
-    ou modificações quaisquer. Uma vez que estiver pronto para produção,
+    ou modificações quaisquer. Uma vez que esteja pronto para produção,
     você deve ou desabilitar mensagens de erro completamente configurando a diretiva
     <function>error_reporting</function> com o valor 0, ou desligar o envio
     de erros usando a opção <literal>display_errors</literal> do arquivo &php.ini;,

security/filesystem.xml

@@ -5,7 +5,7 @@
    <title>Segurança do Sistema de Arquivos</title>
    <simpara>
     O <acronym>PHP</acronym> está sujeito à segurança encontrada na maioria dos sistemas de servidor
-    com respeito à permissões de arquivos e diretórios. Isso permite que
+    com respeito às permissões de arquivos e diretórios. Isso permite que
     seja controlado que arquivos no sistema podem ser lidos e por quem. É preciso
     ter cuidado com quaisquer arquivos que são lidos por todos para assegurar
     que eles podem ser lidos por todos os usuários que têm acesso ao
@@ -46,7 +46,7 @@ echo "O arquivo foi removido!";
 ]]>
      </programlisting>
     </example>
-   Já que o nome do usuário e do arquivo são enviáveis pelo formulário,
+   Já que o nome do usuário e do arquivo são enviados pelo formulário,
    um usuário pode enviar um nome de usuário e de arquivo que pertença a outra pessoa,
    e apagá-lo, mesmo que eles não tenham permissão para fazê-lo.
    Nesse caso, é preciso ter alguma outra forma de autenticação.
@@ -73,7 +73,7 @@ echo "O arquivo foi removido!";
 ]]>
      </programlisting>
     </example>
-    Existem duas medidas importantes que você deve tomar para previnir
+    Existem duas medidas importantes que você deve tomar para prevenir
     esses problemas.
     <itemizedlist>
      <listitem>
@@ -105,7 +105,7 @@ $filepath = "$homedir/$userfile";
 if (file_exists($filepath) && unlink($filepath)) {
     $logstring = "Removido $filepath\n";
 } else {
-    $logstring = "Falhar ao remover $filepath\n";
+    $logstring = "Falha ao remover $filepath\n";
 }
 
 $fp = fopen("/home/logging/filedelete.log", "a");
@@ -119,7 +119,7 @@ echo htmlentities($logstring, ENT_QUOTES);
      </programlisting>
     </example>
     No entanto, ele ainda possui falhas. Se seu sistema de autenticação
-    permitir que os usuários criem seu próprios logins, e um usuário
+    permitir que os usuários criem seus próprios logins, e um usuário
     escolher o login <literal>"../etc/"</literal>, o sistema está novamente exposto. Por
     essa razão, é preferível escrever uma verificação mais personalizada:
     <example>
@@ -151,11 +151,11 @@ if (!ctype_alnum($username) || !preg_match('/^(?:[a-z0-9_-]|\.(?!\.))+$/iD', $us
     ou <filename>COM1</filename>), arquivos de configuração (arquivos <filename>/etc/</filename>
     e arquivos <literal>.ini</literal>), áreas de armazenamento de arquivo bem conhecidas (<filename>/home/</filename>,
     <filename>My Documents</filename>), etc. Por essa
-    razão, normalmente é mais fácil criar uma política onde se proibe
+    razão, normalmente é mais fácil criar uma política onde se proíbe
     tudo exceto aquilo que for explicitamente permitido.
    </para>
    <sect1 xml:id="security.filesystem.nullbytes">
-    <title>Problemas relacionados a bytes nulos (NUL)</title>
+    <title>Problemas relacionados à bytes nulos (NUL)</title>
     <simpara>
      Como o <acronym>PHP</acronym> usa funções em C para operações relacionadas ao
      sistema de arquivos, ele pode lidar com bytes nulos de maneira inesperada.

security/general.xml

@@ -6,16 +6,16 @@
    <simpara>
     Um sistema completamente seguro é virtualmente impossível de se conseguir,
     então uma abordagem freqüentemente usada em segurança é um compromisso entre
-    risco e usabilidade. Se cada variável enviada pelo usuário precias
+    risco e usabilidade. Se cada variável enviada pelo usuário precisar
     de duas formas de validação biométrica (como escaneamento de retina e
     impressão digital), você teria um nível de checagem extremamente alto.
     Demoraria meia hora para preencher um formulário mais ou menos
-    complexo, o que incentivaria os usuários a achar maneiras de
+    complexo, o que incentiva os usuários a achar maneiras de
     burlar a segurança.
    </simpara>
    <simpara>
     A melhor segurança é frequentemente aquele preenche os requerimentos
-    sem obstruir o usuário de fazer o seu trabalho,
+    sem obstruir o usuário a fazer o seu trabalho,
     ou sobrecarregando o programador com complexidade
     excessiva. De fato, alguns ataques de segurança exploram
     esse tipo de segurança super-produzida, que tende a degradar com o tempo.
@@ -33,8 +33,8 @@
     que você pode esperar será totalmente diferente da entrada dada por
     um empregado irritado, um cracker com meses livres para tentar
     quebrar o sistema, ou um gato andando pelo teclado. Por isso é melhor
-    olhar ao código da perspectiva lógica, para discernir
-    onde dados inesperados podem ser introduzidos, e depois seguir aonde
+    olhar para o código da perspectiva lógica, para discernir
+    onde dados inesperados podem ser introduzidos, e depois seguir onde
     o mesmo é modificado, reduzido ou amplificado.
    </simpara>
    <simpara>

security/variables.xml

@@ -4,7 +4,7 @@
 <chapter xml:id="security.variables" xmlns="http://docbook.org/ns/docbook">
  <title>Dados Enviados pelo Usuário</title>
  <para>
-  A maior fraqueza na maioria dos programas <acronym>PHP</acronym> não é inerente a
+  A maior fraqueza na maioria dos programas <acronym>PHP</acronym> não é inerente à
   linguagem em si, mas meramente um problema de código escrito desconsiderando a
   segurança. Por essa razão, você sempre deve investir um pouco de tempo
   considerando as implicações de um certo pedaço de código, para ter certeza