1990年代前半を通じて、ロシアのインターネットはオタクたちにとっては楽しかったままでした。「使用するプロトコルを立ち上げるには、高等教育だけでは十分ではありません。」その後、インターネットがよりアクセスしやすくなり、人気が高まったとき、別の不幸が彼を待っていました-キリル文字のサポートで跳躍。失われるには、異なるエンコーディングで十分でした。

1997年3月に、Computerraはこの問題を「問題のトピック」として選択し、非常に多くのエンコーディングの由来とそれらがすべて使用される理由からストーリーを開始し、このすべてを進める方法に関する推奨事項で終わりました。略語なしで、ジャーナルのテキストをそのまま再入力します。私は、 ~~このテキストがまだGoogleに知られていないことを~~再確認~~しました~~ 。しかし、私の意見では、Unicode時代以前のこのような「スラブ語の執筆の記念碑」は、電子形式で保存する価値があります。

（この機会に、 2年前にCP-1251の公式作成者であるKatya Lazhintsevaについての私の話題にも触れます。）

オレグ・タタルニコフ

十字軍

あなたは影を追いかけているので、あなたは存在感を失います。

ヨブ記から

もともと米国国防総省の単一の中央集中軍システムで開発されたインターネットの概念は、すぐに「独裁の足かせ」から抜け出し、今では世界的に一般にアクセス可能な情報ハイウェイのアイデアとして認識されています。ネットワークへのアクセス、検閲、および外部の影響を制限しようとする試みは、敵意を持って世界のコミュニティによって明確に認識されます。私たちの生活でインターネットが広く採用されている背景には、組織はありません。それは自己組織化システムであり、その主なエンジンはすべて人類です。これは、World Wide Webと商用ネットワークの主な違いです。これは、何百万という人々へのアピールと強みです。この観点から、ロシアの大規模な「協同組合」情報交換の支持者は見苦しく見え、すべてのロシアのユーザーを単一のエンコーディングのプロクラスンのベッドに追い込もうとしています。さらに、このイデオロギーのキャリアは、ロシアのインターネットユーザーのうち、最も活発なユーザーであっても、絶対的な少数派です。さらに、これによって彼らが導かれる善意は、自由を強制的に制限し、急速に増え続けている膨大な数のユーザーに追加の不便をもたらす言い訳にはなりません。道路が通常そのような意図で舗装されている場所が知られているからです。

この記事を書いた理由は、著者や他の多くの「ロシア語」のインターネットリソースサブスクライバーに読めない形式で電子メールで送られた多数のメッセージでした。クロス」）。さらに、これの主な「犯人」は、インターネットリソースのプロバイダーであることが判明し、そのような事件から顧客を保護する義務がありました。

すべての既存の問題を理解し、可能な解決策を見つけようとして、既存の困難を克服することに最も興味がある人、つまりソフトウェア開発者、インターネットプロバイダー、そして当然のことながら顧客に直接頼りました。

これらのグループ間に存在する明らかな不一致すべて（それぞれが1つの共通の分母でわずかに異なる目標を追求する-不必要な作業から身を守るため）、共通の問題を理解するための和解の必要性は明らかです。

したがって、3つの主要なインターネットリソースがあります（ロシア語には1つの問題がありますが、異なる解決策がある可能性があります）。

メール（メール）
ニュースグループ（ニュース）;
WWWリソース。

近い将来、明らかに、WebでKOI8-Rエンコーディングを使用することから逃れることはできません（最大のインターネットプロバイダーの慣性が影響します）。そのような「宗派的」コミットメントによる損害を最小限に抑えるためにのみ残っています。しかし、統一を普遍的に望んでいるとしても、将来はすべてのアカウントがユニバーサルUnicodeエンコーディングを獲得することに属します。テキストとそれに使用されるすべてのフォントとレイアウト。これにより、国のアルファベットを含むいくつかの問題が一度に解決されます。

メール

子供たちが小屋に駆け込んできました

急いで彼らは父親を呼ぶ：

叔母、叔母、私たちのネットワーク

死んだ男を引きずりました。

A. S.プーシキン

電子メールは2人の個人（送信者と受信者）の問題です。理想的には、クライアントプログラムの製造元は、メッセージが到着したエンコーディング（可能なものの1つ、実際には2つまたは3つ）から、このコンピュータープラットフォームおよび/またはオペレーティングシステムで受信されたローカルコンピューターに、およびその逆に転送する機能をユーザーに提供できます（例：MIME文字セットの名前付き）。しかし、チャンスだけです！そのため、ユーザーはいつでもそれを拒否し、必要に応じてメッセージを送信できます。いずれにしても、サーバーはこれを行うべきではありません。一般に、通信（転送を除く）を伴う行為は、文字の閲覧に似ているため、厳密に禁止する必要があります-彼（サーバー）は犬の仕事ではなく、単なる郵便配達、輸送です。一般的なルールはまだ策定されておらず、プログラムは「曲がって」機能していますが、あらゆる種類の迂回作戦が使用されており、状況を悪化させるだけです。

これから抜け出す唯一の方法は、送信者にすべての責任を負わせることです（デフォルト）。別の合意により、もちろん、彼に他の機会を提供することができますが、選択する権利を残します。しかし、今日は何が見えますか？サーバー所有者は「不自然なインテリジェンス」を含み、メッセージをKOI8-Rに強制的にトランスコードします。紳士よ、慈悲を！私たちの多国籍国でメッセージを書く方法と言語をどのように知っていますか？なぜ私はそれを暗号化せず、好きなようにエンコードしないと思いますか？全能で全知の自分を想像し、個人情報を破壊する権利を自分に与えているのはなぜですか（これがよくあることです）。コード表を見てください。トランスコーディングとは何ですか？これは、特定の数の文字コードへの加算（または減算）であり、コードテーブル内の文字の位置の差によって決まります。ダブルまたは不正なトランスコーディングの結果、受信したコードが範囲0〜255から「飛び出す」と、シンボルに関する情報が失われます。練習として、KOI8-Rに再コーディングしてみてください。たとえば、代替のDOSエンコーディングで提示されたテキストをWindows 1251で使用して、何かを復元してみてください...

