Простий метод надійного виявлення коду в тексті?

GMail має цю функцію, де він попередить вас, якщо ви спробуєте надіслати електронний лист, який, на його думку, може мати вкладення.

Оскільки GMail виявив рядок see the attachedв електронній пошті, але не має фактичного вкладення, він попереджає мене діалоговим вікном OK / Скасувати, коли натискаю кнопку Відправити.

У нас пов’язана проблема із переповненням стека. Тобто, коли користувач вводить посаду , як цей :

моя проблема полягає в тому, що мені потрібно змінити базу даних, але я не хочу її створювати 
нове з'єднання. приклад:

DataSet dsMasterInfo = новий DataSet ();
База даних db = DatabaseFactory.CreateDatabase ("ConnectionString");
DbCommand dbCommand = db.GetStoredProcCommand ("uspGetMasterName");

Цей користувач не форматував свій код як код!

Тобто вони не відступали на 4 пробіли за Markdown, або не використовували кнопку коду (або комбінацію клавіш ctrl+ k), яка робить це для них.

Таким чином, наша система приймає чимало змін, в яких люди повинні зайти та відформатувати код вручну для людей, які якимось чином не в змозі це зрозуміти. Це призводить до великої кількості живота . Ми кілька разів вдосконалювали довідку про редактор, але, не маючи приїзду до будинку користувача та натискання правильних кнопок на їх клавіатурі, ми втрачаємо, щоб побачити, що робити далі.

Ось чому ми розглядаємо попередження в стилі Google GMail:

Ви мали на увазі поштовий індекс?

Ви писали речі, які, на нашу думку, виглядають як код, але ви не відформатували його як код, відступаючи 4 пробіли, використовуючи кнопку коду на панелі інструментів або команду форматування коду ctrl+ k.

Однак, подаючи це попередження, ми вимагаємо виявити наявність у запитанні неформатованого коду . Який простий, напівнадійний спосіб зробити це?

• За позначкою коду завжди відступають 4 пробіли або в межах задніх сторін, тому все, що правильно відформатоване, може бути негайно знято з чека.
• Це лише попередження, і воно застосовуватиметься лише до користувачів з низькою репутацією, які задають свої перші запитання (або надають свої перші відповіді), тому деякі помилкові позитивні документи є нормальними, якщо вони становлять приблизно 5% або менше.
• Питання щодо переповнення стека можуть бути на будь-якій мові, хоча ми можемо реально обмежити перевірку, скажімо, на "великих десятках" мовах. На сторінці тегів, які будуть C #, Java, PHP, JavaScript, Objective-C, C, C ++, Python, Ruby.
• Використовуйте дамп даних Creative Commons для перегляду свого потенційного рішення (або просто виберіть кілька запитань у топ-10 тегів на Переповнення стека) і подивіться, як це відбувається.
• Псевдокод чудово, але ми використовуємо c #, якщо ви хочете бути дуже доброзичливими.
• Чим простіше, тим краще (поки це працює). ПОПУСК! Якщо ваше рішення вимагає, щоб ми намагалися скласти пости в 10 різних компіляторах або армії людей, щоб вручну навчати байєсівський механізм висновку, це ... не зовсім те, що ми мали на увазі.

Правильним рішенням, можливо, буде якась вивчена / статистична модель, але ось кілька цікавих ідей:

1. Напівколони в кінці рядка . Це одне може наздогнати цілу купу мов.
2. Вводимо дужки безпосередньо за текстом, не маючи місця для його розділення: myFunc()
3. Крапка або стрілка між двома словами: foo.bar = ptr->val
4. Наявність фігурних брекетів, дужок: while (true) { bar[i]; }
5. Наявність синтаксису "коментар" (/ *, // тощо): /* multi-line comment */
6. Нечасті персонажі / оператори: +, *, &, &&, |, ||, <, >, ==, !=, >=, <=, >>, <<, ::, __
7. Запустіть текст текстом синтаксису. Якщо в кінцевому підсумку виділяється якийсь високий відсоток, це, мабуть, код.
8. camelCase текст у публікації.
9. вкладені дужки, дужки та / або дужки.

Можна було б відслідковувати кількість появи кожного з них, і їх можна використовувати як функції в алгоритмі машинного навчання, як перцептрон , як це робить SpamAssassin.

Мені було б цікаво побачити, які середні показники письмової англійської мови з одного боку, а код - з іншого.

• довжина абзаців
• довжина ліній
• розмір слів
• використовувані символи
• співвідношення між буквеними, цифровими та іншими символьними символами
• кількість символів на одне слово
• тощо.

Можливо, це одне могло б розрізнити вже код і решту. Принаймні, я вважаю, що код, незалежно від мови, у багатьох випадках показав би помітно різні показники.

Хороша новина полягає в тому, що у вас вже є достатньо даних для формування вашої статистики.

Гаразд, я повернувся з деякими даними, щоб підтвердити свої припущення. :-)

