### 課題 ソートの順番は言語ごとに異なる。 そのため、様々な言語を扱う際は、言語（＝ロケール）を指定してソートをしたい*1。 ### 解決手法 PyICUを利用する。これはICU C++ライブラリのPythonラッパーである。 #### 利点 実績のあるUnicodeライブラリであるICUを利用するので、比較的良い結果が得られる。 #### 欠点 インストールが大変で、動作も重い。頻繁に実行する用途には向かないかもしれない。 ### 使い方 インストール方法は次を参照。 * https://pypi.org/project/pyicu/ #### コード例 import icu collator = icu.Collator.createInstance(icu.Locale("si_LK")) result = sorted(["ලංකාව", "භාෂාව", "ලංකා තේ"], key=collator.getSortKey) print(result) 結果 ['භාෂාව', 'ලංකා තේ', 'ලංකාව'] ### 参考 * Sorting list of string with specific locale in python - Stack Overflow *1:日本語を読みでソートする場合などは、ロケールを指定しただけでは不可能だが、言語やユースケースによってはロケールを指定したソートで事足りる。

オンライン辞書などのタイ語学習サービスを提供していたthai-language.comが繋がらなくなっている。 * http://www.thai-language.com/ HTTPS対応してなくてHTTPで接続する必要があったが、少し前までは見えていた。 Internet Archiveを見ると、最後に9月27日にアクセスした記録があるので、繋がらなくなったのはそれより後のはずだ。 現在は名前解決ができず、IPが引けない状態になってるっぽい。Whoisを見てみると、ネームサーバとして`ns1.blobule.com`や`ns2.blobule.com`が指定されているが、これらに繋がらなくなっている。ネームサーバ自体のIPも引けない。 ネットワークやサーバをホストしてるところがダウンしてるのかもしれない。特にこちらでできることもない気がする。 データが無事で運営者が気づいて対応してることを祈っている。

いくつかコミケとかで文字関係の解説漫画をかいて出したりしたのだが、今後のために反省点を書いていく。 なお、この反省点を生かしたからといっていいものができるとは限らない。 ### ある程度のまとまりで話を区切るべき 40ページ近くだらだら書いてたやつがすごく読みづらいと思った。 集中して読めるのは12～16ページくらいだと思う。ページ数が多すぎるなら話数を分けるべきだ。ある程度の内容のまとまりで区切りをつける必要がある。 ### 文字をコンピュータ上で入れると文章が長くなりがち フキダシなどの文字をコンピュータ上で入れると、文章が長くなる。文章が長いと漫画である必要がない。 手書き文字だと、字がそこまで小さくならないので、文字をそこまで詰め込めない。 大事なのは長い文章をだらだらと書かないことであって、それができていればコンピュータ上でフォントで文字を入れて問題ない。 どうしても解説したければ、解説コラムみたいな文章記事を別枠で設けることもできる。 ### 正確さ・網羅性にこだわり過ぎない方がよい すべてを書こうとすると分かりづらくなる。 漫画解説を読む人間がそこまで精緻なことを知りたがってるとは思えないので、エッセンスを伝えるのを重視したらいいのかなと思う。 ### 図が多い方が良い せっかくシームレスに図を入れられるので、理解を助ける図は多い方がよい。関連する絵などもあると画面に情報が増えていいと思う。 文字で解説するより、図示で解説できればそれがよいと思う。 ### 出典をどうするべきか 論文のように、主張の根拠となることについては出典を示したい気持ちがあるが、コマとかにいちいち書くと鬱陶しいかもしれない。注とかにまとめるのはありかもしれない？ 参考文献の一覧は載せるべきだと思うが、出典を書くのはどこまで細かくやるのがいいのかわからない。