ZealotsはNatscapeの頭脳さえ持っており、Netscape Navigatorブラウザーを使用することはまったく不可能です。たとえば、Windows 1251からKOI8-Rにエンコードします。

最後に、Uuencode、MIME、Quoted-printable、およびその他の8ビット文字暗号化機能があります。これは、8ビット目が「切り捨てられた」場合でもメッセージの送信を保証するために考案されています。そして、誰もが「ネイティブ」エンコーディングを使用できます-そして、彼らは私たち全員を1つのストールに追い込もうとしています。もちろん、すべてのメールプログラムが空の文字、数字、句読点のセットからテキストを自動的に正しく復元できるわけではありません。どうする？不明なサブスクライバーに大量メールを送信するつもりがない場合は、受信者にいつでも同意できます。この場合、特別な暗号を使用すると便利です（サーバートランスコーディングのサポーターはこの可能性を完全に拒否します）。

はい、不明な宛先（あなたとあなたの両方に受け入れられる形式に同意することができなかった相手）に手紙を送ると、トラブルに巻き込まれる危険があります。しかし、それはあなたの良心にあるべきです！すべてのエンコーディングを同時に使用するか、英語で書く方が簡単です。または、ロシア語ですが、英語の文字で（「あまりにもスマート」なプロバイダーの努力にもかかわらず、多くの人がそうします）。現状は容認できません！プログラムはバージョンごとに設計ルール、データ形式、コーディングを変更します。サーバーは「不自然な」インテリジェンスと「不可解な」忍耐力を獲得し、ユーザーはビジネスを行う代わりに「欺く」手段を探しています。そして、現在の状況は不安定なので誰も保証できませんが、あらゆる種類のトリックのおかげで、状況は悪化しています。特定のエンコード（可能性のある2つまたは3つ）で手紙が送られてきた場合、自分にとって不便であっても、自分で再エンコードすることができます。途中で2つまたは3つの「暴力的な」変換が行われた場合、情報は絶望的に失われます。

インタレストカンファレンス

>>>>しかし、誰に？

>>>私！

>> th CHOE !!!

>私はね!!!

そして私も!!!!

電話会議は、どのエンコードを使用するかという疑問が全員の個人的なビジネスでなくなる唯一の場所です。公開読書のためにメッセージを送信する場合、明らかにそれを統一する必要があります。

もちろん、会議でいくつかの異なるエンコーディングをサポートするのは非常に愚かなことです。1つに焦点を合わせるのは合理的です。歴史的に-これはKOI8-Rです。たとえそれがより良い時期まで残っていてもです。最後に、議論への参加または不参加は、すべての人と彼自身の問題の個人的な問題でもあります。既存のニュースグループに参加したい場合-「共同認証」はしたくない-自分で（サーバー上および「独自の」エンコーディングで）作成します。参加者がいます-会議があり、参加者は去ります-会議は消えます。

私個人の意見では、パブリックニュースグループの情報価値はかなり低く、真剣な議論は専門のメーリングリストで行われ、情報の詰まりを回避し、オンラインでリアルタイムの情報を取得し、チャットでチャットすることができます。インターネットに代わるものとしてネットワークを守る「攻撃的な」ファイドは、メッセージへの回答を、場合によっては数か月間待ち、それらに対する質問と回答の不一致により、さらに混乱が生じます。

電話会議の参加者のグループはWebで最大ではありませんが、経験が最も影響力があり、保守的であることを示しています。「まあ、KOI8はまだ使用する習慣でした。たとえば、ニュースを読む必要があります。これまで。そして、私はKOI8で何かを読まなければならないので、他のすべてのエンコーディングは私をイライラさせます」（Mikhail Isaev、電話会議relcom.talkでのロシアのエンコーディングの議論から）。

ただし、回答よりも質問が多くあります。時々ロシア語をサポートするという苦しい問題が既存の会議で浮上し、情熱が新たな活力で燃え上がります。これらの議論に参加する場合、個々の参加者の意見に頼るべきではありません。彼らの一部は、若い年齢にもかかわらず「テリー」保守派であり、他の人は有益な活動に負担をかけない話者のようです。特定のクランに属しているという感覚を兼ね備えており、その主な属性はエンコーディングKOI8-Rへのコミットメントです。たぶんこれのために必要ですか？マシンにKOI8-Rサポートをインストールし、まだ実行していない人を軽視して、少なくとも吸盤または少なくともラマーで呼び出して「クール」に感じるのは良いことです。

しかし、私はこの分野の非常に深刻で有名な人々の視点を見つけました：Andrei Chernov、UUPC / @ mailプログラムの開発者であり、RFC 1489（Internet Request For Comments）提案のイニシエーターであり、ロシア語エンコーディングKOI8-Rの使用をプレゼンテーションの推奨として登録しますキリル文字を含むネットワーク内の情報（および、アプリケーションからのとおり、他のキリル文字の意見を考慮しない一般的なキリル文字）; RelcomカンファレンスのコーディネーターであるDmitry Martynov、およびロシアでのインターネットテクノロジーの形成と開発に携わっている私が知っている他の人々。彼らの意見はすべてが一致するわけではなく、もちろん、それらのすべてが「過酷な」措置を支持しているわけではありません。

会議でのスピーチは誰にも何の義務も負わないため、インターネットを離れることなく、原則としてその場で情報を確認および再確認する必要がありました。一般に、情報の大部分は仮想交換の結果として取得されます。さらに、後者の疑いのない利点は、いつでも強制シャットダウンされる可能性があることです。会議は公開されており、公開されているため、著者の同意を得て、個人的な通信で表明された意見や考慮事項を自由に引用する権利を留保します。

したがって、重要な意見は、「1251に「ろくでなし」がなければ、彼らはKOI8-Rマシンに「窓」を取り付けていれば、消えなかっただろう」（Dmitry Martynov）。一方で、Windowsベースの「スターター」はますます増えています...

