にせねこメモ

はてなダイアリーがUTF-8じゃないので移ってきました。

このブログについて

文字・フォント・プログラム・技術・趣味などについて、Twitterでは書きづらい長い内容などをまとめるためのブログです。基本的には自分用のメモとして書いている部分が多いです。

リンク等

note https://note.com/nixeneko 残らなくてもいい記事
Pixiv Fanbox https://nixeneko.fanbox.cc/ 活動まとめと有料の週報(大したこと書いてないので)
Pixiv https://pixiv.me/nixeneko
Tumblr https://nixeneko.tumblr.com/ 絵。Pixivと同じにしたいがサボリ気味
Pleroma @nixeneko@nixeneko.info Mastodonとかやってる人はフォローしてください
Twitter @nixeneko 最近あんまり使ってない
GitHub https://github.com/nixeneko プログラムとか
Bookmeter https://bookmeter.com/users/9166 読書記録。たまに感想
Amazon欲しい物リスト amazon.jp/registry/wishlist/1C43ZFBA4IL6Z

同人誌(無料公開)

https://nixeneko.hatenablog.com/entry/c88_russian_alphabethttps://nixeneko.hatenablog.com/entry/c90_greek_latin_cyrillichttps://nixeneko.hatenablog.com/entry/20170811_dentyuhttps://nixeneko.hatenablog.com/entry/c100_mongol_bichig_unicode

「ラグトレイン」ロシア語カバーの和訳

稲葉曇の楽曲「ラグトレイン」を、ロシア語でカバーしたものを見つけた。歌手はSati Akura。
www.youtube.com
なので、試しに日本語訳してみた。歌詞の出所はここ

歌詞の翻訳だと、音符の数は決まっているので、歌詞と音を合わせるために内容が異なってくる。ロシア語はとにかく子音が多いので内容が多い。元の日本語詞と比較してみると面白いかもしれない。

ラグトレイン(ロシア語カバー) 日本語試訳

Меж городами спешат поезда,
街と街の間を列車たちは急ぐ、*1
Только мой ушёл, и без опоздания.
でも私の列車は行ってしまった、遅れもなく。*2
Как отыскать позабытые слова?
忘れられた言葉をどうやって探し出せばいい?
Пока их не вспомню, держу в кармане я.
それらを思い出すまで、私はポケットの中で握っていよう。

Тяжко вздохну, притворюсь ещё раз
重くため息をつき、もう一度
Погружённой в сон - но как затянулся день...
眠りに浸っているふりをしよう―でもなんて一日は長引いたことだろう…*3
Где отыскать позабытые слова?
忘れられた言葉をどこで探し出せばいい?
Пока покатаюсь на пригородном поезде.
今は行こう、郊外と街を繋ぐ列車に乗って。*4

Я не хочу ни вечера, ни скуки, что таится впереди.
私は欲しくない、夕方も、向かう先に潜む退屈も。*5
Главное - один глухими переулками затемно не ходи.
重要なのは―一人で、暗くなってから人気のない路地を通ってはいけない。
Но вот: на трассе переход "Постой," - говорит как будто бы.
でもほら: 通り道の横断歩道が「止まって」と言ってるみたいだ。*6
Подстерегает поворот, опять тебя удержит путами.
待ち伏せしている曲がり角が、再び君を束縛によって引き留めるだろう。*7

Меж городами спешат поезда,
街と街の間を列車たちは急ぐ、
Только мой ушёл, и без опоздания.
でも私の列車は行ってしまった、遅れもなく。
Как отыскать позабытые слова?
忘れられた言葉をどうやって探し出せばいい?
Пока их не вспомню, держу в кармане я.
それらを思い出すまで、私はポケットの中で握っていよう。

Грёз сброшу груз, ещё раз притворюсь
空想の積荷を振り落とし、もう一度
Погружённой в сон - но как затянулся день...
眠りに浸っているふりをしよう―でもなんて一日は長引いたことだろう…
Где отыскать позабытые слова?
忘れられた言葉をどこで探し出せばいい?
Пока покатаюсь на пригородном поезде.
今は行こう、郊外と街を繋ぐ列車に乗って。

Поезд вот-вот отправится вечерний, на платформе толчея.
ほら夕方の列車が発車するところだ、プラットホームには人混み。
Подожду, пока не опустеет вовсе станция, лучше я.
駅から全然人がいなくなるまで、私は待った方が良いだろうな。

Домой стремящихся прохожих
家へと突き進む通行人たちの
Поток тебя уносит тоже...
奔流が、君をも連れ去っていく…

Но нет: вокзальный турникет "Постой," - говорит как будто бы.
でもだめ: 駅の自動改札が「止まって」と言ってるみたいだ。
И на тебе сомкнутся вдруг объятья рук, и вновь запрут тебя...
そして君のところで突然塞がる両手の抱擁が、再び君を閉じ込めるだろう...*8

Тяжко вздохну, притворюсь ещё раз
重くため息をつき、もう一度
Погружённой в сон - но как затянулся день...
眠りに浸っているふりをしよう—でもなんて一日は長引いたことだろう…
Как отыскать позабытые слова?
忘れられた言葉をどうやって探し出せばいい?
Пока покатаюсь на пригородном поезде.
今は行こう、郊外と街を繋ぐ列車に乗って。

Меж городами поезда спешат без опоздания,
街と街の間を列車たちは遅延なく急ぐ、
Подняв ветра - сорвать, неся, чужим штормам не дай себя.
風を起こして、運びながら—他人の暴風に吹き飛ばされるな。*9
Забытые слова оставь. Не жаль их, раз потеряны.
忘れられた言葉はそのままにしておいて。それらは惜しくない。一度なくしたものだ。
Решает пусть за нас колёс по рельсам стук размеренный.
私たちのために、レールに沿って走る車輪の規則的なガタンゴトンの音に決めさせよう。

Меж городами спешат поезда...
街と街の間を列車たちは急ぐ…

Меж городами спешат поезда,
街と街の間を列車たちは急ぐ、
Только мой ушёл, и без опоздания.
でも私の列車は行ってしまった、遅れもなく。
Как отыскать позабытые слова?
忘れられた言葉をどうやって探し出せばいい?
Пока их не вспомню, держу в кармане я.
それらを思い出すまで、私はポケットの中で握っていよう。

Тяжко вздохну, притворюсь ещё раз
重くため息をつき、もう一度
Погружённой в сон - но как затянулся день...
眠りに浸っているふりをしよう—でもなんて一日は長引いたことだろう…
Где отыскать позабытые слова?
忘れられた言葉をどこで探し出せばいい?
И я улетаю на пригородном поезде.
そして私は飛び去っていく、郊外と街を繋ぐ列車に乗って。

*1:複数の列車が行き交ってることを示すためと、次の「私の(乗る予定の)列車」と対比させるために「列車たち」としてみた。

*2:列車の遅れがないということは、定刻通りの出発ということ。