以前このブログでUnicodeモンゴル文字の問題点についてまとめたが、それに関しての更新となる文書が出たのでそれについて書く。 ### L2/25-140 2025-04-23に、Unicode技術委員会文書レジストリ(UTC Document Registry)に、Unicodeモンゴル文字に関しての経過報告が登録された。 * L2/25-140 Progress report on UTN #57: Encoding and Shaping of the Mongolian Script https://www.unicode.org/L2/L2025/25140-report-utn57.pdf この文書を読んだ。 発表用スライドのようなので真意が分かりづらいところはあるが、次のような変更点や進捗報告が書かれている。 ### MVS モンゴル文字の接尾辞を接続するために、Unicode 15.1以前ではNNBSP (U+202F Narrow No-Break Space)が使われていたが、2024年9月にリリースされたUnicode 16.0からは代わりにMVS (U+180E Mongolian Vowel Separator)が利用されるようになった。 MVSは母音a/eを分離して書く時に使われてきていたものだ。 > Prior to Unicode Version 16.0, U+202F NARROW NO-BREAK SPACE (NNBSP) was used to represent this small whitespace; (…). However, its role has been taken over by U+180E MONGOLIAN VOWEL SEPARATOR (MVS), which not only prevents word breaking and line breaking, but also triggers special shaping for the following separated suffix. > > https://unicode.org/versions/Unicode16.0.0/core-spec/chapter-13/#G45731 これにより、NNBSPがモンゴル文字専用でなかったことにより引き起こされていた問題が解決し得る。 例えば、属格を示す接尾辞の-yinは単語本体から空白で区切って語中形で書き始めるのだが（）、NNBSPの存在により、単語本体と接尾辞が分離されてしまって、語頭形から始まる形で表示されることがあった（）。 特に、モンゴル文字以外の文字に接尾辞が接続することもあるので（次図）、そのような場合に正しい形で表示することは困難だった。 A-yinの正しい形と誤った形 この問題が、MVSというモンゴル文字専用の符号を使うことによって改善できる見込みである。 ### UTN #57進捗報告 さて当該文書のメインとなるUTN #57の進捗状況について。 ここでいうUTN (Unicode Technical Note) #57は、モンゴル文字の符号化とシェイピングルール（ある符号に対してどの様な形状を出力するかを決定する仕組み）の曖昧性のない定義を目指しているものである。 中国が2023年に国家標準の推奨規格としてGB/T 25914-2023を発表し、現代モンゴル語表記のためのモンゴル文字（Hudum; ホダム）の明確なシェイピングルールを規定したとのこと。 この規格により、モンゴル文字をどう表示すべきかがはっきり規定されたため、モンゴル文字フォントが基準に適合しているか判断できるようになったそうだ。 この規格を元にフォント実装用のデータを生成する仕組みが制作されており、それを利用することでモンゴル文字フォントがルールに適合していることを保証し、相互運用性が担保されるようになることが期待される。 ### 文献一覧 * Kushim Jiang. L2/25-140: _Progress report on UTN #57: Encoding and Shaping of the Mongolian Script_. https://www.unicode.org/L2/L2025/25140-report-utn57.pdf * The Unicode Consortium. _TheUnicode® Standard Version 16.0 – Core Specification. 13.5 Mongolian._ https://unicode.org/versions/Unicode16.0.0/core-spec/chapter-13/

コミケ106に宅配便搬入を行ったので、自分用のメモとして書いておく。 なお、内容は変更になる可能性があるため、開催回ごとに詳細は確認し直してください。 ### どこに情報があるか * コミケットアピールに詳細が書かれている。 * コミケの回ごとに内容が異なるので、該当の最新のコミケットアピールを参照する。 * 106のコミケットアピールはこれ: * Webサイト: https://www.comiket.co.jp/info-c/C106/C106appeal.html * PDF: https://www.comiket.co.jp/info-c/C106/C106Appeal.pdf * コミケットアピール106(PDF)ではp.8に搬入の全般的な注意事項と宅配便搬入についての詳細が書かれている。 ### 流れ #### 引き渡しまで 1. 申し込み受付期間になったら、コミケットアピールの宅配便搬入のところに書かれているアドレスにアクセスする。 2. 新規登録してログインする（ログインしなくてもいけるが、変更が効かないらしい？） 3. 個人情報やサークルスペース情報、荷物のサイズと個数などを登録する。 * 家まで集荷に来てもらうことになるので、日時を選択する。夜申し込んだところ翌々日から選択できた。 4. クレジットカードなどで支払いを行う。 5. 荷物を梱包する 6. 集荷の人に引き渡す。 #### 荷物の梱包について * しっかり梱包する。 * サークル参加日ごとに異なる色の搬入物貼付用紙(B6サイズ)を、搬入物の段ボールに貼る。 * 天面と側面1ヶ所以上に貼り付ける。 * コミケットアピールのWebページにテンプレートがあるほか、 * 宅配便搬入の申し込みをした後に記入済みのものがダウンロードできる。 * Webカタログサークル側からも搬入物貼り付け用紙のPDFが作成できるらしい。 #### 当日 * 当日はホールの通路などに区分されてまとめて置かれているらしい。 * 次のいずれかを提示して受け取るとのこと。 1. ① Web申込完了画面のスクリーンショット 2. ② Web申込後の申込完了メール 3. ③ 佐川急便送り状の控え