Я зробив швидкий і брудний тест на власному пості і на перший пост я знайшов на StackOverflow , з досить просунутим інструментом: wc.

Ось що я мав після запуску wcтекстової частини та кодової частини цих двох прикладів:

Спочатку давайте розглянемо англійську частину :

• Англійська частина вашого допису (2635 знаків, 468 слів, 32 рядки)
  • 5 символів / слово, 82 символи / рядок, 14 слів / рядок
• Англійська частина іншого допису (1499 знаків, 237 слів, 12 рядків)
  • 6 символів / слово, 124 символів / рядок, 19 слів / рядок

Дуже схоже, ти не думаєш?

Тепер давайте подивимось на кодову частину !

• Кодова частина вашого допису (174 символів, 13 слів, 3 рядки)
  • 13 символів / слово, 58 символів / рядок, 4 слова / рядок
• Кодова частина іншого допису (4181 символів, 287 слів, 151 рядок)
  • 14 символів / слово, 27 символів / рядок, 2 слова / рядок

Подивіться, чим не такі різні ці показники, але важливіше, чим вони відрізняються від англійських метрик? І це лише використання обмеженого інструменту. Зараз я впевнений, що ви можете отримати щось дійсно точне, вимірявши більше показників (я думаю, зокрема, про статистику символів).

Я можу небезпечно використовувати печиво?

Зазвичай ланцюги Маркова використовуються для генерування тексту, але вони також можуть бути використані для прогнозування подібності тексту (за CE Shannon 1950 ) на навченій моделі. Я рекомендую кілька ланцюгів Маркова.

Для кожної поширеної мови навчіть ланцюжок Маркова на великому, репрезентативному зразку коду на мові. Потім для публікації переповнення стека, для якої потрібно виявити код, виконайте наступне для кожної з ланцюгів:

• Проведіть петлі по рядках.
  • Оголосіть дві змінні: ACTUAL = 1.0 та HIGHEST = 1.0
  • Проведіть цикл через кожен символ у рядку.
    • Для кожного символу знайдіть у ланцюжку Маркова ймовірність того, що поточний символ є тим, що слідує за попередніми N символами. Встановіть ACTUAL = ACTUAL * PROB ₁ . Якщо поточного символу немає в ланцюзі, використовуйте крихітне значення для PROB ₁ , наприклад 0,000001.
    • Тепер знайдіть символу, який найімовірніше (тобто найвища ймовірність) слідувати попереднім N символам. Встановити HIGHEST = HIGHEST * PROB ₂ .
    • Очевидно, PROB ₂ > = PROB ₁

Для кожного рядка у вас повинно бути АКТУАЛЬНЕ та ВИЩЕЕ значення. Ділимо АКТУАЛЬНО на ВИСОКІ. Це дасть вам бал придатності щодо того, чи є конкретний рядок вихідним кодом. Це пов'язує число з кожним із рядків у прикладі, який ви навели:

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

Нарешті, вам потрібно буде вибрати поріг, щоб визначити, коли в публікації є код. Це може бути просто число, вибране спостереженням, яке дає високі показники. Він також може враховувати кількість рядків з високою оцінкою.

Навчання

Для тренінгу придбайте великий, представницький зразок коду мовою. Напишіть програму, щоб перевести цикл на текст коду та пов’язати кожен N-грам у файлі (діапазон для N повинен бути параметризований) зі статистичною частотою наступного символу. Це призведе до отримання декількох можливих станів символів, які слідують за біграмою, кожен з яких пов'язаний з ймовірністю. Наприклад, біграма "()" може мати деякі наступні ймовірності символів:

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

Перший слід прочитати, наприклад, як "Ймовірність того, що крапка з комою слідує за порожньою дужкою, становить 0,5".

Для тренувань я рекомендую N-грам розміром від двох до п’яти. Ще коли я провів деякі дослідження з цього питання , ми виявили, що N-грам розміром від двох до п’яти добре працює для англійської мови. Оскільки велика частина вихідного коду схожа на англійську мову, я б запропонував почати з цього діапазону, а потім налаштувати, щоб знайти оптимальні значення параметрів, коли ви знайдете, що працює.

Застереження: на модель впливатимуть ідентифікатори, назви методів, пробіли тощо. Однак ви можете налаштувати навчання, щоб опустити певні особливості вибірки тренувань. Наприклад, ви можете звалити все зайве пробіли. Наявність пробілів у вході (пост переповнення стека) також можна ігнорувати. Ви також можете проігнорувати алфавітний випадок, який буде більш стійким за умови різних умов іменування ідентифікаторів.