*3:Погружённойが女性造格であることから、ロシア語詞訳者は、歌われている「私」が女性であることを想定しているのがわかる。

*4:郊外と街をつなぐ列車とは要するに通勤列車なのだが、通勤電車っていうと少しイメージが違う気がしたので字義通りにした。あと、покатаюсьは「しばらく乗りまわる」なのだが、日本語にしづらい。

*5:この関係節が、「退屈」だけにかかるのか、「夕方」にもかかるのかはよくわからない。また、夕方と訳したが、вечерは午後4時〜9時位を指すようで、日本語だと夕方〜晩くらいの幅がある。

*6:横断歩道と訳したпереходだが、「渡るためのもの」なので、歩道橋やアンダーパス、踏切などもпереходである。また、постойは「ちょっと待って」という感じでよく使う気がする。

*7:関係節っぽく訳したが、文法的には「曲がり角が待ち伏せしている。それは再び君を束縛によって引き留めるだろう」という感じか。

*8:関係節っぽく訳したが、文法的には「そして君のところで突然両手の抱擁が塞がり、それら(=抱擁)は再び君を閉じ込めるだろう...」という感じで日本語として自然に訳しづらい。

*9:ダッシュの左右で主語が交代している。副動詞の動作主はふつう主節の主語に一致するから、風を起こすのは列車であることはわかりやすい。一方、неся「運びつつ」の動作主は一見ты「君」のようだが、意味的には「君が運ぶ」より「列車が運ぶ」方が自然である。なので、несяは本来はダッシュより左にあるはずだったのではないかと思う。また、чужойは「他人の」の他に「無関係な」「異郷の」などの意味があるらしい。Don't let foreign storms blow yourself offくらいの意味か。直訳だと「他人の暴風に君を吹き飛ばさせることを許すな」。

技術書典14にサークル参加した感想

技術書典14が2023/5/20~6/4にオンライン開催、2023/5/21に池袋サンシャインシティ展示ホールDにてオフライン開催された。
私はこの催しに、オンライン・オフライン両方に「にせねこ.info」としてサークル参加した。

技術書典にはそれまで一般参加としても参加したことはなく、完全に初参加だった。
感想等を書いていく。なお、内容は当時のものであり、現在は異なっている可能性がある。

日程

物理書籍の搬入

  • オフライン会場への搬入→オフライン当日(5/21)に直接会場に持ち込むか、搬入されるように手配する。
  • オンライン会場への搬入→オンライン会期終了後、決められた到着日指定で、指定された量を送付する。

電子書籍の審査

電子書籍の審査には3日かかるとのこと。
なので、オンライン頒布開始5/20の3日前、5/16頃までには提出した方がよさそうだった。

印刷所

オフライン本は後援印刷所を使うと、当日サークルスペースに搬入してくれるので楽。

ねこのしっぽでフルカラーオンデマンドの場合の締め切りは次のようだった

  • 早割: 5/10(水) (当日10時までに申込み→13時までに入稿)
  • 通常締め切り: 5/16(火) (当日10時までに申込み→13時までに入稿)

頒布形式

「かんたん後払い」による決済が必須になっていた。それ以外の決済方法は任意。
また、紙書籍単体での頒布はできず、電子書籍もセットでないと頒布できないということだった。

「かんたん後払い」は電子版配布の仕組みがついているのでいいが、現金決済などを導入する場合は、電子版ダウンロードカードをつけるなどして電子版もセットで頒布する必要があった。

オフラインだけでの頒布というのは禁止のようで、オンラインでも入手可能にしておく必要があった。

感想

Webサイト

  • サイトが分かりづらい。検索すると最新の情報と古い情報が一緒くたに出てくるので、最新の情報がどれかわからない。
    • YouTubeやDiscordで情報を得るなどしないと大変かも?

マイページ

  • 会場でもマイページから商品の販売形態を編集できるので、紙版が売り切れたら受注生産に切り替えたりなどもでき、便利そうではあった。
  • 売上管理では月ごとの売り上げと手数料が見れるのだが、何がどれだけ売れたかなどは分からない。別に販売履歴は確認できるのだが、自動集計ができない(しづらい)ので、CSVとかでダウンロードできるとうれしい。帳簿つけづらいので…

オフライン会場

  • かなりうるさかった。
    • 人がまばらで他のスペースの会話が遮られず聞こえてくるのと、天井が低いから反響するのか、ずっと人の話し声がうるさく聞こえていた。また、マスク越しということもあるのか、話しかけられてもあんまりよく聞き取れないし、そもそも話しかけられても自分宛かどうかわからず気づけないことがあった。扱うのが技術書ということもあり会話が発生しやすいので、ちょっと辛い。
  • 感染対策で入場者を制限してるからかずっと人がまばらな感じだった。空いてるからゆっくり回れるとも言える。
  • スペースが広い。コミケの倍の広さ。コミケ感覚だとスペースが余るので、展示方法を工夫する必要がありそう。
  • サークルには「かんたん後払い」用の2次元バーコードの印刷された紙が置かれていたのだが、事前に画像を登録しておくとその紙に一緒に印刷してくれるということだったらしい。知らなかったので緑ベタになってた。
  • アプリ支払と現金支払いは4:1くらいだった。
    • もしかして498円とか半端な金額にしても成り立つ可能性あるな!?(現金派の人から嫌がられそう)

ZawgyiとUnicode: ミャンマーの文字の電子化について

まえがき

ミャンマーでは公用語としてビルマ語が使われている。ビルマ語の表記にはビルマ文字を用いるのだが、このビルマ文字のインターネット上での使用は、混迷を極めていた。そしておそらく今もまだ…。なぜか?

それは、Unicodeという文字コードの標準がありながら、Zawgyiというものが広く使われていたためである。なぜそのようなものが登場し、普及することとなったのか、この記事で解説する。

凡例

この記事で使う名称について

ミャンマーという国は、1989年に公式の英語名称でBurmaではなくMyanmarという語を使うように変更した。BurmaとMyanmarはどちらもビルマ族の自称(バマーဗမာとミャマーမြန်မာ)に由来するもので、それぞれ口語体と文語体のものであり、いずれも普通に使われている。

この記事では便宜的に、「ミャンマー」という国の主要な民族である「ビルマ族」の言語を「ビルマ語」と表記し、ビルマ語表記のための文字を「ビルマ文字」とする。
また、ビルマ語以外のミャンマーの諸言語(シャン語、カレン語など)もビルマ語と近い文字を使うが、これらのミャンマー(および近隣)の言語を表記する文字を総称して「ミャンマー文字」と称することにする。

参考: ミャンマーの国名 - Wikipedia

ビルマ語表記

この記事でビルマ文字をテキスト表記する場合、現行のUnicode (2023/12/17現在、バージョン15.1)に従う。

コードポイント

コードポイントは16進数4桁で示す。Unicodeのコードポイント(Unicodeスカラ値)はU+XXXXの形で示すことがある(XXXXには16進数が入る)。

