Método simples para detectar código com segurança em texto?

O GMail possui esse recurso, onde você será avisado se você tentar enviar um email que ele acha que pode ter um anexo.

Como o GMail detectou a seqüência de caracteres see the attachedno email, mas nenhum anexo real, ele me avisa com uma caixa de diálogo OK / Cancelar quando clico no botão Enviar.

Temos um problema relacionado ao estouro de pilha. Ou seja, quando um usuário entra em uma postagem como esta :

meu problema é que preciso alterar o banco de dados, mas não quero criar 
uma nova conexão. exemplo:

DataSet dsMasterInfo = new DataSet ();
Banco de dados db = DatabaseFactory.CreateDatabase ("ConnectionString");
DbCommand dbCommand = db.GetStoredProcCommand ("uspGetMasterName");

Este usuário não formatou o código como código!

Ou seja, eles não recuaram 4 espaços por Markdown ou usaram o botão de código (ou o atalho de teclado ctrl+ k) que faz isso por eles.

Portanto, nosso sistema está aceitando muitas edições nas quais as pessoas precisam entrar e formatar manualmente o código para pessoas que de alguma forma não conseguem descobrir isso. Isso leva a muita dor de barriga . Melhoramos a ajuda do editor várias vezes, mas, sem ir até a casa do usuário e pressionar os botões corretos em seu teclado, ficamos sem saber o que fazer em seguida.

É por isso que estamos considerando um aviso no estilo do Google GMail:

Você quis publicar um código?

Você escreveu coisas que achamos que parecem código, mas não o formatou como recuando 4 espaços, usando o botão de código da barra de ferramentas ou o comando de formatação de código ctrl+ k.

No entanto, apresentar esse aviso exige que detectemos a presença do que pensamos ser um código não formatado em uma pergunta . O que é uma maneira simples e semi-confiável de fazer isso?

• Por Markdown , o código é sempre recuado por 4 espaços ou nos backticks, para que qualquer coisa formatada corretamente possa ser descartada da verificação imediatamente.
• Isso é apenas um aviso e se aplicará apenas a usuários de baixa reputação que fizerem suas primeiras perguntas (ou fornecerão suas primeiras respostas); portanto, alguns falsos positivos são válidos, desde que sejam de cerca de 5% ou menos.
• As perguntas sobre o estouro de pilha podem estar em qualquer idioma, embora possamos limitar realisticamente nossa verificação para, por exemplo, os "dez grandes" idiomas. Pela página de tags que seria C #, Java, PHP, JavaScript, Objective-C, C, C ++, Python, Ruby.
• Use o despejo de dados comuns do criativo Stack Overflow para auditar sua solução em potencial (ou apenas faça algumas perguntas nas 10 principais tags do Stack Overflow) e veja como funciona.
• Pseudocódigo é bom, mas usamos c # se você quiser ser mais amigável.
• Quanto mais simples, melhor (desde que funcione). BEIJO! Se sua solução exigir que tentemos compilar postagens em 10 compiladores diferentes, ou um exército de pessoas para treinar manualmente um mecanismo de inferência bayesiano, isso não é exatamente o que tínhamos em mente.

Uma solução adequada provavelmente seria algum modelo estatístico / aprendido, mas aqui estão algumas idéias divertidas:

