2.3: Розширення кодів

Last updated
Save as PDF

Page ID: 29851

Paul Penfield, Jr.
Massachusetts Institute of Technology via MIT OpenCourseWare

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)

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

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

Прикладом досить доброякісного упередження є той факт, що ASCII має два символи, які спочатку мали намір ігнорувати. ASCII розпочався як 7-бітний візерунок отворів на паперовій стрічці, який використовується для передачі інформації на телетайпні машини та з них. Стрічка спочатку не мала отворів (крім ряду невеликих отворів, завжди присутніх, для вирівнювання та подачі стрічки), і пройшла через перфоратор. Стрічку можна було пробивати або з отриманої передачі, або людиною, друкуючи на клавіатурі. Уламки від цієї операції штампування були відомі як «чад». Лідер (перша частина стрічки) був неперфорований, а тому представляв, по суті, ряд символу 0000000 невизначеної довжини (0 зображено як відсутність отвору). Звичайно, коли стрічка читалася, ведучого слід ігнорувати, тому за умовністю символ 0000000 називався NUL і був проігнорований. Пізніше, коли ASCII використовувався в комп'ютерах, різні системи по-різному ставилися до NULs. Unix розглядає NUL як кінець слова за деяких обставин, і це використання заважає програмам, в яких символам дається числове тлумачення. Інший код ASCII, який спочатку мав бути ігнорований, - це DEL, 1111111. Ця конвенція була корисною друкаркам, які могли «стерти» помилку, створивши резервну копію стрічки та вибиваючи кожен отвір. У сучасних контекстах DEL часто розглядається як руйнівний backspace, але деякі текстові редактори в минулому використовували DEL як символ прямого видалення, а іноді його просто ігнорують.

Набагато більш серйозним ухилом, який несе ASCII, є використання двох символів, CR (повернення каретки) і LF (подача рядка), для переходу на нову лінію друку. Фізичний механізм у телетайпних машинам мав окреме обладнання для переміщення паперу (на безперервному рулоні) вгору та переміщення друкувального елемента на ліве поле. Інженери, які розробили код, який перетворився на ASCII, напевно відчули, що вони роблять хорошу справу, дозволяючи ці операції називатися окремо. Вони не могли собі уявити горе, яке вони дали пізнішим поколінням, оскільки ASCII був адаптований до ситуацій з різним обладнанням і не потрібно переміщати точку друку, як це закликає CR або LF окремо. Різні обчислювальні системи роблять речі по-різному - Unix використовує LF для нового рядка і ігнорує CR, Macintoshes (принаймні до OS X) використовують CR і ігнорувати LF, а DOS/Windows вимагає обох. Ця несумісність є постійним, серйозним джерелом розчарувань і помилок. Наприклад, при передачі файлів за допомогою FTP (File Transfer Protocol) CR і LF повинні бути перетворені відповідно до цільової платформи для текстових файлів, але не для двійкових файлів. Деякі FTP-програми виводять тип файлу (текстовий або двійковий) з розширення файлу (частина імені файлу, наступна за останнім періодом). Інші заглядають всередину файлу і підраховують кількість «кумедних персонажів». Інші покладаються на людський внесок. Ці методи зазвичай працюють, але не завжди. Домовленості про розширення файлів не дотримуються повсюдно. Люди роблять помилки. Що робити, якщо частина файлу є текстовою, а частина двійковою?