Під час мого дослідження ми виявили, що наші методи добре працюють як для іспанської, так і для англійської. Я не бачу, чому це не спрацює також для вихідного коду. Вихідний код ще більш структурований і передбачуваний, ніж людська мова.

Чи можу я запропонувати радикально інший підхід? Щодо людської мови, дозволена лише англійська, тому все, що не є англійською, має 99,9% шансів стати фрагментом коду .

Тож моїм рішенням було б: використовувати одну з багатьох перевіряючих англійською мовою там (просто переконайтеся, що вони також подають сигнали - окрім неправильних написань - синтаксичні помилки, як подвійні крапки, або немовні символи на зразок #або ~). Тоді будь-який рядок / абзац, який видає велику кількість помилок та попереджень, повинен викликати "це код?" питання.

Цей підхід також може бути адаптований для тих сайтів StackExchange, що використовують інші мови, крім англійської, звичайно.

Тільки мої 2 ¢ ...

Я, мабуть, отримаю кілька голосів за це, але я думаю, що ви підходите до цього з іншого боку.

Цей рядок отримав мене:

люди повинні зайти і вручну відформатувати код для людей, які якимось чином не в змозі це зрозуміти

ІМО така точка зору є якось зарозумілою. Я знаходжу це багато в розробці програмного забезпечення, де програмісти і дизайнери дратуються користувачами, які не можуть зрозуміти, як правильно використовувати програмне забезпечення, коли проблема не в користувачі, а в самому програмному забезпеченні - або принаймні у користувальницькому інтерфейсі.

Першопричиною цієї проблеми є не користувач, а те, що їм очевидно, що вони можуть це зробити.

Як щодо зміни інтерфейсу користувача, щоб зробити це більш очевидним? Напевно це буде:

1. більш очевидно для нових користувачів саме те, що їм потрібно зробити
2. Вам простіше побудувати, а не писати складні алгоритми для виявлення логіки коду з безлічі мов

Приклад:

Псевдокод представляє справжню проблему, оскільки вся мова програмування залежить від спеціальних символів, таких як '[]', ';', '()' і т. Д. Просто порахуйте кількість цих спеціальних символів. Так само, як ви б виявили двійковий файл (більше 5% вибірки містить значення байтів 0).

Я думаю, що вам може знадобитися орієнтуватися на це лише на конкретні мови, загалом ця проблема, ймовірно, нерозв'язна, оскільки ви можете отримати мови, схожі на англійські (наприклад, inform7 ). але, на щастя, найбільш вживаних можна було покрити досить легко.

Першим моїм вирізом було б шукати послідовність "; \ n", яка допоможе вам відповідати C, C ++, Java, C # та будь-якій іншій мові, яка використовує подібний синтаксис і дуже проста. Він також рідше використовується англійською мовою, ніж a; без нового рядка

Хтось згадав, дивлячись на теги, а потім шукаючи для цього синтаксис, але це було збитий, оскільки це спрямовано на нових користувачів.

Можливим кращим рішенням було б шукати назви мови в тілі питання, а потім застосовувати ту саму стратегію. Якщо я згадаю "Javascript", "Java" або "C #", то, швидше за все, йдеться про це питання, і код у питанні, ймовірно, буде на цій мові.

По-перше, запустіть її через перевірку орфографії, вона знайде дуже мало правильних англійських слів, однак має бути багато слів, які перевірка орфографії запропонує розділити.

Потім з'являються пунктуаційні / спеціальні символи, нетипові для звичайної англійської мови, типові для коду:

• something(); просто не може бути простою англійською;
• $somethingде somethingне все числове число;
• -> між словами без пробілів;
• . між словами без простору;

Звичайно, щоб він працював добре, можливо, ви хочете, щоб басейський класифікатор був побудований на основі цих характеристик.

Є кілька наборів мов, які поділяють подібний синтаксис. на більшість мов вплинули кілька мов, тому мови [AMPL, AWK, csh, C ++, C--, C #, Objective-C, BitC, D, Go, Java, JavaScript, Limbo, LPC, Perl, PHP, Щука, обробка [на всіх впливав C, тому якщо ви виявите C, ви, ймовірно, виявите всі ці мови. тому вам потрібно лише написати простий шаблон для виявлення цих мовних наборів.

Я б також розділив текст на блоки, тому що найбільше коду буде розділено на два нових рядки або подібне від інших текстових блоків у публікації.

це можна легко зробити за допомогою javascript (надзвичайний неповний зразок для сімейства 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 + "]");
   }
}

Просто порахуйте слова / розділові знаки для кожного рядка. В англійській мові, як правило, 4 або більше, код менше 2.

В абзаці, наведеному вище, є 18 слів, наприклад, 4 знаки пунктуації. У цьому абзаці є 19 слів і 4 розділові знаки, тобто в межах очікувань.