1. Ponto e vírgula no final de uma linha . Isso por si só pegaria um monte de idiomas.
2. Parênteses diretamente após o texto sem espaço para separá-lo: myFunc()
3. Um ponto ou flecha entre duas palavras: foo.bar = ptr->val
4. Presença de chaves, suportes: while (true) { bar[i]; }
5. Presença da sintaxe "comentário" (/ *, //, etc): /* multi-line comment */
6. Caracteres / operadores incomuns: +, *, &, &&, |, ||, <, >, ==, !=, >=, <=, >>, <<, ::, __
7. Execute o marcador de sintaxe no texto. Se acabar destacando uma porcentagem alta, provavelmente é código.
8. texto camelCase na postagem.
9. parênteses, colchetes e / ou colchetes aninhados.

Pode-se acompanhar o número de vezes que cada uma delas aparece e elas podem ser usadas como recursos em um algoritmo de aprendizado de máquina como o perceptron , da maneira que o SpamAssassin faz.

Eu ficaria curioso para ver quais são as métricas médias do inglês escrito de um lado e do código do outro lado.

• comprimento dos parágrafos
• comprimento das linhas
• tamanho das palavras
• caracteres usados
• relação entre caracteres alfabéticos, numéricos e outros caracteres de símbolo
• número de símbolos por palavra
• etc.

Talvez isso por si só já possa discriminar entre código e o resto. Pelo menos acredito que o código, independentemente do idioma, mostraria algumas métricas visivelmente diferentes em muitos casos.

A boa notícia é: você já possui muitos dados para construir suas estatísticas.

Ok, estou de volta com alguns dados para fazer backup de minhas suposições. :-)

Eu fiz um teste rápido e sujo em seu próprio posto e sobre o primeiro post eu encontrado na StackOverflow , com uma ferramenta bastante avançado: wc.

Aqui está o que eu tinha depois de executar wcna parte de texto e na parte de código desses dois exemplos:

Primeiro vamos ver a parte em inglês :

• A parte em inglês da sua postagem (2635 caracteres, 468 palavras, 32 linhas)
  • 5 caracteres / palavra, 82 caracteres / linha, 14 palavras / linha
• A parte em inglês do outro post (1499 caracteres, 237 palavras, 12 linhas)
  • 6 caracteres / palavra, 124 caracteres / linha, 19 palavras / linha

Muito parecido, você não acha?

Agora vamos dar uma olhada na parte do código !

• A parte do código da sua postagem (174 caracteres, 13 palavras, 3 linhas)
  • 13 caracteres / palavra, 58 caracteres / linha, 4 palavras / linha
• A parte do código da outra postagem (4181 caracteres, 287 palavras, 151 linhas)
  • 14 caracteres / palavra, 27 caracteres / linha, 2 palavras / linha

Veja como essas métricas não são tão diferentes, mas, mais importante, quão diferentes elas são das métricas em inglês? E isso é apenas usando uma ferramenta limitada. Agora tenho certeza de que você pode obter algo realmente preciso medindo mais métricas (estou pensando em particular nas estatísticas de caracteres).

Eu posso biscoito?

Normalmente, as cadeias de Markov são usadas para gerar texto, mas também podem ser usadas para prever a semelhança do texto (conforme CE Shannon 1950 ) a um modelo treinado. Eu recomendo várias cadeias de Markov.

Para cada idioma predominante, treine uma cadeia de Markov em uma amostra grande e representativa de código no idioma. Em seguida, para uma postagem de Estouro de Pilha para a qual você deseja detectar código, faça o seguinte para cada uma das cadeias:

• Faça um loop pelas linhas da postagem.
  • Declare duas variáveis: ACTUAL = 1.0 e HIGHEST = 1.0
  • Passe por cada caractere na linha.
    • Para cada caractere, encontre a probabilidade na cadeia de Markov de que o caractere atual seja aquele que segue os N caracteres anteriores. Defina ACTUAL = REAL * PROB ₁ . Se o caractere atual não estiver presente na cadeia, use um valor minúsculo para PROB ₁ , como 0,000001.
    • Agora, encontre o caractere mais provável (ou seja, a maior probabilidade) de seguir os N caracteres anteriores. Defina ALTO = ALTO * PROB ₂ .
    • Obviamente, PROB ₂ > = PROB ₁

Para cada linha, você deve ter um valor REAL e MAIS ALTO. Divida REAL por ALTA. Isso fornecerá a pontuação de adequação para saber se uma linha específica é o código-fonte. Isso associaria um número a cada uma das linhas no exemplo que você forneceu:

my problem is I need to change the database but I don't won't to create // 0.0032
a new connection. example: // 0.0023

DataSet dsMasterInfo = new DataSet(); // 0.04
Database db = DatabaseFactory.CreateDatabase("ConnectionString");   // 0.05
DbCommand dbCommand = db.GetStoredProcCommand("uspGetMasterName");  // 0.04

