長い話を短く

Question

このトピックについて調査するほど、そのようなlsfd行動が正しくないという確信が高まりました。RFC 8259 8.1説明する：

クローズドエコシステムに属さないシステム間で交換されるJSONテキストは、UTF-8を使用してエンコードする必要があります。

問題があるという事実は、これらの出力が閉じたエコシステムにカプセル化されていないため、JSONテキストがRFC 8259に違反していることを意味します。

私の考えでは、個々のプロジェクトのバグレポートを開いて問題を知らせるのが良い習慣です。その後、問題を処理するかどうか、およびどのように処理するかを決定することは、プロジェクトメンテナンスに依存します。

私はこれがプロジェクトメンテナンスの観点から解決可能でなければならないと思います。lsfdLC_CTYPE / LANG環境変数を尊重し、入力がそのロケールから来ると仮定し、それをUTF-8に変換できます。

UTF-8でエンコードされた文字列を誤って含むJSON形式の名前はありますか（一部のバイト値> = 0x80は有効なUTF-8エンコーディング文字の一部を形成しません）？

答え：「壊れた」

冗談ですが少しだけです。実際にここで何が起こるのかは、JSONがUTF-8で書かれていますが、すべての入力もUTF-8であることを確認するためのチェックが行われないことです。技術的にあなたが見ているのはミックス文字セットは、非標準の文字セットでエンコードされたjsonファイルではありません。

この形式を確実に処理できるツールやプログラミング言語モジュール（Perlを好むが他のユーザーにも開いている）はありますか？

一部は、入力が完全にLATIN-1という（間違った）仮定に基づく特別な処理など、特定の場合に満足のいく結果を得ることがあります。これは、JSONのすべての特殊文字が単一のUTF-8バイトコード値（128以下のASKII文字コードと同じ）であるために機能します。多くのシングルバイト文字セットの最初の127バイトコードは同じ意味を持ちます。

しかし、明らかにしておくと、私たちはUTF-8でなければなりませんが、UTF-8ではなく出力を処理することについて話しています。したがって、ここでの解決策はデザインではなく運に依存します！これは「未定義の動作」に似ています。

特定の文字セットに対する回避策がある可能性があります。これらの回避策が成功するには、文字セットがすべてのバイトコードをUnicodeにマッピングする必要があること、または実際にマッピングされていないバイトコードが使用されることを確認する必要があります。文字セットはUTF-8、特に1バイトの文字コードも共有する必要があります[]{}:""''\。

LATIN-1は私が知っている唯一のものですが、これはUnicodeにLATIN-1という特別なブロックがあるので特に機能します。ラテン語-1サプリメント。これにより、バイト値をUnicodeコードポイントにコピーするだけでLATIN-1をUnicodeに変換できます。

ただし、同様のcp1252にはUnicodeにマッピングできないスペースがあり、ソリューションが急速に中断されます。

この破損した動作を処理するために私が提案する方法はPython3を使用することです。 Python3は、特にテキストを表すために使用されるバイトシーケンスと文字列の違いを理解しています。

Python3から生のバイトを読み取り、選択したエンコーディングを想定して文字列にデコードできます。

import sys
import json

data = sys.stdin.buffer.read()
string_data = data.decode("LATIN1")
decoded_structure = json.loads(string_data)

その後、主に演算子を使用してjsonを操作できます[]。例：latin-1を使用するjsonの場合Ç：

{
   "lsfd": [
      {
         "name": "/home/chazelas/tmp/Ç"
      }
   ]
}

次のコマンドを使用して名前を印刷できます。

import sys
import json

data = sys.stdin.buffer.read()
string_data = data.decode("LATIN1")
decoded_structure = json.loads(string_data)
print(decoded_structure["lsfd"]["name"].encode("LATIN1"))

このアプローチを使用すると、データを文字列として処理する前にバイトとして処理することもできます。これは状況が非常に汚れているときに便利です。たとえば、入力を次のようにエンコードする必要があります。cp1252ただし、cp1252に無効なバイトが含まれています。

import sys
import json

data = sys.stdin.buffer.read()
data = data.replace(b'\x90', b'\\x90')
data = data.replace(b'\x9D', b'\\x9D')
string_data = data.decode("cp1252")
decoded_structure = json.loads(string_data)
print(decoded_structure["lsfd"]["name"].encode("cp1252"))

Answer 1

このトピックについて調査するほど、そのようなlsfd行動が正しくないという確信が高まりました。RFC 8259 8.1説明する：

クローズドエコシステムに属さないシステム間で交換されるJSONテキストは、UTF-8を使用してエンコードする必要があります。

問題があるという事実は、これらの出力が閉じたエコシステムにカプセル化されていないため、JSONテキストがRFC 8259に違反していることを意味します。

私の考えでは、個々のプロジェクトのバグレポートを開いて問題を知らせるのが良い習慣です。その後、問題を処理するかどうか、およびどのように処理するかを決定することは、プロジェクトメンテナンスに依存します。

