ChatGPTは色々と使える
最近、ゼルダのプレーと、今更ながら朝ドラの「あまちゃん」にハマってしまい、他のことがかなり手つかず状態な今日この頃です。
(あまちゃんネタは別記事でそのうち)
そのようななか、毎月1日に必ず行っている手動バックアップ(RAIDは色々な考えがあり、ビデオサーバのみRAID)をしている最中に、rsyncのコピーエラーが発生しました。
この現象はたまに見かけていたのですが、とあるHDDケースの故障(?)によりrsync中にOSがクラッシュする現象が発生し(これは別の機会があったら記事にする)、この影響で中途半端にコピーしたファイルがrsync的にイカレてしまうということが先月から毎回発生する状況に…
解消方法はエラー対象となるファイルを削除して手動でコピーし直せば良いのですが、残念なことにそのファイル名が日本語ファイルの場合は表示がおかしくなり、特定が難しくなります。
一例を挙げると
といったもので、「\#351\#226\#213\#347\#231\#272...」ってなんだよ、ヲイ!ってなものでした。
ファイル名が分かんねーじゃねーかYO!!
運の良いことに前回と今回は対象のファイル名は前後のアルファベットの文字列情報を元に特定できたのですが、この化けているような数字の羅列がイミフでした。
最初は単純に「UTF-8のコードなのかな?」と思いましたが、頭の351で、あれっ? 255以上の数値だな。じゃぁ、351を16進で表せばいいのかな…と思ったのですが、単純変換では「そのファイル名の文字列にならない」ので、思惑通りに行かず…
と、ここでこんなマニアックなフォーマット情報は全世界をググレカスしても出てこない訳で、かといってrsyncのソースを見てエラー出力フォーマットの仕様を理解するのも時間の無駄と思い、「じゃぁ、AIに相談するか…」と「ChatGPT」を駆使して色々と解決しました。
(あまちゃんネタは別記事でそのうち)
そのようななか、毎月1日に必ず行っている手動バックアップ(RAIDは色々な考えがあり、ビデオサーバのみRAID)をしている最中に、rsyncのコピーエラーが発生しました。
この現象はたまに見かけていたのですが、とあるHDDケースの故障(?)によりrsync中にOSがクラッシュする現象が発生し(これは別の機会があったら記事にする)、この影響で中途半端にコピーしたファイルがrsync的にイカレてしまうということが先月から毎回発生する状況に…
解消方法はエラー対象となるファイルを削除して手動でコピーし直せば良いのですが、残念なことにそのファイル名が日本語ファイルの場合は表示がおかしくなり、特定が難しくなります。
一例を挙げると
rsync: [generator] readlink_stat("/media/oki/ContentsBackup/ <略> \#351\#226\#213\#347\#231\#272\#343\#202\#271 <略> \#347\#247\#230\#350\#251\#261.iso.lRuGLX") failed: Input/output error (5) |
といったもので、「\#351\#226\#213\#347\#231\#272...」ってなんだよ、ヲイ!ってなものでした。
ファイル名が分かんねーじゃねーかYO!!
運の良いことに前回と今回は対象のファイル名は前後のアルファベットの文字列情報を元に特定できたのですが、この化けているような数字の羅列がイミフでした。
最初は単純に「UTF-8のコードなのかな?」と思いましたが、頭の351で、あれっ? 255以上の数値だな。じゃぁ、351を16進で表せばいいのかな…と思ったのですが、単純変換では「そのファイル名の文字列にならない」ので、思惑通りに行かず…
と、ここでこんなマニアックなフォーマット情報は全世界をググレカスしても出てこない訳で、かといってrsyncのソースを見てエラー出力フォーマットの仕様を理解するのも時間の無駄と思い、「じゃぁ、AIに相談するか…」と「ChatGPT」を駆使して色々と解決しました。
まず最初に「\#351\#226\#213\#347\#231\#272...」ってものに検討をつけないとなりません。
今回は運良くファイル名は分かっているので、この不思議な数字を元のファイル名の日本語に当てる訳ですが、法則を掴まないとなりません。
この例では、「\#」を区切りに300番台が3組ごとに繰り返されています。こう思うと、業界が長いので「あー、UTF-8か…」と思うのですが(UTF-8の日本語は大抵3, 4バイトで表現される)、上述したとおり、300番なんて先頭になるものがありません。
例えば「あ」は「0xE38182」の3バイトで、「0xE3」は、10進数で227です。どうやっても先頭の「\#351」にはならないです。
そこで、ChatGPTに、
> 「\#343\#202\#271」を日本語の「ス」で表すキャラクタコードを教えてください。
という感じで、ヒントを与えました。
すると、
と、なかなかの回答が。
「これは凄い!」と思ったのですが、そこからが割と大変でした。
一見合っているようで、説明がおかしいのです。「ChatGPTは嘘つき」というのは結構世間で言われている話で、私も散々騙されているのですが(嘘とは分かってはいるので、騙されているというより「嘘言ってんな~」程度ですが)、割とニアピンなことをいうので、こちらも藁をも掴む気持ちなので、色々とパラメータを与えて学習させることにしました。(今流行りで言うプロンプトエンジニアリングみたいなノリでw)
どうせなら「変換プログラム」も作らせてしまえということで、Python向けに具体的な入力例、具体的な出力例を提示し、AIが考えたコードを軽く添削し、エラーが出たらNGを出すこと18回。まずはまずまずの正解コードを出すようになりました。
結果、この変換には16進数の変換だけでなく、8進数に変換をさせる必要があることをAIに導き出してもらいました。(流石にこれは私も気が付かなかった。つか、なんで2段階も変換させる仕様なのか…)
更にこれをLinuxのターミナルからこのエスケープされているだろう文字列を入力したら変換してターミナルにゴキゲンな日本語を表示させるように指示したら、これまた先の学習内容を忘れたかのようなポンコツコードを生成するので、正しくエスコートし、追加で10回位教え込んで、納得行くコードを生成させることができました。
以下が、ChatGPTが生成したコードです。先頭の2行のshebangとコメントは私が書きました。
【ソース:rsync-error-japanese-code-change.py】
コメントを日本語で付けてくる優秀さです。8進数変換に関しては重要なのにコメント付けてくれないのはご愛嬌w
入力例を挙げると、
【出力結果】
この例では入力パラメータから「開発」という文字列を導き出しています。
これで今後rsyncで日本語ファイル名のファイルコピーでエラーが出ても直ぐに特定できます。
誰も活用しない私だけのプログラムをChatGPTで作りました。(゜∀゜)イイ!!
このように、ちょっとしたコードをAIに相談して利活用できるので、ホント便利です。
先日Microsoft主催のAzure OpenAI Serviceのセミナーを受けることができ、クラウド上でGPT-4を用いてコードを自動生成させるデモを見ましたが、このようなものを用いて更に時短ができるようになると思うと、「オラ、わくわくしてきたぞ!!! (by ドラゴンボール)」って感じです。
いや、今見ている朝ドラマだと、「おら、ドキドキがとまんねぇ (by あまちゃん)」かも。(なんてw)
今回は運良くファイル名は分かっているので、この不思議な数字を元のファイル名の日本語に当てる訳ですが、法則を掴まないとなりません。
この例では、「\#」を区切りに300番台が3組ごとに繰り返されています。こう思うと、業界が長いので「あー、UTF-8か…」と思うのですが(UTF-8の日本語は大抵3, 4バイトで表現される)、上述したとおり、300番なんて先頭になるものがありません。
例えば「あ」は「0xE38182」の3バイトで、「0xE3」は、10進数で227です。どうやっても先頭の「\#351」にはならないです。
そこで、ChatGPTに、
> 「\#343\#202\#271」を日本語の「ス」で表すキャラクタコードを教えてください。
という感じで、ヒントを与えました。
すると、
「ス」をUTF-8のキャラクタコードで表すと、\xE3\x82\xB9となります。 しかし、提供された「#343#202#271」はUTF-8のバイト表現ではなく、バイト列を表す文字列のようです。それをUTF-8のキャラクタコードに変換するには、バイト表現に対応する16進数の値を持つバイト列に変換する必要があります。 |
と、なかなかの回答が。
「これは凄い!」と思ったのですが、そこからが割と大変でした。
一見合っているようで、説明がおかしいのです。「ChatGPTは嘘つき」というのは結構世間で言われている話で、私も散々騙されているのですが(嘘とは分かってはいるので、騙されているというより「嘘言ってんな~」程度ですが)、割とニアピンなことをいうので、こちらも藁をも掴む気持ちなので、色々とパラメータを与えて学習させることにしました。(今流行りで言うプロンプトエンジニアリングみたいなノリでw)
どうせなら「変換プログラム」も作らせてしまえということで、Python向けに具体的な入力例、具体的な出力例を提示し、AIが考えたコードを軽く添削し、エラーが出たらNGを出すこと18回。まずはまずまずの正解コードを出すようになりました。
結果、この変換には16進数の変換だけでなく、8進数に変換をさせる必要があることをAIに導き出してもらいました。(流石にこれは私も気が付かなかった。つか、なんで2段階も変換させる仕様なのか…)
更にこれをLinuxのターミナルからこのエスケープされているだろう文字列を入力したら変換してターミナルにゴキゲンな日本語を表示させるように指示したら、これまた先の学習内容を忘れたかのようなポンコツコードを生成するので、正しくエスコートし、追加で10回位教え込んで、納得行くコードを生成させることができました。
以下が、ChatGPTが生成したコードです。先頭の2行のshebangとコメントは私が書きました。
【ソース:rsync-error-japanese-code-change.py】
#!/usr/bin/env python3
# ChatGPT に出力させたコード
import sys
# 引数の取得
hex_string = sys.argv[1]
# \#を#に置換
hex_string = hex_string.replace(r'\#', '#')
# 16進数の文字列を抽出
hex_values = hex_string.split('#')[1:]
# 16進数をバイト列に変換してUTF-8エンコード
utf8_bytes = bytes([int(hex_value, 8) for hex_value in hex_values])
try:
# バイト列をUTF-8文字列にデコード
utf8_string = utf8_bytes.decode('utf-8')
print(utf8_string)
except UnicodeDecodeError:
print("デコードできませんでした。")
コメントを日本語で付けてくる優秀さです。8進数変換に関しては重要なのにコメント付けてくれないのはご愛嬌w
入力例を挙げると、
【出力結果】
$ rsync-error-japanese-code-change.py '\#351\#226\#213\#347\#231\#272' 開発 |
この例では入力パラメータから「開発」という文字列を導き出しています。
これで今後rsyncで日本語ファイル名のファイルコピーでエラーが出ても直ぐに特定できます。
誰も活用しない私だけのプログラムをChatGPTで作りました。(゜∀゜)イイ!!
このように、ちょっとしたコードをAIに相談して利活用できるので、ホント便利です。
先日Microsoft主催のAzure OpenAI Serviceのセミナーを受けることができ、クラウド上でGPT-4を用いてコードを自動生成させるデモを見ましたが、このようなものを用いて更に時短ができるようになると思うと、「オラ、わくわくしてきたぞ!!! (by ドラゴンボール)」って感じです。
いや、今見ている朝ドラマだと、「おら、ドキドキがとまんねぇ (by あまちゃん)」かも。(なんてw)
コメント
コメントの投稿
« 会合&ものづくりギャラリー展示「家庭用ゲーム機の技術展」 l Home l Can☆Do パックマン コラボレーショングッズ »