JavaScript

ルール： マークダウン構造を保護する。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 # MoeKoe Music Mobile オープンソースでシンプルで高颜值のサードパーティーKuGou Musicのモバイル端末プレイヤー Expo / React Nativeに基づいて構築され、MoeKoeMusicデスクトップ版のモバイル版実装です 🌎 GitHubリポジトリ | 📦️ ダウンロードパッケージ | 💬 ブログアクセス | 🏠 プロジェクトホームページ オープンソースでシンプルで高颜值のサードパーティーKuGou Musicのモバイル端末プレイヤー Expo / React Nativeに基づいて構築され、MoeKoeMusicデスクトップ版のモバイル版実装です ✨ 特徴 🎵 サーバー自建不要 — KuGou APIのアダプテーションレイヤーが直接公式に直結し、すぐに使用可能で、外部APIアドレスに依存しません 🏠 ホームページの推薦 — 毎日の推薦、選定歌単、ランキング 🧭 発見ページ — カテゴリ別歌単、新曲速報などのコンテンツ探索 🔍 検索 — 歌曲や歌単、アルバムの迅速な検索 📀 歌単 / アルバム / ランキング — 完全な詳細ページと曲リスト 🎧 プレイヤー — ロールシャッター歌詞、プレイリスト、ミニプレイヤー（MiniPlayer）、バックグラウンドプレイ 🎚️ 音質検出 — 利用可能な音質を自動的に検出し、選択 📱 電話番号ログイン — KuGouアカウントの收藏と歌単の同期 🌗 ダークモード — システムに従って明暗テーマを自動的に切り替え 📝 Todoリスト [x] ホームページの毎日の推薦 / 選定歌単 / ランキング [x] 発見ページのカテゴリ別内容の閲覧 [x] 歌曲や歌単、アルバムの検索 [x] 歌単 / アルバム / ランキングの詳細ページ [x] プレイヤー：ロールシャッター歌詞、プレイリスト、ミニプレイヤー、バックグラウンドプレイ [x] 音質検出と自動選択 [x] 電話番号ログイン [x] 認証情報ログイン [x] スキャンログイン（他のデバイス） [x] いいね / 收藏の同期 [x] ユーザー歌単管理（作成 / 收藏 / 編集） [ ] 通知バー / ロックスクリーンプレイコントロール [ ] 歌曲詳細の閲覧 [ ] テキストから歌詞の検出 [ ] タブレットと横画面の対応 [ ] パフォーマンス最適化 📸 プレビュー 🚀 快速スタート 環境要件 Node.js ≥ 22 Git iOSシミュレータ / Androidシミュレータ、または開発版クライアントがインストールされた実際のデバイス 開発と実行 # リポジトリをクローン（api submoduleを含む） git clone --recurse-submodules https://github.com/MoeKoeMusic/MoeKoeMusic-Mobile.git cd MoeKoeMusic-Mobile # 依存関係をインストール npm install npm --prefix api install # モバイル端末APIエントリを生成（api/ 更新後は再実行が必要） npm run generate:mobile-api # 開発サーバーを起動 npx expo start クローン時にsubmoduleが欠けている場合は、git submodule update --initを実行して補完できます。 ...

