目次
2019-11-19 遊びプログラム
2019-11-18 自宅電話回線その後
2019-11-17 イベント終わりました
2019-11-14 しばらく日記書いてなかった
2019-10-31 月白青船山
2019-10-28 自宅電話回線
2019-10-23 メールの１行が78文字の理由
今月の日記
今日は一日仕事があいてしまったので、遊びプログラム。
まだ完成していないし、明日からは普通に仕事に戻るので、完成するかもわからない。
Twitter をエゴサーチしているが、ファミコンの画面についてのページを引用してくださった人がいた。
ファミコンでは 52色表示可能、という、表示できる色の一覧だな。
どうやら、その人は「ファミコンの表示」に興味があり、適当な画像をそれっぽくするフィルタを作っていたらしい。
Twitter のログを追って分かったことには、最初は「適当な54色」に減色してみたものの、どうも「それっぽい」画面にならないので、情報を探して僕のページを見つけたようだった。
どうも、当初は RGB 空間を適当に区切って 54色にしたようだ。
しかし、どこかで「RGB ではなく、NTSC の Y/C 空間で考えないといけないようだ」と、情報を探して僕のページに辿り着く。
そして、そこで
・既定の 52色
・16ドット以内で使えるのは、背景色含めて４色だけ
・その４色の組み合わせは、全画面内で４セットだけ
という厳しい条件を知り、「なんだかわからない」とツイートして終わっている。
さて、僕も以前から、ファミコン風画面フィルタは作ってみたかった。
ちょうどよい機会だから、「厳密にはしない」つもりで作ってみる。
とりあえず、52色減色から。
RGB を HSV に変換してからファミコンパレットに適用してみようと思ったのだけど、難しい。
H 信号を参考にして、「パレットの近いあたり」までは見つけられるとわかったので、その周辺を総当たりで「近い色」を探すようにしてみる。
とりあえず、ファミコン 52色への減色はこれでできた。
ディザをかけたりしないので、最適な画像変換ではないけれど。
つぎに、52色自由に使ってはならない、という制限をかけてみる。
使われる色を集計し、上位 12色しか使ってはならない、としてみたら、まだまだ綺麗な絵が出る。
では、６色まで落としてみよう。
というのも、グラディウス２のデモ画面で、ビッグバイパーの絵が６色で書かれているからだ。
…いい具合に「色合いが不自由」な感じが出て、ファミコンらしくなった。
つづいて、「16ドット以内に４色」という制限を作ってみる。
４色のうち１色は「背景色」なので、一番使われている色を背景色にすることにして、それ以外の色で 16ドット以内で使用頻度を集計する。
これで、上位３色＋背景色で描けば、それらしくなる。
…案外、きれいな絵が出てしまう。
いろんな絵で試すと、多少不自然なところも現れるが、この条件だけではまだ「ファミコンらしさ」が出ないようだ。
やっぱり、「全画面で３色セットを４つまで」の制限も入れないといけないだろうか。
ファミコン画面は 256x224 （縦方向は VRAM は 240 ドット分あるが、表示は 224ドット程度とすることが多い）として、16x16 ドットのタイルで区切ると、16x14 タイルになる。
それぞれを、背景色を除いた３色に減色したうえで、同じ色の組み合わせになった数を集計する。
そして、使われた数が「少ない」パレットを、使われた数の「多い」パレットに吸収する。
吸収する際は、３色のうち少なくとも２色が同じパレットに吸収することにした。
この際、使用された数もちゃんと吸収させる。
できる限り吸収を繰り返したうえで、改めて集計された使用数の順に並べ治す。
最終的に、上から４つのパレットを採用する。
そして、このパレットを使って画面を描くと…うん。いい感じに四角く色が化ける。
ファミコン時代にはよくあったよね。無理やり感のある絵。
しかし、四角い不自然さはあっても、まだファミコンにしてはきれいすぎるのだ。
それは、画面全体で、色以外は自由に絵を描けてしまっているから。
ファミコンは、8x8 ドットのキャラクターを並べて絵を作る。
このキャラクターは 256種類しか定義できないのに、画面全体は 896マスある。
だから、自由に絵を描くことはできないのだ。
色だけをファミコン風に変換しても、キャラクターの不自由さで違和感がある。
本当は、「似た部品」を探し出して、無理やり共通化することで不自然さを出していけばよいのだけど、そこまでやるのは結構面倒だ。
そこで、せめて「四角い塗りつぶし」を増やすことにする。
8x8 ドットの範囲内、64ドットのうち、52ドット以上同じ色だった場合には、思い切って 8x8 を塗りつぶしてしまう。
52ドットに根拠はない。色々試して、それくらいがなんとなくいい感じだった、というだけだ。
塗りつぶし部分は、絵としては「使いまわし」になるので、絵が自由に描けない不自由な雰囲気が出る。
とはいっても、これでも絵がある部分が 256マスには収まらないのだけど…
かなり塗りつぶしが多い絵でも、256以上のキャラクタを定義したことになってしまう。
まぁ、遊びプログラムなので、本日はここまで。
あまり満足いく結果が得られていないので、公開するにはまだ早いかな…
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先月末に、電話回線契約のトラブル（？）の話を書いた。
簡単にまとめると以下のような話だ。
まず、ＮＴＴひかり電話を、アサヒネット光電話に変更する契約を８月末にした。
ところが契約内容の確認書類と、工事日以降サービスが若干変化する（サービス会社が変わるから）という案内が来ただけで、工事日の案内が来ない。
どこかで変更されたか確認しないとな…と思っていたら、１０月末になってアサヒネットからセールス電話がかかってきた。
ＮＴＴひかり電話を利用中の方に、アサヒネット光電話に変えませんか、というセールスだった。
すでに使ってます、と言ったら、システム情報を見て使っていないし、案内書類などを発行した形跡もない、というので、再契約した…
というもの。
その後、ふたたび契約内容などの案内の書類が届いた。以前もらったのと同じものだ。
しかし、次の書類が来ない。
以前は、契約内容の後に「工事日以降サービスが若干変化します」という２通目の書類が来たのだ。
肝心の工事日は書いてなかったのだけど。
なんだか、嫌な予感がする。
再契約の際、最速で１１月頭には切り替えられる、と言っていた。
先ほど、心配なのでアサヒネットのページを見に行き、契約内容を確認した。
９月８日から、光電話を使っていることになっていた。
…つまり、再契約のセールスの際に「使ってることになってない」と言っていたのが間違いで、ちゃんと最初の契約で利用開始できていたのだ。
再契約二通目の「工事のお知らせ」が来なかったのは、工事をしようにも、すでに工事すべきＮＴＴ回線がなかったからなのだろう。
そんなわけで、前回「大丈夫かよ。アサヒネット」と書いていたのだけど、大丈夫だった。
いや、使っているのにセールス電話かけてきて、契約した形跡もない、とか言っていたのだから大丈夫じゃないか。
ちなみに、２回目のセールスは「工事費用なども無料です」というキャンペーンだったので、追加で金をとられたりすることもない（はず）。
おまけ：
話は以上で終わりで、この下はアサヒネットを使っている人は読まない方がいい。不安になるから。
知り合いに、アサヒネットに詳しい人がいる。
以前からアサヒネットのサービスを多数利用していて、今もサーバーホスティングサービスを受けているのだ。
その人が、１年くらい前から「アサヒネットの技術力低下がシャレにならない」と言っていた。
たびたびサーバーが停止したり、回線トラブルでアクセス不能になったりする。
数分以内に復旧するのだけど、その知人は「アクセス不能」で、行っているサービスに大きな支障が出たことがあるという。
以前は技術力が高い会社だったのだが、どうも品質が落ちているらしい。
まぁ、アマゾンのクラウドとか、強大なライバルが出すぎてサービス維持が難しいのだろう。
その知人は、アサヒネットのサーバーに依存しないようにシステム改変作業中。
うちは回線借りているだけなので、それほど技術力低下を感じていなかったのだけど、サービスは確実に低下しているかも、と今回の件で痛感した。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日書いた日記の続き。
しばらく日記書いてなかったもので、リハビリみたいなもので、どうでもいい身辺雑記書いてます。
現在一緒に仕事をしている会社、別に名前とか出してもよいとは言われているのだけど、この日記上では名前出していない。
その仕事先の名前（商品名でもある）で検索されて、中の人だとわかるのもなんとなく嫌なので。
（僕はその会社の手伝いをしているが、社員ではない。そんな人の話が会社の意見だと思われても困る）
でも、前回リンクした記事を読めば、何の仕事かはすぐわかる。
「このページを読んだ人が知っていてもいいが、商品情報を頼りにしてここに来ないで欲しい」ということだな。
で、土曜日の夜に、東京ビッグサイト…の「壁」に、映像作品を投影するコンテストが行われた。
いわゆるプロジェクションマッピングというやつです。
応募資格は学生だったのかな。
大学生や専門学校生。プロの映像作家はダメだけど、映像の専門校生はいい。
本番は土曜日だったのだけど、金曜日の通しリハーサルに立ち会った。
一応、本番終わるまではリハーサルの話とか書いちゃまずいだろ…と思っていたので、日記に書くのは本番が済んだ今日になった。
このコンテストでは、最終審査は審査員がやったのだけど、「一般審査」として、見た人は誰でも作品の点数をつけられた。
最終的に、平均点が高いところには「観客賞」が贈られる。
（結果、審査員が付けた「最優秀賞」と、「観客賞」は同じチームだったようだ。
僕は本番ではなくリハーサルで見ただけだけど、このチームは群を抜いて出来が良かった。納得の結果だ。）
一般審査の投票システムとして、一緒に仕事をしている会社のシステムが使われた。
ビッグサイトの壁面に QR コードを表示し、そこから誘導される WEB ページで「投票」すると、リアルタイムに点数が集計されるのだ。
壁面は非常に大きいし、見た人は誰でも投票できる。会場の広場で見ている人は当然、数百メートル離れたところの人だって参加可能だ。
そういう「ゆるい」審査なのだけど、そうした集計ができるシステムは、案外少ないのだ。
そして、集計結果は…点数は、リアルタイムには表示しない。それは、最終結果の発表までのお楽しみ。
その代わり、映像について感じたことを「すごい」「楽しい」「かっこいい」の三択で選んでもらっているので、その割合を表示する。
円グラフがリアルタイムに動いているものが、ビッグサイトの壁に表示される、というだけなのだけど、この部分のシステムを僕が担当しました。
これがね…前日リハーサルまで、実際の映像が見えないので、想像で作るしかなかったの。
文字が大きくないとつぶれちゃうんじゃないか、コントラストが強くないと見えないんじゃないか…って、想像で作り上げるしかない。
直前の日記に「必要なら現地で最終調整」と書いていたのはそのため。
表示してみたら、十分にきれいで何も調整は必要ありませんでした。
一応、円グラフを動かす部分は普段から使っていたプログラム。
でも、普段は円グラフの横に「凡例表」があり、そこにアンケートの内容などが書いてあった。
（グラフの領域には、1 2 3 という数字だけがあり、横に対応表があるわけです）
でも、今回はビッグサイトの三角形の外壁に表示したので、凡例表を出すことはできなかった。
グラフ内に直接文字を入れてほしい、と言われていました。
最初の段階から、「グラフが細くなると、文字重なっちゃうと思うよ？」と言っていたのですが、実際作ってみたら予想以上に深刻でした。
先に書いたように、プロジェクションだと細かな部分がつぶれやすいので、文字をできるだけ大きくしないといけない。
当然大きい方が重なりやすいわけだけど、その状態でも「割合を示す % 部分は読めるようにしたい」という要望がありました。
もう、事前に試行錯誤の連続。幸いなのは、選択肢が３つしかなかったこと。
選択肢が３つだから、「細い領域の両隣のうち、少なくとも一方は表示面積に余裕がある」と確定しています。
そこで、表示面積が細い場合（具体的には、角度にして60度以下になった場合）は、両隣のうち、より広い方にはみ出して文字を表示してもよいことにしました。
（具体的なアルゴリズムとしては、文字は表示領域の中央に出すのだが、60度以下の場合は、広い方にはみ出して60度あるものとした中心に表示を行う）
ただ、両側とも十分に広いばあには、今度逆に「片側に文字が寄る」表示は不自然。
そこで、こうした場合は広い方に寄せる処理をしない、とか、いくつかの場合分けを行います。
これでもまだ、１つの領域が 80% とかとってしまうような極端な状況では、文字同士がぶつかることがありました。
そこで、20% 以下になった場合には、文字サイズが小さくなっていくようにします。
20% 以上なら 100% の文字サイズで、10% 以下なら 80% 。間は滑らかにつなぎます。
これで、問題のないグラフ表示になりました。
この表示、評判良かったので今後も使えるようにしたい…と、仕事先の社長から言われてます。
でも、それなら３つ以上の選択肢でも使えるようにしないと。
今は、文字の表示中心が、円グラフの中心から等距離のところにあるのだけど、本当はこれも可変にしたい。
グラフ中央から「近い」「遠い」をうまく組み合わせれば、もっと文字を表示しても読めるはず。
ただ、そうなってくると文字同士の当たり判定を入れたいのだよね。
今のグラフ表示基礎ルーチンは僕が作ったものではなく、そこまで複雑なことができる作りになっていない。
もっというと、データが決まっていて「うまく表示する」目的なら、内部的に試行錯誤して最適配置を求められるのだけど、リアルタイムに移り変わるのを違和感なく表示するのは至難の業。
まぁ、そこがゲーム的で面白そうなチャレンジだと思ってる。
（試行錯誤させてもらう時間があればね）
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
なんか日記を書かないまま半月過ぎてしまい、長い間何も書かないのも気持ち悪いので、無理やり駄文を書く。
本当に駄文。身辺記程度なので読んで得になることは何もないです。
日記を書いていた理由はいろいろあるのだが、まぁ忙しかったからだ。
今年の５月末に、以前からやっていた仕事の契約を解消した。
そして、友人が起こしたベンチャー企業の仕事をフルタイムで請け負い始めた。
しかしまぁ、その頃はまだそれほど忙しくなかった。
会社の受注状況は悪くなかったが、それは「システムを使いたい」というものであり、プログラムの緊急改変などは不要だったから。
それが、夏ごろから「料金払うからカスタマイズしてほしい」という需要が増え始め、今月は同時に２件。
今週末、２カ所で使用される別々のシステムのカスタマイズを、同時並行で進めていた。
さすがに今週頭に完成し、昨夜までにデバッグも大体終わった。
今も最終チェックが行われているが、僕の仕事は「バグ報告待ち」になっている。
そこで、こんな日記を書いているわけだ。
友人の会社は、スマホを使ってアンケートに答えてもらい、リアルタイムに集計した結果をブラウザ画面にグラフ表示する、というシステムを作っている。
僕が参加し始めたのは２年半くらい前だったと思う。
システムはすでに完成していたのだけど、足りない部分も多く、保守する人がいないから手伝って、と頼まれたのだ。
時々頼まれては作業していたが、１年半ほど前に、その時友人がいた会社が「開発中止」を決定した。
この開発中止は、会社が方針を転換したためで、売り上げが悪いとかの理由ではなかった。
そこで、彼はシステムの権利を買い取って、１年ちょっと前に会社を興したのだった。
詳しいことは、その頃に書かれた、以下のインタビューを読んでもらうといいだろう。
この事業専門の会社にしたことで、いろいろな会社と提携しやすくなった。
「しがらみ」が無くなり、開発速度が増した。
いろいろな会社と提携して、使われる範囲も増えた。
時々「開発料金は払うので、カスタマイズをお願いしたい」という仕事も来る。
友人としては、機能をカスタマイズするとプログラムが複雑になり、保守に支障があるため「カスタマイズはしない」方針をとっている。
しかし、「画面の見た目を変える」というカスタマイズは受け付けている。
このカスタマイズは主に集計表示部分に行われる。集計部分の担当は僕だ。
この手の仕事が増えたこともあり、６月からは、僕もフルタイムで参加するようになった。
今週の末に、２カ所のイベントでカスタマイズしたシステムが使われる。
この２カ所は別々のイベントで、カスタマイズ内容も別だ。
こうしたイベントは、最終仕様が決まるのがぎりぎりになることが多い。
今月に入ってから２つのカスタマイズ内容が決まり、２週間で同時に２つを開発してきた、という状態。
これが、日記を書けなかった主な理由だ。
昨日までにテストしてバグはほぼなくなったことを確認し、今日は余裕があるので日記を書いた。
明日は実際の会場で最終テスト。
より大きなカスタマイズをした方は、現場でテストに立ち会う予定。（必要なら現地で最終調整を行う）
明後日は本番だけど、これは見に行かない。
本番では、もうプログラマの出番はないから。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
久しぶりの書評。
以前同じ人の作品を読み、面白くてそれも書評として書いたのね。
普通に本を読んでも書評を書こうとは思わないのだけど、以前の本は…こう、なんというか、本を読みながら本の「外」を思ってしまう、不思議な構成だったから。
以前読んだのは、「かはたれ」「たそかれ」という、２冊のシリーズ作。
不思議な構成と書いたけど、誰でも読んで不思議を感じられるわけではない。
舞台が架空の町なのだけど、明らかに僕が住んでいる町。
そして、登場する場所がいちいち、知っている場所。知っているのだけど、そこは架空なので微妙に違っていたりして、眩暈を感じられた。
そして、今回読んだ「月白青船山」。
先に書いた「かはたれ」シリーズの舞台は、「散在が池」と「青船」だった。
池は、少し名前が違うが実際に「鎌倉湖」としても知られる場所で、鎌倉湖行きのバスは JR「大船」駅から出ている。
つまり、架空の地名「青船」は、大船だ。
そして、「青船山」を舞台にした新作（今年刊行の本だった）。
読んでみたいと思った。
先に、ざっくりとストーリーを紹介しよう。
東京に住む兄弟が、夏休みの間だけ、親戚の家に預けられて鎌倉へやってくる。
本当は海外出張中のお父さんを訪ねて家族でオーストラリアに行くはずだったのに、お父さんが病気になり、母だけが向かったのだ。
楽しいはずの夏が、友達もいない、それほど親しくもない親戚の家で過ごすことに。
しかし小学校５年生の弟は、同学年の鎌倉在住の少女と出会う。
彼女もまた、家の都合により少し離れた学校に通っていたため、夏休みは友達と遊べない。
家庭の事情もあり、彼女も寂しい気持ちを抱えていた。
そして、中三の兄も合わせて、彼女の案内で近所にある「青船山」で遊んでいるうちに、不思議な場所に迷い込む。
平安時代末期の村だった。
そこで、３人はその村が「時間が止まった」場所であることを知る。
状況を戻し、全ての人が幸せになるためには、失われた瑠璃を探さなくてはならない。
村人は時間が止まっているがゆえにそれができず、願いが彼らに託される。
その後、彼らは現代に戻ってくるが、託された願いがそもそもどういうことなのか、意味を探り始める。
全体に、鎌倉に伝わる伝承、実際の地形などを組み合わせた、なぞ解き話だ。
小学生向けだから、その謎もそれほど難しいわけではないし、推理というよりは冒険物（行き当たりばったりで謎が解ける）だ。
「かはたれ」シリーズに比べると、架空の町、という感じは少なく、出てくる場所がほぼ実在。
お寺とか、神社とか、「伝承」に関係しそうなものはともかく、大船に実在するお菓子屋さん（粟船堂）まで出てきたのにはちょっと笑った。
そして、その分「現実との違いに眩暈を感じる」という楽しさは、残念ながら少なかった。
現実と一番違うのは、主要舞台である「青船山」かな。
位置関係や記述から、これは「六国見山」。
小学生でも簡単に登れる気軽な山、というのはそのままだけど、地形は結構違う。
…とはいえ、それなりに現実に存在するものも出てくるのだけど。
「かはたれ」「たそかれ」もそうだったのだけど、この作者は「寂しい人」を書くのが上手なようだ。
このお話も、寂しい人が多い。
そうではないように見えていても、人物像が明らかになるにつれ、どこかに陰が出てくる。
「瑠璃」を探す冒険は、次第にそれらの人の希望へとつながっていく。
願いを託したのは平安時代の人々なのだけど、それが現代に生きる人々へも希望になっていくのだ。
最後は、大団円。
実際の伝承を基にした…実在の歴史上の人物で「不幸だった」人々も含めて、幸せになったことが示唆される。
歴史はもちろん変えられないから、おそらくそれは死後の世界で幸せになったのか、現在とは違う世界線での話なのだろうけど。
先に書いたように、多数の伝承が組み合わせられて話を形作っている。
しかし、どこまでが史実・伝承で、どこまでが作者の想像による架空のものなのか、どうも判然としない。
「かはたれ」は、町自体が都合よく架空のものになっていたので、現実との違いを楽しむことができた。
しかし、「月白青船山」は町などの描写はかなり現実に近い。
事実が多いからこそ、伝承も本当っぽく見えるが、それも作者の狙いだろうか。
どうもこの作者、事実と架空を自在に操り、境界線がわからない。
非常に巧妙に作られた、良作だと感じた。
同じテーマの日記(最近の一覧)
別年同日の日記
02年 Synchronized, wait & notify
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
８月末のことだ。
僕は自分の会社を持ち、在宅でプログラマをしている。
会社にはしているが、事実上は個人営業に近い。
それで、会社の決算書類の提出が８月末で、毎年８月後半は書類作成に忙しい。
法的な書類作成は社員でもある妻が主にやってくれているのだが、僕も必要データを準備する必要がある。
そして、毎年困るのが、ＮＴＴの電話料金だ。
ＮＴＴの電話料金は、ＮＴＴ東日本からの委託を受け、ＮＴＴファイナンスが請求してくる。
通常、請求というのは「２か月以内の遅れ」で来るものなのだけど、上記の経路の関係なのか、３か月遅れになる。
会社自体の「決算」は６月末で、それから２か月後の８月末までに書類をまとめる。
しかし、ＮＴＴの請求が来るのは９月なので、決算時に困るのだ。
…まぁ、それはいいや。現実には来ないので、８月までに請求された分で書類を作っている。
困るのは、「どこに行けば請求書が見られるのか」ということ。
以前はＮＴＴ東日本で見られたのだけど、今はＮＴＴファイナンスで見なくてはならない。
うかつにＮＴＴ東日本のログインＩＤがあるので、入って探し回ってから「あぁ、違うのだった」と思いだす。
そして、年に一度しか入らないのでパスワードを忘れている。
いつも２～３回試して、「あぁ、ここは特殊だった」と思いだして書いてあるメモを探したりすることになる。
ところが、「セキュリティのため」数度間違えると、郵送で申し込んで再発行だったりする。
時間に追われているときに、ネットワークを見るために、何日もかけて郵送を行わないといけないという時代錯誤。
セキュリティのため、と言ってはいるが、ほぼ「作ってはならない」レベルのシステムだ。
…と、このことは３年前にも詳細を書いていた。
しかし、今年は一連の作業の中で、光明を見出した。
我が家ではインターネットプロバイダに、アサヒネットを使用している。
以前は、回線はＮＴＴ東だった。
数年前に、国の方針もあってＮＴＴが光回線を開放することになり、ＮＴＴの回線を使用して、アサヒネットが光回線のサービスを開始した。
この時に、アサヒネットに統合を行った。
これで、プロバイダ料金と回線料金が一つになり、書類仕事が簡単になる。
…と思ったら、この時は電話回線の統合はできなかった。結局ＮＴＴは残る。
それが、今年の作業中、アサヒネットの請求書などを印刷するためにユーザーページに入ったところで、「アサヒネットが光回線を使用した電話サービスを開始した」ことを知ったのだ。
これで、やっとＮＴＴからオサラバできる。
経理作業が終わった８月末、アサヒネットに切り替え申請を行った。
９月頭、アサヒネットから書類が届き、注文を受け付けた、ということが書かれていた。
他にも各種注意事項などの説明が入っていた。
一般回線から切り替える場合、対応機器を購入して設定を行う必要もある。
しかし、ＮＴＴですでに IP 電話を使用していた場合は、何もすることはない。
不思議なことに、工事日が書いてなかった。
数日後、さらに書類が来る。
切替工事を行う、工事後はサービスがアサヒネットに移管されるため、ＮＴＴへの各種問い合わせはできなくなる、という注意などが書いてあった。
しかし、不思議なことに、やはり工事日が書いてない。
うーん、何か不備を感じるが、書類は届いているし、どこかの段階で工事が行われるのだろう。
切り替えに何も手続きはいらないというし、気づいたら変わっている、という感じなのだろうな。
…ということがあり、それから１か月半ほどたって、すっかり忘れていた。
いや、「ちゃんと工事されたのか、どこかで確かめないとな」という意識は、心の片隅には残っていた。
それが、この週末にアサヒネットのカスタマーサポートから電話があったのだ。
「アサヒネットの IP 電話使いませんか？」という、アサヒネットユーザーへのセールスだった。
え、うち既に使っているはずですけど、というと、しばらく向こうで何か調べていて、使われている記録がないという。
こちらに書類も届いてますよ、と、書類を探して日付なども伝えるが、先方には書類を発行した形跡すらないという。
おいおい、大丈夫かよ。アサヒネット。
こちらはサービスを使う意思はあるし、むしろもう使っているものだと思っていた。
先方としては、サービスを使って欲しいと思っている。
やりたいことは双方一致している。
電話口のオペレーターが平謝りで、再度手続きを行うことになった。
一応、工事日は１１月初頭だそうだ。
2019.11.18追記
後日談書きました。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日、Twitter で僕のページを引用してくださった人がいた。
＃たびたび書くけど、エゴサーチしてますよ。
引用されていたのは、「OS の登場」のページ。
…書いたのずいぶん前で、内容が拙くて恥ずかしい。
しかしまぁ、大きく間違ったことも書いてないのでそのまま残してある。
で、引用してくださった方は、「１行が８０文字」の理由を探していたようだ。
該当ページには、IBM パンチカードが１枚に 80 文字を収めることができたため、コンピューターにディスプレイが付けられた際にも、１行に 80 文字を表示できる必要があった、ということを書いてある。
この話、のちに別のところで詳細解説している。
ハーマン・ホレリス 命日の記事。
ホレリスは、IBM の前身の１つとなる「タビュレーティング・マシン」社を興した人物。
パンチカード集計機を発明し、80桁の数値を記述できるパンチカードを標準化した。
のちに、数値だけでなく文字も表現できるようになったが、80桁、という枠組みは変わらなかった。
さて、冒頭に書いた引用してくださった方は、これが１行 80 文字の理由、としたうえで、「メールの１行を 80文字に制限するマナーは迷信だった」と結論付けていた。
いや、それは論理が飛躍しすぎている。
おそらくは、「古くは」画面の横幅が 80 文字だったことを知り、「今は」その制限がないのだから迷信、という思考の流れだと思う。
しかし、残念ながら 80文字…より厳密にいえば、78文字というのはマナーなどではなくて、システム的な「要求」なのだ。
メールの１行は、78文字を超えるべきではない。
「べきではない」と書かれているように、超えても普通は大丈夫。
だから、緩い制限の「マナー」だと思われがちなのだけど、技術文章で規定された制限なのだ。
インターネットを流れるデータの規定といえば、RFC 。
インターネットメールは、RFC 822 から始まるが、紆余曲折あり、RFC 2822 になり、現在は RFC 5322 となっている。
（なんとなく、822 から連想されやすい番号を割り振っているところが素晴らしい）
で、現在の仕様である 5322 の 2.1.1 節に、こう書いてある。
2.1.1. Line Length Limits
There are two limits that this specification places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
（以下略）
意訳：
2.1.1. 行の長さ制限
１行の文字数には、２つの制限がある。
CRLF を除く１行の文字数は、９９８文字を超えてはならず、７８文字を超えるべきではない。
意訳の中の CRLF というのは、改行を意味する文字のこと。
画面上に表示はされないが、コンピューターのプログラム的には、「１行」の最後には、「行の終わり」を意味する文字が必要となる。
説明すると長いので省略するが、行の終わりは２つの見えない文字で成り立っていて、CR と LF だ。
１行は「改行を除いて」78文字を超えるべきではない。
言い換えれば、「改行を入れて」80文字までだ。
ここに、パンチカードは１枚 80文字という制限が復活している。
パンチカードが 80文字だったために、FORTRAN 言語では１行を 80文字以内と定義しており、ディスプレイは１行に 80文字を表示できるように作られ、初期のスクリーンエディタは１行を 80文字以内としていた。
エディタが１行を 80文字で扱うということは、テキストファイルも１行が 80文字を超えることはない、ということだ。
これを前提として、非常に古いメールシステムの中には、１行を 80文字としてプログラムされたものがあるらしいのだ。
今更そんなシステムが生き残っているとは思えないが、もしそうしたシステムがメールを受け取ってしまうと、80文字を超える部分は削除されたり、強制的に次の行に送られたりする。
RFC ではそうしたシステムを考慮して「78文字を超えるべきではない」としている。
場合によっては一部の情報が削除され、相手に届かなくなってしまう。
それを避けるための制限は、トラブルを未然に防ぐために使用者が心がけなくてはならないもので、マナーや迷信ではない。
ところで、RFC 5322 には、使用できる文字コードの制限もある。
2.3. Body
The body of a message is simply lines of US-ASCII characters.
（以下略）
意訳：
2.3. 本文
メッセージ本文は、単純に US-ASCII で作られた複数行となる。
そう、US-ASCII しか使ってはいけないのだ。
英語は許されるが、ドイツ語もフランス語もだめだし、日本語なんて論外だ。
しかし、実際にこれらの言語でもメールは送れる。
どうなっているかというと、US-ASCII 「以外」のメールは、計算によって US-ASCII の文字に「変換」されて送られるのだ。
この計算方法のひとつに、MIME がある。
US-ASCII に変換されるといっても、日本語が英語に翻訳されたりするわけではない。
単に、日本語の文字を示す「数値」を計算して、数文字の US-ASCII の組み合わせで表現されるだけだ。
変換の際、結果として得られる US-ASCII 文字列は、76文字ごとに改行を入れる、という決まりとなっている。
この結果、元文章の１行が 80文字以上になっていたとしても、通信経路上ではちゃんと 80文字以内に収まっている。
結果的に、「80文字を超えるべきではない」という技術的制限は守られているのだが、利用者がそれを気にする必要はない。
…と、これだけなら「80文字制限は迷信」という最初の話でも、まぁいいかな、ってことになるのだけど、話はもう少し続く。
RFC 5322 で書かれているのは、メールの内容の扱いであり、「MIME の扱いは別議論」としている。
つまり、いったん MIME に変換された際には 80 文字の制限が守られるとしても、それは「メールが」 80文字の制限を守っているのとは違う扱いになる。
通信経路上の問題が解消したとしても、メール自体の問題は残っているのだ。
また、上に、US-ASCII に変換する「計算方法の一つに MIME がある」と書いた。
別の方法もあって、その方法を使うと、MIME の「１行 76文字への変換」が行われない。
この場合、通信経路上の問題も解決していないことになる。
MIME は比較的新しい方法で、日本語の場合、古くは JIS コードでメールの通信が行われた。
これも、「日本語を US-ASCII に変換する計算方法」の一つだ。
そして、今でも互換性のためにこの方法を使えるメールソフトは、結構多い。
JIS コードが当たり前だった当時、よく言われたマナーとしては「１行は 36文字以内」だった。
JIS コードでは、日本語１文字は、英語２文字で表現される。
だとすれば、78文字の制限は、39文字以内となるはずだ。
残る３文字はどこに行ったのだろう？
実のところ、JIS では、ASCII と JIS を切り替えるために、ASCII に規定された「ESC」を使用した。
ESC とは、ASCII から「脱出」して、独自の文字コードを使うために設けられた規定だ。
そして、JIS コードは、ESC に続いて２文字を送ることで、日本語と ASCII を切り替える。
行の頭で日本語を開始し、行の終わりで日本語を終わるとしたら、これに 6文字が必要になる。
日本語に変換すると、３文字分だ。
つまり、これが日本語にした際に消えた３文字分だ。
JIS コードを使用する場合、日本語で RFC の規定を守ろうとすると、１行が36文字以内でないといけない。
ちなみに、行の中に ASCII を入れたりすると、そのたびに切り替えコードが入るため、書いてよい文字数はそれだけ減ることになる。
…JIS でメール書いていた時代でも、80文字を超えて問題出るような環境はまずなかったから、そこまで気にしなかったけどね。
＃現在、JIS コードには iso-2022-jp という名前が与えられている。
JIS コードは、日本国内のローカル規格、iso-2022-jp は国際規格だ。
メールに限らず、通信手段というのは、「相手」や「通信経路」など、多くの参加者があって成立するものだ。
そして、多く参加者があるということは、そのどこに問題が潜むかわからない。
RFC がいまだに１行を 80文字に制限しているのも、実際に過去に 80文字の制限を持つプログラムがあり、今でも残っている可能性があるからだ。
もっとも、RFC5322 の中には、80文字で情報を切り捨ててしまうような環境が本当にあるとすれば、それ自体が RFC5321 違反だ、と言及している部分もある。
（5322 は「メールの書き方」を規定していて、5321 は「メールの送信方法」を規定している）
MIME を使っている場合は、途中経路の問題は気にする必要はないだろう。
MIME によって行は 76文字に揃えられ、決して 80文字を超えることはない。
しかし、この場合も、相手が 80文字を超える行を扱えるとは限らない、ということに注意だ。
…まぁ、そんな古いメーラーを使っている場合、MIME で変換された本文を、元に戻すこともできないような気がする。
もし戻せたとしても、UTF-8 が表示できない、なんてことになりそう。
あまり気にしすぎる必要はないけど、ちょっと気に留めとけ、くらいの問題か。
RFC って、「自分には厳しく、他者には寛容に」という精神なんだよね。
超えるべきではない、と言われているのであれば、自分は超えないようにしないとならない。
でも、誰かが超えてしまったとしても、違反だと怒るのではなく、何の問題もなかったかのように扱えないといけない。
RFC の「規定」って、そういうものなの。
だから、80文字を「超えるべきではない」と規定されているのであれば、少なくとも自分は超えないようにした方がいい。
超えたとしても、「寛容」の精神で、おそらく何も問題は出ないのだけど。
ここで、問題が出ないからこそ、ただの「マナー」だと言われてしまいやすい。
でも、問題が出なくても違反行為で、「寛容さによって」助けられただけという意識は必要。
2019.10.29 追記
そもそも、なぜ「US-ASCIIしか送れない」なんてことになっているのか、という疑問をいただきました。
簡単に言うと、今のコンピューターは 8bit を情報の基本単位としているけど、古いコンピューターには 7bit のものがあるから。
US-ASCII は、7bit で文字を表現するようになっています。
この話、詳細はちょうど10年ほど前に書いてます。
少し内容が古い（最新 OS が Windows 7 だったり、メールの JIS 送信がまだ普通だったりする）けど、以下にリンクしておきます。
同じテーマの日記(最近の一覧)
別年同日の日記
15年 古くて非力なマシンをLinuxBeanで再生してみた
申し訳ありませんが、現在意見投稿をできない状態にしています。 |