ロシア語のコーディング

主題の精神を真に理解するためには、定義をマスターすることが特に重要です。

S. K.クレーネ、「数学論理」

エンコードとは何ですか？これは、アルファベット文字、句読点、数字、特殊文字など、多くの異なる文字をコンピューターで表現する方法です。

ロシアの文字を表現するためのいくつかの異なるエンコーディングの厄介な共存とそれに関連する問題について議論し、彼らはほとんどキリルとメトディウスを見ています。自慢してください...アメリカ人でさえ、最近まで少なくとも2つのエンコーディング、EBCDIC（拡張バイナリコード10進インターチェンジコード）とASCII（情報交換のためのアメリカ標準コード）がありました。。

EBCDIC回路は長い間メインフレームでIBMによって使用され、文字を表すために8ビットを使用していました。しかし、アメリカ人はお金を節約することを決定し（アメリカの文字セットは最も小さく、イギリス人でもポンド記号を示すために追加のアイコンが必要です）、ASCIIスキームを採用しました。アメリカ人は、印刷された文字を表現するには128桁で十分であると判断しました（実際：小文字27文字、大文字27文字、10桁、句読点12文字、そしてそれだけです）。まだマージンがあります。

他のエンコーディングがあり、長い間、それらはすべて同じ条件で共存していました。しかし、突然、米国政府は州レベルでASCIIコーディングをサポートするために「彼の頭にそれを取り込んで」、誰もが主要顧客と提携しました。しかし、中央集権化され計画されたソビエト国民経済は、それほど小さなことすらしませんでしたが、逆に、どうやらm笑の目的で、コーディングによっていくつかのGOSTを採用し、この問題を偶然に任せました。すぐに、すべての「静止」GOSTが忘れられ、今日、米国の「クラッカー」に「提示された」という事実を活用します（この場合、特定のクラッカーの国籍は関係ありません。彼らの「欠陥」）。

	00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F
80
90
A0		よ
B0	A	B	で	G	D	E	F	3	そして	Th	に	L	M	N	ああ	P
C0	P	と	T	で	F	X	Ts	H	W	うん	B	S	B	E	ゆう	私は
D0	でも	b	で	g	d	e	まあ	s	そして	番目	に	l	m	n	について	n
E0	p	と	t	で	f	x	c	h	w	あなたは	b	s	b	あの	y	私は
F0
シンボルテーブルISO 8859-5

	00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F
80	A	B	で	G	D	E	F	3	そして	Th	に	L	M	N	ああ	P
90	P	と	T	で	F	X	Ts	H	W	うん	B	S	B	E	ゆう	私は
A0	でも	b	で	g	d	e	まあ	s	そして	番目	に	l	m	n	について	n
B0
C0
D0
E0	p	と	t	で	f	x	c	h	w	あなたは	b	s	b	あの	y	私は
F0	よ
文字テーブルCP 866（DOS）

	00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F
80
90
A0									よ
B0
C0	A	B	で	G	D	E	F	3	そして	Th	に	L	M	N	ああ	P
D0	P	と	T	で	F	X	Ts	H	W	うん	B	S	B	E	ゆう	私は
E0	でも	b	で	g	d	e	まあ	s	そして	番目	に	l	m	n	について	n
F0	p	と	t	で	f	x	c	h	w	あなたは	b	s	b	あの	y	私は
文字テーブルCP 1251（Windows）

	00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F
80	A	B	で	G	D	E	F	3	そして	Th	に	L	M	N	ああ	P
90	P	と	T	で	F	X	Ts	H	W	うん	B	S	B	E	ゆう	私は
A0
B0
C0
D0														よ		私は
E0	でも	b	で	g	d	e	まあ	s	そして	番目	に	l	m	n	について	n
F0	p	と	t	で	f	x	c	h	w	あなたは	b	s	b	あの	y
Macintoshキャラクターテーブル

拡張ASCII文字テーブル（IS08859-5、DOS 866、WINDOWS 1251、Macintosh）

月の下で無限に迷う

三つの額が私にcounted骨を数えた。

第三に失われた...

5回目のロスト...

誰もが私たちとうまくやっていない方法!!!

S.スタチン

ASCIIテーブルの拡張は、ヨーロッパ諸国の要求に応じて行われました（そして再び政府の介入まで）。ほとんどのヨーロッパのアルファベットの印刷文字を表すには、バイトの8ビットのみを「返す」必要がありました。余分なビットはさらに128文字で、国のアルファベットのすべての発音区別符号をそこに配置できます。これは、拡張ASCII文字テーブルが作成された方法です。しかし、それまでに作成されたアメリカのソフトウェアは7ビットエンコーディング用に設計されており、多くの問題が発生しました。その説明はこの記事の範囲外です。

私たちのアルファベットはラテン語のアルファベットとは完全に異なり、その中にさらに文字があり（66）、他のヨーロッパのアルファベットのように、拡張ASCIIテーブル（ISO 8859-1、またはLatin-1、ISO-国際標準化機構、標準化のための国際組織があります）。言語ごとに別々のテーブルを作成する必要がありましたが、私たちのテーブルは5番目の行であるISO 8859-5でした。結果として生じる純粋な製品は定着していません。 ISO 8859-5は、ロシアのコンピューターの断片化とIBM-PCの開発の両方で機能不全に陥りました。そのオペレーティングシステムでは、ビルゲーツとマイクロソフトが擬似グラフィック（垂直線と水平線、さまざまなコーナー、長方形など）を使用し、ISOテーブルのロシア文字の代わりになりました8859-5。私はロシア語の手紙を、偽字で占められていない場所に緊急に「押し」入れなければなりませんでした。誰も標準を受け入れなかった（正確には、それらのいくつかがあったため、誰も注意を払わなかった）のは面白いことです。 Windowsの場合、明確です-疑似グラフィックは必要ありません。しかし、ISO 8859-5は原則とは無関係にすべてを行うことはできなかったようです（ただし、CP 1251とCP 878（KOI8-R）は両方ともIBM標準に基づいているとA. Chernovは主張していますが、Microsoftはそれとは無関係です）。 CP-コードページ、つまりコードページ）。いずれにせよ、「ロシア語」のWindowsでは、今日最も一般的なエンコーディングWindows 1251（CP 1251）が採用されました。