ラテン文字表記について

基本的なラテン文字表記は加藤昌彦『ニューエクスプレスプラス ビルマ語』(白水社、2019年)の表記に倣った。また、一部発音をIPAで示した部分がある。

そのほかに、文字の名称を大文字のラテン文字で書いたものや、イタリック体で書いたものがあるが、これはUnicodeで定義された文字名の一部からとったものであり、ビルマ語での発音とは異なる*1。現地の呼称と異なる可能性もあるかもしれない。

Zawgyiの概説と歴史

Zawgyiとは

Zawgyiは、ビルマ語表記のためのフォントで、ゾージーと読む。Zawgyi font, Zawgyi-Oneなどとも書かれる。
おそらくビルマ文字ではဇော်ဂျီと書き、発音が/zɔ̀d͡ʑì/である語だと思われる。ヨガをやる人ってことらしい

Zawgyiのダウンロード

ここからZawgyiOne2008.ttfがダウンロードできる。

Zawgyi誕生・普及の経緯

この節はブログ記事Battle of the fonts | Frontier Myanmarを元にしている。

複雑なビルマ文字

ビルマ文字インド系文字の一種であり、複雑な用字系*2である。複雑な用字系とは、ある1つの文字が前後の文字に応じて様々に形を変える、文字が発音される順番に並ばない場合がある、などの要素を持つ文字体系である。

ビルマ文字Unicode

Unicodeには、1999年のバージョン3.0でビルマ文字が収録された。

Unicode以前にビルマ文字の符号化標準が作られたことはなく、そのため、それ以前はコンピューター上で扱うのは困難だったか、可能でもビルマ文字テキストデータを不特定の人とやりとりすることは不可能に近かったと思われる*3


Unicode標準に入ったため、ビルマ文字の文字列を一通りのコード列にすることは可能になったものの、Unicodeビルマ語を正しく表示するための技術は、2005年まで存在しなかった。これは、複雑な用字系を扱うための技術的困難に起因している。

一方では西欧諸国による制裁などもあり、自国で複雑な仕組みに対応するシステムを開発する能力もなかったことから、当面の間は自分の国で何とかなる仕組みでミャンマー文字をコンピュータで使えるようにしようと、暫定的な回避策が開発された。実用できない標準より、とりあえず表示はできる非標準の方がいいだろう、ということだと思われる。
これはUnicodeやコンピュータのUnicode対応が成熟するまでの繋ぎのつもりだったようだ。

回避策としてのビルマ文字フォントの登場

まず、Ko Ngwe Tun氏がMyazedi*4というビルマ文字用フォントを作り、販売した(2003年ころと思われる)。これは、Unicodeミャンマー文字ブロックにビルマ文字を収録していたが、一つの文字に形状のバリエーションがある場合、それらを別々のコードポイントに割り付けていた。部分的にはUnicodeと共通している部分はあるが、互換性はない。

非標準ではあるものの「とりあえず表示できる」フォントの最初期の実装であったが、プロプライエタリであり高額(ユーザーライセンスがUS$100、コンテンツを作る会社にはUS$1,000)だったため、広くは普及しなかった。


Zawgyi-One(あるいは単にZawgyi)フォントは2006年にフリーウェアとして登場した。Myazediをパクったとみられ、最初のバージョンにはKo Ngwe Tun氏の著作権表記の一部がそのまま含まれていたらしい。無料であることから、だんだんMyadeziを置き換えつつ、一般に普及していった。


ある時、Ko Ngwe Tun氏の会社が、Myazediの海賊版フォント(= Zawgyi)を使用した会社やZawgyiの開発者たちを訴えると発表した。これを受けて、Zawgyiの開発者たちはパクリだとみなされないように改変を加え、Myazediとの互換性をなくすとともに、Unicode標準からさらに離れることとなった。


その間Unicode方面はどうなっていたかというと、2005年にWindows XPUnicodeビルマ文字の表示が可能になってからは、Unicodeフォントが作成された。だが完全なものではなく、扱うのに技術的な知識が必要だったりしたため、Unicodeは普及しなかった。また、2008年のUnicode 5.1で後方互換性のない大きな変更がなされるまでミャンマー文字ブロックは大幅な見直しが行われていて、エンコードが安定していなかった*5

Zawgyiの普及

その後のZawgyiのリリースにおいて、一般ユーザーにはインストールは簡単だが、アンインストールが困難な形態のものが登場した。例えば、Arialフォントを書き換えたり、アンインストール方法のないInternet Explorerプラグインとして提供されるなど。

ネット上のほとんどがZawgyiによって書かれているものとなったため、新しくコンピュータを買った人はZawgyiをインストールしたし、 一般に売られるスマホも、最初からZawgyiがインストールされた状態で提供された。

このように、事実上の標準となったZawgyiにロックインされてしまい、Unicodeへの移行は困難になっていた。

2019年に国が正式にUnicodeに切り替えるぞ!と言うまでは広く広く使われていた。それからはだんだんUnicodeが普及しているらしい。

Zawgyiの実装

Zawgyiは、Unicodeのインド系文字で使われている複雑なレンダリングの仕組みを回避するものであるため、実装は単純である。

子音字・独立した母音字などはUnicodeと共通している。Unicode 5.0以前に存在していたビルマ文字については、同じ文字が当てられているように見える。そのほかに、下に重ねて書く子音字や、記号類のバリエーション、合字などが追加されている。

Zawgyiのコード表

上図がコード表であるが、白色部分がUnicode 5.0以前と共通の文字であり、黄色部分はZawgyiで独自で割り当てた文字である。

実装の方針

文字の並べ替えをせず、左から右に書く

Unicodeでは、できるだけ発音順に文字をデータとして収録する方針をとっており、そのため表示する際に文字を並べ替える必要がある。

Zawgyiでは、並び変えの必要をなくし、左から順番に並べていくだけである。

次図に「秀麗な」という語のZawgyiとUnicodeでの表現の比較を示す。Zawgyiでは見た通りに文字が並べられ、Unicodeでは発音する順に並べられているのがわかると思う。

ビルマ語単語例のZawgyiとUnicodeの比較
文字の形のバリエーションに対して、別々のコードポイントを割り付ける

Unicodeでは、一つの文字が前後の文字によって様々に形を変える場合、その文字のバリエーション一つ一つに別々のコードポイントをあてることはせず、一つのコードポイントの文字を、プログラムやフォントの機能を使って形を替えることで対応するのを基本としている。

Zawgyiでは、文字の形のバリエーションや合字に対して、すべて別々のコードポイントを割り付けている。これにより、前後の文字に応じて文字の形を変更する必要がなくなり、プログラムやフォントの変形への対応が不要になる。

Zawgyiのもつ8種類の介子音記号ra

顕著な例としては、介子音記号のraは、子音字をぐるっと囲むような記号であるが、

  1. 幅が狭い文字に付く場合/広い文字に付く場合
  2. 上に記号が来ない/来る場合
  3. 下に記号が来ない/来る場合

