1. Сім разів відміряй, один відріж - така ще недавно була сумна доля восьмого біта при передачі по електронній...
2. ТАБЛИЦЯ СИМВОЛІВ ASCII
3. ТАБЛИЦЯ СИМВОЛІВ LATIN-1
4. ПАРТИЗАНИ НА РЕЙКАХ МЕРЕЖІ
5. ТАБЛИЦЯ СИМВОЛІВ ЯКІ-8
6. ІНШІ ТАБЛИЦІ СИМВОЛІВ
7. А ЯК ЖЕ З ПОШТОЮ?
8. ДЛЯ ІНШИХ ПОВІДОМЛЯЄМО ...
9. Перекодування В ПОЧТОВОЙ ПРОГРАМІ
10. перекодування постачальник
11. ЯК насторіть перекодування НА ПОЧТОВОЙ МАШИНІ
12. З ЯКОЮ ТАБЛИЦІ І В ЯКУ перекодувати
13. ЗВІДКИ
14. КУДИ
15. ВИСНОВОК

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

Давним-давно, чверть століття тому, американці створили Мережу. Спроектували вони її для наукових цілей, тобто для себе, американців. Комп'ютери, які ця мережа зв'язала між собою, так само були зроблені в Америці і для американців. І все було добре, тому що в Америці одні американці. Потім Мережа всім сподобалася, і її віддали народу. І комп'ютери з'явилися у народу, і не тільки у американського. А для оборонних цілей зробили ще одну Мережа, а потім ще.

ТАБЛИЦЯ СИМВОЛІВ ASCII

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

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

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

Так ось, коли американці створювали свої комп'ютери, вони вирішили, що для подання будь-яких друкованих символів з лишком вистачить 128 чисел. Ну справді, 27 малих літер, 27 прописних, 10 цифр, десяток знаків пунктуації - від сили 80 виходить. Так що ще й запас залишався, нічого не скажеш.

Ну далі зрозуміло, 128 це 2 певною мірою 7, значить для подання всіляких символів було досить 7 біт. Саме такий, 7-бітної, є таблиця символів ASCII. Перша літера означає "для Америки".

ТАБЛИЦЯ СИМВОЛІВ LATIN-1

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

Взагалі-то для подання кожного друкованого символу з самого початку розробники комп'ютерів і програмного забезпечення виділяли один байт. У байті завжди кілька біт, в процесі природного відбору вижили і розмножилися тільки байти, що складаються з 8 біт. Зайвий біт - це ще 128 символів, і там можна розмістити всі гачки і завитки, настільки милі серцю західних європейців. Так і була створена таблиця символів Latin-1. Краще, однак, не стало. Якби було добре, нічого було б і цю статтю писати.

ПАРТИЗАНИ НА РЕЙКАХ МЕРЕЖІ

Поява таблиці Latin-1 вирішило проблему уявлення деяких національних алфавітів. Але тепер потрібні були програми, здатні до цих уявлень працювати! Програми, які американці написали до цього, не мають на увазі наявності інформації в 8-м бите! Зрозуміло, програма, нерозрахованих на 8-й біт, може несподівано заробити і з 8-м бітом. Але це неякісна програма. Ті програмісти, добре встигали в школі, твердо запам'ятали: параметри функції слід перевіряти на область визначення, а результат - на область допустимих значень. І перевіряли, тим більше, що це було елементарно - 8-бітові символи виглядали точь-в-точь як негативні числа. Порівняв з нулем, і все. Те, що виходило за рамки, визнавалося сміттям. А рамки-то жорстко запрограмовані, значить, треба програму переробляти, а програм багато, а люди не вічні ...

Тепер уявімо собі європейця, що створює інформаційну систему для свого підприємства. Йому потрібна таблиця Latin-1, він шукає ПО, яка її підтримує, якщо чогось не знайшов, то розробляє сам. Зрештою проблема вирішується. Тепер той же самий європеєць вирішив повідомити про свій успіх іншому європейцеві за допомогою вкрай зручного способу спілкування - електронного листа. У кожного з них поштова система пропускає 8-й біт (припустимо). Але шляхи Господні несповідимі, і по дорозі повідомлення потрапляє на проміжну поштову машину, де 8-й біт по-старому вважають сміттям і обнуляют. Все, панове, приїхали.