私はこれがプロジェクトメンテナンスの観点から解決可能でなければならないと思います。lsfdLC_CTYPE / LANG環境変数を尊重し、入力がそのロケールから来ると仮定し、それをUTF-8に変換できます。

UTF-8でエンコードされた文字列を誤って含むJSON形式の名前はありますか（一部のバイト値> = 0x80は有効なUTF-8エンコーディング文字の一部を形成しません）？

答え：「壊れた」

冗談ですが少しだけです。実際にここで何が起こるのかは、JSONがUTF-8で書かれていますが、すべての入力もUTF-8であることを確認するためのチェックが行われないことです。技術的にあなたが見ているのはミックス文字セットは、非標準の文字セットでエンコードされたjsonファイルではありません。

この形式を確実に処理できるツールやプログラミング言語モジュール（Perlを好むが他のユーザーにも開いている）はありますか？

一部は、入力が完全にLATIN-1という（間違った）仮定に基づく特別な処理など、特定の場合に満足のいく結果を得ることがあります。これは、JSONのすべての特殊文字が単一のUTF-8バイトコード値（128以下のASKII文字コードと同じ）であるために機能します。多くのシングルバイト文字セットの最初の127バイトコードは同じ意味を持ちます。

しかし、明らかにしておくと、私たちはUTF-8でなければなりませんが、UTF-8ではなく出力を処理することについて話しています。したがって、ここでの解決策はデザインではなく運に依存します！これは「未定義の動作」に似ています。

特定の文字セットに対する回避策がある可能性があります。これらの回避策が成功するには、文字セットがすべてのバイトコードをUnicodeにマッピングする必要があること、または実際にマッピングされていないバイトコードが使用されることを確認する必要があります。文字セットはUTF-8、特に1バイトの文字コードも共有する必要があります[]{}:""''\。

LATIN-1は私が知っている唯一のものですが、これはUnicodeにLATIN-1という特別なブロックがあるので特に機能します。ラテン語-1サプリメント。これにより、バイト値をUnicodeコードポイントにコピーするだけでLATIN-1をUnicodeに変換できます。

ただし、同様のcp1252にはUnicodeにマッピングできないスペースがあり、ソリューションが急速に中断されます。

この破損した動作を処理するために私が提案する方法はPython3を使用することです。 Python3は、特にテキストを表すために使用されるバイトシーケンスと文字列の違いを理解しています。

Python3から生のバイトを読み取り、選択したエンコーディングを想定して文字列にデコードできます。

import sys
import json

data = sys.stdin.buffer.read()
string_data = data.decode("LATIN1")
decoded_structure = json.loads(string_data)

その後、主に演算子を使用してjsonを操作できます[]。例：latin-1を使用するjsonの場合Ç：

{
   "lsfd": [
      {
         "name": "/home/chazelas/tmp/Ç"
      }
   ]
}

次のコマンドを使用して名前を印刷できます。

import sys
import json

data = sys.stdin.buffer.read()
string_data = data.decode("LATIN1")
decoded_structure = json.loads(string_data)
print(decoded_structure["lsfd"]["name"].encode("LATIN1"))

このアプローチを使用すると、データを文字列として処理する前にバイトとして処理することもできます。これは状況が非常に汚れているときに便利です。たとえば、入力を次のようにエンコードする必要があります。cp1252ただし、cp1252に無効なバイトが含まれています。

import sys
import json

data = sys.stdin.buffer.read()
data = data.replace(b'\x90', b'\\x90')
data = data.replace(b'\x9D', b'\\x9D')
string_data = data.decode("cp1252")
decoded_structure = json.loads(string_data)
print(decoded_structure["lsfd"]["name"].encode("cp1252"))

長い話を短く

長い話を短く

追加情報

lsfd（およびほとんどのutil-linuxユーティリティ）：生データを出力します。

列: 明示的にエスケープされない:

Journalctl：バイト配列：

カール：フェイク

cvtsudoers: オリジナル

dmesg：オリジナル

iproute2：プリミティブでバグがあります

Exiftool：バイトを次に変更しますか？

lsar：バイト値をtarのUnicodeコードポイントとして解釈します。

lsipc：オリジナル

GNUパラレル：オリジナル

rg: "text": "..." から "bytes": "base64..." に切り替えます。

sqlite3:オリジナル

木: オリジナル

lslock：オリジナル

@raf~の生皮：生の

FreeBSD ps --libxo=json: エスケープ:

FreeBSD wc --libxo=json: 生

JSON処理ツール

jsec：受け入れるがU + FFFDに変換

jq：受け入れてU + FFFDに変換しますが、偽：

gojq：エラーもありません

json_pp：受け入れ、U + FFFDに変換

json_xs：同じ

JSON：エラー

json5: 承諾、U+FFFDに変換

jc：エラー

mlr: 承諾, U+FFFDに変換

vd: エラー

JSON::分析:エラー

ジョー：間違っている

jsed：受け入れてU + FFFDに変換

ベストアンサー1

おすすめ記事