GitHub Emoji Unicode Full Emoji List - shortcode | code point | escape-sequence

絵文字の「ショートコード」は各プラットフォームごとに異なるので困ったものです。

GitHub でショートコードが用意されている絵文字は、最新の Unicode 絵文字バージョンではないようですが、Facebook、Twitter など大手プラットフォームで直接を生貼りでも問題なく使えるような雰囲気です。

👉 Emojis - GitHub Docs




「GitHub ショートコード」と「Unicode コードポイント」、「Unicode エスケープシーケンス」をスクリプトで一覧にして書き出しておきます。

一番左の「emoji」カラムは絵文字クリックから Emojipedia に飛べます。




👉 Python vs Kotlin Unicode Escape Sequence (エスケープシーケンス) の記述 hatena-bookmark


絵文字が意図しない白黒で表示される ➡️ - Unicode Variation Selector

一部の絵文字が白黒の記号と表示される場合があります。

カラーの絵文字と思いきや白黒。


Text("\u2B06\u27A1\u2B07\u2B05\u2195")

直接コードに絵文字埋め込むと意図通りに表示される。


// ブラウザ上でもうまく表示されないものがある。
Text("⬆️➡️⬇️⬅️↕️")

コードはわかりやすく Android Jetpack Compose にしています。

IDEのエディター上からコード内に直接絵文字を書くことができる感じもありますが、編集時にイラッとすること多いので直接書きたくありません。

これは、デバイスやOSやアプリが使用しているフォントだけに依るものなのでしょうか。

私の端末では、白黒とカラー両方の矢印を見たような気がする。

 

➡️ 調べてみる

この記事。

👉 Emoji displayed as monochrome symbol? 🤔 The Unicode variation selector hatena-bookmark

まとめると以下。

一部の記号は、意図しない白黒、またはカラー絵文字として表示される。

Unicode Variation Selector を使うとある程度制御できる。

Unicode Variation Selector を使用しない場合はシステム次第。

絵文字ピッカーには Unicode Variation Selector が含まれないものもある。

Mac の絵文字ピッカーや Emojipedia は Unicode Variation Selector が含まれています。

Unicode Variation Selector には  U+FE0E (VS15)と U+FE0F(VS16) が定義されている。

VS15 を追加すると白黒テキスト、VS16 はカラー絵文字が表示されます。

ここに挙げられている、Macの絵文字ピッカー (Control + Command + Space) でみると以下。右クリックで文字情報見れます。


⬆️
up arrow
Unicode: U+2B06 U+FE0F, UTF-8: E2 AC 86 EF B8 8F

⬇️
down arrow
Unicode: U+2B07 U+FE0F, UTF-8: E2 AC 87 EF B8 8F

➡️
right arrow
Unicode: U+27A1 U+FE0F, UTF-8: E2 9E A1 EF B8 8F

⬅️
left arrow
Unicode: U+2B05 U+FE0F, UTF-8: E2 AC 85 EF B8 8F

↕️
up-down arrow
Unicode: U+2195 U+FE0F, UTF-8: E2 86 95 EF B8 8F


⬆︎
UPWARDS BLACK ARROW
Unicode: U+2B06 U+FE0E, UTF-8: E2 AC 86 EF B8 8E

⬇︎
DOWNWARDS BLACK ARROW
Unicode: U+2B07 U+FE0E, UTF-8: E2 AC 87 EF B8 8E

➡︎
BLACK RIGHTWARDS ARROW
Unicode: U+27A1 U+FE0E, UTF-8: E2 9E A1 EF B8 8E

⬅︎
LEFTWARDS BLACK ARROW
Unicode: U+2B05 U+FE0E, UTF-8: E2 AC 85 EF B8 8E

⬍
UP DOWN BLACK ARROW
Unicode: U+2B0D, UTF-8: E2 AC 8D

同様に、以下からコピーした絵文字も Variation Selector きちんと入ってます。

👉 📙 Emojipedia — 😃 Home of Emoji Meanings 💁👌🎍😍 hatena-bookmark

入ってないツールや絵文字サイトもありますので注意です。

 

➡️ 試してみる

String がどうなってるか拡張関数を作っておきます。



これを使って詳細見てみます。


"⬆➡⬇⬅↕".printUnicodeEscapeSequences()

"⬆︎➡︎⬇︎⬅︎↕︎".printUnicodeEscapeSequences()

"⬆️➡️⬇️⬅️↕️".printUnicodeEscapeSequences()

"⬆️".printUnicodeEscapeSequences()

"➡️".printUnicodeEscapeSequences()