Добре, якщо згадана вище нехороша машина знаходиться там же, в Європі. Можна, як то кажуть, піти і домовитися. А якщо не в Європі? А якщо поштових машин сто тисяч, і тільки тисяча з них "ріже" (обнуляє) 8-й біт? А листи ходять різними, часом непередбачуваними шляхами? Ви, напевно, погодитеся зі мною, якщо я порівняю такі поштові машини з диверсантами, залеглими біля залізничного полотна. І, як і в випадку з справжніми диверсантами, боротьба з ними була довгою і болісною.

ТАБЛИЦЯ СИМВОЛІВ ЯКІ-8

Тепер залишимо західних європейців, не такі вже вони, врешті-решт, нещасні. Ну втратили пару завитків в листі, інші букви-то читаються! Неприємно, але зрозуміло. Давайте подумаємо про нас, європейців не просто східних, а, як би це сказати ... далеко-східних. Наш алфавіт відрізняється від латинського повністю, символів в ньому багато (66), тому в таблицю Latin-1 разом з латинськими завитками він не вмістився. Придумали йому окрему таблицю, вона вийшла п'ятої за рахунком. В результаті називатися ця таблиця стала ISO 8859-5. Хто придумав цю таблицю, невідомо. ISO 8859-5 - це продукт в чистому вигляді, річ в собі, прекрасна в своїй чистоті і височини. Творці ISO 8859-5 абстрагувалися від маси технічних проблем, здатних вплинути на розташування російських букв в таблиці. Наприклад, вона конфліктує з псевдографікою в DOS, чомусь не підійшла для Windows. А тема нашої розмови - електронна пошта?

Уявіть собі лист, написаний російською, відправлене електронною поштою і нарвався по шляху на "диверсанта", зрізали у всіх листів 8-й біт. Після такого "обрізання" ті букви, що були росіянами, стають латинськими. Тими, чий номер в таблиці менше рівно на 128.

Тепер поставимо себе на місце розробників таблиці символів кирилиці, які бажають підвищити стійкість переданої текстової інформації до "обрізання". Напевно, нам захочеться зробити так, щоб адресат зміг зрозуміти зміст листа, написаного по-російськи, нехай і латинськими буквами. На щастя, значне число букв кирилиці має фонетичні аналоги в латинському алфавіті. Припустимо П і P, Р і R. До того ж є кілька співпадаючих і з написання. Значить, розумно розташувати російські літери таким чином, щоб вони відрізнялися від аналогічних латинських на число 128! Тоді втрата 8-го біта перетворить повідомлення хоч і в що складається з однієї латиниці, але все одно читається по-російськи текст. Неприємно, зате зрозуміло.

ЯКІ-8 якраз і є така таблиця. І саме вона застосовується для обміну поштою і новинами в Internet. Сподіваюся, я зміг довести вам, що ЯКІ-8 не дурощі, а сувора необхідність. Якщо ж ви вважаєте, що з винищуванням "диверсантів" ЯКІ-8 більше не актуальна, наведу один свіжий випадок.

Одна моя знайома поїхала в якості аспірантки в Англію. Там була машина і електронна пошта. Перший лист, який я від неї отримав, було на мові "ruglish", тому самому фонетичному еквіваленті, коли "здрастуй" виглядає як "zdrawstwuj". Бр-р ... Я, знаєте, віддаю перевагу творіння Кирила і Мефодія для спілкування з одноплемінниками, тому частина своєї відповіді написав по-російськи, в ЯКІ-8. Я це зробив в надії, що мій кореспондент, може бути, просто не знає, що все вже налагоджено. Якщо немає, то за симптомами (закарлючки таблиці Latin-1 замість російських букв, наприклад) можна було б запропонувати простий вихід, припустимо надіслати правильний екранний шрифт.

Але не тут-то було. По-перше, в тому англійському університеті, де працює моя знайома, затаївся "диверсант", і він зрізав 8-й біт в кожному символі мого послання (ось він, консерватизм!). В результаті ж лист було прочитано! Воно стало схоже на близький серцю виїхали російських "ruglish", хоча і відрізнялося в способі імітації ряду букв. Ні про яке використанні кирилиці й мови більше не було, адже "ruglish" це так зручно - "my vse tak pishem". Але це вже тема для соціологічної науки.

