|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2020-02-03 22:06 UTC] steve dot lloyd at gmail dot com
Description: ------------ Last character of a UTF-8 string gets messed up. See stackoverflow URL in Test Script section. I have tried this with multiple PHP versions. I have concluded it must be an issue with PHP ODBC functions as it works fine in other languages (python, isql). Test script: --------------- https://stackoverflow.com/questions/59904479/last-character-issue-with-sap-hana-utf8-on-php Expected result: ---------------- 因采购/仓库而被冻结 因任务清单/BOM而被冻结 MPN:BOM抬头冻结 gesp. für Besch./Lager gesp. für Arb.plan/Stückl Actual result: -------------- 因采购/仓库而被冻ad 因任务清单/BOM而被ader MPN:BOM抬头冻结 gesp. für Besch./Lager gesp. für Arb.plan/Stüca PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Oct 25 06:00:01 2025 UTC |
PDO has the same problem. test script: -------------------- try { $pdo = new PDO("odbc:{$datasource}",$username, $password); $query = "select * from sltschema.t141t"; $poo = $pdo->prepare($query); $poo->execute(); $row = $poo->fetch(PDO::FETCH_ASSOC); print_r($row); } catch (PDOException $e) { echo "Connection failed : ". $e->getMessage(); } Result: --------------- Array ( [MANDT] => 000 [SPRAS] => 1 [MMSTA] => 01 [MTSTB] => 因采购/仓库而被冻tc [ZMODIFIEDTS] => 20200131152705439 [ZMODIFIEDTS_TEST] => 2020-01-31 15:27:05.4380000a ) -------------------------- The bug you referred to seemed to say this was patched but it is still an issue in PHP 7.4. How do I patch/resolve this issue?> The bug you referred to seemed to say this was patched but it is > still an issue in PHP 7.4. I rather think that some issues have been fixed, but likely not all. > The field I am querying is set to nvarchar(25). If I cast it as > nvarchar(50) it works. That's interesting, since echo strlen('因采购/仓库而被冻结'); // 28 echo strlen('gesp. für Arb.plan/Stückl'); // 27 So apparently either the driver or our binding (or maybe some configuration setting) is confused by UTF-8. I'm not sure how to debug this best. Is there something on CentOS like the Windows ODBC tracing? A trace of a minimal reproduce script could be very helpful.What is the default encoding (the result of System.getProperty("file.encoding")) of your environment? I have tried getBytes() for all the Charset supported in Java. (https://www.cuims.net/)github.comYou really need a UTF-8 Library if you are going to work with UTF-8. However for this task I think something like this may suffice: void pop_back_utf8(std::string& utf8) { if(utf8.empty()) return; auto cp = utf8.data() + utf8.size(); while(--cp >= utf8.data() && ((*cp & 0b10000000) && !(*cp & 0b01000000))) {} if(cp >= utf8.data()) utf8.resize(cp - utf8.data()); } int main() { std::string s = "κόσμε"; while(!s.empty()) { std::cout << s << '\n'; pop_back_utf8(s); } } (https://www.fortivacreditcard.net/)github.com