Por fim, você precisará selecionar um limite para determinar quando há código na postagem. Este poderia ser simplesmente um número selecionado por observação que produz alto desempenho. Também pode levar em consideração o número de linhas com uma pontuação alta.

Treinamento

Para treinar, adquira uma amostra grande e representativa de código no idioma. Escreva um programa para fazer um loop sobre o texto do código e associe cada N-grama no arquivo (o intervalo para N deve ser parametrizado) com a frequência estatística do caractere subsequente. Isso produzirá vários estados possíveis de caracteres que seguem o bigram, cada um associado a uma probabilidade. Por exemplo, o bigram "()" pode ter algumas probabilidades de caracteres a seguir:

"()" 0.5-> ";"
"()" 0.2-> "."
"()" 0.3-> "{"

O primeiro deve ser lido, por exemplo, como "A probabilidade de um ponto e vírgula seguir um parêntese vazio é 0,5".

Para o treinamento, eu recomendo N-gramas de tamanho dois a cinco. Quando eu pesquisei sobre isso , descobrimos que o tamanho N-gramas de dois a cinco funcionava bem em inglês. Como grande parte do código-fonte é semelhante ao inglês, sugiro começar com esse intervalo e, em seguida, ajustar para encontrar os valores ideais dos parâmetros à medida que você encontrar o que funciona.

Uma observação: o modelo será afetado por identificadores, nomes de métodos, espaços em branco e etc. No entanto, você pode ajustar o treinamento para omitir certos recursos da amostra de treinamento. Por exemplo, você pode recolher todos os espaços em branco desnecessários. A presença de espaço em branco na entrada (a postagem Stack Overflow) também pode ser ignorada. Você também pode ignorar letras maiúsculas e minúsculas, o que seria mais resiliente diante de várias convenções de nomenclatura de identificadores.

Durante minha pesquisa , descobrimos que nossos métodos funcionavam bem tanto em espanhol quanto em inglês. Não vejo por que isso também não funcionaria bem no código fonte. O código fonte é ainda mais estruturado e previsível que a linguagem humana.

Posso sugerir uma abordagem radicalmente diferente? No SO, a única linguagem humana permitida é o inglês; portanto, qualquer coisa que não seja o inglês tem 99,9% de chances de ser um trecho de código .