ІНШІ ТАБЛИЦІ СИМВОЛІВ

Отже, придумали таблицю символів (ми ще говоримо: "кодування", оскільки за допомогою таблиці "закодований" російський алфавіт) для обміну поштою і назвали її ЯКІ-8, що означає "код відображення інформації 8-бітний". І, скажете ви, нарешті все утворилося. Ні, дорогі читачі, не утворилося (хоча і стало легше, звичайно). Тому що трапився черговий якісний стрибок в настанні комп'ютерів на нашу маленьку планету. Недорогі персональні комп'ютери зробили величезну кількість нічого не підозрював народу користувачами. А коли маса народу опановує якийсь ідеєю або річчю, ця ідея або вешь настільки видозмінюється, що добре, якщо не стає своєю протилежністю. Так і з комп'ютерами. Персональні виставки перевернули все догори дригом.
Раніше комп'ютерний користувач дещо знав про своєму комп'ютері і грамотно його використовував - тепер більшість очікує від машини, що вона сама себе налаштує, налагодить, домовиться з іншими машинами, а користувачеві залишиться тільки отримувати задоволення. Просити користувача прочитати п'ят сторінок керівництва і ввести пару адрес Internet - мало не поганий тон.
Я не хочу сказати, що це погано - просто це інше життя.

Чи треба пояснювати, що величезна маса персоналок мала свої власні проблеми і встановлювала свої власні стандарти. Одна з таких проблем нас з вами стосується - це підтримка російської мови. Електронна пошта мало кого тоді хвилювала, а ось вводити і обробляти російські тексти в численних програмах для DOS треба було всім. Кодування ЯКІ-8 не підходила для цієї мети (так само, як і ISO 8859-5), в її таблиці деякі російські літери перебували на тих місцях, які за розуміння зарубіжних програм були заповнені графічними символами - вертикальними і горизонтальними рисками, різними куточками, прямокутниками і т.д. Псевдографічні символи були дуже важливі - з їх допомогою персональні виставки робилися привабливими для користувачів. Тому була придумана ще одне кодування кирилиці, в таблиці якій російські літери "обтікали" з усіх боків графічні символи. Назвали це кодування "Альтернативною", оскільки вона була альтернативою офіційним стандартом - кодуванні ISO-8859-5. Останню, щоб не образилася, стали величати "Основний". Але нею все одно майже ніхто не користувався.

Коли настала чергова революція і всі кинулися освоювати Windows, з'ясувалося, що Альтернативна кодування не підходить - кажуть, якусь її частину перші версії системі Windows не обробляли ( "не пропускали"). Основна теж не підійшла. Анітрохи не вагаючись хтось підсунув російські букви в таблиці так, щоб всі вони "пролізали", благо псевдографіка в Windows не потрібно, і вийшла кодування "Windows 1251", сама, напевно, тепер поширена.

А ЯК ЖЕ З ПОШТОЮ?

Отже, ми назвали чотири кодування кирилиці. Всі вони об'єктивно існують, все використовуються. А пошта? Internet - це те місце, де питання, яке кодування застосовувати, перестає бути особистою справою кожного. Якщо ви відправляєте комусь повідомлення, то, ймовірно, для того, щоб його прочитали. Якщо ваш одержувач працює в DOS, а ви в Windows, то проста пересилання тексту навряд чи допоможе. Навіть якщо лист, відправлений в альтернативному кодуванні з DOS, дійде до адресата в неспотвореному вигляді, одержувачу доведеться:

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

Для тих, хто не хоче нічого налагоджувати, є готові рішення. Наприклад, для DOS - пакет під назвою UUPC. Вам доведеться його встановити і користуватися тільки їм, і тільки в DOS, і тільки в поєднанні з модемом. Зате він буде конвертувати відправляється кореспонденцію в кодування КОИ-8, а приходить - в Альтернативну. Вам про це думати не треба. Якщо хочеться чогось красивіше - читайте далі.

ДЛЯ ІНШИХ ПОВІДОМЛЯЄМО ...

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

