仕事メモとか

仕事中に調べた情報とか知ったことをメモしています。
unixコマンド, vim, oracle, putty, postgresql, bash, EXCEL, python, SQL全般 など。
最近は tableau, movabletype とかも触ったりしています。
雑な読書感想とかはこちら

カテゴリ: トラブル

DBeaverでoracleを入れ直したら繋がらなくなった

はい、なんかツールのアナウンスにしたがってoracleのドライバをを入れ直してみたら、逆にoracleに繋がらなくなりました。

postgreSQLとかは繋がるので、多分DBeaverの問題ではなくoracleドライバのみの問題っぽい。


・バージョン
DBeaver 7.1.1
oracle jdbc 8 (12.2.0.1)

結論から書くと、ダウンロードしたoracleのドライバを削除して、デフォルトでみていたjdbc6にしてみたら動きました。

メニューの[データベース]→[ドライバーマネージャー]
からOracleを選択して、ライブラリの中から不要そうなものは全部削除、という感じです(デフォルトっぽいものはそのまま)

新しくダウンロードしたjdbc8の問題かと思うけど、動いちゃったので突き詰めていません。




このエントリーをはてなブックマークに追加

文字化けで一部の文字だけ何故かハテナに化ける

文字コードで化けてて化けてない話
http://workmemo.techblog.jp/archives/41062154.html

こちらの続きです。
そもそもなんで化けてるのか、っていうのが少しわかってきたのでメモ。

PDFからコピーした時に一部の漢字が化けていてDB(postgreSQL)に入っていた結果、
メールを経由すると「?」として表示されてしまう(DBを直接見ると化けてないように見えてしまうけど、文字コードを直接見ると化けてる)という現象でした。

これ原因は康煕部首(こうきぶしゅ)という、漢字とも部首とも取れる文字として扱われ、これとして対応できる文字自体が化けていました。

やるとしたらこの康煕部首として使える文字を全て置換すれば自動置換で行けそう。

例)

select
  data ,
  translate(data, 
    /*部首の'⼈'*/chr(12040) ||  /*部首の'⼗'*/chr(12055) ||
    /*部首の'⽤'*/chr(12132) ||  /*部首の'⽬'*/chr(12140) ||
    /*部首の'⾊'*/chr(12170) ||  /*部首の'⾏'*/chr(12175) ||
    /*部首の'⾔'*/chr(12180) ||  /*部首の'⾯'*/chr(12207) ||
    /*部首の'⾷'*/chr(12215) ,  '人十用目色行言面食')
from table
where
   (
    data like '%' || /*部首の'⼈'*/chr(12040) || '%' or
    data like '%' || /*部首の'⼗'*/chr(12055) || '%' or
    data like '%' || /*部首の'⽤'*/chr(12132) || '%' or
    data like '%' || /*部首の'⽬'*/chr(12140) || '%' or
    data like '%' || /*部首の'⾊'*/chr(12170) || '%' or
    data like '%' || /*部首の'⾏'*/chr(12175) || '%' or
    data like '%' || /*部首の'⾔'*/chr(12180) || '%' or
    data like '%' || /*部首の'⾯'*/chr(12207) || '%' or
    data like '%' || /*部首の'⾷'*/chr(12215) || '%' )
group by
    data
;

(データは一部です)

参考:
https://ja.wikipedia.org/wiki/%E5%BA%B7%E7%85%95%E9%83%A8%E9%A6%96 
https://golden-lucky.hatenablog.com/entry/2019/12/05/171340
このエントリーをはてなブックマークに追加

ORA-01489: result of string concatenation is too long が出た


プログラムを流用しようと思って使ってみたら、エラーが出てました。
見てると普通にoraエラー。

他に使ってるやつなので不思議に思っていたのですが、
実行したやつはデータ件数が多くなる形になっていました。
プログラムをよく見ると、SQLを動的に作っている。

データが増えるのとともに、SQL自体が動的にでかくなる→SQL文字数的にエラー

って言うコンボだったようです。
動的に作ってる部分がわかりづらくて時間を食ったのですが、そもそも作り上げたSQL自体をechoとかしてれば一発で気付けた話。


このエントリーをはてなブックマークに追加

文字コードで化けてて化けてない話


データが部分的に化ける、という話があって、データをみていると化けないんですが、
データをメールに出力すると一部が?になって化ける。

なんだろうこれ、と思ったら、PDFからコピペした文字が化けていて、
ほとんどの場所は通常通りに入ってるんですが、化けて?になるところは「⽅」っていう文字が入ってる。

これ文字コードを解析するツールなどでみるとわかるんですが、
https://www.hyuki.com/aozora/code.cgi

普通の文字に見えてるのはブラウザさんがそうしてるだけで、文字コードはチグハグになっていました。

んで、みていると、化けてないのに「 ︖ 」表記になってるところを発見。

なんだろうと思ったら、縦書き用の?が文字化けしていたようです。
元々「?」の文字が入ってる場所だから、文字化けしても?(ちょっと位置が違うように見える)だったので気がつかなかったようです。

該当文字コード
https://www.compart.com/en/unicode/U+FE16

 
 
このエントリーをはてなブックマークに追加

一見普通そうな文字で地味な文字化け(入手)


文字が一部だけ地味に滲んでるという相談があり、調査。

滲んでる部分は「入手」という文字でした。
こんなの文字化けするのかな、と思って調べたら、入も手も特殊文字だった。


特殊文字と普通のSJISの両方を調査してみた結果、内部的には⼊ ⼿ と別物だった。
これどうやって入手したのか(多分なんかのコピペ)。

⼊=unicode(10進数であらわしたもの)
93FC=sjis

ということで、混在してるケースっぽい。
(文字コードに詳しくないので間違えていたら教えてください)

変換例)
入手(文字化けする方)
入手(手入力した値)
のデータを検索ツールで入れたもの。


 & → 26
 # → 23
 1 → 31
 2 → 32
 0 → 30
 4 → 34
 2 → 32
 ; → 3B
 & → 26
 # → 23
 1 → 31
 2 → 32
 0 → 30
 9 → 39
 5 → 35
 ; → 3B
入 → 93FC  第1水準1-38-94
手 → 8EE8  第1水準1-28-74

参考:
https://www.hyuki.com/aozora/code.cgi
 
このエントリーをはてなブックマークに追加

↑このページのトップヘ