Então, minha solução seria: use um dos muitos verificadores de inglês existentes no mercado (apenas verifique se eles também sinalizam - além de erros ortográficos - erros de sintaxe como pontos duplos ou símbolos que não sejam do idioma como #ou ~). Qualquer linha / parágrafo que gere uma grande quantidade de erros e avisos deve acionar o "é este código?" Pergunta, questão.

Essa abordagem também pode ser adaptada para os sites StackExchange usando outros idiomas, além do inglês, é claro.

Apenas meus 2 ¢ ...

Provavelmente vou conseguir alguns votos negativos, mas acho que você está abordando isso do ângulo errado.

Essa linha me pegou:

as pessoas precisam digitar o código manualmente para pessoas que de alguma forma não conseguem descobrir isso

OMI que ponto de vista é meio arrogante. Acho isso muito no design de software, em que programadores e designers ficam irritados com usuários que não conseguem descobrir como usar o software corretamente, quando o problema não é o usuário, mas o próprio software - ou pelo menos a interface do usuário.

A causa raiz desse problema não é o usuário, mas o fato de não ser óbvio para eles que eles podem fazer isso.

Que tal uma alteração na interface do usuário para tornar isso mais óbvio? Certamente isso será:

1. mais óbvio para os novos usuários exatamente o que eles precisam fazer
2. mais fácil para você construir, em vez de escrever algoritmos complexos, para detectar a lógica de código de várias linguagens

Exemplo:

O pseudo-código representaria um desafio real, porque toda linguagem de programação depende de caracteres especiais como '[]', ';', '()', etc. Simplesmente conte a ocorrência desses caracteres especiais. Assim como você detectaria um arquivo binário (mais de 5% de uma amostra contém o valor de byte 0).

Eu acho que você pode precisar direcionar isso apenas para idiomas específicos; em geral, esse problema é provavelmente intratável, pois você pode obter idiomas bastante semelhantes ao inglês (por exemplo, inform7 ). mas, felizmente, os mais usados ​​podem ser cobertos com bastante facilidade.

Meu primeiro corte seria procurar a sequência "; \ n", que daria uma boa correspondência para C, C ++, Java, C # e qualquer outra linguagem que use sintaxe semelhante e seja realmente simples. Também é menos provável que seja usado em inglês do que a; sem uma nova linha

Alguém mencionou examinar as tags e depois procurar a sintaxe para isso, mas isso foi abatido porque isso é direcionado a novos usuários.

Uma possível solução melhor seria procurar nomes de idiomas no corpo da pergunta e aplicar a mesma estratégia. Se eu mencionar "Javascript", "Java" ou "C #", é provável que essa seja a questão e o código na pergunta provavelmente esteja nessa linguagem.

Primeiro, execute-o através da verificação ortográfica, pois encontrará muito poucas palavras em inglês apropriadas; no entanto, deve haver muitas palavras que o corretor ortográfico sugerirá que sejam divididas.

Existem caracteres especiais / de pontuação que não são típicos do inglês comum, são típicos do código:

• something(); simplesmente não pode ser um inglês simples;
• $somethingonde somethingnão é todo numérico;
• -> entre palavras sem espaços;
• . entre palavras sem espaço;

Obviamente, para que funcione bem, convém que o classificador Bayesiano seja construído sobre essas características.

Existem vários conjuntos de idiomas que compartilham sintaxe semelhante. a maioria dos idiomas foi influenciada por alguns idiomas; portanto, os idiomas [AMPL, AWK, csh, C ++, C--, C #, Objective-C, BitC, D, Go, Java, JavaScript, Limbo, LPC, Perl, PHP, Pike, Processing [foram todos influenciados por C, portanto, se você detectar C, provavelmente detectará todos esses idiomas. então você só precisa escrever um padrão simples para detectar esses conjuntos de idiomas.

Eu também dividiria o texto em blocos, porque o maior número de códigos será dividido por duas novas linhas ou similar dos outros blocos de texto na postagem.

isso pode ser fácil com javascript (uma amostra incompleta super simples para a família c):

var txt = "my problem is I need to change the database but I don't won't to create a new connection. example:\n\nDataSet dsMasterInfo = new DataSet();Database db = DatabaseFactory.CreateDatabase("ConnectionString");DbCommand dbCommand = db.GetStoredProcCommand("uspGetMasterName");";
var blocks = txt.split(/\n\n/gi); console.dir(blocks);
var i = blocks.length;
var cReg = /if\s*\(.+?\)|.*(?:int|char|string|short|long).*?=.+|while\s*\(.+?\)/gi;

while ( i-- ){
   var current = blocks[i];
   if ( cReg.test( current ) ){
      console.log("found code in block[" +  i + "]");
   }
}

Basta contar palavras / caracteres de pontuação para cada linha. O inglês tenderá a ter 4 ou mais, código menor que 2.

O parágrafo acima tem 18 palavras e 4 caracteres de pontuação, por exemplo. Este parágrafo tem 19 palavras e 4 pontuação, portanto dentro das expectativas.

Obviamente, isso precisaria ser testado com relação a perguntas de iniciantes em inglês para pessoas com baixo inglês, e pode ser que, nesses casos, as estatísticas sejam distorcidas.

Eu espero que [espaço em branco]. [Espaço em branco ou nova linha] seja muito raro no código, mas comum em inglês, portanto isso pode ser contado como palavras, não como pontuação.

Eu acho que o maior problema será o código embutido, onde alguém faz uma pergunta como:

Se eu disser para (i = 0; i> 100; i ++) {} o que isso significa?

Isso é código e inglês, e deve ser marcado como com back-ticks:

Se eu disser for (i=0; i>100; i++) {}o que isso significa?

Eu acho que você deve primeiro fazer uma distinção entre código (suficientemente) formatado que só precisa ser realmente designado como tal, e (também) código mal formatado, que precisa de formatação manual de qualquer maneira.

O código formatado possui linhas de quebra e recuo. Ou seja: se uma linha é precedida por uma única quebra de linha, você tem um bom candidato. Se houver espaços em branco principais, você tem um candidato muito bom.

O texto normal usa duas linhas de quebra ou dois espaços e uma linha de quebra para formatação, portanto, existe um critério claro para distinção.

No código LISP, você não encontrará ponto-e-vírgula; no código Ruby, você pode não encontrar parênteses; no pseudo-código, talvez você não encontre muito. Mas em qualquer idioma (não esotérico), você encontrará um código decente a ser formatado com linhas de interrupção e recuo. Não há nada tão universal assim. Porque no final é o código, escrito para ser lido por humanos.

Então, primeiro, procure por possíveis linhas de código . Além disso, linhas de código geralmente vêm em grupos. Se você tiver um, há uma boa chance de que o acima ou abaixo seja uma linha de código também.

Depois de selecionar possíveis linhas de código, você pode compará-las com critérios quantificáveis ​​e escolher um limite :

• frequência de caracteres que não sejam palavras
• frequência de identificadores: palavras muito curtas ou palavras muito longas no estilo CamelCase ou under_score
• repetição de palavras incomuns

Além disso, agora que existem programadores e cs, o escopo do stackoverflow é claramente reduzido. Pode-se considerar denotar todas as tags de idioma como idiomas. E ao postar, você deverá escolher pelo menos uma tag de idioma, escolher a language-agnostictag ou omitir explicitamente.

No primeiro caso, você sabe quais idiomas procurar, no segundo caso, talvez queira procurar pseudo-código e, no último caso, provavelmente não haverá código, porque é uma pergunta relacionada a alguma tecnologia ou estrutura ou tal.

Você pode criar um analisador para cada idioma que deseja detectar (as definições de idioma para o ANTLR geralmente são fáceis de encontrar) e executar cada linha da pergunta em cada analisador. Se alguma linha analisar corretamente, você provavelmente possui um código.

O problema é que algumas frases em inglês (idioma natural) podem ser analisadas como código, portanto, você pode incluir algumas das outras idéias também ou limitar os resultados positivos apenas se mais de uma ou duas linhas consecutivas analisarem corretamente o mesmo analisador de idioma.

O outro problema em potencial é que isso provavelmente não captará o pseudocódigo, mas isso pode ser bom.

O que pode ser o mais provável para o futuro e exigir o menor ajuste manual a longo prazo, à medida que outras linguagens (que parecem um pouco diferentes das linguagens de programação mais usadas atualmente) se tornam mais populares e as linguagens atualmente usadas se tornam menos populares, deve fazer algo parecido com o que o Google Translate faz (consulte o parágrafo intitulado "Como funciona?"), em vez de procurar certas coisas como ab e a () etc.

Em outras palavras, em vez de pensar manualmente nos padrões encontrados no código a procurar, o computador pode descobrir isso sozinho . Isso pode ser feito tendo

1. muito código em várias linguagens de programação diferentes

   • Sugestão: colete automaticamente amostras de código de repositórios de código-fonte baseados na Web, como Google Code ou Github, ou mesmo de itens no Stackoverflow já marcados como código

   • Nota: pode ser uma boa ideia analisar comentários de código

2. muito texto em inglês retirado de artigos na web

   • embora não seja de artigos sobre programação (caso contrário, eles podem ter código e misturar o sistema :-))

e ter algum tipo de algoritmo encontra automaticamente padrões no código que não estão em inglês e vice-versa, e usa esses padrões para detectar o que é código e o que não é código executando o algoritmo nas postagens.

(No entanto, não tenho certeza de como esse algoritmo funcionaria. Outras respostas à pergunta atual podem ter informações úteis para isso.)

Em seguida, o sistema pode varrer novamente o código de vez em quando para explicar as mudanças na aparência do código naquele momento.