マッキントッシュコンピューターのユーザーも忘れないでください。彼らは休日のために特別なエンコーディングを作成しました。そのため、彼らの生活は蜂蜜のように見えず、「ネイティブ」ソフトウェアのみを使用します。 ISO 8859-5は、気分を害さないように、コアを呼び出し始めましたが、とにかくそれを使用する人はほとんどいません。

次に、ロシアのプログラマーが彼の企業のために情報システムを作成していると想像してください。彼には適切なコード表とそれをサポートするプログラムが必要です。プログラムが「強い」アメリカ人である（8ビット目を処理しない）場合、プログラムを変更するか、独自に書き込みます。最終的に、問題は解決されます。

通信プログラムでは状況はより複雑です。電子メールはさまざまな方法で、時には予測不可能な方法で送られます。そして、「邪悪な」アメリカのマシンは8ビット目を「カット」（ゼロ）できます。現在、そのようなマシンはほとんどありません（私はすぐにCompuServeのような「モンスター」を指さされましたが）、いずれにしても、それらは輸送中の中間物ではありません。

ただし、インターネットがロシアで最初に登場したとき（90〜91年）、この可能性は仮説からはほど遠いものの、非常に現実的でした。そのため、7ビット端末がまだ生きていた80年代半ばに使用された次のエンコーディングであるKOI8-Rは、新しいネットワークアプリケーションで非常によく表れています。そのため、Microsoft Windowsユーザー（顧客の90％以上）の大規模な流入であっても、それを解消することはできません。誰が勝ちますか、そして誰かが勝つなら、我々は見るでしょう。問題はそれ自体で（そして、おそらく、現在の形の構造と一緒に）死ぬと思いますが、これにはあらゆる理由があります。その間、「暴力的な協力」が盛んになりました。

キャラクターテーブルKOI8-R

ロシア語で書かれたメールを電子メールで送信し、「邪悪な」アメリカのサーバーに走ったことを想像してください（近隣の家の間でアメリカを通る手紙が時々あります-プロバイダーは同意しません）。そのような「割礼」の後、ロシア語であったこれらの文字はラテン語になります。表の数が正確に128未満であるもの。アルファベットのかなりの数の文字には、対応するラテン語の発音があります。たとえば、PとR、PとR。さらに、いくつかの一致するスペルがあります。したがって、ロシア語の文字は、同様のラテン文字とは128異なるように配置することをお勧めします。次に、8番目のビットが失われると、メッセージは特定の音訳（1つのラテンアルファベットで構成される）に変換されますが、その意味はロシア語で復元および読み取ることができます。不快だが理解できる。

KOI8-R（情報交換コード、8ビット）-これはそのようなテーブルです。そして、ロシアでのメールやニュースの交換に使用されるのは最初からです。最初の文字は、「hello」が「zdrawstwuj」のように見えるのと同じ音声表記である「ruglish」という言語で送られました。しかし、すべての手紙が読まれました！そして何をすべきか-mnogie do sih por tak pishut。しかし、今日、これは他の理由によるものです。

したがって、KOI8-Rは現在、事実上のネットワークエンコーディングです。なんで？上記の考慮事項はすでに無視されている可能性があります。今日、一部の支持者は、1993年7月にAndrei Chernovによって提案された「標準」を意味するRFC 1489のエンコーディング記述を参照しています。それで何？他のRFCもISO 8859-5を提供しています（たとえば、RFC 1700）。とにかく、RFCはインターネット上の他のすべてと同様に推奨事項です。また、推奨事項が生活と一貫しておらず、絶対的な大多数のユーザーに不便をもたらす場合、他のより便利な推奨事項を受け入れるべきではありませんか？

ほとんどのユーザーの観点から、議論の余地のないリーダーはWindows 1251です。これに対する唯一の「深刻な」議論は（伝統を除いて）D.マルティノフによって表現されました。（char）（getchar（））==-1をエラーの兆候とみなすCプログラムが、この文字で不適切に動作する理由。しかし、同じ「b」を持つKOI8-Rも不良であり、「死んだ」ISO 8859-5のみが適しています。

, «» KOI8-R , . «», , , . «» ( ), . , KOI8-R - ( ). : . «» , , — . . -«» ( ) .

, - , — ! , IP- ( ), . . : « , , ». , , , .

, Windows- , «» , « ».

単一のエンコーディングの候補はありますか？はい、法律への彼の参入は、まったく異なる理由であるにもかかわらず、長く待つ必要はなかったようです...

	00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F
80
90
A0
B0				よ
C0	y	でも	b	c	d	e	f	g	x	そして	番目	に	l	m	n	について
D0	n	私は	p	と	t	で	まあ	で	b	s	s	w	あの	あなたは	h	b
E0	ゆう	A	B	Ts	D	E	F	G	X	そして	Th	に	L	M	N	ああ
F0	P	私は	P	と	T	で	F	で	B	S	3	W	E	うん	H	B
キャラクターテーブルKOI8-R

そして、中国人はさらに難しい...

( , - ) 50 . / , , , . 32 . , , , . 50- , 1850 , . , , , «» . 1850 Unicode . , .

-
(«Popular Science» №8, 1996. « » №1, 1997.)

. 102 , 13 . «» 5 .

, , (, 50- , ). . . , .

, , .

«» , 5 10 . , , . «» () .

. 10- , . - , , . 2,7 . « » 24 , , .

Unicode

Unicode? Unicode, , Taligent, Microsoft, Xerox, NeXT Computer, Sybase, . Unix, NeXT, Windows NT, Windows 95 . , ISO 8859-1,2,3,4,5… ( ), , , , charset: koi8-r. , , , . , Unicode, — , ( , Unicode ). « », . Unicode , . , ( , «» , «» , , a Unicode ). , Unicode Java — .