Звичайно, це потрібно перевірити на запитання новачків з поганою англійською мовою, і, можливо, у цих випадках статистика перекошена.

Я очікую, що [непробільний простір]. [Пробіл або новий рядок] в коді дуже рідкісний, але поширений в англійській мові, тому це можна вважати словами, а не пунктуацією.

Я думаю, що найбільша проблема буде вбудованим кодом, де хтось задає питання типу:

Якщо я кажу за (i = 0; i> 100; i ++) {} що це означає?

Це код та англійська мова, і його слід позначати як зворотні кліщі:

Якщо я скажу, for (i=0; i>100; i++) {}що це означає?

Я думаю, спершу слід розрізнити (достатньо) відформатований код, який потрібно лише фактично призначити як такий, і (занадто) неякісний формат коду, який у будь-якому випадку потребує ручного форматування.

Форматований код має рядки та відступи. Тобто: якщо рядку передує один розрив, у вас є хороший кандидат. Якщо у нього поверх провідних пробілів, у вас є дуже хороший кандидат.

Звичайний текст використовує два рядки або два пробіли та розрив для форматування, тому існує чіткий критерій для розрізнення.

У коді LISP ви не знайдете крапки з комою, у коді Ruby ви не можете знайти дужки, у псевдо коді ви можете зовсім не знайти. Але в будь-якій (неезотеричній) мові ви знайдете пристойний код, який слід відформатувати з розривами та відступами. Нічого такого універсального немає. Тому що в кінцевому підсумку код написаний для читання людьми.

Отже, спочатку шукайте потенційні рядки коду . Також рядки коду зазвичай бувають групами. Якщо у вас є, є хороший шанс, що той, що знаходиться вище або нижче, також є рядком коду.

Виділивши потенційні рядки коду, ви можете перевірити їх у відповідності з критеріями , які можна оцінити, та вибрати деякий поріг :

• частота несловесних символів
• частота ідентифікаторів: дуже короткі слова або дуже довгі слова з стилем CamelCase або under_score
• повторення незвичайних слів

Крім того, тепер, коли є програмісти і cs, область stackoverflow чітко звужується. Можна було б позначати всі теги мови як мови. І коли ви публікуєте повідомлення, вас попросять вибрати або принаймні один тег мови, вибрати language-agnosticтег або явно пропустити його.

У першому випадку ви знаєте, які мови шукати, у другому випадку, можливо, ви захочете шукати псевдо-код, і в останньому випадку, мабуть, не буде жодного коду, оскільки це питання, пов’язане з якоюсь технологією або рамки тощо.

Ви можете створити аналізатор для кожної мови, яку ви хочете виявити (мовні визначення для ANTLR, як правило, легко знайти), після чого запустіть кожен рядок питання через кожен аналізатор. Якщо будь-який рядок аналізує правильно, напевно, у вас є код.

Проблема в цьому полягає в тому, що деякі англійські (природні мови) пропозиції можуть розбиратися як код, тому ви можете також включити деякі інші ідеї, або ви можете обмежити позитивні результати лише в тому випадку, якщо більше одного або двох послідовних рядків правильно розбирають той же мовний аналізатор.

Інша потенційна проблема полягає в тому, що це, ймовірно, не підбере псевдокод, але це може бути нормально.

Що може бути найбільш надійним у майбутньому і вимагає найменшого ручного налаштування в довгостроковій перспективі, оскільки інші мови (які виглядають дещо інакше, ніж мови програмування, які зараз використовуються найчастіше) стають все більш популярними, а використовувані в даний час мови стають менш популярними. щось на кшталт того, що робить Google Translate (див. параграф під назвою "Як це працює?"), а не шукати певні речі, такі як ab і a () тощо.

Іншими словами, замість того, щоб вручну придумувати шаблони, знайдені в коді, який потрібно шукати, комп'ютер може сам розібратися в цьому . Це можна зробити, маючи

1. багато коду в багатьох різних мовах програмування

   • Пропозиція: автоматично відбирайте зразки коду з веб-сховищ вихідного коду, таких як Google Code або Github, або навіть із речей у Stackoverflow, які вже позначені як код

   • Примітка. Це може бути гарною ідеєю проаналізувати коментарі до коду

2. багато англійського тексту, взятих із статей в Інтернеті

   • хоча не зі статей про програмування (інакше вони можуть мати в них код і змішувати систему :-))

і маючи якийсь алгоритм, автоматично знаходять шаблони в коді, яких немає в англійській мові, і навпаки, і використовуючи ці шаблони, щоб виявити, що таке код, а що не код, запустивши алгоритм на посадах.

(Однак я не впевнений, як би працював такий алгоритм. Інші відповіді на поточне запитання можуть мати корисну інформацію для цього.)

Тоді система може кожен раз повторно сканувати код для обліку змін у способі вигляду коду в цей момент часу.