"⬇️".printUnicodeEscapeSequences()

"⬅️".printUnicodeEscapeSequences()

"↕️".printUnicodeEscapeSequences()

結果。


⬆➡⬇⬅↕
\u2B06\u27A1\u2B07\u2B05\u2195

⬆︎➡︎⬇︎⬅︎↕︎
\u2B06\uFE0E\u27A1\uFE0E\u2B07\uFE0E\u2B05\uFE0E\u2195\uFE0E

⬆️➡️⬇️⬅️↕️
\u2B06\uFE0F\u27A1\uFE0F\u2B07\uFE0F\u2B05\uFE0F\u2195\uFE0F

⬆️
\u2B06\uFE0F

➡️
\u27A1\uFE0F

⬇️
\u2B07\uFE0F

⬅️
\u2B05\uFE0F

↕️
\u2195\uFE0F

 

➡️ まとめ

異体字セレクタ (いたいじセレクタ、英: Variation Selectors) は、Unicode および ISO/IEC 10646 (UCS) における、文字の字体をより詳細に指定するためのセレクタ (選択子) である。

👉 異体字セレクタ - Wikipedia hatena-bookmark

矢印の場合カラー絵文字をある程度強制したい場合の Kotlin 文字列 Unicode 記述は、

Unicode Variation Selector\uFE0F (VS16) を文字シンボルの後につける。」


⬆️➡️⬇️⬅️↕️
\u2B06\uFE0F\u27A1\uFE0F\u2B07\uFE0F\u2B05\uFE0F\u2195\uFE0F

Jetpack Compose で書くと以下。


Text("\u2B06\uFE0F\u27A1\uFE0F\u2B07\uFE0F\u2B05\uFE0F\u2195\uFE0F")

逆に、白黒にしたい場合は、\uFE0E (VS15) をつければよい。

別に、layout.xml だろうが strings.xml だろうが同じ。

あと、ちなみに、いつも話題に上がる国旗とか。


🇯🇵
\uD83C\uDDEF\uD83C\uDDF5

👨‍👩‍👧‍👧
\uD83D\uDC68\u200D\uD83D\uDC69\u200D\uD83D\uDC67\u200D\uD83D\uDC67

なげえ。

👉 【Kotlin】絵文字を含む Unicode 文字列の文字数をカウントする方法と文字ごとの構成要素 hatena-bookmark


プログラミング「ChatGPT にコーディングを依頼するだけ」は嘘?

こんな記事がありました。

👉 Jay Little - Software Obsessionist - Low Code Software Development Is A Lie hatena-bookmark

Sometimes a client falls into the trap of believing that there is some kind of silver bullet they can employ which will negate the inherent complexity around coding custom solutions. Nowadays the most cliche form of this is to say, "Well I'll just ask ChatGPT to code that for me". I call bullshit. While ChatGPT can handle some simple coding tasks, anything beyond that causes it to rapidly devolve into an unmanageable mess.

「コーディングの複雑さを解消する特効薬がある」という言葉を信じて罠に陥ることがあります。最近のこの決まり文句は「ChatGPT にコーディングを依頼するだけ」というものです。 私はデタラメだと思います。ChatGPT はいくつかの単純なコーディングタスクを処理できますが、その後急に、管理不能な混乱に陥ります。

Beyond the in vogue AI Chatbot example, there are a wide variety of other snake oil tools lingering about. All of them sell prospective buyers on the premise of allowing them to cut through the cruft and quickly pump out custom software without going through the years of training that professional Software Developers tend to go through. The most relevant example of this syndrome are so-called low code tools. As it so happens, I work with one of these at my current job.

流行りのAIチャットボットの他にも、様々なゴミツールが出回っています。これらはすべて、プロのソフトウェア開発者が経験するような長年のトレーニングを受けることなく、厄介なものを切り捨て、好みのソフトウェアを素早く作り出せるという前提で、購入希望者に売り込んでいます。この問題の最もよく見られる例は、いわゆるローコードツールです。たまたま、私は現在の職場でこのうちの1つを使用しています。

This low-code tool is called ***** and my review of it is that its a steaming pile of shit. I won't go into the technical specifics of why as that probably deserves it's own post. While it has enabled some non-developers to produce custom logic and screens, it hasn't actually removed the inherent complexity around designing proper data structures, writing fault tolerant software and validating the quality of the resulting software. Because a lot of the coders in question don't have this expertise, the end result is a custom software system that is poorly thought through, is brittle and as a result will require constant fire fighting on the part of the future members of the team in an effort to keep it functional.