ルール： Markdownの構造を保護する。 URLやコードは翻訳しない。 翻訳された内容のみを返す。 MoeKoe Music エクステンション MoeKoe Music ブラウザエクステンション版は、MoeKoeMusic Webをベースに構築され、ブラウザエクステンション内でAPIルートの互換性を完了しています。 🌎 GitHubリポジトリ 特徴 ブラウザエクステンションのアイコンをクリックして、独立したウィンドウでMoeKoeMusicを起動します。 ユーザーがAPIアドレスを設定する必要はなく、ローカルのAPIサービスを追加で起動する必要もありません。 MoeKoeMusicのオリジナルWebページとインタラクションを保持し、ブラウザエクステンションの運行環境に互換性があります。 快速スタート 環境要求 Node.js 20以降 Git Chrome / EdgeなどのChromiumコアブラウザ 依存関係のインストール git submodule update --init --recursive npm install npm run install:app npm run install:appは、MoeKoeMusicとMoeKoeMusic/apiの依存関係をそれぞれインストールします。インストール後は、子モジュールのワークスペースを確認し、アップストリームのlockfileの非期待の変更をコミットしないようにしてください。 エクステンションの構築 npm run build 構築物は以下に输出されます： dist/extension ブラウザにインストール chrome://extensionsまたはedge://extensionsを開きます。 「開発者モード」を有効にします。 「既に解凍されたエクステンションをロード」をクリックします。 プロジェクトのdist/extensionディレクトリを選択します。 extensionソースディレクトリをロードしないでください。そうすると、ブラウザはマニフェストやバックグラウンドスクリプトの読み込みに失敗を通知します。 APIの実行方法 MoeKoe Music Webバージョンに比べて、このプラグイン版はユーザーにAPIアドレスを入力させることはありません。MoeKoeMusicのフロントエンドは、HTTPルートに基づいてリクエストを送信し、ビルド時にAxiosリクエストをエクステンション内部のメッセージチャネルに適用します。 リクエストフローは以下の通りです： MoeKoeMusic Web -> extension/app/api-adapter.js -> extension/api/service-worker.cjs -> extension/api/generated/modules.cjs -> extension/api/generated/modules.cjs -> MoeKoeMusic/api/module/*.js -> 酷狗関連インターフェース extension/api/generated/modules.cjsは生成ファイルで、scripts/generate-extension-api-entry.mjsがMoeKoeMusic/api/moduleをスキャンして生成します。APIモジュールを追加または更新した場合、以下のいずれかの命令を再実行します： ...

ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 ルール： マークダウン構造を保護。 URLやコードを翻訳しない。 追加のコメントなしで翻訳された内容を返す。 在做插件市场之前，先有的是 MoeKoe 的普通插件系统。 当時我想解决的问题不是某一个具体功能，而是一个更通用的问题：播放器里总会冒出很多小需求，有些人想改界面，有些人想加一个工具弹窗，有些人想接自己的服务。如果每个想法都往主程序里塞，主程序会越来越重，也越来越难维护。 所以我一开始给插件系统定的方向很明确：主程序只提供插件运行环境和管理入口，具体功能交给插件自己做。插件能独立安装、独立卸载，坏了也尽量不要影响播放器本体。 上一篇我写的是 MoeKoeMusic-Plugins 这个插件登记仓库。那边解决的是“插件市场的数据怎么产生”：用户用 Issue 提交，Action 校验，维护者审核，通过后写进 plugins.json。 但光有登记仓库还不够。真正对用户来说，插件市场不是 GitHub 上的一份 JSON，而是客户端里一个能看、能搜、能安装、能更新的入口。 所以这篇就换到 MoeKoe Music 主项目里，专门聊客户端的插件市场部分。 为什么选 Chrome Extension 这一套 MoeKoe は Electron アプリであり、Electron 自身に拡張の読み込み能力があります。既に Chrome Extension が動作する底層があるので、新しいプラグインフォーマットをゼロから設計する必要はありません。 この方法はいくつかの利点があります： 第一，プラグイン作者は完全に新しいフォーマットを学ぶ必要がありません。manifest.json、popup.html、background.js はすべてブラウザ拡張でよく使われる概念です。 第二，プラグインには天然のリストファイルがあります。主プログラムはまず manifest.json を読み取り、プラグイン名、バージョン、説明、権限、ポップアップエントリ、最低サポートバージョンなどの情報を判断します。 第三，Electron はプラグインディレクトリを直接読み込むことができます。私がサンドボックススクリプトを書く必要はありません。 展示、検索、分页と状態 プラグイン市場はインストールできるだけでなく、迅速に判断する必要があります： このプラグインは何をしていますか 私はこれをインストールしていますか 私がインストールしているのは旧バージョンですか このプラグインにはより高いバージョン要求がありますか それがネットワーク、ファイルアクセス、ローカルバイナリなどのリスクポイントを持っていますか 分页、検索、更新、状態 したがって、市場カードには「インストール」ボタンだけでなく表示されます。 プラグインディレクトリが存在することを確認 Electron を呼び出してダウンロード、インストール、旧バージョンをアンインストール、新しいバージョンをインストール プラグイン関連の IPC を登録 Chrome 拡張をロード Native Host インデックスと認証システムをロード 已安装插件 プラグイン管理ページの「已安装插件」は、現在読み込まれている Electron 拡張だけでなく、二つの情報を統合します： ...