の場合分けにより、8通りの形が収録されている(上図)。

特徴と欠点

結果として、Zawgyiは場当たり的なものであり、次のような特徴をもつ。

  • 表示できればいい
    • 文字コードとしては定義が不十分であり、扱いづらい。
    • まともな文字コードや実装が普及するまでの「つなぎ」のつもりで作られたため。
  • 検索や照合が非常に大変
    • 同じ文字の形状のバリエーション全てに別コードを当てている。
    • 上下につく記号など、送り幅*6を持たない文字・記号は、どの順番にするかが決まっていない。
      • Unicodeでは、順番が変わっても表示が同じになる合成記号類は、正規化(normalization)により一定の順番になるように仕様が定められている。
  • ミャンマービルマ語以外の言語向けの文字のために確保されていた当時の未定義部分(現在はすでに諸言語向け文字が収録されている)に勝手に記号類を収録しているため、そのような言語を扱う場合に困る。

参考: Zawgyi font - Wikipedia

Unicodeミャンマー文字の実装

さて、Unicodeの複雑さを回避するためにZawgyiが出てきたことを考慮すると、なぜZawgyiが普及するに至ったかを考えるのには、Unicodeによる符号化がどんなであるかを見ていく必要があるだろう。

Unicode登場まで

Unicodeは、それまでに存在していたテキストエンコーディングを置き換えることを意図して作られた。そして、レガシーな文字コードとの相互運用性を重視していることから、Unicode以前からある既存の文字コードの標準や、広く通用したデファクトスタンダード文字コードは尊重される。

このため、ビルマ文字文字コードが存在していれば、それに近い形でUnicodeビルマ文字が入ったはずである。

しかし実際には、Unicode以前にビルマ文字の標準的な文字コードが作られたことはなさそうで、1999年にUnicode 3.0で実装されたのが初めてのビルマ文字の符号化標準であった。
従って、デーヴァナーガリーなどの他のインド系文字の方式を参考に、新規に標準が作成されたと思われる*7

論理順

インド系文字の符号化にかかわってくるUnicodeの原則として、論理順がある。
論理順の原則というのは、かんたんに言うと、文字を、発音する通りの順番でデータとして収録するという原則である*8

例えば、インド系文字では子音字の上下左右に母音記号がつき得るのだが、子音→母音の順に発音されるのだから、母音記号が子音字の左に書かれる場合でも、データの上では子音字→母音記号の順に収録し、表示する際に母音記号が子音字の左側に来るように並べ替えるというものである。

pyèlɛ̀「うまくいく」のUnicode表現

一例として、ပြေလည် pyèlɛ̀「うまくいく」という単語を見てみると、Unicodeでは上図のようにp-y-èの順番のデータとなるが、見た目の順番では左からè-y-pの順に並んでいて、論理順と視覚順で順番が異なっている。

これにより、データの上ではきれいで、ソートなどもやりやすくなるのだが、表示するときには文字の入れ替えをしなければならない。この文字の入れ替えに関しては、テキストレンダリングエンジン……つまりテキストの表示に用いるプログラムが責任を持つ。そのため、対応していないプログラムを使った場合、正しく表示されないということになる(上図の「間違った表示」参照)。

ブラウザなどでの対応はずいぶん良くなったものの、これに対応していないソフトウェアや、設定で有効になっていなかったりして、正しく表示されないという事態は多々発生している。


話はややずれるが、ビルマ文字を手で書くときは基本的に左から右、内側から外側に書くので、上のpyèlɛ̀の例では、è-p-yの順番で書くことになる。これは論理順と異なっているが、コンピュータでの入力の際には、手で書くような順番で入力すると、インプットメソッドがUnicodeとしていい感じのコード列に変換してくれたりするようだ。

グリフでなく文字

また、Unicodeの原則として、グリフでなく文字を収録するというものがある。
ここでいう文字(character)とは、様々な形のバリエーションがあっても同じ字だと認識されるようなグループに関して、抽象化した文字を想定したものである。一方、グリフは文字の具体的な図像表現であり、文字が目で見える形になったものがグリフである。同じ字でもフォントによってデザインが違うが、それらはグリフの違いであり、文字の違いではない。

これはつまり、一つの文字は原則として1つのコードポイントに割り付け、形のバリエーションは独立して収録しないというものだ。そのため、ある文字が文字の位置や前後の文字などに依存して形が変わる場合、変形後の形はUnicodeに独立して含まれないのが原則であり、表示時にそのような別形への変換を行う必要がある。

これを実現するには、別形へと置換する情報をフォントに含めて、テキストレンダリングエンジンからその情報を参照して置き換えを行うことで可能となる。要するに、フォントとテキストを描画するプログラムの両方が対応していないと、正しく表示することができない。

インド系諸文字でこれが関わってくるのが、ヴィラーマモデルである。

ヴィラーマモデル
デーヴァナーガリーのヴィラーマの例

インド系文字は音節文字であり、子音字は基本的には母音とセットになった状態で書かれる。ヴィラーマ(virama)は、子音字につけられて、母音がないことを示す記号である*9。ヴィラーマはサンスクリット語における呼称であり、各言語によって呼ばれ方は異なるが、Unicodeでは基本的にすべてヴィラーマと呼んでいる。

ビルマ文字におけるヴィラーマはやや特殊なため、ここではインド系文字の一つであるデーヴァナーガリーを例として説明する。


デーヴァナーガリーには、ヴィラーマ記号の他に、母音をなくす表現として、半子音字と呼ばれる仕組みがある。次図に例を挙げる。これは子音字の一部を欠いたものであり、次の子音と連続して、子音連結として発音される場合に用いられる。

デーヴァナーガリーの半子音字の例

Unicodeでは、この半子音字に独立したコードポイントを当てるのではなく、子音字+ヴィラーマの組み合わせで表現する。このように、子音字のバリエーションなどをヴィラーマを組み合わせることで表現するのがヴィラーマモデルである。

すべての子音字について対応する半子音字が存在するわけではなく、子音の組み合わせによっては縦に重なったり特別な合字で表されるものもあるが、次図のように同様にヴィラーマを利用して表現される*10

ヴィラーマモデルによるデーヴァナーガリーの子音連結の表現例
ビルマ文字の場合

さて、ビルマ文字の場合を見てみよう。

ビルマ文字asat

ビルマ文字でヴィラーマに相当する記号はasat (အသတ် /ʔat̪aʔ/ アタッ)である(上図)。しかし、これは母音・末子音・声調などを表すために他の文字と組み合わせて書かれ、母音がないことを示すヴィラーマとは少し性質が異なった使い方がされている。単語の綴の中に含まれていて、後ろに文字が続くからといって書かれないということはない。

現在のUnicodeでは、asatには独立したコードポイントが与えられているが、Unicode 5.0以前ではそうではなかった。これについては次の章でも説明する。


