Gary's questions

Este exemplo fornece o resultado desejado de selecionar o primeiro, segundo e terceiro elementos filhos que são da classe "subhead". No entanto, minha pergunta é: existe algum método de seleção que selecione a primeira, segunda e terceira ocorrências da classe "subhead" independentemente de sua posição exata de filho no pai, de modo que isso funcione quando não se sabe com antecedência quais serão essas posições; e poderíamos usar as posições 1,2,3 em vez de 1,3,5, já que não se saberá quantos elementos irmãos estarão entre cada subhead?

Obrigado.

div.scrl_can * {
  height:25px;
  border: 1px solid black;
}
.subhead:nth-of-type(1) {
  background-color: blue;
}
.subhead:nth-of-type(3) {
  background-color: green;
}
.subhead:nth-of-type(5) {
  background-color: yellow;
}

<div id="main">
  <div>
    <div>
      <div class="scrl_can">
        <div class="subhead"></div>
        <div></div>
        <div class="subhead"></div>
        <div></div>
        <div class="subhead"></div>
        <div></div>
      </div>
    </div>
  </div>
</div>

Na criptografia OpenSSL em PHP usando aes-256-gcm, o tag_lengthvalor é escolhido pelo codificador ou é escolhido pelo método e retornado ao ponteiro como feito com o tag? Ele lê que pode ser entre 4 e 16. O tag_length inserido na função de criptografia é garantido como o comprimento da tag retornada?

Além disso, como os aad("Dados autenticados adicionais") são usados ​​e por que seriam usados?

Obrigado.

Tenho experimentado (a partir do CLI) os exemplos de criptografia em https://www.php.net/manual/en/function.openssl-encrypt.php e gostaria de saber como lidar com um arquivo maior, como um arquivo de banco de dados SQLite de alguns GB. Eu estava recebendo um erro de alocação de memória antes de seguir este exemplo na mesma página PHP.

Demorei para entender; mas finalmente consegui fazer funcionar em um banco de dados SQLite de 3 GB. Acho que base64 é o padrão se definir options=0 e eu estava tentando usar o exemplo mais novo fornecido para o caso simples junto com o exemplo antigo para um arquivo grande que usa opções de OPENSSL_RAW_DATA.

Minha pergunta é: essa abordagem dada naquele post de oito anos ainda é a abordagem adequada? Alguns dos exemplos dão um antes e depois da versão 7.1.

É correto usar os primeiros 16 bytes de um bloco criptografado como o próximo vetor de inicialização?

O número de blocos por criptografia/descriptografia é importante? Deve-se usar o maior tamanho que caiba na alocação máxima de memória ou algo mais?

<?php
//$key should have been previously generated in a cryptographically safe way, like openssl_random_pseudo_bytes
$key = "abcd1234dcba4321";
$cipher = "aes-256-cbc";
$feBlocks = 10000;
$fpPlain = fopen("../Database/filename.db",'rb');
$fpEncrypt = fopen("encrypted.enc", 'wb');
if (in_array($cipher, openssl_get_cipher_methods()))
{
    $ivlen = openssl_cipher_iv_length($cipher);
    $iv = openssl_random_pseudo_bytes($ivlen);
    // Put the initialzation vector to the beginning of the file
    fwrite($fpEncrypt, $iv);
    while (!feof($fpPlain)) {
        $plaintext = fread($fpPlain, $ivlen * $feBlocks);
        $ciphertext = openssl_encrypt($plaintext, $cipher, $key, $options=OPENSSL_RAW_DATA, $iv);
        // Use the first 16 bytes of the ciphertext as the next initialization vector
        $iv = substr($ciphertext, 0, $ivlen);
        fwrite($fpEncrypt, $ciphertext);
    }
    fclose($fpPlain);
    fclose($fpEncrypt);
}

  $fpEncrypt = fopen("encrypted.enc", 'rb');
  $fpPlain = fopen("decrypted.db",'wb');
  $ivlen = openssl_cipher_iv_length($cipher);
  // Get the initialzation vector from the beginning of the file
  $iv = fread($fpEncrypt, $ivlen);
  while (!feof($fpEncrypt)) {
     // we have to read one block more for decrypting than for encrypting
     $ciphertext = fread($fpEncrypt, $ivlen * ($feBlocks+1));
     $plaintext = openssl_decrypt($ciphertext, $cipher, $key, $options=OPENSSL_RAW_DATA, $iv);
     // Use the first 16 bytes of the ciphertext as the next initialization vector
     $iv = substr($ciphertext, 0, $ivlen);
     fwrite($fpPlain, $plaintext);
  }
  fclose($fpEncrypt);
  fclose($fpPlain);

Se as consultas SQL forem armazenadas em variáveis ​​Tcl declaradas em múltiplas linhas para mantê-las legíveis, use:

set ::SQL::QueryName {
}

e executado usando

db eval $::SQL::QueryName

algo deve ser feito nas strings de consulta, já que elas serão as chaves no cache de instruções preparadas?