Користувач взаємодіє з поштовою програмою (user agent), яка дозволяє йому вводити і читати листи, організовувати зберігання прийшли листів, вести адресні книги і т.д. Можна сказати, що основна функція поштової програми - надати зручний призначений для користувача інтерфейс. Щоб доставити або отримати лист, поштова програма звертається до Доставщик (delivery agent), призначеного для користувача інтерфейсу не має, зате володіє тонкощами маршрутизації кореспонденції. Доставщик безпосередньо або через проміжні машини передає лист іншому постачальник, який обслуговує адресата. Той кладе лист в персональний поштову скриньку, звідки його забирає поштова програма одержувача. Це схема загальна, в реальному житті для користувача поштова програма може виконувати частину функцій доставщика. Ми розглянемо деякі варіанти нижче.

Отже, десь треба перекодувати листи. Що йдуть - в ЯКІ-8, що приходять - в ту кодування, яку вважає за краще користувач. Виходячи з нашої схеми це можуть зробити і поштова програма, і постачальник.
Розглянемо кожен варіант.

Перекодування В ПОЧТОВОЙ ПРОГРАМІ

Взагалі-то, в ідеалі пошту треба приводити до стандартного вигляду якомога раніше, ще перед відправкою. В цьому випадку ми не ризикуємо нарватися на помилку або на збій при доставці, пов'язані з неправильною кодуванням листи. Однак тут є складнощі.
Як ви, напевно, помітили, модульність наведеної вище схеми надає нам свободу вибору поштової програми. Таких програм досить багато. Їх десятки для Unix і сотні для Windows. Сам цей факт повинен нас насторожити, якщо ми збираємося виробити скільки-небудь спільне рішення. Адже все це достаток створено іншими людьми, в більшості своїй американцями (див. Вище), які не підозрювали про нашу з вами потреби пошту перекодувати. І ніяк вони не пристосували свої (в іншому - просто чудові) програми до такої перекодировке.

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

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

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

Вам гарантований успіх, якщо поштова програма не надто розумна і не намагається аналізувати вводяться вами символи на предмет їх приналежності до якого-небудь алфавітом. В іншому випадку вам доведеться ще розібратися, яким чином вона це робить.
У більшості випадків поштові програми лякаються будь-яких 8-бітних символів і починають їх шифрувати при відправці так, що потім 90% народу прочитати не може. Це гордо називається MIME, "quoted-printable" та ін. Якщо ви хочете бути зрозумілим, відключайте шифровку 8-бітних символів. Далеко не всі поштові програми можуть автоматично і коректно відновити текст з беззмістовного набору букв, цифр і розділових знаків.

Посилаючи подібні листи невідомому адресату (з яким ви не встигли домовитися про ваше загальне форматі листів), ви проявляєте до нього неповагу. Я особисто сприймаю такі послання не як неповагу, а як прояв технічної безграмотності, не знаю, що для відправника краще. Зазвичай подібними речами грішать торговці, що завалюють наші поштові скриньки своїми оголошеннями.
Найбільш одіозний випадок з моєї практики - лист, що містить зашифрований програмою UUENCODE
ZIP-архів, в свою чергу містить текст у Альтернативною кодуванні. Скільки треба витратити часу, щоб його прочитати користувачеві Windows? При цьому лист не дуже велике, компресія дає економію тільки відправнику, розсилати його по сотням, а то й по тисячам адрес.

перекодування постачальник

Отже, не києм так катаніьем, поштову програму для Windows можна змусити відправляти листи в ЯКІ-8. Але зусилля потрібні значні, і не завжди виходить зручно.

Набагато краще, якщо програмне забезпечення поштової машини саме може перекодувати пошту. Тоді ви берете ту поштову програму, яка вам більше до душі, і все. Тільки не забудьте відключити шифрування 8-бітних символів.

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