また、ビルマ文字では縦に子音字を重ねることがある。これは主にパーリ語などのインド系言語からの借用語にのみ現れ、借用元の言語で子音連続となっている部分を上下に重ねて書く。次図に例を挙げる。

子音字を縦に積み重ねる語の例

Unicodeでは、この重ね文字は、子音字等と子音字の間にヴィラーマを挟むことで表現される。
この重ね文字については、フォントに文字の形を変えて積み重なるようにする情報を含め、表示を行うプログラムからそれに基づいて描画する必要がある。


Unicodeでのミャンマー文字の扱い方については、Unicodeが公開するFAQがあったり、UTN #11 "Representing Myanmar in Unicode"に詳細があるので、詳しくはそちらを参照されたい。


最後に、စင်္ကြံ zínjàn「歩道」とသင်္ဘော t̪ínbɔ́「船」という例を次図に挙げてこの節を終わる。データは論理順に並んでいるが、表示順からは想像できないような順番になっているのがわかると思う。

zínjàn「歩道」と t̪ínbɔ́「船」のUnicode表現

参考

Unicode 5.0.0と5.1.0の比較

ビルマ文字Unicode 5.1.0で大きな変更があってからは、互換性が壊れるような変更は行われず、安定していると思われる。この章では、バージョン5.0.0と5.1.0との間でのビルマ文字に関する差異を見ることで、Unicodeビルマ文字エンコーディングがどう変化したかを概観する。なお、ここではビルマ語以外のために追加された文字については取り上げない。

基本的な変化としては、以前はフォントによる置換で対応していた変化形の一部に独立したコードポイントが当てられ、よりプログラムやフォントの実装がやりやすくなっているように思われる。

asatへの独立したコードポイントの割り当て

5.1.0でasat (အသတ် /ʔăt̪aʔ/ アタッ)に独立したコードポイントが割り当てられた(U+103A)。それまではvirama U+1039 + ZWNJ U+200Cで表していた(Unicode Standard, Version 5.0のp.380など参照)。

例1: ကော် /kɔ̀/
Version Unicode表現
5.0.0 U+1000
ka
+ U+1031
vowel sign e
+ U+102C
vowel sign aa
+ U+1039
virama
+ U+200C
ZWNJ
5.1.0 U+1000
ka
+ U+1031
vowel sign e
+ U+102C
vowel sign aa
+ U+103A
asat
ကော်のUnicode表現の変化

virama + ZWNJでヴィラーマに相当する文字を表示するのはヴィラーマモデルでは典型的な挙動であり、デーヴァナーガリーなどではそうなっている。ただし、ミャンマー文字asatは次に子音字が後続しようが常に表示されるものであり、母音や末子音や声調などを表すために非常に頻繁に用いられる。そのため、これが1つのコードポイントだけで表現できるようになったことで、かなりの効率化が図れたと思われる。

例2: င်္ဂ (「イギリス人」အင်္ဂလိက် /ʔíɴgăleiʔ/の一部など)
Version Unicode表現
5.0.0 U+1004
nga
+ U+1039
virama
+ U+1002
ga
5.1.0 U+1004
nga
+ U+103A
asat
+ U+1039
virama
+ U+1002
ga
င်္ဂのUnicode表現の変化

asatに独立したコードポイントが割り当てられた結果、この例に関してはコードの数が増えている(上に乗るင်をkinziというらしい*11)。

介子音記号への独立したコードポイントの割り当て

介子音記号は、「virama + 子音字」の組合せから、個別のコードポイントが割り当てられるようになった。

文字 Unicode 5.0.0表現 Unicode 5.1.0表現
介子音記号ya U+1039
virama
+ U+101A
ya
U+103B
medial ya
介子音記号ra U+1039
virama
+ U+101B
ra
U+103C
medial ra
介子音記号wa U+1039
virama
+ U+101D
wa
U+103D
medial wa
介子音記号ha U+1039
virama
+ U+101F
ha
U+103E
medial ha
介子音記号のUnicode表現の変化

これにより、形状の置換を減らせるのでフォントの実装がシンプルになるとともに、入力する側としてもより直観的なデータ表現になったと思われる。

縦長のaaへの独立したコードポイントの割り当て

ビルマ語では、縦長のaaは、普通の丸いaa ( ာ U+102C)が来ると紛らわしくなる場合に用いられる(例: ပါ /pà/ ↔ဟ /h/を表す子音字)。
aa (長母音a; ာ U+102C)の縦長版は直前の文字に応じてフォントで形を変えることになっていたが、独立したコードポイントが割り当てられた( ါ U+102B)。

縦長のaaのUnicode表現の変化