Por exemplo, terminar cada linha com o caractere de continuação de linha \, construir com appendinstruções ou executar algum tipo de mapeamento nelas para criar uma única linha sem espaços desnecessários?

Não tinha pensado nisso antes porque o cache é meio automático no Tcl SQLite.

Obrigado.

Minha pergunta diz respeito a esse cenário. Estou armazenando texto como um BLOB usando E/S de blob incremental do SQLite na interface Tcl. Outra tabela no banco de dados contém linhas de dados de ponteiro que apontam para segmentos deste BLOB. Como os canais Tcl procuram locais de bytes e não locais de caracteres (o que presumo ser comum, não estou criticando o Tcl), preciso rastrear o byte_start, char_start, byte_length, char_length de cada ponteiro.

Chega uma solicitação ao Tcl que indica que um ponteiro existente (não os dados reais do buffer, mas apenas o próprio ponteiro) precisa ser dividido em dois ponteiros, começando em algum local de caractere. A solicitação vem da UI e esse código não sabe nada sobre a localização dos bytes e realmente nada sobre o BLOB.

Portanto, preciso extrair o segmento do BLOB, convertê-lo em texto e determinar o comprimento de bytes de pelo menos uma das duas novas partes e usar essas informações para determinar o byte inicial e o comprimento de bytes de ambos os novos ponteiros.

Eu usaria algo como abaixo no SQLite, mas, de acordo com o Dr. Hipp, todo o BLOB deve ser lido na memória para usar substr em um BLOB.

select
   octet_length(
      substr(
         cast(
            substr(
               buffer,
               byte_start,
               byte_length
            ) as text
         ),
         1,
         :len
      )
   )
from
   mem.pt_buffers
where
       doc_id = :doc_id
   and buffer_id = :buffer_id_s
;

Portanto, estou usando incrblob em Tcl que este exemplo ilustra. Parece gerar os resultados corretos, mas também parece dar muito trabalho. Por exemplo, o conteúdo está sendo extraído do BLOB apenas para determinar a posição do byte da posição do caractere do ponto de divisão. O conteúdo não é utilizado de outra forma, nem o BLOB está sendo modificado. Se não houvesse o problema de a posição dos bytes ser desconhecida pela UI, o conteúdo não precisaria ser extraído e a operação seria apenas aritmética.

Minhas perguntas são:

1. Estou fazendo isso da maneira mais difícil; existe uma abordagem mais simples?
2. Pode/deve ser feito mais diretamente no SQLite?

Obrigado por considerar minha pergunta.

package require sqlite3
sqlite3 db
db eval {create table test (id integer, data blob);}
db eval {insert into test values (1, zeroblob(100));}
puts [db eval {select id, cast(data as text) from test;}]
# 1 {}

# Previously, a request had to come in to append this string
# to the BLOB; to the non-zero portion, anyway. This is re-
# quired set-up for the question.
set fdBlob [db incrblob main test data 1]
chan configure $fdBlob -translation binary -buffering none
set bindata [encoding convertto utf-8\
     {This is some הַ / נָּבִ֑יא text cast as a BLOB.}]
chan puts -nonewline $fdBlob $bindata

puts [db eval {
   select
      length(data),
      length(cast(data as text)),
      length(:bindata)
   from
      test
   ;
}]
# 100 47 57

# Pre-split pointer data:
# piece  char_start char_length byte_start byte_length
# -----  ---------- ----------- ---------- -----------
# orig        0          47           0         57

# Request comes in to split the pointer at the 27th character
# into two pointers: characters 0-26 and 27-end.

# Retrieve the segment of the BLOB. Have to retrieve the full
# piece because do not know where to split the bytes. Convert
# from binary to text. Note [chan read numChars] reads chars,
# but since channel is configured as binary, same as bytes.
chan seek $fdBlob 0 start
set data [encoding convertfrom utf-8 [chan read $fdBlob 57]]

# Split the piece. Need only one or the other, not both.
set frontEnd [string range $data 0 26]
set tailEnd [string range $data 27 end]
puts "\"$frontEnd\" \"$tailEnd\""
# "This is some הַ / נָּבִ֑יא " "text cast as a BLOB."

# Convert the substring back to binary and determine byte length.
set frontEndByteLen [string length [encoding convertto utf-8 $frontEnd]]
set tailEndByteLen [expr {57-$frontEndByteLen}]
puts "Front-end data: byte_start: 0 byte_length $frontEndByteLen"
puts "Tail-end data: byte_start: $frontEndByteLen byte_length $tailEndByteLen"
# Front-end data: byte_start: 0 byte_length 37
# Tail-end data: byte_start: 37 byte_length 20

# Test it out by seeking to the start byte and extracting the tail-end.
chan seek $fdBlob $frontEndByteLen start
set data [encoding convertfrom utf-8 [chan read $fdBlob $tailEndByteLen]]
puts $data
# text cast as a BLOB.

# Then the pointer table will have these new pieces inserted.
# piece  char_start char_length byte_start byte_length
# -----  ---------- ----------- ---------- -----------
# front       0          27           0         37
# tail       27          20          37         20