, BrowserWatch .
		( )
Windows	19959	52,3
Macintosh	9460	24.7
OS/2	3567	9,34
Unknown	2004	5,25
Unix	1708	4,47
Amiga	1265	3,31
セガサターン	131	0,34
WebTV	52	0,13
NeXT	10	0,02
VM/CMS	6	0,01

...

.

— , ?

— .

— ?

— , .

, , - ( ). , . , , Windows 95, , , , , . . , , , , « ». , , , . , . , , , . , , « » .

そのため、キリル文字を表すいくつかのエンコーディングがあります。それらはすべて客観的に存在し、すべて使用されます。プロバイダーは、インターネット上にロシアのネットワークエンコーディングを1つ用意したいと考えています。歴史的にメールとニュースの両方がKOI8-Rに送られてきたため、彼らは何も変更したくなく、これを他のリソース（WWWを含む）に拡張する準備ができています。ユーザーは、ロシア語で情報を交換するために、プログラムを調整したり、調整したりする必要はありません。概して、後者は正しいです。ネットワークで動作するプログラムを再構成することにより、非常に高価な価格を支払わなければならない場合があります（そして、それらはますます増えています）。さらに、顧客はこれを、このネットワークへのアクセスを提供する人々の仕事であると正しく考えています。もちろん、時間が経つにつれて、すべてが確立され、誰もがプロバイダーを見つけるでしょう。クライアントは常に正しいです！

何も修正したくない人のために、既製のソリューションがあり、多くのプロバイダーが独自のプログラムを提供しています（常に最高とは言えませんが）。たとえば、DOSの場合、UUPCと呼ばれるパッケージがあります（A. ChernovのDOS修正版-UUPC / @）。 DOSでのみインストールし、使用することができます。Chernov氏はときどき「記憶」します。しかし、彼は、国際標準に準拠し、ロシアのシェアについて考えるために、代わりに来るエンコーディングKOI8-Rで送信される通信を変換します。あなたはそれについて考える必要はありません。厳密に言えば、UUPCプログラムで使用されるUUCPプロトコルはインターネットプロトコルには適用されず、絶望的に古くなっています。メールが宛先に届くようにするには、プロバイダーのサーバーで行われるインターネット形式に変換する必要があります（もちろん、UUCPをサポートしていない場合）。

UUPC — , «» DOS, /. , , UUPC — , .

- — Windows Microsoft Internet Mail & News. , KOI8-R, / 1251 charset ( — ). , , «» . MIME- (Multipurpose Internet Mail Extensions), — , Base64 Quoted printable. .

Internet Explorer, Internet Mail, , HTML-. , , «» Microsoft KOI8-R, «» , Explorer, «», Netscape; Windows 95 , , , .

. , Internet Mail : , . / . .

Microsoft Mail & News ( !), . — ( Netscape), ( ). , ( ), … ! , . , ( Netscape Communicator 4.0, , Microsoft, - ).

したがって、私はリリースの瞬間から今日までNetscapeプログラムを扱ってきましたが、Windows 95ユーザーにはMicrosoft Mail＆Newsをお勧めします。はい。InternetExplorerはさらに良くなっています。そして、それが機能することに加えて...

最終的に同意するのはいつですか？
-RTUCHEF。 LBL DEMB？

-Da normal'no、au tebja？

会話から

こんにちは、親愛なるユーザー！グローバルインターネットの紹介。ここには、必要なものがすべて揃っています。インターネットの使用はこれまで以上に簡単です。インターネットサービスプロバイダーから受け取ったプログラムをインストールし、ブラウザー（別名ブラウザー、別名ウォッチマン、別名移動）を起動し、プロバイダーを呼び出してサーバーにアクセスします。サーバーの内容を調べると、別のサーバーにあるジョークのページ（ www.kulichki.com/anekdotなど）へのハイパーリンクが見つかります。「ああ！ジョーク！」-あなたは考えて、喜びを期待して、クリックして別のサーバーに移動します。ジョークのあるページがモニターにゆっくり表示されます。すみません...しかし、ジョークはどこにありますか？これらは冗談ではありません。これは、ギリシャ語またはその他のバッジのセットです。おそらく、サーバー上で何らかのエラーが発生しています。サプライヤに戻り、政治ニュースページへのリンクを見つけます。「さて、チュバイはどうですか？」-あなたは、ニュースをダウンロードすると思います。その後、Chubaisは今後英語の混合語を話し、ロシア語のアルファベットの大文字で構成される他の言語が不明であることがわかります。なぜサーバー上のサプライヤーはすべてロシア語であるのに、残りはそうではないのですか？..

ローマ・ヴォロネジ

困難な愛好家のために

病気であろうと健康であろうと、体のあらゆる変化は宇宙の物質の動きに帰着します...しかし、悪魔はこの動きをすることはできません。 このことから、悪魔は少なくとも実際の身体的変化を行うことができず、これにより、そのような変換は何らかの秘密の理由に起因しなければならないことは明らかです。

魔女のハンマー

送信された電子メールを処理するにはいくつかの方法があり（ニュースにも同様の考慮事項が適用されます）、したがって、メッセージを絶望的に台無しにする機会があります。これらの方法は、当然のことながら、メールの編成方法に従っています。ユーザーはメールプログラムとやり取りすることで、手紙の送受信、保管の整理、アドレス帳の保持などを行うことができます。メールプログラムの主な機能は、便利なユーザーインターフェイスを提供することです。手紙を送受信するために、メールプログラムはメールサーバーにアクセスします。メールサーバーにはユーザーインターフェイスはありませんが、複雑なルーティング通信を所有しています。次に、直接または中間マシンを介して、受信者にサービスを提供する別のメールサーバーにレターが転送されます。彼は手紙を個人のメールボックスに入れ、そこから受信者のメールプログラムがそれを受け取ります。

