[32] [DFN[The TECkit language]] ([DFN[[CODE[.map]]]] ファイル) は、 [CITE[TECkit]] で使われている[[文字コードの変換]]の規則を記述する[[ファイル形式]]です。 * 仕様書 [REFS[ - [11] [CITE@ja[The TECkit Language - TECkit_Language.pdf]], [TIME[2021-11-12T17:48:17.000Z]], [TIME[2025-06-28T01:26:36.997Z]] ]REFS] [1] >>11 は言語仕様というよりは利用の手引の類で、その種のものにしては細かく説明しているものの、 [[ファイル形式]]の形式と意味の規定としてみると精密さに欠けます。 [33] >>11 の他に [CITE[TECkit]] のプログラムの挙動やソースコード、 あるいは実際の [CODE[.map]] ファイルの利用事例を見て研究する必要があります。 * 公式資料 - >>11 - [10] [CITE@ja[Microsoft Word - Beyond UTR22.doc - BeyondUTR22_pdf.pdf]], [TIME[2021-07-14T15:18:35.000Z]], [TIME[2025-06-28T01:25:02.710Z]] - >>8 - [14] [CITE@en[teckit/test at master · silnrsi/teckit · GitHub]], [TIME[2025-06-28T15:25:19.000Z]] [15] >>14 申し訳程度のテスト * 概略 [48] 主に[[文字コード変換]]に使われます。 [[Unicode]] ではない従来の[[文字コード]]と [[Unicode]] との相互変換の方法を記述することができます。 [49] [[文字コードの変換]]の実装は多く存在しますが、 [CITE[TECkit]] は主に[[東欧]]から[[中東]]、[[南アジア]]にかけての地域などの[[文字]]を使う研究者に使われることが多いようです。 そうした研究者はいわゆる[[フォント依存符号化]]のような専用の[[文字コード]]体系を20世紀末から21世紀初期に使っていましたが、 欧米の商用製品が実装している[[文字コード]]体系とは違うものが多く、 当該地域の一般住民の使っていた[[文字コード]]体系とも必ずしも一致していないので、 専用の実装を必要としています。 [51] [CODE[.map]] は[[1対1]]の単純な[[写像]]だけでなく、 前後の文脈に応じた複雑な変換処理を記述できます。 記述能力は[[正則表現]]に近いですが、 無限の反復を認めないなど制限があります。 [66] [[Unicode]] 以前の[[文字コード]]と [[Unicode]] とでは[[基底文字]]と[[結合文字]]の順序が逆のことがあり ([SEE[ [[非spacing文字]] ]])、 その場合逆転させる規則が必要になります。 [67] [[印度系文字の文字コード]]と [[Unicode]] とでは[[文字]]の扱い方が大きくことなる場合がほとんどです。 従来[[文字コード]]、特に[[フォント依存符号化]]は[[8ビット符号]]用[[フォント]]の限られた字数の制約と既存の[[文字のレンダリング]]の仕組みの流用という仕組み上、 文字の素朴な見た目をそのまま順番に表現していることが多いです。 一方 [[Unicode]] は [[Unicode]] 独自の理論に整合する一貫した方法を採用しているので、 かなり複雑な組み合わせで記述することになります。 [[文字のレンダリング]]の際には [[complex script]] の処理と言われる複雑な手順で [[Unicode文字列]]を[[グリフ]]列に置換することになりますが、 おおよそこれに相当する変換処理が必要になります。 [68] [[南アジア]]の現地住民による実装などを除けば、汎用のソフトウェア ([[Webブラウザー]]等) の[[文字コードの変換]]の処理では >>67 のような複雑なものはほとんど実装事例がなく、 [CITE[TECkit]] や [CODE[.map]] の大きな特徴といえます。 ;; [69] それはつまり、欧米の商用ソフトウェアがこの地域のデータの互換性の問題を切り捨ててきたということでもあります... -*-*- [50] [CODE[.map]] では変換の一方を[[左辺]] (LHS)、他方を[[右辺]] (RHS) と呼んでいます。 順方向の変換 [CODE[>]] は左辺から右辺に、 逆方向の変換 [CODE[<]] は右辺から左辺にと行われます。 [[演算子]] [CODE[>]], [CODE[<]], [CODE[<>]] を使い分けて1つのファイルで両方向の関係を同時に記述します。 [52] [CODE[.map]] では [[Unicode]] でない[[文字コード]]を byte、 [[Unicode]] のことを Unicode や uni と呼んでいます。 [53] [CODE[.map]] は変換を多段で記述でき、 各段のことを pass と呼んでいます。 順方向では前 pass の右辺が次 pass の左辺になります。 pass の入出力は byte または unicode で4種類あり、 [CODE[byte_unicode]] (左辺 byte, 右辺 unicode)、 [CODE[unicode_byte]]、 [CODE[byte]]、 [CODE[unicode]] と呼ばれています。 [54] >>53 の他に [[NFC]] や [[NFD]] の適用を表す pass があります (必然的にそれらは unicode から unicode への変換になります)。 また、 [CODE[LHSFlags]] や [CODE[RHSFlags]] に [CODE[ExpectsNFC]], [CODE[ExpectsNFD]] という値があり、入力が [[NFC]], [[NFD]] であることを期待する指定ができます。 [CODE[.map]] の処理の前段階として適用することになります。 ;; [55] [CODE[LHSFlags]] や [CODE[RHSFlags]] には [CODE[GenratesNFC]], [CODE[GeneratesNFD]] という値もありますが、どちらかというと処理の指定ではなく処理結果を表明するもののようです (保証するわけではありません)。 ;; [56] [[NFC]] / [[NFD]] は破壊的な操作なので ([SEE[ [[Unicode正規化]] ]])、 通常は利用を躊躇されるべきものですが、 [[文字コードの変換]]というのが本質的にそれ以上に破壊的で危険な操作ですし、 対象となる[[文字コード]]の性質をよく理解した者が [CODE[.map]] を書く分には使っても構わないのでしょう。 適切に使えば[[写像]]を単純化できます ([[Unicode]] に[[合成済文字]]が多い[[ラテン文字]]で特に有用そうです)。 [57] pass が明示されていないと、全体が [CODE[byte_unicode]] の1つの pass になります。 [58] pass の数や種類には制限がないようです。 ただし前段の出力と後段の入力が矛盾するものは認められません。 多段化することで複雑な変換を単純に書けることもある一方で、 全体の入力と出力の関係性が非常にわかりにくくなります。 [59] すべての pass を組み合わせた全体としては byte から unicode となるものが多いですが、 そうでないものもあります。 -*-*- [60] 変換の両辺は byte や unicode の文字1つと一致することもあれば、 いくつかの文字の列と一致することもあります。 空に置換される (削除される) こともあります。 [62] 変換の両辺には一致部分の他に、直前の条件や直後の条件やその両方を書くこともできます。 [63] 一致や条件は反復数を指定することもできます。ただし15個までに制限されていて、 無限の連続は指定できません。 [64] 条件には文字の他に境界を表す [CODE[#]] も指定できます。 [61] 変換の規則は何個でも書くことができます。 複数の規則に一致する場合は、一致部分 (前後の条件も含む。) の文字数が長いものが優先されます。 同数なら [CODE[.map]] の先のものが優先されます。 ([CODE[.map]] に記述した要素数ではなく一致した文字数です。) [65] >>61 のために [CODE[.map]] の解析は一見して感じられるものよりかなり複雑になります。 単純に変換処理をしたいだけなら上から順にすべて処理して選べばいいだけですが、 変換表の性質を理解したいときは前後の条件や[[文字クラス]]や反復が相互にどう作用するのか見極める必要が出てきます。 * 実利用例 - [8] [CITE@en[GitHub - silnrsi/wsresources: A catch bag of writing system resource files organised by writing system tag]], [TIME[2025-06-28T01:16:23.000Z]] -- [109] [[MITライセンス]] [2] >>8 から - [3] [CODE[regions/Asia/PH/legacy/sil-phil-ansi/mappings/PhilAnsiSIL.map]] - [6] [CODE[scripts/Grek/legacy/sil-galatia/mappings/SILGreek.map]] - [9] [CODE[scripts/Ethi/legacy/geez/mappings/Geez to Unicode.map]] - [13] [CODE[scripts/Arab/SenAjami/mappings/SenAjami.map]] - [19] [CODE[scripts/Ethi/legacy/sil-eth-m/mappings/SIL Eth M.map]] - [21] [CODE[scripts/Plrd/legacy/lipo3/mappings/lipo3.map]] - [22] [CODE[scripts/Latn/legacy/windows-symbol-cp1252/mappings/Windows-SymbolEncodedFont.map]] - [25] [CODE[regions/Americas/MX/legacy/sil-mexico/mappings/CHNCCR1.map]] - [27] [CODE[langs/r/rap/legacy/sil-rap/mappings/SIL_RAP.map]] - [29] [CODE[scripts/Deva/legacy/annapurna/mappings/Annapurna.map]] - [34] [CODE[scripts/Sinh/legacy/sinhala_07/sinhala_07.map]] - [37] [CODE[scripts/Talu/logical2visual/logical2visual.map]] - [40] [CODE[regions/Americas/MX/legacy/sil-mexico/mappings/MTCSTDMR.map]] - [46] [CODE[langs/m/mav/marktnr_satere/mav_satere.map]] - [70] [CODE[scripts/Music/legacy/musique/mappings/SIL-SA_MUSIQUE-2007.map]] - [71] [CODE[scripts/Grek/legacy/wingreek/mappings/WinGreek.map]] - [74] [CODE[scripts/Latn/legacy/windows-symbol-cp1252/mappings/Windows-SymbolEncodedFont.map]] - [79] [CODE[scripts/Latn/legacy/windows-symbol-cp42/mappings/Windows-SymbolEncodedFont2SymbolCP.map]] - [77] [CODE[scripts/Telu/legacy/nlci-winscript-telugu/mappings/WinScrTel.map]] [4] >>3 注釈に [[ISO/IEC 8859-1]] と思われる文字 [16] >>13 [CODE[Copyright]] の値 (文字列リテラル) に [[UTF-8]] 文字[CH[©]]を含む事例 [18] >>8 に含まれる [CODE[.map]] ファイルの限りにおいては考慮するべき[[非ASCII文字]]は >>16 のような[CH[©]] ([[UTF-8]]) のみのことがほとんどです。それ以外は[[注釈]]に[[非ASCII文字]]が含まれることも少なくありませんが、 [[UTF-8]] のものだけでなく >>4 のような事例も紛れ込んでいるので注意が必要です。 [36] >>34 は例外で、変換式の文字列リテラルでも [[UTF-8]] [[文字]]を使っています。 [39] [[UTF-8]] [CN[BOM]] が先頭についているファイルがあります。 [20] >>19 [[改行]]が [N[0x0D]] のみの事例 [23] >>21 [CH["]], >>22 [CH[']] で始まる[[文字列リテラル]]が[[改行]]まで閉じられていない事例 [24] [CITE[TECkit]] のソースコードを見ると[[改行]]も[[リテラル]]の終わりと明示的に作られていて、 エラーメッセージも特に出していません。 [35] >>34 > [PRE[ EncodingName "a canonical name that uniquely identifies this mapping table from all others" DescriptiveName "a string that describes the mapping" Version "1" Contact "mailto:user@addr" RegistrationAuthority "the organization responsible for the encoding" RegistrationName "the name and version of the mapping, as recognized by that authority" Copyright "© 2017 . All rights reserved." ]PRE] とあまりに雑な[[メタデータ]]。 そう、処理に使われない[[メタデータ]]は真面目に書いてもらえない(ことがよくある)、 これは世界の普遍の法則。 [41] >>40 > [PRE[ Contact "mailto:([SNIP[]]@sil.org)" ]PRE] なんだこの [CODE[mailto:]] [[URL]] は。 [CODE[mailto:]] の続きは [[RFC 822]] [[メールアドレス]]なので[[括弧]]に含まれるのは[[注釈]]。・・・ではさすがにないと思われるが。 [76] なお公式ドキュメント [SRC[>>11]] では Contact の値は [CODE[mailto:]] URL が typical form と書いているだけなので、 実は何でもいいということに。実際 >>74 は > [PRE[ Contact 'Bob Hallissy at SIL' ]PRE] としていてもはや[[メールアドレス]]ですらない。 [38] >>37 [CODE[VisualOrder]] を指定した事例 (他にほとんどない) [72] >>71 左辺が byte であるにも関わらず [CODE[LHSFlags]] に [ODE[ExpectsNFC]] を指定した事例 [7] >>6 [CODE[ByteDefault]] に [N[0x3F]] 以外を指定した事例 [73] ドキュメントによると [CODE[ByteDefault]], [CODE[UniDefault]] は [CODE[byte_unicode]], [CODE[unicode_byte]] の pass に属するべきものです。ところが >>70 は [CODE[.map]] 上に明記された pass は1つで [CODE[unicode]]。 その直前の pass に属さない部分に [CODE[UniDefault]] があります。 byte との変換が発生し得ないのでこの [CODE[UniDefault]] には意味がありません。 [17] >>13 入出力両方とも [[Unicode]] の事例 [78] >>77 pass が9段階もある事例 [47] >>46 は [[Unicode]] - [[Unicode]] 変換という形式になっているが、 左辺の [[Unicode]] は実際には [[Windows-1252]] の[[フォント]]の一部文字を独自に差し替えたもの。 [[CR]] に [[Windows-1252]] が割り当てた文字があるので [[Latin1]] 以外の領域の [[Unicode文字]]も左辺に入ってくる。 [75] >>74 は [[Unicode]] から [[Unicode]] への変換ファイルの事例 [80] >>79 は [[Unicode]] から byte への変換ファイルの事例。 pass が [CODE[Unicode_Byte]] になっているのは非常に珍しい。 注釈によると [[UTF-8]] に誤変換されたデータを処理するときに前段としてこれで[[8ビット符号]]に戻すために使うとのこと。 [5] >>3 [[バイトクラス]]・[[Unicodeクラス]]で定義されている対応と直接記述されている対応で重複がある (どちらの定義も同等)。 [CC[U+00D1]], [CC[U+00D2]], [CC[U+00D3]], [CC[U+00D4]] この他にも何らかの理由重複される変換式があって一方が常に無視されるものが含まれるファイルはかなりある。 (双方向の変換式でうち一方向が無視されるものもある。) [26] >>25 >>40 [CODE[PUA]] という謎の値が出現する事例。ドキュメントにある[[字句]]の中だと定義 (マクロ) か、 そうでなければ[[文字の名前]]扱いになるはずだが、 そのような定義は無いし、 [[文字の名前]]が [CN[PUA]] であるものは存在しない。また、 [CODE[PUA]] という[[クラス]]が定義されているわけでもないし、 [[クラス]]は構文も違う。 このような [CODE[PUA]] が変換式に含まれるファイルは他にもいくつかある。 [42] >>40 > [PRE[ 0xD7 <> U+256B BOX DRAWINGS VERTICAL DOUBLE AND HORIZONTAL SINGLE -- SILID 9090* + SILID 0129 (space glyph ignored) + SILID 9090* + SILID 9090* + SILID 9090* + SILID 9075* ]PRE] なんだこの行は。他の行と比べると本来 [CODE[BOX]] の前に [CODE[;]] が入って[[注釈]]になるべきが何らかの理由で消えてしまったか。 しかしこのファイルで [CITE[TECkit]] は読み込めるのか。 それともコミット後に誰も使っていないのか。 [12] >>9 変換先が [CC[U+FFFD]] を含む文字列の事例 (人間向けに注釈あり) [43] この他 [CODE[ByteDefault]] や [CODE[UniDefault]] が変換式に直接出てくる事例はいくつもある。 変換先が存在しないものであることを明示的に示したかったのか、 あるいは変換式同士の優先順位の関係で明示しないといけないケースもときにはあるのか。 [44] [CODE[<>]] なのに変換先が [CC[U+FFFD]] のものが複数ある (つまり逆変換が重複しているので1つ以外は無視される) というケースもたまにあって、そういうのは何も考えて無さそう。 [28] >>27 [CODE['id ']] から始まるおもしろい変換式。 [CODE[\id ]] から始まる行は通常の変換ではなくそのまま [[ASCII]] から [[Unicode]] に写像する意図らしい。 [CODE[.map]] の表現力で無理矢理記述した結果と思われる。 言語仕様ドキュメントではクラスはその位置で対応付けるとしか説明がなく、 クラス以外の字句の扱いが不明瞭だし、 [CODE[.map]] の字句の位置なのか一致した文字列の数(?)なのかよくわからない。ソースコードを読んだ感じだと、 [CODE[.map]] 上の字句の数で対応付けているように見える。 が、そうだとするとこの変換は正しく処理されないような気もするが... なお同じ変換式があるファイルが他にもいくつかある。 [125] 左辺で [CODE[@]] を使った事例がいくつか [30] >>29 [CODE[(X=a | Y=b) <> @a @b]] 型の変換式がある。 [CODE[|]] による選択があることに注意。 [CODE[<>]] なので両方向の変換に使われる。 左辺から右辺への変換は良いが、右辺から左辺への変換でこれが何を表すのか、 言語仕様ドキュメントを読んでも判然としない。 他のいくつかのファイルにもこの形式の変換式がある。 ;; [31] >>30 はおそらくいずれも特定の種類の文字列における文字の出現順序を一定に揃えるもので、 [CODE[<>]] になってはいるものの、実際には左辺から右辺への変換でしか使われないと思われる。 [45] ファイル仕様上はすべてのファイルが正方向と逆方向の両方の変換に対応することになっていそうだが、 実際のファイルでどこまでしっかり作り込まれているのかは怪しい。正方向が動作するのは当然として、 逆方向が不安なものもちらほら。また、 [CODE[>]] ばかりで逆方向の変換が皆無のファイルもあって、 当然逆方向に変換しても意味がない (未対応という意味で意図的にそうしているのかも)。 -*-*- - [92] [CITE@en[GitHub - Shreeshrii/xetex-itrans: Fork of https://www.ctan.org/tex-archive/macros/xetex/generic/itrans]], [TIME[2025-07-08T08:50:54.000Z]] -- [108] [[LaTeXライセンス]] - [104] [CITE@en[CTAN: Package xetex-devanagari]], [TIME[2025-07-08T11:31:38.000Z]] -- [105] [[LaTeXライセンス]] - [106] [CITE@en[CTAN: Package xetex-tibetan]], [TIME[2025-07-08T11:33:11.000Z]] -- [107] [[LaTeXライセンス]] - [129] [CITE@en[GitHub - davidmjones/brahmic-maps: ISO 15919 TECkit mappings for Indic scripts in XeTeX]], [TIME[2025-07-09T08:29:00.000Z]] -- [130] [[LaTeXライセンス]] - [139] [CITE[XeLaTeX and Fontsite's "Expert" fonts]], [TIME[2025-07-09T11:17:20.000Z]] -- [140] ライセンス不詳 [131] >>129 [CODE[build/]] で [CODE[make]] したら [CODE[.map]] が生成される [132] >>129 [CODE[pass(NFD)]] を使った事例 [133] >>129 [CODE[.*]] を一致部分に使った事例 [134] >>129 [CODE[deva-san.map]] が pass 10段階 [135] >>129 独自?の [[PUA]] に変換しているものも多い。 [CC[U+FFFD]] に変換しているものも多い。 - [85] [CITE@en[GitHub - fc7/arabxetex: An ArabTeX-like interface for XeLaTeX]], [TIME[2025-07-08T08:34:13.000Z]] -- [111] ライセンス不詳 -- [84] [CITE@en[arabxetex/arabtex-farsi-trans-loc.map at master · fc7/arabxetex · GitHub]], [TIME[2025-07-08T08:33:53.000Z]] -- [90] [CODE[arabtex-kurdish.map]] -- [96] [CODE[arabtex-trans-dmg.map]] - [137] [CITE@en[CTAN: /tex-archive/macros/xetex/latex/arabxetex]], [TIME[2025-07-09T11:06:44.000Z]] -- [138] [[LaTeXライセンス]] [86] >>84 [CODE[Define U]] している事例。[[字句解析]]で気をつけないと [CODE[U+1234]] の [CODE[U]] を置換してしまう。 [87] >>84, >>96 条件付きの削除 (右辺空) の事例 [95] >>90 条件に [CODE[.]] (任意の文字) の事例 [136] >>137 [CODE[arabtex-farsi-fullvoc.map]] に [CODE[^#]] の事例 -*-*- - [81] [CITE@en[GitHub - agricolamz/abaza_cyrillic_to_trans: Abaza cyrillic transliterator (TECkit map)]], [TIME[2025-07-08T08:19:34.000Z]] -- [110] ライセンス不詳 -- [82] [TIME[2025-07-08T08:20:34.600Z]] - [117] [CITE@en[GitHub - agricolamz/andi_cyrillic_to_IPA: Andi cyrillic to IPA transliterator (TECkit map)]], [TIME[2025-07-08T11:47:25.000Z]] -- [118] ライセンス不詳 [83] >>82 [[UTF-8]] 文字の[[文字列リテラル]]を利用。 [119] >>117 変換式の末尾の[[文字列リテラル]]を閉じる [CH["]] がない事例 - [89] [CITE@en[GitHub - somadeva/RomDev: TECkit mapping for Unicode Romanised Sanskrit to Devanagari conversion]], [TIME[2025-07-08T08:50:16.000Z]] -- [112] [[CC-BY 4.0]] -- [128] [CITE@en[sārasvataṃ cakṣuḥ: Updated Teckit RomDev]], [TIME[2025-04-09T02:48:01.000Z]], [TIME[2025-07-09T08:25:02.728Z]] -- [141] 関連: [SEE[ [[インド系文字の文字コード]] ]] - [93] [CITE@en[Devangari to IAST in LaTeX · GitHub]], [TIME[2025-07-08T08:51:09.000Z]] -- [113] ライセンス不詳 - [94] [CITE@en[GitHub - HughP/tcf-james-bigramed: Bigram Counting for tcf james]], [TIME[2025-07-08T08:51:19.000Z]] -- [114] ライセンス不詳 - [121] [CITE[Procedures/tools for Transcoding Cross-Platform Legacy Text to Unicode Using TECkit]], [TIME[2004-01-08T19:21:22.000Z]], [TIME[2025-07-08T12:22:00.068Z]] -- [122] ライセンス不詳 -- [123] [CITE[null]], [TIME[2004-01-08T19:20:03.000Z]], [TIME[2025-07-08T12:23:41.780Z]] -- [124] [CITE[null]], [TIME[2004-01-08T19:20:13.000Z]], [TIME[2025-07-08T12:23:50.979Z]] [97] >>93 > [PRE[ U+0905U+0902<>U+1E43;अं ṃ U+0905U+0903<>U+1E25;अः ḥ U+0905U+0901<>U+006FU+0302;अँ ô ]PRE] のように U+ 字句の間に空白がない事例 [98] >>89 [CODE[U+1E6D 'U+1E6C h' 'U+1E6D h' U+1E0C]] のような値がある。 ただの[[文字列リテラル]]。何を意図していたものか。 [99] >>89 [CODE[UniClass]] の定義中に[[文字列リテラル]]。[[UTF-8]] 文字も。 [126] >>123 pass が11段もある事例。流通しているファイルの中ではこれが最大か? [127] >>123 [CODE[([X])=a <> ([Y])=a]] 型のグループ化で一見隠された[[文字クラス]]同士の対応関係を使う事例 -*-*- - [91] [CITE@en[GitHub - dgreenhoe/unihan: C source that once compiled can generate a TECkit map from a Unihan_Variants.txt file to map traditional Chinese characters to simplified Chinese characters]], [TIME[2025-07-08T08:50:42.000Z]] -- [115] [[MITライセンス]] - [88] [CITE@en[GitHub - dgreenhoe/teckitmaps]], [TIME[2025-07-08T08:49:41.000Z]] -- [116] [[MITライセンス]] [100] >>91 は [[Unihan]] から機械的に生成したらしいファイル。 >>88 にもある。 [101] >>91 はとても雑で、 [[Unihan]] が[[異体字]]を列挙 (or) したものまでそのままにしているので、 [[異体字]]が並んだ文字列が変換結果になってしまっているw データの意味も理解しないで雑に処理して検証もしていないということ。 [102] なお[[簡体字]]・[[繁体字]]の変換は中華圏で需要が多く専門のソフトウェアやデータが盛んに開発されていて、 そちらの方がより正確で豊富。 [SEE[ [[異体字データベース]] ]] [103] >>91 はおそらく [CODE[.map]] として流通しているものの中でも変換式の量は最大級なので、 そういう検証には有用。ただ [CODE[.map]] としての複雑度は簡単な部類。 >>102 のようなデータは ([CODE[.map]] ではないが) もっと複雑なことをしている。 [CITE[TECkit]] が[[簡体字]]と[[繁体字]]の変換にも適用可能かというのは理論的に面白いテーマではある (>>91 はその回答にはまったくなっていないが)。 * 関連 [SEE[ [[Graphite Description Language]] ]] * メモ [120] [CITE@en[Bibledit]], [TIME[2025-07-08T12:19:28.000Z]], [TIME[2021-06-18T18:51:06.375Z]]