続き：《同じアニメーション、3つの技術スタックで実装したらどう違うの？》 WebGL による二次元じゃんけんゲーム。 ルールは普通： グー > チョキ チョキ > パー パー > グー でも面白いのはここ： 負けると服を脱ぐ。 ええ、それだけです。単純かつストレート。 きっかけは「スプライトシートを研究したかった」 最初はゲームを作るつもりなんてなかった。 ただ研究したかっただけ： atlas sprite レイヤー合成 アニメーションカット こんな技術要素。 それで考えたんです：「実際に使える場面がないと？」 そして思い付き： じゃあ、二次元脱衣じゃんけんにすればいいと。 そしたらプロジェクトが暴走し始めた。 このプロジェクトで一番大変だったのはゲームロジックじゃない じゃんけんのルールはシンプルすぎる。 本当に大変だったのは：服のレイヤー管理 キャラクターは「1枚の完成した画像」ではなく： ベース画像 (全裸バレ防止のため、わざと暗号化済み) 服 A 服 B 服 C アクセサリー 遮蔽レイヤー 重ね続ける。 「脱衣」の正体はレイヤー管理 プレイヤーが勝った： 設定された順番で服を1枚除去 コンピュータが勝った： 逆順で服を着せる 聞こえるのは簡単。 実際は山のような問題にぶつかる： 例えば「ベース画像が一瞬見えてはいけない」 これは特に重要。 もしこうすると： 古い服を先に消す 新しい服を後で追加する その一瞬ベース画像がチラ見えする。 見た目がすごく変になる。 なので後で：reveal カバーロジックを使うことにした。 新しいレイヤーが即座に上に被さる。 極力避けたい： 「裸が1フレーム映り込む」 プロジェクト自体は不真面目に見えるけど 少なくとも技術的には美しくありたい。 WebGL はここで本当に心地いい このプロジェクトは最終的に WebGL で実装した。 理由はシンプル：レイヤーが多すぎる。 ...

最近、なかなか面白い小実験をやってみました。 二次元キャラクターのちょっとしたアニメーション効果を、それぞれ： WebGL Canvas 2D 純 DOM + CSS の3つの方法で実装し直しました。 効果自体は複雑ではありません： まばたき 眉毛/下まぶたの連動 汗のゆらゆらした揺れ アホ毛の振り動き でも本当に面白いのは、「作れた」こと自体ではなく： 同じものを、3つの技術スタックで実装したとき、どれくらい差が出るのか？ というところです。 本質的には「フロントエンドグラフィクス色の濃い」再現実験でした。 最初はただアホ毛アニメーションを再現したかった インスピレーション元：https://tamanidamani.itch.io/nijikas-ahoge 当時のシンプルな思い：「自分だったらどう実装する？」 そしてやるほどに熱中してしまい、最終的にこうなりました： じゃあ、WebGL、Canvas2D、DOM の3パターン全部作ってみよう。 そうしてリポジトリは今の形になりました： canvas/ canvas2D/ dom/ 同じ効果を3つのバージョンで実装しています。 まず結論 一言でまとめるなら： WebGL が最強だけど、Canvas2D が一番書きやすくて、DOM がビジネス向け 1. WebGL バージョン：「本当のゲーム開発」に一番近い このバージョンが一番手間がかかります。 なぜなら本質的には「フロントエンドアニメーション」ではなく：GPU グラフィクスプログラミング だからです。 どう実装しているのか？ コアとなる考え方は： 背景レイヤー1枚 スプライトを重ねていく shader で描画制御 JS でアニメーションパラメータを動かす 例えば： アホ毛の回転 まばたきの切り抜き alpha ブレンド これらはすべて GPU 側で処理されます。 だんだんとこういうものに触れるようになります： uniform texture shader UV 頂点座標 テクスチャ座標 そして笑顔が消えていきます。 でも WebGL は本当に強い 要素が増えてくると、WebGL の「全然平気」という感覚が際立ちます。 特に： ...