文字をトランスコードするとします。「確立された伝統」によれば、メールプログラムとサーバーの両方がこれを行うことができます。私はすでに最初のオプションの好みを示しており、既存の慣行を考慮すると、そのような解決策による損害は最小限です。

配達員による記録

食べませんが、みんなに噛み付きます...

インターネットサービスプロバイダーは、長年にわたって、メールマシンソフトウェア自体がメールをトランスコードする方がはるかに良いという「意見」を持っています。次に、ユーザーが行う必要があるのは、8ビット文字の暗号化を無効にすることだけです（そうしないと、明らかな理由により、誰も後で何も回復できなくなります）。私はこのアプローチの積極的な反対者であり、多くのプロバイダーでさえ一時的な措置であると考えていることを再度強調します。

サーバーでのメールの送信/配信には2つのプログラムが関係しています。最初はメールの送信に使用され、「SMTPサーバー」と呼ばれます。 SMTP（簡易メール転送プロトコル）は、インターネットメール転送プロトコルです。 SMTPサービスは、メールをメールマシンに保存することによっても受け入れます。ユーザーに直接、彼自身のイニシアチブで、別のプログラム「POP3 Server」（郵便局プロトコル）によって手紙が送られます。

その後、すべてが明らかです。SMTPサーバーは、送信者のエンコードからネットワークエンコードに文字を変換するように「強制」されます（現在はKOI8-Rです）。 POP3サーバーは、KOI8-Rの文字を受信者が受け入れたいエンコードに変換する必要があります。どれだけですか？..そしてどれから？..

変換する場所と場所

文字のエンコードに関する情報はどこから来ますか？

メッセージヘッダーのサービスフィールドから。
構成ファイルから。
各エンコーディングを操作するための専用の仮想サーバーがあります。
レターの内容に従ってエンコードを決定します。

最初のアプローチは、ユーザーの電子メールプログラムに責任を移します。彼女は電子メールのヘッダーに正しい文字セットを含める必要があります。これはドイツにとって最も正しいアプローチですが、ロシアにとってはそうではありません。間違った文字セットを使用する会議コーディネーターもいます。そして、他の全員（読み取り-契約を順守せず、単に「私のように」）がすべてであるときに、お尻を介してすべてを行う（読み取り-標準を順守する）あまりにもスマートなソフトウェアを非難しますいいよプログラムと標準の一般的な無責任と普遍的な「欺ception」を考えると、そのような決定は悲しい結果につながります。

2番目のアプローチはプリミティブです。メールマシンの管理者は、このようなネットワーク名またはアドレスを持つクライアントマシンがWindows 1251などのエンコーディングで機能すると判断します。このマシンから送信されるすべての通信は、このエンコーディングでのみ提示されると見なされます。

マシンに通常のように永続的なアドレスがなく、プロバイダーに接続しているユーザーが各セッションで動的IPアドレスを受信しても、メールサーバーとメールボックスにアクセスする場合、このソリューションは機能しません。このマシンから他に何も送信できないという事実についても話していません。

専用の仮想サーバー。たとえば、エンコードごとに1つずつ、1台のメールマシンで3つまたは4つのメールサーバーを実行し、各サーバーに別々の名前を割り当てましょう。

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などでメールを申請することをお勧めします。クライアントがメールプログラムを設定するときにメールマシンのアドレスを正しく指定するだけで十分です。この場合、送信SMTPストリームと受信POP3を異なるエンコーディングに分割することにより、柔軟性をさらに高めることができます。上記のように、NetscapeがWindows 1251を強制的にKOI8-Rに変換しますが、逆のプロセスは実行しないとします。次に、その中にSMTPを定義します-KOI、およびPOP3-Win、したがって、発信通信はNetscapeによってトランスコードされ、着信はサーバーによってトランスコードされます。エキゾチックな目的地で他のチェーンを試すことができます-多くのオプションがあります。私の意見では、これが最も正しい解決策です（何かする必要がある場合）。とにかく、ユーザーはサーバー名を書き留める必要があり、前の場合のようにそれをそれほど愚かで自由とは考えないでください。そして、デフォルトのオプションをいつでも予約することができます。デフォルトのオプションは何もせず、単に転送するだけです。私はそのようなプロバイダーを持っています。彼は私のものだから私は彼を称賛しませんが、彼はそうしているので彼は私のものです。

私は、見かけの誘惑すべてに対してエンコーディングを自動的に検出するという考えが好きではありませんでした。認識技術によって、どのエンコードでテキストが提示されているか、さらには識字能力を備えているかどうかを判断することは疑わしいです。もちろん、そのようなプログラムは、ロシア語とアブラカダブラを区別することを学ぶだけで十分です。そして、私がタタール語で書くことに決めたなら！さらに、一部のプロバイダーは、認識できない文字を宛先に送信してはならないという意見を持っています！さて、その後それらを何と呼びますか？くだらないものを郵送することは、ユーザーの憲法上の権利です。

いずれにせよ、今日の普遍的なソリューションは存在しません。すべてを予見しようとしても。 Grigory Naumovetsによる会議の例から：「最近、キリル文字で1つのメッセージをメーリングリストを通じて、異なるサーバー（KOI8 <-> 1251をトランスコードする）とメーラー（EudorからBmail）の数十人に送信する必要がありました）フォントやエンコードを切り替えることなく、キリル文字がすべての人にすぐに見えるようにする必要があると思います。したがって、私は手紙に4つの部分を含めます：（1）英語、（2）KOI8、（3）1251、および（4）KOI8-> 1251テーブルに従ってPOPサーバーまたは受信者ソフトウェアによるトランスコーディングの場合にKOI8に変換する必要があるもの。え？とにかく、Dmailの受信者の1人から返事が来ました。「開始文字列がないので、手紙を読むことができません」（???）。道路上の1台のサーバーが私よりもスマートであることが判明し、何らかの理由でBase64で私の手紙をまとめました」。

ワールドワイドウェブ

World Wide Webは、独自の法律に従って生活しています。 HTMLレイアウトの問題は、長い間専門家を悩ませてきました。この問題を克服する試みの中には、同様に、「ロシア」の問題を解決するものもあります。