### シャン語表記の文字化け YouTubeでシャン語の動画を見ていたら、タイトルが一部文字化けしていた。 YouTubeのシャン語動画のタイトルとキャプションが一部文字化けしている https://www.youtube.com/watch?v=3B-HUIr2Zt0 文字化けした表記と、Unicode表記が併記されていて、Unicode表記の方はある程度まともに表示されているようだ。 この化け方…なんとなくZawgyiを思い出すな？ ### Zawgyiについて シャン語は主に、ミャンマー東～北部・タイ北部・中国雲南省あたりにかけて話者が多くいる。タイ語に近い言語であるが、表記に使うシャン文字はビルマ文字と似ている（一部は共通の形である）。 ビルマ語表記用にはZawgyi-One (Zawgyi)というフォントがある。これはUnicode非互換なグリフを勝手に配置したもので、実装が単純なためミャンマーのビルマ語表記用として爆発的に広まった。Zawgyiに関しては以下の記事で考察した。 nixeneko.hatenablog.com しかし、Zawgyiではシャン語は表記できない。ではどうしていたのか？ Zawgyiを拡張し、シャン語向けの文字を追加すればよい。それがZawgyi-Taiであるようだ。 ### Zawgyi-Tai Zawgyi-Taiというフォントは、まさにZawgyiを拡張したような名称である。ちなみにTai (တႆး)はシャンの自称であるので、シャン版Zawgyiというような雰囲気だ。もちろんUnicode非互換である。 #### ダウンロード * https://sourceforge.net/projects/shanfont/files/ ここからダウンロードできる。 `ZawgyiTai-2013.ttf`または`Zawgyi-Tai.ttf`だと思う。ダウンロード数多いから`ZawgyiTai-2013.ttf`が一番使われているのかもしれない。 #### Zawgyi-TaiのZawgyiとの違い 基本的にはZawgyiの割り当てを変更せず、使っていない領域にシャン文字用のグリフを追加しているようだ。 ##### Myanmar文字ブロック Zawgyi-TaiのMyanmar文字ブロックへのグリフ割当て ZawgyiはMyanmarブロックを使い潰しているが、Zawgyi-Taiでは空き部分にシャン文字用の文字や記号を追加している。 ZawgyiとZawgyi-Taiで異なるのは、`0x1022`, `0x1028`, `0x1035`, `0x103E`, `0x103F`, `0x1050`-`0x1059`, `0x105B`-`0x105F`, `0x1093`, `0x1098`-`0x109D`である。 * `0x1022` ဢ はUnicode 5.1以降と共通である（U+1022 Myanmar Letter Shan A）。 * `0x1093`に関してはZawgyiで別の記号が収録されていたが、シャン数字の3に変更されている。これは数字を入れる場所が足りなかったからかもしれない。 * `0x109E`-`0x109F`に関しては、`Zawgyi-Tai.ttf`では未定義、`ZawgyiTai-2013.ttf`ではUnicodeと同じ記号が入っているようだ。 ##### チャム文字ブロック このほか、チャム文字ブロックにも文字を配置している（なんでここに？）。 Zawgyi-TaiのCham文字ブロックへのグリフ割当て `0xAA00`-`0xAA03`, `0xAA05`-`0xAA0E`, `0xAA11`-`0xAA13`, `0xAA15`-`0xAA18`, `0xAA1F`-`0xAA24`, `0xAA2C`, `0xAA2E`-`0xAA44`にシャン文字用のグリフが割り当てられている。 見ると、シャン語用の子音字・母音記号の一部や、声調記号・数字等がミャンマー文字ブロックとチャム文字ブロックに重複して割り当てられている。特に用途の区別がなさそうなものもあるので、表示できるから重複してても問題ないだろうという考えかと思う。 数字なんかは、ミャンマー文字ブロックへの割り当てでは分かれ分かれになってしまっているので、連続させて収録したかったとかかもしれない。 ### Zawgyi-Tai↔Unicodeコンバータ いくつかありそう。 * PangLong Converter https://tawngphait.github.io/plconverter/ (GitHub repository) ### Zawgyi-Taiを使ったサイトの例と他のフォント 以下のページではPanglongフォントとZawgyi-Taiフォントのインストール方法を紹介しているが、ページ全体にわたってシャン語が文字化けしている。これは、Zawgyi-Taiフォントを前提に書かれているためだと思う。 * Tai Cultures: Panglong And Zawgyi-Tai Font https://saolaofa.blogspot.com/p/zawgyi-tai-font.html このシャン語と思われる化けた文字列を前掲のコンバータで変換すると、正しい形のUnicode表現に変換できた。 Panglongフォントについては、次のURLからダウンロードできるようで、しっかりは確認していないが大体Unicode準拠であるようだ。 * https://github.com/NoerNova/Panglong_Shan_Keyboard_Windows/tree/main/shan_fonts ### シャン語のUnicode表現について ミャンマー文字のUnicode表現をどうするかについて書かれた文書である _Representing Myanmar inUnicode: Details and Examples Version 4_にシャン語に関するページがある(pp.41-45)。詳しくはそちらを参照（次掲のURLから読める）。 * Martin Hosken. _Representing Myanmar inUnicode: Details and Examples Version 4_ (UTN#11v4). https://www.unicode.org/notes/tn11/UTN11_4.pdf 一例として、長母音aaを表す ႃ U+1083 Myanmar Vowel Sign Shan Aaには、対応する脚の短い形があり、これは ၢ U+1062 Myanmar Vowel Sign Sgaw Karen Euで表すようだ。文字名はSgaw Karen語となっているが、シャン語表記にも使っている。 脚の短い形は二重母音の一部であったり、閉音節（母音の後に末子音がくる場合）で使われる。次に例を挙げる。 意味 | シャン語 | 発音 | Wiktionaryリンク ---|---|---|--- 馬 | မႃႉ | /maː˦˨ˀ/ | မႃႉ - Wiktionary ビルマ | မၢၼ်ႈ | /maːn˧˧˨/ | မၢၼ်ႈ - Wiktionary ### まとめ * Unicodeが普及する前、ネット上でのシャン文字の表記にはZawgyi-Taiフォントが使われていたようだ。 * Zawgyi-Taiフォントはビルマ語用のZawgyiフォントを拡張したものである。 * 一部チャム文字用のUnicodeブロックを使っているため、ミャンマー文字とチャム文字がごちゃ混ぜの文字列はZawgyi-Taiである可能性がある。 ### その他関連文献 * Issues in Noto Sans Myanmar for "Shan Language" · Issue #19 · notofonts/myanmar · GitHub * シャン文字のデザインについて、Noto Sans MyanmarのGitHubリポジトリに投稿されたissue。教育で使われるものや実際の印刷物などの例があり、面白いかもしれない。

