今回は全然くそみたいな記事だけど、
コードをきれいに見せたくて、
スタイルシートいじったり、いろいろやったことあるんだけど、
一番簡単なのはVSCでコピペすればいい
こんな感じで一部だけコピペしてるだけなんだけど、
綺麗に張り付けられる。
もうこれでいいよね?
今回は全然くそみたいな記事だけど、
コードをきれいに見せたくて、
スタイルシートいじったり、いろいろやったことあるんだけど、
一番簡単なのはVSCでコピペすればいい
こんな感じで一部だけコピペしてるだけなんだけど、
綺麗に張り付けられる。
もうこれでいいよね?
RaspberryPi4がクーラーのない部屋で1.5M稼働してると、熱暴走することがあった。
しかたないので、スマホ用クーラー付けてみた。
今のところ、1.5M動作でも55度から57.4度あたりをうろついている。
あ、写真は間違って裏側につけてた時の写真、
PINの配置がある表側につけないとだめよ?
RaspberryPi4の温度と周波数を手軽に見たいなと思ってalias 作った(そんだけ)
以下を.bashrcの適当なところに設定してやれば、tempとかfreqで出てくる。
キッチンの三角コーナーがダサくて、ダイソーの紙袋をつかっていた。
やりたくなかったけど、大体できた。
以下テストコード
変換後(改行はないけどフォーマットした)
あと考慮するのは以下2点
1.どこのパスからパースするかの指定をアトリビュートに持つ
2.FORCEARRAYの機能実装
どちらも目処は立っている
なんでこんなバグがあるんだろうなぁ
んで、テスト
で、ソース中にも書いたけどさ
ここよ、どうなってんだよ?
マップがnameでまとまってねーんだよ
おそらく途中に<OTHER>挟んだからだよな?
なんでnameでまとまらないの?
もうあれだ、、、疲れたわ、、、
何がダメって、
<list>
<name>あいうえお</name>
<name>かきくけこ</name>
<other>OTHER</other>
<name>さしすせそ</name>
</list>
で、list.childrenを取得すると、nameとotherだけ取得できるようになっておらず、
children[0],children[1]がnameのあいうえお、かきくけこを指していて、children[2]がOTHER、children[3]がnameのさしすせそを指すようになっている。
なんでもう一段まとめてくれねぇんだよ・・・
XMLてのはフォルダ構造に似ていて、
上記まとめ方だと、nameというフォルダが複数あるかのような動きになってしまっている。
XMLデータの扱いとしては、フォルダに例えて説明すると、
nameフォルダの下にファイルが複数あって、そのファイルの中にテキストやアトリビュートが入っているかのような造りにしてくれないと全然使い勝手違うんだよ
まぢわかってねぇわ・・・
XMLからJSONへの変換をしようとしていて、encoding/xml使ったり、XSLで変換かけようかと思ったけど、XSLTは難解で、考え方は分ってきたけど、組みづらい・・・
やはりXMLはDOMで扱わないとダメよ
encoding/xmlとか使っても結局DOM作ろうとしちゃうし、DOM作らないと、XMLの表記方法への対応は出来ない。
たとえば、以下のようにnameが連続していないとき、name項目が一つしかないとき、nameの下に子ノードがあるときなど、汎用的なXMLでは、SAXやxsl的な方法での変換なんて出来ない。
<root>
<list>
<name>aiueo
<special>あいうえお</special>
</name>
<name>kakikukeko</name>
<URL>http://www.blablabla.com</URL>
<name>sasisuseso</name>
</list>
</root>
SAXやXSLは、きまった形のXMLでない対応できない。
この考え方が、xslを使えない奴にしてしまっている。
ていうか、xslで出来ることがHTML変換くらいなものなのだが、
JavaScript系のエンジニアは、JSONでそのまま扱いたいからxslなんて勉強しない。
そして余計にXMLが嫌われていく
xslもオブジェクト指向に毒されてしまっているのだと思う。
golangやってると、オブジェクト指向なんてどうでもよくなる。
(まったくオブジェクト指向なんて悪い夢を見ていたようだよ)
話を戻して、JSONへの変換元となるXMLは、形が無限の種類のXMLなので、SAXやXSLでは絶対に無理だ。
例えば上記の場合、name以下は全部強制的に配列にしたい。
nameの途中にURLタグが出てきちゃうので、nameで要素をまとめてJSON配列にしないといけない。
これは、encoding/xmlのtokenじゃ無理
一度読み込んでまとめ、ソートするなど工夫が必要だ。
つまりそれってDOMだよ
強制配列を実現するために全体をDATAタグで括って、プロパティでForceArrayを指定して変換できるように考えていた。
まず、このアトリビュートの取得をして、複数のXPATHをXSLのVariableに配列としてSplitしようかと思ったのだけど、xsl2.0じゃないとtokenize使えないし、xsl2.0なんて誰も実装してないし、SAXXONくらいだし、俺Java嫌いだし絶対に使わねー
go-xmldomでxml2json作ろうかと思ってまずはxmldomのテストプログラムを動かしてみた。
名前はxml2json.goだけど、機能はxml2jsonじゃありません。
単にテストプログラムをそのまま動かしただけです
Qiitaみたいですみません
===xml2json.go===
んで、テストになってないテストプログラム
go test -vで動かすと以下の様に出てくる
=== RUN TestXml2JSON
testsuite: name=github.com/subchen/go-xmldom, time=0.009
testcase: name=ExampleParseXML, time=0.004
testcase: name=ExampleParse, time=0.005
--- PASS: TestXml2JSON (0.00s)
PASS
ok xml2json 0.004s
簡単に考えていたのだが、XML表記をそのままJSONへ変換することは出来ない。
簡単に言うと2つ問題がある。
1.XMLから配列への扱い
入力XML(NAMEが1つのとき)
出力JSON(NAMEが1つのとき)
入力XML(NAMEが1つ以上とのき)
出力JSON(NAMEが1つ以上のとき)
これは非常にわかりやすい
XMLのNAMEが1件なら配列にはならないのだが、
1件以上あれば鍵カッコで囲われて配列になっている。
なので、XMLの特定のタグについては、
強制配列化を行いたいという要望があちこちのXML2JSONで散見されている。
2.アトリビュート有り無し混在
続いて、アトリビュートの扱いだ。
入力(アトリビュート有り無し混在XML)
出力JSON(アトリビュート有り無し部のアクセスの仕方が違ってしまう
これ、非常にまずい、あいうえおは#textになってて、かきくけこは普通に配列に入っている。ついでにXMLのアトリビュート名にはハイフンがプレフィックスとしてついている。
しかし、XMLからJSONへの変換の仕方としてはこれが一般的なのだ。
上記1の問題から、タグごとにアトリビュートでFORCEARRAYの設定を付けたら配列になるような仕様にするべきと考える。
上記問題2の結果から同じ階層で同じタグ名で、アトリビュート有り無し混在したXMLはJSONへの変換に用いてはならないことになる。
んで、これら2つの問題を考慮したうえで、
XMLからJSONへの変換をもう一度考えてみたが、
やり方として別にgolangでやる必要なんかなかったのでは?
そもそもXMLなんだから、なんでXSLTしないの?
という事に気が付いた。
んで、今色々と試行錯誤中
goxml2jsonの強制配列化はバグがある
詳細はこちら
最初の1行にしか強制配列化が適用されない。
書き込みの最後にアトリビュートでどうたら書かれているけど、
これはただの提案であり、XML的には単なるアトリビュートなので、全く意味のない書き込みだ。
しかも、指定した場所以降、すべて配列化されてしまう。
そして、配列化する場所は一か所しか指定できない。
仕方ないので、自前で作ろうと思う。
とはいえ、encoding/xmlは使う。
こちらにPlayGroundの例を置いておく
まずは任意のXMLを列挙する部分を作った。
encoding/xmlを使うときに、なぜか皆さん、構造体を作って割り当てるやり方しかしていない。
JSONなんざ文字列なので、XMLを列挙しながら対応していけばいいんだよ
まずは列挙だけしたからあとは勝手に作ればいい