今日は何がありますか？エンコーディングに関する状況の愚かさはここで明白です-各サイトの岐路にある古典的なロシアの石：「エンコーディングを選択してください」。これは完全に異常な状況です。コンテンツを複製（3倍および4倍）する必要があり、エラーやミスの可能性が高くなります。この決定により、回答よりも多くの質問が発生します。たとえば、フォームに記入する（インタラクティブなアンケート）またはサーバーで解析されるHTML（マクロ置換を使用）などで何をしますか？

最新の代替ソリューションのうち、2つを挙げることができます。

選択したCGIスクリプト（つまり、サーバーで実行されているプログラム）を使用して、ベースページを「オンザフライ」で再コーディングします。
要求に応じて必要なエンコードの自動検出。

一般に、単純な複製よりも便利ですが、満足のいくものはありません。最初の罪は、使用に多少の不便さとアクセス時間の増加を伴います。 2番目は常に実行可能であるとは限りません。ローカルブラウザーがサーバーに自身に関する情報を送信するという事実に基づいているためです。プラットフォーム/オペレーティングシステムの種類を含むこともありますが、これは常に正しいとは限らず、ユーザーが正しいエンコーディングでフォントを持っていることを保証するものではありません。

電子メールのみで作業するユーザーの数は着実に減少し、オンラインユーザーの数は絶えず増加することを考慮する必要があります。そして、そのようなユーザーには、追加のサービス、そしてもちろん、最高の表示品質と多様なサービスが必要になります。ロシアのネットワークの現在のユーザーは主にプログラマーであり（一部の調査では約4分の3）、ご存知のように気取らず、汚く、怠zyでずさんです。人道主義者（ポリグラフ作成者、アーティスト、デザイナーを含む）がウェブにアクセスするまで、これ以上の変更はありません。

したがって、私たちはいつものように、これがすでに起こっている西部（そして大部分は「野生」、つまりアメリカ人）に焦点を合わせます（そしていくつかのトレンドによると、私たちはすぐそこにいます）。このようなユーザーに8ビット目の「割礼」について説明することはほとんどできませんが、すぐにずさんな組版、エラー、「曲がった」フォントに気付くでしょう。出口はどこですか？

これまでに次の2つがあります。

PDF形式でのWebページのレイアウトと保存（Adobe Acrobat）。
ドキュメントおよびCSS HTML拡張機能とともに送信されるWebフォントの使用。

PDF形式については特に広めませんが、私の観点からはこれが最良のソリューションです（エンコードと言語、プラットフォームとオペレーティングシステムに依存しません）。残念ながら、Adobeはインターネットの波を無視し、Acrobatファイルは多くのWebブラウザーでサポートされていますが（通常、対応するプラグインがあります）、標準にはなりません。

CSS拡張機能は、プログラミング言語と開発ツールの開発の古代段階に似ています（インターネット全体と同様に、その技術のすべての新規性により、一部または別の部分で常に古風なものに似ています）。希望する人はW3でそれらに慣れることができますが、それは一時的な措置（または「まだ」）のように思えました。

ロシアの異教を警戒するウェブフォント

それで、人文科学はインターネットに来ました。 HTMLドキュメントは、単純な<HR>および3Dボタンから、プログラマーではない訪問者を引き付けて保持することを目的とした、専門的で適切に設計されたページに進化します。プリンターの観点から、Webページを開発するための現在のツールの最も重要な欠点の1つは、フォントをハードインストールする機能がないことでした。その結果、デザイナーは、クライアントが画面上で意図したとおりに表示されることを確認できません。

フォントの正確さと品質を保証する最良のソリューションは、今日、それらをWebドキュメントに直接埋め込み、ユーザーに転送すること（通常は表示のみ）と見なされています。 TrueTypeとPostScriptの両方の主要なフォントを使用することが提案されています。適切なヒントを使用して、TrueTypeフォントは画面上により良い画像を提供し、PostScriptフォントは出版の業界標準として高品質の印刷を提供します。

埋め込みフォントの使用は、HTMLファイルのサイズの増加と、結果として、適切な再生品質を維持しながらの転送時間によってのみ制限されます。

最近まで、HTMLで特定のフォントを指定することは事実上不可能でした。デザイナーはフォントを選択し、Webページの定義に含めました。マシンにそのようなフォントを持たないユーザーは、ブラウザを自動的に（デフォルトで）置き換えるフォントを見ました（ロシアの場合、ブラウザはロシアの手紙）。ユーザー自身でさえ、ブラウザに埋め込まれたデフォルトを常に変更できるとは限らず、結果は設計からさらに遠ざかりました（もしあったとしても）。もちろん、多くはテキストのグラフィカルな表現を使用していましたが、これはかなりかさばるファイルにつながり、テキストブラウザー（たとえばLynxなど）でも読み取られませんでした。ドキュメントにフォントを埋め込むと、これらの問題は修正されます。ユーザーは、コンピューターにインストールされていなくても、デザイン中に配置されたフォントを正確に見ることができます。主要なブラウザメーカーは、埋め込みフォントのソフトウェアサポートを発表しました。

埋め込みフォントのもう1つの利点は、表示および印刷時の品質の達成です（これは、画面から読みにくい大きな文書に特に当てはまります）。フォントをドキュメントと一緒に送信すると、文字や文字に関するすべての情報が追加されます。これには、作成者が表示や印刷の品質を改善するために使用するヒントやその他のフォントツールが含まれます。さらに、ドキュメントで使用された文字（フォントのサブセット）のみを転送することが計画されており、さらに節約できます。

圧縮を追加することで、転送されるファイルのサイズをさらに小さくすることができます（圧縮と、可能であればロスレス）。また、コミュニケーションの問題を理解していないクリエイティブな人々がWeb上の出版物の準備に参加するにつれて、ファイルサイズは常に大きくなります。