これについては、スゴー・カレン語(S'gaw Karen)の正書法においては縦長の形しか用いられないため、それへの対応として分離されたようだ(Unicode 5.1.0のミャンマー文字の節参照)。

とはいえ、ビルマ語で使い分けがどのようにされているのかは自明ではないかもしれない。ミャンマーで出版されたあるビルマ語辞書のဓ dhaの項目を見たところ、次にaaが来てဓာとなるものと、tall aaが来てဓါとなるものとが並んでいた(次掲の写真参照)。

ဦးကျော်နိုင်編『ビルマ語辞典မြန်မာ-ဂျပန် အဘိဓာန်』(နဒီမင်္ဂလာစာပေ 2004) p.221

単に好みで形を選んでいるのか、何らかの区別を行っているのかは、私は知識がないのでわからないが…。この辞書を文字の形をそのまま電子化するには、古い方式では難しかったかもしれない。

aforementionedの扱いの変更

U+104E aforementionedの扱いが変更された。
以前はU+104E単独で၎င်း lăgáuɴという語全体を表していたが、5.1.0ではlăgáuɴの最初の部分၎だけになった。

この字は၎င်း lăgáuɴという語にしか使用されない*12ものの、lăgáuɴの別表記で、င်္၎ (င်が၎の上につく)という形に対応するためにこうなったらしい(UTN #11 v4のp.11参照)。

これにより、lăgáuɴのエンコーディングが次のように変更になった。

Version Unicode表現
5.0.0 U+104E aforementioned
5.1.0 U+104E aforementioned + U+1004 nga + U+103A asat + U+1038 visarga
U+104E aforementionedの変更

great saへの独立したコードポイントの割り当て

U+101E saが2つ重なる時は、great sa ဿという特別な形が使われるのだが、これに独立したコードポイントが割り当てられた。

Version Unicode表現
5.0.0 U+101E sa + U+1039 virama + U+101E sa
5.1.0 U+103F great sa

これに並行して、古いシーケンスはသ saが規則通り縦に重なる形に変更になっている: သ္သ

great saUnicode表現の変更

参考

Zawgyi/Unicode判定・変換プログラムについて

Facebookなどでは、Zawgyi/Unicodeを自動判定し、ユーザーの環境に応じて変換しているらしい(参考: ミャンマー語(ビルマ語)のフォントがZawgyiからUnicodeへ大改革 - Enjoy Yangon ヤンゴン, ミャンマーで暮らす旅する)。


Zawgyi/Unicodeの判定、および変換をするプログラムやライブラリは複数ある。
一例をあげると、Googleが公開している次のものがある。

このプログラムでは機械学習を用いて判定を行っている。理由としては、人の手でルールを記述することでZawgyi/Unicode判定を行う場合では、本来のUnicodeでシャン語やモン語などが書かれている場合を誤判定してしまうことがあるためだとしている。

つまり、ビルマ語だけを判定するのでよければ、人の手でルールを記述すれば十分な精度が得られることはあるようである。母音の並び順、Unicodeビルマ文字以外の符号位置の利用などを見るだけでも、十分な長さがあればそれなりの精度で判定はできそうだ。とはいえ判定ルーチンを自分で書くことはまずないと思う。

また、変換に関しては変換ルールを書いていけばいいのだが、前に上げたzínjànやt̪ínbɔ́というような語などZawgyiとUnicode間の順番が大きく異なるのもあり、漏れなく変換ルールを書くのが難しい。

そのため、既存の実績のあるツールやライブラリを使うのがよいと思う。

まとめ

Unicodeに収録されたミャンマー文字をコンピュータで正しく表示することが困難だったために、その表示上の複雑さを回避するZawgyiフォントが作られ、それがデファクトスタンダードとしてミャンマーで広まってしまった。そのため、グローバルスタンダードであるUnicodeへの移行が困難になっていた。

この先Unicodeが普及していくにしろ、過去の資産としてZawgyiで書かれたテキストデータが大量に存在するため、これを無視することができない。判別プログラムを使って判定し、必要に応じて変換を行うことが肝要だろう。

*1:おそらくUnicodeの文字名はビルマ文字ラテン文字転写に由来するものと思われるが、ミャンマーで公式に採用されているラテン文字転写はパーリ語向けのものを元に作られているようで、ビルマ語の音韻構造を表してはいない。そのため、ある程度文字の区別が可能である一方で、転写から発音を想像することが困難になっている。参考: MLC Transcription System - Wikipedia

*2:Complex script. 「用字系」はscriptの訳で、文字の体系のことを示している。scriptは単に「文字」と訳されることがある(例: ビルマ文字/Burmese script)が、個々の文字(letter)と区別するために用字系と訳されていると思われる。

*3:8ビットコードの範囲内(ASCIIや、Latin-1の範囲)にビルマ文字を割り当てたフォントが使われていたらしい。ただし、フォント毎に文字の配列が異なるので、フォントを変えると文字化けしたとのこと。参照: ビルマ語(ミャンマー語)をWindowsで~Unicode以前 | エヤワディ Blog

*4:Myazediという名は、1112年に刻まれたとされるミャゼーディー碑文に由来するものかもしれない。これは現在知られている限りビルマ語最古の碑文であり、パーリ語、ピュー語、モン語、ビルマ語の4言語で碑文が刻まれているため、ミャンマーロゼッタストーンとも呼ばれる。参考: ミャゼディ碑文 - Wikipedia

*5:Unicodeミャンマー文字がほとんど使われてなかったから互換性のない変更を行うことが可能だったわけで、エンコードが安定していないのが普及しない原因だった訳ではなさそうだ。

*6:advance width. 次の文字を表示する位置がこれだけ進行方向前方にズレる、という幅。

*7:インドの諸文字やスリランカシンハラ文字、タイのタイ文字などはそれぞれの国によって文字コード標準が作成されていて、それをもとにUnicodeへと収録されたようだ。ミャンマー文字は、仕組みが似ていて当時標準が存在していなかったクメール文字とセットで、新規にUnicode標準策定が行われたようである。

*8:原則というのだから例外があり、例えばタイ文字なんかは論理順でなく表示順で左から右に並べるものになっている。これは、Unicode策定時にTIS-620というタイ語文字コード標準が存在していたため、それがそのままに近い形でUnicodeに入ったということのようだ。

*9:ヴィラーマは無母音記号だと説明したものの、どちらかというと母音をなくす概念の名前かもしれない。サンスクリット語に関する知識がないので詳しくはわからないが…。参照: Virama - Wikipedia

*10:サンスクリット語ヒンディー語など、言語によって子音の組み合わせに対する合字の形や使い方が異なるため、フォントは言語毎に別の設定を行う必要があるようだ。参考: 『電脳社会の日本語』:ほら貝

*11:kinziは最初入力方法がわからなかった。独立したキーを当てるとかしないと初見では入力無理なのでは…。

*12:၎ U+104Eのこの形は元々はビルマ数字の4 “၄”に由来するが、これは数字の4の発音とlăgáuɴの最初の発音が当時同じだったために、最初の部分を数字の4で代用した略記がなされ、広まったとのこと。発想は英語スラングの2nite (= tonight), 4get (= forget)とかに近いようだ。参考: ၎င်း - Wiktionary, the free dictionary

Pleromaサーバーお引越し

引っ越しました。

環境

作業内容

VPS作成とOSインストール

さくらインターネットVPSでOS (Ubuntu 22.04)をインストール、公開鍵を登録

ログイン

ローカルからログイン

ssh ubuntu@NEW_SERVER_IP

更新・ユーザ追加

新サーバ

更新

sudo apt update
sudo apt upgrade

ユーザ追加

sudo adduser nixeneko
sudo gpasswd -a nixeneko sudo

authorized_keysを移行する

sudo mkdir /home/nixeneko/.ssh/
sudo cp ~/.ssh/authorized_keys ../nixeneko/.ssh/
sudo chown -R nixeneko:nixeneko /home/nixeneko/.ssh
sudo -Hu nixeneko chmod 700 /home/nixeneko/.ssh

所有者をnixenekoに、.sshパーミッションが700、authorized_keysのパーミッションが600になっているのを確認

再起動

sudo reboot now
ローカル

再度ログイン

ssh nixeneko@NEW_SERVER_IP
新サーバー

デフォルトユーザの削除

sudo userdel -r ubuntu

ssh設定

新サーバー

ssh設定する

sudo nano /etc/ssh/sshd_config

変更点は次のあたり。

Port 10022

LoginGraceTime 30
PermitRootLogin no

MaxAuthTries 3
MaxSessions 4

PasswordAuthentication no

保存。

その後、sshdを再起動

sudo sshd -t
sudo service sshd restart

ログアウトする。

さくらインターネットVPSコントロールパネル

パケットフィルターの設定から、SSHを削除、Webとカスタム(TCP 10022)を追加して保存

ローカル

再度ログイン

ssh -p 10022 nixeneko@NEW_SERVER_IP

ファイアウォール設定

新サーバ

さくらインターネットのシステムでもやってるのでこれはやらなくてもいい。

sudo ufw allow 80
sudo ufw allow 443
sudo ufw limit 10022/tcp
sudo ufw enable
sudo ufw status

次のように表示される。

Status: active

To                         Action      From
--                         ------      ----
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
10022/tcp                   LIMIT       Anywhere
80 (v6)                    ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
10022/tcp (v6)              LIMIT       Anywhere (v6)

Pleromaインストール

Installing on Debian Based Distributions - Pleroma Documentation

新サーバ

必要なもののインストール

sudo apt install build-essential postgresql postgresql-contrib cmake libmagic-dev
sudo apt install elixir erlang-dev erlang-nox
sudo apt install imagemagick ffmpeg libimage-exiftool-perl
sudo apt install nginx certbot

ユーザー作成

sudo useradd -r -s /bin/false -m -d /var/lib/pleroma -U pleroma

Pleromaを導入(これに関して、旧サーバから/opt/pleromaをそのまま持ってきてもいいのだが、今回はやめた)

sudo mkdir -p /opt/pleroma
sudo chown -R pleroma:pleroma /opt/pleroma
sudo -Hu pleroma git clone -b stable https://git.pleroma.social/pleroma/pleroma /opt/pleroma
cd /opt/pleroma
sudo -Hu pleroma git checkout v2.6.0
sudo -Hu pleroma mix deps.get

hexをインストールするかについて: y

sudo -Hu pleroma MIX_ENV=prod mix pleroma.instance gen

rebar3をインストールするかについて: y
その後、インスタンスに関する質問がなされるので、旧サーバのconfig/prod.secret.exsに合わせて入力する。

設定ファイルを移動・編集

sudo -Hu pleroma mv config/generated_config.exs config/prod.secret.exs
sudo -Hu pleroma nano config/prod.secret.exs

旧サーバの設定ファイルにあわせて変更する。

SSHFSでつなぐ

旧サーバに十分なスペースがないのでSSHFSで新サーバにデータを出力できるようにする。
sshfsで別サーバのディレクトリをマウントする | server-memo.net

新サーバ

旧サーバのユーザの公開鍵を新サーバのユーザのauthorized_keysに追加。

ディレクトリ作成

mkdir /home/nixeneko/share
chmod 777 /home/nixeneko/share
旧サーバ

旧サーバから新サーバにsshfsで繋ぐ。

ディレクトリ作成

mkdir remote

設定変更

sudo nano /etc/fuse.conf

次の行をコメント解除して保存する。

user_allow_other

sshfsで接続

sudo apt install sshfs
sshfs nixeneko@NEW_SERVER_IP:/home/nixeneko/share /home/nixeneko/remote -p 10022 -o allow_other

バックアップとデータコピー

旧サーバ

データベースのバックアップと、様々なデータをコピーする。

sudo service pleroma stop
sudo -Hu postgres pg_dump -d pleroma_dev -v --format=plain -f /home/nixeneko/remote/pleroma_dev.sql
sudo tar zvcf /home/nixeneko/remote/letsencrypt.tar.gz /etc/letsencrypt
sudo cp /etc/nginx/sites-available/pleroma.nginx /home/nixeneko/remote/pleroma.nginx
sudo tar zvcf /home/nixeneko/remote/pleroma_bak.tar.gz /opt/pleroma #これは念のため
sudo tar zvcf /home/nixeneko/remote/pleromadata.tar.gz /opt/pleroma/uploads /opt/pleroma/instance/static
新サーバ

もしすでにデータベースを作成している場合は削除する。していない場合はこれは実行しない。

sudo -Hu postgres psql -c 'DROP DATABASE pleroma_dev;'
sudo -Hu postgres psql -c 'DROP USER pleroma'

データベース作成

sudo -Hu postgres psql -f /opt/pleroma/config/setup_db.psql

データベースのバックアップファイルを編集
PleromaのサーバーをUbuntu 20.04→22.04に移行する際、データベースのマイグレーションでこける - にせねこメモ
普通にデータベースをリストアしようとするとCREATE INDEX activities_visibility_indexという部分で止まるので、そこだけコメントアウトして実行する。

cat /home/nixeneko/share/pleroma_dev.sql  | grep -n activities_visibility_index

次のように表示される。

6409126:CREATE INDEX activities_visibility_index ON public.activities USING btree (public.activity_visibility(actor, recipients, data), id DESC NULLS LAST) WHERE ((data ->> 'type'::text) = 'Create'::text);

行数が6409126だと分かったので、その行だけコメントアウトする。

sed -e "6409126s/^/-- /g" /home/nixeneko/share/pleroma_dev.sql  > /home/nixeneko/share/pleroma_dev.20231209.replaced.sql
chmod 755 ~     #750になっててpermission denied出たので変更
sudo -Hu postgres psql -a -d pleroma_dev -f /home/nixeneko/share/pleroma_dev.20231209.replaced.sql
sudo -Hu postgres psql -d pleroma_dev -c "CREATE INDEX activities_visibility_index ON public.activities USING btree (public.activity_visibility(actor, recipients, data), id DESC NULLS LAST) WHERE ((data ->> 'type'::text) = 'Create'::text);"

設定・データの復元

新サーバ

Nginx

sudo cp /home/nixeneko/share/pleroma.nginx /etc/nginx/sites-available/
sudo ln -s /etc/nginx/sites-available/pleroma.nginx /etc/nginx/sites-enabled/pleroma.nginx

Letsencrypt

sudo tar zxvf /home/nixeneko/share/letsencrypt.tar.gz -C /

Pleromaデータ

sudo tar xvzf /home/nixeneko/share/pleromadata.tar.gz -C /

Nginxの有効化

新サーバ
sudo nginx -t
sudo systemctl enable --now nginx.service
sudo systemctl restart nginx.service

Pleromaの有効化

新サーバ

データベースのマイグレーション(することがないのを確認)、VACCUM ANALYZEの実行、試しに動くのを確認。

sudo -Hu pleroma MIX_ENV=prod mix ecto.migrate
sudo -Hu pleroma MIX_ENV=prod mix pleroma.database vacuum analyze
sudo -Hu pleroma MIX_ENV=prod mix phx.server

動くのを確認してCtrl-C aで終了
ここで、/etc/hostsドメインから新サーバのIPが引けるようにしたマシンを用意して、そこでドメインにアクセスしてみて普通に使えるのを確認するとよさそう。

Pleromaサービスのインストール

sudo cp /opt/pleroma/installation/pleroma.service /etc/systemd/system/pleroma.service
sudo systemctl enable --now pleroma.service

その後、ドメインのネームサーバでDNSレコードを編集し、ドメインのIPを新サーバに振り向ける。

Swapfile追加

使ってたらメモリが足りなくて安定動作してないっぽかったのでswapfileを追加した。
swapfileの追加 — さくらの VPS マニュアル

新サーバ

Swapfile追加

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

起動時にswapfileが読み込まれるように設定

sudo cp -p /etc/fstab /etc/fstab.orig-20231209
sudo nano /etc/fstab

次の行を追記して保存。

/swapfile none swap sw 0 0

再起動し、swapが有効になっているのを確認(topコマンド等)

IPv6有効化

さくらのVPSではデフォルトでIPv6が無効になっているらしいので有効にする。
IPv6有効化手順(Ubuntu 22.04) — さくらの VPS マニュアル

cat /etc/netplan/01-netcfg.yaml

IPv6が無効になってるのを確認。

/etc/netplan/01-netcfg.yamlを編集して、

sudo nano /etc/netplan/01-netcfg.yaml

IPv6に関するコメントアウトを解除して保存。

OSを再起動する。

sudo reboot

PleromaのサーバーをUbuntu 20.04→22.04に移行する際、データベースのマイグレーションでこける

問題

PleromaのサーバーをUbuntu 20.04からUbuntu 22.04へと移行しようと思ったが、PostgreSQLのデータベースのバックアップからリストアするところで止まってしまって、うまく行かなかった。

環境

  • Pleromaのバージョン: v2.6.0
  • 元サーバ
  • 移行先サーバ

試行1: 公式サイトの手順通りに

Pleromaの公式サイトにバックアップとリストアの手順がかかれている。

最初はこれに従ってやってみた。
データベース名はpleroma_devとする。


まず、移行先の新サーバでPleromaをセットアップを行い、データベースを作成するところまでやった。

sudo -Hu postgres psql -f /opt/pleroma/config/setup_db.psql


旧サーバーでデータベースをバックアップした)。

sudo service pleroma stop
sudo -Hu postgres pg_dump -d pleroma_dev -v --format=custom -f /home/nixeneko/share/pleroma_dev.pgdump


新サーバーにバックアップデータを移動した後、データベースをリストアした。

sudo -Hu postgres pg_restore -d pleroma_dev -v -1 /home/nixeneko/share/pleroma_dev.pgdump

このコマンドは、しばらくは動いていたが、

pg_restore: creating INDEX "public.activities_visibility_index"

と出たまま動かなくなり、1時間たっても変わらなかったので、強制終了することになった。

試行2: SQLプレーンテキストでバックアップ

--format=customではだめなのかもしれないので、--format=plainでバックアップしてリストアを行うことにした。


元サーバーでバックアップする。

sudo -Hu postgres pg_dump -d pleroma_dev -v --format=plain -f /home/nixeneko/share/pleroma_dev.sql


新サーバーでレストアを行う(すでにデータベースを作成していたので消してから再度作成している)。

sudo -Hu postgres psql -c 'DROP DATABASE pleroma_dev;'
sudo -Hu postgres psql -c 'DROP USER pleroma'
sudo -Hu postgres psql -f /opt/pleroma/config/setup_db.psql
sudo -Hu postgres psql -a -d pleroma_dev -f /home/nixeneko/share/pleroma_dev.sql

すると、

CREATE INDEX activities_visibility_index ON public.activities USING btree (public.activity_visibility(actor, recipients, data), id DESC NULLS LAST) WHERE ((data ->> 'type'::text) = 'Create'::text);

とか表示されたまま動かなくなってしまった。そのため今回も強制終了した。

助けてインターネット

ネットを探したら同じところで引っかかっている人がいた。

この記事によると、SQL文の書かれたファイルの中で、実行時に引っかかっているCREATE INDEX activities_visibility_indexと書かれた行だけをコメントアウトして実行する。その後で、コメントアウトした部分のSQL文を個別に実行するとうまく行ったとのことである。

解決策

そのようにやってみる。


旧サーバでバックアップ

sudo service pleroma stop
sudo -Hu postgres pg_dump -d pleroma_dev -v --format=plain -f /home/nixeneko/share/pleroma_dev.sql


新サーバーへバックアップファイルを移動し、編集する。pleroma_dev.sqlnanoで開いて編集しようとしたら、killedされてしまった。6GB近くあるファイルをnanoで編集するのはできないようだ(メモリ1GBだし…)。

仕方ないので、コマンドを使って編集することになる。まず、

cat pleroma_dev.sql  | grep -n activities_visibility_index

で行数を特定。今回は6377738行目だと判明したので、sedを使ってその行のコメントアウトを行う(行頭に--をつける)。

sed -e "6377738s/^/-- /g" pleroma_dev.sql  > pleroma_dev_replaced.sql


次に、置換した結果を使ってデータベースをリストアする。

sudo -Hu postgres psql -c 'DROP DATABASE pleroma_dev;'
sudo -Hu postgres psql -c 'DROP USER pleroma'
sudo -Hu postgres psql -f config/setup_db.psql
sudo -Hu postgres psql -a -d pleroma_dev -f /home/nixeneko/share/pleroma_dev_replaced.sql


その後、コメントアウトした行のSQL文だけ個別に実行する。

sudo -Hu postgres psql -d pleroma_dev -c "CREATE INDEX activities_visibility_index ON public.activities USING btree (public.activity_visibility(actor, recipients, data), id DESC NULLS LAST) WHERE ((data ->> 'type'::text) = 'Create'::text);"


これでデータベースが移行できたようだ。

『はじめてのNostr』サポートページ

技術書典14で発行した『はじめてのNostr』サポートページです。
techbookfest.org


本に関してなにか追加の事項があった場合、ここに記載します。

もしなにか間違いや注意したほうがいい点がありましたら、本誌に記載の連絡先や、この記事のコメント欄、各種SNSなどで教えていただけると助かります。

ライセンスについて

紙書籍にライセンス表記を入れる時間的余裕がなかったので、ライセンス表記がないですが、ライセンスは電子版に準じて、CC BY-SA扱いでお願いします。

Pleromaでadmin-feを使う

Admin-fe使ったことなかったけど使う必要が生じたのでメモ
Pleroma自体の設定を変更することは考えてなくて、ユーザーや投稿のモデレーションができればよかったので、フルで使えてるのかはわからない。


環境

Pleroma 2.5.0(ソースからインストール)

手順

ユーザーにadmin権限を付す

自分をadminに設定してなかったので設定する。

ユーザーの名前(nickname)をfoobarとする。

cd /opt/pleroma
sudo service pleroma stop
sudo -Hu pleroma MIX_ENV=prod mix pleroma.user set foobar --admin

admin-feから設定を変更可能にする

config/prod.secret.exsを編集する:

sudo -Hu pleroma nano config/prod.secret.exs

ここで、

config :pleroma, configurable_from_database: true

に変更(falsetrueにする)。

設定をデータベースへマイグレーション

sudo -Hu pleroma mix pleroma.config migrate_to_db

ここで

Migration is not allowed until all deprecation warnings have been resolved.

というメッセージが出たので、マイグレーションが動いてるかどうかがはっきりしない。
まあ動いてるからいいか…

起動

sudo service pleroma start

使い方

adminユーザでpleroma-FEにログインすると、右上にadmin-FEへのリンクされたアイコンが表示される。
URLでいくと、instanceのドメイン/pleroma/admin/にアクセスするといいっぽい。