Перша служить для відправки пошти і називається "служба SMTP". SMTP - протокол передачі листів в Internet. Взагалі-то, служба SMTP і приймає листи теж, а не тільки відправляє. Однак при прийомі кореспонденції користувачам персоналок на SMTP розраховувати не доводиться. Справа тут ось у чому: служба SMTP виходить з того, що машина-одержувач завжди готова до прийому пошти. 24 години на добу, 7 днів на тиждень. Звичайно, вона зможе перечекати короткочасний збій, але це вже ненормально, ПП. Зрозуміло, що постійна готовність до прийому пошти з ініціативи віддаленого сервера не їсти властивість персональних комп'ютерів. Їх просто вимикають, коли не використовують, не кажучи вже про низьку надійність, ущербної багатозадачності і т.д.

Тому пошта, призначена для користувача ПК, складується на поштовій машині. Передається вона на персоналку з ініціативи користувача, коли він готовий її прийняти. Цим завідує служба POP (Post Office Protocol).

Далі все очевидно: сервер SMTP треба навчити переводити листи з тієї кодування, в якій, по волі Аллаха, представлено відправляється лист, в кодування КОИ-8. Сервер ж POP повинен переводити листи з ЯКІ-8 в ту кодування, яку зможе зрозуміти користувач. В яку тільки ... І хто буде вчити ...

ЯК насторіть перекодування НА ПОЧТОВОЙ МАШИНІ

Як і у випадку з поштовими програмами, постачальник вже написані. Найбільш відомі програми такого роду - sendmail і MMDF. Причому sendmail є стандартом de-facto. Sendmail входить в будь-який Unix і, крім того, доступний у вихідних текстах.

Ми не будемо зараз говорити про несумісних з SMTP (тобто з Internet) поштових системах, таких як Lotus cc: Mail, Microsoft Mail. Всередині мереж, що обслуговуються подібними системами, що підтримують російську мову, напевно або все в порядку, або безнадійно. Нас це не стосується, ми розмірковуємо про пошту в Мережі, з якої несумісні поштові системи поєднуються за допомогою шлюзів.

До речі, якщо в черговий раз прозвучало слово "Unix", то треба нарешті порозумітися з тими, хто це ім'я переносить погано. Отже, якщо Unix викликає у вас алергію, підставляйте замість нього далі по тексту одне зі слів: NT, VMS, DOS, NetWare. Чим далі вибране вами слово стоїть в списку, тим дорожче і незручно буде ваше рішення.

В оригінальному вигляді ні sendmail, ні MMDF не призначені для перекодування пошти. Однак і та й інша мають модульну структуру, інакше складаються з кількох самостійних програм, кожна з яких виконує своє завдання. Одна приймає кореспонденцію від локальної поштової програми (тобто працює на тій же машині, що і постачальник), інша відправляє листи через повільні модемні з'єднання по протоколу UUCP, третя завідує комунікаціями по SMTP, четверта кладе пошту в поштові скриньки користувачів. І є центральний розпорядник, який всім керує. Для того щоб організувати перекодування, потрібні нам модулі треба модифікувати. Для цього зовсім не обов'язково їх переписувати і перекомпіліровать. Модуль можна "обернути" в універсальний перекодировщик. Такий універсальний перекодировщик викликається замість оригінального модуля, приймає за нього листи, перекодує їх і передає в обробленому вигляді оригінального модулю. Аналогічно можна "обернути" і сервер POP.

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

( 1х1 )

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

З ЯКОЮ ТАБЛИЦІ І В ЯКУ перекодувати

Тут головне не помилитися. Якщо текст представлений в Альтернативною кодуванні, а ви його конвертуєте, як ніби він в Windows 1251, то я вам гарантую, що інформація буде серйозно пошкоджена, якщо не знищена.

У випадку з приходять листами (ми припускаємо, що вони в ЯКІ-8, але розраховувати на це теж не можна!) Треба знати, яке кодування використовує одержувач. Користувачі Windows бажають отримувати листи в 1251, DOS - в Альтернативною, а на Unix взагалі можуть існувати всі кодування одночасно.

Це була постановка проблеми, тепер рішення. Рішення називається Cyrillic Support Manager, або скорочено CSM. CSM - це комплексний кіріллізатор Unix; він є для всіх комерційних реалізацій цієї операційної системи, а також для Linux, правда, в неповному обсязі. Система перекодування пошти є складовою частиною CSM. Давайте подивимося, як вона вирішує поставлене завдання (звідки і будь-що перекодувати листи).

ЗВІДКИ

Як завжди, є кілька підходів до проблеми. Ось деякі з них:

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