このローコードツールは ***** というもので、私がみたところ、とんでもないクソの山です。その理由についての技術的な詳細については、ここでは触れません。非開発者でもロジックや画面を作成できるようになりましたが、適切なデータ構造の設計、耐障害性のあるソフトウェアの作成、出来上がったソフトウェアの品質の検証など、固有の複雑さを取り除くことはできません。多くのコーダーはこのような専門知識を持ち合わせていないため、最終的にソフトウェアは、十分に考え抜かれておらず、脆弱で、その結果、機能を維持するために未来のチームメンバーによる絶え間ない消火活動が必要となります。

I haven't even mentioned the best part: Tools like this aren't cheap and they tend to structure their licenses / billing so that you end up paying for as long as you use the software you produce with the tool. On top of which, all of these tools seem to involve accepting some level of vendor lock-in. So the more time you put into tools like these, the tighter their grip on your proverbial balls becomes.

一番大事なことは、このようなツールは安くはなく、ツールで作成したソフトウェアを使用する限り、最終的には、支払いが発生するような ライセンス/請求 の仕組みとなっています。その上、これらのツールはすべてベンダーロックインを受け入れなければならず、このようなツールに時間を費やすほどベンダーロックから抜けられなくなります。

In both the AI Chatbot and the Low Code tool scenarios, the solutions each promise a shortcut around the complexity as perceived by a non-practitioner. That's the essence of the trap. Practitioners know that the writing of the code is merely the last step in a long process that involves a lot of thinking, discussion and planning. The code is generally the end result and producing it is relatively easy once you truly understand the problem at hand.

AIチャットボットとローコードツールの両方で、各ソリューションは、非専門家の複雑さを回避する近道を約束しています。それが罠の本質です。開発者は、コードの記述が、多くの思考、議論、および計画を含む長いプロセスの最後のステップにすぎないことを知っています。コードは通常、最終結果であり、目前の問題を本当に理解していれば、それを作ることは比較的簡単なことです。

TLDR: Designing a solution worth a damn is actually the most difficult part of the software development process. Low Code tools lie to customers by implying that the writing of code is the hardest part. The reality is that No Low Code tool can spare you from having to take the time to properly design your custom software or the consequences you will experience when you build solutions around a half-ass design.

TLDR:価値のあるソリューションを設計することは、実はソフトウェア開発プロセスの中で最も難しい部分です。ローコードツールは、コードを書くことが最も難しい部分であるかのように、顧客に嘘をついています。現実には、どんなローコードツールも、ソフトウェアを適切に設計するための時間や、中途半端な設計でソリューションを構築したときの結末から逃げることはできません。

 

🤔 この意見についてどう思うか ChatGPT に聞いて見た

この意見についてあなたはどう思いますか。関西弁で答えて。

めっちゃ同感やわ。コーディングの複雑さを解消する特効薬があると思ったら大間違いやで。そんなもんあったら、開発者はみんなそれを使って楽々コーディングやろうて思うてるわ。AIチャットボットやローコードツールなんか、一部の単純なタスクをこなすのには使えるやろうけど、それだけや。複雑なタスクをやるには、経験や専門知識、センスが必要なんや。ローコードツールを使っても、適切なデータ構造の設計や品質検証など、ソフトウェア開発の複雑さは取り除けへん。プロの開発者に頼るべきやな。

めっちゃ大事なことは、この手のツールは高くて、ツールで作ったソフトをつかう限り、最終的には、支払わなあかんライセンスか請求のシステムになってるねん。それだけやなくて、全部のツールはベンダーロックインを受け入れなあかんから、この手のツールに時間を使うほど、ベンダーロックから抜け出せなくなることもあるで。

AIチャットボットとローコードツールは、どっちも非専門家でも使いやすいっていうのが売りやけど、それが落とし穴なんよ。開発者たちは、コード書くのは思考や議論、計画が必要な長いプロセスの最後のステップってことを知っとる。コードは普通、最終的な結果であって、問題を本当に理解してたら、それを作ることは比較的簡単なんやで。

要するに、簡単にソリューションを作ることはできへんってことや。どんなローコードツールでも、適切にソフトを設計するための時間や、中途半端な設計から逃げられへんのや。そんなことを顧客に嘘をついて、コード書くのは難しいとか言ってるんや。

 

🤔 まとめ

それを3行にして

1. 特効薬でコーディングが楽になるというのは誤解やで。
2. AIチャットボットやローコードツールは一部のタスクにしか使えへん。
3. 開発には経験や専門知識が必要や。

ナニワ金融道ぽくてワロタ。