パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

XML誕生から20年」記事へのコメント

  • XMLとその関連技術は素晴らしすぎて、20年後の現在もかなり完成されているように見える。
    今はJSON好きが多いけれど、XMLより劣る点は多い。
    現在でもつかわれるプロトコルとして、SMTPとかのメール周りは改良点は多数あるし(参考 [srad.jp])、HTMLは実際手を入れられているが再設計するならかなり良くなるだろう。
    その点でXMLをより良くするなら、今の視点で設計するなら、というのはテーマとして面白いと思う。

    自分としては、

    • 属性を要素に展開する標準的な手法の規定(XAMLではある)。
    • 一般のバイナリを記述できるスキーマ
    • by Anonymous Coward

      「charset が出現するまでは必ず ASCII コード」という規約が欲しい
      いや、BOM なし UTF-16 な XML なんて存在しないならどうでもいいのですが。

      # オレオレパーサを書くのが一番悪いってのはわかっているのですが

      • by Anonymous Coward

        いや、それマトモにテキストエディタで開けないから駄目だろ

        • by Anonymous Coward on 2018年02月12日 19時10分 (#3360272)

          途中で文字コードが変わるテキストデータの話ではなく、文字コードの判別方法に関してです。

          BOM つき UTF-16→わかる
          7bit 領域は ASCII 互換→charset の結果でわかる(SJIS とか UTF-8 とか)
          BOM なし UTF-16→ビッグエンディアンの UTF-16 と判別して読み込む(が、どう判別する?)

          2 番目まで処理してパースに失敗したら 3 番目処理して、というのが現実的な解でしょうか?
          (これだけのために文字コード判別のライブラリとか組み込みたくないので)

          親コメント
          • BOMとか見るなら、頭2バイト見ればわかるんじゃないの?

            0x3c 0x3f ならASCII互換の「<?」なのでencoding指定まで読み進める
            0xFE 0xFF ならUTF-16のBig Endian
            0xFF 0xFE ならUTF-16またはUTF-32のLIttle Endian(UTF-16とUTF-32の確定ができないので4byte目まで読む必要がある)
            0x00 0x00 ならUTF-32のBig Endianの可能性が高い(4byte目まで見ないとBOMか確定はできない)
            0xEF 0xBB BOMありUTF-8(厳密には3byte目の0xBFまでがBOMだけど)
            0x00 0x3c ならUTF-16のBE(BOMなし)
            0x3c 0x00 ならUTF-16またはUTF-32のLE
            それ以外ならXMLではない

            という判定をすれば事足りるよねっていう?

            親コメント
            • by Anonymous Coward

              ここまで網羅しておいて、どうして2バイトと口走ったw
              4バイトで決定できるで良かったのでは。

犯人はmoriwaka -- Anonymous Coward

処理中...