Другий підхід набагато могутніше. Адміністратор поштової машини один раз визначає, що клієнтська машина з таким-то мережевим ім'ям або адресою працює в кодуванні, скажімо, Windows 1251. І тепер вся кореспонденція, що відправляється з даної машини, вважається поданою тільки в цьому кодуванні. А якщо у машини немає постійної адреси? Вона може переміщатися по країнах і континентах, підключаючись до різних вузлів Internet, але все одно звертатися до свого поштового сервера і поштової скриньки. Навіть якщо користувач з'єднується з одним і тим же провайдером, він може отримувати на час кожного сеансу інший IP-адресу. Та й в локальних мережах динамічний розподіл адрес застосовується.

Виділений віртуальний сервер. Давайте запустимо на одній поштовій машині чотири поштових сервера одночасно, по одному на кожну кодування. Кожному сервера дамо окреме мережеве ім'я і окремий IP-адреса, наприклад win.mail.access.ru, alt.mail.access.ru, koi.mail.access.ru, iso.mail.access.ru. Запропонуємо користувачам Windows звертатися зі своєю поштою на сервер win.mail.access.ru, DOS - alt.mail.access.ru і т.д. Цей варіант не вимагає фіксувати IP-адреса клієнта, не примушує користувача в кожний лист вводити інформацію про його кодуванні. Користувачеві досить при конфігурації своєї поштової програми правильно вказати адресу поштової машини. Якщо він з цим впорається, то все ОК. А якщо немає? Користувач, він такий. Або включить До свого листа з Windows, текст в Альтернативною кодуванні? У нього ж на машині ще й DOS є! Якби у нас не було четвертого варіанту, ми б сказали, що це проблеми користувача. Однак у нас ще четвертий підхід є.

Ідея автоматичного визначення кодування виглядає значно краще, і це рішення набагато ближче до ідеального. Однак необхідний хороший алгоритм розпізнавання, якому ми могли б довірити свою інформацію. Адже помилкова перекодування призводить, як ми вже згадували вище, до її втрати. Проста перевірка байтів на потенційну приналежність до тієї чи іншої таблиці символів не годиться. Справа в тому, що всі чотири кодування сильно перетинаються між собою, і потрібен дуже великий текст, щоб зібрати достатньо статистики. Тому, якщо ми хочемо надійно визначити, в якому кодуванні представлений текст, то повинні спробувати його прочитати, перебираючи всі варіанти. Саме так вчинив би людина. Але як навчити читати комп'ютер? На щастя, комп'ютера в даному випадку не треба вміти повноцінно читати, досить навчитися відрізняти російську мову від абракадабри. Можна було б спробувати застосувати одну з програм корекції правопису, наприклад. Однак що робити з граматичними помилками? Є такі "письменники", що здатні звести подібні програми з розуму ...

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

КУДИ

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

Файли - річ хороша, але вони не годяться в випадку з непостійними IP-адресами (див. Вище). Коли ж мова йде про локальні користувачів Unix, це найкращий вихід. Робоча кодування користувача або бажана їм кодування поштової скриньки завжди відома з системних або персональних конфігураційних файлів CSM.

Віртуальний POP-сервер (саме по POP-протоколом отримують свою кореспонденцію користувачі персоналок) не тільки дає нам можливість змінювати IP-адресу клієнтської машини на свій розсуд, але і полегшує адміністрування локальної мережі. Кожну нову машину в файлі конфігурації описувати не треба. А вводити ім'я поштової машини в поштову програму треба в будь-якому випадку.

ВИСНОВОК

Сподіваюся, що автор вніс деяку ясність в питання про те, як повинна передаватися російськомовна пошта. Так, в даний час для організації нормальної роботи пошти потрібні додаткові зусилля. Добре, якщо ця робота покладається на плечі професійних (тобто отримують за це плату) адміністраторів поштових машин. Гірше, якщо проблемою перекодування доводиться займатися кінцевому користувачеві. Це трапляється рідко, в основному за кордоном, але тим складніше людині - ні з ким порадитися, в кінці кінців. Може бути, ситуація скоро зміниться. Нам дуже хочеться листуватися з вами по-російськи, а не "po-russki".