✨ 緒山まひろの隠れ家 ✨ 🌸 緒山まひろの隠れ家へようこそ 🌸 わぁ！私の秘密基地を見つけちゃったんだね！(*≧ω≦) ここは緒山まひろの個人サイトだよ。かわいいアニメーションと面白いコンテンツがいっぱい！ ここでは、私のお気に入りのアニメ、マンガ、ゲーム、そして日常のささやかな幸せをシェアしていくね～ 💕 私について 💕 私は緒山まひろ。エロゲを愛する引きこもりのダメニートだよ。 アニメ、マンガ、ライトノベル、そしてかわいいものが大好き！ 好きな色はピンクと水色！ ∩∩ （･ω･） <- 私だよ！ ＿|　⊃／(＿＿ ／ └-(＿＿＿／ 🎀 サイトコンテンツ 🎀 🌟 素敵なアニメーション 📚 私のプライベートフォト 🎵 おすすめの音楽 📷 日常のワンシーン 🌈 関連リンク 🌈 🎭 デモ: https://mahiro.moejue.cn/ 🏠 個人ブログ: https://MoeJue.cn/ 🐱 GitHub: https://github.com/iAJue/Mahiro 📧 公式サイト: https://onimai.jp/ 📝 著作権情報 📝 このサイトは @Moejue によってデザイン・開発されました サイト内で使用されているすべてのアニメーション、マンガの画像、キャラクター、および関連コンテンツの著作権は、原作者（ねことうふ）およびその発行元（スタジオバインド、一迅社）に帰属します 著作権侵害の可能性がある場合は、上記の連絡先までお知らせください。速やかに関連コンテンツを削除いたします GNU GENERAL PUBLIC LICENSE Version 2 Copyright © 2025 MoeJue. All rights reserved. 💌 スペシャルサンクス 💌 緒山まひろを好きでいてくれるみんな、ありがとう！(●’◡’●) ...

初めてのマルチチェーンウォレット統合の実践的考察 ようやく時間ができてコードを整理できるようになりました。Web3プロジェクトでマルチチェーンウォレット接続機能を導入する際、主にEthereum、Polygon、BSC、Solanaが関わってきます。一見すると「互換性のあるロジックをいくつか追加するだけ」のように思えますが、実際に実装してみると、多くのことが思ったほど単純ではないと気づきました。 this.networkConfigs = { ethereum: { chainId: '0x1', // 1 chainName: 'Ethereum Mainnet', nativeCurrency: { name: 'Ethereum', symbol: 'ETH', decimals: 18 }, rpcUrls: ['https://eth-mainnet.public.blastapi.io'], blockExplorerUrls: ['https://etherscan.io'] }, polygon: { chainId: '0x89', // 137 chainName: 'Polygon Mainnet', nativeCurrency: { name: 'MATIC', symbol: 'MATIC', decimals: 18 }, rpcUrls: ['https://polygon-rpc.com'], blockExplorerUrls: ['https://polygonscan.com'] }, bsc: { chainId: '0x38', // 56 chainName: 'BNB Smart Chain', nativeCurrency: { name: 'BNB', symbol: 'BNB', decimals: 18 }, rpcUrls: ['https://bsc-dataseed.binance.org'], blockExplorerUrls: ['https://bscscan.com'] } } マルチチェーンは単に「複数のウォレットをサポートする」ことではない 最も強く感じたのは、チェーンが異なればウォレットのインタラクション方法も異なり、SDKの考え方すら違うということです。イーサリアムエコシステムでは統一されたWeb3.jsで多くのロジックを処理できますが、Solanaになると、完全に別のシステムであることがわかります。プロバイダーの接続、接続フロー、PublicKeyの構築方法が異なり、ネットワークの遅延や安定性までもがユーザー体験に影響を与えます。 ...

ArticleSync - マルチプラットフォーム記事同期プラグイン ArticleSyncは、ユーザーが複数のソーシャルプラットフォームに記事を簡単に同期・公開できるブラウザ拡張機能です。ローカルの下書きから、知乎（Zhihu）やBilibiliなどの主要プラットフォームに記事を公開することをサポートしています。これにより、異なるソーシャルメディアプラットフォーム間で記事を同期する作業が、シンプルかつ効率的になるワンストップソリューションを提供します。 ブラウザ拡張機能の仕組みに基づき、ローカルでログインしているアカウントを自動的に検出し、アカウント情報の漏洩や環境の異常といったリスクを防ぎます。 Chrome Manifest V3ブラウザ拡張機能の標準に基づいて開発されており、カーネルのバージョン要件にご注意ください。 背景 ご存知の通り、私は最近、いくつかのブログプラットフォームと多くのソーシャルサイトを新たに使い始めました。もし、それらすべてで活発に更新を続けたいと思ったらどうすればいいでしょうか。（私がまだ生きていることを証明するために）ついでに、ワンクリックで記事を転載することもできます。 私が最も頻繁に更新するのは自分の小さなサイトですが、他のプラットフォームはたまにしか更新しません。しかし、毎回手動で投稿するのは面倒です。そこで、ローカルでログインしているアカウントを自動検出し、自動で投稿してくれるプラグインが作れないかと考えました。 「自分のことは自分でやる」ということわざの通り、数日間いじくり回して、なんとか使えるものができました。残りの部分は時間があるときに更新します。お金をくれるなら話は別ですが。 このプラグインにはまだ多くの未完成な部分があり、本番環境で複数のプラットフォームでのテストも行っていません。エラーが発生するのはごく普通のことですので、その際はIssueを提出するか、自分で修正してPRを送ってください。てへぺろ〜 話の邪魔にならないように、スクリーンショットは最後に載せておきました。 それと、オープンソースは大変なので、スターを付けてくれると嬉しいです。へへへ〜 本当は、私のコミュニティプラットフォームを自動でフォローするような、個人的な機能を追加しようかとも思いました。 機能と特徴 マルチプラットフォーム対応：知乎（Zhihu）、Bilibiliなどの主要プラットフォームや、自作のオープンソースCMSシステムをサポートしています。 ステータス追跡：プラグインのインターフェースで記事の同期状況を確認できます。 アカウント管理：プラグインに連携されている各プラットフォームのアカウント情報を確認できます。 高い拡張性：開発者はアダプターパターンを通じて、簡単により多くのプラットフォームに拡張できます。 安全性と信頼性：ブラウザ拡張機能の仕組みに基づいているため、アカウントの安全性を確保し、情報漏洩などのリスクを回避します。 Todoリスト [ ] 独立した記事エディタ [ ] 画像のワンクリック同期 [x] MarkdownとHTMLの相互変換 [ ] サードパーティの画像ホスティングサービス [ ] 複数アカウント管理 [ ] マルチOSクライアントバージョン [ ] ワンクリックAI要約 [ ] 動画の同期 [ ] タグ、カテゴリのサポート [ ] より親切なエラーハンドリング [ ] より多くのプラットフォームへの対応 対応プラットフォーム メディア カテゴリ ステータス URL 対応形式 更新日時 Bilibili (哔哩哔哩) 主要セルフメディア 対応済み https://bilibili.com/ HTML 2024/10/13 知乎 (Zhihu) 主要セルフメディア 対応済み https://www.zhihu.com/ HTML 2024/10/13 博客园 (Cnblogs) ブログ 対応済み https://cnblogs.com/ HTML 2024/10/14 新浪头条 (Sina Headline) 主要セルフメディア 対応済み https://weibo.com/ HTML 2024/10/14 Emlog オープンソースCMS 対応済み https://www.emlog.net/ HTML 2024/10/14 WordPress オープンソースCMS 対応済み https://cn.wordpress.org/ HTML,Markdown 2024/10/14 Discuz! オープンソースCMS 対応済み https://www.discuz.vip/ Markdown,Text 2024/10/15 インストール手順 リポジトリをローカルにクローンします： ...