フォントのサブセットを使用するには、ドキュメントが作成されたアプリケーションがこのメソッドをサポートしている必要があります。 Microsoft Office 97にはこの機能があり、ドキュメントにフォントを埋め込み、ドキュメントのフォントを確認し、暗号化されたバージョンのフォントをドキュメントに関連付けることができます。一部のフォントはドキュメントへの埋め込みを許可せず、指定された機能はそれらに適用されません。法的に埋め込まれたフォントを含むそのようなドキュメントが意図したとおりに到着すると、それらは解読されます。

少し前に、インターネット上にホームページを作成しました。 www.online.ru/people/ashipのアドレス。その直後、私はかなり驚いたことに、このページについての印象を持った海外からの手紙をかなり受け取り始めました。非常に素晴らしいことは、すべての手紙がロシア語で書かれていたことです（時には不器用になることもありますが）。そして、それはすべて、たった1つの質問を含んでいた。「エンコーディングでどんな種類の跳躍をアレンジしましたか？！」そのような手紙のサンプルを提供します。数十の記事よりも雄弁です。
  Ya v AustraliY ottuda tebe privet！
 prejnyaya stranichka tchitalasy cherez KOI8。
 chto mne s novoy sdelaty？  okolo 40 statey
 po russkim fontam prochel ........ Pochemu ne
 dogovoritesy pabotaty s odnoy kodirovkoy。 薬、
私のvse jelaem chitaty smotrety vashy sayty。 
アンドレイ・シピロフ

フォント圧縮ツールは、品質を損なうことなく圧縮を提供するAgfa MicroType ExpressおよびAdobe CFFテクノロジーに基づいています。 MicroType ExpressはTrueTypeおよびPostScriptフォントで動作し、CFFはPostScriptフォントでのみ動作します。 Agfaによる圧縮は、元の情報を完全に保持し、フォントのサブセットを転送する方法と組み合わせて、ラテングラフィックスに基づくフォントの90％圧縮を提供し、中国語、韓国語、および「us」のような場合は最大99％圧縮します。画像やフィルムの保存に使用される非可逆圧縮方法とは異なり、MicroType Expressテクノロジーは元の文字とインターネット上の外観との完全な対応を維持し、その場での解凍をサポートします。さらに、すべてのヒントが保存されるため、高品質の表示と印刷が保証されます。 Microsoft Internet Explorerは、これらのテクノロジーのサポートに取り組んでいます。

オープンツアー

マイクロソフトとアドビは、TrueTypeとPostScriptを組み合わせたOpen Tourと呼ばれる新しいユニバーサルフォント形式で協力しています。作成されている技術の一部はフォント圧縮です。Open Tourでは、既存のフォントの管理が改善され、Web用に設計された新世代のコンピューターフォントで機能するフォーマットが作成されます。この作業の大部分は、フォントのクロスライセンスと、両方の形式が異なるプラットフォームで動作することを保証する技術に専念しています。 Open Tour形式では、ドキュメントにTrueTypeフォントまたはPostScriptフォントを埋め込むことができ、デザイナーやユーザーがWebページをインストールして使用するための簡単な手順を実行できます。 Microsoftは、Open Tourフォントをコアオペレーティングシステムの標準要素にする意向を発表しました。アドビは、グラフィック、パブリッシング、およびインターネットアプリケーション向けのソフトウェア製品の新しいバージョンでOpen Tourをサポートする予定です。

Open « » « ». , Agfa, Adobe Microsoft WWW , , HTML- . , , Web- , , «», .

HTML- «» . , : — , « » !

www.medlux.ru .

www.medlux.ru , ( ), .

( Web- .)

39030 Win95
27094 Windows (.)
10321 Win 16
2903 WinNT
1440 Win32
1254 Freebsd
1181 SunOS
863 Unknown (Lynx)
595 Macintosh
583 OS/2
540 Linux
192 Mac PowerPC
156 HP-UX
132 AIX
97 BSD/386
80 OSF1
34 AlphaServer
28 BSD/OS
16 OpenVMS
14 IRIX64
7 Alpha
6 WebTV
:

MS — 93,3%, Unix — 5,1%, Mac — 0,9%, OS/2 — 0,7%

« »,

主要なソフトウェア開発者は、WWWツールとマルチメディアの分野に力を注いでおり、近い将来この分野で何を期待するかを明確に示しています。

しかし、継続的な「ブラウザ戦争」の結果として、損失は主に消費者が負担します。コンピューターのパフォーマンスに対する要件は増加しており（主にメモリ）、プログラムはより複雑になり、新しい機器が登場しています。これらの資金はすべて、主にテクノエリートを対象としています。したがって、膨大な数の潜在的なユーザーが失われます。また、ネットワークの現在の顧客は、アピールごとに「大量の石炭」を処理する必要があるため、誰もがアクセスできない神話上の「ダイヤモンド」を取得できます。

一方、Webテレビ端末（WebTV）は、VCRや留守番電話と同じくらい簡単です。従来のコントロールパネルでは、1つのボタンだけが追加されます-WEB。ロシアですでに存在を発見していなければ、WebTVコンソールについては言及しません。

Web- ( ). , . : Web- , , , .

おそらく近い将来、WebTVは主にテキスト情報、会議（たとえば、メロドラマなど）、単一の画像、および遅延視聴を伴うビデオの断片の送信に使用されるでしょう。

今日の世界中でのWebTVの使用は、いくつかのアプリケーションに限定されています：オンデマンドニュース（天気やスポーツの結果を含む）、映画、放送、テレビ番組の視聴、および商業注文。成功は、おそらく視聴者がそのような情報を受信するのがどれだけ簡単で、インターネットリソースにアクセスするのがどれだけ便利かによって異なります。追加の機器の価格が高すぎなければ（現在はデバイスあたり約300〜400ドル）、ほとんどの人はコンピューターの代わりにテレビを使用して喜んでいるでしょう。電子メールは、近い将来にWebTVを大衆市場にもたらす主な機会です。

, WebTV — , «» , , . .

, , KOI8-R?

「ロシア語のインターネット」（コンピューター、1997年3月）