Cardano-db-sync: 테스트넷의 유니코드로 인한 예외

이것은 목의 엄청난 통증입니다.

삽입되는 tx 메타데이터는

(1,S "\NUL\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX")

JSON으로 인코딩됩니다.

"\u0000\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003"

물론 유효한 UTF8이 아니므로 데이터베이스가 이를 거부합니다.

설상가상으로 위와 같이 Haskell Text 라이브러리에 의해 위의 내용이 UTF8로 인코딩되지만 PostgreSQL은 이를 거부합니다.

이것이 목에 얼마나 큰 고통인지 다시 한 번 말씀드리겠습니다.

문제의 문자열은 Haskell Text 라이브러리에 의해 UTF8로 디코딩된 다음 SqlError 예외가 발생하는 Postgres로 전달됩니다. 이 예외를 잡으려고 시도했지만 예외를 잡는 것이 작동하지 않는 것 같습니다.

예외를 포착하고 기록할 수 있습니다.

[db-sync-node:Warning:37] [2020-09-21 00:26:18.77 UTC] insertTxMetadata: Failed to insert (1,S "\NUL...\ETX")
SqlError {sqlState = "22P05", sqlExecStatus = FatalError, sqlErrorMsg
 = "unsupported Unicode escape sequence", sqlErrorDetail = "\\u0000 cannot be converted to text.", sqlErrorHint = ""}

그러나 두 번째 예외가 있습니다.

[db-sync-node:Error:37] [2020-09-21 00:26:18.77 UTC] runDBThread: SqlError {sqlState = "25P02", sqlExecStatus = FatalError, sqlErrorMsg = "current transaction is aborted, commands ignored until end of transaction
 block", sqlErrorDetail = "", sqlErrorHint = ""}

이것은 삽입하기 전에 JSON을 더 완전히 검증해야 함을 시사합니다.

우리는 PostgreSQL을 무효 UTF8을 저장할 수 있지만에만 bytea 데이터하지으로 jsonb 우리는 avaiable이다가되지 않습니다 이전 포스트 그레스의 JSON 쿼리 지원을 위해 이동합니다.

수동 UTF8 디코딩을 시도했습니다.

decodeUtf8IO :: ByteString -> IO (Either Text.UnicodeException Text)
decodeUtf8IO = try . evaluate . Text.decodeUtf8With Text.strictDecode

그것도 같은 문제가 있습니다.

발신: https://stackoverflow.com/questions/31671634/handling-unicode-sequences-in-postgresql

null 바이트는 PostgreSQL 문자열에서 유효하지 않습니다. 둘 다 제로 코드 포인트가 아닙니다.

현재 이것은 Haskell/Persistent가 postgres로 보내기 위해 이것을 직렬화하는 방식 때문이라고 생각합니다. 현재 이 이론을 검증하려고 노력하고 있습니다.

Aeson.encode 이미 NUL 문자를 \u0000 이스케이프 처리한 다음 Persistent가 거부합니다.

이에 대한 깔끔한 해결책을 찾는 것은 쉽지 않을 것입니다.

나는 이것을 조사하고 있었고 다음 속성이 유지되는 것 같습니다.

• "\u0000\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003" 는 UTF-8로 꽤 유효합니다. UTF-8은 \u0000 가 직접 표현되도록 허용하기 때문입니다.
• \u0000 허용되지 않습니다 jsonb 가로 변환 할 수 없기 때문에 text .

JSON으로 인코딩한 다음 Text 로 인코딩한 다음 잘못된 문자 시퀀스를 감지하고 잘못된 시퀀스가 ​​포함된 경우 JSON 개체를 거부하는 유일한 임시 솔루션입니다. 또한 \u0000 가 내가 거부해야 하는 유일한 시퀀스인지 궁금합니다.

두 개의 열을 저장할 수 없습니까? bytea 및 JSON(텍스트가 아닌 문자가 포함되지 않은 경우)을 사용하여 필요한 모든 것을 자유롭게 사용할 수 있습니다.

@erikd \u0000 제한 사항은 Postgres가 따르는 다른 모든 규칙과 함께 여기에 명확하게 명시되어

누수 추상화를 방지하려면 정확한 값(사용자가 제공한 대로)을 저장해야 합니다. 이것은 대략적으로 원래 의미를 유지하는 blob(= DB에 구조 없음) 또는 JSON 문자열 값을 의미합니다. 예를 들어 DB의 base64 인코딩 문자열 값(따라서 base64에서 실제 값으로 변환하는 순서).

임시 해결 방법 수정(Postgres에 삽입할 수 없는 메타데이터 개체 삭제)이 마스터에 병합되었습니다.

임시 수정이 적용된 모습입니다.

[db-sync-node:Info:37] [2020-09-22 10:19:09.66 UTC] insertShelleyBlock: epoch 84, slot 6060000, block 1816721, hash 3ec15354c53deae4eb26a206cc3185f799e80bd09393f279bce7e53a7d633144
[db-sync-node:Warning:37] [2020-09-22 10:19:24.08 UTC] insertTxMetadata: dropped due to a Unicode NUL character.
[db-sync-node:Warning:37] [2020-09-22 10:19:24.08 UTC] insertTxMetadata: dropped due to a Unicode NUL character.
[db-sync-node:Warning:37] [2020-09-22 10:19:24.10 UTC] insertTxMetadata: dropped due to a Unicode NUL character.
[db-sync-node:Warning:37] [2020-09-22 10:19:24.10 UTC] insertTxMetadata: dropped due to a Unicode NUL character.
[db-sync-node:Info:37] [2020-09-22 10:19:24.93 UTC] insertShelleyBlock: epoch 84, slot 6065000, block 1816973, hash 0ab0dd5c36c6eb480b8bbd05508be952c5ed8597a4e422af25bd80a905a9368d

도커가 수리되었는지 여부 및 수리 버전은 무엇입니까

고정되지는 않았지만 5.0.x ( 5.0.2 권장)에는 유니코드 NUL 문자가 포함된 tx_metadata 를 삭제하여 이 문제를 방지하는 해결 방법이 있습니다.