PlantUMLでは、図のソースコードを英数字、アンダースコア、ハイフンだけのシンプルな文字列にエンコードする標準の方法を定めています。 これは、URLによって図を使ったコミュニケーションを円滑に行えるようにすることを目的としています(サーバーを参照)。 エンコード後の文字列をできるだけ短くするために圧縮が行われます。 エンコードされた文字列は、生成されたPNGファイルにもメタデータとして保存されます。つまり、画像ファイルから、その図のソースを取り出すことができます(サーバーを参照)。 以下の圧縮アルゴリズムが利用可能です: - Deflateアルゴリズムは小さい図の場合に有効です。
- バージョン1.2017.20以降のPlantUMLでは、Brotliアルゴリズムを利用することもできます。(issue #117)こちらは大きい図の場合に有効です。Brotliアルゴリズムであることを表すために、エンコード後の文字列の最初に
0 が追加されます(Deflateで0 で始まるデータが生成されることはありません)。 - 単純な16進数(HEX)エンコーディングを使用することもできます。この場合、先頭に
~h が追加されます。 原理 例えば、次のようなUMLのテキスト記述があった場合:
@startuml
Alice -> Bob: Authentication Request
Bob --> Alice: Authentication Response
@enduml
このようにエンコードされます:
Syp9J4vLqBLJSCfFib9mB2t9ICqhoKnEBCdCprC8IYqiJIqkuGBAAUW2rO0LOr5LN92VLvpA1G00
この結果を得るには次の処理を行います: - テキストをUTF-8でエンコードします。
- DeflateまたはBrotliアルゴリズムで圧縮します。
- Base64に類似したアルゴリズムを使って、ASCIIに再エンコーディングします。
Base64ではない理由 大きな理由は歴史的なものです。このフォーマットは最初、公開を目的としていませんでした。これを変更するのは今となっては遅すぎます。しかし、その差異は、使用する文字の順番のみです。 Base64は0~63の値を、次の配列に対応させます:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
PlantUMLでは、0~63の値を、次の配列に対応させます:
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz-_
圧縮の比較 次の図をエンコードすると、 Deflateを使うと428文字。 PTE 表現は、 -encodeurl や -decodeurl を コマンドライン フラグをつけることで、使用できます。 以下のコードでは、このエンコードを実際に使っています。 WARNING This translation need to be updated. WARNING DeflateやBrotliは複雑すぎると思う場合は、16進数(HEX)形式を使用することもできます。 この場合は、すべての文字を16進数形式でフォーマットするだけです。 例:
@startuml
Alice->Bob : I am using hex
@enduml
次のようになります:
407374617274756d6c0a416c6963652d3e426f62203a204920616d207573696e67206865780a40656e64756d6c
16進数(HEX)形式であることを示すために、PlantUMLサーバに送信するデータの先頭には~h を付ける必要があります。 http://www.plantuml.com/plantuml/uml/~h4073... 圧縮されていないので、図のサイズが大きくなるとURLが非常に長くなります。 |