買ってきた。
レモンは爽やかな苦味と酸味。
オレンジはいい香りと甘みと酸味。
どちらも美味しい。
いつ頃から売られていたんだろう?
今回初めて買ってきたので、味見ということでそれぞれ１つずつ買ってきた。
半年ぐらいもつようだ。
災害時、乾パンや即席麺ばかり食べているとすぐに飽きる。
こういうものも用意しておいたほうがいい。
もっとたくさん買ってくればよかった。
2023年4月30日日曜日
2023年4月29日土曜日
Ubuntu22.04へ
この3万円ちょいで買ったPCを未だに使っている。
Ubuntu18.04をインストールして使っていたが、LTSの期間も終わった。
個人使用なのでUbuntu Proの延長サポートを使うこともできる。
しかし、Ubuntu1804では、ShotCutが動かないし、Gimpの縦書きもない。
だんだんと無理が出てきている。
そろそろ潮時だ。新しいUbuntuに入れ替えることにした。
LTS(長期サポート)版の最新、すなわち22.04(2022年04月版)にする。
18.04=(2018年04月版)から4年が経過している。
技術的にも色々変わっており、移行は一筋縄では行かないだろうことは、想像に難くない。
倍容量の新しい mSATA SSD に入れ替え、今まで使っていたSSDをまるまる保存することにした。
mSATA-USB I/Fを用意すれば、データの移行もできる。
インストール用のDVDイメージをダウンロードして、「ブータブルUSBの作成」機能でインストールイメージのブータブルUSBを作成した。
起動を試みたが、なぜか起動しない。
一応、UEFIなのだが切り替わって間もない時期のPCなので、現在の技術との互換性が低いのかもしれない。
結局またDVDにイメージを焼こうとした。今度は容量が足りない。
なんと、Ubuntu22.04.2のイメージは、4.9GBもある。
うちのDVDは4.7GBなので、入りきらない。
USBでもだめ。DVDもだめ。どうしたものか…
ダウンロードフォルダを見ていると、Ubuntu22.04日本語Rimixのイメージがあった。
VirtualBoxで試しに使っていたときのやつだ。
そのサイズは4.3GBだった。
これならDVDに焼ける。
DVDを焼いて、起動を試みる。
DVDでの起動は30分ぐらいかかった。起動することを確認してから、SSDの入れ替えを行った。
SSD入れ替え後に、BIOSが正しく認識することを確認して、ついでにBIOSにあったHDDテスト機能でテストした。
インストールDVDで起動に30分、インストールに25分。
インストール後に、aptでパッケージの更新をする。
なんだかんだで作業を初めて数時間かかった。
VirtualBoxで試していたので、ここから先は簡単だろうと思っていたけど、色々引っかかった。
まずRabbitVCS。
これが全然動かない。そもそも Gnome-session-flashback + nemo という主流ではない環境を使っているのが悪いのだが。
nemoをコマンドラインから起動して、エラーメッセージを確認する。
configspec.iniがないのが悪いようだった。
無いのかといえば、”/usr/lib/python3/dist-packages/rabbitvcs-0.18-py3.10.egg/share/rabbitvcs/configspec.ini”にインストールされている。
どこを期待しているのだろう？
Ubuntu2204には、nemo用のRabbitVCSが無いので、RabbitVCS本家のgitのものを使っている。
しかし、Ubuntu2204には Nautilus用のRabbitVCSパッケージは存在し、rabbitvcs-coreパッケージもある。
これらパッケージがconfigspec.iniをどこに保存しているか見てみた。
"/usr/share/rabbitvcs/configspec.ini"となっていた。
そこに”/usr/lib/python3/dist-packages/rabbitvcs-0.18-py3.10.egg/share/rabbitvcs/configspec.ini”へのシンボリックリンクを配置したら、一応動くようになった。
(他にも色々やったんだけど、細かいことは忘れてしまった)
sshで母艦への接続を確認しているときに、PulseAudioのPreferencesアプリの"Network Server"タブ内がすべてグレーアウトして操作できない。
そもそも、paprefsはデフォルトでは入っていないので、"apt-get install paprefs"でインストールする。
ネットで調べると、DLLへのパスがpaprefsが期待している場所ではないらしい。
代りに"pulse-15.99.1+dfsg1/"以下に色々入っている。
ということで、これもシンボリックリンクを作る。
そうするとpaprefsが動作する。
自家製シンセサイザとか作るんなら、リモートの音もならないと面白くない。
ここは、こだわりたい部分だ。
例のプリンタ＋スキャナ複合機のドライバも入れ直し。
プリンタドライバは、以前と同様の方法で入った。
スキャナのAll in Oneも簡単に入ったが、機械のアドレスを設定する方法が変更になった。
以前は”/etc/imagescan/imagescan.conf”を書き換えていたのだが、そのファイルが無い。
ダウンロードページの”epsonscan2_j.pdf”内の「8.1. ネットワーク接続デバイス」のあたりを読むと、初回起動時にアドレスを設定するらしい。
起動すると、以下のような小さなダイアログボックス的なウインドウが表示される。
この真ん中のドロップダウンを何回かクリックすると、「ネットワークスキャナの追加」ダイアログが表示される。
ここで、アドレスの欄にプリンタのIPアドレスを設定する。
うちはルータで固定IPを割り当てており、/etc/hostsで"ewm752t"の名前で参照できるようにしているので上記のようになる。
設定後、「追加」ボタンを押して、「OK」ボタンをクリックすると、スキャナアプリEPSON SCAN2が起動する。
以前はImageScan2という普通すぎる名前で、しばらく使わないとこれはEPSONのだっけ？って感じでわからなくなっていた。
わかりやすい名前になってよかった。
しかし、U/Iが全然違う。
使い方が変わったので少し困惑したが、新しいU/Iのほうが機能的で使いやすい。
また以前の設定を覚えておいてくれるので助かる。
入れ替えは、とにかく手間がかかる。
何かをやろうとすると、問題にぶち当たる。
もうしばらくかかりそうだ。
2023/05/20 プリンタのIPアドレス設定の画像を間違えていた。入れ替えた。
Ubuntu18.04をインストールして使っていたが、LTSの期間も終わった。
個人使用なのでUbuntu Proの延長サポートを使うこともできる。
しかし、Ubuntu1804では、ShotCutが動かないし、Gimpの縦書きもない。
だんだんと無理が出てきている。
そろそろ潮時だ。新しいUbuntuに入れ替えることにした。
LTS(長期サポート)版の最新、すなわち22.04(2022年04月版)にする。
18.04=(2018年04月版)から4年が経過している。
技術的にも色々変わっており、移行は一筋縄では行かないだろうことは、想像に難くない。
倍容量の新しい mSATA SSD に入れ替え、今まで使っていたSSDをまるまる保存することにした。
mSATA-USB I/Fを用意すれば、データの移行もできる。
インストール用のDVDイメージをダウンロードして、「ブータブルUSBの作成」機能でインストールイメージのブータブルUSBを作成した。
起動を試みたが、なぜか起動しない。
一応、UEFIなのだが切り替わって間もない時期のPCなので、現在の技術との互換性が低いのかもしれない。
結局またDVDにイメージを焼こうとした。今度は容量が足りない。
なんと、Ubuntu22.04.2のイメージは、4.9GBもある。
うちのDVDは4.7GBなので、入りきらない。
USBでもだめ。DVDもだめ。どうしたものか…
ダウンロードフォルダを見ていると、Ubuntu22.04日本語Rimixのイメージがあった。
VirtualBoxで試しに使っていたときのやつだ。
そのサイズは4.3GBだった。
これならDVDに焼ける。
DVDを焼いて、起動を試みる。
DVDでの起動は30分ぐらいかかった。起動することを確認してから、SSDの入れ替えを行った。
SSD入れ替え後に、BIOSが正しく認識することを確認して、ついでにBIOSにあったHDDテスト機能でテストした。
インストールDVDで起動に30分、インストールに25分。
インストール後に、aptでパッケージの更新をする。
なんだかんだで作業を初めて数時間かかった。
VirtualBoxで試していたので、ここから先は簡単だろうと思っていたけど、色々引っかかった。
まずRabbitVCS。
これが全然動かない。そもそも Gnome-session-flashback + nemo という主流ではない環境を使っているのが悪いのだが。
nemoをコマンドラインから起動して、エラーメッセージを確認する。
configspec.iniがないのが悪いようだった。
無いのかといえば、”/usr/lib/python3/dist-packages/rabbitvcs-0.18-py3.10.egg/share/rabbitvcs/configspec.ini”にインストールされている。
どこを期待しているのだろう？
Ubuntu2204には、nemo用のRabbitVCSが無いので、RabbitVCS本家のgitのものを使っている。
しかし、Ubuntu2204には Nautilus用のRabbitVCSパッケージは存在し、rabbitvcs-coreパッケージもある。
これらパッケージがconfigspec.iniをどこに保存しているか見てみた。
"/usr/share/rabbitvcs/configspec.ini"となっていた。
そこに”/usr/lib/python3/dist-packages/rabbitvcs-0.18-py3.10.egg/share/rabbitvcs/configspec.ini”へのシンボリックリンクを配置したら、一応動くようになった。
sshで母艦への接続を確認しているときに、PulseAudioのPreferencesアプリの"Network Server"タブ内がすべてグレーアウトして操作できない。
そもそも、paprefsはデフォルトでは入っていないので、"apt-get install paprefs"でインストールする。
ネットで調べると、DLLへのパスがpaprefsが期待している場所ではないらしい。
strace paprefs 2>&1 |grep /lib/pulseで見ると、"/usr/lib/pulse-15.99/"以下を参照しているが、そんなディレクトリはない。
代りに"pulse-15.99.1+dfsg1/"以下に色々入っている。
ということで、これもシンボリックリンクを作る。
そうするとpaprefsが動作する。
ここは、こだわりたい部分だ。
例のプリンタ＋スキャナ複合機のドライバも入れ直し。
プリンタドライバは、以前と同様の方法で入った。
スキャナのAll in Oneも簡単に入ったが、機械のアドレスを設定する方法が変更になった。
以前は”/etc/imagescan/imagescan.conf”を書き換えていたのだが、そのファイルが無い。
ダウンロードページの”epsonscan2_j.pdf”内の「8.1. ネットワーク接続デバイス」のあたりを読むと、初回起動時にアドレスを設定するらしい。
起動すると、以下のような小さなダイアログボックス的なウインドウが表示される。
設定後、「追加」ボタンを押して、「OK」ボタンをクリックすると、スキャナアプリEPSON SCAN2が起動する。
以前はImageScan2という普通すぎる名前で、しばらく使わないとこれはEPSONのだっけ？って感じでわからなくなっていた。
わかりやすい名前になってよかった。
しかし、U/Iが全然違う。
また以前の設定を覚えておいてくれるので助かる。
入れ替えは、とにかく手間がかかる。
何かをやろうとすると、問題にぶち当たる。
もうしばらくかかりそうだ。
2023/05/20 プリンタのIPアドレス設定の画像を間違えていた。入れ替えた。
予防接種
新型コロナのクーポン券がまた来た。
5回目ってことかな。
オミクロン対応ワクチンを接種していたが、番号の若いやつだったように記憶している。
最後のやつをやれってことなのかもしれない。
それはそうと、３月に採血した風疹の予防接種、採血後になんの連絡も来ない。
待っているだけでなく、自分から動いて問題は解決するべきだ。
それはわかっているが…
3月は年度末の追い込みで忙しい。
特に今年は輪をかけて忙しく、４月中頃まできつい状態だった。
体調を崩したりしている状態では、予防注射はできない。
また採血が土曜日だった。
急いでいるわけではない(重病や大怪我ではない)ので病院側の事務手続きその他の手間を考えれば、同じ先生がいる土曜に電話しようと思っているのだが、なかなか時間が確保できない。
そして今週の土曜は「昭和の日」で休み。
来週は普通の土曜だが、GWの休みに挟まれた土曜に、仕事をしているかな？
そう考えると、再来週になりそうだ。
感染症の予防という社会的責任を果たすため、できれば早く済ませようとしているのだが、どうにもうまくいかない。
5回目ってことかな。
オミクロン対応ワクチンを接種していたが、番号の若いやつだったように記憶している。
最後のやつをやれってことなのかもしれない。
それはそうと、３月に採血した風疹の予防接種、採血後になんの連絡も来ない。
待っているだけでなく、自分から動いて問題は解決するべきだ。
それはわかっているが…
3月は年度末の追い込みで忙しい。
特に今年は輪をかけて忙しく、４月中頃まできつい状態だった。
体調を崩したりしている状態では、予防注射はできない。
また採血が土曜日だった。
急いでいるわけではない(重病や大怪我ではない)ので病院側の事務手続きその他の手間を考えれば、同じ先生がいる土曜に電話しようと思っているのだが、なかなか時間が確保できない。
そして今週の土曜は「昭和の日」で休み。
来週は普通の土曜だが、GWの休みに挟まれた土曜に、仕事をしているかな？
そう考えると、再来週になりそうだ。
感染症の予防という社会的責任を果たすため、できれば早く済ませようとしているのだが、どうにもうまくいかない。
2023年4月23日日曜日
2023年4月22日土曜日
いつまでたっても
50を越えて、体力が落ちてきた。
若い頃は、徹夜しても大丈夫だった。
最近は、集中してバリバリ作業をしていると、夕方にはぐったりと疲れている。
それでも、年度末へ向けて頑張らないといけない。
風邪をひいて、寝込んだりしたら大失敗だ。
3月は花粉も飛んでおり、風邪に気づきにくく、悪化させやすい。
それだけは避けなければならない。
結局、3月末には終わらず、4月に被った。
最後の週は、出口が見えて、作業量がつかめたので、ラストスパートで踏ん張った。
気合が入っているので、仮に風邪をひいていても、1,2日なら気が付かずに何とか乗り切れる。
しかし、乗り切った後は、どっと疲れが出て体調を崩す。
先週の週末はダメダメだった。
今週月曜になっても、体調はイマイチで、目の下がくすぐったいような感じになっていた。
だんだん痒くなり、痛くなり、昨日には「ものもらい」のようになった。
昨日目薬をさして、今日やっと回復した。
考えてみると、若い頃、この状態の事を「潰してきたバグの呪い」と呼んでいた。
無理の度合いはだいぶ変わった(減った)けど、今も昔もやっていることは変わらない。
若い頃は、徹夜しても大丈夫だった。
最近は、集中してバリバリ作業をしていると、夕方にはぐったりと疲れている。
それでも、年度末へ向けて頑張らないといけない。
風邪をひいて、寝込んだりしたら大失敗だ。
3月は花粉も飛んでおり、風邪に気づきにくく、悪化させやすい。
それだけは避けなければならない。
結局、3月末には終わらず、4月に被った。
最後の週は、出口が見えて、作業量がつかめたので、ラストスパートで踏ん張った。
気合が入っているので、仮に風邪をひいていても、1,2日なら気が付かずに何とか乗り切れる。
しかし、乗り切った後は、どっと疲れが出て体調を崩す。
先週の週末はダメダメだった。
今週月曜になっても、体調はイマイチで、目の下がくすぐったいような感じになっていた。
だんだん痒くなり、痛くなり、昨日には「ものもらい」のようになった。
昨日目薬をさして、今日やっと回復した。
考えてみると、若い頃、この状態の事を「潰してきたバグの呪い」と呼んでいた。
無理の度合いはだいぶ変わった(減った)けど、今も昔もやっていることは変わらない。
2023年4月16日日曜日
UTF-8
昨日の記事で、Shift_JISの5C問題について書いた。
「だから、Shift_JISなんてダメダメだ!」なんていう人もいるだろう。
文字を「バイト」として扱うから問題になる。
文字を「文字」として扱えば、'\'記号か、2バイト文字の2バイト目なのかは区別がつく。
ようはそれだけだ。
以前は、組み込み開発では、メモリサイズの都合から基本的に2バイト文字に対応することはなかった。
しかし、マイコン内蔵メモリも増えてきた。ファイルシステムを扱うようになると、ファイル名に2バイト文字が含まれるため、しばしば2バイト文字の扱いが必要になることもある(２バイト文字を扱わないというソリューションもあると思うけど)。
そのため、十数年前から組み込み環境へマルチバイト文字を扱う関数群を移植することも増えた。
UTF-8は、C5問題のような問題はない。
UTF-8では、複数バイトで構成される文字のバイト値に、ASCII 7bit文字のバイト値が含まれないためだ。
そのため、5Cは常に'\'であり、文字を「文字」として扱わなくてもこの問題は生じない。
じゃ、何も考えなくていいのかというと、そうでもない。
例えば「泣き別れ問題」は、Shift_JIS同様存在する。
例えば、何らかの理由で文字列の一部を区切る必要があるとき、複数バイトで構成される文字の途中で区切るわけにはいかない。
UTF-8の１文字を構成するバイト列が泣き別れになると、Unicodeへデコードできなくなる。
そのため、任意のバイトでは区切れない。結局、文字を「文字」として扱う必要がある。
文字列を区切る理由の１つに、物理的な表示幅の制限がある。
プロポーショナルフォントの場合、文字毎に、場合によると文字の組み合わせや順序により、文字列の幅が変わる。
そのため、常に文字列として幅を調べなければならないため、1バイト文字もマルチバイト文字も関係ない。
厄介なのは端末アプリだ。
日本語対応端末は伝統的に、英数や半角カナは半角(1カラム)、漢字は全角(2カラム)で表示される。
Unicodeでは、半角、全角以外に、N(中立)、'A'(曖昧な幅)があり、これらの文字のカラム数はコンテキスト依存して変化する。
(Wikipediaの「東アジアの文字幅」参照)
すなわち「よくわからない」幅なのだ。
やや乱暴なソリューションとして、『「よくわからない」を使用しない』というのも考えられる。
しかし、Shift_JISでも存在していたギリシャ文字やキリル文字、一部の記号も、'A'に分類されている。
これらの文字を使わないとするのは、さすがに乱暴すぎるだろう。
コード体系もJIS漢字とは異なるため、これらの文字幅を自力で解決しなければならない。
20年以上前から、自家製FATファイルシステムドライバを実装していた。
当初はFAT12/16のみ対応だったけど、途中からFAT32に対応し、Long File Nameにも対応した。
Long File Nameにしっかり対応するとなると、Unicode - CP932(Shift_JIS)との相互変換が必要になる。
そのころ、UTF-8-cjk.txtという文書が入手可能だったのだので、その情報を元に、変換テーブルを作った。
なんと、そのファイルの末尾には、Unicode文字の文字幅の情報も付いていた。
この文字幅情報を使って、日本語UTF-8テキストファイルのTAB-Space変換を実装したりもした。
さらに、端末を用いた組み込みでのコマンドライン処理で、UTF-8文字を扱う際の、カラム数の算出にも使った。
今では自家製組み込みコマンドライン処理は、Shift_JISとUTF-8の両方に対応している(コンパイル時に決定)。
ところが、そのファイルはいつの間にかダウンロードできなくなっていた。
今は、EastAsianWidth.txtで文字幅の情報が得られる。
ここまでやれば、UTF-8での文字列の幅に対応できるようになる。
私は、Shift_JISであれ、UTF-8であれ、どっちでも同じように実用上問題なく扱えている。
(Shift_JISというか、CP932というか、には例外的なものが多く、Unicodeは今でも成長を続けているので、完璧ではないし、完璧と言えるものは無いだろう)
「UTF-8がいい」「Shift_JISなんてダメダメだ！」なんて言っている人、ちゃんと理解できているかな？
2023/04/23 追記:文字幅0の文字について 制御文字やウムラウト(日本語では濁点や半濁点)等、一部の文字は幅がない。
これらの文字幅も正しく扱うなら、UnicodeData.txt から情報を抽出する必要がある。
検索すればすぐに出てくる。とはいえ、ダウンロードして手元に置いておくほうがいいだろう。
メンテ等で時々ダウンロードできなくなる。
抽出方法については、UTF-8-cjk.txtに書いてあった。
抜粋すると、
これもまた表示環境に依存する。
「だから、Shift_JISなんてダメダメだ!」なんていう人もいるだろう。
文字を「バイト」として扱うから問題になる。
文字を「文字」として扱えば、'\'記号か、2バイト文字の2バイト目なのかは区別がつく。
ようはそれだけだ。
以前は、組み込み開発では、メモリサイズの都合から基本的に2バイト文字に対応することはなかった。
しかし、マイコン内蔵メモリも増えてきた。ファイルシステムを扱うようになると、ファイル名に2バイト文字が含まれるため、しばしば2バイト文字の扱いが必要になることもある(２バイト文字を扱わないというソリューションもあると思うけど)。
そのため、十数年前から組み込み環境へマルチバイト文字を扱う関数群を移植することも増えた。
UTF-8は、C5問題のような問題はない。
UTF-8では、複数バイトで構成される文字のバイト値に、ASCII 7bit文字のバイト値が含まれないためだ。
そのため、5Cは常に'\'であり、文字を「文字」として扱わなくてもこの問題は生じない。
じゃ、何も考えなくていいのかというと、そうでもない。
例えば「泣き別れ問題」は、Shift_JIS同様存在する。
例えば、何らかの理由で文字列の一部を区切る必要があるとき、複数バイトで構成される文字の途中で区切るわけにはいかない。
UTF-8の１文字を構成するバイト列が泣き別れになると、Unicodeへデコードできなくなる。
そのため、任意のバイトでは区切れない。結局、文字を「文字」として扱う必要がある。
文字列を区切る理由の１つに、物理的な表示幅の制限がある。
プロポーショナルフォントの場合、文字毎に、場合によると文字の組み合わせや順序により、文字列の幅が変わる。
そのため、常に文字列として幅を調べなければならないため、1バイト文字もマルチバイト文字も関係ない。
厄介なのは端末アプリだ。
日本語対応端末は伝統的に、英数や半角カナは半角(1カラム)、漢字は全角(2カラム)で表示される。
Unicodeでは、半角、全角以外に、N(中立)、'A'(曖昧な幅)があり、これらの文字のカラム数はコンテキスト依存して変化する。
(Wikipediaの「東アジアの文字幅」参照)
すなわち「よくわからない」幅なのだ。
やや乱暴なソリューションとして、『「よくわからない」を使用しない』というのも考えられる。
しかし、Shift_JISでも存在していたギリシャ文字やキリル文字、一部の記号も、'A'に分類されている。
これらの文字を使わないとするのは、さすがに乱暴すぎるだろう。
コード体系もJIS漢字とは異なるため、これらの文字幅を自力で解決しなければならない。
20年以上前から、自家製FATファイルシステムドライバを実装していた。
当初はFAT12/16のみ対応だったけど、途中からFAT32に対応し、Long File Nameにも対応した。
Long File Nameにしっかり対応するとなると、Unicode - CP932(Shift_JIS)との相互変換が必要になる。
そのころ、UTF-8-cjk.txtという文書が入手可能だったのだので、その情報を元に、変換テーブルを作った。
なんと、そのファイルの末尾には、Unicode文字の文字幅の情報も付いていた。
この文字幅情報を使って、日本語UTF-8テキストファイルのTAB-Space変換を実装したりもした。
さらに、端末を用いた組み込みでのコマンドライン処理で、UTF-8文字を扱う際の、カラム数の算出にも使った。
今では自家製組み込みコマンドライン処理は、Shift_JISとUTF-8の両方に対応している(コンパイル時に決定)。
ところが、そのファイルはいつの間にかダウンロードできなくなっていた。
今は、EastAsianWidth.txtで文字幅の情報が得られる。
ここまでやれば、UTF-8での文字列の幅に対応できるようになる。
私は、Shift_JISであれ、UTF-8であれ、どっちでも同じように実用上問題なく扱えている。
(Shift_JISというか、CP932というか、には例外的なものが多く、Unicodeは今でも成長を続けているので、完璧ではないし、完璧と言えるものは無いだろう)
「UTF-8がいい」「Shift_JISなんてダメダメだ！」なんて言っている人、ちゃんと理解できているかな？
2023/04/23 追記:文字幅0の文字について 制御文字やウムラウト(日本語では濁点や半濁点)等、一部の文字は幅がない。
これらの文字幅も正しく扱うなら、UnicodeData.txt から情報を抽出する必要がある。
検索すればすぐに出てくる。とはいえ、ダウンロードして手元に置いておくほうがいいだろう。
メンテ等で時々ダウンロードできなくなる。
抽出方法については、UTF-8-cjk.txtに書いてあった。
抜粋すると、
% Character width according to Unicode 5.0.0. % - Default width is 1. % - Double-width characters have width 2; generated from % "grep '^[^;]*;[WF]' EastAsianWidth.txt" % and "grep '^[^;]*;[^WF]' EastAsianWidth.txt" % - Non-spacing characters have width 0; generated from PropList.txt or % "grep '^[^;]*;[^;]*;[^;]*;[^;]*;NSM;' UnicodeData.txt" % - Format control characters have width 0; generated from % "grep '^[^;]*;[^;]*;Cf;' UnicodeData.txt" % - Zero width characters have width 0; generated from % "grep '^[^;]*;ZERO WIDTH ' UnicodeData.txt"実は、文字幅0の一部が文字幅2と被っている。
これもまた表示環境に依存する。
2023年4月15日土曜日
Shift_JIS
PC-98+MS-DOSの頃、文字列はShift_JISが当たり前だった。
私が考えるShift_JISの最大の利点は、半角文字は１バイト、全角文字は2バイトということだろう(一部例外を除く)。
これのどこが良いのかと言えば、バイト数が表示カラム数に一致するのだ。
しかしながら、'\'記号(5C)問題がある。
Shift_JISは２バイトで構成され、２バイト目は7bit文字のコードとかぶる部分がある。
そして、２バイト目が'\'記号(5C)になっている文字の場合、C言語のエスケープと見なされ、コンパイル時におかしな処理となる。
80年代、Lattice-CやMS-CでShift_JISで書かれたソースコンパイルしようとするとおかしなことになることがあった。
対策としては、2バイト目が'\'記号の文字の次に'\'記号を挿入するフィルタを実装して、make時にソースコードを変換してコンパイルする。
ちなみに、Turbo-C(後のBoarland C)では、Shift_JISを正しく扱っていた。
個人でプログラミングをする時は、Boarland C/C++ばかり使うようになっていった。
しかし、職場では住友電気のU-Stationを使っていた。
これはUnix機だったが、Shift_JISでソースコードを書いていたため、また'\'記号問題の対策(フィルタを実装して...)をする必要があった。
それから20年ぐらいだろうか。
そんな感じで開発環境が変わるたびに、毎度毎度同じ対策をし続けて、すっかり慣れていた。
そのため「UTF-8で文字の扱いが楽になる」という話を聞いた時、「Shift_JISで充分じゃん。」みたいに考えていた。
UTF-8では、'\'記号問題が無いという利点はあるが、なんと多くの全角文字が3バイトになるのだ。
さらには、半角カナも3バイトになる。
すなわち、文字のバイト数とカラム数が合わなくなる。
多くのprintf()の"%s"の「フィールド幅」や「精度」は、バイト数を指定するもので、カラム数ではない。
この記事のbookinfoの表示がズレズレになっているのも関係する。
実際には、EUC-JPの半角カナも2バイトだったため、このbookinfoは文字のカラム数を調整する機能も実装されている。
しかし、UTF-8には対応しておらず、ズレズレ表示になっている。
これはこれで、面倒な問題だ。
ちょっと話が脱線したが、Shift_JISでの問題は誰であれ自分なりの対処方法を持っていると思っていた。
しかし、こんなニュースを発見した。
キャラ名に「ソ」をいれるとバグる！ 古参開発者「うっ……頭の中で何かが……」
記事の末尾にあるが、もはや「過去の話」なのかもしれない。
私が考えるShift_JISの最大の利点は、半角文字は１バイト、全角文字は2バイトということだろう(一部例外を除く)。
これのどこが良いのかと言えば、バイト数が表示カラム数に一致するのだ。
しかしながら、'\'記号(5C)問題がある。
Shift_JISは２バイトで構成され、２バイト目は7bit文字のコードとかぶる部分がある。
そして、２バイト目が'\'記号(5C)になっている文字の場合、C言語のエスケープと見なされ、コンパイル時におかしな処理となる。
80年代、Lattice-CやMS-CでShift_JISで書かれたソースコンパイルしようとするとおかしなことになることがあった。
対策としては、2バイト目が'\'記号の文字の次に'\'記号を挿入するフィルタを実装して、make時にソースコードを変換してコンパイルする。
ちなみに、Turbo-C(後のBoarland C)では、Shift_JISを正しく扱っていた。
個人でプログラミングをする時は、Boarland C/C++ばかり使うようになっていった。
しかし、職場では住友電気のU-Stationを使っていた。
これはUnix機だったが、Shift_JISでソースコードを書いていたため、また'\'記号問題の対策(フィルタを実装して...)をする必要があった。
それから20年ぐらいだろうか。
そんな感じで開発環境が変わるたびに、毎度毎度同じ対策をし続けて、すっかり慣れていた。
そのため「UTF-8で文字の扱いが楽になる」という話を聞いた時、「Shift_JISで充分じゃん。」みたいに考えていた。
UTF-8では、'\'記号問題が無いという利点はあるが、なんと多くの全角文字が3バイトになるのだ。
さらには、半角カナも3バイトになる。
すなわち、文字のバイト数とカラム数が合わなくなる。
多くのprintf()の"%s"の「フィールド幅」や「精度」は、バイト数を指定するもので、カラム数ではない。
この記事のbookinfoの表示がズレズレになっているのも関係する。
実際には、EUC-JPの半角カナも2バイトだったため、このbookinfoは文字のカラム数を調整する機能も実装されている。
しかし、UTF-8には対応しておらず、ズレズレ表示になっている。
これはこれで、面倒な問題だ。
ちょっと話が脱線したが、Shift_JISでの問題は誰であれ自分なりの対処方法を持っていると思っていた。
しかし、こんなニュースを発見した。
記事の末尾にあるが、もはや「過去の話」なのかもしれない。
2023年4月8日土曜日
2023年4月2日日曜日
2023年4月1日土曜日
さいたまミネラルマルシェに行ってきた
3/31(金)〜4/2(日)の期間、さいたまスーパーアリーナで「さいたまミネラルマルシェ」という催し物が開催されている。
鉱物、化石、隕石等の展示があるというので、見てきた。
三葉虫やアンモナイトの化石、砂漠の薔薇、ざくろ石、愚者の黄金、何かが入っている琥珀など、興味深いものがあった。
きれいな宝石もたくさん展示されていた。
人が多くて、うんざり。
20分ぐらいみて、帰ってきた。
コロナ禍が終わって、人が増えきた。
徐々に慣らしていかないとね。
鉱物、化石、隕石等の展示があるというので、見てきた。
きれいな宝石もたくさん展示されていた。
人が多くて、うんざり。
20分ぐらいみて、帰ってきた。
コロナ禍が終わって、人が増えきた。
徐々に慣らしていかないとね。
登録:
投稿 (Atom)