最近、はてなブログのrobots.txtがAIクローラを拒否しているのを知った。次の記事を参照。 fujii-yuji.net さて、当ブログ(https://nixeneko.hatenablog.com/)のrobots.txtは次のようになっている（2025/5/1現在）。 User-agent: * Sitemap: https://nixeneko.hatenablog.com/sitemap_index.xml Disallow: /api/ Disallow: /draft/ Disallow: /preview User-agent: Mediapartners-Google Disallow: /draft/ Disallow: /preview User-agent: GPTBot Disallow: / User-agent: Google-Extended Disallow: / User-agent: Applebot-Extended Disallow: / User-agent: anthropic-ai Disallow: / User-agent: ClaudeBot Disallow: / User-agent: cohere-ai Disallow: / User-agent: PerplexityBot Disallow: / User-agent: Perplexity-ai Disallow: / User-agent: ChatGPT-User Disallow: / User-agent: OAI-SearchBot Disallow: / User-agent: CCBot Disallow: / User-agent: meta-externalagent Disallow: / 各種生成AIクローラについて、サイト全体のアクセスが拒否という状態になっているようだ。 さて、特にAIを拒否する意図もなく、むしろ積極的にデータとして与えてもらって構わないと思っているので、これはあまり望ましくない。 他のブログサービスに移行するというのも一つの手段であるが、かといって過去の記事のURLをすべて変更するというのも困りものだ。そのため、こちらの記事はそのまま置いておいて、コピーをクロールが可能な別のサイトにアップロードするというのが良いのではないかと思う。 はてなブログで有料オプションでAIクローラ除外を行わない設定ができるようになればそれが良いが。